Безопасное применение SLES 15 STIG с помощью OpenSCAP

Используйте поддерживаемый SUSE профиль DISA STIG для SLES 15, просканируйте сервер с помощью OpenSCAP и устраняйте неполадки только после проверки базового состояния на тестовой системе. Например, представьте себе вымышленного администратора по имени Алекс, подготавливающего сервер SLES 15 для работы с регулируемым сервисом: Алекс использует описанный ниже рабочий процесс для выявления проблем, тестирования изменений и сбора доказательств, но не рассматривает успешное автоматическое сканирование как подтверждение соответствия требованиям.

Приведенные команды соответствуют текущим рекомендациям SUSE STIG для SLES 15. Содержимое профиля может изменяться при обновлении пакетов и выпуске бенчмарков DISA, поэтому перед использованием этой процедуры проверьте применимые требования к версии и конкретной системе. Изображения терминала иллюстрируют команды и не показывают реальные результаты сканирования.

1. Подтвердите целевой показатель и текущий эталонный уровень.

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

Перед выбором контента проверьте установленную версию:

cat /etc/os-release
hostnamectl

Затем получите соответствующий контрольный список SLES 15 STIG и версию бенчмарка на официальной странице загрузок DISA STIG . Сопоставьте контрольный список с семейством систем и следуйте инструкциям по оценке вашей организации. SUSE документирует поддержку профиля SCAP «DISA STIG for SUSE Linux Enterprise 15», но это само по себе не определяет, какой выпуск требуется вашему органу сертификации, и не подтверждает работоспособность хоста.

2. Установите и проверьте содержимое SCAP-файла.

На зарегистрированной системе SLES с доступом к соответствующим репозиториям установите утилиты командной строки OpenSCAP и содержимое руководства по безопасности SCAP:

sudo zypper install openscap-utils scap-security-guide

Указанные ниже названия пакетов и расположение потока данных SLES 15 задокументированы в руководстве SUSE по усилению безопасности OpenSCAP и процедуре SUSE STIG . Репозитории пакетов и версии профилей могут различаться в зависимости от пакета обновлений и уровня обновления. Перечислите установленные потоки данных и проверьте файл-кандидат, а не предполагайте имя файла или профиль:

ls -1 /usr/share/xml/scap/ssg/content/ssg-*-ds.xml
oscap info /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Убедитесь, что поток данных SLES 15 присутствует и что список профилей включает в себя stig. Если файл или профиль отсутствует, остановитесь и устраните несоответствие пакета или репозитория; не используйте в качестве эталона бенчмарк другой операционной системы.

3. Определите исходный уровень, затем протестируйте предложенные меры по устранению проблемы.

Перед созданием отчетов создайте защищенную папку для хранения доказательств. Сначала выполните сканирование, не изменяя системные настройки:

sudo install -d -m 0700 /root/stig-review
sudo oscap xccdf eval \
  --profile stig \
  --results /root/stig-review/baseline.xml \
  --report /root/stig-review/baseline.html \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Откройте HTML-отчет и просмотрите каждый результат, особенно ошибки, сбои и правила, которые не удалось проверить. Сохраните XML-файл и отчет как конфиденциальные данные конфигурации. Они могут раскрыть информацию о хосте и состоянии безопасности, поэтому храните или передавайте их только по утвержденным каналам.

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

sudo oscap xccdf eval --remediate \
  --profile stig \
  --results /root/stig-review/remediation.xml \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Полученный результат может включать результаты тестирования до и после исправления. Правило, помеченное как , fixedуказывает на то, что автоматическое исправление было применено и правило прошло проверку; errorозначает, что исправление для этого правила не удалось. Ни один из этих статусов не заменяет оперативное тестирование или проверку базового требования.

4. Повторное сканирование, устранение ошибок и сохранение подтверждающих данных.

После анализа поведения тестов запустите отдельное сканирование с новыми путями вывода. Оценка только результатов сканирования поможет отличить текущее состояние от состояния, в котором выполнялось исправление:

sudo oscap xccdf eval \
  --profile stig \
  --results /root/stig-review/final.xml \
  --report /root/stig-review/final.html \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Не следует ожидать, что каждое правило можно исправить автоматически. Проверяйте ошибки, сверяя их с полным текстом проверки и исправления правила в той же версии контрольного списка DISA, которая выбрана для системы. Некоторые правила требуют обдуманного решения владельца сервиса, конфигурации, специфичной для конкретного объекта, или подтверждения вручную. Если правило неприменимо или не может быть выполнено, задокументируйте обоснование и компенсирующие меры контроля в рамках формального процесса обработки исключений организации; изменение или адаптация профиля сами по себе не гарантируют выполнение требования.

Для ознакомления с контрольным списком, в документации SUSE описан экспорт файла XCCDF, который можно импортировать в DISA STIG Viewer. Сгенерируйте его с использованием поддерживаемой опции, а затем импортируйте в Viewer в соответствии с текущими инструкциями для пользователей:

sudo oscap xccdf eval \
  --profile stig \
  --stig-viewer /root/stig-review/results_stig.xml \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

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

sudo ls -l /root/stig-review

Прежде чем объявить задачу выполненной, убедитесь, что окончательный отчет отражает результаты сканирования, проведенного после внесения изменений, что для каждого оставшегося обнаружения указан ответственный и принятый меры, а также что необходимые службы сервера по-прежнему работают. Соответствие STIG — это оцениваемое состояние, привязанное к конкретному эталону и области применения системы; OpenSCAP поддерживает эту оценку, но не предоставляет аккредитацию и не гарантирует выполнение всех требований к сайту.

Источники

• SUSE: Усиление безопасности SUSE Linux Enterprise с помощью STIG
• SUSE: Повышение безопасности SLES с помощью OpenSCAP
• DISA: Загрузки STIG