本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
IAM 資源
通過進行簡短的調查 |
雖然 AWS Identity and Access Management (IAM) 不是傳統架構圖中包含的服務,但它涉及 AWS 組織、AWS 帳戶和 AWS 服務的各個層面。您必須先建立 IAM 實體並授予許可,才能部署任何 AWS 服務。IAM 的完整說明已超出本文件的範圍,但本節提供最佳實務建議的重要摘要,以及其他資源的指引。
-
如需 IAM 最佳實務,請參閱 AWS 文件中的 IAM 中的安全最佳實務、AWS 安全部落格中的 IAM 文章
,以及 AWS RE: Invent 簡報 。 -
AWS Well-Architected 安全性支柱概述了許可管理程序中的關鍵步驟:定義許可保護、授予最低權限存取權限、分析公共和跨帳戶存取、安全地共用資源、持續減少許可,以及建立緊急存取程序。
-
下表及其隨附說明提供有關可用 IAM 許可政策類型以及如何在安全性架構中使用它們的建議指導的高階概觀。若要進一步了解,請參閱 AWS RE: Invent 2020 影片,了解如何選擇適當的 IAM 政策組合
。
使用案例或政策 |
效果 |
管理者 |
用途 |
相關 |
影響 |
部署於 |
服務控制政策 (SCP) |
Restrict |
中央小組,例如平台或安全團隊 [1] |
護欄,治理 |
組織、OU、帳戶 |
組織、OU 及帳戶中的所有主參與者 |
組織管理帳戶 [2] |
基準帳戶自動化政策 (平台用來操作帳戶的 IAM 角色) |
授予和限制 |
中央團隊,例如平台、安全性或 IAM 團隊 [1] |
(基準線) 非工作負載自動化角色的權限 [3] |
單一帳戶 [4] |
成員帳戶中自動化使用的主參與者 |
成員帳戶 |
基準人力政策 (授與使用者執行工作權限的 IAM 角色) |
授予和限制 |
中央團隊,例如平台、安全性或 IAM 團隊 [1] |
人類角色的權限 [5] |
單一帳戶 [4] |
同盟主體 [5] 和 IAM 使用者 [6] |
成員帳戶 |
權限界限 (授權的開發人員可以指派給另一個主體的最大權限) |
Restrict |
中央團隊,例如平台、安全性或 IAM 團隊 [1] |
應用程式角色的護欄 (必須套用) |
單一帳戶 [4] |
此帳戶中應用程式或工作負載的個別角色 [7] |
成員帳戶 |
應用程式的機器角色原則 (附加至開發人員部署基礎結構的角色) |
授予和限制 |
委派給開發者 [8] |
應用程式或工作負載的權限 [9] |
單一帳戶 |
此帳戶中的本金 |
成員帳戶 |
資源政策 |
授予和限制 |
委派給開發人員 [8,10] |
資源的權限 |
單一帳戶 |
帳戶中的本金 [11] |
成員帳戶 |
表中的注意事項:
-
企業擁有許多集中式團隊 (例如雲端平台、安全性作業或身分識別與存取管理團隊),這些團隊會劃分這些獨立控制項的責任,並同儕審查彼此的原則。表格中的範例是預留位置。您將需要確定最有效的責任分離為您的企業。
-
若要使用 SCP,您必須啟用 AWS Organizations 內的所有功能。
-
通常需要常見的基準角色和政策來啟用自動化,例如管道的許可、部署工具、監控工具 (例如 AWS Lambda 和 AWS Config 規則) 以及其他許可。此組態通常會在佈建帳戶時傳遞。
-
雖然這些資源與單一帳戶中的資源 (例如角色或政策) 有關,但是可以使用 AWS CloudFormation StackSets 將它們複製或部署到多個帳戶。
-
定義由中央團隊 (通常在帳戶佈建期間) 部署至所有成員帳戶的核心基準人力角色和原則集。範例包括平台團隊中的開發人員、IAM 團隊和安全稽核團隊。
-
盡可能使用聯合身分識別 (而不是本機 IAM 使用者)。
-
委派的系統管理員會使用權限界限。此 IAM 政策會定義最大許可並覆寫其他政策 (包括
“*:*”
允許對資源執行所有動作的政策)。基準人力策略中應需要權限界限,作為建立角色 (例如工作負載效能角色) 和附加原則的條件。其他組態 (例如 SCP) 會強制執行權限界限的附加。 -
這假設已部署足夠的護欄 (例如 SCP 和權限界限)。
-
這些選擇性原則可以在帳戶佈建期間提供,或作為應用程式開發程序的一部分提供。建立和附加這些原則的權限將由應用程式開發人員自己的權限控制。
-
除了本機帳戶許可之外,集中式團隊 (例如雲端平台團隊或安全營運團隊) 通常會管理某些以資源為基礎的政策,以便跨帳戶存取以操作帳戶 (例如,為記錄提供 S3 儲存貯體的存取權)。
-
以資源為基礎的 IAM 政策可參考任何帳戶中的任何主體,以允許或拒絕對其資源的存取。它甚至可以引用匿名主體以啟用公共訪問。
確保 IAM 身分僅具有劃定良好的一組任務所需的許可,對於降低惡意或無意濫用許可的風險至關重要。建立和維護最低權限模型需要有意的計劃,以持續更新、評估和減輕過剩的權限。以下是該計劃的一些其他建議:
-
使用您組織的治理模型和建立的風險偏好來建立特定的護欄和權限界限。
-
通過不斷迭代過程實現最小權限。這不是一次性的練習。
-
使用 SCP 降低可採取行動的風險。這些措施旨在成為廣泛的護欄,而不是狹窄針對性的控制措施。
-
使用許可界限以更安全的方式委派 IAM 管理。
-
確保委派管理員將適當的 IAM 界限政策附加到他們建立的角色和使用者。
-
-
作為一 defense-in-depth 種方法 (與身分型政策搭配使用),使用以資源為基礎的 IAM 政策拒絕廣泛存取資源。
-
使用 IAM 存取顧問、AWS CloudTrail、AWS IAM 存取分析器和相關工具定期分析授與的歷史使用情況和許可。立即修復明顯的過度權限。
-
在適用的情況下將廣泛動作範圍設定為特定資源,而不是使用星號作為萬用字元來指示所有資源。
-
實作機制,根據請求快速識別、檢閱和核准 IAM 政策例外。