理解非人类身份治理的观点

身份可以在沒有被其他身份引用的情況下存在嗎？我們怎麼知道呢？

這可能對於一篇安全技術文章來說有點哲學化，但這是一個在探討非人類身份主題時需要牢記的重要觀點。其實，圍繞安全的一個更好問題是，「身份應該存在嗎，如果它無法被互動？」我們可能無法找到第一個問題的答案，因為證明現實的本質有點超出計算機科學的範疇。然而，許多人一直在努力建設NHI治理工具，以確定機器身份是否存在、為什麼存在，以及回答它是否應該存在的問題。

消除秘密擴散的未來意味著要掌握依賴於秘密的非人類身份的生命周期和相互依賴性。但為什麼是現在呢？讓我們退一步，重新檢視一些關於NHI及其存在的假設。

什麼是非人類身份？

在我們繼續之前，讓我們在這次對話的背景下定義NHI。

In the simplest terms, a non-human identity, also commonly referred to as a machine identity or a workload identity, is any entity that is not human and can perform an action within your system, most commonly interacting exclusively with other non-humans.

這可能是一個Kubernetes pod，需要與數據源互動並將處理後的數據發送到報告系統。這可能是一個將數據提供給中央伺服器的物聯網（IoT）傳感器。這可能是一個基於Slack的聊天機器人。如果在實體創建後不需要任何人類輸入便能完成工作，那麼我們應該將該身份視為「非人類」。

所有這些例子的共同點是它們與另一個系統互動。如果我們希望它們與整個世界溝通，這很容易，因為我們只需指向其他非人身份，並以程序化方式描述它們應該如何互動。然而，我們很可能希望這些系統安全地通信，僅在特定情況下授權特定身份。這推動了訪問管理的秘密演變，從簡單的用戶名/密碼對到 API 金鑰和憑證。

誠然，這是對 NHI 的廣泛定義。然而，通過退一步並考慮這些實體如何通過它們的秘密相互關聯，我們可以縮小我們關注的範圍，從而允許訪問和通信。

所有 NHI 連接到其他系統

您能否構建一個獨立應用程序，不接受任何輸入，不生成任何輸出，也沒有可訪問的接口？這樣的應用程序是否存在於思想實驗之外？儘管思考這個問題很有趣，但現實是我們關心的所有 NHI 都存在於與其他身份溝通的目的。

NHI 本質上需要與其他系統和服務建立連接以實現其目的。這種互聯性意味著每個 NHI 都成為相互依存網絡中的節點。從 NHI 治理的角度來看，這需要保持這些連接的準確和動態庫存，以管理相應的風險。例如，如果一個 NHI 受到破壞，它連接到什麼，攻擊者將能夠訪問什麼進行橫向移動？

適當的 NHI 治理必須包括用於映射和監控這些關係的工具。雖然有許多手動進行的方式，但我們實際上想要的是一種自動化的方法來告訴我們什麼與什麼相連，什麼用於什麼，以及由誰使用。在考慮保護我們的系統時，我們可以利用一個重要事實，即所有 NHI 在安全應用中都必須有秘密來建立該映射，它們必然都有秘密。

所有安全 NHI 必須擁有一個秘密

為了在任何兩個 NHI 之間建立可信的通信，必須為這些實體存在一個唯一的秘密，例如 API 密鑰、令牌或證書，以便進行身份驗證。我們可以使用這個秘密來證明 NHI 的身份並將其映射到生態系統中。問題在於，我們應該在哪裡尋找這些秘密？

在現代企業中，尤其是較大的企業，秘密基本上只能存在於兩個地方。您的第一個選擇是 最佳實踐和最安全的選擇：一個秘密管理系統，例如 CyberArk 的 Conjur、HashiCorp 的 Vault 或 AWS Secrets Manager。另一個選擇則不太安全，但不幸的是，卻是過於常見的：在保險庫之外，在代碼或明文配置中。

企業秘密管理平台，通常被稱為寶庫，對於存儲和保護 NHIs 使用的秘密至關重要。寶庫可以提供所有秘密的唯一真相來源，確保它們在靜態狀態下加密，受到嚴格的訪問控制，並監控未經授權的訪問嘗試。這假設您已經在單一企業秘密管理平台上進行了標準化。實際上，大多數組織同時使用許多寶庫，使得在所有寶庫之間進行同步成為一項額外的挑戰。

團隊可以根據這些秘密的存在來映射所有現有的機器身份。對於使用多個秘密管理解決方案的企業，您需要知道哪些寶庫包含秘密，哪些不包含，以減少在多個寶庫中冗餘存儲同一密鑰所帶來的額外開支。

所有 NHI 秘密都有一個起源故事

機器無法為自己授予權限和訪問權限。每個機器身份都是由人類身份創建或代表的。對於 NHIs 的治理必須包括秘密創建跟踪，以確保每個秘密都可以追溯到其起源，安全分發，並與合法身份相關聯。儘管這一方面可以通過正確使用秘密管理平台來考慮，但我們的數據不斷告訴我們，每年都有一定百分比的秘密外洩，因為我們並未始終使用這些寶庫解決方案。

我們從多年幫助團隊應對事件的經驗中知道，秘密的創建者幾乎總是第一個將憑證引入生態系統的人。我們還可以從代碼歷史或其他系統時間戳信息中得知這一秘密首次出現的時間，這是它被創建或至少以有意義的方式存在的最可能時間。

這是一個至關重要的細節，可能從未在其他地方被正確記錄或文檔化。一旦你了解誰創建了一個秘密以便能夠利用NHI，那麼你就真正理解了我們NHI生命周期的開始。

所有NHI秘密必須授予某些權限集

在創建時，每個NHI秘密必須被授予一定的權限集。範圍決定了身份可以執行的操作以及在哪些系統上執行。這使得權限範圍的確定和強制執行成為治理的關鍵組成部分。

本質上，有兩個風險使得理解秘密的範圍對企業安全至關重要。第一是錯誤配置或過度授權的秘密可能無意中授予對敏感數據或關鍵系統的訪問權限，顯著增加攻擊面。想像一下，意外地將寫入權限授予能訪問客戶個人識別信息的系統。這是一個倒計時，等待威脅行為者找到並利用它。

同樣令人困擾的是，當一個秘密被洩露或泄露時，團隊在首先了解這些權限是如何配置的之前，無法替換它。例如，假設您知道一個關鍵性微服務的密鑰被意外地推送到了公共的 GitHub 存儲庫。在這種情況下，它只是時間問題，它將會被組織外的某人發現並使用。在我們最近的《實踐者之聲》報告中，IT 決策者承認需要 平均 27 天 才能輪換這些關鍵性密鑰。團隊應該能夠在幾秒鐘或幾分鐘內採取行動，而不是幾天。需要提供有關檢測到的秘密的額外上下文資訊的工具，包括它們的角色和權限。當發生泄漏時，迅速了解哪些資產暴露以及受威脅行動者可能造成的損害，對於應對事件時至關重要。確切地知道如何從儀表板視圖或 API 調用中替換它，可能意味著防範入侵和一名受挫的攻擊者發現他們擁有的密鑰無效之間的區別。

所有 NHI 密鑰都需要輪換

機器身份可以並且可能應該在其壽命中擁有許多秘密。如果憑證被保留數月甚至數年，甚至在最壞的情況下是永遠，NHI 秘密曝露或妥協的可能性會越來越大。手動旋轉容易出錯且在操作上負擔沉重，尤其是在存在數千個 NHI 的環境中。自動化秘密旋轉流程是 NHI 治理的重要基石，確保在秘密到期或洩露之前刷新秘密。

對於您寶庫中的任何秘密，旋轉應該是一個簡單的腳本問題。大多數秘密管理平台提供腳本或其他機制來處理安全替換和撤銷舊秘密的微妙舞蹈。

但是對於存在於這些寶庫之外的 NHI 秘密，或者可能分佈在多個寶庫中的相同秘密呢？一個良好的秘密掃描平台需要與這些寶庫無縫集成，以便您的團隊可以更輕鬆地找到並安全地存儲這些秘密在秘密管理器中，為自動旋轉做好準備。GitGuardian 與 CyberArk 的 Conjur 的參考實現更詳細地介紹了您如何完全自動化整個存儲和旋轉過程。

通過識別所有的NHIs並知道它們的創建時間，我們也可以預測它們何時需要輪換。雖然每個團隊都會判斷每個秘密應該存在多長時間，但任何在創建後從未輪換過的秘密都應該被替換。任何超過一年的秘密，或對於一些任務關鍵系統來說，幾天內沒有輪換的秘密也應優先考慮盡快輪換。

所有的NHIs都將有終結期

NHIs，就像它們的人類對應物一樣，有限的生命週期。當服務被淘汰、替換或不再需要時，它們可能被停用。如果不解決NHIs的停用和清理問題，就無法防止未使用的秘密或廢棄連接的持久存在，我們就會產生安全盲點。但是，我們如何知道一個NHI已經走到盡頭，尤其如果它的秘密仍然有效呢？

一個答案是，當一個NHI不再連接到另一個活動系統時，它就不應該再存在。這確保攻擊者無法利用廢棄的NHI秘密在您的環境中佔據一席之地。請記住，攻擊者不在乎秘密應該如何被適當使用；他們只關心他們可以用它做什麼。

通過映射NHI秘密允許的所有關係，您可以識別一個系統何時不再連接到任何其他身份。一旦沒有更多方式讓一個身份進行通信，那麼它及其秘密就不應該再存在。這也意味著該秘密不再需要存儲在您的秘密管理器中，讓您少一件需要存儲和管理的事情。

了解NHIs周圍的世界對安全至關重要

在2022年， CyberArk的研究 顯示，在一個環境中，每個人類身份需要管理至少45個非人類身份。如今這個比例可能接近1比100，並且還在不斷增加。處理您的非人類身份治理和生命周期管理的最佳時間是在幾年前。下一個最佳時間就是現在。

現在是時候採取全周期的方法來保障非人類身份的安全，不僅要清楚您的NHI秘密在哪裡，更重要的是要了解其他連接的NHI。我們在所有行業中都已經過期，需要大規模實施NHI治理。找到並妥善存儲您的秘密只是故事的開始。我們必須更好地記錄和理解NHI秘密的範圍、其年齡、誰實施了它們，以及其他背景信息，例如它們何時應該被更換。

儘管機器身份數量超過人類，但沒有理由獨自解決這個問題；我們都是一起面對這個挑戰的。