科技

企業機密管理快速入門指南

Vendor Icon

CIO Taiwan

12月. 21, 2022

1200x630_1221

集中管理用於存取應用程式、服務和所有 IT 生態系統其他部分的工具、方法和憑證是值得做的事情。

文/Dipti Parmar‧譯/酷魯


今天企業 IT 情境的一大特點莫過於持續性的數位轉型和史詩級的資料生成。隨著遠端和行動辦公成為後疫情時代的新常態,行動化和敏捷性已成為企業營運持續性的重要驅動力。

為了實現每一個可能業務功能的自動化和整合,同時集中並加速資料和資訊流,進而提高生產力並提供更好的客戶體驗,企業組織莫不正透過複雜的混合多雲營運模型來打造靈活的開發營運(DevOps)環境。

然而,隨著行動化和即時資料的增加,企業責任也越來越大。企業在維護資料、服務和個人可識別資訊(Personally Identifiable Information,PII)安全方面面臨越來越多的挑戰。儘管技術不斷進步,但資料外洩事件的發生頻率與數量年復一年地刷新紀錄。

企業如何改進自身資料儲存、管理和保護機制,以確保員工能夠直截了當地存取數位資源,同時加強整個 IT 基礎設施的安全性?

答案就在有效的機密管理(secrets management)。

什麼是機密管理?為什麼需要機密管理?

機密管理是一套適當的工具和最佳實踐,用於在整個生命週期內安全地儲存、存取和集中管理數位身分識別憑證(或「機密」)。機密是用於身分驗證和授權的資料項 ─ 它們包括密碼、加密公鑰和私鑰、SSH 金鑰、應用程式介面(API)、令牌(Token)和證書。機器和人類都使用機密進行身分驗證和交流。

但首先你為什麼需要機密管理呢?

「隨著朝向混合多雲基礎設施的普遍移轉,以及對應用程式容器化的日漸依賴,機器和人類持續存取系統和資料的需求大幅成長。例如,越來越多的應用程式必須不斷地存取不同的資料來源、雲端服務和伺服器,而每個資源通常需要不同類型的憑證。這在 DevOps 過程中產生了對機密的指數型成長需求,」基於 SaaS 服務之機密管理工具 Akeyless 執行長暨共同創辦人 Oded Hareven 解釋道。

讓它變得棘手的是,開發人員經常將各種機密編碼到應用程式或微服務程式碼、腳本、自動化工具和程式碼庫(Code Repository)中 — 所有這些都常駐在不同的基礎架構中。更糟糕的是,這些程式碼處於不同的開發階段,存在管理不當和未受保護的真正風險。其結果是對機密缺乏全面的控制和整合,導致了安全界所謂「機密散亂」(Secret Sprawl)的狀況發生。

[ 加入 CIO Taiwan 官方 LINE 與 Facebook ,與全球CIO同步獲取精華見解 ]

麻煩還不止於此。保存在雲端平臺中執行持續整合/持續部署(Continuous Integration/Continuous Delivery,CI/CD)的機密,會根據其性質被要求用於管理和允許存取其他機器和軟體。對此,他們需要儲存機密和簽章金鑰(用於加密程式碼和軟體更新),但這些金鑰經常儲存在不安全的位置,例如開發人員的筆記型電腦或組建伺服器。

「機密散亂」不僅使憑證難以追蹤和管理,而且容易受到駭客攻擊。事實上,根據美國第二大電信業者 Verizon 的一份報告指出,在所有資料外洩事件中,憑證遭竊就占了一半。

最近許多駭客攻擊,包括軟體供應鏈駭客,便充份利用了存放在程式碼中的機密,這些機密再次儲存在像是 GitHub 等易於存取的程式碼庫中。事實上,GitHub 最近在數千個私有程式碼庫中偵測到超過 70 萬個憑證有潛在曝光外洩的風險,駭客隨時都可輕易竊走。

這樣的例子層出不窮。最近曝光的軟體供應鏈攻擊就劫持了熱門的 PHP 和 Python 庫,以竊取 AWS 金鑰。在另一個例子中,一個專門協助開源開發人員編寫和測試軟體的常用服務,發生數千個身分驗證令牌和其他機密外洩的嚴重事件,這使得駭客得以存取開發人員在 Docker、GitHub、AWS 和其他程式碼庫上的私人帳號。

但是,你可能會問,保護密碼、金鑰和其他憑證的可行方法不是有無數種嗎?

的確有很多種。但這反而是問題的一部分。

機密管理的挑戰

在機密管理方面,當今安全解決方案存在著相當大的效率不彰及重複問題。其中一些挑戰分別羅列如下:

● 機密散亂

整個世界正從「地端」向「雲端」移轉 — 機密也一樣。三大雲端服務供應商以及其他供應商都有提供自家的機密管理解決方案,大多數公司只能被迫預設接受這些解決方案,只因為缺乏更好的解決方案 — 還有什麼能比供應商自己的平臺更安全呢?

但是,隨著混合多雲架構成為主流焦點(這是唯一採用率不斷在成長的 IT 營運模型),大多數 DevOps 團隊發現自己要處理多個環境,這些環境充滿了針對不同工作負載的微服務和容器。它們又有會相互通訊的成千上萬個機器對機器元件,這導致了流通中的金鑰、令牌和其他機密的數量多到令人難以置信的地步。

機密的爆炸性成長和過度分散對管理員和 DevOps 從業人員來說是一個巨大的操作負擔。當前無數雲端和虛擬化解決方案讓用戶能大規模地創建和銷毀 VM 虛擬機器和應用程式。毋庸贅言的,每個VM 實例都自帶一組需要管理的機密。再者,在企業組織中,光 SSH 金鑰就可以達到數百萬個。除此之外,不論 Ansible 任務、Kubernetes 容器和日常批次處理常式都傾向於擁有需要輪替的密碼。

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

● 能見度不足

常駐在不同環境(如雲端、地端、邊緣或混合環境)的靜態機密,會由不同的個人、團隊和管理人員管理,進而造就出許多「機密孤島」。這不可避免地會導致稽核挑戰和安全性漏洞的形成。

● 機密儲存庫解決方案的複雜性

由於傳統舊有的工具和平臺(包括 DevOps 和非 DevOps)的數量龐大,而且每個工具和平臺都有大量的擴展,致使地端儲存庫解決方案(vault solution)在很多情況下的效益不彰。再者,在混合環境中很難根據底層運算、儲存和網路基礎設施配置儲存庫。而且頻繁更新的需要更只會增加地端儲存庫的複雜性。

雲端式儲存庫也好不到哪裡去。一個巨大的危險信號是,這些產品與服務是供應商專有的,只支援在他們自己的環境和生態系統中運行的工作負載,因此它們並不適合混合雲架構。即使你只使用一個主要的雲端供應商,一個多雲環境,它也只會導致「儲存庫散亂」(vault sprawl)的情形發生。另一個疑慮是,你的主金鑰(master key)會與雲端供應商共用。這意味著一個惡意管理員、駭客或政府機構可以存取這些主金鑰,而且你將無能為力。

完美的機密管理解決方案…

儘管可能不存在完美方案,但這並不意味著你不能建立可靠的身分識別與存取管理(Identity and Access Management,IAM)策略,以確保你的企業免受所有已知威脅和所有已知類型威脅之危害。

IAM 是新的安全邊界 — 它是現代安全策略的基礎。隨著自動化程度的提高和隨需求波動之動態工作負載的數量增加,不論是驗證人和機器用戶的身分(身分驗證),還是證實他們存取資源(授權)的需求是否合法都變得日益複雜。

此外,身分驗證的性質在不斷變化。應用程式和資料庫模組不再像過去那樣局限於大區塊的程式碼。相反,它們是微服務和子元件的複雜與動態整合,每個微服務和子元件都有自己的身分驗證程序。

以下是在多雲環境中營運的企業,或擁有地端、私有雲和公有雲系統的混合組合的企業,所應在機密管理平臺或解決方案中尋找的東西:

● 以混合、多雲和多區域配置工作

這可能是企業最基本的因素。儘可能地選擇使用原生雲端技術將跨平臺、跨環境工作流加以無縫整合的平臺。你的機密管理解決方案應該支援對 SSH 憑證、API 金鑰、x.509 憑證、加密金鑰等不同類型的機密啟用 IAM 的機對機和人對機身分認證和驗證,以確保持續的安全合規性。

● 支援不同身分認證協定、語言和裝置之工作

重要的是,你的機密管理工具會經由第三方身分識別提供者(Identity Provider,IdP)透過所有主要介面(當然包括主要語言的命令列、GUI 圖形使用者介面、REST API 介面和 SDK 軟體開發套件), 支援人工、硬體和軟體身分驗證。毋需贅言的,它應該會催生動態機密(Dynamic Secret),並與 Docker、Kubernetes、Terrform、Ansible 和 Jenkins 等常見基於雲端的平臺整合,以實現不受干擾的 DevOps 操作。

然後是擴展的問題。如果你希望以「雲端規模」成長並擴展你的地理或技術基礎設施,那麼你必須能擴展你的機密管理能力,以支援所有現有和即將到來的工具和外掛程式。

● 可透過統一 SaaS 平臺進行管理

如今的安全團隊需要對跨越所有組織使用環境下所有使用者、應用程式和裝置的身分驗證實現集中化的可見度與控制。「直覺易用的 SaaS 機密管理工具可以即時查看每個機密使用實例、稽核日誌紀錄並提供強健的分析,就我所交談過的每個安全主管而言,這是當前需要的工具,」Hareven 表示。

● 解決零機密問題並加強零信任模型

密碼管理是目前常用的功能。個人可能會使用試算表或文件來儲存他們用於各種應用程式或控制台的所有密碼。然而,要打開這個試算表,他們可能需要另一個密碼。他們還需要使用者憑證才能登錄作業系統並存取試算表。將這個情境乘以你今天擁有的無窮無盡機密,你就會得到「零機密」(Secret Zero)問題。

你的機密管理解決方案應該會為你提供一組包含一個臨時令牌或金鑰的初始憑證,以便持續向父機(Parent Machine)進行身分驗證,這樣「零機密」就不會遭到外洩。

這屬於零信任架構(Zero Trust Architecture,ZTA)的前提,該架構遵循最小權限原則(Principle Of Least Privilege,PoLP),在該原則下,使用者和應用程式被授予在特定時間內對特定數量資源的「即時」(Just-in-time)和精細度存取權 — 只有在向管理員「證明」他們的請求合法之後。這些權限是動態授予的,並在預先設置的時段後自動過期。

守住機密

理想的機密管理平臺透過促使不同團隊存取他們所需的資源並自主管理他們的機密,進而為企業 DevOps、雲端遷移和數位轉型賦能。透過從雲端提供的「某解決方案即服務」,你可以減少維護開銷,提高可用性並擴展你的營運,以滿足貴組織的成長目標。


(本文授權非營利轉載,請註明出處:CIO Taiwan)

內容來源

author avatar
CIO Taiwan
IDG集團的媒體品牌CIO於1987年創刊,為國際性最權威的IT管理專業雜誌。擁有全球最頂尖的IT管理專家作者群,因此能寫出最權威的分析評論、最先進的IT管理觀念。
donate plan

充電計畫

喜歡這篇文章嗎?歡迎幫作者充電,好內容值得更多人支持

瞭解詳情