Allianz Direct是世界上最有价值的保险品牌的欧洲直接面向客户的部门。在德国、荷兰、西班牙和意大利当局的监管下，它利用IS和IT风险职能部门与工程团队的合作方式的逐步改变，迅速建立一个绿地保险平台，将其扩展到所有四个国家，并从传统的解决方案中迁移出来。它在公共云中运行其平台，广泛使用敏捷和DevSecOps实践，每年部署数千次，同时遵守严格的法规、政策和流程。
该平台利用安联内部的核心保险系统--安联商业系统（ABS），该系统由大约60个用Kotlin、Java和NodeJS编写的微服务加强。我们利用领域驱动设计（DDD）来设计平台和我们的组织，围绕定义的交互点创建独立的团队，这些服务通常通过Kafka进行通信。我们还广泛使用Kubernetes进行容器编排，并采用云原生方法来构建软件。这种现代化的方法使我们能够快速构建具有灵活架构的可扩展软件，然而，正是合规流程的革命使我们得以上线。
相信我们，监管机构会喜欢它
保险业的核心是信任。客户支付保费，相信在未来，如果保险事件发生，保险公司会对他们进行赔偿。保险公司通常对风险有深刻的理解，特别是对其声誉的任何风险。他们有一种健康的恐惧，害怕站在监管机构和媒体的对立面，也许在创建流程以确保这种情况不发生方面有数百年的经验。然而，目前对云计算的争夺和对数字化转型的推动，甚至迫使保守的行业找到一种既能快速发展又不危及客户信任的方法。
它必须是更好的
变革从来都不是一件容易的事：在努力和组织压力方面都要付出高昂的代价。幸运的是，如果改变不仅能带来生产力和成本上的好处，还能带来更好的结果，那么倡导IS和IT风险的改变就会变得更容易。传统的流程往往更注重于证明控制的实施，而不是被减轻的风险。为了说服各个职能部门，你需要证明你不仅仅是想更快地构建软件，而且结果实际上会更可靠。
渗透测试就是一个很好的例子。大多数IS流程只在预定的基础上或在大型发布时要求进行渗透测试。通过将持续的笔测试解决方案整合到我们的DevSecOps流程中，我们缩小了差距，并证明了现代的方法，即使是更频繁的部署，实际上拥有更少的风险。
纳入持续的漏洞扫描是另一个例子，说明新方法的风险更小。以前的漏洞扫描只在构建时进行，由于旧的应用程序通常不经常更新，所以可能是几个月或几年前才检查一次运行中的应用程序。我们加强了一个商业工具，以持续扫描所有运行中的容器的漏洞，并立即将新的漏洞直接反馈给工程团队。
在最近的Log4Shell安全事件中，Allianz Direct的新安全方法得到了检验。当关于远程代码执行（RCE）问题的信息首次出现时，我们的IS团队提醒我们的工程团队注意这一威胁。在继续调查的同时，我们能够利用我们的基础设施即代码理念，快速部署WAF过滤器并定期更新。我们的IS工具扫描了所有正在运行的容器，以查找有漏洞的库版本，包括依赖的依赖，并强调了需要更新的微服务列表。在我们的工程师争分夺秒地升级服务时，我们的持续渗透测试工具被更新为使用Log4Shell漏洞进行探测，我们的日志平台也被持续扫描以发现可疑活动。在事件开始后的48小时内，我们的CI/CD管道重新部署了几乎所有的60个服务，同时遵守了所有的变更管理流程，我们能够证明所有的服务都被发现、扫描和更新。
专注于减轻风险，而不是检查清单
对IS和IT风险政策的遵守往往采取记录政策的形式，有时会让人觉得是一种填写清单的工作。着手改变计划提供了一个极好的机会，以确保你的政策实际上使你的公司更安全，而不是仅仅提供一种虚假的安全感。
当接近风险控制时，重要的是要记住过程不是重点，减轻风险才是重点。花点时间了解为什么会有这个过程，它试图防止什么，以及你如何能以另一种与你的新工作方式兼容的方式来减轻风险。
在Allianz Direct，我们有一个变更管理政策，所有的版本在部署前都要经过授权人员的签字，甚至新功能也被认为是变更。我们有雄心壮志，每年要部署1000次，但看不到有什么办法可以遵守这一要求。然而，在与我们的IT风险同事交谈后，我们了解到这一过程是为了防止在企业不知情的情况下部署新功能。我们在CI/CD平台上增加了一个步骤，要求产品所有者作为企业的代表，在生产管道接收之前，在GitHub上批准部署，从而缓解了这个问题。
我们的CI/CD平台使用Tekton和Argo CD，为我们的开发人员提供了流畅的部署体验。它们还使我们能够准确地知道在生产中运行的是什么，并将服务或基础设施的变化追溯到编写它的工程师和批准它的产品负责人。这一点，再加上回滚部署到有保障的先前状态的能力，在与审计人员讨论变更管理时是一个强大的优势。
IS和风险部的同事是一个奇妙的知识来源，并帮助寻找新的方法。事实上，我们发现他们和我们的审计同事对敏捷和DevOps方法所带来的挑战的认识比我们预期的要多得多。他们往往更乐意充当可信赖的顾问。
拥有规则
Allianz Direct是安联集团的一个运营实体（OE），这意味着我们需要正式采用我们自己的规则和政策。内部和外部审计师会定期进行审计检查，以确保这些政策的存在，并得到良好的记录和遵循。
与大多数安联的运营实体一样，我们的政策是基于安联集团的政策，但作为我们自己的运营实体，我们可以在与我们的新方法相冲突的地方进行修改。所有的改变都需要得到风险职能部门和管理委员会的批准，并且能够经受住审计的审查。
此外，能够正式做出这些改变并设计适当的控制意味着当审计发生时，我们可以证明我们遵循了我们记录的流程。如果我们是一个更大的实体内的创新团队，使用更传统的政策，审计会将我们标记为不合规。保险公司不喜欢不符合规定的情况，一般来说，集团管理委员会会被告知审计的问题。拥有规则使我们能够进行创新并符合规定。
挑战现状
许多反对敏捷和DevOps流程的人认为，这些方法与经过考验的合规政策不相容。通常情况下，这些假设是基于某种长期存在的企业神话，或者对这些新方法所能带来的好处的误解。
保险公司是非常保守的组织，而这种保守主义对我们和我们的客户都有好处。然而，它可能导致规则被解释得非常狭窄。随着围绕合规性的对话继续进行，我们逐渐建立了对哪些意见可以被挑战的理解。同样，了解这些规则试图减少的风险有助于指导我们。
有一个老大哥的帮助
虽然作为一个精简的组织使我们能够迅速转型，但在一些情况下，这也意味着我们需要安联集团其他部门的帮助。作为德国经济中具有战略意义的一部分，安联集团与德国监管机构BaFin有定期的接触点。这包括讨论我们的IT战略，包括转移到云端。这些讨论的结果使我们能够衡量监管机构对在云中托管数据的开放程度，并确定要解决的议题。
近年来，BAFIN加强了对IT安全的关注，包括在其对保险公司IT的特别规定（VAIT）中。对变化的认识是至关重要的，拥有理解和解释变化的资源也是如此。作为一个小型的OE，安联直销依靠集团的IS和IT风险功能来指导我们。
我们也能够利用安联德国在向云端迁移方面的努力。在2020年，安联德国通知BAFIN，它打算将一些IT转移到云供应商。这种通知的准备工作是巨大的，而Allianz Direct能够搭上这个通知的顺风车。
不仅仅是你
虽然把自己的房子整理好已经很有挑战性，但你也需要确保你的供应链是合规的。向云原生方法的转变，增加了供应商对更多管理服务或SaaS解决方案的转移。每一个都需要被评估，不仅仅是IS和IT风险，还有数据隐私的合规性。
当与SaaS供应商合作时，我们尽量避免那些需要分享客户身份数据或健康信息的使用案例。没有真正的方法来减少合规要求和检查，这可能是广泛的，导致较小的供应商被排除在外。在这些情况下，我们想了解数据是如何存储的，谁有访问权，服务提供商有哪些IS政策，以及他们是否符合我们所有的政策。
DevOps文化
对我们来说，一个关键的成功因素是我们的ISO Anton Göbel与工程师的接触。以前，ISO可能被看作是生产部署的守门员，因此要与之保持一定距离。在Allianz Direct，我们采取了完全相反的方法。安东和他的团队完全融入了工程团队：他们被工程师们看作是知识的来源和竞争的伙伴，而不是执行者。
不管是DevOps思想的副作用，还是开发人员现在被纳入我们的IS和IT风险流程，我们都看到组织对IS和IT风险的认识更加深刻。我们遵循安全和隐私设计的方法，所以风险是每个服务架构讨论的一部分，但我们也看到工程师们积极参与我们的IS功能。为了充分利用这一点，我们在每个工程团队中都有一个安全冠军的角色，我们为工程师提供额外的安全主题培训，以换取他们在团队中充当IS的眼睛和耳朵。
这种紧密的合作使Allianz Direct能够对最近的SpringShell安全事件做出快速反应。一位工程师是第一个注意到一条推特的人，他开始讨论这是否真的是一个RCE漏洞。他们通知了安全冠军和安东的团队。另一位工程师主动分析了Spring的源代码，并在Spring承认之前就把这个威胁作为一个可能的问题提出来。Allianz Direct能够利用这一分析在Allianz内部展开更广泛的讨论，使全球Allianz IS社区能够对这一威胁做出适当的反应。
从历史上看，唯一让工程师感到兴奋的时候，是他们觉得被合规性束缚的时候。然而，就像所有 "运营 "方法的变化一样（DevOps, DevSecOps, AIOps），在一个过程中整合人和授权人通常会产生深刻的影响。在我们的工程流程中建立IS和风险流程，使我们的工程师对风险有了更深的理解，更重要的是使我们的组织更加安全。