Если в вашем штате нет безопасника, это не значит, что защищать данные некому. Просто роль эта ложится на IT-отдел — то есть на людей, у которых и без того горят тикеты. Знакомая картина: руководство просит «провести аудит безопасности», а что именно делать, никто не объясняет. Продавцы тут же подсунут «комплексное решение», которое «закрывает всё» — от SIEM до DLP.
Хватит бегать за волшебной кнопкой. Аудит — это не покупка и не однократный акт «прошли и забыли». Это повторяемый процесс из понятных шагов, большая часть которых делается руками вашей же команды. Ниже — рабочий порядок действий и чек-лист, который можно взять и применить на этой неделе.
Что такое аудит защищённости данных в масштабе малого IT-отдела
Аудит — это ответ на три вопроса: что мы защищаем, от кого и какой ценой. Не на бумаге, а в виде таблицы, где у каждого актива есть владелец, критичность и текущее состояние защиты. Всё остальное — производные.
Полезно держать в голове нормативную рамку, даже если вы не обязаны ей строго следовать: 152-ФЗ для персональных данных, приказы ФСТЭК №17 (для ГИС) и №21 (для ПДн) задают структуру требований. Даже если вы не подпадаете под них напрямую, они работают как готовый каркас, по которому удобно раскладывать меры. Сам текст документов ищется на сайте ФСТЭК.
Шаг 0. Инвентаризация: без неё всё бессмысленно
Самый скучный и самый важный шаг. Пока вы не знаете, что у вас есть, любой «аудит» превращается в гадание.
- Составьте реестр серверов, БД, облачных сервисов, SaaS-подписок, репозиториев, CI/CD-раннеров.
- Отметьте, где лежат персональные данные, ключи, токены, коммерческая информация.
- Назначьте владельца для каждого актива: не «IT-отдел», а конкретный человек.
- Зафиксируйте, что выводится из эксплуатации — про EOL-системы обычно забывают именно их.
Формат — обычная таблица в том же инструменте, где ведёте задачи. Главное, чтобы её кто-то обновлял, а не она жила один день.
Шаг 1. Доступы и аутентификация
Большинство реальных инцидентов в малом и среднем бизнесе — это не экзотический 0-day, а скомпрометированная или бывшая учётка сотрудника, слабый пароль и ключ, забытый в открытом репозитории.
Что проверить
- Учётные записи уволенных и подрядчиков отключены, а не «на всякий случай оставлены».
- Во всех внешних сервисах включена двухфакторная аутентификация (2FA), у админов — приложение или аппаратный ключ, а не SMS.
- Работает принцип наименьших привилегий: рядовому разработчику не нужен прямой доступ к продовой БД.
- Сервисные учётки отделены от человеческих, у каждой — свой пароль и владелец.
- Секреты не лежат в git, в CI-логах и в конфигах на общем диске. Для них есть менеджер секретов.
Отдельный пункт — регулярная ревизия. Раз в квартал выгружаете список активных учёток и проходите по нему глазами. Это дешевле любой системы класса IAM и иногда эффективнее.
Шаг 2. Данные: где хранятся, как шифруются и куда утекают
- Диски на ноутбуках и серверах — с полнодисковым шифрованием (BitLocker, LUKS).
- Трафик наружу и внутри периметра — только TLS, устаревшие протоколы выключены.
- Копии продовых данных для тестов — обезличенные, если это персональные данные. Иначе это просто вторая копия возможной утечки.
- Вы знаете, куда уходят данные: проверьте интеграции, вебхуки, аналитику и «временные» выгрузки в личные облака сотрудников.
Шифрование не спасает от всего, но закрывает целый класс сценариев: украденный ноутбук, слитый дамп, перехваченный трафик.
Шаг 3. Бэкапы: проверяйте восстановление, а не факт наличия
Наличие бэкапа — не защита. Защита — это восстановленный из него сервис за известное время.
- Правило 3-2-1: три копии, два носителя, одна — вне основной площадки.
- Минимум одна копия неизменяемая (immutable) или на офлайн-носителе — это прямой ответ на шифровальщиков.
- Учётка для бэкапов не имеет доступа к проду, а её собственные ключи лежат отдельно.
- Раз в квартал устраиваете учебное восстановление и записываете время. Если не пробовали — считайте, что бэкапа нет.
Шаг 4. Обновления и зависимости
Массовые компромиссы идут по известным уязвимостям, патч для которых вышел месяцы, а иногда годы назад. Классический пример — CVE-2021-44228 в библиотеке Log4j, эхо которого в проектах слышно до сих пор.
- Ведите инвентарь версий ОС, СУБД, веб-серверов и фреймворков.
- Сверяйтесь с БДУ ФСТЭК и каталогом известных эксплуатируемых уязвимостей CISA.
- Настройте SBOM и сканер зависимостей в CI — это дешевле, чем искать заражённый пакет вручную.
- Определите SLA на патчи: критичное — дни, остальное — по плану. Без приоритизации вы просто не успеете.
Полезные источники: БДУ ФСТЭК, Known Exploited Vulnerabilities от CISA, OWASP Top 10 — последний пригодится для веб-приложений, которые вы пишете сами.
Шаг 5. Видимость: логи, которые кто-то читает
Логи, которые никто не смотрит, — это просто занятое место. Задача не «собирать всё», а собирать то, по чему можно заметить проблему.
- Сводите события в одно место: аутентификация, изменения прав, доступ к секретам, изменения в CI/CD, вход в облако.
- Определите срок хранения по требованиям и по здравому смыслу: обычно от 3 до 12 месяцев.
- Настройте алерты на аномалии: всплеск неудачных входов, вход из новой страны, создание админ-учётки, отключение защиты.
- Следите, чтобы логи нельзя было тихо подтереть: копии уходят туда, куда у атакующего нет доступа с той же учётки.
Шаг 6. Люди и процессы
Технические меры легко перевешивает один сотрудник, перешедший по ссылке из письма. Поэтому процессы — такая же часть аудита, как и настройки.
- Онбординг и офбординг по чек-листу: доступы выдаются и снимаются по одной процедуре.
- Заявка на повышение прав — с обоснованием и сроком, а не «дай на всякий случай».
- Журнал изменений в инфраструктуре: кто, что и когда поменял.
- Минимум раз в год — учебная рассылка и разбор фишинга без наказаний за клик.
Как расставить приоритеты, если вы один
Риск считайте просто: вероятность умножить на ущерб. Сначала закрывайте то, что и вероятно, и больно: доступы, 2FA, бэкапы, патчи по интернет-периметру. Мелкие технические долги копите в бэклог, но с датами.
Не пытайтесь внедрить SIEM ради галочки. Полноценная система мониторинга без человека, который разбирает алерты, быстро превращается в генератор уведомлений, которые все игнорируют.
Сводный чек-лист
- Есть реестр активов, и у каждого — владелец.
- Все внешние сервисы закрыты 2FA, у админов — сильнее остальных.
- Учётки уволенных и подрядчиков отключены, ревизия раз в квартал.
- Секретов нет в git и логах, есть менеджер секретов.
- Диски зашифрованы, наружу — только TLS.
- Бэкапы 3-2-1, одна копия неизменяемая, восстановление протестировано.
- Патчи по интернет-периметру закрываются в дни, а не месяцы.
- Зависимости сканируются в CI, есть SBOM.
- Логи сведены в одно место, настроены алерты по критичным событиям.
- Есть процедуры онбординга и офбординга, заявка на доступ.
Вместо вывода
Аудит защищённости данных — это не продукт, который покупают, и не отчёт на 200 страниц. Это набор привычек: знать, что у вас есть, знать, кому это доступно, и уметь восстановиться. Начните с одного раздела — например, с ревизии учёток и бэкапов — и повторяйте цикл раз в квартал. Каждая итерация будет быстрее предыдущей, а разрыв между «как мы думали, что защищены» и реальностью — заметно меньше.
