该银行将其项目外包给许多承包商。 “外部”编写代码，然后以不太方便的形式传输结果。 具体来说，流程是这样的：他们移交了一个通过功能测试的项目，然后在银行周边进行集成、负载等测试。 人们经常发现测试失败。 然后一切都回到了外部开发人员手中。 正如您所猜测的，这意味着错误修复的准备时间很长。
该银行认为，有可能而且有必要将整个管道（从提交到发布）纳入其旗下。 这样一切都是统一的，并由银行负责产品的团队控制。 也就是说，就好像外部承包商只是在办公室隔壁房间的某个地方工作一样。 在公司堆栈上。 这是一个普通的 DevOps。
秒从哪里来？ 银行的安全对外部承包商如何在网段中工作、某人拥有哪些访问权限、如何以及由谁使用代码提出了很高的要求。 只是 IB 还不知道，当承包商在外面工作时，几乎没有遵循银行标准。 然后几天后每个人都需要开始观察它们。
承包商可以完全访问产品代码这一简单的事实已经让他们的世界发生了翻天覆地的变化。
这一刻，我想给大家讲的DevSecOps的故事就开始了。
银行从这种情况中得出了哪些实际结论？
关于一切都以错误的方式进行这一事实存在很多争议。 开发人员表示，安全只是忙着试图干扰开发，而他们就像看守人一样，不假思索地试图禁止。 反过来，安全专家在两种观点之间犹豫不决：“开发人员在我们的电路中创建了漏洞”和“开发人员不会创建漏洞，漏洞本身就是开发人员”。 如果没有新的市场需求和 DevSecOps 范式的出现，这场争论将会持续很长一段时间。 可以解释的是，这种“开箱即用”考虑到信息安全要求的流程自动化将帮助每个人保持快乐。 从某种意义上说，规则是立即写下来的，并且在游戏过程中不会改变（信息安全不会意外地禁止某些事情），并且开发人员让信息安全了解所发生的一切（信息安全不会突然遇到某些事情） 。 每个团队也负责最终的安全，而不是一些抽象的老大哥。
- 由于外部员工已经可以访问代码和许多内部系统，因此有可能从文档中删除“开发必须完全在银行基础设施上进行”的要求。
- 另一方面，我们需要加强对正在发生的事情的控制。
- 妥协的办法是创建跨职能团队，让员工与外部人员密切合作。 在这种情况下，您需要确保团队使用银行服务器上的工具。 从开始到结束。
也就是说，可以允许承包商进入，但需要给他们单独的部分。 这样他们就不会从外部将某种感染带入银行的基础设施，也不会看到超出必要的内容。 好吧，这样他们的行为就会被记录下来。 用于防止泄漏的 DLP，所有这些都包括在内。
原则上，所有银行迟早都会遇到这个问题。 在这里，我们走了一条老路，并就“外部”工作的这种环境的要求达成了一致。 出现了最大范围的访问控制工具、漏洞检查工具、电路、组件和测试的防病毒分析。 这称为 DevSecOps。
突然之间，我们发现，如果在 DevSecOps 之前，银行安全无法控制开发人员这边发生的事情，那么在新的范式中，安全的控制方式与基础设施上的普通事件相同。 现在才出现关于程序集、库控制等的警报。
剩下的就是将团队转移到新模型。 好吧，创建基础设施。 但这些都是小事，就像画一只猫头鹰一样。 实际上，我们帮助建立了基础设施，当时开发流程正在发生变化。
发生了什么变化
我们决定分小步实施，因为我们知道许多流程会崩溃，许多“外部人员”可能无法承受所有人监督下的新工作条件。
首先，我们创建了跨职能团队，并学会根据新要求来组织项目。 从组织意义上来说，我们讨论了哪些流程。 结果是一张包含所有负责人的装配流水线图。
- CI： Git、Jenkins、Maven、Roslyn、Gradle、jUnit、Jira、MF Fortify、CA Harvest、GitlabCI。
- 光盘： Ansible、Puppet、TeamCity、Gitlab TFS、Liquidbase。
- 测试： Sonarqube、SoapUI、jMeter、Selenium：MF Fortify、Performance Center、MF UFT、Ataccama。
- 企业介绍 （报告、沟通）：Grafana、Kibana、Jira、Confluence、RocketChat。
- 运营 （维护、管理）：Ansible、Zabbix、Prometheus、Elastic + Logstash、MF Service Manager、Jira、Confluence、MS Project。
选定的堆栈：
- 知识库 - Atlassian Confluence；
- 任务跟踪器 - Atlassian Jira；
- 工件存储库 - “Nexus”；
- 持续集成系统——“Gitlab CI”；
- 连续分析系统——“SonarQube”；
- 应用安全分析系统——“Micro Focus Fortify”；
- 通讯系统——“GitLab Mattermost”；
- 配置管理系统——“Ansible”；
- 监控系统 - “ELK”、“TICK Stack”（“InfluxData”）。
他们开始组建一支团队，准备将承包商拖进去。 人们认识到有几件重要的事情：
- 一切都应该统一，至少在传输代码时是这样。 因为有很多承包商，有很多不同的开发流程，每个流程都有自己的特点。 有必要让每个人都适应大约一种，但要有选择。
- 承包商很多，手动创建基础设施并不合适。 任何新任务都应该非常快速地启动 - 也就是说，实例应该几乎立即部署，以便开发人员拥有一套解决方案来管理他们的管道。
要迈出第一步，有必要了解正在做什么。 我们必须确定如何到达那里。 我们首先帮助绘制基础设施和 CI/CD 自动化方面的目标解决方案的架构。 然后我们开始组装这个传送带。 我们需要一种基础设施，对每个人来说都是一样的，并且运行相同的传送带。 银行认为，我们提供了经过计算的选项，然后决定建造什么以及用什么资金。
接下来是电路的创建 - 软件安装、配置。 开发用于基础设施部署和管理的脚本。 接下来是向传送带支持的过渡。
我们决定在飞行员身上测试一切。 有趣的是，在试点过程中，银行中首次出现了某个堆栈。 除此之外，还为试点范围提供了其中一种解决方案的国内供应商，以便快速启动。 保安人员在他驾驶时认识了他，这给他留下了难忘的印象。 当我们决定切换时，幸运的是，基础设施层被替换为 Nutanix 解决方案，该解决方案之前已经在银行中了。 而且，之前它是用于VDI的，但我们将其重新用于基础设施服务。 小批量时，它不适合经济，但大批量时，它成为开发和测试的绝佳环境。
堆栈的其余部分或多或少是每个人都熟悉的。 使用了 Ansible 中的自动化工具，并与安全专家密切合作。 该银行在该项目之前就使用了 Atlassin 堆栈。 Fortinet 安全工具 - 它是由安全人员自己提出的。 测试框架是由银行创建的，没有提出任何问题。 存储库系统提出了问题；我必须习惯它。
承包商获得了新的堆栈。 他们给了我们时间为 GitlabCI 重写它，并将 Jira 迁移到银行领域，等等。
一步步
步骤1。 首先，我们使用了国内厂商的解决方案，该产品连接到新创建的DSO网段。 选择该平台是因为其交付时间、扩展灵活性和完全自动化的可能性。 进行的测试：
- 可以灵活、完全自动化地管理虚拟化平台基础设施（网络、磁盘子系统、计算资源子系统）。
- 虚拟机生命周期管理的自动化（模板、快照、备份）。
平台安装和基本配置完成后，用作第二阶段子系统（DSO 工具、零售系统开发概要）的放置点。 创建了必要的管道集 - 创建、删除、修改、备份虚拟机。 这些管道被用作部署过程的第一阶段。
结果是提供的设备不符合银行对性能和容错的要求。 该银行的 DIT 决定创建一个基于 Nutanix 软件包的综合体。
步骤2“。 我们采用了定义的堆栈，并为所有子系统编写了自动安装和后配置脚本，以便将所有内容尽快从试点传输到目标电路。 所有系统都部署在容错配置中（此功能不受供应商许可策略的限制）并连接到指标和事件收集子系统。 IB 分析了其要求的合规性并给予了批准。
步骤3“。 将所有子系统及其设置迁移到新的 PAC。 重写了基础设施自动化脚本，并以完全自动化的方式完成了DSO子系统的迁移。 IP开发的轮廓是由开发团队的管道重新创建的。
步骤4。 应用软件安装自动化。 这些任务是由新团队的团队领导制定的。
步骤5。 开发。
远程访问
开发团队要求在使用电路时具有最大的灵活性，并且在项目一开始就提出了从个人笔记本电脑进行远程访问的要求。 该银行已经有了远程访问功能，但不适合开发人员。 事实上，该方案使用了用户与受保护 VDI 的连接。 这适合那些在工作场所只需要邮件和办公包裹的人。 开发人员需要大量的客户端、高性能和大量资源。 当然，它们必须是静态的，因为对于使用 VStudio（例如）或其他 SDK 的用户来说，用户会话的丢失是不可接受的。 为所有开发团队组织大量厚静态VDI，大大增加了现有VDI解决方案的成本。
我们决定直接远程访问开发部门的资源。 Jira、Wiki、Gitlab、Nexus、构建和测试平台、虚拟基础设施。 保安人员要求只有符合以下条件才可以进入：
- 使用银行已有的技术。
- 基础结构不应使用存储生产帐户对象记录的现有域控制器。
- 访问权限应仅限于特定团队所需的资源（以便一个产品团队无法访问另一团队的资源）。
- 对系统中 RBAC 的最大控制。
因此，为该细分市场创建了一个单独的域。 该域包含所有开发部门资源，包括用户凭据和基础设施。 该域中记录的生命周期是使用银行中现有的 IdM 进行管理的。
直接远程访问是在银行现有设备的基础上组织的。 访问控制分为 AD 组，上下文规则对应这些 AD 组（一个产品组 = 一组规则）。
虚拟机模板管理
创建组装和测试循环的速度是开发单位负责人设定的主要KPI之一，因为准备环境的速度直接影响流水线的整体执行时间。 考虑了两种准备基础 VM 映像的选项。 第一个是最小图像尺寸，所有系统产品默认，最大程度符合银行的设置政策。 第二个是基础镜像，其中包含已安装的重型POPPO，其安装时间可能会极大地影响管道的执行速度。
开发过程中还考虑了基础设施和安全要求 - 保持映像最新（补丁等）、与 SIEM 集成、根据银行标准进行安全设置。
因此，我们决定使用最少的图像，以尽量减少保持更新的成本。 更新基本操作系统比为新版本的 POPPO 修补每个映像要容易得多。
根据结果，形成了所需的最低操作系统集的列表，其更新由运营团队进行，管道中的脚本完全负责更新软件，并在必要时更改版本已安装的软件 - 只需将所需的标签传输到管道即可。 是的，这需要 DevOps 产品团队拥有更复杂的部署场景，但它大大减少了支持基础映像所需的操作时间，否则可能需要维护一百多个基础 VM 映像。
互联网接入
银行安全的另一个障碍是从开发环境访问互联网资源。 而且，这种访问可以分为两类：
- 基础设施接入。
- 开发者访问。
基础设施访问是通过使用 Nexus 代理外部存储库来组织的。 也就是说，不提供从虚拟机的直接访问。 这使得在信息安全方面达成妥协成为可能，这明确反对提供开发部门对外部世界的任何访问。
出于显而易见的原因，开发人员需要访问互联网（stackoverflow）。 尽管如上所述，所有命令都可以远程访问电路，但当您无法从 IDE 中银行的开发人员工作场所执行 ctrl+v 时，这并不总是很方便。
与 IS 达成协议，最初在测试阶段，将通过基于白名单的银行代理提供访问权限。 项目完成后，访问权限将转入黑名单。 准备了巨大的访问表，其中表明了项目开始时需要访问的主要资源和存储库。 协调这些访问需要花费相当多的时间，这使得坚持以最快的速度过渡到黑名单成为可能。
结果
该项目在不到一年前结束。 奇怪的是，所有承包商都按时切换到新堆栈，并且没有人因新的自动化而离开。 IB并不急于分享积极的反馈，但也不抱怨，从中我们可以得出结论，他们喜欢它。 冲突已经平息，因为信息安全再次受到控制，但不会干扰开发过程。 团队的责任被赋予了更多，信息安全的整体态度也变得更好。 该银行明白向 DevSecOps 的过渡几乎是不可避免的，并且在我看来，以最温和、最正确的方式做到了这一点。
亚历山大·舒宾，系统架构师。
来源： habr.com