Положения об информационной безопасности: от бумажных требований к реальной защите

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

На практике термины «Политика ИБ» и «Положение об ИБ» иногда используются как синонимы, но формально это разные документы. Политика — это самый верхний уровень (5-10 страниц общих принципов), а Положения — детализация отдельных направлений (могут быть десятки документов).

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

Для чего компании нужна Политика информационной безопасности

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

  • Требования законодательства. Для компаний, работающих с ПД, наличие Политики — обязательное условие выполнения 152-ФЗ. Без нее грозят штрафы до 500 тысяч рублей для юридических лиц.
  • Отраслевые стандарты. Например, банки должны соблюдать требования Центрального банка РФ, а субъекты критической инфраструктуры — требования Федерального закона № 187-ФЗ и принятых на его основании постановлений Правительства РФ и приказов ФСТЭК России.
  • Аудиты и сертификация. Многие крупные заказчики требуют подтверждения соответствия стандартам информационной безопасности. Политика — один из документов, необходимых для получения сертификатов.

Политика ИБ обычно включает следующие разделы:

  1. Назначение и цели — для чего создан документ, какие угрозы и риски он помогает минимизировать.
  2. Сфера применения — на кого распространяется (например, на какие подразделения).
  3. Термины и определения — ключевые понятия, которые используются в тексте (например, «привилегированный пользователь», «учетная запись»).
  4. Роли и ответственность — кто отвечает за выполнение требований: служба ИБ, руководители подразделений, рядовые сотрудники.
  5. Требования к защите данных — правила работы с информацией: как хранятся данные, кому доступны, как передаются внутри и за пределы компании.
  6. Аудит и контроль соблюдения — как проверяется выполнение требований, кто проводит проверки, как часто.
  7. Меры ответственности — что грозит сотрудникам за нарушение правил: от замечания до увольнения.
  8. Актуализация документа — с какой периодичностью пересматривается Политика, кто инициирует изменения.

Как Политика ИБ детализируется через систему документов

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

Трехуровневая система документов по ИБ

Уровень 1: Политика (документ верхнего уровня)

  • Определяет общие принципы, цели и область применения.
  • Написана понятным языком для всех сотрудников — от генерального директора до рядового работника.
  • Утверждается высшим руководством компании.

Пример формулировки из Политики: «Компания обеспечивает защиту учетных записей с повышенными привилегиями от несанкционированного доступа и злоупотребления полномочиями».

Уровень 2: Положения (детализация отдельных направлений)

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

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

И другие — в зависимости от специфики бизнеса и технической инфраструктуры компании.

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

Уровень 3: Инструкции и регламенты (технические детали)

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

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

Пример формулировки из Инструкции: «Для запроса временного доступа к продакшен-серверу администратор открывает систему Indeed PAM, выбирает целевую систему из каталога, указывает срок доступа (не более 8 часов) и отправляет запрос на одобрение руководителю. После одобрения система автоматически предоставляет временные учетные данные…»

Как три уровня обеспечивают защиту

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

  1. Целостность защиты — все уровни связаны между собой: Политика определяет цели, Положения устанавливают правила, Инструкции описывают технические способы реализации.
  2. Доступность информации — каждый сотрудник получает документацию на своем уровне понимания: руководители работают с Политикой, специалисты ИБ — с Положениями, технические администраторы — с инструкциями.
  3. Конфиденциальность — четкие правила доступа на всех уровнях защищают информацию от несанкционированного раскрытия.

Несмотря на наличие документов по ИБ компании часто оказываются незащищенными

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

Рассмотрим гипотетическую ситуацию в качестве примера

В Политике написано: «Компания обеспечивает защиту учетных записей с повышенными привилегиями от несанкционированного доступа».

В Положении об управлении доступом детализировано: «Пароли привилегированных пользователей должны храниться в защищенном виде и регулярно обновляться. Действия администраторов подлежат контролю и аудиту».

А на практике:

  • Администраторы хранят пароли в Excel-файлах на рабочем столе или в текстовых документах.
  • Пароли не меняются месяцами — процесс ручной, занимает много времени, все забывают.
  • При увольнении сотрудника учетные записи блокируются с задержкой в несколько дней или вообще «зависают» на месяцы.

В результате многие компании оказываются незащищенными, не могут противостоять настоящим кибератакам. Так, по результатам свежего исследования компании Positive Technologies, 89% компаний не готовы к серьезным киберугрозам извне.  

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

Почему управление доступом — самое критичное направление

Учетные записи — ключи от всей инфраструктуры

Если злоумышленник получает доступ к привилегированной учетной записи администратора, он может:

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

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

Статистика подтверждает критичность проблемы

По информации из отчета Verizon Data Breach Investigations Report 2024, 68% всех утечек данных в мире связаны с компрометацией учетных записей — кражей паролей, злоумышленным использованием привилегий или применением украденных учетных данных.

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

Как превратить требования Положений в автоматическую защиту

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

Пример трехуровневой логики работы:

Уровень 1 — Положение формулирует требование: «компания обеспечивает защиту паролей администраторов от несанкционированного доступа».

Уровень 2 — указывается технология, которая это реализует: «для защиты паролей используется система управления привилегированным доступом».

Уровень 3 — инструкция описывает, как это работает на практике: «пошаговый порядок работы описан в Инструкции по управлению привилегированным доступом».

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

Основные ошибки при составлении Положений об ИБ

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

  • Ошибка 1: копирование шаблона без адаптации

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

  • Ошибка 2: абстрактные формулировки без привязки к технологиям

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

  • Ошибка 3: отсутствие конкретных ответственных

Написано «необходимо обеспечить», «должны контролировать», но не указано, кто именно: служба ИБ, IT-отдел, руководители подразделений. Каждый считает, что это не его зона ответственности.

  • Ошибка 4: нереалистичные требования без инструментов

«Пароли должны меняться каждые 30 дней» — правильное требование, но без системы автоматизации его физически невозможно выполнить. Администраторы тратят на ручную работу много времени, откладывают задачу или выполняют лишь формально.

  • Ошибка 5: документ не обновляется годами

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

  • Ошибка 6: «положение в вакууме»

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

Как составить полезные Положения об ИБ

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

Шаг 1: проведите аудит существующих документов

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

Шаг 2: определите приоритеты

Не все требования одинаково критичны. Сосредоточьтесь на направлениях, которые дают максимальный эффект:

  • Защита привилегированного доступа;
  • Управление жизненным циклом учетных записей;
  • Обнаружение аномалий и атак.

Шаг 3: привяжите требования к технологиям

Для каждого критичного требования определите, какие технические средства его реализуют. Укажите это прямо в тексте Положения.

Было (абстрактно): «Пароли администраторов должны храниться безопасно»

Стало (конкретно): «Пароли привилегированных учетных записей хранятся в системе управления привилегированным доступом в зашифрованном виде. Порядок работы описан в Инструкции по управлению привилегированным доступом»

Шаг 4: назначьте ответственных

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

Шаг 5: обучите сотрудников

Проведите обучение для всех, кого касаются Положения:

  • Руководителей — по процедурам одобрения доступа;
  • Администраторов — по работе с системами защиты;
  • Рядовых сотрудников — по правилам безопасности.

Шаг 6: регулярно пересматривайте документы

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

Заключение: от формальных документов к реальной защите

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

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

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

  • Требования выполняются вручную — с ошибками и задержками;
  • Или не выполняются вообще — из-за нехватки времени и ресурсов;
  • Компания остается уязвимой, несмотря на наличие документов.

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

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

Читайте еще

  • Запись эфира: Indeed ITDR — событие года в области Identity Security Записи вебинаров
    Запись эфира: Indeed ITDR — событие года в области Identity Security

    25 ноября состоялся прямой эфир, посвященный единственному на российском рынке решению для комплексной защиты инфраструктуры айдентити — Indeed ITDR 2.0....

    27.11.2025
  • Вебинар «Командные игры на поле аутентификации: как построить инфраструктуру корпоративного доверия» Записи вебинаров
    Вебинар «Командные игры на поле аутентификации: как построить инфраструктуру корпоративного доверия»

    2 декабря в 11:00 состоится вебинар «Командные игры на поле аутентификации: как построить инфраструктуру корпоративного доверия», на котором будет представлен инновационный продукт – платформа...

    25.11.2025
  • Индид представила первую публичную версию Indeed ITDR Indeed ITDR
    Индид представила первую публичную версию Indeed ITDR

    Компания «Индид», российский разработчик решений в области защиты айдентити, объявила о выпуске Indeed Identity Threat Detection and Response (ITDR) 2.0...

    17.11.2025