多年来我们一直在采用新技术来寻找系统构建过程中的改进办法，因此如今的IT基础设施可谓是经历了重大的演变。为了迎接新技术的到来，遗留技术常常需要与新技术结合在一起，但这种结合并不是水到渠成的。在整体解决方案中，超现代与传统之间相互融合的阻力使过去和未来之间的关系剑拔弩张。
云的多租户共享基础架构、Docker和Kubernetes等容器技术，以及像微服务和无服务器这样的新架构，在技术层面上可以说是引人注目的，但同时也增加了复杂性。复杂性是安全的头号敌人。因此，我们需要一种并不依赖于将基础设施作为控制点的新的安全方法。而像思科和VMware这样的公司，都在扩展他们的解决方案，以覆盖容器网络和安全。
IT环境的挑战
管理员对云的控制力很有限。启用云服务可以控制现有的静态环境——这些静态环境以前由本地管理员控制，具有良好的边界和传统的安全构造。而原生云技术对传统的安全边界是不可见的，传统的安全控制(如IP地址过滤和防火墙上的ACL)已不再有效。
经典的三层架构现在经常被分解成许多不同的应用程序编程接口(API)，它们都在共享环境中运行。微服务架构消除了显式的入口和逸出点。现在，服务之间的通信是通过许多不同的内部和第三方API以公开的网络调用和服务进行的。API是新资源，所有服务现在都响应API调用。
IP地址的挑战
在这个快速发展的环境中，IT组织在维护传统IP地址和ACL入口的尝试中面临挑战。现代的动态基础设施通过假定一个相对静态的配置，使现有的网络安全方法失效。ACL表变得越来越大，最终变得非常复杂，以至于几乎不可能有效地进行管理，而且它们的处理进程会影响主机性能。层4与网络拓扑结构耦合，缺乏支持敏捷型应用程序的灵活性。此外，将网络地址转换(NAT)引入到数据路径中，消除了端到端可见性，这增加了连接的第二个问题。使用IP地址有效地识别和保护应用程序端点是一项挑战。因此，也可以说IP识别“蒙上了管理员的眼睛”。这时你有两个选择：你可以信任网络来完成它的工作，不需要对它进行任何控制，也可以引入一种新的方法来进行资源识别和控制，从而减少对IP地址的依赖。
应用程序标识和政策
IP地址就像家庭住址，为你的房子创建了一个物理标识。我们使用IP地址作为网络计算资源身份的代理，但是直到此时我们还没有一个可靠的方法来有效地标识实际的端点。你对一个人了解得越多，那个人的身份就越丰富。并不仅仅是了解一个人的名字、身高、体重或年龄，而且，你肯定不能只通过他们的家庭住址来了解他们。身份的概念对于在现实世界和网络中发生的每一种授权和身份验证通信都是必不可少的。每当有交互时，你需要建立标识并安全地授权和验证连接。交互可以是用户、应用程序或API之间的任何通信组合。
在零信任的云环境中，你必须假设任何东西对于任何人在任何时刻都是可以访问的，在网络交互过程中，应用程序组件需要额外的安全性。仅仅免受外部威胁是不够的，还需要加强防范内部漏洞和配置错误。如果一个工作负载产生一个特定的标识，应该是安全签名，这样就没有机会篡改它的标识。作为流程的一部分，当端点呈现给另一个端点时，它应该使用用于建立信任的证书来显示已签名的标识。云原生应用程序是有弹性的，并且根据需求动态增长。应用程序的动态特性需要一种新的持久特性。传统上，应用程序配置了IP地址，但是在没有对基础设施进行控制的动态环境中，IP地址不再是识别应用程序的可靠或持久的方式。但是，如果你给应用程序、服务或API一个持久的标识，你就可以识别它是谁。
为什么这个很重要?策略创建需要授权和对试图沟通者的身份验证。传统的编写策略的模型基于IP地址，但是由于IP地址不再是持久性的，所以如果在规模上构建策略并非不可能，那么它就会变得非常费力。具有稳定的身份范式和可靠的身份应用程序组件(如容器、微服务或API)的能力，安全策略可以与应用程序一起分发，以实现规模和独立于网络的实时执行。持久的和经过验证的身份可以减轻跨动态工作负载的策略执行，并在多个环境中实现统一的安全性。
可见性
当你检查网络时，会有一个同时具有源和目标的流。源是基于子网的，它被分配给一个工作负载，例如前端或后端层。在检查云中信息的流时，你无法找到发送者和端点试图进行通信的原因。云应用程序的采用放弃了对正在实例化应用程序的基础设施的控制。从可见性的角度来看，你没有持久的标识或有意义的方式去跟踪服务到服务之间的通信。但是，如果你给一个应用程序一个持久的身份，就可以快速地找出谁是前端或后端层，以及他们为什么试图通信。持久性标识提高了网络中的可见性和一致性。
应用程序标识
工作负载可以用几种方式封装，比如虚拟机(VM)、裸金属或容器。容器安全解决方案必须以一种独特的方式评估工作负载。如何保护工作负载是一个次要的概念。然而，封装的方法是微不足道的。
容器安全解决方案应用程序标识应该将安全性与网络和基础结构分离开来，以使其能够伸缩。这种方法使策略与实际的工作负载标识绑定在一起。使用细粒度的、统一的安全策略来保护工作负载简化了安全模型，而不需要对业务逻辑或网络配置进行任何更改。现在，应用程序和组件之间的所有通信都可以通过身份验证、授权和透明加密。因此，这些解决方案完全保护了应用程序，并消除了网络内的任何未经授权的横向移动。
由于安全策略的执行不再依赖于IP，因此关于以网络和以边界为中心的安全性的挑战不再是一种不利因素。例如，如果数据库工作负载脱机并返回一个不同的IP地址，这不再是什么大事，因为工作负载现在已具有从元数据或其他环境变量中提取的持久标识。
如何搭建?
当一个受保护的工作负载通过Docker、Kubernetes或作为一个程序在主机或VM上完成实例化时，安全解决方案必须检查工作负载的所有相关属性，以建立资源的唯一应用程序标识。
有各种各样的元数据和安全信息来源用于建立应用程序标识的上下文，可以来自操作系统本身，例如systemd和与操作系统环境变量相关的元数据。如果是一个主机上的进程，它们可以检查通过CLI命令或systemd进程发出的环境变量。除此之外，数据还可以从其他可用的数据源中提取，比如来自云服务提供商的身份证明文件(ID)文档、关于应用程序的CI/CD管道元数据、来自内部或第三方漏洞扫描器的漏洞信息以及运行时观察到的威胁行为信息。
在应用程序通信中嵌入多属性标识是可行的，这可以通过截取用于在组件之间建立网络连接的三次握手来实现。一个模块可以位于应用程序TCP/IP栈的前面。然后，身份组件被注入到SYN和SYN-ACK数据包的TCP选项中，使它们能够独立于基础设施。作为三次握手的一部分，可以嵌入一个JSON Web Token来交换用于建立和执行策略的多属性标识。当传入的连接请求出现时，前端模块检查传入请求的标识，检查策略以查看是否允许通信，并简单地删除连接，而接收方永远不会看到预期的连接。接收方被隐藏在所有类型的恶意探索中，如无根据的连接、攻击探针或攻击者的扫描。
到现在为止，我们已经讨论了控制网络层的访问，即TCP层，但是超文本传输协议(HTTP)层又如何呢?在微服务环境中，典型的资源是API。在这种情况下，可以部署在堆栈中运行更高的HTTP代理。例如，一个服务公开了一组具有特定范围的统一资源标识符(URI)。在这种保护API的场景中，这个用例扩展到了那些试图使用API或服务的用户。现在，它是一种服务对服务、用户对服务和服务对用户的连接，根据策略允许的用户和服务标识的组合进行了身份验证和授权。
HTTP代理扩展能力超出了网络访问控制，达到了其中身份可以是用户或服务的API访问控制。
为了充分接受应用程序分解和云原生应用程序带来的好处，为资源建立一个独特的应用程序标识，以确定如何识别和保护应用程序端点。这需要技术和心态的改变。
使用网络作为安全控制点的旧方法不仅在操作上具有挑战性，而且还具有安全隐患。应用程序身份与分布式策略实施模型的结合，创建了一个安全范例，可以有效地在任何基础设施上实现统一的安全性。