容器，是未來it創新和數字化轉型第一驅動力，這幾年已經成為開發人員最愛。容器構造之精密，絲毫不亞于建筑大師蜜蜂所造蜂房。正如達爾文贊嘆蜜蜂的巢房是自然界最令人驚訝的神奇建筑，蜂房是自然界最經濟有效的建筑。在這里，青藤推出“蜂巢之聲”欄目，和大家講講堪比大自然鬼斧神工般的容器，其安全該怎么做？
雖然現在容器的使用率還不是特別高，但是許多組織機構也正在加速采用容器，容器化是未來發展的所趨。根據gartner預測，到2023年將有超過70%%u7ec4織會在生產環境中運行超過3個容器應用程序。如下圖所示，越來越多組織將采用容器化部署應用，對超過一半的應用程序進行容器化處理的組織百分比從23％增至29％，增長率為22％。同時，將少于10％的應用程序打包的組織的數量從32％下降到21％。
容器化部署應用程序占比
但是，開發人員常常用不安全的方式來部署容器，而安全團隊卻很少或根本沒有機會參與。如何讓容器更加安全使用？
一、安全左移和自動化是容器安全前提
在當今快節奏的容器devops中，部署容器時，安全人員必須注意容器共享os內核帶來潛在風險、鏡像漏洞、錯誤配置、容器間網絡流量問題。不管是防火墻還是入侵防御系統，并不適用于容器環境。
此外，隨著現代環境越來越多地由軟件控制，并實現了自動化，停止作業進行安全評估已不再可行。標準的做法是盡可能地將安全融入生產，并且通過微服務進行快速迭代。
安全左移
現在容器鏡像是由開發人員構建的，因此，開發人員承擔了許多其他職責。開發人員對以前由其他團隊處理的活動所具有的控制權越來越多，包括一部分測試和運營。
無論是在測試環境中還是在生產環境中，由開發人員構建的容器鏡像的運行方式都是相同的。因此，容器鏡像必須是獨立的而且適配各類環境，只需配置好與容器相關的安全和加固策略，適當調整可與生產資源連接的基本操作系統即可。
因此，容器安全必須左移，從代碼編寫和編譯時就要確保容器安全。如果在生產過程中解決安全問題必然會產生大量浪費，因為修復發現的問題就要終止創新管道，并將容器返回到開發階段。
自動化
容器是devops實踐最佳承載方式之一，微服務事實上成為新應用程序體系結構。借助容器化微服務，不同的開發團隊通過為每個微服務建立并行開發管道，可將創新速度提高十倍以上。
當這些微服務投入生產時，編排軟件可以對其進行部署和管理。編排軟件是基于策略來運行的，從而讓容器部署實現遠超人工可以實現的效果。這就有效地讓人員從容器化生產環境運營中抽出身來，讓他們能夠進行策略制定和監控異常。這就意味著支持自動化、api和策略運行，從而讓容器具有自行評估和采取措施的能力。
二、全生命周期方案
構建階段
（1）安全鏡像掃描
通常，容器鏡像是從根鏡像的基礎上構建出來的，根鏡像提供了操作系統組件和應用程序中間件（例如node.js或tomcat）。然后，開發人員通過自己的代碼對根鏡像進行拓展，形成微服務的應用程序結構。一般情況下，無需修改即可直接使用kafka或vertica等應用中間件。
但是，如果是從docker hub等公共倉庫獲取根鏡像時，開發人員無法了解那些未經測試和未經驗證的根鏡像究竟會帶來哪些安全風險。因此，需要通過容器鏡像掃描，檢測是否包含了常用漏洞和風險（cve），減少最終容器鏡像的攻擊面。
正確的鏡像掃描應包括以下幾個級別：
·進行鏡像掃描，檢查根鏡像，檢測開源鏡像庫中是否有已知的第三方漏洞。
·對配置和部署腳本進行靜態掃描，及早發現錯誤配置問題，并對已部署的鏡像進行動態基礎架構加固掃描。
（2）對受信鏡像進行簽名和注冊
在查看容器鏡像時，確保已對其進行了掃描和測試以確保安全。了解這一點很重要，因為這會影響下一個階段（例如轉移到生產環境中）的其他檢查點。
在成功進行鏡像掃描和創建安全評分后，可以對容器鏡像重新簽名，包括安全評分和測試結果，標明該容器鏡像已經過測試并達到特定的安全狀態等級。
（3）觀察應用程序行為
當開發人員通過許多容器化的微服務形成其工作負載和應用程序時，網絡將成為應用程序結構。網絡動態綁定所有微服務。以前，所有邏輯都是在編譯時綁定的。現在，微服務是解綁的，并根據需要在運行時與其他服務形成連接。
當然，判斷正常行為和異常行為并非易事。將一個應用程序分解為可服務多個應用程序的微服務時，威脅建模要困難得多。建議在開發和集成時觀察微服務架構，了解哪些是正常行為，這有助于威脅建模。在生產中，可通過威脅模型檢測異常行為，進行隔離。
分發
（1）審核已知內容
隨著容器鏡像從一個鏡像倉庫遷移到另一個鏡像倉庫（不管是內部還是外部運行的），遇到包含未知漏洞的鏡像風險都會增加。容器安全系統需要在通過容器鏡像倉庫時驗證容器鏡像，一旦發現不合規情況，就要攔截和隔離相關鏡像。
每次將容器升級到新狀態時（例如，從開發到測試或從測試到生產），都應執行額外的強制措施，以確保在上一階段為了方便進行調試/監視/基準測試而添加的任何配置不會隨容器本身而進入下一個階段。
（2）審核風險評分
容器和鏡像層的安全策略非常廣泛，因此，很難設置一個人為管理的統一且易于維護的安全策略。對安全策略進行編碼，對每個檢查點的每個容器鏡像生成一個風險評分，這樣就可以實現容器生命周期的標準化，并對每個重要的檢查點中設置最低安全閾值，如果沒有達到最低水平，將對容器生命周期進行控制。
風險評分還有助于促進dev、sec和ops的協同合作，因為這個統一的風險評分是對這三方的綜合評分，這有助于促進不同團隊和專業人士保持統一行為。
部署
（1）自動部署
開發人員正在以不斷加快的速度創建容器格式的微服務。不僅devops管道難以管理，而且在生產環境中，在調度和編排方面，人工操作要讓位于機器操作，因為編排和調度程序可以實現容器化微服務的自動化部署。編排程序可以比人做出更好的布局和擴展決策，因此，可以統一穩定地實施安全策略。
為了將管理良好的安全狀態始終維持在一個可接受的水平上，要將容器安全軟件與部署系統聯系起來，以便您按統一方式遵守安全策略。
基于基礎架構即代碼（iac）原則，要對所編寫的、支持自動化部署任務的代碼進行掃描和驗證，按照應用程序代碼級別，發現代碼中存在的漏洞。
（2）安全基礎架構
在主機上部署干凈無漏洞的容器仍然會有安全風險，需要實施相關的加固最佳實踐，否則，針對流氓容器的保護就太少了。例如，以cis基準或公司加固策略為基準，查看與加固最佳實踐存在哪些偏差；向管理員發出警報，并為容器化的基礎架構提供安全評分。
（3）用戶和機器審計
通過完整的審核跟蹤，團隊可以調查導致安全事件的原因，并據此采取補救措施并實施新的安全策略。這就需要知道誰做了什么，哪個容器編排程序將哪個鏡像部署到了物理或虛擬主機，或者為什么阻止了容器鏡進行部署或訪問給定資源。
容器安全系統需要與人為操作系統和機器操作系統連接起來，對容器基礎設施上發生的所有事件創建準確的審計跟蹤，并記錄其自身的行動和活動。
運行
(1)秘鑰管理
在很多系統中，密碼和安全令牌之類的秘鑰是安全系統的一個重要組成部分。在主機上部署容器鏡像或訪問基于網絡的資源時需要這些秘鑰。若將秘鑰存儲在容器或環境變量中，所有有權訪問該容器的人都會可以看到。
容器系統要求在進行操作（例如容器部署）時使用秘鑰。因此，容器安全系統通常需要訪問秘鑰系統，在容器命令中注入正確的秘鑰進行部署和運行。因此，容器的秘鑰管理需要采用專門解決方案。例如，與hashicorp的vault之類的秘鑰系統集成后，僅特定用戶和容器可以訪問特定秘鑰。
(2)與主機隔離
在主機上運行的容器可能會訪問主機資源，例如計算資源、存儲資源和網絡資源。此外，由于容器通常包含微服務，因此從本質上講，容器應僅限于一些特定任務，并且每個容器通常負責的任務只有一個。
一旦流氓容器獲得對主機資源（尤其是網絡）的訪問權限，就可以從網絡上獲取更多資源，進一步滲透到其他主機和系統。應該限制正在運行的容器的訪問權限，并且這些容器只能使用已批準的特定主機資源，從而限制其對主機和網絡的影響。
(3)容器網絡安全
一臺主機上有多個容器，每個容器都與同一主機或基于網絡的服務上的相鄰容器進行交互，僅依靠網絡安全措施是不夠的，因為主機內部發生的一切對于這些解決方案都是不可見的。
容器安全解決方案需要更靠近主機上發生事件的地方。比如，通過容器化的agent，它會監控所有主機網絡活動，主機上運行的容器的流入和流出，并觀察容器是如何與不同主機的另一個網絡進行交互的。了解了網絡交互情況之后，可以通過網絡流量加固活動來阻止任何異?；顒印?br>應根據在構建階段進行的威脅建模，預先規劃適當的網絡分段，并對其進行實施和驗證，確保失陷容器盡可能少地影響其他網段，而不會對整個網絡造成重大影響系統。
(4)應用程序配置文件加固
應用程序架構是由眾多微服務構建而成，每個微服務都具有一個或多個實例，可以實現彈性擴展。應用程序架構中的容器在不斷發生變化，主要由編排產品來實現的。
因此，想要維持正確的應用程序拓撲和觀察異常行為也愈發困難。例如，異常行為可能是由軟件缺陷帶到了生產環境中造成的，也可能是通過第三方開放源代碼庫滲透的惡意代碼引起的。
建議，在開發階段捕獲正常的應用

企業郵箱怎么申請子部門賬號
云服務器推薦及價格表
一個優質網站必備的基本要素有哪些？
.商標有什么含義？它的優勢在哪里？
彈性云服務器ecs屬于saas嗎
云服務器價格恒創裝漫畫
騰訊會議電腦版怎么關閉麥克風 騰訊會議電腦版關閉麥克風的方法
域名注冊網站排行靠前的網站哪家好？域名申請步驟有哪些？