每天生成大量数据。你能处理你的DevSecOps过程吗？

从 DevOps“向左移动”到DevSecOps

当使用瀑布式方法的开发团队无法满足客户的需求时，采用了DevOps和敏捷的SDLCs。这种灵活的方法试图满足客户的需求，但安全流程落后。你跳过安全，或者你不太敏捷。不管怎样，你会失去迅速适应客户需求的优势。

现在，新法规和消费者意识已将隐私和安全作为优先事项，业界认识到必须在SDLC上部署。向左移动传统上意味着将最后发生的过程和测试集成到开发过程本身中，经常听到描述从DevOps到DevSecOps的转换的术语。

DevSecOps通常从一开始就被描述为在SDLC的所有阶段内置安全性的声明。

DevSecOps认识到安全也是所有团队成员的责任，但排名前40位的计算机科学程序不需要安全类。开发商也没有准备好改变。那该怎么办？

这是一个基本问题，但如今天所述，DevSecOps只是软件和应用程序开发的思维方式。数据是所有安全战略的主要驱动力吗？为了保持敏捷性，必须从一开始就为SDLC设置安全性，数据(和数据处理)也必须成为此次对话的领导者。

谈谈“机器规模”数据

每天制作2.5兆字节的数据，这个数字还在增加。指数级。不再是人们制作这些数据。我们制作的应用程序是快速增长的贡献者。Nest生成了多少数据？你的Fitbit怎么样？

这么多数据正在生成，无法与人扩展手动工作。这些字节汇总在数据池中，以便机器理解，但这一步显然是不可能的。我们开发了一种算法，可以在几秒钟内推理复杂的输入，但随着数据激增，我们的耐心也在下降。应用程序延迟时，容差是多少？就像玩四五年前生产的国产手机一样，吃卡很特别，想用，但又无从下手。

接受“机器规模”数据意味着承认我们需要自动化。我们需要正确的技术工具来处理大规模的数据。再有经验的人也不能像生成的数据一样快速处理这么多数据。我们要消除人为错误，这是信息流的瓶颈。

机会和威胁

挖掘戴尔生成的大量数据有助于提高业务智能、知情决策和客户服务。利用机器规模的数据，可以带来操作员的进步和市长/市场部门的改善，当然也要看到这个数据。

数据池一直是大公司能够承受存储和处理海量数据的庞大基础设施的领域，但云工具和IaaS已经可以广泛使用该技术，目前国内有阿里云、华为云、百度BAE平台、腾讯云等。从大量数据中获得相当大价值的机会对中小企业来说是可以承受的。所有规模的组织现在都在云中移动、存储、处理和处理数据。

毫无疑问，你对这种危险很了解。数据不再保留在网络范围内。即使外设安全性很好(可能没有)，数据也不再存在。

除了在云中管理数据、在多个云中或与Office环境相结合的复杂性外，数据聚合本身也有令人毛骨悚然的方面。经纪人通过数据、市长/市场、交易位置和个人信息，可以在机动性目标上找到从这些关联中得到的观点，并发生了很多不知道但可怕的事情。

国家的一些规定和公司共同规定的出现反映了对隐私和安全的这种威胁。这些法规对不知道如何使用数据，无法锁定数据使用方法的企业构成了巨大的风险。但是，这些法规还提供了一个机会，可加快安全工具和流程的“左移”，从而涵盖整个DevOps生命周期。

在机器规模的世界里，如何保持敏捷？

我将回到保持敏捷但保持安全的第一个任务。您如何处理数据？为了保持灵活性，同时最大限度地减少风险和法规遵从性开销，需要一套标准。需要的是：

l了解数据。如果不知道什么是访问，如何保持法规遵从性？这个字节包含什么？这需要自动发现所需的工具和可扩展的数据识别存储。l了解消费者。这包括用户、服务和设备。谁(或什么)正在访问这个字节？访问某个数据时，对消费者的理解是什么？怎么消费？这需要消费者身份存储，以便与身份提供者、目录和计费系统轻松集成。(相当于产品经理的角色。)了解l上下文。何时、何地、如何

对DevSecOps意味着什么？

DevSecOps表面上是让安全成为整个过程的一部分，从一开始就这样。但它不讨论数据处理，它需要。静态扫描很重要，但你不能一直告诉你的开发人员只检查应用程序安全测试结果，希望这能教会他们如何编写更安全的代码。因为不是。

记住你需要安全性的原因-数据-记住它带来的机器规模问题。需要将可伸缩的数据处理技术构建到框架中，作为任何数据生产、存储和访问解决方案的自动化部分。

我介绍一个使用低级运行库的类比：如果我在每个应用程序中都包含libgcc，然后发现它有一个bug，那么我必须进入并重新构建我的每个应用程序。每次申请我都得回顾整个SDLC。数据处理策略提出了同样的挑战：如果我对应用程序进行编码以满足GDPR需求，那么CCPA就会出现，每个应用程序都必须重新构建、重新测试和重新部署。如果只有两到三个应用程序，也许这没啥，但我所说的大多数企业都有成百上千个应用程序。只是映射哪个应用程序访问哪些数据会导致程序员发疯。现在考虑在每个策略中重做硬编码策略。

实际的答案是：从应用程序代码中抽象数据处理。允许您的策略使用我前面调用的数据和消费者标识存储，及时适应请求的上下文。不必编写代码就可以做到这一点；外部化策略引入了在这个机器的世界中生存和发展所需的规模。

也可以使用市场上已有的技术拼凑出这一解决方案，但这将耗费大量时间，而且成本很高。一种更实用的方法是利用SDK和API集来解决今天已经存在的解决方案。DevSecOps专注于通过正确的工具和过程实现自动化和敏捷性。它应该包括消除程序员在竖井中理解、编码、测试和维护数据保护的需要。不要让你的软件工程师每次都为每个应用程序重新设计策略和数据处理规则。让他们专注于业务核心的特性和功能。

MAWAN解决了上面提到的四个标准，我认为在保持数据敏捷性、最小化风险和遵从开销以及最大化运行时可见性时，必须考虑数据保护。它的外部决策引擎对数据的属性、数据使用者的身份和请求本身的上下文进行推理。每一次数据访问尝试——以及由此产生的策略决策——都会被记录为一个完全可审核的链。Machina帮助使安全成为Dev和Ops规程的一个组成部分。

感谢您看完，记得关注哦。