文章总结： 文章提出云原生安全默认设置的八大原则：将安全作为设计要求、优化配置体验、明确不安全配置责任、支持渐进式迁移、继承底层安全、规范例外管理、防御常见漏洞及解释安全局限。通过这些纵深防御措施，旨在提升云原生环境整体安全性，降低运维风险。 综合评分： 88 文章分类： 云安全,安全建设,安全开发,解决方案,应用安全

安全默认设置：云原生

河南等级保护测评

2026年1月19日 00:01 河南

以下文章来源于豫说网数安 ，作者何威风

豫说网数安 .

网络安全人人有责，贯彻网络安全为人民，网络安全靠人民。网络安全和信息化是相辅相成的。安全是发展的前提，发展是安全的保障，安全和发展要同步推进。

1. 将安全性作为设计要求

理由：在设计云原生系统时，安全性应与一致性、可用性和分区容错性并列为第四大支柱。与事后将系统从不安全状态迁移到安全状态相比，这种方法可以节省时间和精力成本。这种方法被称为“安全设计”。

方法：利用威胁建模、原型和现有系统的红/紫/蓝队测试报告，以及强化反馈循环，生成用于缓解潜在攻击的设计需求。这些需求应以相应测试的形式整合到现有的软件开发流程和流水线中。

例如：Docker运行时自带内置的seccomp策略，默认情况下会阻止不需要的Linux功能，并在本地Unix套接字上运行，从而减少内核和网络层的攻击面。

2. 应用安全配置可获得最佳用户体验

理由：安全默认设置应包含在初始配置中，并且对操作员透明。它必须是完成任务最简便的方法，且不会显著降低系统性能。

方法：审查现有的面向最终用户的指南和API，确定安全配置的位置，并向项目用户提出以下问题：说明是否清晰？API文档是否明确？是否需要读者或用户具备专业知识或进行猜测？是否增加了读者或用户的认知负担？如果安全配置的实施时间与传统设置相同或更长，或者缺少文档，或者难以理解，则应重新审视配置，争取每次版本发布后将时间缩短20%，最终将其纳入项目设置和安装流程。

例如：在Kubernetes中启用双向TLS以在控制平面组件之间进行通信，由于其内置的证书管理功能，因此具有最佳的用户体验。

3. 选择不安全的配置是一种有意识的决定

理由：有时，为了实现业务目标，会采用不安全的配置，但这会增加风险。在这种情况下，这种选择应该易于理解，并且需要系统用户明确做出选择，以便他们既理解风险，又有意识地接受风险。

方法：在系统以不安全模式运行时发出警报，并确保相关文档清晰地记录这些信息。列出不安全配置的安全隐患，并提供指向首选安全配置指南的链接。

例如：要在 Kubernetes中以特权模式运行pod ，需要在pod规范的安全上下文中显式添加 privileged: true，从而使用户选择以特权模式运行 pod。

4. 从不安全状态过渡到安全状态是可能的

理由：当安全性未被作为设计要求，且项目被广泛采用时，转向更安全的默认设置可能会获得维护者的关注和支持。突然切换到安全的默认设置可能会导致向后兼容性问题。如果这种转变是渐进的、简单的且可逆的，则可以增强用户对这些安全默认设置的信心。

方法：每次版本发布后与最终用户互动，了解他们在采用和使用安全默认设置方面的体验。每个迭代周期都安排专门的工程时间，通过简化或自动化升级和迁移中的配置，减少最终用户遇到的任何困难——目标是在向后兼容性、用户体验和新功能开发之间取得平衡。

例如：Kubernetes中的Seccomp过滤器支持功能，包括特性门控和系统调用故障审计功能，使用户能够逐个集群地过渡到这种安全的默认状态。如果过渡失败，可以将集群和命名空间恢复到之前的默认状态。

5. 安全默认设置将被继承

理由：底层系统的安全默认设置可以被运行在其上的系统继承。这使得系统能够实现更高层次的抽象，并降低系统耦合度，从而避免不同层级间的冗余工作。

方法：提供一个以安全默认设置为中心的共享责任模型，底层系统可以提供这些默认设置，并提供指向指南、说明和设置的链接，以确保这些默认设置可以作为纵深防御的一部分被继承。继承的控制权应明确说明混合控制在哪些情况下由用户负责。

例如：使用TLS协议进行服务间通信，使得使用TLS的系统能够继承TLS协议及其实现的安全特性，而无需担心安全密钥交换、传输中数据保护和双方身份验证。

6. 例外列表享有顶级支持

理由：对于某些工作流程而言，安全的默认设置可能过于严格。在这种情况下，应允许例外情况，并由策略引擎记录和跟踪这些例外情况。正确实施例外列表应确保仅授予必要的权限。

方法：例外列表被视为一项基本功能，并纳入软件安全设计之中。在制定设计需求时，应为例外列表创建用户故事，并与其他需求同等重视。

例如：策略执行准入控制器（如Pod安全准入 (PSP替代品)）内置支持添加命名空间列表，在这些命名空间中不强制执行Pod安全策略，以允许在这些命名空间中运行特权工作负载。

7. 安全的默认设置可以防止普遍存在的漏洞利用

理由：安全的默认设置应该为系统用户创造价值，保护他们免受普遍存在的常见漏洞利用，这些漏洞利用的成功前提是不安全的。

方法：在产品开发流程中，集成工具和代码审查，以识别以下常见安全漏洞：远程代码执行 (RCE)、任意代码执行、任意文件读取、路径遍历、凭据泄露和权限提升。在发布前，积极缓解并修复所有发现的漏洞。

例如：以非root用户身份运行或启用SELinux强制模式，可以防止在容器运行时和 Kubernetes中检测到的多个漏洞。

8. 系统的安全局限性是可以解释的

理由：即便系统设计者出于好意，某些安全控制措施也无法在不从根本上改变系统性质的前提下应用于系统。在这种情况下，这些限制应被记录在案并确保易于查找，同时应清晰、易懂地解释这些权衡取舍背后的原因，并列出替代方案。

方法：在设计评审和代码评审过程中，标注出安全选项会对软件行为产生负面影响的区域。将排除安全选项的决定记录在代码和设计文档中，并将此信息复制到更易于最终用户理解的“设计注意事项”指南中。

例如：容器运行时不提供虚拟机管理程序隔离，因为容器并非虚拟机。在这种情况下，可以使用Kata容器等替代方案，它们提供硬件虚拟化，同时允许像管理容器一样管理工作负载。

注意：请将示例限制在与云原生生态系统相关的开源项目中。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：河南等级保护测评 《安全默认设置：云原生》