Регламент управления конфигурацией ИСПДн

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

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

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

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

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

Разумный порядок состоит из нескольких шагов.

1. Инициатор описывает предполагаемое изменение и его цель.
2. Ответственный за безопасность оценивает, не создаёт ли изменение новых рисков.
3. При необходимости изменение проверяется на тестовом контуре или в нерабочее время.
4. Изменение применяется с фиксацией даты, автора и содержания.
5. Результат проверяется на соответствие ожидаемому.

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

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

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

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

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

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

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