混淆代理人問題 - AWS Identity and Access Management
預防跨帳戶混淆代理人預防跨服務混淆代理人

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

混淆代理人問題

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

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

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

預防跨帳戶混淆代理人

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

混淆代理人問題描述。

此案例假設如下：

  • AWS1 是你的 AWS 帳戶.

  • AWS1：ExampleRole是您帳戶中的角色。此角色的信任政策透過將 Example Corp 的 AWS 帳戶指定為可擔任該角色的帳戶來信任 Example Corp。

將發生以下情況：

  1. 當您開始使用實施例公司的服務時，您將 AWS1: 的 ARN 提供ExampleRole給示例公司

  2. 範例公司使用該角色 ARN 取得臨時安全登入資料，以存取. AWS 帳戶這樣一來，您將信任 Example Corp 做為可代表您執行操作的「代理人」。

  3. 另一位 AWS 客戶也開始使用實施例公司的服務，並且該客戶還提供了 AWS1 的 ARN：ExampleRole例如公司使用。據推測，其他客戶學習或猜測了 AWS1: ExampleRole，這不是一個秘密。

  4. 當其他客戶要求 Example Corp 存取其帳戶中的 AWS 資源時，Example Corp 會使用 AWS1: 存ExampleRole取您帳戶中的資源。

這就是其他客戶可對您的資源進行未授權存取的方式。由於此客戶能夠誘使 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。這些識別碼已針對此方案進行簡化。通常，這些識別碼為 GUID。假定這些識別碼在 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"
      }
    }
  }
}

此原則中的「條件」元素允許範例公司只有在 AssumeRole API 呼叫包含 12345 的外部識別碼值時才會擔任角色。示例公司確保每當它擔任代表客戶的角色時，它始終包含該客戶的外部 ID 值在 AssumeRole 呼叫中。即使其他客戶提供了示例公司與您的 ARN，它也無法控制示例公司在其請求中包含的外部 ID。 AWS這有助於防止未經授權的客戶取得對您的資源的存取權限。

下圖說明此程序。

如何消除混淆代理人問題。

  1. 和以前一樣，當您開始使用實施例公司的服務時，您將 AWS1: 的 ARN 提供ExampleRole給示例公司

  2. 當範例公司使用該角色 ARN 承擔角色 AWS1: 時ExampleRole，範例公司會在 AssumeRole API 呼叫中包含您的外部識別碼 (12345)。外部 ID 符合角色的信任原則，因此 AssumeRole API 呼叫成功，Example Corp 會取得臨時安全登入資料，以存取. AWS 帳戶

  3. 另一位 AWS 客戶也開始使用 Example Corp 的服務，和以前一樣，該客戶還提供了 AWS1 的 ARN：ExampleRole例如公司使用。

  4. 但是這一次，當實施例公司試圖承擔角色 AWS1: 時ExampleRole，它提供了與其他客戶（67890）關聯的外部 ID。其他客戶無法更改此外部 ID。Example Corp 這樣做是因為另一個客戶請求使用該角色，因此 67890 表示 Example Corp 正在其中操作的環境。因為您將具有自己外部識別碼 (12345) 的條件新增至信任原則 AWS1: ExampleRole，因此 AssumeRole API 呼叫會失敗。該其他客戶不能對您帳戶中的資源進行未經授權的存取 (由圖表中的紅色 "X" 表示)。

該外部 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:SourceArn的使 AWS 服務 用aws:SourceAccount和信任原則，但帳戶中的現有角色並不需要使用金鑰。

注意

AWS 服務 與 AWS Key Management Service 使用 KMS 金鑰授權整合的不支援aws:SourceArn、aws:SourceAccountaws:SourceOrgID、或aws:SourceOrgPaths條件金鑰。如果 AWS 服務 透過 KMS 金鑰授權也使用金鑰，則在 KMS 金鑰原則中使用這些條件金鑰會導致非預期的行為。

跨服務混淆副預防 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，您必須選擇允許事件管理員代表您執行 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/*"
      }
    }
  }
}
注意

並非所有服務都與 AWS STS 支援aws:SourceArnaws:SourceAccountaws:SourceOrgID、或aws:SourceOrgPaths條件金鑰整合。在具有不支援整合的 IAM 信任政策中，使用這些鍵可能會導致非預期行為。