Подсистема контроля целостности

Подсистема контроля целостности — это компонент системы защиты информации, предназначенный для обнаружения несанкционированных изменений (модификации, удаления, подмены) данных, программного обеспечения, конфигурационных файлов и аппаратных средств. Основная задача подсистемы — обеспечение свойства целостности информации, которое заключается в гарантии того, что данные не были искажены или разрушены в результате случайных или преднамеренных действий. Подсистема контроля целостности (далее — ПКЦ) является одним из базовых механизмов защиты, применяемых в операционных системах, системах управления базами данных, средствах криптографической защиты информации (СКЗИ) и специализированных программно-аппаратных комплексах.

История развития

Концепция контроля целостности возникла в середине XX века с развитием вычислительной техники и необходимостью защиты данных от случайных ошибок. Первоначально использовались простые методы, такие как контрольные суммы, основанные на циклическом избыточном коде (CRC). Однако с ростом числа угроз, связанных с целенаправленными атаками, потребовались более надёжные механизмы.

В 1970-х годах, с появлением криптографических хеш-функций (например, MD5, SHA-1), стало возможным создавать «цифровые отпечатки» файлов, которые практически невозможно подделать без знания ключа. В 1980-х годах в операционных системах UNIX появились утилиты, такие как tripwire, которые периодически сравнивали текущие хеши файлов с эталонными. В России развитие ПКЦ связано с требованиями государственных стандартов (ГОСТ Р 34.11-94, затем ГОСТ Р 34.11-2012 «Стрибог») и нормативных документов ФСТЭК России, которые предписывают обязательное использование контроля целостности для систем, обрабатывающих персональные данные или государственную тайну.

Классификация

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

По принципу действия

• Статические ПКЦ: проверяют целостность объектов в заданные моменты времени (например, при загрузке системы, по расписанию). Результат сравнения текущего состояния с эталонным фиксируется в журнале.
• Динамические ПКЦ: работают в реальном времени, перехватывая системные вызовы (API) на запись, удаление или изменение файлов. При обнаружении попытки несанкционированной модификации блокируют операцию и уведомляют администратора.

По объекту контроля

• Контроль файловой системы: проверка целостности исполняемых файлов, библиотек, конфигурационных файлов, скриптов.
• Контроль реестра (для Windows): мониторинг изменений ключей реестра, которые могут указывать на внедрение вредоносного ПО.
• Контроль системных вызовов: отслеживание вызовов к ядру операционной системы.
• Контроль аппаратного обеспечения: проверка целостности BIOS/UEFI, загрузчика, микрокода процессора (например, с помощью технологии Trusted Platform Module — TPM).
• Контроль сетевого трафика: выявление изменений в пакетах данных (например, в системах обнаружения вторжений).

По используемому алгоритму

• На основе криптографических хеш-функций: вычисление хеша (SHA-256, ГОСТ Р 34.11-2012) и сравнение с эталонным значением.
• На основе цифровых подписей: проверка подлинности и целостности объекта с использованием открытого ключа.
• На основе контрольных сумм (CRC, Adler-32): применяются для обнаружения случайных ошибок, но не защищают от целенаправленных атак.

Устройство и принцип работы

ПКЦ обычно состоит из трёх основных компонентов:

1. База эталонных значений: хранит «слепки» (хеши, цифровые подписи, метаданные) объектов, которые считаются доверенными. База должна быть защищена от модификации (например, храниться на отдельном защищённом носителе, быть подписанной электронной подписью).
2. Модуль сбора данных: периодически или по запросу вычисляет текущие характеристики объектов (хеши, размер, время последнего изменения, атрибуты).
3. Модуль сравнения и принятия решений: сопоставляет текущие данные с эталонными. При несовпадении фиксирует событие в журнале аудита и, в зависимости от настроек, может блокировать доступ, уведомить администратора, запустить механизм восстановления.

Эталонные значения

Создание эталонных значений происходит в момент установки защищённого программного обеспечения или при первом запуске системы. Для обеспечения доверия к эталону необходимо, чтобы сам процесс создания выполнялся в контролируемой среде (например, «чистая комната»). В современных системах (например, в СКЗИ «КриптоПро CSP») эталонные значения подписываются электронной подписью производителя или удостоверяющего центра.

Применение

Подсистемы контроля целостности широко применяются в различных областях.

Защита операционных систем

В операционных системах семейства Windows (начиная с Windows Vista) используется механизм Windows Resource Protection (WRP), который предотвращает замену критических системных файлов. В Linux аналогичную функцию выполняют пакетные менеджеры (apt, yum), проверяющие целостность пакетов через контрольные суммы. Для глубокого контроля применяются специализированные средства, такие как AIDE (Advanced Intrusion Detection Environment) и Tripwire.

Средства криптографической защиты информации (СКЗИ)

В России требования к ПКЦ для СКЗИ регламентируются приказом ФСБ России. Например, СКЗИ «КриптоПро CSP» и «ViPNet CSP» реализуют контроль целостности собственных модулей и библиотек при каждой загрузке. Если хеш модуля не совпадает с эталонным, СКЗИ отказывается запускаться, что предотвращает использование подменённого криптографического ядра.

Автоматизированные системы управления (АСУ ТП)

В промышленных системах (SCADA, PLC) контроль целостности критичен для предотвращения диверсий. Например, в системах управления атомными станциями или химическими производствами любое несанкционированное изменение программного обеспечения контроллера должно быть немедленно обнаружено. Для этого применяются специализированные аппаратные модули, такие как TPM (Trusted Platform Module) и HASP (Hardware Against Software Piracy).

Системы защиты государственной тайны

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

• контроль целостности программной среды;
• контроль целостности конфигурационных файлов;
• контроль целостности средств защиты информации.

Примеры реализации

Программные средства

• Tripwire (США) — одна из первых систем контроля целостности для UNIX/Linux. Использует базу данных эталонных хешей.
• AIDE (Advanced Intrusion Detection Environment) — свободная альтернатива Tripwire, поддерживает SHA-256, SHA-512, ГОСТ Р 34.11-2012.
• Osquery (Facebook) — позволяет выполнять SQL-запросы к состоянию системы, включая контроль целостности файлов.
• Wazuh — платформа с открытым исходным кодом, включающая модуль контроля целостности файлов (FIM).

Аппаратные средства

• Trusted Platform Module (TPM) — микроконтроллер, встроенный в материнскую плату, хранящий ключи и эталонные значения. Используется для проверки целостности загрузчика (Secure Boot) и операционной системы.
• Аппаратные модули доверенной загрузки (МДЗ) — российские разработки, например, «МДЗ-С» (ЗАО «НПП «Безопасность»), которые контролируют целостность BIOS и загрузчика до старта ОС.

Критика и ограничения

Несмотря на эффективность, подсистемы контроля целостности имеют ряд недостатков:

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

Интересные факты

• В 1989 году, после атаки червя Морриса, в UNIX-системах была впервые внедрена утилита md5sum для проверки целостности загружаемых файлов.
• В России алгоритм хеширования ГОСТ Р 34.11-2012 («Стрибог») является обязательным для использования в государственных информационных системах, обрабатывающих информацию высшей степени секретности.
• Современные системы контроля целостности могут использовать машинное обучение для выявления аномалий в поведении файлов, что позволяет обнаруживать атаки, не опираясь на известные сигнатуры.

Источники

• ГОСТ Р 34.11-2012 «Информационная технология. Криптографическая защита информации. Функция хеширования».
• Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных».
• Методические документы ФСТЭК России: «Меры защиты информации в государственных информационных системах» (утв. 11.02.2014).
• Безопасность операционных систем. Учебное пособие / Под ред. В.П. Шерстюка. — М.: Горячая линия – Телеком, 2019.
• Tripwire, Inc. «Tripwire Enterprise: File Integrity Monitoring Best Practices». — 2020.