我来自黑暗的一面,遵从性,并希望获得更好的DevOps知识&如何在这些过程中实现SOX控制。我希望建立一个良好的知识库,以便能够建议控制,这将为审计员提供良好的保证,同时尽量减少对实际操作的影响。此外,当我与我们的内部DevOps团队会面时,我可以很有知识地谈论这个问题。
我通过ISACA白皮书和其他各种来源做了一些研究:
对于为DevOps工作流构建控制框架的资源,您有什么其他建议吗?或者只是一般的DevOps?
发布于 2018-06-27 04:15:46
您要寻找的是容器的符合性和安全性。有些公司可以为你做这件事,即使我不提倡,你也可以看到他们提供的东西,并以此为模板。
https://www.twistlock.com/platform/container-compliance/ https://www.aquasec.com/use-cases/container-auditing-compliance/
作为一名HIPAA安全官员和DevOps管理人员,我一直在回顾这些过程。在您的意义上,看待DevOps的方法可能是快速、早期失败和经常失败的船舶自动化和文化。其目标是不从安全和遵从性的角度破坏管道。从技术上讲,这看起来就像在管道中添加自动遵从性检查,在启动之前、期间和之后。随着自动化的建立,您可以用手动过程代替自动化。您可以查看像DevSecOps这样的主题,这是确保遵从性的相同概念,并且可能更接近您需要做的事情。
下面是一个AWS图,它可以帮助https://aws.amazon.com/blogs/devops/implementing-devsecops-using-aws-codepipeline/
发布于 2019-08-05 06:49:16
这是以前在你发布的链接中提到的,所以我只会添加一些细节。遵从性测试可以被看作是一种QA或集成测试,就像您的应用程序(S)可能具有的其他测试一样。为了使其有用,遵从性测试应该以某种有意义的方式失败构建,并指导开发人员和负责操作应用程序的人员(希望是同一团队的一部分),哪些准则被违反,以及如何恢复遵从性。
这也意味着遵从性团队需要能够编写测试,对应用程序的部署状态进行断言,最好是在部署之前。如果遵从性是在部署之后完成的,则需要回滚或应用修补程序。
我发现厨师Inspec是这份工作的好工具。它允许合规团队在最佳实践文档的基础上编写概要文件。它可以保存在一个独立的存储库中,如果需要的话可以从货架上摘下来,并应用于任意的工作负载,或者与应用程序包含在同一个存储库中。前者允许在整个组织的应用程序套件中进行全局遵从性测试,而后者则有助于促进开发人员和安全团队之间的更好协作。当然,中间有几种选择。
关于如何编写遵从性配置文件的一个很好的示例可以从厨师培训场地获得。
谁应该编写配置文件取决于几个因素,包括熟练程度、角色,当然还有应用程序的操作责任。我发现,与编写部署代码的人相比,用第二组眼睛编写配置文件是最好的。这有利于保持审计过程的独立性和公正性。
至于应该将遵从性测试插入到CI/CD管道中的位置,这通常是一个讨论的问题,并取决于您的交付和部署模型。其他人提到了左移的好处,这在DevSecOps世界也是有意义的。
然而,关键是测试实际的生产状态。通常,人们会为此使用阶段环境,这将是一个好主意,如果它是尽可能接近生产环境。然而,现实情况是,遵从性的某些方面会影响应用程序或环境的某些方面,因此将遵从性测试注入CI/CD部署的各个阶段(类似于图3.1 )通常更有意义:

不同的工具在不同的阶段发挥作用,当您沿着交付管道移动时,遵从性信封变得越来越复杂。部署之后,您也无法确定状态是否与代码库中的内容不同(人们可以登录并执行操作)。在某些时候,您需要断言应用程序的总体遵从性,并将其作为监控系统的一部分。
拥有一组可作为代码执行的遵从性概要文件,并且能够破坏构建,可以更容易地实现持续改进,给开发人员和操作员带来即时的优势,从而更快地交付质量代码。它还允许你在审计人员敲门时向他们提供具体的信息。
发布于 2019-08-04 22:09:17
你读过NIST 800 190吗?这份文件是由负责集装箱安全的公司twistlock的首席技术官John共同撰写的。
这个NIST文档帮助我理解了各种攻击以及您能做什么。这可能对你有帮助。
https://devops.stackexchange.com/questions/4173
复制相似问题