秋天到了院子里；乌托邦的技术狂暴。 技术正在向前发展。 我们在口袋里携带一台计算机，其计算能力比控制飞往月球的计算机的能力高数亿倍。 借助Youtube VR，我们可以与海with和鲸鱼一起在海洋中游泳，并且机器人一直在探索无生命的寒冷星球。
同时，工程师和IT服务专家，开发人员及其无数的同事分为两个阵营：创建新解决方案（软件，策略，信息系统）的人和了解它们的人。
进入应用程序开发生态系统和使用微服务的方法。 直到最近，这还是一种不可理解的技术，根本无法窥探。 但是今天，仅仅几年之后，大中型公司已经有信心在自己的开发环境中使用这种方法。 他是什么样的人？ 我们不会使用“经典”定义，而是会用自己的话告诉您。
微服务架构。 货柜
微服务是一种方法，其中将一个系统的功能划分为许多小服务，并且每个小服务都从复杂的功能执行一项任务。 一个充当网络服务器，另一个充当数据库，第三个充当其他内容，等等。 在所有这些微服务之间，建立了网络交互，并分配了必要的资源。 这种概念的一个有趣且同样显而易见的例子是在快餐店订购和发行午餐的系统。
客户（用户）使用终端或接待台（Web服务器）创建新订单，传输有关其汉堡中的芝士汉堡，土豆和苏打水类型的数据（填充数据库），付款，然后将数据传输到厨房，其中员工油炸土豆（烹饪服务），另一部分传播食物，倒苏打水（收集服务）。 然后将收集到的订单转移到开票柜台（开票服务），客户在此显示带有订单编号的支票（甚至还有验证！），然后他们给他午餐。 在这种情况下，每个处理单元都忙于一项任务，并且根据一种确定的算法，它可以快速，平稳地工作。 您必须承认，期望接待处的汽水弹出速度快于厨房中的汽水弹出速度，否则油炸小馅饼的员工将能够接受您的订单付款是愚蠢的。 但是，如果对系统进行了正确的调试，并且过程按预期进行，则一切都会真正快速有效地进行。
关于微服务架构，值得注意的是它的执行环境。 如今，容器是一个广泛的选择（嗨，Docker）。 容器的一个特征是将所有必需的环境打包在其中的想法，从轻量级的OS映像，已安装的软件包，已加载的框架和库开始，到应用程序本身结束。 这有什么用？ 至少当您向开发人员发出“应用程序无法正常工作”的消息时，开发人员将无法拒绝“我的计算机上的所有程序”的解释。
容器使您可以创建应用程序，将它们与整个环境打包在一起成为轻量级系统的现成映像，而不必担心与在各种环境中工作相关的问题。 需要将应用程序部署到另一台服务器吗？ 我们在容器中启动了一个工作图像-一切正常。
在使用容器构建的信息系统中，您不再需要担心应用程序正在运行的环境中的软件版本，并且在实现连续交付过程的同时，您还需要交付代码等。容器的概念意味着开发本身该应用程序在相同的容器环境中运行，并且由于微服务已关闭，因此它在哪个操作系统上运行或与哪个安装包无关。 该应用程序之所以能够运行，是因为它是为容器环境创建的，无论容器周围的系统如何，该环境都不会改变。 您不再需要花费大量的时间来安装所有必要的软件来建立连接，依赖关系和程序包。 在开发和部署环境之间移动或计算中心容量增加时，无需手动迁移应用程序。 出现了一个新的抽象级别，它在最终软件及其用户和主机环境（虚拟或裸机）之间发挥了作用，所有这些工作都在此环境下进行。 由于其便利性，该方法正在稳步发展，并且不会减慢速度。
许多大型组织都努力采用最佳技术来提高业务效率，其发展，可伸缩性和转换，包括在信息系统中。 毕竟，正是针对大型，面向数字的企业，他们主要对旨在灵活性，可扩展性和移动性的解决方案感兴趣，因为在改变行业时，它容易受到与扩展，适应不断变化的市场等相关的困难。不一定与IT公司有关。 在CI / CD问题及其安全性的背景下，公共部门的公司，主要的金融市场参与者（例如银行）甚至物流垄断企业都向我们的组织求助。 在所有情况下，一件事将它们结合在一起-开发应用程序，服务等时以一种或另一种形式使用容器。
大生意常常被比作鲨鱼。 在这种情况下，很难进行更合适的比较。 您是否看到鲨鱼如何捕食鱼类？ 您是否注意到即使是大群的小鱼也有更多的可操纵性？ 谁对鲨鱼或小鲭鱼有更敏锐，更机动和更快的反应？ 整个市场中的公司也是如此。 当然，当Microsoft或Apple装进车库时，我们不会考虑它们是孤立的情况。 但是从统计学上讲，大公司能够决定趋势并设定方向，但是，小公司更容易快速适应和适应。 大型公司还试图以负担得起的方式提高移动性和灵活性。
但是，正如他们所说，这是有细微差别的。事实上，大公司并不是垄断者。 他们由许多部门组成，有许多部门，团队，部门以及更大的员工群。 特别是在信息系统和发展的背景下，团队的行动领域可能会重叠。 正是在这个交界处，IS服务和开发人员之间出现了那些冲突情况。 也就是说，事实证明，大型和中型企业都不能幸免于难。
迟早使用容器时，组织将有一个问题。 这种情况可能在使用之初就发生，也可能在某些事件发生后发生，因此，公司将蒙受损失。
如何使流程安全？
以一种或另一种形式，我们经常听到这个问题，并与客户一起思考解决方案并寻找合适的方法。 通常，一个组织，尤其是已实施CI / CD的大型组织，由聪明又有经验的专家组成，包括信息安全领域的专家。 这些人知道为什么需要使用微服务，它将解决什么问题以及将会出现什么新的困难。 因此，他们采取措施成功实施和使用技术：准备基础架构，进行审核，部署系统，构建流程并协调内部法规。
但是，并非总是可以预见所有内容，跟踪所有内容并监视所有内容。 例如，这是如何了解容器中SQL Server的版本是否包含严重漏洞的方法？ 手动吗？ 比方说 如果有几十个容器？ 还有几百个？
信息安全专家如何确保应用程序容器中的基本OS映像不包含隐藏漏洞？ 手动检查？ 究竟要检查什么，在哪里看？ 在所有数十个和数百个容器上？ 在哪里获得这么多时间和资源？
随着CI / CD的开发和发行，开发周期中的安全性问题变得更加尖锐。 毕竟，您需要确保至少在可接受的图像质量水平上，需要了解软件和软件包的漏洞，工作容器的状态以及其中是否进行了可疑或明显不合法的操作。 而且，如果我们专门讨论开发周期，那么值得拥有一些工具来确保开发过程本身，开发流程中的安全性，而不仅仅是容器中的安全性。 您还需要控制机密，注册表审核，网络交互控制等。 在这里，我们谈到主要问题。
为什么需要安全性，CI / CD中有什么功能？
从本质上讲，这是确保开发周期内和周围安全的一组实践。 也就是说，它是使用特殊软件，开发方法和法规，甚至是团队准备（团队是一切的关键！），以确保安全。 重要的一点是：将所有这些安全性合理地引入开发中，而不是从肩膀上掏腰包！
在这里，我们将详细介绍。 我想到的通常是IT安全的通用方法，尤其是在开发中，是基于“禁止/限制/阻止”的原则。 到目前为止，最安全的信息系统根本无法使用。 但是它必须工作！ 使用此系统的人也应该可以使用它。
上面提到了利益冲突。 信息安全专家寻求使环境安全并希望对其进行完全控制，开发人员希望制造产品并希望其快速便捷地发生，而IT工程师则使环境可行，容错，并与开发人员一起努力实现自动化。
CI / CD中的保护与软件或法规无关，而与团队合作和将安全概念嵌入开发流中有关。 这种方法旨在使所有参与者平等参与这一过程，明确职责范围的分配，实现自动化，监测和透明的报告。 最重要的是，要以一种在早期阶段就出现的方式来实现应用程序开发过程中的安全性，而不需要分配计算和人力方面的额外资源。
让我们看一个例子。 假设其中一个开发团队创建了一个应用程序，它发生在容器介质上，在信息安全专家的监督下进行，而基础架构经理则维护了该环境的健康。 在开发结束时，将出现一个现成的应用程序，该应用程序进入生产并开始在那里工作，客户使用它-每个人都很高兴。 但是一段时间后，在带有应用程序的容器中发现了一个严重的漏洞。 一名信息安全专家注册了此漏洞，并将其传递给开发人员以消除该漏洞；然后，他们使用补丁程序对其进行了修复，然后您必须重写依赖关系并更新某些程序包。 然后，推出该应用程序的下一个版本。
IS专家用于定位问题的时间，开发团队解决该问题的时间，以及IS服务将进行第二次审核并结案的时间。 但是，如果我们可以使用某种工具并在开发阶段实施它，该怎么办？ 如果在给定的安全级别上不适合我们的应用程序，但该应用程序没有部署到产品中怎么办？ 每个参与此过程的专家都可以看到在其职责范围内发现了哪些威胁？ 但是，如果整个过程也将自动化（从检测开始到在错误跟踪器中结束事件），该怎么办？
这是组织安全开发和实施的目标。 不仅安全，而且方便。 引入新流程或使用其他工具应简化活动，反之亦然。
有一些工具和技术可让您监视必要的系统元素和开发过程阶段的状态，并帮助所有相关方及时了解其职责范围内的事件。 这里的重点不是专门的软件，而是人们与系统以及彼此之间的交互。 开发人员在工作容器内修复和测试应用程序是否更方便？ 好吧，让他修复它。 同时，IS服务希望确保容器内没有非法行为？ 没问题，她会知道的。 任务已完成，在此过程中没有人干预任何人。 高效合理！ 如果您在开发环境中的正确位置应用必要的信息安全工具并修改服务与团队之间的交互规则，则这是可能的。 然后不要有乌托邦，但您必须同意，与两者生活在一起会变得容易一些。
如果您可以构建流程，以便开发人员尽其所能（无私地为完善自己的代码而精疲力尽），并且IB专家控制此过程（不干涉，而只分享这种乐趣），为什么还要束缚开发人员的手，并向其中加载IB服务。从侧面）。
集装箱安全。 值得吗？
客户在完全不同的阶段与具有不同CI / CD经验的客户联系。 有一些大型组织在生产中的容器中面临未被检测到的后门，通过这些后门可以获得对重要数据的访问并窃取了数据。 结果，显而易见的是，在一个过于繁杂且繁琐的系统中，很难跟踪并预防性地消除潜在威胁。
还有一些小公司最近在开发中使用CI / CD。 在分析了管道中的流程之后，他们的专家得出的结论是，可用的信息安全工具覆盖了不足的流程量，并且在危险的地方迟早会发生攻击。 也许不是现在，也许是以后，或者根本没有。 但是，如果发生这种情况，错误的代价将很高。
我们的客户有共同的忧虑，在大多数情况下，这都归结为在试图超越时限时击败开发人员，工程师和过程中涉及的每个人的想法。 但是有时候这样做会更容易，更快捷，在某些情况下通常是相反的。 然后，IS服务必须通过手指查看违规情况。 但是，我们是一个不同的概念。 为什么要违反或忽略如此痛苦的法规？ 服务为什么要相互干扰才能完成任务？ 在与客户合作时，我们开始与他的问题进行沟通。 他们总是在那里。
“不要寻找客户，发现问题并提供解决方案-客户会亲自出现。”
通常，在听取客户的意见后，我们了解他们面临的问题。 这可能是团队互动中的困难，“管道”设计中的决策失败，缺乏计算和人力资源，还有更多。 在客户基础架构中实施安全性增强的方法中，我们始终以帮助解决客户的问题并以最大程度减少新问题的方式实现这一愿望为指导。 因此，创建了未来的基础，由谁来服务创建的系统无关紧要，一开始就应该预见并解决许多问题。 在早期阶段，大多数情况下，决策要比深度生产中的高工作负载便宜。
基于所有这些，我们建议从审计开始，该审计不仅包括信息系统的状态及其要素，而且还包括对开发团队之间的流程组件，信息安全服务方法等的理解。 不要忘记，就威胁和系统功能的结果而言，人员是最重要的因素。 审核是必不可少的步骤，因此可以发现与我们试图解决或处理的客户一起发生的重要系统缺陷或交互错误。 重要的是要了解，目标不是堆积许多软件解决方案和产品，也不是掩盖它们发现的漏洞。 相反，很可能根本没有必要购买昂贵的软件产品。 通常，可以在组织现有的安全功能的帮助下实现CI / CD环境中提高安全性的过程，这些功能既内置在容器化环境中（例如在协调器中），又内置于第三方。 重要的不是它们的数量或质量，而是正确的应用。
根据审核结果，可以创建工作计划，具有明确的中间任务和易于理解的最终目标的路线图。 好吧，一切都在技术上。 任何业务的正确计划都是成功完成工作的重要组成部分。
重要的是不要太着迷，也不要忘记一切都做好了。 没有人要创建一个受疯狂保护的系统，在其中检测到任何威胁时都不会启动容器，或者如果与受保护模型有任何偏差，则不会在生产中部署任何应用程序。 值得记住的是，引入或启动保护工具不仅可以提高安全性，而且还可以提供便利。
例如，其中一种情况涉及引入容器保护软件和业务流程环境。 看来他们实施，配置，扫描了所有漏洞，然后才找到了消除漏洞的漫长过程。 但是，使用这种方法会出现问题，因此一开始就进行了讨论。 信息安全服务提供了一个工具，使您可以阻止业务流程环境中的许多活动，如果使用不当，则会弊大于利。 开发人员束手无策，因为信息安全服务正在缩减其功能。 例如，不再可能在“热”状态下修复容器中的东西，并且当在图像中检测到包装漏洞时，开发人员将参与监管机构。 结果，无限期地延迟了可以在白天消除的问题的解决方案。
为避免这种情况，我们建议流程的安排应使IS服务不会像通常那样脱离开发流程，而应参与其中。当然，这需要一些时间，但是值得调试该过程，而且生活确实变得越来越容易。例如，IS工具使您可以在CI / CD管道内部的组装阶段监视威胁，并且IS服务可以注册此威胁。同时，有关装配各个阶段威胁的信息可以自动转移到负责特定阶段的团队或专家，而他又将采取必要的措施消除威胁。所有这一切都不是在鞭子的监督下发生的，而是在IS服务的监督下发生的。最终，可以大大减少解决漏洞所需的时间，并因此减少商业成本，例如财务或声誉方面的成本。利用任何初始数据，我们努力形成一种组织和提高集装箱开发安全性的方法，不仅着眼于特定解决方案的设计和实施，而且着眼于人力资源。该过程中的每个参与者都履行其职责，并且越方便，不必要的干扰越少，其最终结果就越好。而且，如果您在所有参与方之间的便利之间找到平衡，那么您将获得一个非常有效的团队。当然，将来可能会进行各种优化，应用或增加某些过程的自动化，任务委派等，但是主要思想仍然没有改变，即对安全性的修改。职责分离，监督而不是无意识的禁止以及每个人在其职责范围内的参与。当然，方便！安全可以很方便。