雲安全管理中的 DevOps 職責

作者 | Dotan Nahum

譯者 | 蓋磊

策劃 | 丁曉昀

審校 | 冬雨

通常，安全屬於信息安全團隊的工作範疇。這樣的網絡安全實現方式曾一度運作良好，直至最近幾年才發生變化。

向雲計算基礎設施的轉變，造就了分散化的軟件開發環境，進而推動了軟件開發在速度和規模上的增長。DevOps 爲軟件開發全生命週期提供了更豐富的服務，有助於開發團隊更快速地實現敏捷的軟件創建、測試和實施。但 DevOps 同時引入了新的網絡安全漏洞，這是傳統的信息安全孤島所無法管理的。爲保護 DevOps 環境，以敏感信息（Secret）管理爲主責的 DevSecOps 部門應運而生。

1 網絡安全是必須的

毫無疑問，雲安全已成爲 DevOps 團隊不可分割的職責。團隊必須在雲安全管理（Cloud Security Management，CSM）上積極作爲。

2雲安全：敏感信息及防泄露方法

現代開發人員在創建軟件之外，還必須保護組織的敏感信息免受未經授權或身份驗證的訪問，並將其落實在開發過程中。那什麼是“敏感信息”？敏感信息指支持訪問權限的數字憑證，其中訪問包括用戶訪問應用，以及應用間的相互訪問。對於後一種訪問，“敏感信息”包括密碼、加密密鑰、證書和 API 密鑰等。

爲避免代碼出現泄露敏感信息而導致數據泄露，DevOps 團隊必須首先了解在 DevOps 環境中存在的多種敏感信息擴散方式。導致敏感信息滾雪球般擴散的因素，可概況爲如下七種方式：基於雲原生的開發、多雲基礎設施、微服務架構、從用戶到機器的身份轉變、主動學習 / 機器學習 / 數據分析、物聯網 / 嵌入式設備，當然還包括 DevOps 本身。這些致因引發了更多的出錯機會，因此會產生漏洞。其中包括：爲加速測試而對敏感信息做了硬編碼、使用了不安全的開源庫，以及未考慮雲上安全和雲本身安全等。

當前存在着多種商業的和開源的敏感信息管理技術，用戶需要考慮的因素包括：所在組織的預算和要求、當前部署的技術、DevOps 團隊在敏感信息管理上的經驗，以及目前實施這些技術並維持最新的可能性。

3 支持雲架構安全，DevOps 團隊的 8 項做法

1. 識別必要需求：前期應做好預警的準備，越早越好。大部分公司已至少部分上雲，有時很難後退一步看到整體局面。

謹記，雲服務並不僅僅是 AWS、Azure 和 Google 這些廠商，而是技術棧涵蓋了從記賬到 Zoom 的所有 SaaS 應用。需特別提出一點，團隊是否正在使用 Slack 等基於 SaaS 的文檔管理系統（DM）？

如果開發團隊或 DevOps 團隊正使用自己的 Slack Channel 分享企業的敏感信息，那麼攻擊一旦通過暴力獲取了 Slack 的訪問權限，就能置整個組織於危險境地。

CI/CD 訪問的界定和管理，需明確落實爲管制措施。

鑑於數據泄露主要由人爲錯誤引發，表現爲配置不正確、敏感信息泄露和數字衛生堪憂等問題，因此鑑權的責任需由 DevOps 和 DevSecOps 團隊承擔，這是每個聯網的安全系統的基本要求。

有別於開發團隊，DBA 團隊需要完全不同的數據訪問權限。爲降低風險，應在正確配置的技術棧上遵循“最小訪問權限策略”（least access privilege policy）。

事實上，任何一種“某某即服務”，無論是 IaaS、PaaS 或是其它，都需要做到在憑證這一最基本的級別上的保護。Solarwinds 數據泄露案例就始於憑證的泄露。Google 會定期向其商業用戶發送警報，告知用戶潛在的憑據泄露。

無論如何，都不要遺漏"影子 IT"（ShadowIT）。確保組織中每位人員都知道，自身憑據的泄露可能是皇冠明珠中最薄弱的環節。影子 IT 增大了憑證泄露的風險，因爲 IT 團隊並未意識到一些外部平臺能突然連接到受控的內部系統。

最後一點，舉一反三，博採衆長。推薦英特爾提供的速查安全清單，可作爲確定雲安全要求的一個基礎。

2. 定義架構：一旦識別了組織的雲安全要求，就會更加全面地掌握組織在用的雲服務類型，以及需添加的其它服務。

始終將雲上安全和雲自身安全置於首位。謹記，用戶需對自己應用、數據、操作系統、用戶訪問和虛擬網絡流量的安全負責。此外，還需提升用戶對配置的基礎認知。有超過 5% 的 AWS S3 Bucket 被錯誤地配置爲公開可讀。近期 Kafdrop 的一個低級錯誤配置，就泄露了一些世界上最大型企業的 Apache Kafka 技術棧。

儘管三大雲廠商在自身技術棧安全加固上的投資數以百萬計，但 PaaS 公司並沒有此類預算。所以重要的事情說三遍，檢查、檢查，仔細檢查。稱其爲“零信任”是有原因的。

對於 SaaS 和 Web 安全，憑證保護同樣關鍵。

每種類型的架構，都需要有各自的安全類型，在這點上不能偷懶。例如，混合雲基礎架構需要達到一種“三重擊”類型的安全。一是本地部署需實現高度安全，包括關閉所有的端口、追蹤表面區域，以及具備一個高度活躍的安全運營中心 (SOC)；二是在公有云的安全防護上，需使用其技術棧中可用的最新和最強大的安全技術；三是二者間的連接也需加以保護，以免受攻擊。

3. 分析現有管控措施，找出存在的漏洞：零敲碎打的安全技術棧，效果是不會好的。顯然，更徹底、更合理的做法是從零開始構建。下面列出了一些可行的技術措施：

雲訪問安全代理 (Cloud access security broker，CASB)

雲工作負載保護平臺 (Cloud workload protection platforms，CWPP)

雲安全態勢管理 (Cloud security posture management，CSPM)

靜態應用安全測試 (Static application security testing，SAST)

數據丟失防護 (Data loss prevention，DLP)

CASB 擔當了組織和雲廠商間的中介，提供配置審計、DLP、治理和監控等服務。主要的 CASB 產品廠商包括 Broadcom、Palo Alto 和 Forcepoint 等企業。

CWPP 用於防止系統過載，比如 DDoS 和潛在導致內存溢出的錯誤代碼。CWPP 監控雲基礎設施上部署的雲計算資源。CheckPoint、Trend Micro 和 Carbon Black 等企業都提供 CWPP 產品。

CSPM 通過持續審計方式檢測錯誤的配置，幫助發現人爲錯誤，這是導致出現安全漏洞的主要原因之一。CSPM 廠商包括 Spectral 等。

SAST 掃描源代碼中的潛在漏洞，防止由於人爲錯誤和遺漏而導致敏感信息泄露。例如，測試後遺忘了數據庫訪問憑證的硬編碼。

DLP 可以是 CASB 產品的組成部分，也可以是單獨的產品。DLP 提供保護敏感數據的工具和策略，降低或消除由不良行爲者或內部資源導致的數據泄露風險。

上述工具可以單獨使用，也可以作爲更廣泛的安全技術棧的組成部分；可用於整個組織，也可用於特定的領域內，例如在開發中使用 SAST。

4. 聚焦於雲上敏感信息保護：在理想情況下，只要相關教育、以安全爲中心的文化和各項工具到位，敏感信息是永遠不會泄露的。但人爲錯誤是難免會出現的。老話常說“更快、更好、更便宜”。但在新說法中，會再添加上一條，“更安全”。當然，最初的收益是從“更快”和“更便宜”中獲得的，但忽視“更安全”的後果是對會業務產生更持久的影響。

開發人員面對着發佈代碼的巨大壓力。爲簡化跨工具的訪問，他們有時會走捷徑，試圖使用更易於記憶的密碼，或是使用易於猜出模式的輪轉密碼。

鑑於此，我們應聚焦於憑證保護。密鑰和密碼應儘可能在無需人工交互的情況下自動輪轉，也必須強大到足以承受蠻力攻擊。

不要忘記培訓人員瞭解一些“典型”威脅，例如釣魚式攻擊、短信息釣魚（smishing）、鏈接投毒等。

然而，無論團隊如何審慎而爲，人總是會犯錯誤的。

5. 搜索錯誤配置：如前所述，在更快、更高效、更好的過程中，開發人員一直專注於如何將代碼發佈出來。一種加速做法就是在配置中硬編碼數據庫訪問等敏感信息。偶爾還會爲了省事，在 QA 和測試中直接將“讀取訪問權限”設置爲“公共”。

問題在於，開發人員面對太多需要關注的事情，以至於有時會忘記刪除這些訪問權限，從而導致整個系統易受攻擊。自動配置掃描是發現此類錯誤的關鍵，因爲沒有人會真正有時間特地去逐行地檢查配置代碼。

6. 聚焦於最少訪問原則：理想情況下，每個人都是百分百適崗和誠實的，從不會犯錯誤，或是故意做錯事。

現實中，爲實現更好的訪問控制，需執行將訪問權限嚴控於必需人員的“最少訪問權限”原則，由此降低發生錯誤的風險、限制損害的範圍，並加強安全性。例如，在 Sage 公司數據泄露案例中，即便某位會計崗員工圖謀不軌，該策略也能大大地降低企業的損失。當然，最小訪問權限需要輔以持續的監控，它並非一種完備的解決方案，但可通過以下方式得到強化：

去除終端用戶計算機上的管理員權限；

更好地保護帳戶憑據；

監控特權會話，確保正確的使用；

除非開發人員有特定的要求，否則應限制訪問權限；

限制對生產系統的訪問。

這一原則同樣具有技術解決方案。權限訪問管理技術提供監控、審計和強制合規性。好的權限訪問解決方案，可支持權限的動態分配和拒絕，確保基於實際需要訪問。

7. 對 CI/CD 管道的全面持續安全防護：關鍵在於“測試關口前移”（Shifting Left）。安全性應始於首行代碼，而不是遺留到 QA 或測試階段。主動安全涵蓋了從防止不合規的和錯誤的配置，到限制敏感信息泄露和憑證漏洞，從而降低了整個軟件生命週期出現問題的可能性。

在開發中的每一步，都需要主動安全和被動安全齊頭並進。在加快響應速度的同時，保持一切過程的敏捷性。安全性是每位開發人員都需要考慮的問題，並檢查新舊代碼是否存在潛在的漏洞。簡而言之，從一開始就要在新代碼編寫中落實安全，在舊代碼審查中尋找問題。

8. 一切從簡：爲確保整個軟件生命週期的安全，實現自動化是最快捷、最簡單的方式。重要的解決方案包括配置檢查、敏感信息掃描、身份訪問管理、治理、合規性、掩碼和人工數據等。解決問題的關鍵在於找出一種組合，能最大限度地提高雲安全性、減少誤報，並快速且低代價地發佈高質量的代碼。

最好的解決方案，應是最簡單的。即使用盡可能少的工具構建安全技術棧，卻能提供最高等級的安全性和最低等級的誤報。不幸的是，事情總是相當複雜的。雖然一些企業提供了多合一工具或兼容套件，用於簡化流程。但作爲用戶，並不能完全依賴於此。和所有的大型項目一樣，最好的做法是擇機去邁出這一步。

永遠不要忽視雲上安全與雲本身安全，雲廠商很少會去分擔用戶的責任。對照企業自身的 SLA，去發現雲廠商提供服務中所有遺留下的坑，並逐項加以彌補。

作者簡介：

Dotan Nahum 是 Spectral 公司的 CEO 和聯合創始人。作爲一名技術大拿和代碼忍者，Nahum 具有數十年的動手編碼經驗，力圖通過深思熟慮的設計實現快速構建，融合性能、正確性和開發人員經驗。作爲一名重要的開源貢獻者、作家、演講者和播客，Nahum 在 React、Node.js、Go、React Native、分佈式系統和基礎設施（包括 Hadoop、Spark、Docker、AWS 等）方面體現出專業高水平。可訪問他的 Github 和博客。

https://www.infoq.com/articles/devops-cloud-security/