DevSecOps和机器规模数据
每天生成大量数据。你的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 了解上下文。何时、何地以及如何访问数据？为了什么目的？这需要灵活的决策引擎来确定访问是否表示根据策略适当使用信息。
- l 审核链。能否以自动化的方式提供何时、何地、由谁以及由于什么原因访问了一段数据？你能证明你遵守法规吗？这需要更多的数据在我们的机器规模的世界，容易消费，预包装，如果可能的话。可行时加密；始终控制和审核。
对DevSecOps意味着什么？
DevSecOps表面上是让安全成为整个过程的一部分，从一开始就这样。但它不讨论数据处理，它需要。静态扫描很重要，但你不能一直告诉你的开发人员只检查应用程序安全测试结果，希望这能教会他们如何编写更安全的代码。因为不是。
记住你需要安全性的原因-数据-记住它带来的机器规模问题。需要将可伸缩的数据处理技术构建到框架中，作为任何数据生产、存储和访问解决方案的自动化部分。
我介绍一个使用低级运行库的类比：如果我在每个应用程序中都包含libgcc，然后发现它有一个bug，那么我必须进入并重新构建我的每个应用程序。每次申请我都得回顾整个SDLC。数据处理策略提出了同样的挑战：如果我对应用程序进行编码以满足GDPR需求，那么CCPA就会出现，每个应用程序都必须重新构建、重新测试和重新部署。如果只有两到三个应用程序，也许这没啥，但我所说的大多数企业都有成百上千个应用程序。只是映射哪个应用程序访问哪些数据会导致程序员发疯。现在考虑在每个策略中重做硬编码策略。
实际的答案是：从应用程序代码中抽象数据处理。允许您的策略使用我前面调用的数据和消费者标识存储，及时适应请求的上下文。不必编写代码就可以做到这一点；外部化策略引入了在这个机器的世界中生存和发展所需的规模。
也可以使用市场上已有的技术拼凑出这一解决方案，但这将耗费大量时间，而且成本很高。一种更实用的方法是利用SDK和API集来解决今天已经存在的解决方案。DevSecOps专注于通过正确的工具和过程实现自动化和敏捷性。它应该包括消除程序员在竖井中理解、编码、测试和维护数据保护的需要。不要让你的软件工程师每次都为每个应用程序重新设计策略和数据处理规则。让他们专注于业务核心的特性和功能。
MAWAN解决了上面提到的四个标准，我认为在保持数据敏捷性、最小化风险和遵从开销以及最大化运行时可见性时，必须考虑数据保护。它的外部决策引擎对数据的属性、数据使用者的身份和请求本身的上下文进行推理。每一次数据访问尝试——以及由此产生的策略决策——都会被记录为一个完全可审核的链。Machina帮助使安全成为Dev和Ops规程的一个组成部分。