Разбираем структуру полноценного ИТ-аудита (от инфраструктуры до сайта) с примерами реальных находок
Большинство компаний приходят к ИТ-аудиту после инцидента. Где-то произошла утечка данных. Где-то встала работа из-за ransomware. Иногда все начинается с проверки регулятора, во время которой выясняется, что документы живут отдельно от реальных процессов.
До этого момента ИТ-инфраструктура оценивается очень просто: сотрудники работают, серверы не падают, интернет есть – значит все нормально.
На практике именно это ощущение стабильности и становится главным источником риска.
Современный ИТ-аудит – это не обход серверной и не поиск устаревших компьютеров. Это попытка понять, насколько компания вообще контролирует собственную ИТ-среду: инфраструктуру, доступы, данные, процессы и действия сотрудников.
В этой статье разбираем структуру ИТ-аудита так, как мы выстроили его в РТИ: от конкретных направлений проверки до типичных находок.
Почему формальный аудит почти бесполезен
На рынке огромное количество аудитов, которые сводятся к сбору галочек: есть ли антивирус, резервные копии, политика безопасности, документы по персональным данным.
На бумаге – все хорошо. Но как только начинается сравнение документов с реальной инфраструктурой, появляются расхождения.
Типичный пример: перечень персональных данных, которые компания фактически обрабатывает, отличается от того, что указано во внутренних документах и в уведомлении Роскомнадзора. Формально бумаги есть.
Фактически процессы уже давно изменились: HR начал собирать новые данные кандидатов, маркетинг подключил новые формы на сайте, а документы остались прежними.
Это очень типичная ситуация. Бизнес развивается быстрее, чем обновляются регламенты.
Именно поэтому полноценный аудит начинается не с документов и не с техники, а с понимания того, как компания реально работает.
Из чего состоит ИТ-аудит
Хороший аудит почти никогда не ограничивается одной зоной. Он охватывает несколько направлений, потому что большинство рисков возникают не внутри одного блока, а на стыке нескольких.
Структура полного аудита:
- ИТ-инфраструктура – сеть, серверы, Active Directory, резервное копирование, хранилища данных
- Информационная безопасность – доступы, MFA, антивирусная защита, логирование, политики паролей
- Персональные данные (ЛНА) – локально-нормативные акты, согласия, реестр процессов обработки
- Сайт компании – формы сбора данных, cookies, политика обработки ПД, согласия посетителей
- Организационные процессы – ответственные лица, регламенты, сценарии реагирования на инциденты
Разберем каждый блок подробнее.
Блок 1. ИТ-инфраструктура
Что смотрим
- Инвентаризация сети: соответствует ли реальный состав устройств тому, что числится в учете ИТ-службы
- Серверные системы: температурные режимы, нагрузка, журналы ошибок
- Правила маршрутизации
- Наличие неучтенных устройств в сети (shadow IT)
- Доменная инфраструктура (Active Directory, политики паролей, ограничения на неверный ввод)
- Обновления безопасности на клиентских машинах (patch management)
- VPN и сегментация сети (VLAN)
Хороший пример из практики
На одном из наших аудитов в РТИ картина была такая: инфраструктура выглядит стабильно, состав сети соответствует инвентаризации, неучтенных устройств нет, серверы работают в норме, доменная инфраструктура настроена корректно, на всех машинах лицензионный антивирус с актуальными обновлениями безопасности. Жалоб на производительность сети нет.
На этом многие аудиты заканчиваются. Но именно здесь начинается разница между формальной проверкой и реальной.
Что находят за внешней стабильностью
Упрощенный механизм авторизации на СХД. В инфраструктуре используется система хранения данных Synology. Для удобства доступа включена функция упрощенного входа, которую сам вендор не рекомендует для корпоративных решений: существуют эксплойты, позволяющие получить доступ к корневым службам СХД. Эти эксплойты несут угрозу даже если у СХД нет открытых портов в интернет. Рекомендация – отключить.
Персональные данные в открытом доступе. При анализе виртуальной машины-файлообменника обнаружены персональные данные, хранящиеся без какого-либо шифрования. Доступ к ним не ограничен внутри сети.
Блок 2. Резервное копирование
Почти каждая компания говорит: «У нас есть бэкапы».
Вопрос не в самом наличии резервных копий, а в том, насколько они защищены и пригодны для восстановления.
Что проверяем
- Наличие резервных копий
- Шифрование резервных копий
- Кто имеет доступ к резервной инфраструктуре
- Изоляция резервной инфраструктуры от основной среды
- Тестирование восстановления – когда последний раз проверяли, что из бэкапа вообще можно поднять систему
- Попадают ли персональные данные в резервные копии
Типичная находка
Резервирование систем настроено, но не использует шифрование. Поскольку в резервируемые данные попадают персональные данные, их хранение также требует шифрования по 152-ФЗ.
Рекомендация: переход на системы резервирования с поддержкой шифрования (например, Veeam), которые также обеспечивают защиту от ransomware-атак на данные компании.
На практике это означает простую вещь: если злоумышленник получает доступ к резервной инфраструктуре, он получает доступ сразу ко всей информации компании, в том числе к персональным данным, без каких-либо дополнительных усилий.
Блок 3. Многофакторная аутентификация (MFA)
Одна из проблем, которая регулярно встречается в аудитах, – отсутствие MFA. Особенно часто это встречается там, где уже есть доменная инфраструктура, политики паролей, лицензионный антивирус. То есть компания уже потратила ресурсы на безопасность, но не внедрила один из самых эффективных механизмов защиты учетных записей.
Причина обычно одинаковая: MFA воспринимается как неудобство для сотрудников.
MFA – это связка учетной записи пользователя с приложением на телефоне или другим фактором аутентификации. Получить доступ к системе без подтверждения со стороны пользователя становится значительно сложнее. Решение повышает устойчивость как к внешним атакам, так и к внутренним утечкам.
Если внутренние утечки рассматриваются как дополнительная угроза – стоит рассматривать DLP-системы (Data Loss Prevention) для мониторинга и предотвращения несанкционированного копирования данных с ведением подробных логов о действиях сотрудников.
Блок 4. Персональные данные: локально-нормативные акты
Многие компании воспринимают обработку персональных данных как «бумажную» задачу юристов. На практике именно здесь обнаруживается огромное количество проблем, причем не из-за злого умысла, а потому что бизнес-процессы меняются быстрее, чем документация.
Реестр процессов обработки персональных данных
Один из самых важных документов, который в большинстве компаний отсутствует или существует в устаревшем виде.
Реестр – это полная карта того, что происходит с персональными данными внутри организации. Для каждого бизнес-процесса он фиксирует: категории субъектов, цели обработки, конкретный перечень данных, правовые основания, способы обработки (автоматизированный / неавтоматизированный / смешанный), места хранения, сроки хранения, порядок уничтожения и передачу третьим лицам.
На практике реестр часто показывает несоответствия, которые иначе не видны. Например:
- Кадровые процессы (прием на работу, оформление отпусков, командировок, увольнение) фиксируются в 1С:ЗУП и хранятся в личных делах. Доступ – только у главного бухгалтера и генерального директора. Это типичная нормальная ситуация.
- Водители. У них принципиально другой перечень обрабатываемых данных по сравнению с офисными сотрудниками: добавляются результаты медицинского освидетельствования, реквизиты водительского удостоверения, данные психиатрического осмотра (ст. 220, 328 ТК РФ, Приказ Минздрава от 20.05.2022 № 342н). Это специальные категории персональных данных по ч. 2 ст. 10 152-ФЗ. Оформить единое согласие для водителей и офисных работников – нарушение.
- Зарплатный проект. При передаче данных работников в банк компания фактически передает персональные данные третьему лицу. Согласие на такую передачу должно быть получено отдельно. При смене банка – согласие переоформляется. Альтернатива: согласие на распространение ПД неопределенному кругу кредитных организаций в целях перечисления заработной платы – но оно должно быть составлено строго по ст. 10.1 152-ФЗ и Приказу РКН № 18 от 24.02.2021.
- Заявки с сайта. Данные посетителей (телефон, ФИО, e-mail) собираются через форму, обрабатываются автоматизированно, хранятся до момента исполнения договора или отзыва согласия. Если эта цепочка нигде не описана – компания обрабатывает данные без правового основания.
- Передача данных водителей заказчикам-контрагентам. При оформлении транспортной накладной данные водителя (ФИО, паспортные реквизиты, водительское удостоверение) передаются заказчику по email. На каждого нового контрагента нужно согласие водителя на передачу его данных, либо согласие на распространение без указания конкретного получателя, но с четкой целью.
Без актуального реестра аудит занимает в разы больше времени, а риски остаются невидимыми.
Что проверяется по 152-ФЗ
Содержание обрабатываемых ПД Объем обрабатываемых данных должен соответствовать заявленным целям. Типичная находка: в Положении о ПД, в уведомлении Роскомнадзора и в реальных процессах – три разных перечня данных. «Берем на всякий случай» – нарушение ч. 5 ст. 5 152-ФЗ.
Согласия субъектов
Частые проблемы: нет отдельного согласия для соискателей; нет согласия на передачу ПД банку в рамках зарплатного проекта (ч. 3 ст. 6 152-ФЗ); форма согласия не содержит ИНН и адрес оператора, конкретный перечень действий с данными, способ отзыва согласия, понятный срок действия; единое согласие для всех работников – при том что перечень ПД у водителей объективно отличается.
Назначение ответственного за обработку ПД
По п. 1 ч. 1 ст. 18.1 152-ФЗ оператор-юрлицо обязан назначить ответственного. Обязательные документы: Приказ о назначении, Должностная инструкция, допсоглашение к трудовому договору. Ответственный должен иметь административный ресурс и достаточную квалификацию – понимать обязательные требования и иметь возможность давать обязательные к исполнению указания другим сотрудникам.
Положение об обработке персональных данных
Типичные нарушения: отсутствие описания целей обработки ПД, нет категорий субъектов и перечней ПД в разбивке по целям, не указаны правовые основания обработки, не описан порядок уничтожения данных, не указаны лица, имеющие доступ к ПД.
Ознакомление сотрудников
Документ, подтверждающий ознакомление работников с ЛНА по ПД, практически никогда не предоставляется. По п. 6 ч. 1 ст. 18.1 152-ФЗ и п. 8 ст. 86 ТК РФ это обязанность оператора. Рекомендация: лист или журнал ознакомления с подписями под Положением о ПД и всеми сопутствующими документами.
Оценка вреда субъектам ПД
По п. 5 ч. 1 ст. 18.1 152-ФЗ оператор обязан оценивать вред, который может быть причинен субъектам в случае нарушения закона, и соотносить этот вред с принимаемыми мерами защиты. Документ отсутствует практически у всех.
Уведомление Роскомнадзора
Уведомление должно содержать актуальный перечень целей обработки, категорий субъектов и перечней ПД. Типичная находка: уведомление подано, но цели в нем неполные – например, не включена цель «Подбор персонала» или «Ведение воинского учета», хотя фактически эти процессы ведутся.
Блок 5. Сайт компании
Сайт – полноценная часть ИТ-инфраструктуры и зона обработки персональных данных. Исключать его из аудита – ошибка. Особенно часто проблемы здесь возникают после доработок, когда маркетинг, подрядчики и ИТ работают независимо друг от друга.
Что проверяем
Политика обработки персональных данных на сайте
Если на сайте есть форма обратной связи, заявка, калькулятор – компания собирает персональные данные. Политика обработки ПД должна быть доступна на каждой странице, где происходит сбор данных (стандартная практика – «подвал сайта»). В политике: наименование оператора, цели обработки, категории субъектов, перечень ПД, способы и сроки, правовые основания, порядок уничтожения.
Файлы cookies
Cookies считаются персональными данными. Если сайт их использует – необходимо уведомление для всех новых посетителей (cookie banner) с кнопкой «Согласен» и ссылкой на политику. Описание всех типов cookies должно быть включено в политику обработки ПД или вынесено в отдельный документ.
Согласие на обработку ПД под формами
Под каждой формой сбора данных должен быть чек-бокс с согласием. Критически важно: чек-бокс должен быть пустым по умолчанию. Посетитель сам принимает решение. Предустановленная галочка – нарушение.
Сервисы веб-аналитики
Если используются сервисы веб-аналитики (Яндекс.Метрика и аналоги) – необходимо проверить соответствие требованиям локализации данных (ч. 5 ст. 18 152-ФЗ).
Типичная находка
На сайте есть чек-бокс для согласия обработки персональных данных, но без привязки к документу согласия и без ссылки на политику. Политика обработки персональных данных на сайте отсутствует вовсе. Cookies используются, но никак не описаны и не задокументированы.
Блок 6. Организационные процессы
Главная проблема большинства компаний – не в технике. А в процессах.
Что выявляется
- Сотрудники используют общие учетные записи – при инциденте невозможно установить, кто именно и что сделал
- Доступы не отключаются после увольнения – одна из самых частых и критичных проблем
- Резервные копии никто не тестировал на восстановление – бэкап есть, но поднять из него систему не пробовали
- Ответственность за ИБ размыта между отделами, нет конкретного владельца
Что делать с инцидент-менеджментом
Рекомендуется совместно с ИТ-службой разработать алгоритмы реагирования минимум на три сценария:
- Кибератака / ransomware
- Утечка информации (внешняя или внутренняя)
- Выход из строя ключевых элементов инфраструктуры (сервер, основной роутер)
Наличие задокументированных playbook’ов позволяет решать такие ситуации с минимальными задержками для бизнес-процессов. Без них даже простой отказ маршрутизатора превращается в хаос – непонятно, кто звонит первым, кто принимает решения и что делать с данными в процессе восстановления.
Что в итоге дает полноценный аудит
Задача хорошего ИТ-аудита – не найти максимальное количество нарушений. Его задача – показать реальное состояние среды: где уже есть критичные риски, что работает хорошо, какие проблемы нужно решать срочно, а какие можно устранять постепенно.
Именно после полноценного аудита компания впервые начинает видеть собственную ИТ-среду как систему, а не как набор серверов, лицензий и отдельных сервисов.
Еще один важный результат – разрыв между документацией и реальностью становится видимым. Большинство компаний уверены, что у них «все оформлено»: реестр процессов, согласия, политики. Но когда начинается сравнение документов с тем, что происходит в 1С, на сервере и на сайте – оказывается, что реальность давно ушла вперед.
Хороший аудит синхронизирует эти два мира. И делает ИТ-среду управляемой.
