|

Пункт 2.3 Приказа ОАЦ №66: как защитить резервные копии, настройки и события безопасности от несанкционированного доступа

ОтVK

Смысл требования

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

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

Формулировка требования

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

Обязательность применения

По таблице приложения 3 требование пункта 2.3 является обязательным для всех классов типовых ИС: 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл, 3-дсп. Рекомендательного режима применения для данного требования не предусмотрено.

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

Что именно следует защищать

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

  • Резервные копии. К ним относятся копии данных, виртуальных машин, баз данных, файловых хранилищ, конфигураций и иных объектов, позволяющих восстановить ИС или её часть.
  • Параметры настройки телекоммуникационного оборудования. Это конфигурации маршрутизаторов, коммутаторов, межсетевых экранов, VPN-шлюзов, точек доступа и иных сетевых компонентов.
  • Параметры настройки системного программного обеспечения. Сюда входят настройки ОС, служб, политик безопасности, системных сервисов, доменной инфраструктуры, расписаний, системных параметров и иных базовых компонентов.
  • Параметры настройки средств защиты информации. Это правила межсетевого экранирования, политики антивирусной защиты, настройки СЗИ от НСД, СКЗИ, IDS/IPS, средств журналирования, контроля целостности и иных защитных механизмов.
  • События безопасности. Это журналы и записи, используемые для контроля, расследования и подтверждения действий пользователей, администраторов, системных компонентов и средств защиты.

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

Что проверяет аудитор или ОАЦ

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

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

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

Варианты реализации

Организационный вариант.

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

Технический вариант.

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

Комбинированный вариант.

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

Что целесообразно закрепить в ЛПА и ОРД

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

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

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

Возможность технической реализации и инструменты

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

  • Active Directory, LDAP, группы доступа и файловые ACL. Применимы для разграничения доступа к каталогам с резервными копиями, журналами, конфигурационными файлами и служебными ресурсами. Важно использовать не персональные исключения, а управляемые группы и ролевую модель.
  • Средства резервного копирования: Veeam, Bacula, Bareos, Acronis, Nakivo и аналогичные решения. Позволяют разграничивать роли операторов, администраторов и пользователей, защищать репозитории, ограничивать удаление копий и фиксировать операции с заданиями и архивами.
  • Immutable-хранилища и WORM-подход. Используются для защиты резервных копий и архивов журналов от удаления или изменения в течение заданного периода. Особенно полезны при защите от действий злоумышленника с административными привилегиями.
  • Шифрование резервных копий и архивов. Применимо там, где резервные копии могут храниться вне основного контура, передаваться на внешние площадки или содержать чувствительную информацию. Требует отдельного порядка управления ключами.
  • RANCID, Oxidized, GitLab/Gitea или иные системы хранения конфигураций. Подходят для версионирования и контроля доступа к конфигурациям сетевого оборудования и части системных настроек. Позволяют видеть изменения и ограничивать круг лиц, имеющих доступ к конфигурационным данным.
  • Ansible, Ansible Vault, HashiCorp Vault и иные средства управления конфигурациями и секретами. Уместны там, где настройки и чувствительные параметры должны храниться централизованно, с разграничением доступа и контролем изменения.
  • Средства централизованного журналирования и SIEM. Используются для ограничения доступа к событиям безопасности, разграничения ролей просмотра и анализа, а также защиты журналов от изменения или удаления пользователями, действия которых должны контролироваться.
  • PAM-системы. Целесообразны в более зрелой инфраструктуре для контроля привилегированного доступа к хранилищам резервных копий, системам журналирования, СЗИ и административным интерфейсам оборудования.

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

Типичные ошибки при реализации

  • резервные копии хранятся в сетевой папке, доступной широкому кругу администраторов или пользователей;
  • администратор, чьи действия должны контролироваться, имеет возможность удалить или изменить журналы событий безопасности;
  • конфигурации межсетевых экранов, коммутаторов, VPN-шлюзов и СЗИ хранятся в обычных файловых папках без разграничения доступа;
  • резервные копии шифруются, но ключи хранятся рядом с архивами или доступны тем же лицам;
  • в системе резервного копирования всем администраторам выданы максимальные права без разделения ролей;
  • доступ к событиям безопасности не разграничен между просмотром, анализом, администрированием и удалением;
  • права доступа к резервным копиям и конфигурациям не пересматриваются после увольнения, смены роли или изменения состава администраторов;
  • технические ограничения есть, но в ЛПА и ОРД порядок доступа не описан.

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

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

Похожие записи