一般來說，安全屬于信息安全團隊的管轄范圍。直到幾年前，這種網絡安全方法一直運作良好。

向云計算基礎設施的轉變創造了一個分散的軟件開發環境，這對軟件開發的增長和規模起到了重要作用。DevOps 幫助團隊以更快的速度創建、測試和實施軟件——通過在整個軟件開發生命周期中使用廣泛的服務來支持這種敏捷性。然而，這樣做也引入了新的網絡安全漏洞，傳統的信息安全孤島無法管理這些漏洞。為了保護 DevOps 環境，創建了 DevSecOps 部門——一個主要支柱是秘密管理的領域。

1. 網絡安全是必須的

云計算安全已成為 DevOps 團隊職責的一個組成部分，積極主動地進行云安全管理 (CSM) 至關重要。

2. 云安全：防止秘密泄露

除了創建軟件外，開發人員現在還必須保護企業的機密免遭未經授權或未經身份驗證的訪問，并且在開發過程中這樣做。秘密是支持訪問權限的數字憑證——無論是人對應用程序還是應用程序對應用程序。后者使用“秘密”，例如密碼、加密密鑰、證書和 API 密鑰等。

為了讓 DevOps 保護代碼免受秘密泄露導致的數據泄露，他們必須首先了解秘密在其環境中擴散的多種方式。秘密通過七個驅動因素滾雪球，包括：基于云原生的開發、多云基礎設施、微服務架構、從用戶身份到機器身份的轉變、AL/ML/數據分析、物聯網/嵌入式設備。

這些驅動程序會產生漏洞，因為它們允許更多的錯誤機會 - 無論是硬編碼秘密以加速測試，使用不安全的開源庫，還是忽略考慮云的安全性。

雖然有各種技術可以幫助管理機密，包括商業和開源，但一定要考慮企業的預算和要求、當前部署的技術、 DevOps 團隊在機密管理方面的經驗，以及實施和保持這些技術最新和更新的機會。

3. DevOps 團隊保護云基礎架構的八種方式

(1) 確定必要的要求

預先警告是預先準備好的，所以這個過程越早開始越好。大多數公司已經至少部分地在云上，所以有時很難退后一步了解大局。

不要忘記——云服務不僅僅是 AWS、Azure 和 Google。云服務涵蓋所有這些 SaaS 應用程序。團隊是否在使用 Slack 或其他基于 SaaS 的 DM?

如果開發或 DevOps 團隊正在使用他們的 Slack 頻道來分享公司機密，那么通過暴力攻擊獲得 Slack 訪問權限可能會使整個企業處于危險之中。

需要通過明確的治理來定義和管理對 CI/CD 管道的訪問。

由于大多數數據泄露是由導致配置錯誤、機密泄露和糟糕的數字衛生的人為錯誤引起的，DevOps 和 DevSecOps 負責管理誰可以訪問什么——這是每個連接的安全系統的基本要求。

DBA 需要與開發團隊等不同的數據訪問權限。通過遵循最小訪問權限策略并結合正確配置的堆棧，企業將能夠降低風險。

所有 IaaS、PaaS 或實際上任何 XaaS 都需要在最基本的級別(憑證級別)進行保護。Google 會定期向其商業客戶發送警報，通知他們潛在的憑據泄露。

無論要做什么，都不要忘記 ShadowIT – 確保企業中的每個人都知道他們的憑據泄露可能是最薄弱的環節。ShadowIT 增加了憑證泄露的風險，僅僅是因為 IT 沒有意識到許多外部平臺突然連接到受控的內部系統。

最后，要從別人的錯誤中吸取教訓。英特爾有一個方便的安全清單，企業可以將其用作確定云安全要求的基礎。

(2) 定義架構

一旦確定了企業的云安全要求，企業將更全面地了解已經使用的云服務類型以及需要添加的其他服務。

云安全始終需要放在首位。企業也有責任保護自己的應用程序、數據、操作系統、用戶訪問和虛擬網絡流量。除此之外，磨練企業員工的配置基礎知識。超過 5% 的 AWS S3 存儲桶被錯誤配置為公開可讀。

雖然三大云已經投資了很多來保護他們的堆棧，但 PaaS 公司沒有這些預算——所以，一定要仔細檢查。它被稱為“零信任”是有原因的。

借助 SaaS 和 Web 安全，憑證保護再次成為關鍵。

每種架構類型都需要自己的安全類型——勤奮。例如，混合云基礎設施需要“三重打擊”的安全性——本地需要高度安全，所有端口都關閉、表面積跟蹤，以及高度活躍的安全運營中心 (SOC)。公共云方面需要使用該公共云堆棧可用的最新和最強大的安全技術來保護。它們之間的連接也需要保護免受攻擊。

(3) 分析現有控制并找出差距

對安全堆棧采取零碎的方法效果不佳;從頭開始構建顯然是一種更徹底、更合理的方法。以下是一些使這成為可能的選項：

• 云訪問安全代理 (CASB)
• 云工作負載保護平臺 (CWPP)
• 云安全態勢管理 (CSPM)
• 靜態應用程序安全測試 (SAST)
• 數據丟失防護 (DLP)

CASB 充當企業和云服務提供商之間的中介 - 并提供配置審計、數據丟失預防、治理和監控等服務。常見的 CASB 包括 Broadcom、Palo Alto 和 Forcepoint。

CWPP 可防止系統過載，例如導致潛在內存溢出的 DDoS 或錯誤代碼。他們監控部署在云基礎設施上的云計算資源。CheckPoint、Trend Micro 和 Carbon Black 都提供 CWPP。

CSPM 通過提供持續審計以檢測錯誤配置(包括 Spectral 等)來幫助檢測人為錯誤(安全漏洞的主要原因之一)。

SAST掃描源代碼中的潛在漏洞——例如測試后忘記的硬編碼數據庫訪問憑證——以防止由于人為錯誤/遺漏而泄露機密。

DLP 可能是 CASB 的一部分，也可能是一項單獨的技術，通過降低/消除數據泄露風險(無論是不良行為者還是內部資源)，提供工具和策略來保護敏感數據。

這些工具可以單獨使用，也可以作為更大安全堆棧的一部分使用。它們可以在整個組織內或僅在特定領域內使用——例如用于開發的 SAST。

(4) 專注于保護自己的的云機密

首先，在理想世界中，通過教育、以安全為中心的文化和足夠的工具，永遠不會泄露任何機密。但人為錯誤永遠存在。新版本需要更安全。開發人員面臨著將代碼發布出去的巨大壓力。有時他們會采取捷徑或嘗試使用一個易于記憶的密碼來簡化跨工具的訪問，或者他們使用易于猜測的模式輪換密碼。

因此，重點需要放在憑證保護上。密鑰和密碼需要在可能的情況下自動輪換，無需人工交互。它們必須足夠強大以承受攻擊。

不要忘記培訓員工了解“典型”威脅，例如網絡釣魚、網絡釣魚、中毒鏈接等。

然而，無論團隊多么謹慎，我們都會犯錯誤。

(5) 掃描錯誤配置

如前所述，在追求更快、更快、更好的競賽中，開發人員一直專注于將代碼發布出去。加速該過程的一種方法是將機密(例如數據庫訪問)硬編碼到配置中。有時，他們通過將“讀取訪問權限”設置為“公共”以進行 QA 和測試來偷工減料。

問題是開發人員有太多他們關注的其他事情，以至于他們有時會忘記刪除這些訪問權限——從而使整個系統易受攻擊。自動配置掃描是發現這些類型錯誤的關鍵，因為沒有人真正有時間專門檢查每一行配置代碼。

(6) 關注最少訪問原則

在理想的世界中，每個人都是 100% 有能力和誠實的，從不犯錯誤或考慮做錯事。

在現實世界中，執行最少訪問權限原則——將訪問權限限制在嚴格需要的人身上——將通過降低錯誤風險、限制損害范圍和加強安全性來實現更好的訪問管理。例如，當一名會計員工出現錯誤時，這樣的政策可以大大減損失。誠然，最小訪問權限可能不是一個足夠強大的解決方案，需要通過持續監控來補充，但可以通過以下方式加強：

• 消除最終用戶計算機上的管理員權限
• 更好地保護帳戶憑據
• 監控特權會話以確保正確使用
• 限制開發人員訪問，除非他們有特定要求
• 限制對生產系統的訪問

權限訪問管理技術提供監控、審計和合規性實施。一個好的權限訪問解決方案允許輕松分配或即時拒絕，確保僅根據需要進行訪問。

(7) 全面且持續地保護 CI/CD 管道

向左移動是關鍵。安全性應該從第一行代碼開始，而不是留給 QA 或測試。主動安全降低了整個 SDLC 出現問題的可能性——從防止不合規和配置錯誤到限制秘密泄漏和憑證漏洞。

主動和被動安全需要與開發的每一步齊頭并進，在加快響應速度的同時保持一切敏捷。每個開發人員都需要考慮安全性，并且需要檢查新舊代碼是否存在潛在漏洞。

(8) 保持簡單

自動化是確保整個 SDLC 安全的最快捷、最簡單的方法。配置檢查、秘密掃描器、身份訪問管理、治理、合規性、屏蔽和合成數據都是重要的解決方案。關鍵是找到能夠最大限度地提高云安全性、最大限度地減少誤報并保持高質量代碼快速且廉價地推出的組合。

最好的解決方案是最簡單的：使用最少的工具構建安全堆棧，提供最高級別的安全性和最低級別的誤報。不幸的是，實現這種效果相當復雜。許多公司提供可以簡化流程的一體化工具或兼容套件，但不能總是指望這一點。與所有龐大的項目一樣，最好的方法是一次邁出這一步。

永遠不要忘記云安全，企業應檢查自己的服務水平協議，找出云提供商留下所有漏洞并進行修改。