随着对微服务和与云无关的应用程序和数据的日益依赖，保持数据安全需要一种新方法。令许多人惊讶的是，只需点击几下鼠标，就可以启动一个服务器集群，准备好处理任何大小的数据。过去，企业需要采购CPU、内存、网络、存储等硬件设备，花费大量资金和精力建设自己的数据中心，将设备接入全球互联网。现在，即使是已经拥有大量数据中心的传统大型组织也在利用云计算技术的简单性和可扩展性。但是云原生环境中的安全性如何呢？基础架构和应用程序是否安全？企业对构建基础架构的看法没有人会从订购服务器开始构建业务。企业首先确定它想要做什么，开发一个系统，然后部署它。不太关心刀片服务器的品牌，但IT系统必须持续运行，它们必须可靠、可用、及时和安全。每个IaaS提供商（无论是AWS、Google、Microsoft还是其他公司）都提供基础设施安全性。通过使用其基础架构，用户将大量安全责任委托给云计算提供商。目前，许多企业认为AWS、谷歌和微软等公司所做的工作比他们自己做的工作更安全。基础设施安全让我们来看看现代计算的分层模型。云基础架构即服务(IaaS)提供虚拟机——内存、存储、处理器和网络。更高级别的服务提供操作系统、编排和对象存储。基础设施的安全功能只能阻止来自其下层的攻击。例如，如果用户选择AmazonElasticBlockStorage(EBS)加密，则实际数据存储上的数据将在操作系统(OS)级别和硬件之间的虚拟化级别进行加密。如果攻击者闯入亚马逊数据中心并窃取硬盘驱动器，将其带回家并将其连接到他的计算机，他看到的只是加密数据。如果网络攻击者远程破坏同一台虚拟机，他可以打开同一EBS卷上的文件并像合法应用程序一样透明地读取数据，因为虚拟化层无法分辨谁在尝试读取信息。这同样适用于其他基础架构级别的安全功能，例如防火墙。如果一个企业有服务器A和B，其中B是A的客户端，可以通过定义防火墙规则来限制对正在运行的服务器A的访问，只有服务器B可以访问。因此，侵入服务器B的攻击者可以很容易地获得对服务器A的访问权限。一般来说，如果攻击源在保护层之上，则其安全防护是无效的。鉴于攻击主要来自应用层方向，基础设施层面的保护只能提供部分安全。虽然基础架构可以限制应用程序级别的活动以防止不必要的行为，但结果将非常紧凑且维护成本高昂。这意味着它的边界太宽而无法提供足够的安全性，或者太窄而无法维持云原生世界的安全。真正的应用程序安全神话如果应用程序能够保护自己，那将是迈向全面的云原生安全的一大步。当然，业界并不认为应用程序是需要保护的东西，并且已经开发了许多基础架构安全功能来解决这个问题。此外，自我保护应用程序难以配置和维护。他们的安全级别无处不在。事实上，在这种类型的环境中很难实现真正的应用程序安全，因为它们可能有不同的版本，它们可能来自不同的来源。当SSL/TLS不起作用时该安全协议实际上是保护TCP连接的行业标准，是在1990年代开发的。虽然它的设计堪称典范，但对本次讨论的主题而言重要的是传输层安全(TLS)连接被设计为在浏览器应用程序和Web服务器软件之间创建。它不是基础设施功能，甚至不是网络驱动程序功能。这是一个纯粹的应用程序级功能，这意味着理想情况下只有应用程序才能访问通过线路发送的数据。随着时间的推移，服务器端传输层安全(TLS)产品不断发展，例如RSA的传输层安全(TLS)服务器终端硬件。TLS终止已成为一种常见的做法，这意味着当传输层安全(TLS)连接到达反向代理软件或硬件时，其唯一目的是取消保护连接并将其转发到正确的未受保护的Web服务器。为什么要这样做？一方面，它不是那么安全，但很难在服务器园区内维护TLS证书和密钥。当内部服务之间的通信也必须受到保护变得很明显时，不同的云供应商会有不同的答案。Istio解决方案，例如独立于云的解决方案和其他解决方案附带的解决方案，在受保护的应用程序旁边放置了一个额外的容器，可以像Web服务器一样执行传输层安全性(TLS)终止，但这种方法无效。TLS的使用很差，因为很难配置和维护使用它的应用程序。TLS需要不断的重新配置（证书更新）和密钥保护（它的密钥丢失会危及整个TLS系统）。所有应用程序的配置都略有不同，这使得维护变得困难。当然，有些应用程序根本不支持TLS。当然，这个简单的传输层安全(TLS)示例通过向应用程序添加广泛的安全功能突出了操作问题。此外，业务和应用程序开发都专注于功能。安全是次要的，如果有的话。什么是真正的解决方案？业务驱动的思维推动基础架构内的安全性；它应该开箱即用。在许多情况下这是真的——但基础设施的安全性是有限的。以基础架构为中心的应用程序安全方法也行不通。答案是它的安全性必须在应用程序级别，而不是应用程序的一部分。
