雷鋒網按：基礎設施即代碼（IaC）將成為本文重點討論的對象，它的出現(xiàn)，源自云原生時代不僅是開發(fā)者體驗的核心，也是補齊云原生體系的最后一塊版圖。

近年來，DevOps 在云原生領域越來越朝著自動化方向演進。基礎設施即代碼（IaC）現(xiàn)在通常用于啟動服務器、自動配置、設置存儲和跨服務應用標準網絡功能。使用新的工具和能力來簡化整個應用程序生命周期的操作，開發(fā)團隊顯著提高了其部署的敏捷性。

但是，在這種新范式中，誰對安全負責？更多的工具提升了開發(fā)人員全周期的所有權。然而，應用開發(fā)人員有很多事情要負責。此外，他們沒有一個完整的窗口來了解細粒度的漏洞、以及每天出現(xiàn)大量新的合規(guī)性要求。IT 安全工程師通常不了解不擴展的 DevOps 工具連續(xù)體的復雜性。如果沒有更好地協(xié)作，強大的云原生命令可能會失控，需要修復。

Oak9 的聯(lián)合創(chuàng)始人兼 CPO Om Vyas 在最近的采訪中，談論了他們團隊如何應對云原生部署環(huán)境下安全性的問題。按照他的說法，安全需要為 IaC 采用與 DevOps 相同的自動化策略。

云原生中的 IaC 問題

十年前的軟件交付方式與如今大有不同。部門之間往往是孤立的，IT 和運營部門只能管理本地部署的硬件。這使得工程師能夠使用防火墻鎖定一切以控制運行時環(huán)境。同時，IT 可以更直接地控制訪問、網絡策略、數(shù)據流和通信邊界。

快進到如今的云原生架構，工程師擁有觸手可及的巨大能力。開發(fā)人員可以通過使用 Terraform 立即啟動像 EC2 這樣的實例，用編輯器管理 Kubernetes 上的計算集群，調用無服務或其他各種功能。在引入新功能時，如果基礎設施自動化正在改變現(xiàn)有架構，那么安全實施是什么？

保護 IaC 的一般方法

AWS、Azure 和 GCP 使啟動存儲、計算和網絡資源變得非常容易，但是前提是建立在不考慮 IaC 的安全影響對開發(fā)團隊再次造成困擾的可能性。例如，混淆彈性負載均衡器之間的細微差別可能會暴露敏感數(shù)據。當然，一些組織正在構建適當?shù)?IaC 抽象和模塊。要做到這一點，必須要對文化轉變、可觀測性和全周期發(fā)展進行思考。

文化轉變

與大多數(shù) IT 變革一樣，提高安全性首先需要進行文化轉變。技術是次要的，擁抱文化轉變需要增加程序員、DevOps、SRE 和安全專業(yè)人員之間的協(xié)作，以決定自主的領域。

文化轉變可能包括重新調整部署流程，或決定何時讓安全團隊參與新功能的發(fā)布。它還可以包括制定新的代碼分析工具和工作流程標準化。

可觀測性

如果從根本上改變了應用程序的架構，那么團隊需要知道哪些安全領域受到了影響。一個棘手的部分是在不增加開發(fā)人員工作流程的情況下，添加更多安全檢查點，關鍵就在于實現(xiàn)自動化。

全周期開發(fā)

開發(fā)人員繼續(xù)圍繞代碼庫承擔延長生命周期的責任，有人稱這種趨勢為全周期發(fā)展。在應用生命周期內，為開發(fā)人員提供自主權確實會帶來生產力優(yōu)勢。它可以減少對外部批準的需求并實現(xiàn)更快的軟件更改。

但是，這種自主權并不意味著其他人不參與安全過程。安全的責任不應該僅僅在于開發(fā)人員和 SRE 團隊，安全是整個組織的共同責任。

安全和 IaC 的未來

對于改變底層架構的新功能，團隊需要提前了解潛在的安全影響和風險因素。例如，在添加分析儀表板時，如何知道無服務功能具有對數(shù)據庫的正確訪問級別？是公開的嗎？是靜態(tài)加密的嗎？有適當?shù)拿荑€管理系統(tǒng)嗎？如何確保每次更改都不會產生額外風險？

圍繞這些因素提高安全意識并不是可以馬虎的事情。與 DevOps 的實踐類似，采用安全思維往往在最后一環(huán)才能感受其帶來的巨大收益。此外，隨著多云采用率的提高，如果企業(yè)想要在所有軟件部門應用與云無關的一致保護，則需要實時響應自身的安全理念。

最后再提一點，隨著這種基礎設施自動化的持續(xù)演進，預計未來很快還會從 IaC 轉向更多低代碼 / 無代碼的能力，這通常稱為 ClickOps。而有可能將是未來新的發(fā)展方向。

（雷鋒網編譯）雷鋒網雷鋒網