两位行业专家在构建支持星巴克公司移动应用程序所需的团队和流程的过程中, 总结了一些经验和教训.
在日前召开的互联网安全大会上, 帮助星巴克公司构建一个主要云计算项目的两位安全和合规负责人发表了演讲. 几年前, 星巴克公司曾要求合规性自动化初创厂商 Shujinko 公司的创始人 Matt Wells 和 Scott Schwan 为其构建必要的团队和流程, 以支持星巴克公司开发的移动应用程序, 采用完全符合支付卡行业 (PCI) 的安全云架构, 并根据互联网安全中心 (CIS) 制定的标准进行衡量.
Shujinko 公司首席技术官 Matt Wells 解释说,"我们公司的 20 名工程师在大约 9 到 12 个月的时间里构建了一个高度自动化, 可扩展, 可重复的环境, 星巴克公司可以用来支持他们想要推出的所有产品, 他们以此为基础然后开始将其他应用程序移至公共云."
Shujinko 公司首席技术官 Matt Wells 和首席执行官 Scott Schwan 深入研究了他们为星巴克的工作细节, 并分享了有关如何将合规性纳入企业的云计算架构以及在此过程中扩展 DevSecOps 的技巧. 在此采用了他们自己的语言提出一些见解.
1. 将合规要求放入 "完成" 的定义中
Matt Wells 说,"对于一个工程团队来说, 将合规性要求纳入'完成'的定义中是非常重要的. 很多时候, 团队没有及早地开始对话和进行讨论. 因此,'完成'的定义没有包括与法规遵从性或安全性相关的内容. 因此, 为团队建立这种联系极为重要."
2. 让工程师直接负责保护环境
Matt Wells 说,"在特殊情况下, 我们正在构建一个完整的云平台, 并且我们负责该平台的安全性. 能够尽早设定期望, 也就是说,'这很重要: 如果想加入这个团队, 将会使用一些非常好的技术, 但是要对安全负责, 要对合规性负责. 如果没有通过审核, 那将是我们的团队责任, 而不是安全团队或合规性团队的责任.'"
3. 在云计算工程团队和安全团队之间建立紧密的联系
Scott Schwan 说,"我们确保从一开始就真正与安全领导保持一致. 我确实相信 DevSecOps 的基本原则, 因此, 如果工程团队了解他们正在建立的要求, 他们可以对自己的职责负责这样做, 不再是安全团队在项目的最后阶段突然涌入, 并试图更改或阻止它们, 因此, 文化转变的一部分是确保我们在团队之间建立信任."
4. 在构建之前定义安全性程序和要求
Matt Wells 表示," 我们从安全团队那里收集了要求, 并且从业务组那里收集了必须支持的地理区域的合规性要求. 我们拥有了必须遵守的所有合规性标准, 这些标准有不同的要求. 从那里我们定义了程序, 那么我们要如何给服务器打补丁呢? 我们将如何采用容器并部署代码?
我们认为在扩建之前设置这些程序很重要, 因为随着工程师扩建基础设施, 有时这些程序会影响他们构建某些技术的方式. 对我们来说, 这就是设计阶段."
5. 将安全专业知识嵌入并培训工程团队
Matt Wells 表示,"在设计之后, 我们大量招聘工作人员, 需要获得一些短缺的技能, 因此我们雇佣了一批安全人员, 开发人员和运营人员, 结果发现需要的开发人员比安全人员和运营人员多得多. 我们非常专注于自动化和规模化, 因此发现让开发人员参与进来更容易, 让安全人员和运营人员与他们一起工作, 定义开发人员将如何构建许多这些功能. 我们并不是直接聘用专业安全人员, 而是通过培训开发人员使他们成为安全人员."
6. 遵照法规自动加固环境
Matt Wells 表示,"对我们来说, 一个主要原则是自动强化我们构建的所有内容. 我们要做的第一件事是我们使用 Terraform 自动化配置和强化 AWS 账户. 我们花了一周的时间使用 Terraform 来构建 AWS 账户, 而不是花一天或几个小时来构建 AWS 账户, 设置日志记录, 密码策略等. 但是从长远来看, 每次我们在 AWS 账户中设置新内容时, 不必对工程师说,'是否设置了密码策略?'或者," 日志要去哪里?"我只想说,'运行 Terraform 脚本进行加固了吗? 现在我们可以继续工作.'"
7. 自动化护栏
Scott Schwan 说," 我们使用了可以扫描新环境的支付卡行业 (PCI)要求的供应商. 因此, 在运行脚本后, 我们立即运行并向他们提供了报告. 如果他们仍然遇到支付卡行业 (PCI)方面的问题, 我们将确保返回进入 sprint, 然后将它们添加到 Terraform 中的基础设施代码中, 然后下次进行设置时, 他们将不会遇到类似问题.
这是在 AWS 拥有他们现在拥有的一些工具和服务之前. 在此之前, 我们必须构建它, 因为那不是他们所拥有的东西. 我们确保将其纳入团队的精神之中. 当时是, 使用 CIS 基准测试, 获得良好的反馈, 迅速进行补救, 将其重新添加到其代码中."
8. 将基于合规性的测试构建到单元测试中
Scott Schwan 说," 我们总是必须验证是否在运行合规代码, 其中一部分是通过基于合规性的测试. 我们始终确保不会因为尽快行动而破坏合规性.
我们开始为代码编写单元测试, 不仅是针对功能的单元测试, 还涉及安全性和合规性. 我们希望确保团队每次部署新服务时都在测试合规性标准. 他们是否设置了密码策略, 是否启用了日志记录? 它是跨功能的. 编写这些单元测试的不仅仅是安全工程师. 团队队员对此也需要负责."
9. 尽可能使用云原生控件
Matt Wells 表示,"我们在这里所做的一件事是尽可能使用云原生控件. 云原生并不是说在云中提供控件. 而是使用了构建于云中的控件, 有时这意味着来自云计算提供商, 有时则意味着来自供应商. 这完全取决于情况."
10. 让工程师在差距评估中扮演重要角色
Matt Wells 表示," 在构建阶段结束时, 我们专注于完成程序, 以确保认为可以正常工作的东西有效. 在大多数情况下可以实现, 但是在某些情况下, 我们必须更改程序. 最重要的是, 我们实际上已经完成并验证了程序.
这需要进行差距评估工作, 我们把它交给构建它的工程师, 并在团队中分散了评估责任. 他们比其他人更了解环境, 因为他们拥有它的所有权, 并且会说,'是的, 我们确实存在差距, 我们必须解决这个问题.'"
来源: http://cloud.51cto.com/art/201911/606507.htm