«Забудь про аудиторские отчёты. Реальная безопасность видна изнутри — в мелочах, к которым все привыкли. За полчаса можно увидеть больше, чем за неделю формальной проверки, если смотреть не по чек-листу, а глазами того, кому всё это нужно взломать.»
Внешние проверки дают бумагу для регулятора, но часто пропускают суть. Грубые уязвимости, на которые не обращают внимания годами, обычно лежат на поверхности. Их поиск не требует спецсредств — достаточно командной строки, наблюдательности и смены точки зрения с пользователя на атакующего.
Подготовка: переключи контекст
Перестань быть сотрудником. Стань на минуту злоумышленником, который ищет лёгкий вход, или проверяющим из ФСТЭК. Не нужно запускать сканеры — начни с составления двух карт: что видно извне и что доступно внутри сети.
Что светится в интернете
Узнай публичный IP-адрес организации. Используй `nmap` или открытый ресурс вроде Shodan для проверки портов.
nmap -sS -p- --min-rate=5000 -Pn ваш_публичный_IP
Стандартные порты 80, 443 или 25, это норма. Тревогу должны вызывать любые другие управляющие сервисы, выставленные наружу. Открытый RDP (3389/tcp) или SSH (22/tcp) на публичный адрес, это не уязвимость, это уже открытая дверь. То же самое касается портов СУБД (3306, 5432, 1433). Их наличие в результатах сканирования говорит о провале базовой архитектуры безопасности.
Что видно изнутри
С рабочего компьютера выполни быстрое сканирование локальной сети. Цель — понять масштаб сегментации.
nmap -sn 10.0.0.0/24
Если в ответе сотни активных хостов — серверы, камеры, принтеры, — значит, сеть плоская. В такой среде компрометация одной станции через фишинг-письмо даёт доступ практически ко всем активам. Отсутствие сегментации нарушает базовый принцип ФСТЭК о разграничении сетевого трафика.
Люди и привычки: обход самой сложной защиты
Патчи не исправляют человеческое поведение. Оцени риски, не задавая прямых вопросов.
Физический доступ и данные
Пройдись по офису. Стикеры с паролями на мониторах, распечатанные реестры с персональными данными на столе, разблокированные компьютеры в отсутствие сотрудника, это не мелочи, а прямое нарушение требований 152-ФЗ о мерах защиты. Если так работают с обычными данными, то где гарантии, что иначе обстоят дела с биометрией или гостайной?
Восприимчивость к социальному инжинирингу
Проведи мысленный эксперимент. Новый сотрудник «службы безопасности» звонит в бухгалтерию и просит «проверить соединение», запрашивая логин для входа в 1С. Сколько человек выполнит просьбу, не перепроверив полномочия? Если ответ «большинство», значит, в организации отсутствует культура проверки. Это делает бессмысленными даже самые сложные криптографические средства защиты.
Политики против практики: разрыв в документах
Найди действующую «Политику информационной безопасности». Её отсутствие — уже критичный факт. Если документ есть, изучи раздел об управлении доступом.
- Длина пароля. Если минимум 8 символов — этого уже недостаточно для учётных записей с повышенными привилегиями.
- Сложность. Требование обязательных заглавных букв, цифр и спецсимволов часто приводит к шаблонам вида «Passw0rd!». Современные подходы (как в рекомендациях NIST) смещают акцент на длину парольной фразы и использование менеджеров паролей.
- Срок действия. Принудительная смена пароля каждые 60–90 дней заставляет пользователей использовать инкрементные схемы (пароль01, пароль02), что снижает реальную безопасность.
Проверь, как политика воплощена в системах. Попробуй ввести простой пароль «123456» в корпоративный портал. Если система не блокирует учётную запись после 5–10 неудачных попыток подряд, это недостаток контроля учётных записей, который могут использовать для подбора.
Техническая гигиена: обновления и учётные записи
Состояние системного софта и учёток — основа, которую часто запускают.
Хроника обновлений
На Windows-сервере проверь, когда устанавливались последние обновления. Долгий аптайм системы может быть косвенным признаком их отсутствия.
systeminfo | findstr /B /C:"Дата установки:" /C:"Время загрузки системы:"
На Linux-системах посмотри историю обновлений ядра и ключевых пакетов. Пропущенные критические обновления для Apache, nginx или Java, это известные публично уязвимости, занесённые в реестр ФСТЭК, которые эксплуатируются в первую очередь.
Контроль учётных записей
Получи список пользователей. Ищи аномалии.
net user
Наличие generic-аккаунтов (admin, test, backup) — плохая практика. Учётные записи уволенных сотрудников, оставленные «на всякий случай», это «зомби», которыми могут воспользоваться. По требованиям 152-ФЗ и ФСТЭК доступ должен предоставляться строго в силу трудовых функций и своевременно аннулироваться.
Восстановление: бэкап, который не проверяли
Спроси ответственного: «Когда в последний раз полностью восстанавливали продакшен-сервер из резервной копии и проверяли целостность данных?» Разница между регулярным созданием копий и гарантией их работоспособности — фундаментальна. Многие организации годами пишут данные на ленту или в облако, но процесс восстановления не отлажен. При атаке шифровальщиком это приводит к полной остановке бизнеса.
Что делать с находками
Цель не в создании отчёта, а в формировании личной картины рисков. Выпиши 3–5 самых острых проблем, которые ты обнаружил. Например:
- Управляющий сервис (RDP/SSH) доступен из интернета.
- Внутренняя сеть не сегментирована, все системы «видят» друг друга.
- Критичные обновления безопасности не устанавливаются месяцами.
- Парольная политика устарела и не соответствует реальным угрозам.
- Процесс восстановления из резервных копий не тестировался более года.
Обсуди эти пункты с руководителем или архитектором. Говори не на языке нарушений, а на языке бизнес-рисков: «Открытый RDP может привести к криптованной атаке. Простой ключевой системы оценивается в X рублей в час». Такая внутренняя диагностика — первый шаг от иллюзии контроля к реальному управлению безопасностью.