外部IDと混乱した代理人問題

自分のアカウント内のロールを第三者が引き受けられるようにすると、混乱した代理人の問題と呼ばれるセキュリティリスクが発生する可能性があります。外部IDは、これを防ぐためのシンプルですが重要な制御策です。このパターンは、SaaSベンダーがユーザーのAWSアカウントにアクセスする必要がある場合に、試験でよく登場します。

混乱した代理人とは、信頼されたエンティティ（代理人）がだまされ、攻撃者のために自身の権限を使ってしまうことです。AWSでは、第三者サービスが多数の顧客アカウントでロールを引き受ける権限を持つ場合があります。正規の顧客との関係にリクエストを結び付ける仕組みがなければ、攻撃者はそのサービスをだましてあなたのロールを引き受けさせる可能性があります。

各顧客アカウントでロールを引き受ける監視SaaSを想像してください。そのSaaSは全顧客に対して1つのAWSアイデンティティを使用します。攻撃者が同じSaaSの顧客でもあり、あなたのロールARNを推測できた場合、SaaSが信頼されたプリンシパルであるため、SaaSを説得してあなたのロールを引き受けさせる可能性があります。アカウントIDだけでは、これを防ぐには不十分です。

外部IDは、ベンダーが顧客との関係ごとに割り当てる一意の値です。この値をロールの信頼ポリシーに条件として設定し、ベンダーはAssumeRoleの呼び出し時にまったく同じ値を指定する必要があります。攻撃者はあなたの外部IDを知らないため、ベンダーをだましてあなたのロールを引き受けさせることができません。

この信頼ポリシーでは、一致する外部IDが必須です。ベンダーが同一の値を渡した場合にのみAssumeRoleが成功し、混乱した代理人による攻撃を防ぎます。

重要なのは、ベンダーが外部IDを生成して管理し、顧客が設定するのではないという点です。これにより、顧客同士が同じ値を使い回すことを防げます。AWSのガイダンスは明確です。第三者であるベンダーは、顧客ごとに一意の外部IDを割り当て、AssumeRoleのたびにその値を必須にする必要があります。

外部IDは、パスワードのような秘密として扱うものではなく、設定手順に記載されることもあります。外部IDのセキュリティ上の価値は、顧客ごとに一意であり、ベンダーが管理することにあります。そのため、攻撃者は代理人に別の顧客の値を使わせることができません。これは認証情報ではなく、なりすましを防ぐトークンとして扱ってください。

外部IDは誰が引き受けられるかを制御しますが、ロールで何ができるかは厳格な権限ポリシーで制限する必要があります。正しく認証されたベンダーであっても、必要最小限の権限だけを付与してください。安全な第三者アクセスのために、外部ID、特定のプリンシパル、最小権限の権限設定を組み合わせます。

混乱した代理人のパターンは、AWSサービスがユーザーに代わって動作する場合にも当てはまります。サービス間の信頼では、リソースポリシーにaws:SourceArnやaws:SourceAccountなどの条件キーを使用し、呼び出し元のサービスが自分のリソースのために動作していることを確認します。これは、形は異なっても同じ防御の考え方です。

問題文に、アカウント間で第三者またはSaaSがロールを引き受ける状況が出てきたら、安全な答えにはほぼ必ず、信頼ポリシー内の外部IDが含まれます。サービス間のシナリオであれば、代わりにaws:SourceArn／aws:SourceAccount条件を探してください。この手がかりを認識すれば、適切な制御策にすぐたどり着けます。

混乱した代理人の問題では、攻撃者が信頼された第三者をだまして、そのアクセスを悪用させる可能性があります。顧客ごとに一意でベンダーが管理する外部IDを使用し、AssumeRoleで一致する値を必須にすることで、この問題を防げます。AWSサービスではaws:SourceArnとaws:SourceAccountを使用してください。これらは必ず最小権限の権限設定と組み合わせます。

混乱した代理人の概念を確認しましょう。

混乱した代理人の問題は、信頼された第三者がだまされ、アカウント間アクセスを悪用すると発生します。顧客ごとに一意でベンダーが管理する外部IDを、sts:ExternalIdに対する信頼ポリシーの条件として指定することで防止できます。AWSサービス間の信頼では、常に最小権限とともにaws:SourceArnとaws:SourceAccountを使用してください。