[AWS] 混乱する代理問題の話
業務柄DevOpsに関わることがありその一環としてAWSについて学んでいたところ、気になる題材があったためメモ代わりに少しまとめる。
公式リンク
IAMとは
大前提としてAWSのIAMというサービスについて。
AWS上のリソースの権限を管理集約するAWSの1サービス。
大きく4種類ある
- IAM ユーザー…AWSを利用する際に普段使うアカウント、リソース権限付与の対象(請求などを管理するルートユーザーとは異なる)
- IAM グループ…IAM ユーザーをまとめたもの、会社で利用する際に部署単位などひとまとめにして権限管理できたりする
- IAM ポリシー…AWSリソースの権限情報を定義したもの(複数可)、IAM ユーザーとIAM ロールに付与(アタッチ)できる
- IAM ロール…IAMユーザーだけでなくAWSリソースにも権限を付与できる。(例：EC2インスタンスからS3バケットへのアクセス権限など)また別AWSアカウントのIAMユーザーに権限を一時的に付与したり安全に権限を委任できたりする。
- IAMポリシー…このロールが持っているアクセス権限を定義する
- 信頼ポリシー…このロールを使える(厳密にはassumeRoleなので引き受ける)ユーザーまたはリソースを定義する
今回は4番目のIAMロールに関わる内容。
混乱する代理問題とは
正常な仕組み
分かりやすい例で示すとまずシチュエーションとしては
まず、あるAWSリソースを使って他のAWSリソースに対するアクセスをしたいというタスクがある。
このタスクは言い換えると「AWS serviceがAWS resourceにアクセスする」となる。
次に、自分も含めて他のAWSアカウントでもこのタスクが実行できるようにしたいというニーズがあったとする。
この際、このタスクは前述のIAMロールの要件に当てはまるので管理者である自分がAWS resourceにアクセスできる権限を定義したIAMロールを作成。以下二つの設定をする。
- AWS serviceに対してIAMロールを登録…IAMロールのアクセス権限をAWS serviceが行使できるようにする→IAMポリシー
- IAMロールに対してAWS serviceとの信頼関係を構築…AWS serviceがこのIAMロールを使用できる(引き受ける)ことを定義する→信頼ポリシー
そして自分を含め信頼する第三者に作成したロールの情報を渡し、ロールを持っている(知っている)ユーザーがAWS serviceを介してAWS resourceにアクセスするというタスクを実行できることができるようになる。
問題の仕組み
この仕組みに対して問題を引き起こす攻撃者の定義は、基本的には管理者から信頼を受けているユーザーであり、前述したタスクを実行する権限は持っていないという立ち位置になる。
ARNについて
問題の仕組みを説明する前にARNについて、ARNは全てのAWSリソースに付与されている識別子。
もちろんIAMロールも持っており、AWSのアカウント番号とロール名で構成されている。
ARNは秘匿されている情報ではなく公開されている情報(AWSのアカウント番号など)などが分かれば推測することができる情報。
以上を踏まえて攻撃者が実行する攻撃は以下のようになる。
- 管理者から信頼されている正規ユーザーのIAMロールARNを推測する
- 推測したARNの情報を元にAWS serviceに対してアクセス
- 本来許可していない攻撃者がAWS serviceを介することでAWS resourceにアクセスできてしまう
この問題の本質はこれであり、AWS resourceから見ると代理者であるAWS serviceの背後にいるユーザーが正規ユーザー以外の攻撃者である可能性があり、誰がアクセスしたか混乱する中結果的にアクセスできてしまうことから。
解決策
解決策としてAWSのベストプラクティスより 「外部ID(External ID)」 という設定値が提供されている。これはアクセスしてくるユーザーごとに一意となるIDのこと。
AWS serviceからこの外部IDを発行してもらうことでAWS serviceを使用するユーザーはそれぞれ異なる外部IDが割り当てられることになる。IAMロールにこの外部IDのうち正規ユーザーのみの外部IDを許可するという条件を追加すれば、攻撃者は他の外部IDを持っているためアクセスができなくなるという仕組み。
AWS service側で外部IDがユーザーごとに関連付けられる = AWS service内で外部IDの発行と認証が完結するため、攻撃者が外部IDを操作するといったことも不可能となる。
Discussion