讓我們深入探討 DevOps 和 DevSecOps 管道中密碼密鑰管理的各個方面。

當今的數(shù)字業(yè)務有望以閃電般的速度創(chuàng)新、執(zhí)行和發(fā)布產(chǎn)品。自動化工具的廣泛采用，加上 DevOps 和DevSecOps 工具，有助于這些企業(yè)實現(xiàn)更高的開發(fā)速度和更快的反饋循環(huán)。這最終有助于縮短發(fā)布周期并以迭代方式提高產(chǎn)品質量。

盡管向微服務和容器化應用程序的轉變以及開源的采用正在幫助開發(fā)人員更快地交付產(chǎn)品，但它們也帶來了與合規(guī)性和安全性相關的挑戰(zhàn)。根據(jù) 1Password 的Hidden In Plain Sight 報告，企業(yè)中的 DevOps 和 IT 團隊不斷面臨由機密泄露、機密共享不安全和手動機密管理等帶來的挑戰(zhàn)。

管理大型項目的 API 密鑰、密碼、加密密鑰等機密信息非常復雜。讓我們在本文中深入探討機密管理的各個方面。

什么是密碼密鑰管理?

簡而言之，密碼是非人類特權憑證，為開發(fā)人員提供訪問應用程序、容器等資源的權限。類似于密碼管理，秘密管理是一種將秘密(例如，訪問令牌、密碼、API 密鑰等)存儲在具有更嚴格訪問控制的安全環(huán)境中的做法。

隨著應用程序的復雜性和規(guī)模隨著時間的推移而增長，管理密碼可能會變得混亂。此外，可能會出現(xiàn)跨技術堆棧的不同塊共享秘密的情況。這可能會造成嚴重的安全威脅，因為它會為惡意行為者打開后門來訪問您的應用程序。

密碼管理確保敏感信息永遠不會被硬編碼，并且只能以加密格式提供。與 RBAC(基于角色的訪問控制)一起安全訪問敏感數(shù)據(jù)是密碼管理的秘訣。

密碼密鑰管理的挑戰(zhàn)

在許多情況下，開發(fā)人員可能不小心在他們的代碼或配置文件中使用了硬編碼的純文本格式憑證。如果將包含機密的相應文件推送到 GitHub(或任何其他流行的代碼托管平臺)上指定的公共存儲庫，對業(yè)務的影響可能會很大。

多云基礎設施、容器化應用程序、IoT/IIoT、CI/CD 和類似進步所提供的好處可以通過同時關注秘密的有效管理來最大限度地利用。對開發(fā)和 DevOps 團隊進行應用程序安全教育是在團隊中建立安全第一文化的最重要步驟。

以下是 DevOps 和 DevSecOps 團隊在管理機密時面臨的主要挑戰(zhàn)：

密碼密鑰蔓延

這種情況通常發(fā)生在團隊(和/或組織)的密碼分布在整個組織中時。數(shù)字優(yōu)先的組織越來越多地使用容器和基于云的工具來提高開發(fā)人員的速度、節(jié)省成本并加快發(fā)布速度。同樣的原則也適用于基于物聯(lián)網(wǎng)應用程序的開發(fā)和測試。

根據(jù)應用程序的規(guī)模和復雜性，機密很可能分布在：

• 基于容器化微服務的應用程序(例如，Kubernetes、OpenShift、Nomad)
• 自動化 E2E 測試/跟蹤平臺(例如，Prometheus、Graphite)
• 內部開發(fā)的工具/流程
• 應用服務器和數(shù)據(jù)庫
• DevOps 工具鏈

以上列表中的項目因應用程序的規(guī)模、大小和復雜性而異。提供 RBAC、使用強旋轉密碼和避免密碼共享是團隊/組織內每個級別都必須遵循的一些簡單實踐。

云開發(fā)人員和測試工具的激增

無論項目的大小和規(guī)模如何，開發(fā)團隊都希望最大限度地利用 GCP(谷歌云平臺)、Microsoft Azure、AWS(亞馬遜網(wǎng)絡服務)、Kubernetes 等云開發(fā)工具。

云工具肯定會加快與開發(fā)和測試相關的流程，但必須在使用它們的同時將安全實踐放在首位。用于訪問相應云平臺的密鑰(例如 AWS 密鑰)的任何泄露都可能導致經(jīng)濟損失。

在存儲庫中公開公開的 AWS 憑證

鑒于如此多的風險，DevOps 和開發(fā)團隊必須確保任何類型的密鑰在公共領域(例如 GitHub 存儲庫)中都不會以人類可讀的格式提供。專注于社區(qū)主導增長 (CLG) 以宣傳其產(chǎn)品或開發(fā)人員工具的組織需要確保其用戶不會將任何密鑰公開遺漏!如果密鑰可公開訪問，黑客可能出于惡意原因利用您的平臺。

用于管理機密的手動流程、使用第三方資源(例如 API)時的數(shù)據(jù)安全以及安全鏡頭的端到端可見性是組織在機密管理方面面臨的其他挑戰(zhàn)。

密碼密鑰管理最佳實踐

在安全管理機密方面沒有一種放之四海而皆準的方法，因為這在很大程度上取決于基礎設施、產(chǎn)品要求和其他此類變化因素。

撇開變量不談，這里有一些關于高效和可擴展的秘密管理的最佳實踐：

使用 RBAC(基于角色的訪問控制)

每個項目和組織都有敏感數(shù)據(jù)和資源，必須只能由受信任的用戶和應用程序訪問。系統(tǒng)中的任何新用戶都必須分配默認權限(即最小訪問控制)。提升的權限必須僅對項目或組織中的少數(shù)成員可用。

管理員(或超級管理員)必須有權根據(jù)需要添加或撤銷其他成員的權限。權限升級也必須根據(jù)需要進行，并且只能在有限的時間內進行。在授予/撤銷權限時必須添加適當?shù)淖⑨?，以便所有相關的項目涉眾都具有完整的可見性。

使用安全保險庫

簡單來說，保險庫是一種主要用于保護任何敏感信息(例如，密碼、API 密鑰、證書等)的工具。以人類可讀的形式在本地存儲機密信息是管理機密信息最糟糕的方法之一。

這就是安全保險庫非常有用的地方，因為它們?yōu)槿魏蚊孛芴峁┝私y(tǒng)一的接口，并提供了詳細的審計日志。通過指定訪問權限(授權)，安全保險庫還可用于檢測基于角色的訪問控制 (RBAC)。Hashicorp Vault Helm chart和Vault for Docker是兩個流行的保險庫管理器，可用于運行保險庫服務、訪問和存儲機密等。

由于大多數(shù)應用程序都利用了云的潛力，因此在數(shù)據(jù)傳輸或靜止時關注數(shù)據(jù)安全性非常重要。這就是 EaaS(加密即服務)可用于在靜態(tài)存儲數(shù)據(jù)之前將應用程序的加密需求卸載到保管庫的地方。

定期輪換密鑰

幾周或幾個月后重置密鑰是一種很好的安全做法。一種做法是手動重新生成密鑰，因為使用這些秘密的應用程序可能會在日志文件或集中式日志記錄系統(tǒng)中留下痕跡。攻擊者可以獲得對日志的后門訪問并使用它來泄露秘密。

此外，同事可能會無意中向組織外部泄露機密。為避免此類情況，建議在相應的機密管理工具中啟用機密輪換。例如，AWS Secrets Manager 中的 Secrets Manager 輪換使用 AWS Lambda 函數(shù)來更新密鑰和數(shù)據(jù)庫。

最重要的是，團隊應該有適當?shù)膶嵺`來檢測對系統(tǒng)的未授權訪問。這將有助于在對業(yè)務造成重大損害之前采取適當?shù)拇胧?/p>

為什么要在 DevSecOps 管道中實施機密管理?

只有在 CI/CD 管道中對代碼進行自動化測試，才能實現(xiàn)加速發(fā)布周期和更快的開發(fā)人員反饋。在 CI 管道中運行的測試可能需要訪問關鍵的受保護資源，如數(shù)據(jù)庫、HTTP 服務器等。

甚至在 Docker 容器內運行單元測試也是一種常見做法，但開發(fā)人員和 QA 需要確保秘密不存儲在 Dockerfile 中。秘密管理工具可以與流行的 CI/CD 工具(例如 Jenkins)結合使用，從而在集中位置管理密鑰和其他秘密。秘密也通過加密和令牌化存儲。