讓很多人都感到驚奇的是，只需點擊幾下鼠標，就可以啟動一個服務器集群，隨時處理任何規模的數據。
在以往，企業需要購買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)示例通過在應用程序中添加廣泛的安全功能突出了操作問題。此外，業務和應用程序開發都集中在功能上。安全是次要的，如果有的話。
真正的解決方案是什么?
業務驅動的思維推動了基礎設施內的安全性;它應該是開箱即用的。在很多情況下是這樣的——但是基礎設施的安全性是有限的。以基礎設施為中心的應用程序安全性方法也不起作用。
其答案是，其安全必須在應用程序級別，而不是應用程序的一部分。
