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

Если мы пишем политику только для того, чтобы пройти аудит или успокоить регулятора, можно просто скачать шаблон из интернета, поменять ООО «Ромашка» на название своей компании и забыть об этом. Но если задача — построить реальную защиту, то подход «ctrl+c — ctrl+v» не сработает.

Зачем компании политика безопасности

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

Политика безопасности переводит технические «хотелки» ИБ на язык бизнес-рисков. Она объясняет, почему надо тратить ресурсы именно на это, а не на что-то другое.

Вот основные задачи, которые решает этот документ.

Определяет механизмы защиты критичных данных.

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

• Конфиденциальность: база клиентов не утечет конкурентам, а зарплатная ведомость не появится в общем чате.
• Целостность: никто случайно или специально не изменит сумму платежа в 1С или код на боевом сервере.
• Доступность: сайт не зависает в «Черную пятницу», а CRM не тормозит, когда менеджеры закрывают сделки.

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

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

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

Регламентирует взаимодействие участников

Политика фиксирует зоны ответственности подразделений и порядок их совместной работы при внедрении мер защиты.

Что ищут в сети: частые вопросы о политике ИБ

Когда специалист впервые садится писать политику, он идет в Google с запросами вроде «шаблон политики безопасности» или «пример документа ISO 27001». Поиск примеров — нормальный шаг, но механическое копирование чужих регламентов не даёт рабочего результата.

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

Что должно входить в политику информационной безопасности компании?

Документ должен состоять из конкретных блоков. Не пытайтесь впихнуть в нее инструкции по настройке UserGate или ViPNet — для этого есть регламенты и гайды.

Политика занимает верхний уровень в иерархии документов ИБ: фиксирует требования и принципы. Способы реализации выносятся в отдельные «подчинённые» документы.

Рабочая политика безопасности отвечает на несколько ключевых тем:

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

Подробную структуру и состав разделов политики разберем ниже.

Как связать политику с ISO 27001 и 152-ФЗ?

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

ISO 27001 описывает логику системы управления: активы, риски, роли, контроль. Закон №152-ФЗ задаёт минимальные требования к защите персональных данных. Политика безопасности — точка, где эти требования переводятся на язык конкретной компании.

Как написать политику безопасности по ISO 27001. Стандарт задаёт перечень обязательных тем и контрольных вопросов. Политика безопасности фиксирует ответы компании на каждый из них.

Работает это так: вы берете структуру стандарта и по каждому пункту фиксируете правила своей компании. Стандарт требует: «Организация должна управлять паролями». Вы в политике пишете: «В нашей компании запрещены простые пароли, смена раз в 90 дней, история паролей — 5 версий». То есть, политика наполняет требования стандарта конкретными правилами вашей организации. Без знания текста стандарта вы не поймете, какие разделы должны быть в документе, чтобы он прошел проверку.

Связка с №152-ФЗ о персональных данных. Здесь жестче. Политика должна содержать явное обязательство компании соблюдать законодательство РФ в области защиты персональных данных. Но не переписывайте закон. Лучше сделайте ссылку на отдельное «Положение об обработке ПДн», где детально распишете согласия, цели обработки и меры защиты.

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

Кто несет ответственность за выполнение регламентов?

Самый больной вопрос. Обычно все кивают на начальника отдела ИБ.

Но в грамотной политике безопасности ответственность распределена по ролям, иначе система не работает:

• Руководство компании отвечает за выделение ресурсов (бюджет, люди) и поддержку инициатив. Если директор сам ходит под админской учеткой и паролем «123456», политику можно смело выбрасывать.
• Владельцы бизнес-процессов определяют, кому из их подчиненных реально нужен доступ к данным. Безопасник не должен знать, нужен ли бухгалтеру Ивановой доступ к базе CRM. Это знает главбух.
• ИТ-служба отвечает за техническую реализацию требований. Политика говорит «пароли должны быть сложными», ИТ-отдел настраивает групповые политики в Active Directory.
• Пользователи несут дисциплинарную, а иногда и уголовную ответственность за соблюдение правил. Подписал политику — не имеешь права передавать токен коллеге.

Четкое разделение ответственности в тексте документа защищает ИБ. Когда случится инцидент, политика покажет: ИБ-отдел разработал правила, ИТ внедрил, а вот конкретный менеджер их нарушил.

Основные принципы эффективной политики информационной безопасности

Принципы определяют, как политика должна применяться и исполняться.

Поддержка со стороны топ-менеджмента

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

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

Принцип минимальных привилегий и Zero Trust — нулевое доверие

Современная модель угроз предполагает, что злоумышленник уже может быть внутри. Поэтому в политику зашиваем два подхода:

1. Минимальные привилегии. Доступ выдается строго в объеме, необходимом для работы. Маркетологу не нужны права администратора на ноутбуке, а бухгалтеру — доступ к серверной консоли.

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

Понятный язык в политике безопасности: избегаем технического жаргона

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

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

ISO 27001 содержит список требований и на этой основе была выработана универсальная схема, которая логично группирует требования стандарта. Эти пять блоков закрывают 95% вопросов любого аудитора и понятны бизнесу.

1. Цели, задачи и область действия

Зачем нужна политика, какие бизнес-риски она закрывает, на кого и на что распространяется.

Цели. Не пишите общие фразы, берите их из реальных болей бизнеса. Откуда взять конкретику:

• Из законов: если работаете с гражданами — цель «соблюдение №152-ФЗ», если банк — «требования ЦБ РФ».
• Из контрактов: если крупные клиенты требуют ISO 27001 — цель «соответствие контрактным обязательствам».
• Из страхов бизнеса: боитесь простоя продаж — цель «обеспечение непрерывности бизнеса». Боитесь утечек — цель «защита репутации и коммерческой тайны».

Область действия. Четко очертите границы. Распространяются ли правила на удаленщиков? Касаются ли они фрилансеров и уборщиц? Входят ли в периметр личные смартфоны и ноутбуки сотрудников?

2. Роли, ответственность и порядок взаимодействия

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

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

3. Управление активами и классификация информации

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

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

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

О видах информации ограниченного доступа и ее защите читайте наш обзор.

4. Требования к защите данных, доступу и передаче

Самый объемный технический блок политики безопасности. Здесь мы описываем жизненный цикл данных от создания до уничтожения:

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

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

5. Реагирование на инциденты и аудит эффективности политики

Правила поведения в кризисной ситуации и методы проверки:

• Алгоритм при инциденте. Четкая инструкция для пользователя: что делать, если на экране появилось требование выкупа или мышка «поехала» сама собой. Главное правило: будешь наказан, если скроешь. Если признался сразу — мы успеем остановить атаку, если промолчал — подставил всю компанию.

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

6. Обучение сотрудников и Security Awareness в политике безопасности

Политика не работает, если её никто не читал. В этом разделе фиксируем обязательства компании по просвещению:

• Планы вводных инструктажей для новичков.
• Регулярные тренинги и тесты на знание правил.
• Учебные фишинговые рассылки для тренировки бдительности.

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

Остальное: принципы, KPI, техническая реализация, ошибки — это надстройка над политикой, а не разделы.

Политика и процедуры: в чем разница и почему их путают

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

Часто совершают классическую ошибку: пытаются написать один гигантский «Документ Обо Всем». Излишняя детализация — указание конкретных вендоров, версий ПО, IP-адресации — парализует работу ИТ-службы.

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

Здесь работает простое правило разделения:

• Политика — это конституция. Она отвечает на вопросы «Что?» и «Зачем?» и редко меняется.
• Процедура — регламент/инструкция — это мануал. Он отвечает на вопрос «Как именно?», меняется так часто, как меняются технологии.

Типовая иерархия документов ИБ, где не смешиваются принципы и технические детали, выглядит так:

1. Политика безопасности — верхний уровень требований.
2. Стандарты и положения — общие правила по направлениям.
3. Регламенты и процедуры — порядок действий.
4. Инструкции — конкретные шаги для исполнителей.

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

Сравнительная таблица: стратегия vs тактика

Чтобы окончательно закрыть вопрос о различиях политики и регламента ИБ, посмотрим на них в сравнении.

7 типовых ошибок, из-за которых политика безопасности не работает

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

1. Копирование чужих шаблонов без адаптации

Скачать политику «Газпрома» или Google и поменять логотип — худшая идея. Чужой регламент написан для чужих бизнес-процессов, бюджетов и рисков.
Вы получите документ-франкенштейн: в тексте требуют использовать смарт-карты для входа, а у вас в офисе даже турникета нет.

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

2. Избыточная детализация

Мы уже говорили об этом выше, но повторим: превращение политики в мануал по Windows — тупик. Не пишите «зайти в Пуск -> Панель управления». Пишите «запрещено самостоятельное изменение настроек ОС».

Как только вы спускаетесь на уровень кнопок, документ устаревает еще до момента подписания. Более того, такая детализация провоцирует теневое ИТ (Shadow IT): когда штатный способ работы слишком сложен или зарегулирован, сотрудники начинают тайком использовать личные Dropbox и WhatsApp, чтобы просто выполнить свою работу.

3. Отсутствие контроля исполнения и «мертвые» пункты

Правило без наказания — это рекомендация. Если в политике написано «запрещено передавать пароли», но половина офиса клеит стикеры на мониторы, а безопасник проходит мимо, документ теряет силу.

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

4. Юридический язык вместо человеческого

Если политика написана канцеляритом: «во исполнение приказа», «надлежит обеспечить», её никто не дочитает до конца. Текст должен быть понятен старшекласснику. Длинные сложные предложения  пугают и вызывают отторжение, а нам нужно понимание и соучастие.

5. Отсутствие регулярного пересмотра

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

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

6. Игнорирование человеческого фактора и пользовательского опыта (UX)

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

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

7. Отсутствие связи с техническим стеком

Самая частая проблема: «бумажная» безопасность живет отдельно от «железной». В Политике написано «блокировать соцсети», а в правилах межсетевого экрана, например, на UserGate, эта категория открыта.

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

Как измерить эффективность политики безопасности: KPI и контроль

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

Рассказываем, какие KPI помогут перевести безопасность из категории «расходы» в категорию «инвестиции в стабильность».

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

Количественные показатели: статистика инцидентов и время реагирования

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

Динамика инцидентов. Считать нужно не просто «сколько нас ломали», а связывать это с требованиями политики. Например, после внедрения жесткого парольного регламента количество атак подбора паролей «brute force» должно упасть до нуля. Если не упало — политика технически не внедрена.

Скорость реакции MTTD и MTTR — важнейшие показатели эффективности защиты.

• Mean Time To Detect: Как быстро мы заметили, что правило нарушено? Например, админ создал учетку без заявки.
• Mean Time To Respond: Как быстро мы это исправили? Политика должна задавать норматив SLA: «блокировка скомпрометированной станции — 15 минут». Если по факту проходит 4 часа — процесс не работает.

Норматив должен быть реальным для вашего штата ИТ. Если у вас круглосуточный SOC — ставьте 15 минут. Если один сисадмин — пишите «в течение 5 рабочих часов».

Число «мертвых душ». Простой и показательный KPI. Сколько уволенных сотрудников сохранили доступ к системе? В идеале — 0. Любая другая цифра — приговор вашему процессу управления доступом.

Качественные показатели: результаты внешних и внутренних аудитов

Не все можно посчитать в штуках. Иногда важнее оценка рисков и зрелость процессов:

• Результаты пентестов. Это главный экзамен для политики безопасности. Если этичный хакер зашел в сеть через дефолтный пароль на принтере, значит, пункт политики «смена заводских паролей» был проигнорирован.
• Внутренние проверки. Пройдитесь по офису: сколько незаблокированных экранов вы увидите? Сколько паролей под клавиатурой? Это покажет реальный уровень культуры безопасности лучше любых отчетов DLP-системы.
• Бизнес-конфликты. Неожиданный, но важный маркер. Если на политику постоянно жалуются: «невозможно работать», «все тормозит», значит, вы перегнули палку. Хорошая политика безопасности незаметна для пользователя. Если она мешает — сотрудники начнут искать обходные пути, и уровень защиты рухнет.

Как внедрить политику безопасности: технические меры

Политика выступает в роли технического задания для администраторов. Расскажем, как перевести требования политики в настройки оборудования на примере ключевого элемента защиты — NGFW (Next-Generation Firewall).

Контроль интернета.

• В Политике: «Запрещено использование ресурсов развлекательного характера и социальных сетей в рабочее время для снижения рисков фишинга».
• В железе: системный администратор открывает консоль межсетевого экрана, заходит в раздел фильтрации контента и ставит галочку «Block» напротив категорий Social Networking, Gambling и тому подобных. Без этой галочки требование политики — пожелание, которое проигнорируют.

Удаленная работа.

• В Политике: «Удаленный доступ к внутренним ресурсам компании должен осуществляться по защищенному шифрованному каналу».
• В железе: это требование означает, что админ поднимает VPN-шлюз, выдает сотрудникам сертификаты или настраивает клиентский доступ. Если вместо этого он просто «пробросил» RDP-порт наружу — политика нарушена, а инфраструктура открыта всему интернету.

Защита от атак.

• В Политике: «Компания обеспечивает мониторинг и блокировку сетевых атак».
• В железе: на шлюзе активирован модуль IPS (Intrusion Prevention System), а не просто работает пакетный фильтр.

Прежде чем нести документ на подпись директору, сядьте с ведущим инженером, откройте админку вашего шлюза или контроллера домена и проверьте: «А мы вообще можем технически выполнить то, что здесь понаписали?». Если ваш роутер не умеет фильтровать приложения (L7), то и писать в политике про блокировку торрентов бессмысленно.

Главное

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

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

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

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

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

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

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

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

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

Сертифицировано ФСТЭК для работы с персональными данными и ГИС.

Современные NGFW работают на уровне приложений L7. Вы сможете настраивать правила фильтрации в точных терминах политики, а не только по IP-адресам:

1. Задача: ограничить доступ бухгалтерии к облачным хранилищам.
2. Реализация: создание правила запрета для категории Content Filtering -> File Storage для группы пользователей AD.

Правило применяется автоматически при каждой попытке доступа.

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

• для оценки выполнения требований политики;
• для контроля KPI подразделения ИБ;
• при внутренних и внешних аудитах.

Чтобы корректно перенести требования Политики безопасности в настройки оборудования, нужны технические навыки.

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