こんにちは！クラウドでのシステム開発、毎日お疲れ様です。「AWSなどのクラウドサービスを使い始めたけれど、セキュリティの設定がなんだか難しそう……」そんな風に感じていませんか？
今回は、クラウドのセキュリティにおいて、新人のエンジニアさんや開発者さんが最初につまずきやすい「IAM（アイアム）ロールの過剰な権限付与」と、そこから起こる「権限昇格のメカニズム」について、身近な防犯の例えを交えながら、一歩ずつ優しく紐解いていきたいと思います。
難しい言葉が出てきても大丈夫です。一緒に仕組みを理解して、安全なシステムを作れるようになりましょう！
—
1. 家の鍵で例える「IAMロール」と「権限」の基本
まず、クラウドにおける「IAM（Identity and Access Management）」がどんなものか、私たちが暮らす「お家」に例えて考えてみましょう。
皆さんがお家に住むとき、玄関の鍵を持っていますよね。この「鍵」が、クラウドの世界では「IAMユーザーやIAMロール」にあたります。そして、「その鍵でどの部屋に入れるか」を決めるルールブックが「IAMポリシー（権限）」です。
- リビングだけに入れる鍵
- すべての部屋（寝室、金庫室、屋根裏まで）に入れるマスターキー
もし、家族の一員（あるいは遊びに来たお友達）に「ちょっと郵便受けを見てきてほしいだけ」なのに、家のすべての部屋が開くマスターキーを渡してしまったらどうなるでしょうか？ もしその人が悪い人に騙されたり、鍵を落としたりしたら、金庫の中身まで全部盗まれてしまいますよね。
クラウドの世界でもこれと全く同じことが起こります。これが、今回テーマにする「過剰な権限付与」の正体です。
—
2. 攻撃者はどう狙う？「ワイルドカード」の罠
クラウドの初期設定や、早く開発を終わらせたいがために、ついついやってしまいがちなのが「ワイルドカード（*）」の乱用です。
ワイルドカードとは、パソコンの検索などでよく使う「すべて」を意味する記号のことです。IAMポリシーを書くときに、以下のような設定を見かけたことはありませんか？
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
]
}この設定、何が問題だかわかりますか？
Action の部分にある s3:* は、「Amazon S3（ファイルの保存場所）に関するすべての操作を許可する」という意味です。さらに Resource の * は、「すべてのファイルやバケットに対して」という意味になります。
つまりこれは、「会社のすべてのファイル庫に対して、何でも好き勝手に読み書き・削除していいですよ」という、文字通りのマスターキーを渡している状態なのです。
攻撃者の視点：どうやって入り込むの？
私たちレッドチーム（攻撃側）がペネトレーションテスト（模擬サイバー攻撃）を行う際、一番最初にチェックするのが、このワイルドカードが設定された緩い権限です。
もし、開発者がテスト用に作ったWebアプリに小さな脆弱性（セキュリティの穴）が見つかり、そこに侵入されてしまったとします。もしそのアプリに紐づいているIAMロールが「何でもできるマスターキー」を持っていたらどうなるでしょうか？
攻撃者はそのキーを奪い、データベースをすべて人質に取ったり、こっそりバックアップをすべて削除してしまったりすることが簡単にできてしまいます。これが、過剰な権限がもたらす恐ろしいリスクです。
—
3. 「iam:PassRole」を使った権限昇格のメカニズム
さて、ここから少しだけステップアップして、攻撃者がよく使うテクニックである「権限昇格（権限を自分でランクアップさせる技）」について見ていきましょう。
ここで登場するのが、少し特殊な権限である iam:PassRole です。
またまた「鍵」に例えてみましょう
想像してください。あなたは会社の一般社員で、普段は自分のデスクの引き出ししか開けられません。しかし、なぜか「総務の人に新しい合い鍵を渡す（パスする）権限」だけを持っていたとします。
ここで、あなたは「自分よりも強い権限を持つ、社長専用の強力なロール（身分証）」を作る権利も持っていたとしたら……？
1. まず、こっそり「何でもできるスーパー権限」を持った新しいロールを作る。
2. 次に、自分が持っている iam:PassRole 権限を使って、新しく作ったスーパーロールを、自分が動かせるサーバー（EC2など）にこっそり装着させる。
3. そのサーバーを踏み台にして、自分自身が「社長の権限」を手に入れてしまう！
これが、iam:PassRole を悪用した権限昇格のメカニズムです。一見すると「ただ鍵を渡すだけ」に見える権限も、他の権限と組み合わさることで、攻撃者にとっての「最強の踏み台」に変貌してしまうのです。
—
4. 安全な設計への第一歩：IAM Access Analyzerで権限を最適化しよう
「じゃあ、いったいどうやって自分のクラウド環境を守ればいいの？」
安心してください。AWSには、私たちのセキュリティを守るための強力で便利なツールが用意されています。それが「IAM Access Analyzer」です。
IAM Access Analyzerってなに？
イメージとしては、「お家の鍵の点検おじさん」です。
この機能を目を覚まさせておくと、クラウド環境の中をこっそり見回してくれて、
- 「あれ？ このファイル置き場の鍵、外部の知らない人にも開けられる設定になっていませんか？」
- 「このロール、ちょっと強すぎませんか？」
と、危ない設定を見つけて優しく教えてくれます。
権限最適化（最小権限の原則）の進め方
セキュリティの基本は「最小権限の原則（Least Privilege）」です。「お仕事をするのに最低限必要な鍵だけを渡し、不要になったらすぐ回収する」というルールを徹底することです。
例えば、先ほどの何でもできてしまう危ないポリシーは、以下のように書き換えるべきです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject", -- ファイルの「読み込み」だけ許可
"s3:PutObject" -- ファイルの「書き込み」だけ許可
],
"Resource": "arn:aws:s3:::my-company-specific-bucket/*" -- 特定のフォルダの中だけ！
}
]
}このように、「どの操作（Action）を、どの範囲（Resource）で許可するか」をしっかりと絞り込むことで、万が一アプリが攻撃されても、被害を最小限に食い止めることができます。
—
まとめ：一歩ずつ、安全なクラウド環境を作っていこう
今回は、IAMロールの過剰な権限付与と、そこから起こる権限昇格の仕組みについてお話ししました。
- ワイルドカード（
*）の乱用は「すべての部屋が開くマスターキー」を渡すようなもの。 iam:PassRoleなどの特殊な権限は、組み合わせ次第で攻撃者に悪用されるリスクがある。- IAM Access Analyzerを活用し、「最小権限の原則」を意識して権限を絞り込もう。
セキュリティの対策は、一度にすべて完璧にやろうとすると大変です。「まずは自分の担当するシステムのポリシーから、ワイルドカードが使われていないか確認してみようかな」そんな小さな一歩からで大丈夫です。
一緒に、安全で安心なクラウドライフを作っていきましょう！それでは、次の記事でお会いしましょう。
コメント