將AWS IAM/AWS IAM身份中心引入公司組織/系統【的指南】注意事項

📅 發布日: 2023/08/07, 更新日: 2025/05/05 ⏱️ 預計閱讀時間約11分鐘 (4,549字)

AWS IAM Identity Center是一項服務，用於在多帳戶環境中集中管理使用者和應用程式的身份驗證和授權。
相比之下， AWS IAM是一項服務，用於在單個AWS帳戶中管理使用者和應用程式的身份驗證和授權。本文概述了AWS IAM/AWS IAM Identity Center ，並介紹了在考慮將其引入公司組織或系統時需要檢查的要點。

修訂歷史
什麼是 AWS IAM？
什麼是 AWS IAM 身份中心？
採用注意事項
1. 1. 您的AWS賬戶的合同型別是什麼？
設計考慮因素
相關檔案

修訂歷史

日期	更新詳情
2025/05/05	“設計注意事項”新增“③IAM許可權設計策略定義”

什麼是 AWS IAM？

AWS IAM（以下簡稱“IAM”）是一項用於管理對 AWS 資源的訪問的服務。
使用 IAM，您可以建立使用者、組和角色，並授予這些實體控制對 AWS 資源的訪問的許可權。
IAM 是使用 AWS 的一項重要服務。您可以建立用於操作AWS管理控制檯的“IAM使用者”和用於授予對AWS資源的訪問許可權的“IAM角色”。
但是，如果您按照如下所述使用 AWS IAM Identity Center，則無需建立 IAM 使用者即可進行操作。
使用 IAM 使用者時，您需要頒發憑證才能透過 AWS CLI 或開發工具包進行訪問，但使用 AWS IAM Identity Center 則無需頒發憑證。
為 IAM 使用者頒發憑證需要定期更新，從而增加了管理開銷。如果憑據洩露，還存在濫用風險。
使用 AWS IAM Identity Center，您無需頒發憑證。您可以透過 AWS Access Portal 或在執行 AWS CLI 命令時獲取臨時憑證。

什麼是 AWS IAM 身份中心？

AWS IAM Identity Center（以下簡稱“IIC”）是多賬戶 AWS 環境中的身份和訪問管理服務。
提供AWS訪問門戶，用於統一管理對AWS資源的訪問，提供訪問每個AWS賬戶管理控制檯的連結。
訪問許可權以稱為“許可權集”的單元進行管理，該單元定義對 AWS 賬戶的訪問許可權。
您還可以獲取每個 AWS 賬戶的臨時憑證，該憑證可用於透過 AWS CLI 或 SDK 操作 AWS 資源。
透過與外部身份提供商 (IdP) 整合，您可以使用現有憑據登入訪問門戶。自 2023 年 7 月 30 日起，支援以下 IdP：
Azure AD
賽博方舟
谷歌工作區
跳雲
奧克塔
一次登入
Ping 身份

採用注意事項

1. 您的AWS賬戶的合同型別是什麼？

如果您有多賬戶結構，建議使用IIC、Okta、Entra ID或其他可以管理多個賬戶訪問的IDaaS。IIC 自動將 IAM 角色分配給每個 AWS 賬戶，與 IDaaS 相比減少了運營開銷。
在管理帳戶中啟用 IIC。請務必檢查您的 AWS 賬戶的合同型別以及管理賬戶功能是否可用。
有關合同型別的詳細資訊，請參閱指南：將 AWS Organizations 引入公司結構/系統的注意事項 |Moderniser.repo 。

設計考慮因素

1. 組織利益相關者

設計 IAM 時， 明確組織內利益相關者的角色非常重要。
參考標準化AWS使用指南的最佳實踐|Amazon Web Services Blog ，我以自己的方式組織了定義。
CCoE、通用平臺管理員、安全人員和會計/財務這四個角色可能由同一部門或人員處理，具體取決於組織。

不	角色	描述	職責
01	中央教育中心	促進和運營雲採用中心	制定指導方針
02	通用平臺管理	雲端提供跨系統通用平臺和功能	構建和運營通用平臺
03	安全	維護雲環境的安全	定義安全策略、構建和執行安全功能、安全監控和運營
04	系統管理員	構建並作業系統在雲中執行的系統	AWS資源搭建與運營、系統建設與運營
05	運營	雲環境下的運營管理	系統監控及執行
06	會計/金融	AWS使用成本的分配和最佳化	審查成本分配政策、考慮購買選項、成本監控、支付 AWS 使用費

2.角色分配組織（確定IAM許可權委託的範圍和方式）

決定應向系統管理員委派多少 IAM 管理許可權，以及在執行委派時應採用哪些方法或限制。
IAM 中管理的元素有：“IAM 使用者”、“IAM 組”、“IAM 角色”和“IAM 策略”。
雖然普通平臺管理員可以管理一切，但隨著系統的增長，管理成本會增加，因此可以考慮將IAM管理許可權委託給使用者。
一般來說，考慮使用SCP（服務控制策略）來禁止帳戶級別的特定操作，作為委派給系統管理員的主要方法。
以下是六個典型用例。

使用案例 1：委派管理許可權（IAM 使用者/組除外）

要求專案	細節
使用 AWS Organizations (SCP) 或 IIC	✓ 可用
使用者管理委託	✗ 無法委託給系統
角色委派/策略管理	✓ 可委託給系統

一種有效的內部欺詐對策是刪除不必要的使用者。
有權訪問 AWS 賬戶的使用者必須定期檢查並刪除不必要的使用者。
為防止使用者刪除時的遺漏，使用者管理應由公共平臺管理員進行，而不是委託給系統管理員。
為防止 IAM 角色信任策略配置不當，請考慮使用訪問分析器進行檢測。

使用案例 2：使用許可權邊界委派管理許可權（IAM 使用者/組除外）

要求專案	細節
使用 AWS Organizations (SCP) 或 IIC	✗ 不可用
使用者管理委託	✓ 可委託給系統
角色委派/策略管理	✓ 可委託給系統

如果管理賬戶功能不可用，您可以透過使用許可權邊界限制可授予 IAM 角色的許可權來委派給系統管理員。

使用案例 3：建立系統專用堡壘賬戶並委派所有 IAM 管理許可權

要求專案	細節
使用 AWS Organizations (SCP) 或 IIC	✓/✗ 可用/不可用
使用者管理委託	✓ 可委託給系統
角色委派/策略管理	✓ 可委託給系統

將IAM使用者管理許可權委託給系統管理員時，您還可以建立由系統管理員集中管理的堡壘賬戶。

使用案例 4：委派除 IAM 組之外的 IAM 管理許可權

要求專案	細節
使用 AWS Organizations (SCP) 或 IIC	✗ 不可用
使用者管理委託	✓ 可委託給系統
角色委派/策略管理	✓ 可委託給系統

IAM組由公共平臺管理員管理，系統管理員透過將IAM使用者分配到IAM組來授予IAM使用者許可權。
由於IAM使用者許可權由公共平臺管理員控制，防止系統管理員授予未經授權的許可權。
這也減少了許可權設計的工作量。

使用案例 5：不委派任何 IAM 管理許可權

要求專案	細節
使用 AWS Organizations (SCP) 或 IIC	✓/✗ 可用/不可用
使用者管理委託	✗ 無法委託給系統
角色委派/策略管理	✗ 無法委託給系統

透過讓公共平臺管理員保留所有 IAM 管理許可權，您可以選擇不委託給系統管理員。
由於必須根據系統管理員的請求建立IAM使用者和角色，因此管理成本可能會增加。

3. 定義IAM許可權設計策略

設計 IAM 許可權的主要挑戰之一是確定如何嚴格地應用最小許可權原則。
作為最佳實踐，建議僅向 IAM 使用者和 IAM 角色授予必要的最低許可權。
但是，限制IAM使用者和角色的許可權可能會增加系統管理員的操作負擔。
因此， 提前評估與授予的IAM許可權相關的業務風險並在可接受的風險範圍內授予許可權非常重要。
除了 IAM 許可權控制之外，使用 AWS Organizations 的 SCP（服務控制策略）可以幫助減輕 IAM 許可權設計的負擔。
正確劃分AWS賬戶也很重要。透過劃分AWS賬戶，即使IAM許可權被不當授予，影響也可以受到限制。
您可以使用三種型別的策略來授予 IAM 許可權：
內聯政策
AWS 託管策略
客戶管理政策
其中，“AWS 託管策略”由 AWS 提供，並在 AWS 正確評估許可權後提供。透過使用這些策略，您可以授予每個 AWS 服務的寫入和讀取許可權。
基本上，建議使用AWS託管策略。但是，由於 AWS 託管策略可能會授予過多的許可權，因此請考慮使用“客戶託管策略”或“內聯策略”來根據需要進一步限制許可權。
例如，在以下模式中，考慮使用“客戶管理策略”或“內聯策略”來限制許可權。

模式一：授予KMS金鑰管理許可權

要使用 AWS 託管策略授予 KMS 金鑰的管理許可權，您可以使用 AWS 託管策略“AWSKeyManagementServicePowerUser”。
參考： AWSKeyManagementServicePowerUser - AWS 託管策略
但是，使用此策略將為 KMS 金鑰授予強大的許可權，例如建立或刪除金鑰以及更改 IAM 策略。
因此， 考慮使用 IAM 策略僅授予特定 KMS 金鑰的許可權。
例如，以下 IAM 策略授予解密使用具有特定標籤的 KMS 金鑰加密的資料的許可權：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                   "kms:Decrypt",
                   "kms:GenerateDataKey"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/System": "SystemA"
                }
            }
        }
    ]
}

模式2：授予SSM Automation / Lambda / Step Functions等執行許可權

授予 AWS 資源（例如 Lambda 或 Step Functions）的執行許可權時，您將授予執行這些資源時所行使的許可權。
如果執行這些資源會帶來業務風險，請考慮使用 IAM 策略限制執行許可權。
例如，透過使用以下 IAM 策略，您可以授予執行遵循特定命名約定的 Lambda 函式的許可權。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                   "lambda:InvokeFunction"
            ],
            "Resource": [
                "arn:aws:lambda:ap-northeast-1:123456789012:function:SystemA-*"
            ]
        }
    ]
}

模式 3：在外部賬戶中承擔 IAM 角色

當您需要在外部賬戶中代入 IAM 角色時，您可以使用 IAM 策略授予 AssumeRole 許可權。
無法使用 AWS 託管策略授予此許可權，因此您必須使用自定義 IAM 策略來授予許可權。
例如，以下 IAM 策略授予擔任特定 IAM 角色的許可權。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                   "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::123456789012:role/SystemA-*"
            ]
        }
    ]
}

模式 4：當資料管理員和使用者不同時

使用 S3 或 DynamoDB 等資料儲存時，資料管理員和使用者可能不同。
例如，如果S3儲存桶的管理員不同，您可以使用IAM策略向特定S3儲存桶管理員授予許可權。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                   "s3:PutObject",
                   "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::systema-bucket",
                "arn:aws:s3:::systema-bucket/*"
            ]
        }
    ]
}