【実務・中級編】マルチクラウド環境における権限管理の複雑性とIDフェデレーションの統合 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

マルチクラウドのIDフェデレーション：利便性の裏に潜む「権限の肥大化」という時限爆弾

現場で数多のインシデントを見てきたが、マルチクラウド運用において「IDフェデレーション（SAML/OIDC）」を導入した瞬間にセキュリティホールが生まれるケースは後を絶たない。

「AWSとAzureとGCP、全部のアカウントを管理するのが面倒だから、IDプロバイダ（IdP）を一箇所にまとめてシングルサインオン（SSO）しよう」

この判断自体は正しい。だが、「どのクラウドでも同じ権限が使える」という設計ミスが、一度の認証突破を大惨事へと変える。今日は、泥臭いインフラ現場の視点から、この複雑性をどう制圧するかを説いていく。

—

1. 攻撃者が狙う「IDフェデレーション」の盲点

攻撃者は、IDフェデレーションの設定が甘い環境を「横展開（Lateral Movement）」の踏み台として利用する。

例えば、開発環境で実験的に付与した ReadOnlyAccess のロールが、フェデレーションの設定ミスで本番環境のIdPユーザーにも紐付いてしまっていたとする。攻撃者が開発者の端末をマルウェアで感染させ、セッションをハイジャックすれば、そのまま本番環境の機密データへ最短距離でアクセスできる。

攻撃のPoCイメージ

1. reconnaissance: IdPのメタデータエンドポイントから、信頼関係にあるサービスプロバイダ（SP）の情報を列挙。
2. Exploitation: 設定不備のあるIAMロールに対し、不当なアサーションを送り込み、昇格した権限を取得。
3. Persistence: 複数のクラウド間で共通のIdPを利用しているため、片方のクラウドで永続的なアクセス権を得れば、他方へのバックドアも開通する。

—

2. 「最小権限の原則」を強いるためのIAM設計

マルチクラウドで最もやってはいけないのが、IdP側のグループをそのままクラウド側のロールにマッピングすることだ。「どの環境の、どのリソースに対し、何を許可するか」を明示的に記述しなければならない。

AWSのIAMロールで、信頼関係を厳格に制限するポリシー例を見てほしい。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:saml-provider/MyCompanyIdP"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        },
        "StringLike": {
          "SAML:sub": "engineering-team-*" 
          // IdPから渡されるユーザー名が特定のパターンに合致する場合のみ許可する
        }
      }
    }
  ]
}

この設定の肝は Condition ブロックだ。単に「IdPを信頼する」のではなく、誰が、どのターゲットに対して要求を出せるかをここで縛り上げる。

—

3. 実装の鉄則：IdPとSP間の属性マッピング

OIDCを使用する場合、アプリケーション側で受け取るトークンの検証を怠ると、偽造されたIDトークンを突きつけられる。Python（Flask）でのトークン検証サンプルを用意した。

from jose import jwt
import requests

# IdPから公開されているJWKSエンドポイントをキャッシュして使用する
def verify_id_token(token):
    # 実際の実務ではjwks_clientを使用して鍵を自動取得する
    key = get_public_key_from_idp()
    
    try:
        # トークンの署名検証と有効期限（exp）の確認を必須とする
        payload = jwt.decode(token, key, algorithms=['RS256'], audience='my-app-client-id')
        
        # 重要なのは「権限（Scope/Claims）」をここでフィルタリングすること
        if 'admin' not in payload.get('roles', []):
            raise Exception("権限不足")
            
        return payload
    except jwt.JWTError as e:
        # ログには詳細を残すが、ユーザーには汎用的なエラーを返す
        log_security_event(f"Token validation failed: {e}")
        return None

4. 運用エンジニアへの提言：なぜ「要塞化」が必要か

サーバーOSの要塞化（ハーデニング）と同様に、クラウドの権限管理も「使っていないものは全て塞ぐ」のが鉄則だ。

不要なIdP連携の削除: プロジェクトが終わったら、即座に当該ロールとIdPのコネクタを削除する。
権限の棚卸し: 90日ごとにアクセスログを突き合わせ、実際に使われていない AssumeRole 権限を削除するスクリプトをCI/CDに組み込む。
特権IDの排除: AdministratorAccess を個人に付与する運用は論外だ。常に「Just-In-Time (JIT) アクセス」による一時的な昇格を前提に設計せよ。

最後に

クラウドの利便性は、セキュリティの複雑さとトレードオフの関係にある。しかし、技術でカバーできない領域はない。

君たちがコードを書くとき、あるいはインフラを構築するとき、常に自問自答してほしい。「この権限は、今のこの瞬間のタスクに本当に必要か？それ以上の権限を要求していないか？」と。その疑い深さこそが、最強の防御壁になる。

明日からの運用で、まずは「IAMロールの信頼ポリシー」に Condition が抜けていないか、確認することから始めてほしい。それが、君たちの組織を守る第一歩だ。