如今的企業IT場景的特點是持續的數字化轉型和大規模的數據生成。隨著遠程工作和移動工作成為新冠疫情發生之后的新常態，移動性和敏捷性已經成為企業業務連續性的重要驅動因素。

 

為了自動化和集成所有可能的業務功能，集中并加快數據和信息的流動，提高生產力并提供更好的客戶體驗，很多企業正在使用復雜的混合多云的運營模型構建敏捷的DevOps環境。

 

然而，隨著巨大的移動性和即時的數據，隨之而來的是巨大的責任。企業在保持數據、服務和個人身份信息(PII)安全方面面臨著越來越多的挑戰。盡管技術一直不斷進步，但人們仍然年復一年地看到大量的數據泄露事件。

 

企業如何發展其數據存儲、管理和保護方法，以確保員工能夠直接訪問數字資源，同時加強整個IT基礎設施的安全性?答案在于有效的企業機密管理。

 

 

機密管理是一套適當的工具和最佳實踐，用于在整個生命周期內安全地存儲、訪問和集中管理數字身份驗證憑證。機密是用于身份驗證和授權的數據項——它們包括密碼、公共和私人加密密鑰、SSH密鑰、API、令牌和證書。機器和人類都使用機密進行身份驗證和通信。

 

但是，為什么首先需要機密管理?基于SaaS的機密管理工具Akeyless公司首席執行官兼聯合創始人Oded Hareven解釋說，“隨著向混合多云基礎設施的普遍轉變以及對應用程序容器化的依賴，機器和人員持續訪問系統和數據的需求已經大幅增長。例如，越來越多的應用程序必須不斷地訪問不同的數據源、云服務和服務器，通常每個資源都需要不同類型的憑據。這在DevOps流程中產生了對機密的指數級需求。”

 

棘手的是，開發人員經常將各種機密編碼到應用程序或微服務代碼、腳本、自動化工具和代碼庫中——所有這些都駐留在各種基礎設施中。更糟糕的是，這些代碼處于不同的開發階段，存在管理不當和未受保護的實際風險。其結果是總體上缺乏對機密的控制和整合，導致安全行業稱之為“機密蔓延”。

 

麻煩還不止于此。在執行持續集成(CI)/持續交付(CD)的云平臺中保存的機密本質上是管理和允許訪問其他機器和軟件所必需的。為此，他們需要存儲機密和簽名密鑰(用于密封代碼和軟件更新)，這些密鑰通常存儲在非安全位置，如開發人員的筆記本電腦或他們構建的服務器。

 

機密蔓延不僅使憑證難以跟蹤和管理，而且容易受到黑客攻擊。事實上，根據Verizon公司日前發布的一份調查報告，被盜憑證占所有數據泄露的近一半。

 

最近發生的許多黑客攻擊，包括軟件供應鏈黑客攻擊，都利用了代碼中的機密，這些機密再次存儲在GitHub等易于訪問的存儲庫中。事實上，GitHub最近在數千個私有存儲庫中檢測到70多萬次潛在的憑證泄漏，并且已經準備就緒。

 

這些例子不斷涌現。最近曝光的軟件供應鏈攻擊劫持了流行的PHP和Python庫以竊取AWS密鑰。在另一個例子中，一項幫助開源開發人員編寫和測試軟件的常用服務被發現泄露了數千個身份驗證令牌和其他機密，允許黑客訪問開發人員在Docker、Github、AWS和其他代碼存儲庫上的私人賬戶.

 

但是有人會問，是否已經有方法可以保護密碼、密鑰和其他憑據?有，這就是問題的一部分。

 

 

在管理機密方面，當今的安全解決方案存在相當低的效率和重復。其中的一些挑戰是：

 

(1)機密蔓延

 

很多企業將業務從內部部署遷移到云端——機密也是如此。全球三大云計算提供商和其他云計算提供商都提供自己的機密管理解決方案，大多數企業默認接受這些解決方案，只是為了獲得更好的解決方案，還有什么比云計算提供商自己采用的平臺更安全的呢?

 

但是，隨著混合多云架構占據中心位置(這是唯一一種越來越多采用的IT運營模型)，大多數DevOps團隊發現自己要處理充滿不同工作負載的微服務和容器的多個環境。這些環境擁有數千個相互通信的機器對機器組件，導致流通中的密鑰、令牌和其他機密的數量多得驚人。

 

機密的爆炸式增長和分散對管理員和DevOps從業者來說是一個巨大的運營負擔。當今可用的大量云計算和虛擬化解決方案讓用戶可以大規模創建和銷毀虛擬機和應用程序。不用說，這些虛擬機實例中的每一個都有自己的一組需要管理的機密。此外，在企業中僅SSH密鑰就可以達到數百萬個。除此之外，Ansible作業、Kubernetes容器和日常批處理例程都傾向于使用需要輪換的密碼。

 

所有這些系統都無法訪問其環境外部的安全資源。沒有統一的控制平臺可以幫助企業管理存儲在不同平臺上的多個機密存儲庫。

 

(2)能見度不足

 

本地化到不同環境(如云平臺、內部部署、邊緣計算或混合部署)的靜態機密由不同的個人、團隊和管理員管理，從而創建“機密孤島”。這不可避免地會導致審計挑戰和安全漏洞。

 

(3)保管庫解決方案的復雜性

 

由于大量現有和遺留工具和平臺(包括DevOps和非DevOps)以及每個工具和平臺的大量擴展，本地庫解決方案在許多情況下都無法正常工作。此外，在混合環境中很難根據底層計算、存儲和網絡基礎設施配置保管庫。頻繁更新的需求只會增加內部部署保管庫的復雜性。

 

基于云計算的保管庫也并不安全。一個巨大的危險信號是，這些產品是云計算提供商專有的，只支持在他們自己的環境和生態系統中運行的工作負載，因此它們也不適合混合云架構。即使企業只采用一個主要的云提供商提供的服務，也只會導致保管庫蔓延。另一個問題是企業的主密鑰與云計算提供商共享。這意味著流氓管理員、黑客或政府機構可以訪問它們，而用戶卻束手無策。

 

 

完美的機密管理解決方案可能并不存在。但這并不意味著企業無法創建萬無一失的身份和訪問管理(IAM)策略來保護自己免受已知類型的威脅。

 

身份和訪問管理(IAM)是新的邊界——它是現代安全策略的基礎。隨著自動化程度的提高和隨需求波動的動態工作負載的數量的增加，驗證人類和機器用戶的身份(身份驗證)并證明他們訪問資源(授權)的需求變得越來越復雜。

 

此外，身份驗證的性質在不斷變化。應用程序和數據庫模塊不再像以前那樣局限于一些代碼。與其相反，它們是微服務和子組件的復雜且動態的集成，每個子組件都有自己的身份驗證過程。

 

以下是在多云環境中運營或擁有內部部署、私有云和公有云系統混合組合的企業應該在機密管理平臺或解決方案中尋找的內容：

 

·適用于混合云、多云和多個云區域設置：這可能是企業最重要的一個關注因素。盡可能選擇使用云原生技術與跨平臺、跨環境工作流無縫集成的平臺。企業的機密管理解決方案應支持啟用身份和訪問管理(IAM)的機器對機器和人對機器身份驗證和驗證不同類型的機密，例如SSH證書、API密鑰、x.509證書、加密密鑰等，以強制執行連續安全合規性。

 

·適用于不同的身份驗證協議、語言和設備：重要的是，企業的機密管理工具通過所有主要接口(當然)包括命令行、GUI、RESTAPI和SDK，通過第三方身份提供者支持人工、硬件和軟件身份驗證主要語言。不用說，它應該促進動態機密并與常見的基于云的平臺集成，例如Docker、Kubernetes、Terraform、Ansible和Jenkins，以實現不間斷的DevOps操作。

 

然后是擴展問題。如果企業想以“云計算規模”增長并擴展其地理或技術基礎設施，需要能夠擴展其機密管理功能以支持所有現有以及即將推出的工具和插件。

 

·可以通過統一的SaaS平臺進行管理：當今的安全團隊需要對企業使用的所有環境中的所有用戶、應用程序和設備的身份驗證進行集中可見性和控制。Hareven說，“一些安全負責人表示，直觀的基于SaaS的機密管理工具可以實時查看每個機密使用實例、審計日志記錄和強大的分析，這是他們的需求。”

 

·實現機密零問題并實施零信任模型：密碼管理是當今的常見功能。例如某人可能有一個電子表格或文檔，其中存儲了他們使用的各種應用程序或控制面板的所有密碼。然而，要打開這個電子表格，他們可能需要另一個密碼。他們還需要用戶憑據才能登錄操作系統并訪問電子表格。

 

機密管理解決方案應該提供一組初始憑證，其中包含一個臨時令牌或密鑰，用于進行持續身份驗證，以便永遠不會泄露機密。

 

這屬于零信任架構(ZTA)的前提，該架構遵循最小特權(PoLP)原則，在這一原則下，用戶和應用程序被授予“即時”和細粒度訪問特定時間內的特定數量的資源——只有在向管理員“證明”他們的請求合理之后。這些特權是動態授予的，并在預設的時間范圍后自動過期。

 

 

理想的機密管理平臺通過使不同的團隊能夠訪問他們需要的資源并自主管理他們的機密，從而為企業中的DevOps、云遷移和數字化轉型提供支持。通過從云中“即服務”交付的解決方案，可以減少維護開銷、提高可用性并擴展運營，以滿足企業的增長目標。

 

 

國內主流的to B IT門戶，同時在運營國內最大的甲方CIO專家庫和智力輸出及社交平臺-信眾智（www.cioall.com）。同時運營18個IT行業公眾號（微信搜索D1net即可關注）。

 

版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。