在设计阶段将安全性融入功能中

教程

DevOps

不同学科如何合并以提高效率是一件令人兴奋的事情。2009年，DevOps被创造出来，以解决开发和运维团队之间的摩擦。结果，行业朝着合并这两个团队的方向发展，使开发团队负责整个周期，从编写代码到生产部署。当然，谁会比开发它们的人更了解复杂性呢？

在这种转变之后，我们看到功能被迅速交付，新功能的上市时间也迅速缩短。DevOps也为许多其他实践奠定了基础，如MLOps、DataOps、GitOps，毫无疑问还有许多其他实践涌现。

今天我们将讨论一个你们许多人可能熟悉的实践，即称为DevSecOps（开发安全运维）。那么，什么是DevSecOps？

传统上将安全视为事后才考虑的问题，团队首先将功能发布到生产环境，然后在安全审查或事件发生后急忙部署安全修复措施。随着网络安全、供应链和其他复杂攻击的激增，行业迅速意识到，与开发和运维一样，安全也应该成为流程的一部分。它应尽早嵌入到开发生命周期中，因为后期处理安全问题可能是昂贵的（无论是从架构还是运维的角度来看）。

现在，让我们讨论如何将其应用到我们开发生命周期的各个阶段，以确保我们发布的代码不仅高效，而且安全。

通常，发布一个功能的过程包括：

开发 – 在此阶段，功能被构建
分发 – 在此阶段，创建和准备交付物品
部署 – 在此阶段，功能被发布到生产环境中

让我们讨论在开发阶段我们可以采取哪些步骤来增强我们正在构建的功能的安全性姿态。

在开发阶段，一个功能经历设计审查、编码，然后是拉取请求审查。作为设计审查的一部分，功能所有者讨论API合同的外观，我们使用的数据库类型，索引，缓存策略，用户体验等等（并非详尽列表）。在安全优先的文化中，执行威胁建模也很重要。

执行威胁建模

简单来说，威胁建模是”识别漏洞、进行风险评估并实施推荐的缓解措施，以确保产品/组织的安全状态不受损害。”

让我们举个例子来理解。假设您正在开发一个 API，该 API:

列出产品目录中的产品。
搜索产品或产品类型。

HTTP

GET /api/products?search=laptop

威胁模型可能如下所示:

functionality	vulnerability	risk assessment	recommended mitigation
未经身份验证的用户可以搜索产品	威胁行为者可以执行分布式拒绝服务 (DDoS) 攻击，使数据库和 API 基础设施不堪重负	高 – 可导致服务中断并降低可用性	使用 API 网关或速率限制器防止 DDoS 攻击。
用户输入搜索字段的查询字符串	可能执行像插入”1=1″这样的 SQL 注入攻击	高 – 攻击者可以删除生产表	确保对输入进行适当验证/净化。
用户接收产品详情	暴露内部字段，如数据库ID、状态代码和版本号，可能会让攻击者获取关于数据库或底层系统结构的关键信息。	中度风险 – 攻击者可以利用这些内部实现执行诸如信息收集等攻击。	只发送用户所需的细节。