こんにちは！クラウドインフラやセキュリティの世界へようこそ。
初めてサーバーやAWSなどのクラウドサービスに触れるとき、次から次へと出てくる専門用語に「うっ……」と頭を抱えてしまいますよね。
今回は、クラウドセキュリティの現場でエンジニアたちが最も頭を悩ませるポイントの一つ、「クロスアカウントアクセスにおけるIAMロールの連鎖とセキュリティリスク」についてお話しします。
なんだか呪文のような名前ですが、身の回りの「防犯の仕組み」に置き換えてみると、スルスルと理解できるようになりますよ。一歩ずつ、安心して読み進めてくださいね。
—
1. 家の鍵の貸し借りから考える「IAMロール」の基本
まずは、クラウドの世界での「身分証」や「合鍵」にあたるIAM（Identity and Access Management）ロールについておさらいしましょう。
皆さんが自分の家（自分のAWSアカウント）にいるときは、自分の部屋の鍵を当然持っていますよね。でも、お隣の家（別のアカウント）の庭木の手入れを頼まれたとします。
そんなとき、わざわざお隣の家の合鍵をずっと持っているのは、落としたときに危ないですし、管理も面倒です。
そこでクラウドの世界では、「お隣の家に入るときだけ、一時的に使える『特設の合鍵（＝IAMロール）』を発行してもらい、作業が終わったらすぐに返す」という方法をとります。これがクロスアカウントアクセスの基本的な仕組みです。
—
2. 恐怖の「ロールの連鎖」：泥棒が合鍵をコピーする手口
ここで、今回の本題である「ロールの連鎖（Role Chaining）」というセキュリティリスクについて見ていきましょう。
防犯上、すごく気をつけておかなければいけないシーンがあります。それは、「人から借りた合鍵を使って、さらに別の人の家の合鍵を勝手に作ってしまう（借りてしまう）」という状態です。
クラウドの世界で何が起きるか、イラストを思い浮かべるように想像してみてください。
1. あなた（A社のアカウント）が、取引先であるB社のアカウントのロールを使わせてもらう。
2. B社のロールの権限が強すぎたり、設定が甘かったりすると、なんとその権限を使ってさらに機密情報の眠るC社のアカウントのロールまで勝手に使い始めてしまう！
攻撃者は、もしあなたの管理するアプリやサーバーの隙をついて侵入に成功した場合、この「ロールの連鎖」を巧みに利用します。
「A社のサーバーに侵入したぞ $\rightarrow$ つぎにB社への合鍵をゲットしたぞ $\rightarrow$ おっ、このB社の合鍵ならC社の中まで入れるぞ！」というふうに、まるで数珠つなぎのように、次々と関係のないセキュリティエリアの奥深くまで侵入されてしまうのです。
これが、意図しない権限の拡大を引き起こす「ロールの連鎖」の恐ろしいメカニズムです。
—
3. 対策の切り札！「セッションポリシー」で行動範囲に足枷をつける
「じゃあ、他の会社や別のアカウントと連携するなんて怖くてできないよ……」と思いますよね。大丈夫です。ちゃんと強力な対策が用意されています。
それが、今回ご紹介する「セッションポリシー（Session Policies）」を用いた権限の絞り込みです。
これも身近な例に例えてみましょう。
友人に自分の車の運転を貸すとき、「車全体を自由に運転していいよ」と全権を渡すのは怖いですよね。「近所のスーパーまでの運転だけにしてね」「スピードは時速40キロまでね」と一時的な制限（足枷）をかけるはずです。
セッションポリシーとは、まさにこの「一時的に引き渡す鍵の効力を、その場のノリでさらに弱く（限定的に）上書きする仕組み」のことです。
たとえ元々のロールが「何でもできる強力な権限」を持っていたとしても、連鎖して次のロールを呼び出す瞬間にセッションポリシーを適用すれば、「あなたが行けるのは、この特定のフォルダ（S3バケット）の閲覧だけですよ！」とガチガチに行動範囲を制限できるのです。
—
4. 実践！セッションポリシーを設定してみよう
それでは、実際にインフラエンジニアが設定するコード（JSON形式）を見てみましょう。
今回は、「S3というオンラインストレージの、特定のフォルダ（safe-folder）の中身を見る権限だけ」に絞り込むセッションポリシーのサンプルです。
初心者の方でも迷わないように、日本語のコメントを丁寧に書き込んでいます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowReadingSpecificFolderOnly",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::example-company-bucket",
"arn:aws:s3:::example-company-bucket/safe-folder/*"
]
}
]
}この設定のポイント
Action: 許可する操作を「読むこと（GetObject）」と「一覧を見ること（ListBucket）」だけに限定しています。データを勝手に消したり（DeleteObject）、書き換えたりする権限は一切与えていません。Resource: アクセスできる場所をexample-company-bucketという特定の宝箱と、その中のsafe-folderという安全なエリアだけに絞り込んでいます。
このセッションポリシーを、AWSのAPI（AssumeRoleなどのコマンド）を実行する際に渡すことで、万が一ロールが連鎖したとしても、この制限以上の危険な行動ができなくなるというわけです。
—
5. まとめ：安全なクラウドライフのために
今回は、クロスアカウントアクセスにおける「IAMロールの連鎖」と、それを防ぐ「セッションポリシー」について解説しました。
- ロールの連鎖は、合鍵が勝手にコピーされて被害が雪だるま式に広がるリスクがある。
- セッションポリシーを使えば、一時的な合鍵に「ここしか通しちゃダメ！」という強力な足枷（制限）をはめることができる。
セキュリティ対策というと「なんだか難しそう、面倒くさそう」と感じてしまいがちですが、「誰にどこまでの鍵を渡すか」という現実世界の防犯と同じ感覚で考えると、ぐっと本質が見えやすくなります。
一歩ずつ、安全で堅牢なシステム作りを楽しみながら学んでいきましょうね！それではまた次回の記事でお会いしましょう。
コメント