Введение. Зачем автоматизация вместо ручного аудита

Ручная проверка Linux-сервера на соответствие требованиям безопасности — это десятки конфигурационных файлов, сотни параметров ядра, права доступа, настройки SSH, политики паролей и логирования. Пройтись по всему этому руками для одного сервера — уже задача на несколько часов. А если у нас серверов штук 100? Тут проверять придётся ну месяц, может, и больше. А ещё не забываем, что эта ручная проверка держится на человеческом факторе: администратор может забыть пункт чек-листа, по-разному интерпретировать формулировку требования или просто устать к концу списка. В результате один и тот же сервер, проверенный двумя разными специалистами, может получить два разных вердикта.

Автоматизация решает эти проблемы/задачи.

Инструменты проверяют систему за пару минут вместо пары часов. Одна и та же проверка даёт одинаковый результат, и вообще можно получить отчёт от сканеров (лог/html/json), который можно приложить к внутреннему аудиту или предъявить регулятору — вместо того чтобы задним числом восстанавливать, что именно проверялось. В этой статье мы посмотрим, какие бывают compliance-требования и инструменты для харденинга сервера/Linux.

Харденинг (от англ. hardening — укрепление, закалка) — это процесс усиления безопасности ИТ-систем путём уменьшения поверхности атаки и настройки конфигураций по стандартам безопасности.

Какие бывают compliance-требования

Слово compliance (в русскоязычной практике его обычно так и оставляют — «комплаенс», реже переводят как «соответствие требованиям») в контексте ИБ означает, что настройка системы должна соответствовать конкретному внешнему стандарту, а не просто «быть безопасной» в общем смысле. То есть у нас есть комплаенс, где мы делаем проверку по формальному списку критериев, который задаёт кто-то извне, и этого «извне» зовут регулятор/заказчик.

Стандарты бывают разные и зависят от компании/продукта/страны и иных требований. Рассмотрим одни из распространённых стандартов, которые чаще всего встречаются и настраиваются под Linux-серверы:

CIS Benchmarks (Center for Internet Security)

Пожалуй, самый распространённый в мире набор рекомендаций по безопасной настройке ОС, СУБД, контейнеров и облачных сервисов. Большинство сканеров, которые мы посмотрим, в первую очередь ориентированы именно на CIS.

ISO/IEC 27001

Международный стандарт систем менеджмента информационной безопасности. В отличие от CIS, это не технический чек-лист по параметрам ОС, а более такой широкий процессный стандарт с управлением рисками, политиками, ролями и т. д. Техническая настройка серверов — только часть требований, но именно для неё используются те же CIS-подобные проверки как техническое основание.

PCI DSS (Payment Card Industry Data Security Standard)

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

Требования ФСТЭК России

Для российской инфраструктуры (госсистемы, ГИС, объекты КИИ, персональные данные) действуют приказы ФСТЭК. Формально многие технические требования ФСТЭК пересекаются с CIS Benchmarks на 80–90% — те же принципы: минимизация привилегий, отключение неиспользуемых сервисов, контроль изменений.

ФСТЭК и open source

В процессе изучения нашёл такой частый вопрос: можно ли использовать open source инструменты для официальной аттестации по ФСТЭК? И тут конкретного ответа я не нашёл, т. к. один говорит «да», другой — «нет», и, если конкретизировать уж, то — не напрямую. Open source сканеры и утилиты харденинга не имеют сертификата ФСТЭК России и не могут быть формально вписаны в аттестат соответствия информационной системы как сертифицированное средство контроля защищённости. Для официальной аттестации нужны сертифицированные средства защиты информации из реестра ФСТЭК.

Это не делает open source бесполезным в этом контексте — совсем наоборот. На практике эти инструменты закрывают другую, не менее важную задачу, а именно предварительный аудит, постоянный контроль и саму подготовку к аттестации. Некоторые отечественные дистрибутивы, к примеру Astra Linux, учитывают это на уровне поставки: в них встроен openscap/openscap-scanner (или вот), а вендоры и сообщество (как пример) публикуют репозитории и Ansible-роли, уже привязанные к требованиям.

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

Мой топ по инструментам для автоматизации compliance

1. Lynis

Lynis в бесплатной версии ориентирован на стандарты ISO 27001, PCI DSS, HIPAA и CIS Benchmarks. Запускается как shell-скрипт, кстати проверяет он не только Linux, но и macOS. Есть ещё enterprise-версия, там добавляется GUI и плагины, которые полностью покрывают. Это, кстати, минус Lynis (в плане бесплатности), т. к. хоть он и проверяет, но только частично, для идеала вообще следует получить enterprise. Из плюсов: достаточно много профилей под Ubuntu.

Установка на Ubuntu

Установка через пакетный менеджер:

sudo apt update && sudo apt install lynis

И затем уже можно делать запуск аудита: sudo lynis audit system

Лог пишется в /var/log/lynis.log, отчёт — в /var/log/lynis-report.dat. Сама команда делает по умолчанию проверки по всем четырём стандартам (CIS, HIPAA, ISO27001 и PCI DSS), если хочется ограничить аудит, к примеру, только CIS, придётся создать свой профиль с compliance-standards=cis и запустить sudo lynis audit system --profile /путь/к/custom.prf

Документация Lynis.

2. OpenSCAP

OpenSCAP (она же открытая реализация стандартов SCAP — Security Content Automation Protocol — от NIST), сканер, который благодаря набору правил (SCAP-контент, например scap-security-guide от ComplianceAsCode) покрывает профили: PCI DSS, DISA STIG, CIS Benchmarks, HIPAA, NIST SP 800-171/CUI, OSPP (Common Criteria), ACSC Essential Eight, CJIS, C2S, ANSSI.

Установка на Ubuntu

Установка через пакетный менеджер:

# Ubuntu 24.04 и новее
sudo apt install openscap-scanner

# Более старые версии Ubuntu
sudo apt install libopenscap8

После установки можем проверить его наличие и как пример проверим под CIS:

# 1. Скачать и распаковать. Последнюю версию смотрите сами в https://github.com/ComplianceAsCode/content/releases/

wget https://github.com/ComplianceAsCode/content/releases/download/v0.1.82/scap-security-guide-0.1.82.zip
unzip scap-security-guide-0.1.82.zip
cd scap-security-guide-0.1.82

# 2. Запуск CIS Level 1 Server
sudo oscap xccdf eval --profile cis_level1_server --results-arf results-arf.xml --report report.html ssg-ubuntu2404-ds.xml

# Открыть отчёт
xdg-open report.html

Из плюсов: детальный html-отчёт, и лучше, чем даже Lynis в некоторых моментах, но порог входа я бы посчитал сложнее, чем в Lynis, из-за нехватки профилей. Из-за чего я использую их в связке и не забываю про топ-3.

Документация OpenSCAP

Да, и ещё такой момент, что у них разные подходы: у Lynis — динамическое сканирование (оппортунистическое), а у OpenSCAP — статическое сканирование (по чек-листу).

3. systemd-analyze

Это встроенная утилита из состава самого systemd, поэтому доустанавливать ничего не нужно, она уже есть на любом современном дистрибутиве. В отличие от Lynis и OpenSCAP, которые смотрят на систему в целом, systemd-analyze security проверяет конкретно то, как изолированы юниты (сервисы), запущенные через systemd — nginx, docker, postgres и любые другие.

Запуск без аргументов покажет сводную таблицу по всем загруженным долгоживущим сервисам:

systemd-analyze security

Каждому сервису присваивается exposure level от 0.0 (максимально защищён, жёсткий sandboxing) до 10.0 (практически никакой изоляции). Для разбора конкретного сервиса указываем его юнит:

systemd-analyze security docker.service

Тут уже выводится подробная построчная таблица: какие настройки безопасности (PrivateTmp, ProtectSystem, NoNewPrivileges, RestrictNamespaces и десятки других директив unit-файла) включены, какие нет, и сколько «очков» экспозиции добавляет каждая отсутствующая настройка.

Инструмент смотрит только на unit-файл systemd, AppArmor/SELinux и другие службы он не видит то как они реализованы. Поэтому высокий exposure level — не значит уязвим, значит просто не прописан харденинг.

Практический смысл в связке с остальными инструментами: Lynis и OpenSCAP проверяют ОС и файловую систему в целом, а systemd-analyze закрывает узкое, но важное место — изоляцию конкретных сервисов друг от друга и от ядра.

4. DevSec Hardening Framework

DevSec Hardening Framework — готовые роли и профили харденинга под Ansible, Chef, Puppet. Фишка в том чтобы не писать плейбуки харденинга с нуля под каждый проект, а взять готовый набор ролей от сообщества, который закрывает базовую защиту ОС и популярных сервисов.

В качестве примера — ansible-collection-hardening, закрывает харденинг ОС, SSH, nginx и MySQL одной командой ansible-galaxy collection install devsec.hardening и парой ролей (os_hardening, ssh_hardening) в плейбуке, а рядом есть проекты с суффиксом -baseline (linux-baseline, ssh-baseline и т.д.) уже не для настройки, а для проверки через InSpec, что всё применилось и держится.

Плюс — тут community-driven и регулярные обновления, минус — роли заточены под общие практики (близко к CIS), а не под конкретный регуляторный стандарт, так что под PCI DSS или ФСТЭК привязку придётся делать самому.

Ну и, конечно, самому как вариант написать 1 раз условный скрипт под стандарт и гонять его по всем серверам ради проверки всё ещё остаётся. Но для этого, чтобы не заморачиваться, есть Cinc!

5. Cinc

Это форк проекта Chef InSpec (после покупки он стал платным, и сообщество его форкнуло) под именем Cinc Auditor (Cinc Is Not Chef), по факту тот же InSpec, но с полностью свободной сборкой и без лицензионных ограничений. Фишка проекта в том, что он compliance-as-code, т. е. инструмент проверки, только аудит, без исправлений. Он подсветит, что на сервере небезопасные права на файл /etc/shadow, но сам их не исправит. Готовые профили брать не обязательно писать самому — та же DevSec-экосистема выше публикует готовые *-baseline профили под InSpec/Cinc (linux-baseline, ssh-baseline и другие), их можно сразу запускать без написания собственных controls. Как и исправление, можно это реализовать уже ручками либо другими инструментами.

Установка Cinc Auditor:

curl -L https://omnitruck.cinc.sh/install.sh | sudo bash -s -- -P cinc-auditor

Пример теста (control) — проверка прав и владельца на /etc/shadow:

describe file('/etc/shadow') do
  it { should_not be_executable }
  it { should be_owned_by 'root' }
end

Такой control сохраняется в файл profile/controls/example.rb внутри профиля и запускается командой:

cinc-auditor exec ./profile

И, кстати, мне понравился режим «сканер-клиент»: можно запускать проверку удалённого сервера по SSH прямо со своей машины, ничего не устанавливая на целевой сервер.

cinc-auditor exec ./profile -t ssh://user@remote-host

Заключение

Ручной аудит на соответствие compliance-требованиям работает, только пока серверов один-два. С ростом инфраструктуры единственный рабочий вариант — автоматизация: сканеры дают повторяемый результат и готовый отчёт, который можно предъявить хоть внутреннему безопаснику, хоть регулятору.

© 2026 ООО «МТ ФИНАНС»