一般來說，安全屬于信息安全團(tuán)隊(duì)的管轄范圍。直到幾年前，這種網(wǎng)絡(luò)安全方法一直運(yùn)作良好。

向云計(jì)算基礎(chǔ)設(shè)施的轉(zhuǎn)變創(chuàng)造了一個(gè)分散的軟件開發(fā)環(huán)境，這對(duì)軟件開發(fā)的增長(zhǎng)和規(guī)模起到了重要作用。DevOps 幫助團(tuán)隊(duì)以更快的速度創(chuàng)建、測(cè)試和實(shí)施軟件——通過在整個(gè)軟件開發(fā)生命周期中使用廣泛的服務(wù)來支持這種敏捷性。然而，這樣做也引入了新的網(wǎng)絡(luò)安全漏洞，傳統(tǒng)的信息安全孤島無法管理這些漏洞。為了保護(hù) DevOps 環(huán)境，創(chuàng)建了 DevSecOps 部門——一個(gè)主要支柱是秘密管理的領(lǐng)域。

1. 網(wǎng)絡(luò)安全是必須的

云計(jì)算安全已成為 DevOps 團(tuán)隊(duì)職責(zé)的一個(gè)組成部分，積極主動(dòng)地進(jìn)行云安全管理 (CSM) 至關(guān)重要。

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

除了創(chuàng)建軟件外，開發(fā)人員現(xiàn)在還必須保護(hù)企業(yè)的機(jī)密免遭未經(jīng)授權(quán)或未經(jīng)身份驗(yàn)證的訪問，并且在開發(fā)過程中這樣做。秘密是支持訪問權(quán)限的數(shù)字憑證——無論是人對(duì)應(yīng)用程序還是應(yīng)用程序?qū)?yīng)用程序。后者使用“秘密”，例如密碼、加密密鑰、證書和 API 密鑰等。

為了讓 DevOps 保護(hù)代碼免受秘密泄露導(dǎo)致的數(shù)據(jù)泄露，他們必須首先了解秘密在其環(huán)境中擴(kuò)散的多種方式。秘密通過七個(gè)驅(qū)動(dòng)因素滾雪球，包括：基于云原生的開發(fā)、多云基礎(chǔ)設(shè)施、微服務(wù)架構(gòu)、從用戶身份到機(jī)器身份的轉(zhuǎn)變、AL/ML/數(shù)據(jù)分析、物聯(lián)網(wǎng)/嵌入式設(shè)備。

這些驅(qū)動(dòng)程序會(huì)產(chǎn)生漏洞，因?yàn)樗鼈冊(cè)试S更多的錯(cuò)誤機(jī)會(huì) - 無論是硬編碼秘密以加速測(cè)試，使用不安全的開源庫，還是忽略考慮云的安全性。

雖然有各種技術(shù)可以幫助管理機(jī)密，包括商業(yè)和開源，但一定要考慮企業(yè)的預(yù)算和要求、當(dāng)前部署的技術(shù)、 DevOps 團(tuán)隊(duì)在機(jī)密管理方面的經(jīng)驗(yàn)，以及實(shí)施和保持這些技術(shù)最新和更新的機(jī)會(huì)。

3. DevOps 團(tuán)隊(duì)保護(hù)云基礎(chǔ)架構(gòu)的八種方式

(1) 確定必要的要求

預(yù)先警告是預(yù)先準(zhǔn)備好的，所以這個(gè)過程越早開始越好。大多數(shù)公司已經(jīng)至少部分地在云上，所以有時(shí)很難退后一步了解大局。

不要忘記——云服務(wù)不僅僅是 AWS、Azure 和 Google。云服務(wù)涵蓋所有這些 SaaS 應(yīng)用程序。團(tuán)隊(duì)是否在使用 Slack 或其他基于 SaaS 的 DM?

如果開發(fā)或 DevOps 團(tuán)隊(duì)正在使用他們的 Slack 頻道來分享公司機(jī)密，那么通過暴力攻擊獲得 Slack 訪問權(quán)限可能會(huì)使整個(gè)企業(yè)處于危險(xiǎn)之中。

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

由于大多數(shù)數(shù)據(jù)泄露是由導(dǎo)致配置錯(cuò)誤、機(jī)密泄露和糟糕的數(shù)字衛(wèi)生的人為錯(cuò)誤引起的，DevOps 和 DevSecOps 負(fù)責(zé)管理誰可以訪問什么——這是每個(gè)連接的安全系統(tǒng)的基本要求。

DBA 需要與開發(fā)團(tuán)隊(duì)等不同的數(shù)據(jù)訪問權(quán)限。通過遵循最小訪問權(quán)限策略并結(jié)合正確配置的堆棧，企業(yè)將能夠降低風(fēng)險(xiǎn)。

所有 IaaS、PaaS 或?qū)嶋H上任何 XaaS 都需要在最基本的級(jí)別(憑證級(jí)別)進(jìn)行保護(hù)。Google 會(huì)定期向其商業(yè)客戶發(fā)送警報(bào)，通知他們潛在的憑據(jù)泄露。

無論要做什么，都不要忘記 ShadowIT – 確保企業(yè)中的每個(gè)人都知道他們的憑據(jù)泄露可能是最薄弱的環(huán)節(jié)。ShadowIT 增加了憑證泄露的風(fēng)險(xiǎn)，僅僅是因?yàn)?IT 沒有意識(shí)到許多外部平臺(tái)突然連接到受控的內(nèi)部系統(tǒng)。

最后，要從別人的錯(cuò)誤中吸取教訓(xùn)。英特爾有一個(gè)方便的安全清單，企業(yè)可以將其用作確定云安全要求的基礎(chǔ)。

(2) 定義架構(gòu)

一旦確定了企業(yè)的云安全要求，企業(yè)將更全面地了解已經(jīng)使用的云服務(wù)類型以及需要添加的其他服務(wù)。

云安全始終需要放在首位。企業(yè)也有責(zé)任保護(hù)自己的應(yīng)用程序、數(shù)據(jù)、操作系統(tǒng)、用戶訪問和虛擬網(wǎng)絡(luò)流量。除此之外，磨練企業(yè)員工的配置基礎(chǔ)知識(shí)。超過 5% 的 AWS S3 存儲(chǔ)桶被錯(cuò)誤配置為公開可讀。

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

借助 SaaS 和 Web 安全，憑證保護(hù)再次成為關(guān)鍵。

每種架構(gòu)類型都需要自己的安全類型——勤奮。例如，混合云基礎(chǔ)設(shè)施需要“三重打擊”的安全性——本地需要高度安全，所有端口都關(guān)閉、表面積跟蹤，以及高度活躍的安全運(yùn)營中心 (SOC)。公共云方面需要使用該公共云堆?？捎玫淖钚潞妥顝?qiáng)大的安全技術(shù)來保護(hù)。它們之間的連接也需要保護(hù)免受攻擊。

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

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

• 云訪問安全代理 (CASB)
• 云工作負(fù)載保護(hù)平臺(tái) (CWPP)
• 云安全態(tài)勢(shì)管理 (CSPM)
• 靜態(tài)應(yīng)用程序安全測(cè)試 (SAST)
• 數(shù)據(jù)丟失防護(hù) (DLP)

CASB 充當(dāng)企業(yè)和云服務(wù)提供商之間的中介 - 并提供配置審計(jì)、數(shù)據(jù)丟失預(yù)防、治理和監(jiān)控等服務(wù)。常見的 CASB 包括 Broadcom、Palo Alto 和 Forcepoint。

CWPP 可防止系統(tǒng)過載，例如導(dǎo)致潛在內(nèi)存溢出的 DDoS 或錯(cuò)誤代碼。他們監(jiān)控部署在云基礎(chǔ)設(shè)施上的云計(jì)算資源。CheckPoint、Trend Micro 和 Carbon Black 都提供 CWPP。

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

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

DLP 可能是 CASB 的一部分，也可能是一項(xiàng)單獨(dú)的技術(shù)，通過降低/消除數(shù)據(jù)泄露風(fēng)險(xiǎn)(無論是不良行為者還是內(nèi)部資源)，提供工具和策略來保護(hù)敏感數(shù)據(jù)。

這些工具可以單獨(dú)使用，也可以作為更大安全堆棧的一部分使用。它們可以在整個(gè)組織內(nèi)或僅在特定領(lǐng)域內(nèi)使用——例如用于開發(fā)的 SAST。

(4) 專注于保護(hù)自己的的云機(jī)密

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

因此，重點(diǎn)需要放在憑證保護(hù)上。密鑰和密碼需要在可能的情況下自動(dòng)輪換，無需人工交互。它們必須足夠強(qiáng)大以承受攻擊。

不要忘記培訓(xùn)員工了解“典型”威脅，例如網(wǎng)絡(luò)釣魚、網(wǎng)絡(luò)釣魚、中毒鏈接等。

然而，無論團(tuán)隊(duì)多么謹(jǐn)慎，我們都會(huì)犯錯(cuò)誤。

(5) 掃描錯(cuò)誤配置

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

問題是開發(fā)人員有太多他們關(guān)注的其他事情，以至于他們有時(shí)會(huì)忘記刪除這些訪問權(quán)限——從而使整個(gè)系統(tǒng)易受攻擊。自動(dòng)配置掃描是發(fā)現(xiàn)這些類型錯(cuò)誤的關(guān)鍵，因?yàn)闆]有人真正有時(shí)間專門檢查每一行配置代碼。

(6) 關(guān)注最少訪問原則

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

在現(xiàn)實(shí)世界中，執(zhí)行最少訪問權(quán)限原則——將訪問權(quán)限限制在嚴(yán)格需要的人身上——將通過降低錯(cuò)誤風(fēng)險(xiǎn)、限制損害范圍和加強(qiáng)安全性來實(shí)現(xiàn)更好的訪問管理。例如，當(dāng)一名會(huì)計(jì)員工出現(xiàn)錯(cuò)誤時(shí)，這樣的政策可以大大減損失。誠然，最小訪問權(quán)限可能不是一個(gè)足夠強(qiáng)大的解決方案，需要通過持續(xù)監(jiān)控來補(bǔ)充，但可以通過以下方式加強(qiáng)：

• 消除最終用戶計(jì)算機(jī)上的管理員權(quán)限
• 更好地保護(hù)帳戶憑據(jù)
• 監(jiān)控特權(quán)會(huì)話以確保正確使用
• 限制開發(fā)人員訪問，除非他們有特定要求
• 限制對(duì)生產(chǎn)系統(tǒng)的訪問

權(quán)限訪問管理技術(shù)提供監(jiān)控、審計(jì)和合規(guī)性實(shí)施。一個(gè)好的權(quán)限訪問解決方案允許輕松分配或即時(shí)拒絕，確保僅根據(jù)需要進(jìn)行訪問。

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

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

主動(dòng)和被動(dòng)安全需要與開發(fā)的每一步齊頭并進(jìn)，在加快響應(yīng)速度的同時(shí)保持一切敏捷。每個(gè)開發(fā)人員都需要考慮安全性，并且需要檢查新舊代碼是否存在潛在漏洞。

(8) 保持簡(jiǎn)單

自動(dòng)化是確保整個(gè) SDLC 安全的最快捷、最簡(jiǎn)單的方法。配置檢查、秘密掃描器、身份訪問管理、治理、合規(guī)性、屏蔽和合成數(shù)據(jù)都是重要的解決方案。關(guān)鍵是找到能夠最大限度地提高云安全性、最大限度地減少誤報(bào)并保持高質(zhì)量代碼快速且廉價(jià)地推出的組合。

最好的解決方案是最簡(jiǎn)單的：使用最少的工具構(gòu)建安全堆棧，提供最高級(jí)別的安全性和最低級(jí)別的誤報(bào)。不幸的是，實(shí)現(xiàn)這種效果相當(dāng)復(fù)雜。許多公司提供可以簡(jiǎn)化流程的一體化工具或兼容套件，但不能總是指望這一點(diǎn)。與所有龐大的項(xiàng)目一樣，最好的方法是一次邁出這一步。

永遠(yuǎn)不要忘記云安全，企業(yè)應(yīng)檢查自己的服務(wù)水平協(xié)議，找出云提供商留下所有漏洞并進(jìn)行修改。