Нормативный источник: пункт 7.15 Приложения 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ).
Краткое описание требования
Информационная система может быть защищена от несанкционированного доступа, но это не исключает вывода информации через разрешённые рабочие инструменты. Пользователь может отправить документ не тому адресату, скопировать его на носитель либо передать через приложение, для которого доступ в сеть разрешён. Межсетевой экран при этом видит допустимое соединение, но не обязательно понимает, какие сведения передаются.
Пункт 7.15 посвящён именно этому разрыву: необходимо выявлять и предотвращать утечки информации из ИС с использованием системы обнаружения утечек. На практике подобные решения обычно называют DLP — Data Loss Prevention. Однако название продукта не является доказательством выполнения требования: требуется показать, какие сведения он распознаёт, какие каналы контролирует и что происходит при нарушении заданной политики.
Важно различать обнаружение и предотвращение. Обнаружение означает фиксацию попытки и формирование сообщения; предотвращение — применение заранее установленной меры, например блокировки операции. Если средство только формирует отчёты после завершённой передачи, следует отдельно оценить, чем обеспечивается предотвращение на предусмотренных каналах.
Оригинальная формулировка требования
Приложение 3 к Положению о порядке технической и криптографической защиты информации, раздел «7. Иные требования», пункт 7.15: «обеспечение обнаружения и предотвращения утечек информации из информационной системы, использование системы обнаружения утечек информации из информационной системы».
Строка определяет требуемый результат и прямо предусматривает применение системы обнаружения утечек. Марка продукта, набор модулей и форматы отчёта пунктом не установлены. Для конкретной ИС подбирают техническую реализацию, способную одновременно обнаруживать и предотвращать предусмотренные сценарии вывода информации.
Обязательность требования
По таблице приложения 3 требование обязательно для класса 3-дсп. Для классов 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин, 3-спец, 3-бг и 3-юл оно рекомендуемое. Обозначения «+» и «+/–» имеют именно такие значения в примечаниях к таблице.
Для рекомендуемого класса решение о реализации следует обосновывать условиями конкретной ИС. При этом если мера включена в утверждённое техническое задание и проектные решения, её необходимо проверять как предусмотренную для данной системы, не выдавая рекомендацию самой таблицы за общую обязанность.
Что именно проверяет проверяющий
Наличие установленного DLP-сервера или лицензии недостаточно. Проверка должна установить, что контроль охватывает фактически используемые пути вывода защищаемой информации и что система применяет предусмотренные действия.
- Объект защиты: определён перечень категорий защищаемых сведений, документы и системы-источники, владельцы информации, допустимые операции.
- Граница контроля: установлены рабочие станции, терминальные серверы, почтовые шлюзы и другие точки, на которых информация может покидать ИС; учтены реальные исключения.
- Правила обнаружения: установлено, по каким признакам решение отличает защищаемые сведения от обычных; есть результаты настройки ложных срабатываний.
- Реакция: для значимых каналов предусмотрены и проверены запрет, ограничение либо иной механизм предотвращения; определены случаи, требующие решения уполномоченного лица.
- Подтверждение: по тестовой попытке передачи можно получить событие, установить источник, объект и канал передачи и показать результат применения правила.
Такой подход не означает, что для любого класса ИС необходимо внедрить одинаковый набор DLP-модулей. Предмет проверки — фактическая реализация установленной меры в конкретной архитектуре.
Варианты реализации
Контроль на конечных узлах. Агент на рабочем месте или терминальном сервере может контролировать операции с буфером обмена, съёмными носителями, печатью и передачей файлов — в пределах поддерживаемых функций и настроек. Этот вариант особенно важен, когда данные выводятся без прохождения через почтовый шлюз. Следует проверить совместимость с применяемыми ОС, VDI и режимами работы.
Контроль на почтовом и сетевом направлении. Почтовый шлюз либо иной компонент анализирует передаваемые сообщения и вложения. Такой контроль не заменяет endpoint-механизмы: локальное копирование файла на носитель через него не проходит. Шифрование трафика и используемые приложения также могут ограничивать видимость.
Комбинированная архитектура. Разные компоненты закрывают разные каналы, а события сводятся в единый контур анализа. Этот вариант полезен для ИС, где пользователи работают одновременно с почтой, файловыми ресурсами, веб-сервисами и локальными носителями. Он требует устранения дублирования правил и согласованного порядка обработки инцидентов.
Для любой архитектуры необходимо учитывать права самих операторов DLP: система может получать доступ к содержимому защищаемых документов, а значит, её администрирование, хранение событий и доступ аналитиков тоже требуют разграничения.
Как построить проверяемую политику
Начинать целесообразно не с десятков абстрактных шаблонов, а с конкретного сценария. Например, в ИС обрабатываются служебные документы с установленным признаком ограничения распространения. Владелец информации определяет, что передача таких документов на внешние адреса почты не разрешена.
Далее последовательно задаются: категория документа → признаки обнаружения → контролируемый канал → разрешённые адресаты → действие при нарушении → ответственный за разбор. На испытании используется специально подготовленный тестовый документ, не содержащий реальных ограниченных сведений, но имеющий необходимый признак для распознавания.
Проверка включает два самостоятельных результата. Сначала выполняется разрешённая операция, которая должна пройти без необоснованной блокировки. Затем выполняется заранее согласованная попытка отправки тестового документа на контролируемый тестовый адрес вне разрешённого списка: система должна выдать предусмотренное правило и зафиксировать применённое действие. Таким образом одновременно проверяются полнота контроля и влияние на штатный процесс.
Если политика работает только в режиме наблюдения, отчёт об обнаруженной попытке подтверждает работу обнаружения, но сам по себе не подтверждает предотвращение. Для блокирующего режима нужен отдельный результат, показывающий, что передача не завершилась вследствие действия выбранного средства.
Что закрепить в ТЗ, ЛПА и ОРД
В ТЗ и проектных решениях указывают классы защищаемой информации, контролируемые каналы, область установки компонентов, правила обработки событий и ожидаемые функции предотвращения. В эксплуатационных инструкциях фиксируют настройку политики, действия при отказе агента или шлюза и порядок безопасной проверки. В ЛПА и ОРД определяют владельцев информации, полномочия операторов, согласование исключений и порядок реагирования на установленные нарушения.
Организационный запрет сам по себе не заменяет техническую систему, прямо названную в пункте 7.15 для случаев его обязательного применения. И наоборот, наличие DLP не отменяет необходимости определить допустимые действия с информацией: без этой основы техническая политика будет произвольной.
Типичные ошибки при реализации
- Установлен продукт, но не определены сведения для защиты. Система формирует общие события, не связанные с содержанием ИС.
- Включено только наблюдение. Отчёт фиксирует уже завершившуюся передачу, но механизм предотвращения не показан.
- Охвачен один канал. Например, проверена почта, но предусмотренные в ИС носители, печать или другие разрешённые пользователям способы вывода не учтены.
- Нет проверки разрешённой операции. Чрезмерно широкое правило блокирует штатную работу, из-за чего сотрудники добиваются постоянных исключений.
- Исключения бесконтрольны. Наиболее значимые документы передаются по исключённым каналам без владельца и срока пересмотра.
- Нет связи события с действием. В журнале видно совпадение сигнатуры, но невозможно доказать, была ли передача прекращена.
Вывод
Содержательная реализация пункта 7.15 строится от защищаемой информации к конкретным каналам передачи и проверенным действиям системы. Доказательством служит не общая политика «предотвращать утечки», а воспроизводимый результат: тестовый документ обнаруживается, событие позволяет определить обстоятельства, а предусмотренный механизм предотвращения действительно срабатывает.
Нормативная основа
- Приказ ОАЦ от 20.02.2020 № 66, действующая редакция — приложение 3 к ПТКЗИ, пункт 7.15 и таблица обязательности.
- Microsoft: проверка политик DLP в режиме моделирования — пример технического подхода к настройке и испытанию, не нормативное требование Республики Беларусь.
