本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# IAM 資源
<a name="iam-resources"></a>


|  | 
| --- |
| 進行[簡短的問卷](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua)，以影響 AWS 安全參考架構 (AWS SRA) 的未來。 | 

雖然 AWS Identity and Access Management (IAM) 不是包含在傳統架構圖中的服務，它觸及 AWS 組織的各個層面 AWS 帳戶，以及 AWS 服務。 AWS 服務 您必須先建立 IAM 實體並授予許可，才能部署任何 。IAM 的完整說明超出本文件的範圍，但本節提供最佳實務建議和其他資源指標的重要摘要。
+ 如需 IAM 最佳實務，請參閱 AWS 文件中的 [IAM 安全最佳實務、安全](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)部落格中的 [IAM 文章](https://aws.amazon.com/blogs/security/category/security-identity-compliance/aws-identity-and-access-management-iam/)，以及 [AWS re：Invent 簡報](https://www.youtube.com/watch?v=YQsK4MtsELU)。 AWS 
+  AWS Well-Architected 安全支柱概述[許可管理](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html)程序中的關鍵步驟：定義許可護欄、授予最低權限存取、分析公有和跨帳戶存取、安全地共用資源、持續減少許可，以及建立緊急存取程序。
+ 下表及其隨附的備註提供有關可用 IAM 許可政策類型的建議指引，以及如何在安全架構中使用它們的高階概觀。若要進一步了解，請參閱 [AWS re：Invent 2020 影片，了解選擇正確的 IAM 政策組合](https://www.youtube.com/watch?v=o1bfA0SIxBk)。


|  |  |  |  |  |  |  | 
| --- |--- |--- |--- |--- |--- |--- |
| **使用案例或政策** | **效果** | **管理者** | **用途** | **與 相關** | **影響** | **在 中部署** | 
| **服務控制政策 (SCP)** | Restrict | 中央團隊，例如平台或安全團隊 【1】 | 護欄、控管 | Organization、OU、帳戶 | Organization、OU 和帳戶中的所有主體 | 組織管理帳戶 【2】 | 
| **資源控制政策 RCPs)** | Restrict | 中央團隊，例如平台或安全團隊 【1】 | 護欄、控管 | Organization、OU、帳戶 | 成員帳戶中的資源 【12】 | 組織管理帳戶 【2】 | 
| **基準帳戶自動化政策** （平台用來操作帳戶的 IAM 角色） | 授予和限制 | 中央團隊，例如平台、安全或 IAM 團隊 【1】 | （基準） 非工作負載自動化角色的許可 【3】 | 單一帳戶 【4】 | 自動化在成員帳戶中使用的委託人 | 成員帳戶 | 
| **基準人工政策** （授予使用者執行其工作的許可的 IAM 角色） | 授予和限制 | 中央團隊，例如平台、安全或 IAM 團隊 【1】 | 人類角色的許可 【5】 | 單一帳戶 【4】 | 聯合主體 【5】 和 IAM 使用者 【6】 | 成員帳戶 | 
| **許可界限** （授權開發人員可指派給另一個委託人的許可上限） | Restrict | 中央團隊，例如平台、安全或 IAM 團隊 【1】 | 應用程式角色的護欄 （必須套用） | 單一帳戶 【4】 | 此帳戶中應用程式或工作負載的個別角色 【7】 | 成員帳戶 | 
| 應用程式 （連接至開發人員所部署基礎設施的角色） **的機器角色政策**  | 授予和限制 | 委派給開發人員 【8】 | 應用程式或工作負載的許可 【9】 | 單一帳戶 | 此帳戶中的委託人 | 成員帳戶 | 
| **資源政策** | 授予和限制 | 委派給開發人員 【8，10】 | 資源的許可 | 單一帳戶 | 帳戶中的委託人 【11】 | 成員帳戶 | 
| **中央根使用者管理** | 授予和限制 | 中央團隊，例如平台、安全或 IAM 團隊 【1】 | 大規模集中管理成員帳戶根使用者 | 組織 | 成員帳戶中的所有根使用者 | 組織管理帳戶、委派管理員帳戶 | 

資料表的備註：

1. 企業有許多集中式團隊 （例如雲端平台、安全操作或身分和存取管理團隊），這些團隊會劃分這些獨立控制的責任，並對彼此的政策進行對等審核。資料表中的範例為預留位置。您需要為企業確定最有效的職責分離。

1. 若要使用 SCPs，您必須[啟用其中的所有功能](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html) AWS Organizations。

1. 啟用自動化通常需要常見的基準角色和政策，例如管道的許可、部署工具、監控工具 （例如 AWS Lambda 和 AWS Config 規則) 和其他許可。此組態通常會在佈建帳戶時傳送。

1. 雖然這些與單一帳戶中的資源 （例如角色或政策） 有關，但可以使用 [AWS CloudFormation StackSets ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)複寫或部署到多個帳戶。

1. 定義由中央團隊 （通常在帳戶佈建期間） 部署到所有成員帳戶的核心一組基準人工角色和政策。範例包括平台團隊的開發人員、IAM 團隊和安全稽核團隊。

1. 盡可能使用聯合身分 （而非本機 IAM 使用者）。

1. 委派管理員會使用許可界限。此 IAM 政策會定義最大許可，並覆寫其他政策 （包括允許對資源執行所有動作`"*:*"`的政策）。基準人工政策中應該需要許可界限，作為建立角色 （例如工作負載效能角色） 和連接政策的條件。SCPs等其他組態會強制執行許可界限的連接。

1. 這會假設已部署足夠的護欄 （例如 SCPs和許可界限）。

1. 這些選用政策可以在帳戶佈建期間或應用程式開發程序中交付。建立和連接這些政策的許可將由應用程式開發人員自己的許可管理。

1. 除了本機帳戶許可之外，集中式團隊 （例如雲端平台團隊或安全操作團隊） 通常會管理一些以資源為基礎的政策，讓跨帳戶存取能夠操作帳戶 （例如，提供 S3 儲存貯體的存取以進行記錄）。

1. 以資源為基礎的 IAM 政策可以參考任何帳戶中的任何委託人，以允許或拒絕對其資源的存取。它甚至可以參考匿名主體來啟用公開存取。

1. RCPs適用於 子集的資源 AWS 服務。如需詳細資訊，請參閱 文件中的 AWS Organizations [AWS 服務 支援 RCPs 清單](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html#rcp-supported-services)。

確保 IAM 身分只有明確描述任務集所需的許可，對於降低惡意或無意濫用許可的風險至關重要。建立和維護[最低權限模型](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)需要有深思熟慮的計劃，才能持續更新、評估和緩解超額權限。以下是該計畫的一些其他建議：
+ 使用組織的控管模型和已建立的風險偏好來建立特定的護欄和許可界限。
+ 透過*持續反覆運算程序*實作最低權限。這不是一次性練習。
+ 使用 SCPs來降低可行的風險。這些旨在作為廣泛的護欄，而不是窄度目標控制。
+ 使用許可界限，以更安全的方式委派 IAM 管理。
  + 確定委派管理員將適當的 IAM 界限政策連接到他們建立的角色和使用者。
+ 作為defense-in-depth（結合以身分為基礎的政策），請使用以資源為基礎的 IAM 政策來拒絕廣泛存取資源。
+ 使用 IAM Access Advisor AWS CloudTrail、IAM Access Analyzer 和相關工具定期分析授予的歷史用量和許可。立即修復明顯的超額許可。
+ 在適用的情況下，將廣泛的動作範圍涵蓋在特定資源，而不是使用星號做為萬用字元來表示所有資源。
+ 實作機制，根據請求快速識別、檢閱和核准 IAM 政策例外狀況。