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

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

В логике приказа № 66 политика ИБ — это не замена остального комплекта документов и не декоративное вступление к проекту. Это верхнеуровневая рамка, которая фиксирует, зачем вообще строится защита информации в конкретной ИС, на каких общих принципах она должна держаться и какие обязательства принимает на себя владелец системы. Именно поэтому её место — в начале проектирования, а не в финале, когда всё уже сделано и остаётся только красиво упаковать комплект.

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

Что в ней действительно должно быть

Приказ № 66 не оставляет этот вопрос полностью на усмотрение автора. В политике ИБ должны быть цели и принципы защиты информации, а также обязательства собственника или владельца ИС соответствовать требованиям по защите информации и постоянно совершенствовать систему защиты информации. Уже этого достаточно, чтобы увидеть правильный масштаб документа. Это не инструкция администратору и не перечень всех мер по пунктам. Это документ уровня намерений, принципов и управленческой ответственности.

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

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

Что в политику обычно запихивают зря

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

Это не значит, что такие темы не важны. Наоборот, они важны, но им место в других документах: в техническом задании, в структурной и логической схемах, в локальных правовых актах и организационно-распорядительных документах по применению СЗИ, в регламентах доступа, резервного копирования, журналирования и реагирования. Политика ИБ не должна их дублировать.

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

Почему этот документ нужен не только для папки

Политика ИБ важна не потому, что её “надо иметь”, а потому, что она связывает всю дальнейшую документацию в одну управленческую линию. Если техническое задание, схемы и локальные акты описывают уже конкретную реализацию, то политика показывает, на какой общей позиции стоит владелец ИС. Именно поэтому рекомендации ОАЦ отдельно показывают политику ИБ в числе документов, на которые затем опираются при аттестации.

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

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

Практический пример

Допустим, организация строит СЗИ для прикладной ИС, в которой есть доменная среда, виртуальная инфраструктура, удалённый доступ администраторов, межсетевой экран, резервное копирование и централизованное журналирование. Если подойти к политике ИБ формально, можно написать полторы страницы общих фраз про важность защиты информации, ответственность персонала и необходимость соблюдать законодательство. Такой документ будет выглядеть аккуратно, но мало что объяснит.

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

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

Как проверить, что политика не раздута и не пустая

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

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

Если на эти вопросы можно ответить уверенно, документ, скорее всего, сделан в правильном масштабе.

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