Защита информационных систем обработки персональных данных: ключевые факторы

Эти параметры определяют не формальный статус документации, а архитектуру всего контура: от модели угроз и разграничения доступа до регистрации событий и контроля эффективности средств защиты.

Ошибка на первом этапе распространяется на всю систему. Неверно определенный уровень защищенности приводит к неполному набору мер. Слабая модель угроз делает бесполезными даже сертифицированные средства защиты. Отсутствие контроля изменений превращает однажды созданную систему в устаревший набор настроек.

Защита ИСПДн — не отдельный антивирус, межсетевой экран или комплект приказов. Это связанная система процессов, программных компонентов и организационных ограничений. Ее задача — снизить вероятность несанкционированного доступа, изменения, уничтожения или распространения персональных данных до приемлемого уровня.

Нормативный фундамент защиты ИСПДн

Базовый контур регулирования в России формируют три документа:

• Федеральный закон № 152-ФЗ «О персональных данных»;
• Постановление Правительства РФ № 1119;
• Приказ ФСТЭК России от 18 февраля 2013 года № 21.

152-ФЗ задает общую правовую рамку обработки персональных данных. Он определяет обязанности оператора, требования к законности обработки, защите данных и прекращению работы с ними при достижении цели обработки или наличии других оснований.

Постановление № 1119 связывает требования безопасности с уровнем защищенности информационной системы. Приказ ФСТЭК № 21 переводит эту логику в набор организационных и технических мер. В документе предусмотрено 15 групп мер, которые оператор адаптирует под конкретную инфраструктуру и модель угроз.

Такой порядок принципиален. Приказ не означает, что для любой компании существует одинаковый перечень программ и настроек. Сначала определяется, какие данные обрабатываются, кто имеет к ним доступ, где размещены системы, какие угрозы актуальны и какие последствия повлечет инцидент. Затем выбирается базовый набор мер и выполняется его адаптация.

Соответствие требованиям начинается не с покупки средства защиты, а с определения того, что именно необходимо защищать и от какой угрозы.

Регуляторный контур не отменяет технический анализ. Один и тот же тип персональных данных может обрабатываться в разных архитектурах: на локальных серверах, в облачной инфраструктуре, в SaaS-системах, через мобильные приложения или интеграционные шины. Набор рисков будет отличаться.

В локальной инфраструктуре ключевыми объектами контроля становятся серверы, рабочие станции, сетевое оборудование и учетные записи администраторов. В облаке добавляются вопросы распределения ответственности, журналирования действий провайдера, управления API-ключами и изоляции арендаторов. В мобильном приложении критичны хранение токенов, защита канала связи, логика авторизации и поведение клиентской части при компрометации устройства.

Уровни защищенности персональных данных

Уровни защищенности персональных данных обозначаются как УЗ-1, УЗ-2, УЗ-3 и УЗ-4. Это не классы защищенности государственных информационных систем. Обозначения УЗ и К1–К3 относятся к разным классификациям и не должны смешиваться.

Уровень определяется с учетом нескольких факторов:

• категории обрабатываемых персональных данных;
• типа актуальных угроз;
• количества субъектов персональных данных;
• особенностей информационной системы;
• состава пользователей и их полномочий;
• способов обработки и передачи данных.

В нормативной логике учитывается и порог в 100 000 субъектов. Но количество пользователей само по себе не заменяет полноценную классификацию. Одинаковое число записей в двух системах не означает одинаковый уровень риска. Значение имеют состав данных, архитектура, доступность системы из внешних сетей и потенциальные сценарии атаки.

Три типа актуальных угроз

Тип угрозы связан с возможностями нарушителя и особенностями программной среды. Упрощенное представление выглядит так:

1. Угрозы, связанные с недокументированными возможностями системного программного обеспечения.

Речь идет о рисках, возникающих из-за скрытых или неизвестных оператору функций базового ПО, платформы, операционной системы или другого системного компонента.

2. Угрозы, связанные с недекларированными возможностями прикладного программного обеспечения.

В этом случае анализируется прикладной уровень: корпоративные приложения, модули, веб-интерфейсы, интеграционные компоненты и другое ПО, которое непосредственно работает с данными.

3. Угрозы, не связанные с наличием недекларированных возможностей.

Они могут реализовываться через ошибки конфигурации, компрометацию учетных данных, фишинг, эксплуатацию известных уязвимостей, инсайдерские действия или нарушение процедур доступа.

Точная оценка зависит от конкретной системы. Нельзя назначать уровень только по названию категории данных или числу сотрудников в штате. Сначала требуется описать состав активов и возможных нарушителей. Затем — определить, какие сценарии действительно применимы к инфраструктуре.

Почему классификация влияет на архитектуру

Уровень защищенности определяет не только количество документов. Он влияет на набор реализуемых механизмов:

• способ идентификации и аутентификации пользователей;
• требования к разграничению доступа;
• необходимость контроля действий привилегированных пользователей;
• правила регистрации и хранения событий безопасности;
• применение средств антивирусной защиты;
• контроль целостности программной среды;
• сегментация информационной системы;
• резервное копирование и восстановление;
• защита каналов передачи данных;
• контроль съемных носителей;
• реагирование на инциденты.

Низкий уровень защищенности не означает отсутствие риска. Он означает иной набор актуальных угроз и другой базовый состав мер. Если система меняется, исходная классификация может перестать соответствовать фактической архитектуре.

15 групп мер: защита как набор взаимосвязанных контуров

Приказ ФСТЭК № 21 описывает 15 групп организационных и технических мер. Их нельзя воспринимать как независимый список для поэтапного закрытия задач. Мера доступа без журналирования дает ограниченную доказательную базу. Антивирус без управления обновлениями быстро теряет эффективность. Резервные копии без проверки восстановления не гарантируют возврат системы в рабочее состояние.

Практический контур защиты ИСПДн обычно включает следующие направления.

Управление доступом

Доступ предоставляется не пользователю вообще, а к конкретным функциям и данным. Ролевая модель должна отделять оператора, руководителя, администратора, специалиста поддержки и владельца системы. Универсальная учетная запись администратора разрушает эту границу.

Минимальные привилегии сокращают последствия компрометации учетной записи. Администратор резервного копирования не должен автоматически получать права на изменение бизнес-данных. Сотрудник службы поддержки не должен видеть содержимое клиентской базы только потому, что система технически позволяет это сделать.

Контроль доступа должен учитывать:

• жизненный цикл учетной записи;
• изменение должности и роли сотрудника;
• увольнение;
• временные полномочия;
• доступ подрядчиков;
• повторное использование учетных данных;
• привилегированные операции;
• подключение из внешних сетей.

Идентификация и аутентификация

Пароль остается слабым фактором. Его компрометация может происходить через фишинг, вредоносное расширение браузера, повторное использование на стороннем сервисе или утечку базы учетных данных.

Для критичных операций используется многофакторная аутентификация. Дополнительный фактор не устраняет все риски, но снижает вероятность входа по одному украденному паролю. При этом необходимо защищать сам механизм второго фактора: резервные коды, телефонный номер, приложение-генератор и административные процедуры восстановления доступа.

Внутренний периметр также не следует считать доверенным по умолчанию. Компрометация рабочей станции сотрудника создает путь к системе независимо от того, находится ли сервер в локальной сети.

Регистрация событий безопасности

Без журналов невозможно надежно установить, кто получил доступ к данным, какие операции выполнил и в какой момент началось отклонение от штатного поведения.

Логи должны охватывать как минимум:

• успешные и неуспешные попытки входа;
• изменение ролей и прав;
• операции с учетными записями;
• доступ к критичным объектам;
• экспорт и массовую выгрузку данных;
• действия администраторов;
• изменения конфигурации;
• срабатывания средств защиты;
• события на сетевом периметре;
• ошибки приложений, связанные с авторизацией и доступом.

Сам факт сбора журналов недостаточен. Необходимо определить срок хранения, защитить логи от изменения и настроить анализ событий. Иначе система будет накапливать технический шум, а не формировать доказательную картину инцидента.

Защита от вредоносного кода

Антивирусная программа закрывает только часть сценариев. Она работает в пределах известных сигнатур, поведенческих правил, репутационных баз и механизмов обнаружения. Вредоносный код с нулевым днем может не распознаваться на момент атаки.

Защита должна включать обновление компонентов, контроль исполняемых файлов, ограничение запуска неизвестного ПО, анализ почтовых вложений и изоляцию потенциально опасных объектов. На серверах и рабочих станциях применяются разные политики. Слепое копирование настроек рабочего места на сервер создает операционные и технические риски.

Контроль целостности и конфигураций

Изменение системного файла, библиотеки, конфигурационного параметра или веб-компонента может быть признаком атаки. То же действие может быть штатным обновлением. Разница определяется процедурой управления изменениями и полнотой журналирования.

В инфраструктуре должны быть зафиксированы:

• эталонные версии программных компонентов;
• допустимые конфигурации;
• ответственные за изменение;
• порядок согласования;
• процедура отката;
• контроль результата после обновления.

Проприетарный код не является доказательством безопасности. Закрытость исходного кода ограничивает внешний анализ, но не устраняет уязвимости. Открытый код также не гарантирует защиту. Решающими остаются контроль разработки, скорость устранения дефектов, качество обновлений и прозрачность поставщика.

Защита каналов и шифрование

Передача персональных данных между сегментами или через внешние сети должна выполняться по защищенным каналам. Применяемый механизм зависит от архитектуры, состава данных и требований к взаимодействующим системам.

Шифрование канала не заменяет контроль конечных точек. Если учетная запись скомпрометирована, защищенный транспорт не мешает авторизованному злоумышленнику получить данные. Сквозное шифрование также не решает проблему доступа приложения к информации на сервере. Оно защищает определенный участок пути, а не весь жизненный цикл данных.

Резервное копирование и восстановление

Резервная копия относится к защите доступности и целостности. Она должна быть отделена от основной среды, защищена от несанкционированного удаления и регулярно проверяться восстановлением.

Особый риск — шифровальщики, которые получают доступ к подключенным резервным хранилищам вместе с основной системой. Поэтому резервный контур требует отдельных учетных записей, ограниченных прав и контроля удаления.

Система считается устойчивой не тогда, когда копия существует, а когда подтверждено восстановление нужного набора данных за приемлемое время. Проверка должна учитывать не только файлы, но и базы данных, ключи, настройки приложений, зависимости и порядок запуска сервисов.

Модель угроз как основа технических решений

Модель угроз связывает нормативные требования с реальной ИТ-инфраструктурой. Без нее оператор рискует получить универсальный набор защитных средств, который плохо соответствует фактическим точкам атаки.

В модели описываются:

• информационные активы;
• категории персональных данных;
• владельцы и пользователи;
• точки входа;
• внешние и внутренние интерфейсы;
• доверенные и недоверенные сегменты;
• применяемые программные компоненты;
• потенциальные нарушители;
• цели нарушителей;
• возможные последствия;
• существующие меры защиты;
• остаточные риски.

Состав активов должен быть конкретным. Недостаточно написать «база персональных данных». Нужно указать, где размещена база, какие сервисы к ней обращаются, какие учетные записи используют приложения, откуда выполняются запросы и куда уходят выгрузки.

Особое внимание требуется интеграциям. Уязвимость может находиться не в основной системе, а в модуле обмена, старом API, сервисной учетной записи или промежуточном хранилище. Внешний подрядчик с доступом к данным также становится частью периметра, даже если его сервер физически находится за пределами организации.

Типовые ошибки при моделировании

1. Описание угроз без привязки к активам.

Формулировка о возможной утечке не показывает, какой компонент должен быть атакован и каким способом.

2. Игнорирование привилегированных пользователей.

Администраторы обладают широкими правами. Их действия требуют отдельного контроля, а не общего правила для обычных сотрудников.

3. Отсутствие сценариев через подрядчиков.

Доступ внешней поддержки, облачного провайдера или разработчика должен отражаться в модели.

4. Формальное отношение к мобильным клиентам.

Мобильное приложение не является безопасным хранилищем только потому, что опубликовано в официальном магазине. Токены, локальные базы и механизмы восстановления сессии нуждаются в отдельном анализе.

5. Непроверенная актуальность модели.

Переезд в облако, внедрение нового CRM, изменение API или подключение удаленной работы меняют поверхность атаки. Старая модель после таких изменений становится архивным документом.

Модель угроз должна описывать не идеальную схему из проектной документации, а фактический маршрут данных. Включая временные файлы, сервисные учетные записи и забытые интерфейсы.

Оценка эффективности средств защиты

Наличие средства защиты не подтверждает его эффективность. Оценка должна показывать, выполняет ли механизм заявленную функцию в конкретной инфраструктуре.

Проверяются не только настройки, но и рабочие сценарии:

• блокируется ли доступ без нужной роли;
• фиксируется ли операция в журнале;
• приходит ли уведомление об отклонении;
• сохраняется ли событие после перезапуска;
• можно ли изменить или удалить лог;
• восстанавливается ли система из резервной копии;
• обнаруживается ли тестовый вредоносный объект;
• отзываются ли права после увольнения;
• прекращается ли доступ подрядчика после завершения работ;
• сохраняется ли защита при отказе отдельного компонента.

В государственных информационных системах оценка эффективности средств защиты проводится в форме обязательной аттестации. То же относится к частным ИСПДн, подключенным к ГИС. Работы выполняются организациями с лицензией ФСТЭК.

Это ограничение нельзя расширять до утверждения, что аттестация обязательна абсолютно для каждой коммерческой компании. Обязанность зависит от категории системы и характера ее взаимодействия с государственными информационными системами.

Для остальных операторов остаются иные формы контроля: внутренний аудит, проверка конфигураций, тестирование восстановления, анализ журналов, контроль уязвимостей и оценка выполнения организационных процедур. Формат проверки меняется, но задача остается прежней — подтвердить фактическую работоспособность мер.

Горизонт 2026 года: переход к более детальной модели

ФСТЭК России разработала проект обновления правил защиты персональных данных, предусматривающий вступление в силу с 1 сентября 2026 года. В проекте заявлен переход к 19 организационным и 17 техническим категориям мер. Отдельное внимание уделяется искусственному интеллекту и безопасной разработке программного обеспечения.

Точные тексты методических документов, которые должны сопровождать проект, на текущем этапе нельзя считать установленным фактом. Поэтому компаниям не следует заранее переписывать всю систему защиты по неподтвержденным трактовкам.

Практическая подготовка к изменениям может идти по направлениям, которые не зависят от финальной редакции:

• инвентаризация ИСПДн и обрабатываемых данных;
• актуализация модели угроз;
• удаление неиспользуемых учетных записей;
• разделение административных полномочий;
• внедрение многофакторной аутентификации для критичных операций;
• централизация и защита журналов;
• описание процесса управления уязвимостями;
• проверка резервного восстановления;
• фиксация изменений в инфраструктуре;
• контроль компонентов собственной разработки;
• анализ использования ИИ в обработке и классификации данных.

Искусственный интеллект добавляет несколько отдельных классов риска. Персональные данные могут передаваться внешнему API, попадать в журналы запросов, использоваться для обучения модели или сохраняться в истории диалогов. Если поставщик не раскрывает порядок хранения и удаления информации, оператор не получает полного контроля над жизненным циклом данных.

Безопасная разработка также перестает быть вспомогательной процедурой. Уязвимость в прикладном коде может обойти сетевой периметр и антивирусную защиту. Нужны контроль зависимостей, анализ исходного кода, тестирование авторизации, защита секретов и проверка логики доступа к объектам.

Как выглядит рабочая архитектура защиты

Комплексная защита ИСПДн строится слоями. Каждый слой закрывает отдельный класс отказов, но не компенсирует полное отсутствие другого.

Эти контуры должны быть связаны процессами. Выявленная уязвимость должна попадать в реестр, получать приоритет и владельца. Уволенный сотрудник должен быть удален из системы не по устной заявке, а по формализованной процедуре. Изменение серверной конфигурации должно оставлять проверяемый след.

Без процессов технические средства деградируют. Срок действия сертификата истекает. Агент защиты отключается. Роль сотрудника не меняется после перевода. Резервная копия оказывается поврежденной. Эти сценарии не требуют уязвимости нулевого дня. Достаточно отсутствия контроля.

Итог

Защита информационных систем обработки персональных данных складывается из классификации, модели угроз, технических мер и постоянного контроля. 152-ФЗ задает общий контур. Постановление № 1119 связывает систему с уровнями защищенности. Приказ ФСТЭК № 21 формирует 15 групп мер, которые необходимо адаптировать под конкретную инфраструктуру.

Надежность определяется не числом купленных продуктов и не объемом документации. Определяющими остаются четыре свойства: понятный маршрут данных, минимальные права, наблюдаемость операций и подтвержденная возможность восстановления.

Система, которую невозможно проверить, фактически не контролируется. Система, которую невозможно восстановить, не защищает доступность. Система, где неизвестно, кто имеет доступ к данным, уже содержит неустраненный риск.