【入門編】 IAMロールの信頼ポリシーにおける条件句(Condition)の活用 – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

みなさん、こんにちは！セキュリティの世界へようこそ。
日々の開発やインフラ構築、本当にお疲れ様です。

「AWSの権限管理（IAM）って、設定項目が多くてなんだか難しそう…」
「もし設定を間違えて、大切なデータが泥棒（サイバー攻撃者）に盗まれたらどうしよう…」

そんな不安を抱えていませんか？でも、安心してください。セキュリティは、基本を一つずつ紐解いていけば、決して怖いものではありません。

今回は、AWSセキュリティの要である「IAMロール」、そしてその鍵の守衛とも言える「信頼ポリシー（Trust Policy）の条件句（Condition）」について、身近な「お家の防犯」に例えながら、どこよりも優しく、かつ実戦で即座に使える深さで解説していきます。

一歩ずつ、一緒にセキュリティの階段を上っていきましょう！

—

1. IAMロールと信頼ポリシーは「ホテルのフロント」と「カードキー」

まず、IAMロールの仕組みをイメージしやすいように、「高級ホテルのカードキー」に例えてみましょう。

AWSにおける「ユーザー（IAM User）」が「特定の個人（あなた）」を指すのに対し、「ロール（IAM Role）」は「役割（フロント、清掃員、宿泊客など）」を指します。

このホテルのカードキー（IAMロール）をフロントで受け取る際、フロントのスタッフはあなたにこう尋ねますよね。

「お客様、ご予約のお名前と、ご本人確認書類（パスポートなど）を見せていただけますか？」

この、「そもそも、このカードキーを誰に貸し出して良いか？」というフロントの確認ルールこそが、AWSでいう「信頼ポリシー（Trust Policy）」になります。

信頼ポリシーで「この人になら鍵を貸していいよ」と許可することを、AWS用語では「ロールを引き受ける（AssumeRole）」と呼びます。

—

2. なぜ「条件（Condition）」が必要なのか？

「信頼ポリシーで、開発者のAさんや、連携するプログラムに鍵を渡す設定にしたから、これで安心！」

…本当にそうでしょうか？
もし、Aさんがカフェの公共Wi-Fiを使って作業しているとき、悪い泥棒にパソコンをハッキングされ、フロントからカードキーを受け取るための「暗証番号（アクセスキー）」を盗まれてしまったらどうなるでしょう。

泥棒はAさんになりすましてフロントに行き、「Aです。カードキーをください」と言って、簡単に部屋に侵入できてしまいます。

そこで登場するのが、今回の主役である「条件（Condition）」です。
フロントのスタッフに、以下のような「追加の防犯ルール」をあらかじめ指示しておくのです。

ルール1（IPアドレス制限）：「Aさんからの要求であっても、会社のオフィス（特定のIPアドレス）以外からの受け取りは絶対に拒否してください」
ルール2（MFA制限）：「Aさんのスマホに送られるワンタイムパスワード（MFA）を入力した形跡がない場合は、鍵を渡さないでください」

このルールを設定しておけば、万が一暗証番号が世界中のどこかで漏洩したとしても、泥棒は会社の外から鍵を手に入れることができなくなります。これが「Condition」の強力な力なのです。

—

3. 実践！信頼ポリシーの書き方（Conditionの活用）

それでは、実際にAWSで使える「信頼ポリシー」のコードを見てみましょう。
今回は、新人のみなさんでもそのままコピー＆ペーストして、カスタマイズして使える実用的なテンプレートを用意しました。

このポリシーは、「特定のAWSアカウントのユーザー」に対して、「MFA（多要素認証）が必須」かつ「特定のIPアドレスからのみ」ロールの引き受け（AssumeRole）を許可するという、非常にセキュアな設定になっています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAssumeRoleWithIPAndMFA",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root" 
        /* ↑鍵を貸し出す対象のAWSアカウントIDを指定します（あなたの会社のアカウントなど） */
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
          /* ↑「MFA（多要素認証）をクリアしていること」を必須にする条件です */
        },
        "NotIpAddress": {
          "aws:SourceIp": [
            "192.0.2.0/24",
            "198.51.100.0/22"
          ]
          /* ↑「指定されたオフィスのIPアドレス『以外』からのアクセスは拒否する」という強力なフィルターです。
             ここにあなたの会社のグローバルIPアドレスを記載します */
        }
      }
    }
  ]
}

コードの解説

Principal: 誰がこの鍵を使おうとしているかを指します。ここでは、指定したAWSアカウント内のユーザー全員が候補になります。
Action: sts:AssumeRole は、「鍵を貸し出す（ロールを引き受ける）」というアクションそのものを指します。
Condition（条件句）:
aws:MultiFactorAuthPresent: これが "true" であるということは、「二段階認証の鍵をちゃんと通してきた人だけね」という意味になります。
NotIpAddress と aws:SourceIp: 「このIPアドレスの範囲ではない場合は、ポリシーを適用しない（＝拒否する）」という記述方法です。これにより、指定外のIP（例えば自宅や海外の怪しいIP）からのアクセスを完全にシャットアウトします。

—

4. クロスアカウントアクセスの罠と「友達の友達」リスク

次に、少し応用的な、でも実務では非常によくあるシチュエーションをお話しします。
それが「クロスアカウントアクセス（他社や別プロジェクトのAWSアカウントとの連携）」です。

例えば、あなたがセキュリティ監視を専門とする「B社（SaaSベンダー）」を契約したとします。
B社のアカウントから、あなたのAWSアカウント内のログ（データ）を定期的に見に来てもらうために、あなたはB社専用の「IAMロール」を作り、B社のアカウントIDに対して鍵を貸し出す設定（信頼ポリシー）を書きました。

ここで、泥棒（悪意ある第三者）が目をつけます。
もし泥棒がB社のシステムを騙って、あなたのフロント（AWS）に「B社の者です。A社（あなた）の鍵をください」と要求したらどうなるでしょうか？

これをセキュリティの世界では「混乱した代理（Confused Deputy）問題」と呼びます。

B社は多くの企業のデータを扱っています。泥棒がB社のシステムに対して「A社のデータを取ってきて」と命令した際、B社が「誰の命令で動いているか」を区別できないと、B社という「信頼された代理人」を経由して、あなたのデータが盗まれてしまうのです。

防犯の合言葉「外部ID（External ID）」を導入しよう！

この「混乱した代理問題」を防ぐために、信頼ポリシーには必ず「外部ID（ExternalId）」という「秘密の合言葉」を設定します。

これは、あなたとB社の間だけで共有する、世界に一つだけのパスワードのようなものです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountWithExternalID",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::444455556666:root"
        /* ↑信頼する外部のパートナー企業（B社）のAWSアカウントID */
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "SuperSecretToken123456"
          /* ↑パートナー企業とあなたとの間で事前に決めた「秘密の合言葉（外部ID）」です。
             これが一致しない限り、たとえB社からのアクセスであっても鍵は貸し出しません */
        }
      }
    }
  ]
}

なぜこれで防げるの？

泥棒がB社のシステムを悪用してあなたのデータにアクセスしようとしても、泥棒は「あなたとB社の間で取り決めた合言葉（SuperSecretToken123456）」を知りません。
そのため、B社からあなたのAWSに対してロールの要求が飛んだ際、合言葉が不一致となり、AWSはアクセスを断固としてブロックします。

他社サービス（SaaSなど）と連携するIAMロールを作成する際は、「External IDの入力欄が提供されているか？」を必ず確認し、設定するようにしましょう。これだけで、クロスアカウントのセキュリティリスクは劇的に低下します。

—

5. まとめ：一歩ずつ、安全なシステムを作っていきましょう！

お疲れ様でした！今回はAWSセキュリティの非常に重要な部分である「信頼ポリシー」と「Condition」について学びました。

最後に、今回学んだ防犯のポイントを振り返ってみましょう。

1. 信頼ポリシーは「鍵を誰に貸すか」のルールである。
2. Condition を使うことで、IP制限やMFA（二段階認証）という追加の鍵をかけられる。
3. 他社アカウントに鍵を貸すときは、必ず「外部ID（External ID）」という合言葉を設定する。

セキュリティは一見難しそうに見えますが、こうして「お家の防犯」に置き換えてみると、「なるほど、だからこの設定が必要なんだ！」と納得していただけたのではないでしょうか。

一度にすべてを完璧にする必要はありません。まずは開発環境のロールに、自分のオフィスのIP制限をかけるところから、一歩ずつ試してみてくださいね。

あなたの開発するシステムが、より安全で素晴らしいものになることを心から応援しています。また次回のセキュリティバイブルでお会いしましょう！