Compliance на Kubernetes: кто берёт на себя NIS2 и DORA — security team или platform team?

Compliance на Kubernetes: кто берёт на себя NIS2 и DORA — security team или platform team?

Тикет с NIS2 или DORA почти всегда оседает на борде security: просто потому, что в названии стоит слово "регуляция". Три спринта спустя кластер не меняется, evidence не появляется, а security-лид получает молчаливое раздражение всей команды. Такой повторяющийся сценарий в европейских инженерных организациях описывает Matteo Bisi из компании Reevo в материале на CNCF Blog, опубликованном 9 октября 2026 года.

Краткий ответ

По закону за NIS2 и DORA отвечает management body организации, а не security-команда: это прямо следует из статьи 20 NIS2 и статьи 5 DORA. На практике регуляция застревает в security-бэклоге как название закона, а не как объект кластера с владельцем и сроком. Bisi предлагает закрывать разрыв трассировкой от статьи закона к Kubernetes-артефакту и RACI, где за большинство объектов отвечает platform engineering manager, а не security.

Где начинается путаница

Bisi формулирует проблему жёстко: она не юридическая и не техническая, а провал ownership с конкретной формой. Название регуляции попадает на борд вместо того, чтобы артефакт попал в спринт. Security умеет писать policy. Security не может замержить Helm chart.

Платформенная команда владеет кластером. Security владеет риском. Когда эти два владения не синхронизированы явным RACI, регуляция зависает между ними — формально у всех на виду, фактически ничья.

Автор оговаривается отдельно: ничего в материале не юридическая консультация, а приведённые соответствия не официальная карта compliance. NIS2 и DORA написаны от результата, а не от конкретной технической меры. Какие организации и сервисы попадают в периметр, какие меры пропорциональны и какого evidence достаточно, зависит от собственной риск-оценки компании, отраслевых правил, национальной транспозиции закона и позиции регулятора.

Два сбоя, когда всё падает на security

Дефолтный сценарий такой: всё, что связано с регуляцией, становится тикетом security. CISO или единственный security-инженер, который ещё отвечает в Slack, становится персональным владельцем NIS2, DORA и всего, что прилетит следующим. Platform-инженеры остаются на продуктовой работе. Security превращается в очередь.

Первый сбой — бутылочное горлышко. Каждое исключение для образа, каждый привилегированный securityContext, каждый запрос "нужно это в SIEM" ждёт одних и тех же людей. Delivery-команды учатся: говорить с security — значит хоронить задачу, и начинают обходить процесс. Появляется break-glass kubeconfig, непроверенный sidecar, реестр образов мимо утверждённого каталога. Несоответствие требованиям не светится красной ячейкой в презентации — оно расползается теневой инфраструктурой с тикетом, в котором до сих пор написано "security".

Второй сбой — выученная беспомощность на стороне платформы. Если compliance навсегда остаётся чужим бэклогом, platform-инженеры никогда не владеют логикой, стоящей за policy. Они включают admission policy, потому что сказали включить, отключают её при первом блокирующем релизе и ждут, пока security заметит. Это прямая противоположность той ownership-культуре, о которой говорят на каждой platform engineering конференции.

Что на самом деле пишут NIS2 Article 20 и DORA Article 5

Оба текста прямо называют, кто отвечает, и это не security-команда. Статья 20 NIS2 возлагает меры управления киберрисками на management body существенных и важных организаций: он утверждает меры, следит за реализацией, может нести ответственность за несоблюдение и обязан проходить профильное обучение.

Статья 5 DORA делает то же самое для финансовых организаций: management body определяет, утверждает, контролирует и остаётся ответственным за ICT risk management framework, а роли и зоны ответственности для всех ICT-функций должны быть чётко распределены и задокументированы. Должность CISO не заменяет это распределение — она лишь одна из ролей, которую распределение обязано назвать.

По пятницам это уже не вопрос совета директоров, а вопрос среднего менеджмента. Management body не будет патчить containerd и решать, хранить ли audit-логи kube-apiserver 12 месяцев или 18. Он не сядет на планирование, где "выкатить нового тенанта" конкурирует с "у нас всё ещё нет evidence trail". Эти решения принимают инженерные менеджеры — или их не принимает никто. Именно в этой пустоте под management body чаще всего умирают программы compliance.

Как требование регулятора превращается в объект кластера

У Bisi трассировка делится на два этапа. Первые три шага — периметр регуляции, контрольный вопрос, определение evidence — это интерпретация, и ею занимаются risk, legal и security. Следующие три шага — артефакт, пункт спринта, повторяющаяся операция — это доставка, и ею занимаются platform- и application-команды.

Передача между этапами — это артефакт, а не номер статьи. Тикет "реализовать статью 21(2)(d) NIS2" пропускает середину цепочки и просит инженера сыграть роль юриста, который решил, что закон применим.

Цепочка замыкается: шестой шаг — работающий pipeline — должен возвращать evidence риск-менеджменту, аудиту и SOC как рутинную практику, а не как аврал за три дня до проверки. Артефакт, который существует лишь потому, что кто-то однажды вручную прогнал скрипт, цепочку не замкнул.

Какие артефакты закрывают какие статьи регуляций

Bisi сводит результат трассировки в таблицу: артефакт, контрольный вопрос, который он закрывает, и статьи NIS2/DORA, которые делают этот артефакт релевантным — не буквальное предписание именно такой реализации, а обоснование, почему он вообще нужен.

DORA-колонка применима только там, где финансовая организация и ICT-услуга действительно попадают в периметр регуляции — это оговаривает сам автор.

Какие open source проекты производят evidence

Bisi подчёркивает: ни один из этих артефактов не требует отдельного compliance-продукта. Это обычные платформенные возможности, и open source-экосистема закрывает большинство из них. Не всё в примере — проекты CNCF: Sigstore и in-toto живут под OpenSSF, OpenBao — под Linux Foundation, но всё перечисленное — open source, и всё может эксплуатировать команда, владеющая кластером.

• Каталог hardened-образов: Harbor как реестр, Sigstore для подписи и верификации, in-toto для аттестаций, сканер образов в CI.
• Secrets как управляемый сервис: OpenBao или эквивалентный открытый secrets manager, External Secrets Operator для проекции секретов в кластер, SPIFFE/SPIRE для identity нагрузок, cert-manager для жизненного цикла сертификатов.
• Evidence обнаружения: upstream audit policy Kubernetes, Fluentd/Fluent Bit и OpenTelemetry для сбора, Falco для runtime-событий, Prometheus для операционных сигналов.
• Admission control: Kyverno или OPA Gatekeeper поверх upstream-бейзлайна Pod Security Admission.
• Software inventory: генерация SBOM в CI, хранимая как аттестация рядом с артефактом.
• Метаданные владения сервисом: Backstage или эквивалентный каталог — именно он делает RACI машиночитаемой, а не декларативной.

Этот список Bisi приводит как пример того, что можно собрать из открытых строительных блоков, а не как рекомендацию конкретного вендора. Сложнее всего эксплуатировать именно каталог hardened-образов: pipeline пересборки нужно держать живым на каждом базовом образе и рантайме, в том числе на неделе, когда половина команды в отпуске. Мало какая платформенная команда получает на это бюджет, а устаревший каталог хуже отсутствующего — потому что control statement к этому моменту уже утверждает, что всё под контролем. Закупка базового слоя у поставщика, который сопровождает его постоянно, легитимный ответ, но он не снимает вопрос владения, а меняет его форму: поставщик входит в периметр third-party-риска по статье 21(2)(d) NIS2 и статье 28 DORA, и за управление поставщиком тоже нужен именованный владелец.

RACI, которая должна пережить планирование спринта

Ниже — иллюстративный пример RACI из материала Bisi, а не юридическая рекомендация по распределению ответственности: адаптируйте роли и названия под структуру своей организации. Сам автор настаивает только на одной идее — security почти никогда не Accountable за артефакт.

Смысл не в конкретных буквах таблицы, а в том, что у каждой строки ровно один Accountable и ровно один исполнитель, который физически может замержить изменение. Secrets manager и каталог hardened-образов — это сервисы, которыми управляет платформенная команда, а не приложения, которые security навешивает в конце.

Два места, где такая RACI обычно рвётся

Bisi отдельно разводит два часто путаемых момента.

Обнаружение инцидента — не то же самое, что уведомление регулятора. Статья 23 NIS2 требует раннего предупреждения CSIRT или компетентному органу в течение 24 часов с момента осознания значимого инцидента, уведомления об инциденте в течение 72 часов и итогового отчёта в течение месяца. DORA устанавливает собственный маршрут отчётности и сроки для крупных ICT-инцидентов. Если заставить дежурного инженера "владеть отчётностью по NIS2", в два часа ночи получится либо паника, либо молчание. Инженер владеет фактами: что сломалось, когда, какой радиус поражения, что уже сделано. Назначенная control-функция владеет уведомлением регулятора. Инженерный менеджер владеет тем, был ли runbook отрепетирован до той ночи, когда он понадобился.

Исключения принадлежат менеджеру запрашивающей команды, а не security. Security может указать, что CAP_SYS_ADMIN в production namespace — плохая идея. Только менеджер команды, которая просит исключение, может решить, что продуктовый риск того стоит, зафиксировать причину и назначить срок истечения. Если Accountable за исключения — security, каждое исключение превращается в переговоры с человеком, которого все стараются не беспокоить, а настоящий принимающий решение остаётся невидимым.

Где не хватает мощностей, а не процесса

Простой тест на планировании: артефакт уже в следующем спринте с именованным инженерным менеджером, или он всё ещё строчка на слайде security? Второй, менее приятный вопрос: кто сейчас держит работу с лейблом "security" или "compliance", которая не должна быть его? Admission policy, которую должна была вести платформа, — один ответ. 40-страничный control mapping, который должен лежать у risk, — другой.

Именно нехватка мощностей обычно тихо убивает такие программы. Платформенная команда, укомплектованная только под продуктовую доставку, воспримет любой control как переработку: она выпустит либо каталог hardened-образов, либо новое тенантное окружение, но не оба силами тех же трёх человек — разве что roadmap написан с излишним оптимизмом.

Security по-прежнему задаёт планку: что значит "restricted" на практике, какие CVE допустимы как исключение, что должен содержать пакет фактов, какие логи реально нужны SOC. Но Consulted должно означать "ответит в рамках того же спринта", а не "присоединится к рабочей группе". Если security-функция не может себе позволить такую скорость реакции, честнее сократить набор контролей, чем держать очередь, которую delivery-команды научатся обходить.

"Мы не можем предъявить, кто имел доступ к kube-apiserver на прошлой неделе для этого инцидента" — нормальная фраза на второй неделе программы. Та же фраза за три дня до выездной проверки стоит заметно дороже.

Что проверить у себя

Для CTO и platform lead тест Bisi сводится к нескольким конкретным вопросам, а не к списку инструментов:

• Есть ли у каждого крупного регуляторного требования один конкретный Kubernetes-артефакт с именованным инженерным менеджером и местом в ближайшем спринте.
• Переживает ли ваша RACI реальное планирование спринта, или регуляторные тикеты систематически проигрывают фичам за приоритет.
• Кто сейчас держит работу с ярлыком security/compliance, которая логичнее лежала бы у платформы или у risk.
• Возвращается ли evidence к risk, audit и SOC как рутинная практика, или вы собираете его разово перед проверкой.
• Есть ли повторяемый шаблон декомпозиции "от статьи закона к объекту кластера", который можно будет применить к следующей регуляции после NIS2 и DORA — та же пустота под management body проявляется и в программах вокруг Cyber Resilience Act, где сроки реагирования жёстче.

Заключение

Цепочка короткая: management body отвечает по тексту закона, инженерный менеджер отвечает в кластере, security — специалист, которого консультируют, чтобы работа была сделана правильно, а инженер отвечает за объект, который он поставляет.

Укомплектовать только management body и security — получить политики и ответственность без единой строчки в Kubernetes. Укомплектовать только инженерного менеджера и инженера — получить быструю платформу, которую нечем объяснить проверяющему. Обе половины несущие.

В следующий раз, когда регуляция приземлится в переговорке, стоит для начала посмотреть не на security, а на инженерного менеджера, который владеет системой из требования, и задать два вопроса: какой артефакт он покажет на демо и в каком спринте он стоит. Если ответа нет, как заключает Bisi, у организации не пробел в безопасности, а пробел в ownership — а такие пробелы обходятся дороже.

FAQ

Кто по закону отвечает за NIS2 и DORA — CISO или совет директоров?

По статье 20 NIS2 и статье 5 DORA ответственность формально несёт management body организации: он утверждает меры управления риском и может быть привлечён к ответственности за несоблюдение. Должность CISO не заменяет это распределение ролей, а является одной из его частей.

Почему security-команда не может единолично закрыть требования NIS2 или DORA?

Security может написать политику или стандарт, но не может самостоятельно внести изменение в Kubernetes-кластер — например, замержить Helm chart с нужным securityContext. Исполнение требует участия платформенной команды, у которой есть доступ и полномочия менять инфраструктуру.

Что такое трассировка от регуляторного требования к Kubernetes-объекту?

Это декомпозиция абстрактного пункта закона до конкретного артефакта — admission policy, конфигурации логирования, securityContext в чарте — с именованным владельцем и сроком. По схеме Bisi первые три шага (периметр, контрольный вопрос, определение evidence) — зона risk, legal и security, следующие три — зона platform- и application-команд.

Какие open source проекты помогают собирать evidence для compliance в Kubernetes?

В примере Bisi это Harbor, Sigstore и in-toto для каталога hardened-образов; OpenBao, External Secrets Operator, SPIFFE/SPIRE и cert-manager для управления секретами; Fluentd/Fluent Bit, OpenTelemetry, Falco и Prometheus для evidence обнаружения; Kyverno или OPA Gatekeeper для admission control; Backstage для метаданных владения сервисом.

Является ли материал CNCF официальным compliance mapping по NIS2 и DORA?

Нет. Автор прямо указывает, что это не юридическая консультация и не официальная карта соответствия: периметр регуляции, достаточность мер и необходимый объём evidence зависят от собственной риск-оценки организации, отраслевых правил, национальной транспозиции закона и позиции регулятора.