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

混淆代理人問題

混淆代理人問題屬於安全性議題，其中沒有執行動作許可的實體可以強制具有更多許可的實體執行該動作。為了防止這種情況，如果您提供第三方 （稱為跨帳戶 ） 或其他 AWS 服務 （稱為跨服務 ） 存取您帳戶中的資源， AWS 會提供可協助您保護帳戶的工具。

有時，您可能需要授予第三方存取您 AWS 資源的存取權 （委派存取權）。例如，假設您決定聘請名為 Example Corp 的第三方公司來監控您的 AWS 帳戶 並協助最佳化成本。為了追蹤您的每日支出，Exeg Corp 需要存取您的 AWS 資源。Example Corp 也會 AWS 帳戶 為其他客戶監控許多其他 。您可以使用 IAM角色，在 AWS 帳戶 和 Example Corp 帳戶之間建立信任關係。此案例的一個重要方面是外部 ID ，您可以在IAM角色信任政策中使用的選用資訊，以指定誰可以擔任角色。外部 ID 的主要功能是解決並防止混淆代理人問題。

在 中 AWS，跨服務模擬可能會導致混淆代理問題。在某個服務 (呼叫服務) 呼叫另一個服務 (被呼叫服務) 時，可能會發生跨服務模擬。可以操縱呼叫服務來使用其許可，以其不應有存取許可的方式對其他客戶的資源採取動作。

預防跨帳戶混淆代理人

下圖說明了跨帳戶混淆代理人問題。

此案例假設如下：

將發生以下情況：

這就是其他客戶可對您的資源進行未授權存取的方式。由於此客戶能夠誘使 Example Corp 無意中操作您的資源，因此 Example Corp 現在是一個「混淆代理人」。

Example Corp 可以透過要求在角色的信任政策中包含 ExternalId 條件檢查來解決混淆代理人問題。Example Corp 為每個客戶生成唯一的 ExternalId 值，並在其請求中使用該值來擔任此角色。因此，ExternalId 值必須在 Example Corp 的客戶中具備唯一性，並由 Example Corp 而非其客戶控制。這就是您從 Example Corp 取得該 ID 且不能自行提供該 ID 的原因。這可防止 Example Corp 成為混淆代理人，並授予其他帳戶的 AWS 資源存取權。

在我們的方案中，假設 Example Corp 為您提供的獨有識別碼是 12345，而為另一個客戶提供的識別碼是 67890。這些識別碼已針對此方案進行簡化。一般而言，這些識別碼為 GUIDs。假定這些識別碼在 Example Corp 的客戶之間是獨有的，它們將是用於外部 ID 的有意義的值。

Example Corp 將為您提供外部 ID 值 12345。然後，您必須將一個 Condition 元素加入到角色的信任政策，該政策要求 sts:ExternalId 值為 12345，如下所示：

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "AWS": "Example Corp's AWS Account ID"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "12345"
      }
    }
  }
}

此政策中的條件元素允許 Example Corp 僅在呼叫包含外部 ID 值 12345 時 AssumeRole API擔任角色。Example Corp 會確保每當代表客戶擔任角色時，一律在 AssumeRole 通話中包含該客戶的外部 ID 值。即使其他客戶將 Example Corp 與您的 一起提供ARN，也無法控制 Example Corp 向其 提出的請求中包含的外部 ID AWS。這有助於防止未經授權的客戶取得對您的資源的存取權限。

下圖說明此程序。

該外部 ID 說明阻止任何其他客戶誘使 Example Corp 無意中存取您的資源。

預防跨服務混淆代理人

建議您在資源型政策中使用 aws:SourceArn、aws:SourceAccount、aws:SourceOrgID 或 aws:SourceOrgPaths 全域條件內容鍵，將服務具備的許可限定於特定資源。使用 僅aws:SourceArn將一個資源與跨服務存取建立關聯。使用 aws:SourceAccount 可讓該帳戶中的任何資源與跨服務使用相關聯。使用 aws:SourceOrgID 允許組織內任何帳戶的任何資源與跨服務使用相關聯。使用 aws:SourceOrgPaths將 AWS Organizations 路徑內帳戶的任何資源與跨服務使用建立關聯。如需有關使用和了解路徑的詳細資訊，請參閱了解 AWS Organizations 實體路徑。

防止混淆代理問題的最精細方法是使用aws:SourceArn全域條件內容索引鍵，並在資源型政策中使用完整的ARN資源。如果您不知道資源ARN的完整內容，或要指定多個資源，請將aws:SourceArn全域條件內容索引鍵與萬用字元 （*） 搭配使用，用於 的未知部分ARN。例如：arn:aws:servicename:*:123456789012:*。

如果該aws:SourceArn值不包含帳戶 ID，例如 Amazon S3 儲存貯體ARN，您必須同時使用 aws:SourceAccount和 aws:SourceArn來限制許可。

若要大規模防範混淆代理人問題，請在資源型政策中使用 aws:SourceOrgID 或 aws:SourceOrgPaths 全域條件內容鍵和資源的組織 ID 或組織路徑。當您新增、移除或移動組織中的帳戶時，包含 aws:SourceOrgID 或 aws:SourceOrgPaths 鍵的政策將會自動包含正確的帳戶，您無需手動更新政策。

對於 non-service-linked角色信任政策 ，信任政策中的每個服務都已執行 iam:PassRole動作，以驗證角色是否與呼叫服務位於相同的帳戶中。因此，不需要搭配這些信任政策使用 aws:SourceAccount、aws:SourceOrgID 或 aws:SourceOrgPaths。在信任政策aws:SourceArn中使用 可讓您指定可代表 擔任角色的資源，例如 Lambda 函數 ARN。有些 AWS 服務 使用 aws:SourceAccount和 aws:SourceArn 對新建立角色的信任政策，但您帳戶中的現有角色不需要使用金鑰。

的跨服務混淆代理預防 AWS Security Token Service

許多 AWS 服務要求您使用 角色，以允許服務代表您存取其他服務的資源。服務會擔任代您執行動作的角色稱為服務角色。角色需要兩個政策：指定允許承擔角色的主體的角色信任政策；以及指定角色可執行動作的許可政策。角色信任政策是 中唯一一種資源型政策IAM。其他 AWS 服務 具有資源型政策，例如 Amazon S3 儲存貯體政策。

當服務代表您擔任角色時，必須允許服務主體執行角色信任政策中的 sts:AssumeRole 動作。當服務呼叫 時sts:AssumeRole， AWS STS 會傳回一組暫時性安全憑證，供服務主體用來存取角色許可政策所允許的資源。當服務在您的帳戶中擔任角色時，您可以在角色信任政策中包含 aws:SourceArn、aws:SourceAccount、aws:SourceOrgID 或 aws:SourceOrgPaths 全域條件內容鍵，以將對角色的存取限定於僅由預期資源產生的請求。

例如，在 中 AWS Systems Manager Incident Manager，您必須選擇一個角色，以允許 Incident Manager 代表您執行 Systems Manager 自動化文件。自動化文件可以包含由 CloudWatch 警示或 EventBridge事件啟動的事件的自動回應計劃。在下列角色信任政策範例中，您可以使用 aws:SourceArn 條件金鑰，根據事件記錄的 限制對服務角色的存取ARN。只有從回應計劃資源 myresponseplan 建立的事件記錄能夠使用此角色。

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "Service": "ssm-incidents.amazonaws.com"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "ArnLike": {
        "aws:SourceArn": "arn:aws:ssm-incidents:*:111122223333:incident-record/myresponseplan/*"
      }
    }
  }
}