«Большинство думает, что их личные данные в безопасности, если они не публикуют их напрямую. Но реальность такова: следы, которые вы оставляете в интернете, складываются в пазл, ключевой фрагмент которого — пароль от почты — может лежать в публичном доступе в вашем же проекте. И это не хакерская атака, а обычный результат человеческой невнимательности» .
Найти учётные данные топ-менеджеров компании — задача, которая кажется сложной лишь на первый взгляд. Часто для этого не требуются дорогие инструменты или глубокие знания социальной инженерии. Достаточно знать, где искать, и провести систематическую проверку открытых источников, которые сами сотрудники наполняют данными. В российском IT-контексте, где требования к защите информации (ФСТЭК, 152-ФЗ) становятся всё строже, подобные уязвимости становятся критическим риском.
Основа поиска: публичные Git-репозитории
Первое и самое очевидное место, это системы контроля версий, такие как GitLab или Bitbucket, если в компании используют внутренние решения, или GitHub, если работают с открытым кодом. Разработчики, особенно в спешке, могут случайно закоммитить и запушить конфигурационные файлы, содержащие чувствительную информацию. Это не обязательно файл .env с паролями от базы данных. Это могут быть:
- Скрипты деплоя или CI/CD-конфигурации (
gitlab-ci.yml,.gitlab-ci.yml,deploy.sh), где прописаны логины и токены для доступа к внутренним системам. - Конфигурационные файлы для тестовых сред, где для простоты используют реальные учётные данные, заменяя лишь префикс хоста.
- Даже одноразовые заметки или дампы базы данных, созданные для отладки и забытые в ветке разработки.
Поиск начинается не с имени директора, а с домена компании. Зная корпоративный домен (например, company.ru), можно искать его комбинации с типовыми названиями переменных.
Пример поискового запроса для Git:
"company.ru" password filename:env
"@company.ru" filename:json
"api_key" "company"Анализ публичных проектов и документации
Второй вектор — техническая документация, выложенная для партнёров или клиентов. Это могут быть API-документация в формате OpenAPI (Swagger), инструкции по интеграции, размещённые на корпоративном портале разработчика. В таких документах, особенно в разделах с примерами запросов, часто оставляют тестовые ключи доступа (API-токены), которые по ошибке не отзывают. Эти токены могут предоставлять доступ к внутренним сервисам, включая почтовые системы или CRM, где можно найти учётные записи руководства.
Более тонкий метод — анализ публичных проектов на языках типа Python или JavaScript. Библиотеки для работы с корпоративной почтой (например, через IMAP или API почтовых сервисов) иногда содержат в примерах кода или тестах хардкоженные логины для демонстрации.
Пример фрагмента, который может встретиться в открытом коде:
# Пример подключения к тестовому ящику
mail_client = ImapClient("mail.company.ru", "director.ivanov@company.ru", "TempPass123!")Такой код, попав в публичный репозиторий, становится мгновенной уязвимостью.
Сбор информации из служебных систем
Третий, менее очевидный, источник, это служебные веб-интерфейсы, которые по ошибке могут быть открыты для индексации поисковыми системами. Речь идёт о:
- Внутренних вики-системах (например, на базе Confluence или MediaWiki), где в статьях о процедурах аварийного доступа могут быть указаны общие учётные данные.
- Системах мониторинга (Zabbix, Grafana), которые иногда настраивают с дефолтными паролями или оставляют демо-дашборды с реальными данными доступными извне.
- Порталах с отчётами или логами, выложенными для удобства отладки.
Поиск здесь ведётся через специализированные операторы в поисковых системах. Например, можно искать страницы, содержащие слова «пароль» или «credentials» в пределах домена компании.
Пример запроса для поисковой системы:
site:company.ru intitle:"Dashboard" "password"
site:wiki.company.ru "временный доступ"Финальная сборка и проверка
Собрав фрагменты из разных источников — email из Git-коммита, пароль из тестового скрипта, токен из документации — можно попытаться восстановить полную картину доступа. Ключевой момент: люди склонны повторять пароли. Пароль, найденный в тестовом скрипте к базе данных, с высокой вероятностью может быть использован и для учётной записи в корпоративной почте или VPN.
Проверка найденных данных не должна проводиться прямым входом в систему, это незаконно. Достаточно косвенных признаков. Например, если найден логин вида ivanov_ai и пароль, можно попробовать восстановить пароль от привязанного аккаунта в публичных сервисах (где используется корпоративная почта), используя функцию «Забыли пароль?». Система подтвердит существование учётной записи, отправив письмо на email. Сам факт такой возможности — уже критический инцидент.
Почему это работает в российских компаниях?
В российском сегменте IT сохраняется ряд специфичных проблем:
- Разрыв между разработкой и безопасностью. Команды разработки часто работают в условиях жёстких дедлайнов, а процессы code review и проверки на утечку секретов (с использованием tools like TruffleHog или Gitleaks) внедрены фрагментарно.
- Наследие «временных решений». Многие внутренние инструменты и скрипты были написаны годы назад как временные, но продолжают работать. Их исходный код, содержащий учётные данные, мог быть выложен на внутренний Git-сервер, который позже частично открыли для внешнего доступа.
- Слабая осведомлённость о публичности. Сотрудники не всегда отдают себе отчёт, что внутренний wiki или Git-репозиторий с настройкой «виден всем участникам проекта» может быть проиндексирован или доступен извне при определённых настройках сети.
Что делать, чтобы этого не произошло?
Меры защиты носят преимущественно организационно-технический характер и напрямую пересекаются с требованиями регуляторов.
| Мера | Техническая реализация | Связь с требованиями (ФСТЭК, 152-ФЗ) |
|---|---|---|
| Сканирование на утечки секретов | Внедрение pre-commit хуков и CI-пайплайнов, которые автоматически проверяют код на наличие паттернов паролей, токенов, приватных ключей. Использование инструментов вроде git-secrets, detect-secrets. |
Реализация мероприятий по контролю целостности и конфиденциальности информации (п. 19 Приказа ФСТЭК № 21). |
| Строгий контроль доступа к системам | Регулярный аудит списков доступа к Git-репозиториям, wiki, порталам мониторинга. Применение принципа наименьших привилегий. Отказ от публичных репозиториев для внутреннего кода. | Разграничение прав доступа пользователей (требования к СЗИ). |
| Использование менеджеров секретов | Внедрение Vault-систем или облачных KMS (Key Management Service) для хранения паролей, ключей, токенов. Конфигурационные файлы должны содержать только ссылки на секреты. | Защита ключевой информации (криптографических ключей, паролей). |
| Периодический аудит открытых данных | Проведение регулярных (ежеквартальных) ручных или автоматизированных проверок через публичные поисковики и специализированные сервисы мониторинга утечек на предмет упоминания домена компании и типовых секретов. | Мониторинг информационной безопасности и реагирование на инциденты. |
| Повышение осведомлённости | Обязательные тренировки для разработчиков и DevOps-инженеров на тему безопасного обращения с учётными данными, последствий публикации конфигов. | Обучение работников, эксплуатирующих информационные системы. |
Главный вывод прост: логин и пароль директора или любого другого сотрудника чаще всего оказываются в открытом доступе не из-за злого умысла, а из-за цепочки мелких упущений, ставших нормой в рабочем процессе. Поиск, описанный выше,, это не демонстрация хакерских навыков, а проверка на соблюдение базовых гигиенических правил информационной безопасности. В условиях ужесточения регуляторного давления подобные «мелочи» могут стать причиной не только утечки данных, но и серьёзных штрафов по 152-ФЗ.