こんにちは！クラウドの世界へようこそ。アプリケーションをサクッと動かすのにとても便利な「AWS Lambda（ラムダ）」、皆さんもよく使っていますよね。
サーバーの管理を気にせず、コードを書くだけで動いてくれるので本当に最高ですが、「便利さの裏にはリスクが潜んでいる」のがセキュリティの常です。今回は、初めてセキュリティに触れる方にもわかりやすいように、「AWS Lambdaの実行環境におけるIAM（アイアム）ロールの分離」について、身近な例えを交えながら一歩ずつ紐解いていきましょう！
—
1. 家の鍵に例える「IAMロール」の考え方
いきなりですが、ちょっと想像してみてください。
あなたは大きなおウチに住んでいます。その家には、リビング、寝室、そして大切なへそくりが入っている「金庫室」がありますよね。
もし、家族全員や遊びに来た友人に「家中のすべての部屋が開くマスターキー」を配ってしまったらどうでしょう？ 誰か一人がうっかり悪い人に騙されたり、カバンを盗まれたりしたら、リビングだけでなく、一番守りたい金庫室まであっさり開けられてしまいますよね。これってすごく怖くないですか？
クラウドの世界もこれとまったく同じです。
AWS Lambdaで作るプログラム（関数）一つひとつは、いわば「家の中でお手伝いをするロボット」のようなものです。
このロボットに「AWSの中にあるすべてのリソース（データベースやファイル置き場など）にアクセスしていいよ！」という強力なマスターキーを持たせてしまうのは、セキュリティの観点から見ると最悪の悪手なんです。
ここで登場するのが、今回の主役である「IAMロール」です。
IAMロールとは、AWSの世界で「このロボットには、この部屋（リソース）のドアノブだけ回していいよ」という制限付きの専用キーを渡す仕組みのこと。関数ごとに「最小限の権限」だけをあたえる（これを最小権限の原則と言います）ことで、万が一ひとつのプログラムが乗っ取られても、被害を最小限に食い止められるようにするんです。
—
2. 攻撃者はどうやってLambdaを狙うのか？
「でも、コードがちゃんと書いてあればLambdaが乗っ取られることなんてあるの？」と思われるかもしれません。
実は、攻撃者は私たちが書いたプログラムの「ちょっとした隙」を狙ってきます。
例えば、外部からの入力をそのままデータベースに投げちゃうような脆弱性（インジェクションなど）があったり、使っている外部ライブラリ（オープンソースの部品など）に後から見つかった危険なバグ（脆弱性）があったりすると、攻撃者はLambdaの実行環境の中にこっそり侵入してきます。
もし、そのLambdaに関係ないデータベース（例えば、顧客情報の入ったデータベース）へのアクセス権限が与えられていたらどうなるでしょうか？
攻撃者は、その乗っ取ったLambdaを踏み台にして、いとも簡単に顧客情報を根こそぎ盗み出してしまうのです。これが、セキュリティ事故の現場でよくある「権限の波及（ラテラル・ムーブメント）」と呼ばれる恐ろしいシナリオです。
だからこそ、「ひとつのLambdaには、その仕事に必要な最低限の鍵だけを持たせる」という分離設計が絶対に必要になります。
—
3. 実践！安全なIAMロールの設計と設定パターン
それでは、実際にAWSでどうやって権限を分ければいいのか、具体的な設定を見ていきましょう！
今回は、よくある「画像をS3（ストレージ）から読み込んで、DynamoDB（データベース）にログを記録する」というLambdaを例にします。
悪い例：全部の権限をまとめた「おまかせ強力ロール」
よくある初心者の失敗として、どのLambdaにもとりあえず AdministratorAccess や、何でもできてしまう広範なポリシーをアタッチしてしまうケースがあります。これは絶対にやめましょう。
良い例：関数ごとに専用のIAMポリシーを作る
画像処理を行うLambdaであれば、「特定のS3バケットを読む権限」と「特定のDynamoDBテーブルに書き込む権限」だけを組み合わせた、その関数専用のIAMロールを作ります。
実際のAWS CloudFormationやServerless Framework、あるいはTerraformなどの設定ファイル（インフラをコードで管理する仕組み）では、以下のように記述して権限を絞り込みます。
# 例：Serverless Frameworkを使った安全なIAMロールの定義
functions:
imageProcessor:
handler: handler.main
# このLambda専用の極小の権限を定義する
iamRoleStatements:
- Effect: "Allow"
Action:
- "s3:GetObject" # 画像を「読む」ことだけ許可
Resource: "arn:aws:s3:::my-secure-image-bucket/*"
- Effect: "Allow"
Action:
- "dynamodb:PutItem" # ログを「書き込む」ことだけ許可
Resource: "arn:aws:dynamodb:us-east-1:123456789012:table/ImageLogs"この設定のポイントを解説しますね。
s3:GetObject: バケットからファイルを「読む」ことだけを許可し、ファイルを削除するDeleteObjectなどの権限は一切与えていません。Resource: AWS全体ではなく、my-secure-image-bucketという特定のバケットの配下にだけアクセスを限定しています。
万が一、この imageProcessor のコードに脆弱性があり、攻撃者に乗っ取られたとしても、攻撃者が触れるのは「指定されたバケットの画像読み込み」と「ログテーブルへの書き込み」だけです。他の重要なシステムやユーザーデータ（例えばユーザーのパスワード管理テーブルなど）には一歩も近づくことができません。これが「被害の波及を防ぐ」ということなんです。
—
4. まとめ：一歩ずつ安全なクラウドインフラを作ろうい
今回は、AWS LambdaにおけるIAMロールの分離について、お家の鍵の例えを交えながら解説しました。
セキュリティ対策と聞くと、「なんだか難しそう…」「面倒くさそう…」と感じてしまうかもしれませんが、基本の考え方はとてもシンプルです。
1. 「このプログラムには、何の仕事が必要だっけ？」と立ち止まる
2. 「そのためだけに必要な最小限の鍵（権限）を渡す」
3. 「他の部屋の鍵は絶対に持たせない」
この3つを意識するだけで、あなたの作るシステムは劇的に安全になります。
最初は難しく感じるかもしれませんが、実務の現場でもこの「最小権限の原則」をコツコツ守ることが、プロとしての第一歩であり、最大の防御になります。
焦らず、一歩ずつ安全なクラウドライフを作っていきましょうね！それではまた次回の記事でお会いしましょう。
コメント