«Та история с паролями на скриншоте, это лишь верхушка айсберга. Настоящая проблема в том, что меры безопасности мы представляем как что-то внешнее, что защищает нас от хакеров и вирусов. А на деле самый критичный сбой происходит внутри, на уровне привычки. Внутренняя угроза, это не только злой умысел, это банальная человеческая оплошность, умноженная на повсеместное непонимание, как на самом деле работают цифровые инструменты, которые мы используем каждый день. Фокус сместился с технической сложности на социальную.»
История звучит как анекдот: сотрудник делает скриншот, чтобы показать коллеге настройку интерфейса, а на заднем фоне развёрнут менеджер паролей со всеми логинами. Или открыт текстовый файл с креденшелами, или висит чат с пересылкой данных. Казалось бы, элементарная невнимательность. Но если посмотреть шире, это симптом системного сбоя, который касается не одного человека, а целых команд и подходов к организации работы в IT.
Почему это происходит: невнимательность или неправильные процессы?
Чаще всего такую ошибку списывают на человеческий фактор. Сделал и отправил, не глядя. Но если сотрудник регулярно работает с конфиденциальными данными, почему у него возникает потребность делать скриншоты всего рабочего стола? Ответ обычно лежит в плоскости процессов.
Скриншот, это быстрый способ зафиксировать и передать проблему. Когда нужно показать ошибку в интерфейсе, странное поведение системы или просто поделиться видом настройки, альтернатив часто не предлагают. Записать видео? Слишком долго. Сделать выборочный скриншот области? Нужно лишнее действие, о котором многие забывают в потоке задач. Система по умолчанию поощряет самый простой и рискованный путь.
Вторая причина — отсутствие чёткого разграничения сред. На одном и том же мониторе сотрудник может одновременно держать открытыми личный мессенджер, рабочую почту, административную панель базы данных и тот самый файл с паролями. Контексты смешиваются, внимание рассеивается. Окно с паролями становится просто частью фонового шума.
Что именно «горит» на таком скриншоте
Казалось бы, ну пароли. Но масштаб ущерба зависит от того, что именно попало в кадр.
- Пароли к служебным системам. Доступ к внутренним wiki, трекеру задач, CI/CD. Это может дать представление об инфраструктуре проекта.
- Креденшелы к базам данных, бэкенд-админкам. Прямой доступ к данным, включая персональные данные пользователей, что является прямым нарушением 152-ФЗ.
- Ключи доступа к облачным хранилищам или API-токены. Скомпрометированный токен может дать доступ на запись или удаление данных от имени сервисного аккаунта.
- Пароли к средствам криптографической защиты информации (СКЗИ). Если компания работает с гостайной или в регулируемых отраслях, утечка паролей от СКЗИ, это уже инцидент для ФСТЭК.
- Скриншот окна мессенджера, где в истории видны другие пересылаемые пароли или чувствительная информация. Утечка приобретает каскадный эффект.
Главная опасность — даже не в том, что злоумышленник сразу получит доступ. А в том, что эти данные попадают в неконтролируемую среду (чаты, почта, облачные диски), откуда их уже невозможно отозвать. Они становятся цифровым активом, который может быть использован спустя месяцы.
Как это связано с регуляторикой (152-ФЗ, ФСТЭК)
Ситуация со скриншотом паролей, это чистый пример нарушения требований к защите персональных данных и информации ограниченного доступа.
Согласно 152-ФЗ, оператор ПДн обязан принять меры, обеспечивающие защиту персональных данных от неправомерного доступа. Хранение паролей в открытом виде на рабочем столе, а уж тем более их непреднамеренная передача, это явное несоблюдение организационных и технических мер защиты. В отраслевых стандартах ФСТЭК (например, в приказах, регулирующих создание систем защиты информации) всегда есть требования к управлению учётными записями и паролями, включая их хранение и передачу.
Если в результате такой утечки произойдёт инцидент (утечка данных клиентов), компания может получить не только штраф по 152-ФЗ, но и предписание от Роскомнадзора или ФСТЭК о необходимости исправить нарушения, что часто влечёт за собой дорогостоящий аудит и перестройку процессов. Для организаций, работающих с госзаказом, такие инциденты могут поставить крест на допуске к работам.
Технические и организационные решения
Бороться с одной лишь «невнимательностью» бесполезно. Нужно менять среду и давать безопасные альтернативы.
1. Запретить хранение паролей в открытом виде
Это базовое правило. Вместо текстовых файлов и стикеров — использовать менеджеры паролей (KeePass, Bitwarden). Корпоративные решения позволяют хранить доступы в зашифрованном хранилище с разграничением прав. Пароль от базы — единственный, который нужно помнить.
2. Изменить поведение при создании скриншотов
Здесь нужны и технические, и обучающие меры.
- Настройка инструментов по умолчанию. Установить программу для скриншотов, которая по умолчанию делает снимок не всего экрана, а выбранной области. Это добавляет один лишний шаг — выбор области, — который и становится моментом осознанности, когда человек видит, что попадает в кадр.
- Использование режима «невидимого окна». Некоторые менеджеры паролей и админ-панели могут иметь функцию скрытия содержимого при обнаружении действия создания скриншота (хотя это сложнее реализовать).
- Внедрение DLP-систем. Системы предотвращения утечек могут детектировать на скриншотах (и в буфере обмена) определённые шаблоны: строки, похожие на пароли, токены, номера карт, и блокировать их отправку через неуполномоченные каналы.
3. Разделение рабочих контекстов и сред
Эффективный, но более затратный подход.
- Виртуальные машины или отдельные рабочие столы. Для работы с критической инфраструктурой или данными можно использовать изолированную среду. Скриншот, сделанный внутри неё, не захватит окна личного мессенджера с основного рабочего стола.
- Жёсткое разграничение ПО. На рабочем компьютере, который имеет доступ к prod-базам, не должно быть личных мессенджеров или почтовых клиентов, через которые обычно и отправляются скриншоты. Для коммуникации использовать только корпоративные, контролируемые инструменты.
4. Культура безопасного обмена информацией
Техника бессильна, если нет понимания. Нужно формировать привычки.
- Объяснять, что пароли, токены, ключи, это не просто текст, а цифровые ключи от дверей. Их нельзя оставлять на столе (виртуальном) и показывать посторонним.
- Внедрять внутренние инструкции: «Если нужно показать ошибку, обрежь скриншот до области ошибки. Если на фоне что-то лишнее — замажь или переделай».
- Поощрять практику взаимной проверки. Перед отправкой ответственного скриншота коллеге можно попросить соседа взглянуть одним глазом: «Ничего лишнего не видно?».
Что делать, если инцидент уже произошёл
Если пароль всё же «уплыл» на скриншоте, действовать нужно быстро и системно.
- Немедленно изменить скомпрометированный пароль/отозвать токен. Во всех системах, где он использовался. Это приоритет номер один.
- Оценить круг получателей. Скриншот отправили одному коллеге в рабочем чате? Или выложили на публичный форум? От этого зависит масштаб.
- Попросить получателя удалить сообщение/файл. Если это возможно. Стоит помнить, что в большинстве мессенджеров и почтовых систем это не гарантирует удаление с серверов.
- Зафиксировать инцидент. В соответствии с внутренними процедурами информационной безопасности. Даже если всё обошлось, это нужно для анализа первопричин и недопущения в будущем.
- Проанализировать причину. Почему пароль был в открытом виде? Почему попал в кадр? Что в процессах можно изменить, чтобы это не повторилось?
История с коллегой и скриншотом — не повод для поиска виноватого. Это чёткий сигнал о том, что в цепочке процессов появилось слабое звено, где удобство победило безопасность. В российском IT-контексте, где требования регуляторов становятся всё жёстче, а стоимость инцидентов растёт, умение выстраивать работу так, чтобы подобные ошибки были технически затруднены или сразу видны, становится не просто хорошим тоном, а профессиональной необходимостью. Безопасность, это не только межсетевые экраны и шифрование, но и правильная настройка кнопки «Сделать скриншот».