安全是一個多層級的話題，包括物理、硬件、引導、存儲和其他方面。本文只探討數據中心工作負載的訪問控制。

幾乎所有企業數據中心里都有很多防火墻/VPN設備，但是Google的數據中心沒有。Google是如何做到不部署傳統的防火墻，還能對其數據中心應用做到訪問控制的？

從技術方面得出的答案是Google將訪問控制、身份驗證和授權部署到應用層，而不是在網絡層，Google通過這種方式有效的在應用程序中進行訪問控制，而不是在網絡層去實現。

Google的這種方式保證了訪問控制的穩定性、可移植性、可伸縮性：app-to-app，service-to-service數據中心內部訪問控制不再依賴于在正確的時間正確的地點的人類或者腳本。它是基于應用程序身份的控制，而不是網絡代理的身份控制；也沒有更容易出錯的“after-thought”應用人員和運維人員的協調。

盡管有眾多的好處，圍繞應用級安全控制和網絡級安全控制依然存在著辯論。從行業發展史上看，企業數據中心選擇的是“after-thought”網絡級安全模型，因為它對傳統的環境有意義；大多數數據中心運行打包軟件，工作負載信任他們的內部網絡，并且實現了有責任的分離。

盡管以應用為中心的模式在過去不符合企業的需求，但是現在已經有了相當程度的改變，云本地的應用將改變企業數據中心安全工作負載的方式。

1、內部自定義軟件將控制數據中心：傳統上，企業數據中心運行大量的打包軟件，企業可以采取實際的方式從包的外部軟件來保護這種類型的工作負載。但是，企業將傳統的打包軟件轉換成軟件即服務（SaaS）消費，因此安全打包軟件不再是內部網絡的需求。企業將運行卓越的內部開發定制軟件，對他們的業務進行差異化經營。對應用來說，“baked-in”安全是一個極其可行的方法，因為企業擁有這些應用的代碼和設計。

2、內部安全與周邊安全重要性等同：傳統的企業工作負載通常有一個信任的內部網絡，不需要對單個的工作負載做訪問控制，因此傳統的營銷或微營銷技術更適應應用案例。Google的安全需求是基于“零信任”的，它不能保證內部網絡比公共網絡更加安全，傳統的基于網絡的接入控制不能滿足這種規模的需求。但是企業開始在內部安全和周邊安全上投注更多的心力：究其原因是“內部”可能駐留在共有云或混合云上。基于應用的“baked-in”模型將更可取，因為它具備高可擴展性和可移植性。

3、企業廣泛采用DevOps：傳統上，開發和運維之間的職責是分離的，這就劃清了開發與運維之間的界限，“after-thought”網絡安全模型實際上更適應日常工作流程。盡管一些職責的分離會得到保留，DevOps將會促進開發人員參與安全保障。應用程序生命周期的變化率急劇增加，在Docker和微服務中可見一斑。基于網絡的“after-thought”的方法跟不上變化的腳步，基于應用的安全就必須得到加強。

現在的網絡采用的是“after-thought”安全模型，并且在過去的二十年中為整個行業提供良好的服務。隨著云原生應用的出現，云計算被廣泛采用，以及積極擁抱DevOps，企業將會尋求能與云計算原生波長相匹配的安全模式。從“after-thought”到“baked-in”的安全模式的轉變不會一夜之間就實現，它是一個量變引起質變的過程，但是在云安全產業仍然有一些激動人心的變化。

原文鏈接：https://www.sdxcentral.com/articles/contributed/cloud-native-security-paradigm-shift-2/2016/07/