Стандарты различаются тем, насколько подробно указывают, что делать. ISO/IEC 27002 формулирует результат и оставляет средства на усмотрение. PCI DSS предписывает меры, но публикует цель каждой. Конфигурационный базис стоит на другом краю: он называет файл, параметр и значение. Руководство по технической реализации безопасности для RHEL 9 содержит 446 правил, и у каждого есть команда, которая либо возвращает ожидаемую строку, либо даёт замечание.

В этой точности весь смысл. И в ней же устройство без связи упирается в стену — причём интереснее, чем «базис слишком строг».

Базис требует ровно такой схемы

Два правила стоит читать вместе. Первое требует аутентификации по сертификату на смарт-карте, а проверяется, в обычной для базиса манере, поиском ключа в конфигурации:

Чтобы убедиться, что в RHEL 9 включены смарт-карты в демоне системных служб безопасности (SSSD), выполните команду: $ sudo grep -ir pam_cert_auth /etc/sssd/sssd.conf /etc/sssd/conf.d/ … Если «pam_cert_auth» не установлен в «True», строка закомментирована или отсутствует — это замечание.

Конфигурационный базис для операционной системы общего назначения требует входа по сертификату на носителе. Спорить не с чем: это и есть механизм.

Второе правило, идущее следом, требует проверки статуса сертификата — и называет протокол:

Убедитесь, что операционная система использует протокол оперативной проверки статуса сертификата (OCSP) и корректное значение дайджеста, с помощью команды: $ sudo grep -sir certificate_verification /etc/sssd/sssd.conf /etc/sssd/conf.d/

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

Смежное правило требует проверять сертификаты «построением пути сертификации (включающего сведения о статусе) до доверенного якоря». Построение пути локально; наружу тянется именно проверка статуса.

Офлайновый ответ — список отзыва, рассылаемый по расписанию, и короткий срок действия; и требование отзыва в PCI DSS, и ISO/IEC 27002 такой ответ принимают. Но это не то, что говорит данное правило.

Оговорка, которую никто не цитирует

У каждого из этих правил о личности есть одна и та же пометка — причём в тексте проверки, а не в самом требовании:

Если системный администратор продемонстрирует использование одобренного альтернативного метода многофакторной аутентификации, требование неприменимо.

Это местный аналог customized approach из PCI и целевых формулировок ISO, и его легко пропустить, потому что он выглядит примечанием для проверяющего, а не правом для того, кто внедряет. Работает здесь слово «одобренного»: одобренного уполномоченным лицом для конкретной системы, а не разработчиком базиса и не поставщиком. Так что офлайновый довод доступен — но это довод, который нужно выстроить и утвердить, а не галочка.

Три стандарта — три разных правила блокировки

То же расхождение видно в мелочи. PCI DSS требует блокировки не более чем после 10 неудачных попыток, минимум на 30 минут или до подтверждения личности. Этот базис строже и категоричнее:

Убедитесь, что RHEL 9 настроен блокировать учётную запись до снятия блокировки администратором после трёх неудачных попыток входа, командой: $ sudo grep -w unlock_time /etc/security/faillock.conf — unlock_time = 0

Три попытки и никакого автоматического снятия. Собственный счётчик попыток аппаратного токена ведёт себя ближе к этому, чем к варианту PCI: блокируется и остаётся заблокированным, пока кто-то не разблокирует. Полезное напоминание, что «защита от перебора» — не одно требование с одним числом: три документа дают три, и действует то, которое держит в руках проверяющий.

Чего базис не покрывает

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

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

Одно правило стоит ровно на границе, и честности ради его стоит назвать. Базис требует блокировать сессию при извлечении смарт-карты — а текст проверки начинается с оговорки, что требование неприменимо, если графический интерфейс не установлен, потому что осматриваемая настройка принадлежит рабочему столу. Даже там, где базис тянется к этому поведению, он поручает его операционной системе, а не тому, что выполняло аутентификацию. Тот же ответ мы получали в каждом стандарте, прочитанном про эти устройства.

Честные границы

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

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

Источники