Kubernetes平台团队中谁负责NIS2和DORA
内容提要
合规失败常因将法规名称直接丢给安全团队，而未明确工程责任。NIS2第20条和DORA第5条要求管理层担责，但具体决策由工程经理执行。应建立从法规要求到Kubernetes对象的可追溯链，将制品而非法规名纳入冲刺。安全团队设定标准，平台团队交付加固镜像、密钥管理、审计日志等证据。关键是明确RACI，让工程经理对制品负责。
延伸解读
合规责任错位的典型症状
文章指出，将法规名称直接丢给安全团队会导致两种失败模式：安全成为瓶颈，交付团队开始绕行，产生影子基础设施；平台团队则陷入习得性无助，不拥有合规背后的推理。这两种失败都不是个人问题，而是组织设计问题。识别这些症状有助于团队及早调整责任分配，避免合规工作积压。
从法规到制品的可追溯链
文章提出一个两阶段可追溯链：风险、法律和安全团队负责范围、控制问题和证据定义；平台和应用团队负责制品、冲刺项和日常操作。交接点是制品，而不是法规条款号。例如，将“NIS2第21条”转化为“kube-apiserver审计策略已发布、日志已发送至SIEM、保留期已记录”。这样，工作可估算、可演示、可审计。
RACI中安全通常不是问责方
文章强调，对于加固镜像目录、密钥管理器等制品，平台工程经理是问责方，安全团队是咨询方。例外情况应由请求工程师的经理问责，而非安全团队。检测与通知是不同任务：值班工程师负责事实收集，指定控制职能负责向当局报告。明确这些角色可以避免责任真空和决策延迟。
容量规划与开源工具的现实
文章提醒，合规工作常因容量不足而失败。平台团队若仅按产品交付配置人力，则每项控制都成为加班。开源工具（如Harbor、Sigstore、Kyverno）可降低许可障碍，但无法解决人员问题。团队需在路线图中明确构建或采购决策，并诚实削减范围，而非将合规工作留给工程师在晚上完成。
Q&A
NIS2和DORA合规失败最常见的原因是什么？
合规失败常因将法规名称直接丢给安全团队，而未明确工程责任。具体表现为：法规名称被放在安全团队的看板上，而不是将制品放入冲刺。安全团队可以编写策略，但无法合并Helm chart。这导致安全团队成为瓶颈，平台团队产生习得性无助，最终出现影子基础设施。
NIS2第20条和DORA第5条对管理层的责任是如何规定的？
NIS2第20条将网络安全风险管理措施的责任置于基本和重要实体的管理层。管理层批准措施、监督实施、可能对不合规承担责任，并需接受培训。DORA第5条对金融实体同样规定：管理层定义、批准、监督并负责ICT风险管理框架，所有ICT相关职能的角色和职责必须明确分配并记录。
如何将法规要求转化为Kubernetes平台上的具体工作？
应建立从法规要求到Kubernetes对象的可追溯链，将制品而非法规名纳入冲刺。可追溯链分两阶段：风险、法律和安全团队负责范围、控制问题和证据定义；平台和应用团队负责制品、冲刺项和重复操作。交接的是制品，不是条款编号。例如，将“实现NIS2第21(2)(d)条”转化为“kube-apiserver审计策略已发布、日志已发送至SIEM、保留期已记录”。
在Kubernetes平台上，哪些开源项目可以用于生成合规证据？
开源项目包括：Harbor用于镜像仓库，Sigstore用于签名和验证，in-toto用于证明，OpenBao或类似秘密管理器，External Secrets Operator用于投射秘密，SPIFFE和SPIRE用于工作负载身份，cert-manager用于证书生命周期，Kubernetes审计策略，Fluentd或Fluent Bit和OpenTelemetry用于收集，Falco用于运行时事件，Prometheus用于运营信号，Kyverno或OPA Gatekeeper用于准入控制，Backstage用于服务所有权元数据。
在Kubernetes平台团队中，谁应该对合规制品负责？
工程经理应对合规制品负责。安全团队设定标准并咨询，但平台团队负责交付加固镜像、秘密管理、审计日志等证据。RACI中，平台工程师负责执行，平台工程经理负责问责，安全团队被咨询，应用团队和风险被通知。例外情况应由请求的工程经理负责。
事件检测和向监管机构通知有什么区别？
事件检测和向监管机构通知是不同的工作，有不同的时间要求。NIS2第23条要求：在意识到重大事件后24小时内向CSIRT或主管当局发出早期警告，72小时内提交事件通知，一个月内提交最终报告。DORA对重大ICT相关事件有自己的报告路径和截止日期。值班工程师负责事实（什么坏了、何时、影响范围、已采取的措施），指定的控制职能负责向当局通知，工程经理负责运行手册是否经过演练。
