AWS IAM PassRole権限の深淵：攻撃者が潜む「権限の委譲」という名の落とし穴
セキュリティアーキテクト、チーフホワイトハッカー、そして未来を担うテックリード諸氏。日夜、サイバー空間の静寂を破るべく蠢く脅威の最前線に立ち、その深淵を覗き込んでいるあなた方へ。今回は、クラウドネイティブな環境、特にAmazon Web Services (AWS) における、見過ごされがちな、しかし極めて強力な権限昇格ベクトル、すなわち「PassRole」権限の悪用について、その本質をえぐり出し、防御の最前線を論じたい。
CVE番号に踊らされる表面的な脆弱性解析に飽き飽きしているあなたなら、きっとこの話に飢えているはずだ。我々が日々向き合っているのは、単なるコードのバグではない。それは、システム設計思想の隙間、プロトコル仕様の曖昧さ、そして人間心理の盲点を突く、極めて洗練された攻撃である。PassRole権限も、まさにその典型と言えるだろう。
PassRole権限の「魔力」：なぜ攻撃者はこれを狙うのか
まず、PassRole権限がなぜそれほどまでに魅力的で、攻撃者にとって「権限昇格への近道」となるのか、その根本を理解する必要がある。AWS IAM (Identity and Access Management) において、iam:PassRole アクションは、あるエンティティ（ユーザーやロール）が、別のエンティティ（EC2インスタンス、Lambda関数など）に対して、特定のIAMロールを引き受けることを許可する権限だ。
一見すると、これはシステム連携やリソース管理を円滑に行うための、ごく普通の、むしろ必要な権限設定に見える。しかし、ここに落とし穴がある。攻撃者がEC2インスタンス、あるいはコンテナ（ECS, EKS）のような、ある程度自由な操作が可能な環境の認証情報を握った場合を想像してみよう。もし、そのインスタンスやコンテナに紐づいたIAMロールに、さらに他のリソース（例えば、S3バケットへのフルアクセス権を持つロールや、より広範なIAM権限を持つロール）を「PassRole」できる権限が付与されていたらどうなるか？
攻撃者は、自身の制御下にあるインスタンスやコンテナから、本来自分がアタッチされているロールよりもはるかに強力な、別のIAMロールを「奪い取る」ことが可能になるのだ。これは、あたかも「裏口入学」を成功させるようなものであり、本来アクセスできないはずの機密情報へのアクセスや、さらなるシステム破壊行為へと繋がる、極めて深刻な権限昇格シナリオとなる。
実際のアタックチェーンの例
1. 初期侵入: 攻撃者は、脆弱なWebアプリケーションや、設定ミスのある公開されたSSHポートなどを通じて、EC2インスタンスへのアクセス権限を奪取する。
2. 情報収集: インスタンス内で、AWS認証情報（IAMロールのメタデータエンドポイント、あるいはハードコーディングされたクレデンシャル）を探し出す。
3. PassRole権限の発見: 取得した認証情報を用いて、EC2インスタンスにアタッチされているIAMロールが、iam:PassRole アクションを許可しているか、そしてその許可対象に、より高権限なロールが含まれているかを確認する。
4. 権限昇格: 攻撃者は、aws cli などのツールを用いて、本来アタッチされているロールとは異なる、高権限なロールを自身のEC2インスタンスに「PassRole」する。
5. 後続アクション: 新たに取得した高権限ロールを利用して、S3バケットからの機密情報漏洩、他のAWSリソースの停止・削除、さらには他のアカウントへの横展開などを試みる。
低レイヤの視点：なぜIAMは「信頼」を委譲するのか
このPassRole権限の悪用を理解するために、AWSの認証・認可メカニズム、特にIAMロールの挙動を低レイヤで捉え直してみよう。AWSのIAMロールは、一時的なセキュリティ認証情報（Access Key ID, Secret Access Key, Session Token）を発行する。EC2インスタンスにIAMロールをアタッチすると、インスタンスメタデータサービス（IMDS）経由で、これらの認証情報にアクセスできるようになる。
iam:PassRole アクションは、この「一時的な認証情報」を生成するプロセス、あるいはそれを利用するAPI呼び出し (iam:CreateRole, iam:UpdateAssumeRolePolicy などを直接叩くわけではないが、APIの挙動としては、あるロールを別のサービス（EC2, Lambdaなど）に紐づける際の前提条件として機能する）に、制限をかけるものである。
問題は、IAMポリシーで iam:PassRole を明示的に許可してしまうと、そのポリシーがアタッチされているエンティティは、「自身が引き受けたロールの権限」 に加えて、「PassRole権限で指定されたロールを引き受ける権限」 を持つことになる点だ。ここで重要なのは、iam:PassRole の条件指定において、「どのロールを、どのサービスにPassできるか」 を厳密に制限する必要があるという点だ。
例えば、以下のようなIAMポリシーは、非常に危険な設定例だ。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*", // !!! 危険: 全てのロールを許可 !!!
"Condition": {
"StringEquals": {
"iam:PassedToService": "ec2.amazonaws.com" // !!! 危険: 全てのEC2サービスに許可 !!!
}
}
}
]
}このポリシーがEC2インスタンスのIAMロールに付与されている場合、そのインスタンスは、任意のIAMロールを、任意のEC2インスタンスにPassできるという、まさに悪夢のような状況を生み出す。攻撃者がそのインスタンスを乗っ取った瞬間、彼は「IAMの管理者」とほぼ同等の権限を得たも同然だ。
防御の最前線：IAMポリシーによる「ガードレイル」の設計
このPassRole権限の悪用を防ぐための、最も効果的な防御策は、IAMポリシーによる厳格な「ガードレイル」の設計だ。これは、単に「許可しない」という消極的な姿勢では不十分であり、「必要最小限の権限のみを、必要最小限の対象に、必要最小限の期間だけ」 付与するという、ゼロトラストの原則に基づいた、積極的かつ詳細なポリシー設計が求められる。
1. iam:PassRole アクションの原則的な不許可
まず、原則として、iam:PassRole アクションは、極力許可しないことが推奨される。もし、どうしても特定のサービス連携などで必要になる場合でも、その許可範囲は極めて限定的であるべきだ。
2. Resource と Condition による厳密なスコープ指定
iam:PassRole を許可せざるを得ない場合、以下の点を厳守する必要がある。
Resource: 許可するロールを、特定のARN（Amazon Resource Name）で正確に指定する。"*"やワイルドカードの使用は避ける。Condition:iam:PassedToService: ロールが引き渡される対象サービスを、具体的なサービスエンドポイント（例:ec2.amazonaws.com,lambda.amazonaws.com）で指定する。iam:ResourceTagやaws:RequestTag: 渡されるロールに付与されたタグに基づいて制限をかける。これは、ロールのライフサイクル管理や、意図しないロールの引き渡しを防ぐのに役立つ。aws:PrincipalArn: 誰が（どのプリンシパルが）そのロールをPassできるかを制限する。
実践的なIAMポリシー例
以下に、EC2インスタンスが、特定のタグ（Environment: Production）が付与された、AmazonS3ReadOnlyAccess 管理ポリシーがアタッチされたカスタムロール（例: arn:aws:iam::123456789012:role/MySpecificS3ReaderRole）のみを、EC2サービスにPassすることを許可するポリシー例を示す。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowPassSpecificS3ReaderRoleToEC2",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::123456789012:role/MySpecificS3ReaderRole", // 許可するロールのARNを正確に指定
"Condition": {
"StringEquals": {
"iam:PassedToService": "ec2.amazonaws.com" // 許可する対象サービス
},
"ForAllValues:StringEquals": { // ロールに付与されたタグの確認
"iam:ResourceTag/Environment": "Production"
}
}
}
]
}このポリシーは、EC2インスタンスにアタッチされたIAMロールに付与されるべきだ。これにより、仮にそのEC2インスタンスの認証情報が漏洩しても、攻撃者は MySpecificS3ReaderRole 以外のロールを奪取することはできず、かつそのロールも Production 環境のEC2にしかPassできない、という強力な制約が課される。
監査と監視の重要性
さらに、これらのIAMポリシーの変更履歴や、iam:PassRole アクションの実行ログを、AWS CloudTrailなどを通じて継続的に監査・監視することが不可欠だ。予期せぬロールのPass試行や、ポリシーの変更は、即座に検知・アラートされるべきだ。
まとめ：設計思想に潜む脆弱性を排除する
PassRole権限の悪用は、単なる設定ミスではなく、AWS IAMの「信頼の委譲」という設計思想の深淵に潜む落とし穴だ。攻撃者は、この「信頼」を逆手に取り、システム全体のセキュリティ境界を突破しようと試みる。
我々セキュリティエンジニアは、単に最新の攻撃手法を追うだけでなく、システムがなぜ、どのように機能するのか、その根本原理、低レイヤの挙動、そして設計思想の背景まで理解する必要がある。PassRole権限の悪用を防ぐためには、AWS IAMのポリシーを、表面的な「許可/不許可」ではなく、「条件付きで、範囲を限定した、最小限の信頼の委譲」 という観点から、極めて慎重に設計・監査していかなければならない。
これは、単なる技術的な対策に留まらない。それは、システムを構築する我々自身の、セキュリティに対する「設計思想」そのものを問う行為なのだ。常に疑い、常に検証し、常に最悪のシナリオを想定する。それが、この流動的で危険なサイバー空間を生き抜くための、我々ホワイトハッカーの責務である。
コメント