ゼロトラストにおけるアイデンティティ管理 - IAMとIdPの基礎

ゼロトラストセキュリティにおいて、「誰がアクセスしているか」を常に検証することは最も重要な柱の一つです。境界型セキュリティでは、一度社内ネットワークに入れば暗黙的に信頼されていましたが、ゼロトラストではすべてのアクセス要求に対してアイデンティティの検証が求められます。

本記事では、ゼロトラストにおけるアイデンティティ管理について以下の内容を解説します。

• Identity and Access Management（IAM）の役割と構成要素
• Identity Provider（IdP）の仕組みとゼロトラストにおける位置づけ
• SAML、OAuth 2.0、OpenID Connectの違いと使い分け
• シングルサインオン（SSO）の実現方法とメリット
• 主要なIdPソリューションの比較

この記事を読むことで、アイデンティティ管理の基本を理解し、IdP導入のメリットを論理的に説明できるようになります。

前提知識

本記事を理解するために、以下の知識があることを前提としています。

• ゼロトラストの基本原則を把握している
• HTTPの基本（リクエスト、レスポンス、ヘッダー）を理解している
• 認証と認可の違いを知っている

ゼロトラストの基本原則については、ゼロトラストセキュリティ入門 - 基本原則と7つの柱を理解するを先に読むことをお勧めします。また、境界型セキュリティの限界については、境界型セキュリティの限界とゼロトラストへの移行が必要な理由で解説しています。

期待される学習成果

本記事を読み終えると、以下のことができるようになります。

1. IAMの役割と主要コンポーネントを説明できる
2. IdPの仕組みとゼロトラストにおける重要性を理解できる
3. SAML、OAuth 2.0、OpenID Connectの違いを明確に説明できる
4. SSOのメリットと実装パターンを把握できる
5. 自組織に適したIdPソリューションの選定基準を説明できる

なぜアイデンティティがゼロトラストの中核なのか

ゼロトラストセキュリティの7つの柱の中で、アイデンティティは最も基本的かつ重要な要素です。ゼロトラストの原則「Never Trust, Always Verify」を実現するためには、すべてのアクセス要求に対して「誰がアクセスしているか」を確実に検証する必要があります。

flowchart LR
    subgraph identity["アイデンティティ検証"]
        user["ユーザー"]
        device["デバイス"]
        app["アプリケーション"]
    end
    
    subgraph verification["検証プロセス"]
        authn["認証<br/>（誰か？）"]
        authz["認可<br/>（何ができるか？）"]
    end
    
    subgraph resources["リソース"]
        data["データ"]
        service["サービス"]
        system["システム"]
    end
    
    user --> authn
    device --> authn
    app --> authn
    authn --> authz
    authz --> data
    authz --> service
    authz --> system

認証と認可の違い

アイデンティティ管理を理解するうえで、認証（Authentication）と認可（Authorization）の違いを明確にしておくことが重要です。

ゼロトラストでは、この認証と認可を継続的に実行することで、常にアクセスの妥当性を検証します。

NIST SP 800-207におけるアイデンティティの位置づけ

NIST SP 800-207「Zero Trust Architecture」では、Policy Decision Point（PDP）がアクセス判断を行う際に、以下のアイデンティティ関連情報を評価することを規定しています。

• ユーザーのアイデンティティと認証状態
• デバイスの識別情報とセキュリティ状態
• アプリケーションの識別情報
• アクセス要求のコンテキスト（場所、時間、リスクレベル）

これらの情報を統合的に管理し、一貫した検証を行うためのシステムがIAMです。

Identity and Access Management（IAM）とは

IAM（Identity and Access Management）は、組織内のユーザー、デバイス、アプリケーションのアイデンティティを管理し、適切なリソースへのアクセスを制御するためのフレームワークです。

IAMの主要コンポーネント

IAMは複数のコンポーネントで構成されており、それぞれが異なる役割を担っています。

flowchart TB
    subgraph iam["IAMフレームワーク"]
        direction TB
        subgraph identity_mgmt["アイデンティティ管理"]
            provisioning["プロビジョニング<br/>（アカウント作成・変更・削除）"]
            directory["ディレクトリサービス<br/>（ユーザー情報の格納）"]
            lifecycle["ライフサイクル管理<br/>（入社・異動・退職）"]
        end
        
        subgraph access_mgmt["アクセス管理"]
            authn_service["認証サービス<br/>（本人確認）"]
            authz_service["認可サービス<br/>（権限付与）"]
            sso["シングルサインオン<br/>（統合認証）"]
        end
        
        subgraph governance["ガバナンス"]
            audit["監査ログ<br/>（アクセス記録）"]
            compliance["コンプライアンス<br/>（規制対応）"]
            certification["アクセス棚卸<br/>（権限の定期レビュー）"]
        end
    end
    
    identity_mgmt --> access_mgmt
    access_mgmt --> governance

各コンポーネントの役割を詳しく見ていきます。

アイデンティティ管理

アイデンティティ管理は、ユーザーアカウントのライフサイクル全体を管理します。

• プロビジョニング: ユーザーアカウントの作成、変更、削除を自動化します。人事システムと連携し、入社時のアカウント作成や退職時の即時無効化を実現します。
• ディレクトリサービス: ユーザー情報、グループ情報、組織情報を一元的に格納します。Active DirectoryやLDAPが代表的な実装です。
• ライフサイクル管理: 入社、異動、退職、休職などのイベントに応じて、アカウントの状態と権限を適切に管理します。

アクセス管理

アクセス管理は、認証と認可を通じてリソースへのアクセスを制御します。

• 認証サービス: パスワード、多要素認証、生体認証などを用いて本人確認を行います。
• 認可サービス: 認証されたユーザーに対して、ポリシーに基づいたアクセス権限を付与します。
• シングルサインオン: 一度の認証で複数のアプリケーションにアクセスできる仕組みを提供します。

ガバナンス

ガバナンスは、セキュリティとコンプライアンスを確保するための機能を提供します。

• 監査ログ: すべてのアクセス試行と権限変更を記録し、追跡可能性を確保します。
• コンプライアンス: 法規制や業界標準への準拠を支援します。
• アクセス棚卸: 定期的に権限をレビューし、不要な権限を削除します。

IAMがゼロトラストにもたらす価値

ゼロトラスト環境において、IAMは以下の価値を提供します。

Identity Provider（IdP）の仕組み

Identity Provider（IdP）は、ユーザーのアイデンティティを認証し、その情報をサービスプロバイダー（SP）に提供する専門のシステムです。ゼロトラストにおいて、IdPは認証の中央集権化と標準化を実現する重要なコンポーネントです。

IdPの基本的な役割

IdPは以下の役割を担います。

sequenceDiagram
    participant User as ユーザー
    participant SP as サービスプロバイダー<br/>（アプリケーション）
    participant IdP as Identity Provider
    participant Dir as ディレクトリ<br/>（Active Directory等）
    
    User->>SP: 1. アクセス要求
    SP->>IdP: 2. 認証リダイレクト
    IdP->>User: 3. 認証画面表示
    User->>IdP: 4. 資格情報入力
    IdP->>Dir: 5. 資格情報検証
    Dir-->>IdP: 6. 検証結果
    IdP->>SP: 7. 認証結果（トークン/アサーション）
    SP->>User: 8. アクセス許可

1. 認証の実行: ユーザーの資格情報を検証し、本人確認を行います。
2. アイデンティティ情報の提供: 認証されたユーザーの属性情報（名前、メール、所属グループなど）をSPに提供します。
3. トークン/アサーションの発行: 認証結果を標準化された形式（SAMLアサーション、JWTなど）で発行します。
4. セッション管理: ユーザーのログイン状態を管理し、SSOを実現します。

IdPとSPの関係

IdPとSP（Service Provider）は信頼関係に基づいて連携します。

flowchart LR
    subgraph trust["信頼関係（Trust）"]
        direction TB
        idp["Identity Provider<br/>・ユーザー認証<br/>・トークン発行"]
        sp1["SP: SaaS A"]
        sp2["SP: SaaS B"]
        sp3["SP: 社内アプリ"]
    end
    
    idp -->|"メタデータ交換<br/>証明書共有"| sp1
    idp -->|"メタデータ交換<br/>証明書共有"| sp2
    idp -->|"メタデータ交換<br/>証明書共有"| sp3
    
    sp1 -->|"認証委任"| idp
    sp2 -->|"認証委任"| idp
    sp3 -->|"認証委任"| idp

この構成により、以下のメリットが得られます。

• 認証の一元化: ユーザーは一つの認証情報で複数のサービスにアクセスできます。
• セキュリティポリシーの統一: MFAや条件付きアクセスなどのポリシーをIdPで一元管理できます。
• アカウント管理の効率化: ユーザーの追加・削除をIdPで一括管理できます。

主要なIdPソリューション

現在、多くの企業で利用されている主要なIdPソリューションを比較します。

認証連携プロトコル

IdPとSP間の認証連携には、標準化されたプロトコルが使用されます。主要なプロトコルとして、SAML、OAuth 2.0、OpenID Connect（OIDC）があります。

SAML（Security Assertion Markup Language）

SAMLは、2000年代初頭から使用されている認証連携の標準プロトコルです。エンタープライズ環境でのSSO実現に広く採用されています。

SAMLの特徴

• XML形式のアサーションを使用
• ブラウザベースのSSOに最適化
• 認証情報と属性情報を同時に伝達
• 署名と暗号化による高いセキュリティ

SAML認証フロー（SP-initiated）

sequenceDiagram
    participant User as ユーザー
    participant SP as Service Provider
    participant IdP as Identity Provider
    
    User->>SP: 1. リソースアクセス
    SP->>User: 2. SAMLリクエストと共にIdPへリダイレクト
    User->>IdP: 3. SAMLリクエスト送信
    IdP->>User: 4. 認証画面表示
    User->>IdP: 5. 認証情報入力
    IdP->>IdP: 6. 認証処理
    IdP->>User: 7. SAMLレスポンス（アサーション）と共にSPへリダイレクト
    User->>SP: 8. SAMLレスポンス送信
    SP->>SP: 9. アサーション検証
    SP->>User: 10. リソースへのアクセス許可

SAMLアサーションの構造

SAMLアサーションには以下の情報が含まれます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <saml:Subject>
    <saml:NameID>user@example.com</saml:NameID>
  </saml:Subject>
  <saml:Conditions NotBefore="2026-01-24T10:00:00Z" 
                   NotOnOrAfter="2026-01-24T10:05:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://sp.example.com</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AuthnStatement AuthnInstant="2026-01-24T10:00:00Z">
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
      </saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
  <saml:AttributeStatement>
    <saml:Attribute Name="email">
      <saml:AttributeValue>user@example.com</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="groups">
      <saml:AttributeValue>developers</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

OAuth 2.0

OAuth 2.0は、アプリケーション間の認可を実現するためのプロトコルです。重要な点として、OAuth 2.0は認可のためのプロトコルであり、認証プロトコルではありません。

OAuth 2.0の特徴

• アクセストークンによる認可
• スコープによる権限の細分化
• リフレッシュトークンによるトークン更新
• 複数の認可フロー（Grant Type）をサポート

OAuth 2.0の主要な認可フロー

Authorization Codeフローの例

sequenceDiagram
    participant User as ユーザー
    participant Client as クライアントアプリ
    participant AuthServer as 認可サーバー
    participant Resource as リソースサーバー
    
    User->>Client: 1. サービス利用開始
    Client->>AuthServer: 2. 認可リクエスト
    AuthServer->>User: 3. ログイン・同意画面
    User->>AuthServer: 4. 認証・同意
    AuthServer->>Client: 5. 認可コード
    Client->>AuthServer: 6. トークンリクエスト（認可コード + クライアント資格情報）
    AuthServer->>Client: 7. アクセストークン（+ リフレッシュトークン）
    Client->>Resource: 8. APIリクエスト（アクセストークン付き）
    Resource->>Client: 9. リソースデータ

OpenID Connect（OIDC）

OpenID Connect（OIDC）は、OAuth 2.0の上に構築された認証レイヤーです。OAuth 2.0の認可機能に加えて、ユーザー認証とアイデンティティ情報の取得機能を提供します。

OpenID Connectの特徴

• OAuth 2.0を基盤とした認証プロトコル
• IDトークン（JWT形式）によるユーザー情報の伝達
• UserInfoエンドポイントによる詳細な属性情報の取得
• Discovery機能による設定の自動取得

OpenID Connectの認証フロー

sequenceDiagram
    participant User as ユーザー
    participant RP as Relying Party<br/>（クライアント）
    participant OP as OpenID Provider
    
    User->>RP: 1. ログイン要求
    RP->>OP: 2. 認証リクエスト（scope: openid profile email）
    OP->>User: 3. 認証画面
    User->>OP: 4. 認証情報入力
    OP->>RP: 5. 認可コード
    RP->>OP: 6. トークンリクエスト
    OP->>RP: 7. IDトークン + アクセストークン
    RP->>RP: 8. IDトークン検証
    RP->>OP: 9. UserInfoリクエスト（オプション）
    OP->>RP: 10. ユーザー属性情報
    RP->>User: 11. ログイン完了

IDトークンの構造（JWT）

IDトークンはJWT（JSON Web Token）形式で発行されます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

{
  "header": {
    "alg": "RS256",
    "typ": "JWT",
    "kid": "key-id-123"
  },
  "payload": {
    "iss": "https://idp.example.com",
    "sub": "user-123456",
    "aud": "client-app-id",
    "exp": 1706180400,
    "iat": 1706176800,
    "auth_time": 1706176800,
    "nonce": "abc123",
    "email": "user@example.com",
    "name": "山田 太郎",
    "groups": ["developers", "admin"]
  },
  "signature": "..."
}

プロトコルの比較と選択基準

各プロトコルの特徴を比較し、適切な選択を行うための基準を示します。

プロトコル選択のガイドライン

flowchart TD
    start["認証連携の<br/>要件は？"]
    
    start -->|"エンタープライズSSO"| q1["既存システムは<br/>SAML対応？"]
    start -->|"API保護のみ"| oauth["OAuth 2.0"]
    start -->|"モダンアプリ認証"| oidc["OpenID Connect"]
    
    q1 -->|"はい"| saml["SAML"]
    q1 -->|"いいえ"| q2["モバイル対応<br/>必要？"]
    
    q2 -->|"はい"| oidc
    q2 -->|"いいえ"| saml

シングルサインオン（SSO）の実現

シングルサインオン（SSO）は、一度の認証で複数のアプリケーションにアクセスできる仕組みです。ゼロトラスト環境において、SSOはユーザー体験の向上とセキュリティの強化を両立させる重要な機能です。

SSOのメリット

SSOを導入することで、以下のメリットが得られます。

ユーザー視点のメリット

• 複数のパスワードを覚える必要がない
• ログイン操作の回数が減少
• 生産性の向上

セキュリティ視点のメリット

• パスワード使い回しのリスク低減
• 認証ポリシーの一元管理
• 多要素認証の統一的な適用
• アカウント無効化の即時反映

管理者視点のメリット

• ユーザー管理の効率化
• パスワードリセット対応の削減
• 監査ログの一元化

SSOの実装パターン

SSOの実装には複数のパターンがあります。

パターン1: IdP-initiated SSO

ユーザーがIdPのポータルからアプリケーションを選択してアクセスするパターンです。

sequenceDiagram
    participant User as ユーザー
    participant IdP as Identity Provider
    participant SP as アプリケーション
    
    User->>IdP: 1. IdPポータルにログイン
    IdP->>User: 2. アプリ一覧表示
    User->>IdP: 3. アプリ選択
    IdP->>User: 4. 認証トークンと共にSPへリダイレクト
    User->>SP: 5. トークン送信
    SP->>User: 6. アプリにアクセス

パターン2: SP-initiated SSO

ユーザーがアプリケーションに直接アクセスし、認証が必要な場合にIdPへリダイレクトされるパターンです。

sequenceDiagram
    participant User as ユーザー
    participant SP as アプリケーション
    participant IdP as Identity Provider
    
    User->>SP: 1. アプリに直接アクセス
    SP->>User: 2. IdPへリダイレクト
    User->>IdP: 3. 認証リクエスト
    IdP->>User: 4. ログイン画面（未認証の場合）
    User->>IdP: 5. 認証情報入力
    IdP->>User: 6. 認証トークンと共にSPへリダイレクト
    User->>SP: 7. トークン送信
    SP->>User: 8. アプリにアクセス

SSOセッション管理

SSOを実装する際には、セッション管理について以下の点を考慮する必要があります。

ゼロトラストにおけるSSO

ゼロトラスト環境でSSOを運用する際には、以下の追加的なセキュリティ対策が必要です。

flowchart TB
    subgraph zt_sso["ゼロトラストSSO"]
        direction TB
        mfa["多要素認証の強制"]
        ca["条件付きアクセス"]
        risk["リスクベース認証"]
        continuous["継続的な検証"]
    end
    
    mfa --> ca
    ca --> risk
    risk --> continuous
    
    mfa -.->|"すべてのログインで<br/>MFAを要求"| note1["フィッシング耐性のある<br/>認証方式を推奨"]
    ca -.->|"アクセス条件を<br/>動的に評価"| note2["デバイス状態、場所、<br/>時間などを考慮"]
    risk -.->|"リスクスコアに<br/>応じた対応"| note3["高リスク時は追加<br/>認証を要求"]
    continuous -.->|"セッション中も<br/>継続的に検証"| note4["異常検知時は<br/>セッション終了"]

アイデンティティ管理のベストプラクティス

ゼロトラスト環境でアイデンティティ管理を実装する際のベストプラクティスを紹介します。

1. 一元化されたIdPの採用

すべてのアプリケーションの認証を一元化されたIdPで管理します。

• 複数のIdPが存在する場合は統合を検討
• 新規アプリケーションは必ずIdP連携を要件とする
• レガシーアプリケーションの段階的なIdP対応

2. 多要素認証の標準化

すべてのユーザーに多要素認証を適用します。

• パスワードレス認証（FIDO2/WebAuthn）の採用を推奨
• フィッシング耐性のある認証方式を優先
• リカバリープロセスも同等のセキュリティを確保

3. 最小権限の原則の適用

ユーザーには必要最小限の権限のみを付与します。

• ロールベースアクセス制御（RBAC）の導入
• 属性ベースアクセス制御（ABAC）による細かな制御
• 定期的な権限棚卸の実施

4. ライフサイクル管理の自動化

ユーザーアカウントのライフサイクル管理を自動化します。

• 人事システムとの連携
• 即時のアカウント無効化プロセス
• 孤立アカウントの定期的な検出と対処

5. 包括的な監査ログ

すべての認証イベントを記録し、分析可能にします。

• 認証成功・失敗のログ
• 権限変更のログ
• 異常パターンの検知とアラート

IdP導入のロードマップ

IdPを導入する際の段階的なアプローチを示します。

flowchart LR
    subgraph phase1["Phase 1<br/>基盤構築"]
        p1_1["IdP選定・導入"]
        p1_2["ディレクトリ統合"]
        p1_3["MFA有効化"]
    end
    
    subgraph phase2["Phase 2<br/>アプリ連携"]
        p2_1["主要SaaSのSSO化"]
        p2_2["社内アプリのSSO化"]
        p2_3["条件付きアクセス導入"]
    end
    
    subgraph phase3["Phase 3<br/>高度化"]
        p3_1["パスワードレス認証"]
        p3_2["リスクベース認証"]
        p3_3["継続的な検証"]
    end
    
    phase1 --> phase2
    phase2 --> phase3

Phase 1: 基盤構築（1〜3ヶ月）

• IdPソリューションの選定と初期設定
• 既存ディレクトリ（Active Directoryなど）との連携
• 全ユーザーへの多要素認証の展開

Phase 2: アプリケーション連携（3〜6ヶ月）

• 主要なSaaSアプリケーションのSSO設定
• 社内アプリケーションのIdP連携
• 条件付きアクセスポリシーの設計と実装

Phase 3: 高度化（6〜12ヶ月）

• パスワードレス認証の導入
• リスクベース認証の実装
• 継続的な検証メカニズムの構築

まとめ

本記事では、ゼロトラストにおけるアイデンティティ管理の基礎として、IAMとIdPの役割、認証連携プロトコル、SSOの実現方法について解説しました。

重要なポイントを振り返ります。

• アイデンティティはゼロトラストの中核: 「誰がアクセスしているか」を常に検証することが、ゼロトラストの基本原則です。
• IAMは包括的なフレームワーク: アイデンティティ管理、アクセス管理、ガバナンスを統合的に実現します。
• IdPは認証の一元化を実現: 複数のアプリケーションに対する認証を一箇所で管理できます。
• プロトコルは用途に応じて選択: SAML、OAuth 2.0、OpenID Connectはそれぞれ異なる用途に最適化されています。
• SSOはUXとセキュリティを両立: 適切に実装されたSSOは、ユーザー体験の向上とセキュリティ強化を同時に実現します。

次の記事では、多要素認証（MFA）とパスワードレス認証について詳しく解説し、より強固なアイデンティティ検証の実現方法を学びます。

参考リンク

• NIST SP 800-207 Zero Trust Architecture
• Microsoft Entra ID ドキュメント
• SAML 2.0 Technical Overview
• OAuth 2.0 RFC 6749
• OpenID Connect Core 1.0
• CISA Zero Trust Maturity Model