NIST CSF 2.0 для Linux-инфраструктуры: безопасность как управляемый процесс

NIST Cybersecurity Framework 2.0 — это не набор команд и не сертификат. Это рамка управления риском, которая связывает техническую защиту Linux-серверов с владельцами систем, требованиями бизнеса, реагированием и восстановлением. Она особенно полезна, когда в проекте уже несколько VPS, контейнеров, баз данных и подрядчиков, а настройки безопасности существуют отдельно друг от друга.

Разберём практический профиль для сайта, API, Telegram-бота или небольшого кластера. Цель — получить проверяемый процесс: понятно, что защищается, кто отвечает, какие меры внедрены и как измеряется результат.

Шесть функций NIST CSF 2.0

• Govern — роли, политика, поставщики и допустимый риск.
• Identify — активы, данные, зависимости и уязвимости.
• Protect — доступ, обновления, защита данных и конфигурации.
• Detect — журналы, мониторинг и обнаружение отклонений.
• Respond — локализация инцидента и координация действий.
• Recover — восстановление сервиса и устранение первопричины.

Функции образуют непрерывный цикл. После восстановления организация обновляет профиль риска, правила и защиту. CSF описывает результат, но не требует конкретный продукт: ограничение доступа можно реализовать через SSH-ключи, MFA, VPN, bastion-host и минимальные права sudo.

Создайте профиль Linux-сервера

Начните с карточки актива. Для каждого узла зафиксируйте:

• дистрибутив, версию ядра и срок поддержки;
• роль сервера и владельца системы;
• критичность и последствия простоя;
• публичные адреса, домены и открытые порты;
• пользователей, сервисные аккаунты и sudo-доступ;
• обрабатываемые данные и внешние зависимости;
• расположение резервных копий и дату последнего восстановления;
• целевые RTO и RPO.

RTO — допустимое время восстановления. RPO — допустимая потеря данных по времени. Ежедневная копия может означать RPO почти 24 часа. Если бизнес допускает потерю только 15 минут, нужна другая схема резервирования.

Govern: кто отвечает и по каким правилам

У сервера должен быть владелец, принимающий решения о риске. Даже небольшой проект нуждается в минимальных правилах:

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

Identify: инвентаризация поверхности атаки

cat /etc/os-release
uname -r
systemctl --type=service --state=running
ss -tulpn
findmnt
last -ai

Сопоставьте результат с ожидаемым состоянием. Если web-сервер должен принимать только HTTPS, а наружу доступны PostgreSQL, Redis или Docker API, это незапланированная поверхность атаки. Для контейнеров сохраняйте SBOM, для приложений — lock-файлы, для WordPress — перечень активных плагинов и тем.

Protect: базовый профиль защиты

Доступ

Используйте Ed25519-ключи или аппаратные ключи, отключите парольный вход и прямой root-login. Администрирование по возможности выполняйте через VPN или bastion-host.

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
MaxAuthTries 3

Настройки OpenSSH размещайте в drop-in-файле внутри /etc/ssh/sshd_config.d/. Перед применением выполните sshd -t и сохраните резервную сессию.

Обновления и конфигурация

Используйте поддерживаемую LTS-ветку, автоматизируйте security updates и контролируйте перезагрузки после обновления ядра. Конфигурацию храните как код: Ansible или cloud-init дают историю, review и воспроизводимость.

Сеть и секреты

Firewall разрешает только необходимые соединения. Базы данных, Redis, панели и Docker socket не публикуются в интернет. Секреты не должны попадать в Git, Dockerfile и журналы CI/CD.

Резервные копии

Копия на том же VPS не защищает от удаления сервера или компрометации аккаунта. Используйте несколько копий на разных носителях, одну — вне основной площадки. Архивы шифруйте, а восстановление регулярно проверяйте.

Detect: какие события контролировать

• успешные и неуспешные административные входы;
• изменения пользователей, групп, sudoers и SSH-ключей;
• запуск новых systemd-сервисов;
• неожиданно открывшиеся порты;
• остановку журналирования;
• аномальную нагрузку и сетевой трафик.

journalctl -p warning..alert --since today
journalctl -u ssh --since today
sudo auditctl -s
sudo ausearch -m USER_LOGIN --start today

Критичные события отправляйте на отдельный узел. У каждого алерта должен быть владелец и понятное действие: сигнал, который никто не проверяет, не является мониторингом.

Respond: план действий при инциденте

1. зафиксировать время и признаки инцидента;
2. ограничить доступ, не уничтожая доказательства;
3. сохранить журналы, процессы и сетевые соединения;
4. отозвать ключи, токены и пароли;
5. определить затронутые данные;
6. восстановить сервис из доверенного источника;
7. устранить первопричину и обновить меры защиты.

Если атакующий получил root, случайное удаление подозрительного файла не возвращает доверие к системе. Надёжнее пересоздать узел из проверенного образа, сменить секреты и восстановить данные.

Recover: проверяйте восстановление

Успешный backup job не гарантирует работоспособность копии. Тест включает новый или изолированный сервер, получение и расшифровку архива, восстановление базы и файлов, запуск приложения и функциональную проверку.

Сравните фактические RTO/RPO с целевыми. Если восстановление заняло восемь часов вместо двух, автоматизируйте развёртывание, увеличьте частоту копий или измените архитектуру до реального инцидента.

Практические метрики

• доля узлов на поддерживаемой версии ОС;
• доля узлов с актуальными security updates;
• время закрытия критической уязвимости;
• число публичных сервисов относительно утверждённого списка;
• число привилегированных аккаунтов;
• доля копий с успешным тестом восстановления;
• фактические RTO и RPO;
• время обнаружения и реакции на подозрительный вход.

План внедрения на 30 дней

1. Неделя 1: инвентаризация узлов, владельцев, портов, доступов и данных.
2. Неделя 2: SSH hardening, MFA, firewall и удаление лишних сервисов.
3. Неделя 3: централизованные журналы, алерты и политика обновлений.
4. Неделя 4: тест восстановления и учебный сценарий инцидента.

Текущий и целевой профиль

CSF предлагает описать Current Profile — фактическое состояние — и Target Profile — необходимый результат. Не отмечайте контроль как выполненный только потому, что инструмент установлен. Например, «резервное копирование настроено» и «восстановление проверено в пределах RTO» — разные состояния.

Для каждого разрыва укажите риск, приоритет, владельца, срок и доказательство выполнения. Техническим доказательством может быть конфигурация Ansible, отчёт сканера, запись учебного восстановления или журнал проверки доступа.

Риск поставщиков и цепочки поставки

Linux-проект зависит не только от операционной системы. В профиль входят хостинг, DNS, CDN, Git, CI/CD, container registry, плагины и внешние API. Для каждого поставщика определите владельца аккаунта, MFA, резервный способ доступа, процедуру выгрузки данных и действия при недоступности.

Зависимости приложения фиксируйте lock-файлами, создавайте SBOM и контролируйте источник артефактов. Компрометация CI или registry способна обойти отличный hardening production-сервера.

Приоритизация по риску

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

Принятый риск документируется: кто его принял, почему исправление отложено, какая временная защита используется и когда решение пересматривается. «Не успели» не является управлением риском.

Учебные сценарии

Проведите tabletop exercise: украден SSH-ключ, утечка токена CI, шифрование базы или удаление VPS. Команда должна определить, кто принимает решение, где лежат контакты, как изолировать систему, какие секреты отозвать и как восстановить сервис.

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

Ошибки внедрения CSF

• превращение Framework в формальную таблицу без владельцев;
• покупка инструментов до инвентаризации и модели угроз;
• оценка безопасности количеством алертов;
• отсутствие тестов восстановления;
• игнорирование подрядчиков и облачных аккаунтов;
• попытка исправить все разрывы одновременно.

FAQ

CSF — это сертификация?

Нет. Это добровольная рамка управления риском. Обязательные требования определяются отраслью, законом и договорами.

Заменяет ли CSF CIS Benchmarks или ISO 27001?

Нет. CSF организует результаты и риски, CIS даёт рекомендации по конфигурации, а ISO 27001 — требования к системе менеджмента. Их можно применять совместно.

Подходит ли CSF маленькому проекту?

Да. Начните с активов, владельцев, MFA, обновлений, копий и проверенного восстановления.

Изменения безопасности сначала проверяйте на отдельном стенде. Развернуть тестовый VPS на Beget можно для проверки конфигурации и восстановления до переноса в production.