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