«Внешне — просто строка букв и цифр, контрольная сумма. На деле — сигнал о взломе всей файловой системы или штатной операции обновления. Умение отличать одно от другого и есть ключ к реальной, а не формальной проверке целостности.»
Проверка целостности данных
Целостность — не просто пункт в ФСТЭК. Это состояние, в котором данные находятся в соответствии с исходными, авторизованными и утверждёнными значениями. Любое отклонение, будь то случайная ошибка бита или целенаправленная подмена файла, делает информацию ненадёжной. В контексте российских требований 152-ФЗ и регуляторики ФСТЭК обеспечение целостности трансформируется из технической задачи в организационно-техническую.
Суть проверки целостности: больше, чем цифровой отпечаток
Проверка целостности — это процесс верификации, что данные не подвергались несанкционированному изменению, уничтожению или подмене. Цель — обнаруживать изменения, а в идеале — и предотвращать их.
Типичная ошибка — сводить проверку к банальному сравнению хешей скачанного файла. В инфраструктуре организации всё сложнее: изменения вносятся легитимно (администраторами, обновлениями), но должны быть авторизованы. Проверка целостности здесь работает как система сигнализации: она должна сработать на любое отклонение от утверждённого «эталонного» состояния. Вопрос в том, как этот эталон определяется и кто имеет право его менять.
.
Контрольные суммы: базовый, но уязвимый фундамент
Алгоритм контрольной суммы берёт блок данных и вычисляет для него относительно короткое значение, предназначенное для обнаружения случайных ошибок (повреждений при передаче). Это не криптографический метод.
Принцип работы прост: данные проходят через алгоритм (например, CRC32), результат фиксируется. При повторной проверке вычисляется новая сумма. Несовпадение указывает на изменение.
Однако для защиты от злонамеренных изменений контрольные суммы бесполезны. Злоумышленник, имеющий доступ к файлу, может модифицировать его и пересчитать корректную сумму для изменённой версии. Поэтому в требованиях информационной безопасности они используются лишь для внутренних проверок непротиворечивости, но не для защиты от НСД.
Криптографические хеш-функции: инструмент для обнаружения
В отличие от контрольных сумм, криптографические хеш-функции (SHA-256, SHA-512, ГОСТ Р 34.11-2012 «Стрибог») спроектированы так, чтобы по их выходу (хешу) было практически невозможно восстановить входные данные или найти два разных набора данных с одинаковым хешем (стойкость к коллизиям).
Именно хеш-функции — техническая основа для проверки целостности в соответствии с ФСТЭК. Эталонный хеш критически важного файла (например, исполняемого модуля, конфигурации межсетевого экрана) должен храниться отдельно от самого файла и в защищённом от изменений виде.
| Алгоритм | Статус в российской практике | Типичное применение |
|---|---|---|
| MD5, SHA-1 | Запрещены для использования в системах защиты информации (СЗИ) из-за уязвимостей. Допустимы лишь для непротиворечивости. | Не рекомендуется. |
| SHA-256/384/512 | Рекомендованы, широко применяются в импортном ПО и современных стандартах. | Проверка целостности образов ПО, документов, элементов PKI. |
| ГОСТ Р 34.11-2012 («Стрибог») 256/512 бит | Обязателен к использованию в СЗИ, сертифицированных ФСТЭК и ФСБ России. | Криптографическая защита, ЭП, проверка целостности в государственных ИС и КИИ. |
Проверка выглядит так: система мониторинга целостности (HIDS) периодически вычисляет хеш файла, сравнивает с эталонной базой, хранящейся на доверенном сервере. Любое несоответствие — событие для службы ИБ.
Система контроля версий (СКВ): целостность через историю
СКВ (Git, Subversion) — это не только для разработчиков. В администрировании защищённых систем она становится инструментом обеспечения целостности конфигураций.
Любое изменение конфигурационного файла сервера (nginx, iptables, БД) фиксируется в репозитории. Появляется:
- Неизменяемый журнал: кто, когда и что изменил.
- Возможность моментального отката к известной рабочей версии.
- Автоматическая проверка: сценарий может сравнивать текущую конфигурацию с версией в репозитории и алертить о расхождениях.
Это реализует принцип «двух ключей»: администратор вносит изменение, но фиксация в репозитории (commit) требует ревью или дополнительной авторизации. Сама история репозитория защищена криптографически.
Резервное копирование: целостность во времени
Резервная копия — это снимок данных в определённый момент, чья целостность критически важна. Бесполезно иметь бэкап, который сам повреждён или содержит уже внедрённое вредоносное ПО.
Требования к резервным копиям в контексте целостности:
| Требование | Реализация для целостности |
|---|---|
| Верификация после создания | Обязательное вычисление хешей (лучше ГОСТ) для резервных наборов данных и сравнение с хешами исходных данных. |
| Защита от модификации | Хранение бэкапов на Write-Once Read-Many (WORM) носителях или в объектных хранилищах с политикой неизменяемости. |
| Регулярное тестирование восстановления | Восстановление не только данных, но и проверка их хешей после восстановления. |
| Изолированное хранение | Физическое и сетьевое разделение основного контура и хранилища резервных копий для защиты от атак типа ransomware. |
Авторизация и журналирование: организационная рамка
Технические меры бесполезны без чёткого разграничения прав. Принцип минимальных привилегий означает, что право изменять критичный файл должно быть у минимального круга лиц.
Журналирование (аудит) всех действий с важными данными — вторая сторона медали. Если хеш файла изменился, журнал должен однозначно показать: изменение произошло в 14:30 учётной записью «admin_sys», вошедшей с рабочей станции Х. Без этого факт нарушения целостности есть, а виновник — нет.
В современных ОС это реализуется через подсистемы аудита (auditd в Linux, Audit Policies в Windows), которые настраиваются в соответствии с руководящими документами ФСТЭК.
Практика: не только проверить, но и отреагировать
Типичный сценарий в организации, соответствующей 152-ФЗ:
- На критичном сервере развёрнут агент системы контроля целостности (например, на базе OSSEC, Wazuh или коммерческого аналога).
- Агенту задана политика: каждые 5 минут вычислять хеш (ГОСТ 34.11) для ключевых файлов (/etc/passwd, бинарников в /usr/bin/, конфигов служб).
- Эталонная база хешей хранится на выделенном, строго контролируемом сервере управления.
- При любом изменении агент отправляет алерт в SIEM-систему.
- В SIEM заведены правила корреляции: если изменение совпало по времени с авторизованным событием «установка обновления» из тикета, событие понижается до информационного. Если нет — генерируется инцидент для группы реагирования.
Таким образом, проверка целостности перестаёт быть разовой акцией и становится непрерывным процессом мониторинга, встроенным в цикл управления информационной безопасностью.