Как случайно нашли все пароли компании в открытом Excel на Яндекс.Диске

Факт нахождения открытого файла с паролями на Яндекс.Диске, даже если это выглядело случайностью, всегда говорит о более глубокой проблеме — отсутствии чёткого контроля над тем, как и куда сотрудники выгружают чувствительные данные. Классические уязвимости могут быть успешно закрыты средствами защиты, но реальная угроза зачастую скрывается в человеческом факторе и рутинных ошибках в организации процессов обращения с информацией.

Как произошла утечка: случайность, ставшая правилом

Ситуация с обнаружением файла началась во многом типично для аудитов российских компаний. Во время планового теста на проникновение (пентеста), где задача команды — пройти по всем возможным сценариям атаки, одним из обязательных этапов выступает OSINT — сбор информации из открытых источников. При использовании стандартных методик эксперты вводят сочетания корпоративного домена, адресов, наименований сервисов и ключевых фраз: «пароли», «credentials», «доступ» и т.д. В этот раз, как и в ряде других аудитов, буквально за считаные минуты был найден документ на Яндекс.Диске, открытый для всех желающих по публичной ссылке.

Особенность «публичной ссылки» на Яндекс.Диске — её индексируемость поисковыми системами. Даже если ссылка выглядит уникальной, а файл не отображается в каталоге, он легко обнаруживается с помощью специализированных поисковых запросов, доступных любому, кто интересуется конкретным доменом или тематикой (например, термин «пароли» или название компании). В данном случае сотрудник поспешил упростить обмен — и файл с паролями стал доступен для скачивания всем пользователям Интернета, без малейшей защиты или даже временного ограничения доступа. Никто не проконтролировал ни сам факт такой публикации, ни последствия для информационной безопасности компании.

[ИЗОБРАЖЕНИЕ: Пример интерфейса Яндекс.Диска с настройками доступа («Публичная ссылка» выделена без защиты и срока действия)]

Как выглядел сам документ? На первый взгляд, ничего необычного: стандартная таблица Excel с колонками — «Система/Сервис», «Логин», «Пароль», «Примечание». Всё, что нужно для быстрого обмена внутри команды — или для злоумышленника, чтобы тут же получить управление над ключевыми системами.

Система/Сервис	Логин	Пароль	Примечание
CRM Bitrix24	ivanov@company.ru	Qwerty123!	Основной доступ
Внутренний портал	ivanov_i	IvaNov1985
База знаний Confluence	i.ivanov	такой же как в портал

В результате, все сотрудники фирмы — а зачастую и подрядчики, интеграторы, арендаторы — оказались потенциально под угрозой компрометации. Кроме классических сценариев с раскрытием информации, это даёт путь для хакеров к финансовым системам, личным данным пользователей, всей IT-инфраструктуре. Учитывая, что многие пароли повторяются, реальный ущерб трудно переоценить — фокус быстро смещается в сферу ответственности по 152-ФЗ и требованию срочно реагировать в интересах регуляторов.

Вторичный риск — подобную ошибку часто не замечают месяцами. Пока кто-то извне не получит реальный доступ, руководство только догадывается о возможном масштабировании проблемы на другие файлы, облака, платформы — ведь один прецедент обычно не бывает единичным.

Откуда проблема: человеческий фактор и недонастроенная инфраструктура

Подобная утечка — результат целого комплекса недостатков. Они возникают по следующему механизму:

• Желание действовать быстро. Не хватает внутренних инструментов передачи паролей или файлов — и сотрудник, пользуясь «сделать быстро», выгружает Excel на облако. При этом чувствительность данных не оценивается, стандартные процедуры проходят мимо. Критически важно понимать, что это типовой сценарий для срочных задач: предоставление временного доступа, работа с подрядчиком, обмен информацией в режиме форс-мажора.
• Доступность облаков и минимальные ограничения по умолчанию. Российские облачные сервисы упрощают создание и распространение ссылок по максимуму: всего в пару кликов документ становится публичным, хотя в ряде западных хранилищ для этого требуется отдельное подтверждение или даже оплата. Это подталкивает к формированию ложной уверенности — «ничего страшного, файл ведь не в общем доступе».
• Отсутствие DLP-систем и формализованных регламентов. В большинстве компаний среднего и малого бизнеса мощных DLP-решений либо нет, либо они есть, но действуют только в части контроля почтовых вложений. Облака и другие каналы остаются вне поля мониторинга. Ни в одной корпоративной инструкции нет запрета на хранение паролей в открытых таблицах или публичном облаке, а требования ИБ часто воспринимаются как «лишняя нагрузка».
• Плохая культура хранения учётных данных. Традиция работы с «общим файлом паролей» тянется ещё с 90-х годов, когда подобных угроз не было. Даже в современных условиях сотрудники предпочитают хранить критически важную информацию в Excel, Word, txt-документах, оправдывая это привычкой, удобством, или отсутствием альтернативных средств.
• Отсутствие контроля со стороны управления и ИТ-служб. В ряде случаев отсутствует даже базовый аудит облачных рабочих пространств: никто не отслеживает публичные ссылки на корпоративном Яндекс.Диске, не ведёт инвентаризацию файлов, не ограничивает право публикации по ссылке, не выключает индексацию публичных папок.

Проблема имеет не только организационное, но и правовое измерение. По факту публикация подобных файлов квалифицируется как инцидент безопасности персональных данных — нарушение требований 152-ФЗ и нормативов по технической защите информации (ФСТЭК).

Как действовать после обнаружения: пошаговый протокол

Ограничиться удалением файла — стратегическая ошибка. Классический план реагирования должен предполагать следующие шаги:

1. Фиксация события. Всегда фиксируются доказательства: делаются скриншоты страницы Яндекс.Диска, настроек доступа, списка пользователей, фрагментов открывшегося файла. По возможности сохраняется история изменений файла, чтобы иметь всю хронологию. Рекомендуется занести информацию в журнал инцидентов ИБ.
2. Ликвидация опасности. Связавшись с владельцем аккаунта или с администратором корпоративного хранилища, немедленно блокируется доступ к файлу, отменяется публичная ссылка, удаляется сам файл и резервные копии. Затем выполняется поиск аналогичных файлов с помощью фильтров и запросов — в случае обнаружения допускается полное изъятие всех подобных документов.
3. Обнуление паролей. Все найденные пароли и логины немедленно признаются скомпрометированными, вне зависимости от того, есть ли подтверждённое их использование. Обновляются учётные данные в соответствующих сервисах, включая сброс резервных факторов (двухфакторная аутентификация, привязка почтовых ящиков и телефонов).
4. Анализ причин и масштабов. Запрашиваются объяснения от лица, создавшего файл, анализируется аудит доступа: кто мог увидеть файл, сколько времени он был доступен, какие поисковые системы его индексировали (можно использовать инструменты вроде Google Cache, Яндекс.Поглядеть), уточняется риск остаточного доступа по кэшам. Особое внимание уделяется, если внутри файла содержались персональные данные, коммерческие сведения, служебные или иные данные, имеющие защитный статус.
5. Информирование и обучение сотрудников. Руководитель службы ИБ готовит резюме инцидента, докладывает информацию на уровне руководства, формализует выводы и предложения по недопущению аналогичных происшествий. Всем сотрудникам, задействованным в процессе передачи и хранения паролей, разъясняются факты и предоставляются инструкции по использованию защищённых каналов и менеджеров паролей.
6. Отчёт и уведомление регуляторов (при необходимости). Если в открытом доступе оказался файл с персональными данными, событие квалифицируется как инцидент по 152-ФЗ, готовится сообщение для Роскомнадзора, при необходимости составляется отчёт для ФСТЭК.

Применение такого протокола позволяет минимизировать последствия инцидента, ускорить восстановление контроля над инфраструктурой и снять критические вопросы при внешних проверках.

Регулярный аудит: не ждать беды, а предупреждать

Практика единичной проверки облачных источников или реагирования только на «находки» неизбежно приводит к новым утечкам и проеданию доверия в коллективе. Эффективная защита предполагает постоянный превентивный аудит: раз в неделю или месяц проводится оперативный поиск уязвимых или публичных источников, куда могли попасть рабочие документы, базы и учётные данные, связанные с компанией.

Что и как искать

• Структурированные поисковые запросы. Используются операторы, позволяющие минимизировать шум: site:disk.yandex.ru "company.ru" пароли OR credentials, filetype:xls filetype:xlsx, сочетания с «логин», «база», «user», «пользователь». Данные фильтры позволяют сразу находить только Excel- или Word-файлы, размещённые по публичной ссылке. Для русскоязычных компаний комбинируются ключевые слова на обоих языках («доступ», «пароли» / «passwords», «access»).
• Использование собственной аналитики и анализа ссылочного окружения. Компаниям рекомендуется периодически проводить ревизию публичных ссылок внутри корпоративных облаков. По возможности внедряются дополнительные инструменты Google Alerts, Яндекс.Алертс для отслеживания новых появлений специфических фраз или документов, связанных с брендом или уникальными словами.
• Примеры сочетаний запросов для самостоятельной проверки:
  • site:disk.yandex.ru/ "название_компании" пароли filetype:xls
  • site:disk.yandex.ru "логин:пароль"
  • site:disk.yandex.ru "ПДн" OR "ФИО" OR "паспорт" OR "ИНН"
• Детальное тестирование с помощью специализированных сканеров. Для крупных организаций использование отечественных сервисов мониторинга (Surfpatrol, CiphrGenie, продукты InfoWatch/СёрчИнформ) позволяет настроить автоматический анализ не только по внешним, но и по внутренним облачным хранилищам, интегрировать собственные поисковые шаблоны и алерты. Такой подход показывает максимальную эффективность при постоянных изменениях команд и появлении новых рабочих групп.

[ИЗОБРАЖЕНИЕ: На скриншоте поисковой системы выделен пример сложного поискового запроса и найденные публичные ссылки на Яндекс.Диск]

Автоматизация и мониторинг

• Мониторинговые сервисы. Классические продукты DLP теперь поддерживают проверку не только внутренних каналов, но и публичных репозиториев и облачных хранилищ. Российские системы (например, InfoWatch Traffic Monitor, Falcongaze SecureTower, SearchInform DLP) способны настроить автоматическую выгрузку результатов сканирования по ключевым словам и облачным сервисам — результаты сразу поступают в рабочие отчёты или алерты. Интеграция с SIEM-платформами повышает эффективность за счёт объединения событий из разных источников.
• Регламенты и периодический пересмотр процедур. Необходимо не только формировать шаблоны поисковых запросов (для OSINT, анализа в поисковых системах, внутреннего аудита), но и включать выполнение этих действий во внутренний регламент ИБ. Руководитель службы ИБ обязан обеспечить документирование, внедрение чек-листов для периодической ревизии — не реже одного раза в месяц, даже если нет внешних требований.
• Использование административных и встроенных инструментов облачных сервисов. Во многих корпоративных подписках на те же Яндекс.Диск или Mail.ru Облако доступны журналы доступа, логи публикации ссылок. Требуется регулярно выгружать отчеты с перечнем всех активных публичных ссылок, проводить их сверку с утверждёнными регламентами и немедленно устранять нарушения. Для контроля индексации можно оперировать настройками «robots.txt» или корпоративным политиком (если это поддерживается провайдером).
• Интеграция с внутренними уведомлениями и образовательными сервисами. Не все сотрудники смогут мгновенно освоить всю процедуру аудита, поэтому полезно разместить пошаговую инструкцию по проверке публичных файлов, спискам запрещённых к загрузке типов данных. Иногда IT-службы размещают автоматические уведомления или pop-up окна при попытке выгрузить файл на облако или сформировать публичную ссылку с типовым названием.

Профилактика: внедрять, а не надеяться на удачу

Ни один инцидент расследовать и компенсировать последствия проще, чем устранять репутационные и финансовые потери от массовых утечек. Если компания декларирует соответствие требованиям ФСТЭК, ФСБ, Роскомнадзора и других регуляторов, профилактика уязвимостей при работе с облаками и паролями должна быть заложена не только в локальных актах, но и в ежедневной практике.

• Внедрение корпоративного менеджера паролей. Организуется категорический запрет на хранение паролей в незащищённых Excel, Word, txt. Документируется переход на централизованный менеджер: KeePass, Bitwarden, отечественные аналоги (например, Password Manager от Код Безопасности или SinglePoint). Разграничиваются и протоколируются права доступа, все действия c паролями логируются, ведутся отчёты.
• Разработка и внедрение строгих регламентов работы с облачными сервисами. Систематизируется перечень разрешённых и запрещённых к хранению в облаке категорий информации (учётные данные, пароли, ПДн, документы, финансовые отчёты). Чётко формулируются и доводятся до всех сотрудников требования — что категорически нельзя переносить в публичные облака даже на несколько минут.
• Настройка DLP и средств обнаружения утечек. В современных продуктах для защиты информации внедряются шаблоны идентификации типовых форматов паролей: строки «логин:пароль», многие типичные рукописные фрагменты («Логин», «Доступ админа», «Root», «DB_Connect», «API-ключ»). На русском и английском создаются правила для блокировки выгрузки/отправки подобных файлов в облако или на email.
• Техническое ограничение выгрузки файлов из корпоративной среды в облако для небезопасных типов файлов. Через настройку прокси, межсетевых экранов и политик endpoint-решений осуществляется фильтрация отправки Excel, Word-документов по ключевым шаблонам (например, по названиям: password*, пароли*, credentials*, users*), настройка блокировки загрузки на публичные файлообменники с рабочих машин. Административный доступ к данным инструментам конфигурируется отдельными учетными записями.
• Обязательное включение сценариев с паролями в учебные программы по инфобезопасности. На всех вводных и периодических тренингах проводится подробный разбор инцидентов с открытыми файлами на облаках, моделируются реальные последствия утечек в рабочей и домашней ИТ-инфраструктуре. Формируются памятки с типовыми примерами, организуются регулярные тематические рассылки.
• Проведение сценарных учений по реагированию на утечку информации. Регламентируются действия при обнаружении открытых файлов — кто ответственен за фиксацию, как фиксируются доказательства, кто устанавливает причины и готовит отчёт, какие шаги требуются по очистке и изменению настроек. Такие учения эффективно выявляют пробелы на стыке между ИБ и реальными корпоративными процессами.
• Аудит доверенных/публичных ресурсов в зоне ответственности компании. Рекомендуется не только закрывать открытые публичные ссылки, но и проводить ревизию всех ресурсных сред (корпоративный чат, серверные каталоги, общие облачные пространства), где по ошибке могли быть размещены чувствительные данные.

Только комплекс таких мер, сочетающий технические инновации и образовательные подходы, способен создать реальную «гигиену» работы с облачными сервисами в любой, даже самой гибкой и динамичной компании.

К чему это всё: сигнал о качестве безопасности

Обнаружение открытого файла с паролями в публичном облаке — всегда индикатор системной несостоятельности, а не единичная ошибка. Это лакмусовая бумажка зрелости архитектуры информационной безопасности, сценариев реагирования и культуры обращения с корпоративными и персональными данными. Ни один технический аудит, ни одна система защиты не смогут заменить регулярную проверку облачных ресурсов, аудит публичных источников и системное обучение сотрудников.

В условиях российских реалий, где минимизация бюрократии, доверие между коллегами и стремление к технологическому удобству конкурируют с требованиями регуляторов (ФСТЭК, Роскомнадзор), только регулярные профилактические проверки, внедрение строгих регламентов и сценарное обучение помогут защитить бизнес от инцидентов, угрожающих как финансовыми потерями, так и уголовной ответственностью за допущенные утечки.

Базовые принципы таковы:

• Публичный файл с паролями — риск не только потери коммерческой тайны, но и автоматической эскалации до расследования по 152-ФЗ или иным положениям права.
• Осознанно хранить критические данные следует только в специализированных менеджерах, реализующих разграничение доступа и контроль изменений.
• Технический, организационный и просветительский контроль должны быть выстроены как единая система, интегрированная в ежедневную работу.

Любой выявленный файл с паролями — повод пересмотреть подходы, усилить проверку, обновить и технические, и процессные инструменты защиты. Только такая последовательная работа позволяет не бояться облаков, а использовать их безопасно, эффективно и в полном правовом соответствии с российским и отраслевым законодательством.