浅析云原生应用安全组织架构

GNET0566

数字化转型是一股不可忽视的力量。在每个垂直领域，企业都努力成为技术公司，并越来越多地区分他们如何实现这一描述。

云和DevOps在这种转型中发挥着巨大的作用，并彻底改变了我们开发和运营软件的方式。软件从未像今天这样容易创建，从未像今天这样频繁地更新，也从未创新过如此迅速地适应客户需求。面对这样的变化，安全别无选择，只能适应。企业必须并将继续努力提高速度，而独立团队是实现这一目标的唯一途径。我们保护应用程序的方式必须转变，使其成为这些独立开发团队日常工作的一部分。安全团队首先需要专注于帮助这些团队实现安全性。安全性需要成为开发优先。

安全行业并不是 DevOps 旅程的一部分。安全流程倾向于控制持续流程，而不是合并到流程中。值得注意的是，安全流程无法实现以下功能：

增强独立开发团队的能力

安全能力由一个单独的团队拥有，开发团队无权做出安全决策，并且工具主要是为审计人员而不是构建人员设计的。

持续运维

安全流程仍然严重依赖手动门，例如安全审计或结果审查，从而减慢了持续流程的速度。

让安全工作违背速度和独立性的业务动机，不可能有好下场。开发团队必须在放慢速度（这会损害业务成果）和规避安全控制（这会引入重大风险）之间做出选择。这些都不是可行的长期选择，因此企业必须改变其安全实践以适应 DevOps 现实。

DevOps 推动了对开发优先的安全方法论的需求，在数字化转型时代，我们还看到了云的演变和云原生应用程序。云原生应用程序的范围比其前身更广泛，并且越来越多地包含底层堆栈的更多元素。

应用程序范围的这种变化也需要改变应用程序安全的范围。本文讨论应用程序安全性的一个新的和扩展的范围，称为云原生应用程序安全 （CNAS）。

采用 CNAS 需要对我们保护应用程序和基础架构的方式进行重大更改。进行转变的过程是一个旅程，对于每个组织，甚至对于同一组织的不同部分，其经历都是不同的。

虽然选择正确的道路是由你的决定，但是为了获得正确的路径，模式和最佳实践已经开始出现。在本文中，我提出了几个可以考虑打破现状的领域，以及如何打破现状。

重新思考安全组织架构

组织通常根据责任范围进行拆分。当你将保护基础架构的某些部分视为应用程序安全问题时，请重新考虑如何构建安全组织。更具体地说，请考虑是否更改应用程序安全团队的责任范围。

此外，随着你的安全实践变得更加偏向开发优先的理念，并专注于增强开发人员的能力，你对此应用程序安全团队的要求也会发生变化。你需要更多的同理心和项目管理以及更多的工程能力。你需要更多的建设者和更少的破坏者。

为了帮助你评估安全部门的组织结构，以下是我在应用程序安全这个领域中看到的三个最常见的团队作用域：核心应用程序安全、安全工程和较新的产品安全。这些应该作为如何构建组织的参考点，而不是采用完美的模型。

核心应用安全团队

让我们从现状开始，为应用程序安全团队保持相同的范围。由于这是默认状态，因此大多数组织都使用此团队作用域， 至少作为起点。

核心应用程序安全团队的任务是保护自定义应用程序代码和业务逻辑以及正在使用的开源库。他们通常拥有经典的应用程序安全测试（AST）套件，包括静态，动态和交互式应用程序安全测试（SAST，DAST和IAST）以查找自定义代码中的漏洞，以及软件成分分析（SCA）工具以查找易受攻击的开源库。此外，这些团队通常会开发安全教育和培训，并可能开展漏洞管理或漏洞赏金工作。在某些情况下，他们也可能使用 RASP 或 WAF 工具实现运行时应用程序保护的能力。

核心应用程序安全团队成员通常需要是安全编码方面的专家，并具有应用程序运行审核和安全代码审计的一些经验。他们需要良好的开发人员同理心才能与开发人员合作，这反过来又需要一些理解或与代码相关的能力，但不需要完整的软件开发证书。

坚持设定核心应用程序安全团队的主要优势是它在行业中的长期地位。它使招聘具有整个团队领域经验的专业人员变得更容易。对于工具来说，这是一个工具和实践被很好地记录的领域。从组织结构的角度来看，大多数行业都会认为应用程序安全团队与核心应用程序安全团队类似。

虽然核心应用程序安全团队的职责范围是维持现状，但它的方法论往往变得更加有利于开发人员。应用程序安全团队通常会将团队中的个人职责分配为多个开发团队的合作伙伴，从而帮助促进更好的协作。在应用安全领域有许多同行会开展安全冠军计划，帮助他们获得规模并在开发团队中嵌入更多安全专业知识。虽然范围基本保持不变，但核心应用程序安全团队的内部实践不必是传统的那些做法。