嘿,每一个人。我叫Liran Haimovitch，今天我要讲的是在高遵从性环境中管理软件开发。请记住，当你看到这个演讲时，我会在聊天中站在你旁边，所以如果你有任何问题或任何问题，只要在聊天中写下，我会回答你。看我自己的现场演讲可能会有点奇怪，但我们还是去做吧。现在,在我开始之前,对……只是……几分钟前这个DevSecOps轨道上约翰·威利斯DevOps讨论实现治理,这对我来说是很特别的,因为4年前,我刚进入DevOps类由约翰·威利斯,在线课程,EDX和我知道DevOps来自他对我来说有点特殊的时刻之后他说话。
就在这里，请记住，演讲有很多共同点，所以我希望我在他之后会很有趣，有教育意义。祝我们好运。我们开始吧。正如我提到的，我叫Liran Haimovitch，是Rookout的联合创始人兼首席技术官，我是敏捷、DevOps和精益等现代软件开发方法的倡导者，在创立Rookout之前，我花了大约10年时间为以色列做网络安全工作。
我曾担任过网络安全研究员、开发人员、团队领导、项目和产品经理等多个角色，后来加入了Rookout，我也对合规有了很多了解。在Rookout，我们实际上做了很多合规工作，特别是对于这样一个不到3年的年轻公司。
在此过程中，我们已经获得了HIPAA SOC 2 Type 2 ISO 27001以及GDPR和CCPA。我们通过如此多的合规性的原因是Rookout与客户合作的方式，为您提供了一些背景。Rookout是一个SDK，可以部署在我们客户的环境中，无论是他们的生产阶段，都可以用于动态提取数据，而无需编写更多的代码，重新部署或重新启动。现在，要让我们的客户在这些环境中部署我们，既需要很大的信任，也需要我们满足他们的合规和法律需求。这就是我们现在变得如此深入合规这么早,大约2年前,2年半前我们刚刚开始我们的第一个合规- SOC 2 2型DevOps主管我坐下来与我们的时间和他和我分享他的故事从一个以前的雇主,他们通过SOC 2 2型合规,它变得如此糟糕开发人员无法做这项工作,他几乎放弃,假设对我来说并不是最令人鼓舞的事情我们都知道,为了让开发人员做他们的工作，特别是在现代、小型、敏捷的组织中，你希望他们被授权。
我认为最好的方法是通过DevOps报告的状态来了解它，这是当今DevOps最重要的知识宝库之一，引用Nicole和团队的话说，“我们自己的研究发现，一个文化优化信息流信任、创新和风险分担的组织可以预测软件开发组织的绩效”，因此我们试图赋予我们的开发人员权力，我们试图向左平移，我们正试着给他们尽可能多的帮助。同时，看看这段关于治理的引用，这段引用来自Align Org solutions的Read Deshler他说的是在商业中，我们经常使用政治上更精明的术语治理而不是控制现在，你可以在线阅读这篇文章它确实提出了挑战治理并不一定意味着控制有不同的方法，但传统上，传统形式的顺从变革委员会，所涉及的一切都是关于控制，一直是关于你作为一个高管告诉你的员工做什么，怎么做，什么时候做，我们关注的是敏捷和DevOps，这不是我们试图实现的目标，也不是我们试图实现的方式。
因此，我们必须弄清楚如何实现无控制的治理，这实际上是可能的，这两种想法是不一样的，用词也不一样。
可以实现治理通过定义你的团队为你的团队的基本规则,你可以让他们获得有需要做什么,以保持你的密码安全与合规,你只需要有测量的边界的地方,知道当你的团队,当你的工程师的界限你必须知道如果有人窃听你的系统,你必须知道什么是错误的,但你不需要控制一切。你只需要制定基本规则。DevOps有很多原则。对于这节课，我从See the Whole博客中选择了这个。
它展示了DevOps社会方面、自动化、质量保证精简、共享和度量这6个不同的原则，正如你所看到的，其中一些原则，如社会方面、信任和共享，与控制并没有很好地一致，因为你试图授权你试图信任，另一方面，你试图启用许多其他的东西，如质量保证、度量，在某种程度上，自动化实际上与治理携手工作，所以，你必须缓和这场冲突。你通过DevOps来实现治理，就像John说的，不需要试图控制，在整个过程中，我有自己的小框架，试图弄清楚如何做到这一点，我今天想和你们分享，这是我为现有DevOps实现治理的方式，它已经为我们服务了多个合规周期，每当你做合规无论是从外部审计师或一些内部审计师或指令从你的老板你会得到要求的要求是要问你需要确保已经采取了和治理一个可预测的方式你必须问自己这是目前满足现有DevOps过程在我的团队,我的组内如果这个需求目前遇到了那么你的黄金。
您所要做的就是记录您通过现有流程满足需求的方式。就是这样。另一方面，您可能会发现现有的DevOps流程目前并没有满足这个需求。这就提出了一个问题为什么?我的意思是，DevOps都是关于持续学习的，现在，把它看作一个学习机会有人告诉你这个要求是必须的，这个部分是必要的以避免业务风险为你的企业避免业务风险为你的客户避免业务风险你同意他们的观点吗?你认为这会带来重大风险吗?如果是这样，那么你刚刚学到了一些东西。有一个新的风险，也许这是你所瞄准的新市场或地理位置的结果，你必须面对这个风险，但你可以用DevOps的方式来做。
不减轻风险通过添加变更委员会或手动过程减轻风险通过自动化通过把责任转移到开发人员通过测量的风险,所以,一旦你遇到了这样的风险你所要做的是文档,分享现在的审计师,有时一旦你理解风险,你可能会发现,这种风险不重要你的业务或产品或平台,因此,在许多情况下,你可以直接把它记录为一个可接受的治理风险我知道我们试图治理的风险是什么我知道需要的控制，我觉得现有的条件已经足够好了现在，你会感到惊讶但在很多情况下，一旦你精通了，一旦你了解合规当你开始理解你的流程的业务=你可以经常让审计师和客户,真正的风险是可以接受的,并且是不值得的时间和精力去修复它不幸的是在某些情况下这不会走得好,在Rookout已经有为数不多的情况下,我们需要实现控制其区域内我们没有必要觉得正是为了满足治理控制为例,我们一直觉得我们办公室的物理安全对于我们的服务安全来说并不重要所有的笔记本电脑都是加密的，密码保护的我们使用mfa登录等等不幸的是，我们遇到的一个合规审核员不同意在这个要求上让步所以我们不得不升级我们的物理安全来满足更高的标准，尽管对我们来说，这不是我们最好的判断，但在一天结束的时候，在整个过程中，Rookout的开发人员几乎没有受到我们现在经历的合规过程的影响，通过这个过程，通过这个框架，我们最终通过3个主要支柱实现了合规让我和你们分享一下，首先是自动化，我们在一个DevOps会议上，每个人今天都会谈论自动化的价值，他们会谈论它如何节省存储，如何加快速度，如何提供更一致的结果，在我们的情况下，所有这些都是正确的，从安全和治理的角度来看，最重要的是，我们所说的关于赋予人们权力和信任的困难，设置边界，保持平衡，这不是真的可以很容易与机器机器控制通过控制你写一个脚本,你控制它,所以机器可预见和让你非常非常容易goverened最重要的是,当你为安全自动化思考如何从员工删除权限,工程师和停止给人们访问生产环境中通常可以有脚本为他们做这项工作,所以你不需要给人们尽可能多的特权,所以,这是我们做的方式在Rookout我们所有员工权限授予一个自动化自动化门户在我们的案例中是詹金斯集群哩数可能不同,每一个员工都有一个登录门户和被访问各种各样的工作根据他需要任何的自动完成从门户是否为Kubernetes供应环境,扩展云资源上下旋转机器备份数据库,等等。2022世界杯阿根廷预选赛赛程
这个过程中发生的所有事情员工登录，员工触发作业以及作业的实际工作所有事情都被审计成日志，我们已经把治理放在了整个过程中，同时我们不需要给我们的员工通过SSH通过管理员访问生产环境的特权，但最好的是员工不会认为这是一种剥夺或伤害他们或阻止他们工作的东西。
另一方面，这是授权员工做他们真正的工作，并节省了辛劳。现在，整个自动化候选部署和发布，配置和取消配置环境系统和集成测试，维护、清理、备份和恢复，这与你在开发和运维方面自动化的东西没有什么不同，你必须考虑的唯一一件事是是否自动化，这样我就可以给更少的人更少的权限，通过给予更少的权限，你现在正在改善你的治理，Rookout的第二个支柱是CI/CD和GitOps，本质上是将自动化提升到一个新的水平，直接将其纳入公司的工作流程。现在,正如我所提到的,这是一个DevOps会议所以人们会谈论CI / CD一整天甚至还有这个新CI / CD提供从JFrog我确信你会听到很多关于今天,我要让别人讨论我想与你分享CI / CD的值在治理和相当多的第一次,你得到一个把一切真理的来源在Git中,然后你可以去那里看看是什么配置,代码是什么，部署了什么，事情的进展是什么，在哪里以及如何进行的，你向左移动而不是在应用程序写完之后添加所有这些治理需求，之后经过测试后准备部署你左移位尽可能要求开发人员构建一个安全管理应用程序从第0天给他们每一个要求你可以挑战他们找出如何编写代码以及如何测试它,确保它被支配,你实际上已经有了一个本机默认机制来做的,把请求包括人类和机器的过程评价和评估变化的代码就像你测试bug一样任何代码可读性的测试你都可以通过pull request测试任何安全需求你实际上有。所有事情都被记录下来你实际上知道谁打开了一个pull request谁批准了它，它是如何被测试的，并确保一切正常。最好的是，所有这些现有的工作处理和控制都已经到位了，你们的大多数团队已经知道如何以这种方式工作，如何使用它，你不需要在他们的日常生活中做任何改变，他们只需要通过拉请求做一些额外的步骤，这些步骤大部分是自动化的。
正如我所提到的，所有的事情都要经过审计，无论是源存储库中的Git更改，还是对CI/CD进行的更改，所有的事情都要经过审计，你确切地知道发生了什么，为什么，谁触发了它，所以你可以很容易地将它提供给你的审计人员作为证据。现在，实现遵从性的第三个支柱是监控和可观察性，这有两个原因。
第一个原因，我不打算花太多时间讨论是为了确保遵从性你实际上必须知道发生了什么你必须从你的环境中收集信息例如，如果你的治理需要正常运行时间监控你必须监控正常运行时间如果你做出其他保证那么你也必须监控这些但更重要的是，你有一个生产环境，组织中的每个人都想知道生产环境中发生了什么你有业务人员，销售和营销人员想知道有多少人注册了他们付了多少钱你有产品和用户体验人员想知道你的用户如何使用你的系统什么被使用得更多，什么少使用什么更直观或者与其说你有行动和安全人们试图确保系统安全,按预期工作,最后,肯定不是最不重要的是,开发人员通常你这里最大的危险,因为开发者需要不同的数据每天不管是修复一个缺陷是开发一个新功能开发人员日常数据需求变更而我提到过的所有其他群体倾向于需要相同的数据,日复一日的开发人员需要根据他们正在从事的任务进行更改，这经常导致我们中的许多人授予他们过多的生产访问权限，只是为了查看代码，通过这样做，我们正在损害对生产的治理，所以，确保你有适当的监控工具，以确保每个人都得到他们需要的数据，而不必以不受管制的方式直接访问生产;确保你有商业智能工具，为业务人员;确保你有日志记录和apm，为安全和运操作人员。
确保为工程师和错误跟踪发送尽可能多的数据从应用程序到谁需要它显然你必须确保所有这些监视工具也安全,访问控制等等关于Rookout的好处之一是,我们使用我们自己的产品,允许开发人员访问生产环境中根据需要收集数据安全审计的方式没有发放到生产服务器本身的直接访问。hth华体会最新官方网站
现在,构建你的可观察性和监控是一个很大的话题,可以说和写它甚至可能有一些会谈今天肯定还有其他我甚至给一些我想给几个指针特别是集中在安全所以先混合和匹配工具没有一个工具,将提供你所需要的一切你可能会获得那些和你要留意的从安全的角度来看尽量多买现成的有很多商业软件和开源软件可供你使用但最终，你有时候要做自己周围是否把一些胶带绑定在一起或开发一些自己尽量不要做太多,除非是真正必要的修订数据确保你刚刚经历了一个完整的磨难让你生产安全生产管理,确保你知道发生了什么,所以确保它被屏蔽的数据根据其敏感性和它在哪里会这样you’re not accidentally sending data under compliance to non-compliant systems and last but not least make sure to have retrospectives at the end of the day, there is no better way to figure out what you need than by seeing what you needed in the past now especially when you have production issues and data is needed then everybody needs to step in use the permissions they have and extract the data from production to fix it but once the dust settles down have a retrospective, think through it what data was missing? what data did you have to risk your activities in Ops or security perspective to get and how can you make sure that next time that data will be available faster, easier and to people who might not have as many privileges as the Ops people? Now, that’s it.
这就是我今天要说的全部内容。正如我提到的，我就在这里，在频道里和你在一起，所以请自由地问更多问题，在rookout.com上查看我们，并在Twitter上@liran_last上关注我
