關注留言點讚，帶你了解最流行的軟體開發知識與最新科技行業趨勢。

IAM 代表「身份和訪問管理」。IAM 為 DevOps 中的基本問題提供了答案：「誰可以訪問什麼？」

IAM 的根源可以追溯到計算的早期，當時 UNIX 系統的用戶需要用戶名和密碼才能訪問他們的帳戶和文件。隨著系統變得越來越複雜，數量越來越多，並且需要訪問的用戶數量越來越多，輕量級目錄訪問協議 LDAP等身份管理解決方案變得越來越流行，中央團隊可以在其中管理多個部門和角色的訪問。

DevOps 的革命為訪問管理增加了一層新的複雜性；非人類實體也需要訪問數據和系統。這些非人類包括同一平台上的應用程式以及第三方系統，使事情變得更加複雜。

雖然它通常與 AWS 及其AWS IAM 服務相關聯，但 IAM 並不限於其平台。所有雲提供商，例如Google Cloud和Azure DevOps，都提供允許用戶訪問資源和系統的 IAM 解決方案。

對於本文的其餘部分，我們將研究過去十年中圍繞我們開始時提出的基本問題「誰可以訪問什麼？」的每個部分演變而來的通用最佳實踐：

• 誰：人類和非人類實體（應用程式和機器工作者）
• 可以訪問：權限集
• 什麼：資源和系統
  

誰：IAM 中的用戶

在 IAM 中，我們關注兩大類：人類和非人類。

人通常是開發人員、工程師、分析師或任何其他需要訪問 DevOps 環境中的數據和資源的人。IAM 服務允許您為特定角色創建特定用戶，並為他們分配任何所需的權限。這些不是單獨的帳戶，而只是單個帳戶下的用戶。

非人類實體，通常也稱為機器身份，是需要能夠與您的 CI/CD 管道連接和交互的任何系統、API、平台或服務。IAM 系統可以授予這些實體他們需要的訪問權限，並嚴格限制它的範圍，只允許在正確的條件下進行特定的訪問。我們將在資源和服務部分進一步探討這種訪問方式。

無論何種用戶，都應始終應用最小權限原則。任何創建或批准的新用戶都應該從沒有任何訪問權限開始，然後只被授予可以讓他們完成工作的權限，但沒有進一步的權限。這就是我們所說的零信任。

默認情況下，大多數雲提供商使用此模型，以便任何新用戶都將從零權限開始。只有分配了角色或特定權限後，他們才能訪問任何資源。

權限的分階段方法

雖然我們認為每個人都應該傾向於零信任，但平衡訪問限制與實際業務需求也很重要。考慮這一點的一個好方法是根據項目的成熟度或進度來確定訪問範圍。

例如，對於新產品或應用程式的早期研究，可能需要為用戶提供不受限制的訪問權限，以有效地獲得最小可行產品 MVP。在這種情況下，最好創建一個專用於該項目並與您的生產基礎設施隔離的全新帳戶。隨著項目的生產進展，可以應用和微調額外的訪問限制，只允許完成應用程式所需的訪問。最後，在啟動時，權限可以與現有的公司政策和最佳實踐保持一致。

身份提供者和臨時憑證

對於人類用戶來說，最好的憑據是短暫的，而且沒有人見過或不知道。得益於AWS IAM Identity Center或Google Cloud Identity等身份提供商，這完全可以實現。您還可以同步受信任的外部 ID 源，如Okta Universal Directory、Microsoft Active Domain或任何基於SAML的開源系統，以獲得相同的結果。

當利用身份提供者時，任何用戶都會使用他們的身份服務進行身份驗證，然後獲得一個永遠不會暴露給用戶的短期令牌或證書，因此幾乎不可能泄露。這種方法還有一些額外的優點，例如：

• 易於管理的集中式用戶存儲
• 不斷輪換密碼減少了密碼疲勞
• 減少整體安全的系統數量
• 更易於保護和審計的集中式 ID 管理器
  
  

根用戶

IAM 中有一種特殊的人類用戶控制著組織在雲提供商上的帳戶：root，也稱為超級管理員。這些用戶最終負責供應訪問、資源和計費。這些是非常強大的帳戶，應謹慎使用。

完全避免使用根憑據是個好主意。相反，創建唯一的用戶來執行特定的工作。一些供應商，如 AWS，允許您阻止根用戶管理或使用某些流程，確保這些特殊和強大的帳戶受到保護。

由於根帳戶必然需要長期密碼，因此創建複雜的高熵密碼並保護它們至關重要。我們強烈建議使用 LastPass 或 1Password 等密碼管理器。結合多因素認證，MFA。MFA 意味著擁有一些你知道的東西，比如密碼，結合你擁有的東西，比如谷歌身份驗證器一次性密碼、OTP，或者更好的是，硬體令牌。

另一種方法是創建非常長且複雜的密碼，但在登錄後永遠不會將它們存儲在任何地方，而是在每次需要訪問時依賴密碼重置。

確保根用戶的長期憑據永遠不會出現在您的代碼或配置中的任何地方對您的企業至關重要。事實上，最好的做法是永遠不要使用你的根用戶訪問密鑰，最好是刪除它。雖然這聽起來很激進，但它有兩個有趣的好處：它限制了可以破壞帳戶的向量（請記住，這個帳戶具有完全管理權限！），並且它強制創建具有受限權限的基於角色的帳戶。

信任是好的，但驗證更好。

保護憑據恢復路徑

確保您還保護了根憑據恢復流程。不幸的是，最近針對管理員級別密碼重置的網絡釣魚嘗試穩步增加。攻擊者知道這是嘗試竊取登錄憑據的好方法。

任何密碼重置策略的一個重要元素是對用於恢復的任何電子郵件帳戶實施 MFA。另一種策略是為這些備受推崇且功能強大的證書創建專用電子郵件帳戶。如果惡意行為者不知道或無法猜測您的根用戶的相關電子郵件地址，那麼他們將更難發起攻擊。

確保您的用戶列表準確且最新

最容易管理的用戶是不存在的用戶。一旦不再需要某個用戶，就將其從系統中刪除。確保您定期審核用戶以查看他們是否仍然活躍並且行為是否符合預期。如果您發現您不認識的用戶正在訪問您的資源，可能是時候與您的安全團隊進行對話了。

可以訪問——IAM 中的權限

IAM 等式的第二部分，「誰可以訪問什麼？」 正在設置權限。權限可以按用戶或按角色管理。

有時可能需要為長期用戶帳戶設置權限，但這意味著您將需要隨著時間的推移監控和管理每個用戶的權限。這也意味著您將需要跟蹤哪些人擁有哪些權限，以避免重疊或配置錯誤。

可用於權限的另一條路徑是創建角色。可以為角色分配任意數量的權限，然後您可以為用戶分配這些角色。這種方法可以更輕鬆地管理更大規模的權限集，並快速查看誰有權訪問每個角色。如果將新資源添加到您的設置中，您可以快速向具有角色的任何人添加所需的權限，而不是設置單個用戶權限。它也可以更快地廣泛撤銷對服務的訪問權限。

AWS EPARC 模型

雖然 IAM 由各種供應商提供，但仔細研究 AWS 用於其權限結構 EPARC 的模型可能會有所幫助：

• 效果 ——如果允許許可會發生什麼
• 原則——允許或拒絕訪問的用戶或機器工人
• 行動——如果允許或拒絕訪問將執行什麼
• 資源——要訪問的服務或數據
• 條件——可以授予訪問權限的條件

如果您可以提供並理解滿足 EPARC 模型所需的所有信息，那麼您就可以很好地制定政策。

使用條件進一步限制意外訪問

在定義策略時，您可以使用條件來進一步縮小訪問權限。條件是用於定義允許權限的特定情況的細粒度控制。您可以將這些視為「但是，僅當」語句。例如：

• 授予對資源的訪問權限，但前提是訪問請求來自特定子網並在特定 IP 範圍內
• 授予對資源的訪問權限，但前提是訪問請求以特定前綴開頭
• 允許創建 AWS Lambda 函數，但前提是使用 AWS CloudFormation
• 允許 Google Cloud Function，但前提是它會存在於特定的 VPC 中

雖然所有雲平台在實施細節上略有不同，但都支持實施條件。

最後，IAM 的最後一塊「誰可以訪問什麼？」 難題是用戶可以訪問的資源和服務。在「用戶」是非人類實體的情況下，您可以將其視為「可以訪問資源的資源」。幸運的是，如果您正確處理了用戶身份驗證和權限，那麼這部分就不需要考慮太多。

基本上有兩種類型的服務；同一平台上的系統和平台外存在的第三方服務。在極少數情況下，團隊構建了自己的私有雲，可能根本沒有任何「平台上」應用程式。

您的數據邊界

查看資源和服務的一種好方法是考慮它們存在於您的「數據邊界」之內或之外，我們可以將其定義為您的應用程式與網際網路其餘部分之間的邊界。簡而言之，您只希望可信身份能夠從預期位置訪問可信資源。如果資源在您的數據邊界之外，則應該拒絕訪問。同樣，如果此邊界之外的任何人試圖訪問任何受信任的服務，那麼訪問也應該被拒絕，並且很可能應該敲響警鐘。

對於同一平台上的系統，您通常可以依靠他們提供的身份提供者服務來確保它是可信資源。即使它在您的帳戶中，設置條件以確保只有預期的用戶才能訪問任何服務仍然是個好主意。

對於第三方應用程式，總是會想快速將訪問憑證嵌入到您的配置中……永遠不要這樣做！這是攻擊者在突破期間橫向擴展的主要路徑之一，有時，這是突破的起源。相反，為了使它們成為可信資源，可以依靠像 Hashicorp Vault 這樣的工具來存儲任何長期存在的憑證。或者，更好的是，與證書頒發機構服務集成，通過自動生成和管理的證書自動進行身份驗證。

雲提供商希望您取得成功並實現最佳安全策略。這就是AWS IAM Access Analyzer和Google Cloud Policy Analyzer等工具背後的動機。這些免費工具可以幫助您了解當前設置並對其進行微調。

IAM 分析器可以向您顯示誰擁有哪些權限，同樣重要的是，還可以顯示哪些權限未被使用。應撤銷任何未使用的權限以防止濫用。不應錯過它們，因為完成工作不需要它們。AWS 將這種微調練習稱為「適當調整您的權限」。

除了僅分析現有權限外，這些工具還可以針對給定情況建議最佳權限集。他們還可以驗證您的設置。例如，AWS IAM Access Analyzer 聲稱提供超過 100 項驗證檢查，這些檢查將顯示安全問題、錯誤和一般警告，同時提供優化建議。無論您選擇哪個供應商，請務必查看他們的文檔，了解可以幫助您保持安全的最佳做法和工具。

IAM 最佳實踐是一段旅程

對於許多組織而言，上一次討論甚至考慮 IAM 是在首次實施時。如果這聽起來像你，那麼你並不孤單，但可能是時候重新考慮你的權限並回答這個問題：「誰可以訪問什麼？」。雖然這個問題沒有唯一的正確答案，但所有雲提供商都同意您應該能夠回答這個問題。

在結束本文時，我們想總結一下管理 IAM 的技巧：

WHO：

• 使用 Identity Manager 對用戶進行身份驗證
• 默認情況下為零權限的特定任務創建用戶
• 切勿在日常工作中使用 root 帳戶，並刪除未使用的訪問密鑰
• 使用長期憑據時，確保它們及其恢復路徑受到保護
• 到處執行 MFA

可以訪問：

• 使用角色來管理權限集，分配用戶角色而不是權限
• 分配權限時仔細考慮 EPARC 模型
• 使用「但僅當」條件微調權限
• 使用 IAM 分析器工具定期驗證和優化權限

什麼：

• 從數據邊界的角度思考；只有受信任的身份才能從預期位置訪問受信任的資源
• 切勿將憑據嵌入配置文件
• 儘可能與證書頒發機構服務集成

在您的組織中實現更安全的 IAM 實踐的過程中，請記住 GitGuardian 可以幫助您發現那些長期存在的憑證在您的代碼和文件中的位置。在採用更好的安全實踐時，請確保解決秘密蔓延問題。