こんにちは！クラウドのインフラ構築やアプリ開発の現場に飛び込んだばかりの皆さん、日々の業務本当にお疲れ様です。
AWSをはじめとするクラウド環境、とっても便利ですよね。サーバーを何台も買わなくても、ボタン一つ（あるいはコードを書くだけで）でシステムが動き出す魔法のような世界です。でも、その便利さの裏で、「セキュリティの管理って、難しそう…」と不安になっていませんか？
今回は、クラウドセキュリティの要である「IAMロールの過剰権限利用」について、身近な「家の鍵」の例えを交えながら、一緒に優しく紐解いていきたいと思います。難しい専門用語が出てきても置いてけぼりにしませんので、一歩ずつリラックスして学んでいきましょう！
—
1. 身近な例えで理解する：クラウドの「合鍵」と泥棒の心理
皆さんが住んでいる「お家」を想像してみてください。
玄関の鍵には、普段自分たちが使う「通常の鍵」がありますよね。では、もし家の中に「家中のすべての部屋、金庫、さらには隣の家のドアまで開けられてしまう『マスターキー』」があったとしたらどうでしょう？ しかも、その鍵が、玄関のポストにぽんと置きっぱなしになっていたら……想像するだけでゾッとしますよね。
クラウドの世界における「IAMロール」は、まさにこの「鍵」のようなものです。
AWSなどのクラウドでは、人間だけでなく、システムやプログラム（動いているアプリなど）がAWSの機能を使うために「IAMロール」という専用の身分証（＝鍵）を持ちます。
そして、このIAMロールに「過剰な権限（何でもできてしまう強力なマスターキー）」を与えてしまうことが、セキュリティ事故の最大の盲点になります。
もし攻撃者が、セキュリティの甘いアプリの隙をついて、この「強力なマスターキー（過剰な権限を持ったIAMロール）」をこっそり手に入れてしまったらどうなるでしょうか？ 彼らは家の中を荒らすだけでなく、クラウド上の全データを盗み出したり、勝手に有料のサーバーを大量起動して高額な請求を発生させたりできてしまいます。
怖いですよね。だからこそ、「誰が、どの鍵を、どんな場所から使っているか」を監視する必要があるのです。
—
2. 攻撃者はどうやって「過剰な権限」を悪用するのか？
実務の現場でよくあるシナリオを少しだけ覗いてみましょう。
例えば、社内の開発メンバーが「すぐにテスト環境を作りたいから、とりあえず何でもできる強い権限（AdministratorAccessなど）をこのアプリ用のIAMロールに持たせておこう」と設定したとします。一時的なつもりが、そのまま本番環境に残りっぱなしになってしまうことは、残念ながら珍しくありません。
ここに攻撃者がやってきます。
攻撃者はアプリの脆弱性を突いてサーバーに侵入し、そのIAMロールが持っている「強力なマスターキー」の権限を奪い取ります。そして、普段は絶対に実行されないような不審なAPI（例えば、暗号化キーを勝手に変更したり、別の国から大量のユーザーデータをごっそりダウンロードしたりする操作）をこっそり呼び出すのです。
ここで私たちSOC（セキュリティオペレーションセンター）アナリストやインシデントレスポンスの担当者が頼るのが、「CloudTrail（クラウドトレイル）」という、いわば「クラウド上の防犯カメラ映像と出入り口の記録ノート」です。
—
3. 「普段と違う動き」を検知するベースライン作成の考え方
「誰がどんな操作をしたか」をすべて人間の目でチェックするのは不可能です。そこで活躍するのが、「ベースライン（普段の正しい状態）」の定義と異常検知です。
防犯カメラに例えるなら、「うちの家族は、平日の昼間はリビングにいないし、夜中に勝手口の鍵を開けて出歩くこともない」という「普段のルーティン」をあらかじめ決めておくイメージです。このルーティンから外れた動き（夜中に勝手口がガチャリと開いたなど）があれば、アラートを鳴らして警備員を走らせます。
これをクラウドのログ（CloudTrail）で実現するために、AthenaやPythonなどのスクリプトを使って分析基盤を作ります。次の章で、実際にどのようにログを解析して異常を見つけるのか、コードを見ていきましょう！
—
4. 実践！CloudTrailログから不審なIAM利用を見つけるクエリ例
AWSのログ分析でよく使われるAmazon Athena（SQLを使ってS3上のログを検索できるサービス）を例に、普段利用されないAPIコールや、異常なIPアドレスからのアクセスを炙り出すクエリを見てみましょう。
実務でそのままコピー＆ペーストして調整できるように、日本語の解説コメントをたっぷり入れています。
-- 過去7日間に発生した特定のIAMロールによるAPI利用状況を集計し、
-- 「普段使っていないAPI」や「見慣れないIPアドレス」をあぶり出すためのSQLクエリです。
SELECT
-- 操作を行ったユーザーやIAMロールの名前
useridentity.arn AS iam_role_arn,
-- 呼び出されたAPIの名前（例: ListUsers, GetSecretValue など）
eventname,
-- アクセス元のIPアドレス
sourceipaddress,
-- 何回その操作が行われたか
COUNT(*) AS call_count,
-- 最初にその操作が観測された日時
MIN(eventtime) AS first_seen,
-- 最後にその操作が観測された日時
MAX(eventtime) AS last_seen
FROM
-- あなたの環境のCloudTrailログが保存されているテーブル名を指定してください
aws_cloudtrail_logs_123456789012_us_east_1
WHERE
-- 調査対象の期間（直近7日間など）
eventtime >= '2023-10-01T00:00:00Z'
-- システムが自動で行う内部的な共通処理などはノイズになるため除外します
AND eventname NOT IN ('ListBuckets', 'DescribeRegions')
-- 特定の怪しいIAMロールに絞り込んで調査する場合に指定します
AND useridentity.arn LIKE '%app-production-role%'
GROUP BY
useridentity.arn,
eventname,
sourceipaddress
-- 呼び出し回数が少ないものや、特定のパターンをあぶり出します
ORDER BY
call_count ASC;このクエリが教えてくれること
このクエリを実行すると、「この本番用アプリのIAMロールは、普段はデータベースを読むAPIしか使わないはずなのに、なぜか見慣れない海外のIPアドレスから、ユーザー情報を一括削除するような危険なAPIが1回だけ呼び出されているぞ！」といった違和感（異常値）をスピーディーに発見することができます。
—
5. 明日からできる！過剰権限を防ぐためのファーストステップ
インシデントの現場にいる私たちから、これからクラウドを触る皆さんに心からお伝えしたいことがあります。それは、「最初から完璧なセキュリティを目指さなくていいけれど、基本の『三種の神器』だけは守ってほしい」ということです。
1. 最小権限の原則（PoLP: Principle of Least Privilege）を守る
- 「とりあえず動かすために、強い権限を渡す」のは、玄関の鍵を開けっぱなしにするのと同じです。「このアプリには、このフォルダを開く鍵だけ渡す」という細かい設定を心がけましょう。
2. 定期的に「使われていない鍵」を棚卸しする
- 半年前から誰も使っていない古いIAMロールやアクセスキーは、格好のターゲットになります。使っていないものは思い切って削除（あるいは無効化）しましょう。
3. CloudTrailとアラート通知をセットで設定する
- 泥棒が入ってきたときに「誰も気づいていなかった」というのが一番最悪のシナリオです。CloudTrailのログを有効にし、不審な動きがあったらSlackやメールに通知が飛ぶ仕組みを小さくてもいいので作っておきましょう。
セキュリティは、一度作ったら終わりではなく、日々の暮らしの戸締まりと同じです。
「一歩ずつ、安全で心地よいクラウド環境を作っていくんだ」という気持ちで、楽しみながらセキュリティ対策に向き合っていきましょうね。皆さんのインフラライフを心から応援しています！
コメント