CIS benchmarks and baselines

Что такое CIS Benchmark на самом деле

Вам не нужно с нуля изобретать ответ на вопрос «как выглядит укреплённый хост Ubuntu» — это месяцы исследований на каждую платформу, и вы что-нибудь упустите. CIS Benchmark — это уже готовый ответ: разработанное по консенсусу, предписывающее руководство по конфигурации для конкретной платформы — дистрибутива Linux, Windows Server, Kubernetes, PostgreSQL, nginx, аккаунта AWS, демона Docker. Их больше сотни, каждый поддерживается сообществом практиков и пересматривается под новые версии платформ и новые техники атак. Там, где общее руководство вроде NIST SP 800-123 описывает принципы укрепления сервера (минимизировать поверхность атаки, работать с наименьшими привилегиями, патчить, логировать), CIS Benchmark даёт точные настройки, которые реализуют эти принципы на стоящей перед вами машине — вплоть до файла, строки и ожидаемого значения.

Две структурные черты важны для того, как им пользоваться. Во-первых, рекомендации делятся на Level 1 (практичное укрепление, которое не должно ломать нормальную работу — здравый дефолт для большинства парков) и Level 2 (глубокая эшелонированная защита для сред высокой безопасности, где жертвуют частью функциональности или удобства). Во-вторых, каждая рекомендация помечена Automated или Manual: у Automated есть машинно-проверяемая процедура аудита и исправления, Manual требует человеческого суждения. Это разделение — самое важное, что зрелый инженер считывает с benchmark, потому что оно прямо говорит, какие контроли можно обеспечивать непрерывно, а какие требуют процесса.

От benchmark к вашей базе

Benchmark — это не база. Benchmark — это меню; ваша конфигурационная база — это блюдо, под которым вы реально подписались: конкретный набор рекомендаций выбранного вами уровня, минус исключения, которые ваша среда законно требует, причём каждое исключение записано с причиной и владельцем. Именно на этом различии тихо ломается большинство программ укрепления. Команда, для которой целью становится «100% соответствие CIS», натыкается на рекомендацию, ломающую их приложение — скажем, отключение модуля ядра, нужного их агенту мониторинга, — и вместо того, чтобы записать обоснованное исключение, либо выкатывает сломанный хост, либо молча отключает всю проверку. Теперь база лжёт.

Зрелый ход — вывести базу один раз, осознанно. Начните с подходящего уровня (Level 1 для парка), пройдите по рекомендациям и по каждой примите явное решение: применить или исключить-с-причиной. На выходе — документ базы, в идеале машиночитаемый, где отклонение никогда не сюрприз. Почему это важно для обнаружения дрейфа — причинно: если вы не можете сказать, что такое «правильно», вы не сможете обнаружить «неправильно». Чистая база с аннотированными исключениями — это эталон, с которым сверяется каждый работающий хост. Нет эталона — нет обнаружения дрейфа, только надежда.

Дрейф: как укреплённый хост сам себя раз-укрепляет

Вы укрепляете золотой образ, выкатываете его, идёте дальше. Потом приходит энтропия. Конфигурационный дрейф — это зазор, открывающийся со временем между базой, с которой хост был развёрнут, и его реальным работающим состоянием. Обычно это не злой умысел — это эксплуатация: инженер отключает контроль, чтобы разобрать инцидент в 2 часа ночи, и забывает включить обратно; обновление пакета сбрасывает конфиг к вендорскому дефолту; ручной hotfix чинит одну машину, но не остальные сорок; две команды владеют пересекающимся конфигом и каждая «исправляет» другую. Каждое изменение по отдельности разумно. В сумме — парк, где нет двух одинаковых хостов, и спроектированная вами защита существует только в образе, а не в продакшене.

Дрейф опасен именно потому, что по умолчанию невидим. Хост всё ещё работает. Приложение всё ещё обслуживает трафик. Ничто не алертит. Уехавшая настройка заявляет о себе лишь тогда, когда её найдёт атакующий — или аудитор. Поэтому работа защитника — сделать дрейф видимым: непрерывно переаудировать каждый работающий хост против базы и поднимать каждое отклонение, чтобы контроль, переключившийся с no на yes, выдал находку на следующий день, а не в пост-мортеме.

Compliance as code: замыкаем цикл

Обнаруживать дрейф вручную не масштабируется дальше горстки хостов. Устойчивый паттерн — compliance as code: выразить базу как машиночитаемые, версионируемые правила и запускать их автоматически против каждого хоста по расписанию и в деплой-конвейере. CIS поставляет свои базы в структурированном формате и даёт инструмент (CIS-CAT), а открытая экосистема кодирует benchmarks как OpenSCAP/SCAP-контент или как политику в инструментах вроде Chef InSpec, Ansible или OPA. Форма одинакова независимо от инструмента: контроль — это правило с аудитом (как прочитать текущее значение) и часто исправлением (как выставить правильное), закоммиченное в репозиторий и запускаемое CI.

Кодирование базы как кода даёт вам четыре вещи разом. База становится ревьюируемой (изменение контроля проходит через pull request, а не через SSH-сессию в 2 ночи), версионируемой (вы можете доказать, что было «правильным» на любую дату — это любят аудиторы и требуют инциденты), единообразно обеспеченной (одни и те же правила бегут на хосте 1 и хосте 41, так что дрейф между хостами ловится) и быстро обнаруживаемой (плановый скан превращает полугодовую тихую регрессию в утреннюю находку). Оставшееся зрелое решение — что делать при отклонении: только алерт для контролей, где авто-починка могла бы сломать рабочую нагрузку (пусть согласует человек), против авто-исправления для контролей, где правильное значение однозначно и безопасно для обеспечения — сводя хост обратно к эталону, не дожидаясь тикета.