【入門編】クラウド環境におけるIAM権限昇格のログ監視 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

こんにちは！クラウドのインフラやセキュリティの担当になったばかりの頃は、AWSやAzureといった言葉だけでも「なんだか難しそう……」と身構えてしまいますよね。

特に、目に見えないクラウドの世界で「誰がどこまで触っていいのか」を管理するIAM（Identity and Access Management）の権限周りは、覚えることも多くて頭がクラクラしてしまうかもしれません。

でも、安心してください。難解に見えるクラウドのセキュリティも、「私たちの身の回りにある防犯の仕組み」に置き換えてみると、驚くほどスッと頭に入ってくるようになります。

今回は、サイバー攻撃者が一番狙いたがる「クラウドの合鍵（権限昇格）」について、現場の裏側も交えながら、一歩ずつ優しく紐解いていきましょう！

—

1. クラウドのセキュリティを「家の鍵」に例えてみましょう

まずは、私たちが普段暮らしている「お家」を想像してみてください。

皆さんはお出かけするとき、玄関の鍵をちゃんと閉めますよね。そして、家族には合鍵を渡すけれど、見ず知らずの他人に家の合鍵をポンと渡したりはしないはずです。

通常のユーザー（一般開発者など）： リビングに入ったり、自分の部屋で作業したりできる「一般的な鍵」を持っています。
管理者（マスターキー持ち）： 家のすべての部屋に入り、新しい鍵を作ったり、窓の鍵の仕組みをごっそり変えたりできる「強力なマスターキー」を持っています。

さて、もし「泥棒」があなたの家に入ろうとしたとき、どうやって侵入するでしょうか？
正面から強引にドアをぶっ壊すのは目立つので、彼らはもっとスマートな方法を使います。

それは、「たまたま鍵が開いていた窓からこっそり侵入し、家の中の引き出しから『マスターキー』を見つけ出して自分を『家族（管理者）』に格上げする」という手口です。

クラウドの世界でもこれと全く同じことが起きます。攻撃者は、新人がうっかり強めの権限を持ったまま放置していたアカウントや、パスワードが甘かったアカウントを足がかりにして侵入し、自分たちの権限をこっそり「最高権限（マスターキー）」に書き換えてしまうのです。これが、今回お話しする「IAM権限昇格」の正体です。

—

2. 攻撃者はクラウドでどうやって「合鍵」を手に入れるのか？

クラウド（AWSやAzure）では、ユーザーやプログラムが「何ができるか」を細かいルール（ポリシー）で管理しています。

攻撃者がよく使う手口は、主に次の3つです。

1. アクセスキーの不正発行（勝手に合鍵を作る）：
侵入したアカウントに「新しい鍵（アクセスキー）を作る権限」があった場合、攻撃者は自分用の合鍵を勝手に量産し、元のパスワードを変えられてもいつでも戻ってこられるように裏口を作ります。
2. AssumeRoleの濫用（他人の権限を一時的に借りパクする）：
AWSには AssumeRole という、一時的に別の強い権限に変身できる便利な仕組みがあります。お父さんの財布から、必要なときだけ「お小遣い帳の管理権限」を借りるようなイメージです。しかし、この変身のルールがガバガバだと、攻撃者は一番強い「家全体を支配できる権限」に変身してしまいます。
3. ポリシーの書き換え（窓の鍵を勝手に外す）：
自分に与えられたルールブックをこっそり書き換えて、「私はこのクラウドのすべての操作をしていい神様です！」という一文を付け足してしまいます。

現場のセキュリティエンジニアは、こうした「怪しい動き」がログに残っていないかを日夜チェックしているわけです。

—

3. 現場で役立つ！怪しい動きを見つけるログ監視クエリ

「じゃあ、どうやってそんなコソ泥の足跡を見つけるの？」と思いますよね。
AWSなら CloudTrail という全操作の記録係が、Azureなら Azure Activity Log が、すべての動きをノートに書き留めてくれています。

ここでは、AWSのログ（CloudTrail）を分析するときによく使われる検索クエリ（Athena用）のサンプルを、初心者向けに分かりやすくコメント付きで紹介しますね。

パターンA：勝手に新しいアクセスキー（合鍵）が作られていないか？

「普段はアクセスキーなんて作らない一般のシステムユーザー」が、急に新しい鍵を発行した瞬間をキャッチするクエリです。

SELECT
  eventTime,             -- 操作が行われた日時
  userIdentity.username, -- 誰が操作したか
  sourceIPAddress,       -- どこからアクセスしてきたか（怪しい海外IPじゃないか？）
  requestParameters      -- どんなお願いをしたか
FROM
  aws_cloudtrail_logs.your_table_name
WHERE
  eventSource = 'iam.amazonaws.com'
  AND eventName = 'CreateAccessKey' -- 新しいアクセスキーを作成するAPI
  AND errorCode IS NULL             -- エラーになっておらず、成功しているもの
ORDER BY
  eventTime DESC;

ここがポイント：
もし sourceIPAddress に見覚えのない国のIPアドレスが入っていたり、深夜にこのログが流れてきたりしたら……赤信号です！すぐにそのアカウントの鍵を凍結しましょう。

パターンB：強い権限への「変身（AssumeRole）」が乱用されていないか？

次に、誰かが怪しい権限に「変身」していないかを暴くクエリです。

SELECT
  eventTime,
  userIdentity.arn,        -- 変身した人の元の姿
  requestParameters,       -- どの役割（Role）に変身しようとしたか
  responseElements
FROM
  aws_cloudtrail_logs.your_table_name
WHERE
  eventName = 'AssumeRole' -- 別の権限に変身するAPI
  -- ここに特に強力な管理用ロールの名前を指定して監視します
  AND requestParameters LIKE '%AdministratorAccess%'
  AND errorCode IS NULL
ORDER BY
  eventTime DESC;

—

4. 今日からできる！クラウドの防犯対策

「ログ監視も大事だけど、そもそも泥棒に入られにくい家にしたい！」ですよね。
クラウドの世界で最初にやるべき基本的な防犯対策をまとめておきます。

多要素認証（MFA）の徹底：

家の鍵に加えて、「スマホに飛んでくる暗証番号」の二重ロックをかけましょう。これだけで不正アクセスの大半を防げます。

最小権限の原則を守る：

新人のメンバーや普段のアプリには、「自分の部屋の鍵」だけを渡し、必要のない強力な権限（マスターキー）は絶対に持たせないようにしましょう。

定期的な大掃除（棚卸し）：

退職した人のアカウントや、使わなくなった古いアクセスキーがそのまま放置されていないか、定期的にチェックする習慣をつけましょう。

—

おわりに

クラウドのIAM権限昇格の監視というと、何やら専門知識が詰まった難解な要塞のように思えたかもしれませんが、本質は「誰が、いつ、どの鍵を触ったか」という身の回りの防犯と全く同じです。

一歩ずつ、まずは「誰が新しい鍵を作ったか」のログを眺めるところから、クラウドの安全を守る第一歩を踏み出してみませんか？
皆さんのインフラ生活が、安全で快適なものになるよう応援しています！