Контроль целостности файлов: что требуют регуляторы и как выбрать решение

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

Разберём, кто и что требует в части контроля целостности, какими классами средств защиты эту задачу закрывают и почему внедрённое СЗИ от НСД не всегда означает выполнение требований.

Что требуют регуляторы

ФСТЭК России. Требования по контролю целостности содержатся в трёх документах: приказе от 11.04.2025 № 117 — для государственных информационных систем (применяется с 1 марта 2026 года, пришёл на смену приказу № 17), приказе от 18.02.2013 № 21 — для информационных систем персональных данных, и приказе от 25.12.2017 № 239 — для значимых объектов критической информационной инфраструктуры.

Подробнее всего состав требований расписан в приказе № 239. Группа мер VIII, «Обеспечение целостности (ОЦЛ)», включает семь мер:

• ОЦЛ.0 — регламентация правил и процедур обеспечения целостности;

• ОЦЛ.1 — контроль целостности программного обеспечения;

• ОЦЛ.2 — контроль целостности информации;

• ОЦЛ.3 — ограничения по вводу информации в информационную (автоматизированную) систему;

• ОЦЛ.4 — контроль данных, вводимых в информационную (автоматизированную) систему;

• ОЦЛ.5 — контроль ошибочных действий пользователей по вводу и (или) передаче информации и предупреждение пользователей об ошибочных действиях;

• ОЦЛ.6 — обезличивание и (или) деидентификация информации.

Обязательность зависит от категории значимости объекта. ОЦЛ.0 и ОЦЛ.1 входят в базовый набор мер для всех трёх категорий, ОЦЛ.4 и ОЦЛ.5 — для первой и второй, ОЦЛ.3 — только для первой. ОЦЛ.2 и ОЦЛ.6 в базовый набор не входят ни для одной категории: их применяют по решению субъекта критической информационной инфраструктуры, когда это следует из модели угроз.

Похожая группа ОЦЛ есть и в приказе № 21 — для систем персональных данных, со своей нумерацией и формулировками, привязанными к персональным данным.

Приказ № 117 устроен принципиально иначе, и это важно понимать. Отдельной группы мер «обеспечение целостности» в нём нет вовсе. Восемнадцать базовых мер защиты, перечисленных в пункте 63, сгруппированы не по свойствам безопасности, а по объектам защиты: конечные устройства, контейнерные среды и их оркестрация, веб-технологии, программные интерфейсы приложений, устройства интернета вещей и так далее. Контроль целостности встроен в обязательные мероприятия:

• Контроль конфигураций информационных систем (пункт 37). Мероприятия должны исключать несанкционированное изменение состава программных и программно-аппаратных средств, их настроек и конфигураций, а также «обеспечивать обнаружение фактов несанкционированных изменений и выявление причин изменений». Это фактически постановка задачи для FIM, причём более требовательная, чем прежде: мало зафиксировать факт изменения — нужно понять, откуда оно взялось.

• Управление обновлениями (пункт 39). Требуется проверка подлинности и целостности обновлений программных и программно-аппаратных средств, а бесконтрольная их установка прямо не допускается.

Конкретный состав мер приказ № 117 не приводит: согласно пункту 68 мероприятия и меры реализуются с использованием методических документов ФСТЭК России, и детализацию нужно смотреть там.

Практический вывод для тех, у кого документация писалась несколько лет назад: если контроль целостности в государственной информационной системе обоснован ссылкой на ОЦЛ.1 из приказа № 17, эту ссылку пора менять — приказа больше нет, а в № 117 группы ОЦЛ не существует. Для значимых объектов критической информационной инфраструктуры ничего не изменилось: ОЦЛ.1 из приказа № 239 действует, как и действовал.

Банк России. ГОСТ Р 57580.1—2017 описывает требования подробнее прочих и разделяет их на две группы. Первая — собственно контроль:

• наличие, учёт и контроль целостности эталонных копий программного обеспечения автоматизированных систем, средств и систем защиты информации, системного программного обеспечения;

• наличие, учёт и контроль целостности эталонных значений параметров настроек этого программного обеспечения, а также возможность восстановить настройки при нештатных ситуациях;

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

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

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

PCI DSS. В действующей версии стандарта — 4.0.1 — контроля целостности касаются два требования. Требование 10.3.4 предписывает применять контроль целостности файлов или механизмы обнаружения изменений к журналам аудита, чтобы существующие записи нельзя было изменить без формирования оповещения. Требование 11.5.2 обязывает развернуть механизм обнаружения изменений, который оповещает персонал о несанкционированных изменениях, добавлениях и удалениях критичных файлов и выполняет сопоставительный анализ таких файлов не реже одного раза в неделю.

Варианты решения задачи

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

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

Средства анализа защищённости (vulnerability scanners)

Как устроено. Сканер удалённо подключается к защищаемым ресурсам, периодически снимает хеш-суммы контролируемых файлов и сохраняет их в локальной базе.

Плюсы. Не требует установки агента на защищаемый хост.

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

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

Средства защиты от несанкционированного доступа (СЗИ от НСД, endpoint protection)

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

Плюсы. Одним решением закрывается целая группа мер — и по защите, и по управлению доступом.

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

Средства обнаружения вторжений уровня хоста и контроля целостности файлов (HIDS, File Integrity Monitoring)

Как устроено. Лёгкий агент отслеживает изменения файлов по хеш-суммам и свойствам.

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

Минусы. У открытых решений функционал достраивается другими компонентами, и настройка интеграций требует квалификации и времени, а поддержка ложится на вашу команду. У коммерческих — лицензионные платежи и закрытый код.

Когда достаточно СЗИ от НСД, а когда нужен FIM

Использование СЗИ от НСД обосновано для комплексной защиты государственных информационных систем и объектов критической информационной инфраструктуры, построенных на «стандартных» технологических стеках Microsoft и однородной унаследованной (legacy) инфраструктуре.

Современный вызов выглядит иначе: системы разворачиваются в разнородных и гибридных инфраструктурах, в том числе облачных, идёт переход к cloud-native сервисам, широко используются open source компоненты. Для таких задач «классические» СЗИ от НСД неприменимы — нужны решения контроля целостности с широким набором поддерживаемых платформ. В массовом распространении представлены два таких решения, открытое и коммерческое:

• Wazuh — открытый проект (open source), распространяется свободно; у вендора есть платная техническая поддержка: wazuh.com;

• Parus Integrity Monitoring — коммерческое решение российской компании ООО «Стайл Телеком» (бренд PARUS). Это не сборка на основе открытых проектов: вендор заявляет полностью собственный код. Включено в единый реестр российских программ для ЭВМ и баз данных, запись № 24210: parus.su/pim.

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

Поддерживаются Debian, Ubuntu, ALT Linux, Astra Linux, РЕД ОС, Red Hat, CentOS, Windows Server и Windows Desktop. Отдельно стоит отметить безагентский контроль сетевых устройств — Cisco, Check Point, Palo Alto, Fortinet, UserGate, Eltex, Qtech и других.

Что из этого можно применять для выполнения требований

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

Государственные информационные системы. Приказ № 117 выбора не оставляет: пункт 71 требует применять сертифицированные средства защиты информации, а пункт 72 задаёт класс защиты и уровень доверия в зависимости от класса защищённости системы — для 1 класса не ниже 4-го, для 2-го — 5-го, для 3-го — 6-го. Там же требование, о которое спотыкаются иностранные проекты: разработчик должен обеспечивать поддержку безопасности средства на территории России, включая выпуск обновлений, устраняющих выявленные уязвимости.

Значимые объекты критической информационной инфраструктуры. Приказ № 239 мягче. По пункту 28 средства защиты проходят оценку соответствия в одной из трёх форм: обязательная сертификация, испытания или приёмка. Обязательная сертификация нужна в случаях, прямо установленных законодательством, либо по решению самого субъекта КИИ; в остальных случаях достаточно испытаний или приёмки, которые субъект проводит самостоятельно или с привлечением организации с лицензией ФСТЭК. То есть открытое решение здесь в принципе применимо — но его придётся провести через испытания и оформить результат, и эту работу нужно закладывать в проект.

Информационные системы персональных данных. Приказ № 21 требует средств, прошедших оценку соответствия; обязательная сертификация для всех уровней защищённости не предписана. Здесь свободы больше всего.

И отдельно — Указ Президента от 01.05.2022 № 250. С 1 января 2025 года органам и организациям из его перечня — а в него входят государственные корпорации, системообразующие организации и субъекты критической информационной инфраструктуры — запрещено использовать средства защиты информации, происходящие из недружественных государств или произведённые подконтрольными им организациями. Для Wazuh, который развивает американская компания, это означает, что в таких организациях он как средство защиты не применяется, независимо от технических достоинств и от того, что исходный код открыт.

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

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

Я внедрил СЗИ от НСД. Этого достаточно?

Не всегда. В современных реалиях свойство целостности (integrity) дополняется неотказуемостью (non-repudiation), и это уже нашло отражение в российском регулировании: достаточно вспомнить оперативно-розыскное мероприятие «получение компьютерной информации» в Федеральном законе «Об оперативно-розыскной деятельности» или обновление Положения Банка России от 17.04.2019 № 683-П.

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

• авторство артефакта (authority);

• его актуальность (up to date);

• факт выполнения конкретной операции в рамках процесса.

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

В следующих статьях мы опишем принципиальные подходы к обеспечению неотказуемости и контроля целостности pipeline.

Что мы делаем

«Ореол Секьюрити» предлагает комплексный подход к внедрению FIM-решений:

• консультации по выбору решения под вашу инфраструктуру и требования регулятора;

• пилотное тестирование на вашей территории — как на вашем оборудовании, так и на нашем;

• все стадии проектных работ по внедрению, в том числе в соответствии с ГОСТ;

• сопровождение внедрённого решения.

Внедрение средств защиты информации — проектирование, поставка, настройка и ввод в эксплуатацию. От 500 000 ₽. Подробнее об услуге

Соответствие ГОСТ Р 57580 — оценка соответствия, устранение несоответствий, подготовка к внешней оценке. От 600 000 ₽. Подробнее об услуге