Just-In-Time（JIT）アクセスとPrivileged Access Management（PAM）入門

ゼロトラストセキュリティにおいて、特権アカウントの管理は最も重要な課題の1つです。管理者権限やルートアクセスなどの特権は、システム全体に影響を及ぼす強力な権限であり、攻撃者にとって最も価値の高い標的となります。従来の「常時アクセス可能」なモデルでは、特権アカウントが侵害された場合の被害は甚大です。

本記事では、Just-In-Time（JIT）アクセスとPrivileged Access Management（PAM）について以下の内容を解説します。

• 特権アクセス管理における課題と常設権限のリスク
• Just-In-Time（JIT）アクセスの概念と実装パターン
• PAMソリューションの主要機能と選定ポイント
• Microsoft Entra PIM、HashiCorp Vault等による実装例
• JITアクセス導入のベストプラクティス

この記事を読むことで、特権アクセスのリスクを理解し、JITアクセスによる安全な運用設計ができるようになります。

前提知識

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

• ゼロトラストの基本原則を把握している
• 最小権限の原則（PoLP）を理解している
• IAMとアクセス制御の基本概念を知っている

ゼロトラストの基本原則についてはゼロトラストセキュリティ入門 - 基本原則と7つの柱を理解するを、最小権限アクセスの設計については最小権限アクセスの設計 - RBACとABACの使い分けを先に読むことをお勧めします。

期待される学習成果

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

1. 常設権限（Standing Privileges）のリスクを説明できる
2. JITアクセスの仕組みと利点を明確に説明できる
3. PAMソリューションの主要機能を理解し、選定基準を説明できる
4. 組織の要件に応じたJITアクセス戦略を策定できる
5. 実際のPAMソリューションでJITアクセスを設計・実装できる

特権アクセスとは

特権アクセス（Privileged Access）とは、一般ユーザーよりも高いレベルの権限を持つアクセスを指します。システム管理者、データベース管理者、ネットワーク管理者などが日常的に使用する権限であり、組織のITインフラストラクチャに対する広範な操作を可能にします。

特権アカウントの種類

特権アカウントは、その用途や権限レベルによって分類できます。

flowchart TB
    subgraph privileged["特権アカウントの分類"]
        direction TB
        
        subgraph super["スーパーユーザー"]
            root["root / Administrator"]
            desc1["システム全体への<br/>無制限アクセス"]
        end
        
        subgraph service["サービスアカウント"]
            svc["バッチ / 連携用"]
            desc2["アプリケーション間の<br/>自動処理"]
        end
        
        subgraph admin["管理者アカウント"]
            domain["ドメイン管理者"]
            db["DB管理者"]
            desc3["特定領域の<br/>管理権限"]
        end
        
        subgraph emergency["緊急アカウント"]
            glass["Break Glass"]
            desc4["障害時の<br/>緊急対応"]
        end
    end
    
    impact["影響範囲"]
    
    super --> |"最大"| impact
    admin --> |"中〜大"| impact
    service --> |"中"| impact
    emergency --> |"状況依存"| impact

特権アクセスが狙われる理由

特権アカウントは攻撃者にとって最も価値の高い標的です。その理由は以下の通りです。

広範な影響力

特権アカウントを取得すれば、システム設定の変更、データの窃取・改ざん、バックドアの設置、ログの消去など、あらゆる操作が可能になります。

横展開の起点

1つの特権アカウントを侵害すると、そこを足がかりにネットワーク全体へ横展開（Lateral Movement）できます。

検知の困難さ

正規の管理者権限を使った操作は、通常のアクセスと区別しにくく、検知が困難です。

IBMの調査によると、特権アカウントの侵害を含むデータ侵害の平均コストは、通常のデータ侵害と比較して約60%高くなっています。

常設権限（Standing Privileges）のリスク

常設権限（Standing Privileges）とは、恒常的に有効化されている特権アクセスを指します。「いつでも使える状態」の特権は、攻撃者にとって絶好の標的となります。

常設権限が生むリスク

flowchart LR
    subgraph risks["常設権限のリスク"]
        direction TB
        
        attack["攻撃面の拡大"]
        exposure["露出時間の増加"]
        creep["権限の蓄積"]
        insider["内部脅威"]
    end
    
    standing["常設権限<br/>Always On"]
    
    standing --> attack
    standing --> exposure
    standing --> creep
    standing --> insider
    
    attack --> breach["セキュリティ侵害"]
    exposure --> breach
    creep --> breach
    insider --> breach
    
    style standing fill:#f99,stroke:#333
    style breach fill:#f66,stroke:#333

攻撃面（Attack Surface）の拡大

常時有効な特権アカウントが多いほど、攻撃者が狙える標的が増えます。

露出時間の増加

権限が常に有効であれば、攻撃者がその権限を悪用できる時間的ウィンドウが無制限に存在します。

権限の蓄積（Privilege Creep）

時間の経過とともに、不要な権限が蓄積していきます。異動や役割変更後も以前の権限が残り続けるケースは非常に多く見られます。

内部脅威の増大

常設権限を持つ内部者が悪意を持った場合、あるいは不注意で操作した場合の被害が大きくなります。

衝撃的な統計データ

Microsoftの「State of Cloud Permissions Risks」レポートによると、クラウド環境における権限の実態は深刻です。

IBMのX-Force Redによるペネトレーションテストでは、99%のケースで過剰な権限を通じてクラウド環境の侵害に成功したと報告されています。

ゼロ常設権限（Zero Standing Privileges）の目標

理想的なセキュリティ状態は「ゼロ常設権限（Zero Standing Privileges: ZSP）」です。これは、すべての特権アクセスを必要な時にのみ、必要な期間だけ付与するモデルです。

flowchart TB
    subgraph traditional["従来モデル"]
        direction LR
        user1["管理者"]
        perm1["特権<br/>常時有効"]
        
        user1 --> perm1
    end
    
    subgraph zsp["ZSPモデル"]
        direction LR
        user2["管理者"]
        request["アクセス要求"]
        approval["承認・検証"]
        perm2["特権<br/>一時付与"]
        revoke["自動取消"]
        
        user2 --> request --> approval --> perm2 --> revoke
    end
    
    traditional --> |"移行"| zsp
    
    style perm1 fill:#f99,stroke:#333
    style perm2 fill:#9f9,stroke:#333

Just-In-Time（JIT）アクセスとは

Just-In-Time（JIT）アクセスは、ユーザーが特権を必要とする時にのみ、必要最小限の期間だけアクセス権を付与するセキュリティモデルです。「必要な時に、必要な権限を、必要な期間だけ」という原則に基づいています。

JITアクセスの基本原則

JITアクセスは、以下の3つの原則に基づいています。

JITアクセスのワークフロー

典型的なJITアクセスのワークフローは以下の流れで進みます。

sequenceDiagram
    participant User as ユーザー
    participant PAM as PAMシステム
    participant Approver as 承認者
    participant Target as ターゲットシステム
    participant Audit as 監査ログ
    
    User->>PAM: 1. アクセス要求<br/>（目的、期間、対象リソース）
    PAM->>PAM: 2. ポリシー評価<br/>（リスク分析、条件確認）
    
    alt 自動承認の場合
        PAM->>PAM: 自動承認
    else 承認が必要な場合
        PAM->>Approver: 3. 承認依頼
        Approver->>PAM: 4. 承認/拒否
    end
    
    PAM->>Target: 5. 権限付与
    PAM->>User: 6. アクセス許可通知
    User->>Target: 7. 特権操作の実行
    PAM->>Audit: 8. セッション記録
    
    Note over PAM,Target: 設定時間経過後
    
    PAM->>Target: 9. 権限自動取消
    PAM->>User: 10. アクセス終了通知
    PAM->>Audit: 11. 監査レポート生成

JITアクセスの実装パターン

JITアクセスにはいくつかの実装パターンがあります。

JITアカウント作成・削除

タスク実行のために一時的なアカウントを作成し、完了後に削除します。

flowchart LR
    request["アクセス要求"]
    create["アカウント作成"]
    task["タスク実行"]
    delete["アカウント削除"]
    
    request --> create --> task --> delete

JIT権限昇格

既存アカウントに一時的に権限を追加し、期限後に自動削除します。

flowchart LR
    request["昇格要求"]
    elevate["権限追加"]
    task["タスク実行"]
    revoke["権限取消"]
    
    request --> elevate --> task --> revoke

JITグループメンバーシップ

特権グループへの一時的なメンバー追加により、権限を付与します。

flowchart LR
    request["参加要求"]
    add["グループ追加"]
    task["タスク実行"]
    remove["グループ除外"]
    
    request --> add --> task --> remove

JIT無効化アカウント

事前に作成された無効状態のアカウントを、必要時にのみ有効化します。

flowchart LR
    disabled["無効状態"]
    enable["有効化"]
    task["タスク実行"]
    disable["無効化"]
    
    disabled --> enable --> task --> disable

JITアクセスのメリット

JITアクセスを導入することで、以下のメリットが得られます。

Privileged Access Management（PAM）とは

Privileged Access Management（PAM）は、特権アカウントとそのアクセスを管理、監視、保護するためのセキュリティソリューションおよびプラクティスの総称です。JITアクセスは、PAMの重要な機能の1つとして位置づけられます。

PAMの主要コンポーネント

flowchart TB
    subgraph pam["PAMソリューション"]
        direction TB
        
        subgraph vault["パスワードボールト"]
            store["認証情報の安全な保管"]
            rotate["パスワードの自動ローテーション"]
        end
        
        subgraph session["セッション管理"]
            record["セッション記録"]
            monitor["リアルタイム監視"]
            terminate["強制終了機能"]
        end
        
        subgraph workflow["承認ワークフロー"]
            request["アクセス要求"]
            approve["承認プロセス"]
            notify["通知機能"]
        end
        
        subgraph jit["JITアクセス"]
            time["時間制限"]
            scope["スコープ制限"]
            auto["自動取消"]
        end
        
        subgraph analytics["分析・レポート"]
            audit["監査ログ"]
            risk["リスク分析"]
            report["コンプライアンスレポート"]
        end
    end

パスワードボールト

パスワードボールトは、特権アカウントの認証情報を安全に保管・管理する機能です。

主な機能

• 認証情報の暗号化保管
• パスワードの自動ローテーション
• チェックアウト/チェックイン方式のアクセス
• APIによるシークレット配布

flowchart LR
    subgraph vault["パスワードボールト"]
        direction TB
        secret1["DB管理者パスワード"]
        secret2["サーバー管理者キー"]
        secret3["APIキー"]
        secret4["証明書"]
    end
    
    user["管理者"]
    app["アプリケーション"]
    
    user --> |"チェックアウト"| vault
    app --> |"API取得"| vault
    
    vault --> |"自動ローテーション"| target["ターゲットシステム"]

セッション記録と監視

特権セッションの記録と監視は、監査とインシデント対応に不可欠です。

記録対象

リアルタイム監視機能

flowchart LR
    session["特権セッション"]
    monitor["リアルタイム監視"]
    
    session --> monitor
    
    monitor --> alert["アラート生成"]
    monitor --> terminate["セッション終了"]
    monitor --> notify["管理者通知"]
    
    alert --> |"禁止コマンド検知"| response["インシデント対応"]
    terminate --> |"リスク行動検知"| response

承認ワークフロー

承認ワークフローは、特権アクセスの要求から付与までのプロセスを制御します。

flowchart TB
    subgraph workflow["承認ワークフロー"]
        direction TB
        
        request["アクセス要求"]
        validate["要求の検証"]
        
        decision{"承認タイプ"}
        
        auto["自動承認"]
        manual["手動承認"]
        multi["多段階承認"]
        
        grant["アクセス付与"]
        deny["アクセス拒否"]
    end
    
    request --> validate --> decision
    
    decision --> |"低リスク"| auto
    decision --> |"中リスク"| manual
    decision --> |"高リスク"| multi
    
    auto --> grant
    manual --> |"承認"| grant
    manual --> |"拒否"| deny
    multi --> |"全員承認"| grant
    multi --> |"誰か拒否"| deny

主要なPAMソリューション

Microsoft Entra Privileged Identity Management（PIM）

Microsoft Entra PIM（旧Azure AD PIM）は、Microsoft EntraおよびAzureリソースの特権アクセスを管理するクラウドネイティブなPAMソリューションです。

主な機能

ロール割り当ての種類

PIMでは、ロール割り当てを「Eligible（対象）」と「Active（アクティブ）」の2種類で管理します。

flowchart TB
    subgraph assignment["ロール割り当て"]
        direction LR
        
        subgraph eligible["Eligible（対象）"]
            e_desc["ロールの使用資格を持つ<br/>有効化が必要"]
        end
        
        subgraph active["Active（アクティブ）"]
            a_desc["ロールが常時有効<br/>操作不要で使用可能"]
        end
    end
    
    user["ユーザー"]
    
    user --> |"JIT推奨"| eligible
    user --> |"例外的"| active
    
    eligible --> |"有効化要求"| activation["一時的なアクティブ状態"]
    activation --> |"期限切れ"| eligible

PIMの設定例（Azure Portal）

ロール設定でJITアクセスのパラメータを構成します。

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

# 仮想マシン共同作成者ロールの設定例
ロール設定:
  有効化:
    最大有効化期間: 8時間
    有効化時にMFAが必要: はい
    有効化時に正当化が必要: はい
    有効化時にチケット情報が必要: いいえ
    有効化に承認が必要: はい
    承認者:
      - セキュリティ管理者グループ
  割り当て:
    永続的な対象割り当てを許可: いいえ
    対象割り当ての有効期限: 180日
    永続的なアクティブ割り当てを許可: いいえ
    アクティブ割り当ての有効期限: 15日
  通知:
    ロール有効化時にメール送信: はい
    割り当て時にメール送信: はい

Microsoft Graph APIでのPIM操作

プログラムからPIMを操作する場合の例を示します。

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

# 対象ロール割り当ての作成
POST https://graph.microsoft.com/v1.0/roleManagement/directory/roleEligibilityScheduleRequests
Content-Type: application/json

{
  "action": "adminAssign",
  "justification": "プロジェクトXのインフラ管理のため",
  "roleDefinitionId": "9b895d92-2cd3-44c7-9d02-a6ac2d5ea5c3",
  "directoryScopeId": "/",
  "principalId": "ユーザーのオブジェクトID",
  "scheduleInfo": {
    "startDateTime": "2026-01-24T08:00:00Z",
    "expiration": {
      "type": "afterDuration",
      "duration": "P180D"
    }
  }
}

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

# ロールの有効化要求
POST https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignmentScheduleRequests
Content-Type: application/json

{
  "action": "selfActivate",
  "principalId": "ユーザーのオブジェクトID",
  "roleDefinitionId": "9b895d92-2cd3-44c7-9d02-a6ac2d5ea5c3",
  "directoryScopeId": "/",
  "justification": "本番環境のデプロイ作業",
  "scheduleInfo": {
    "startDateTime": "2026-01-24T09:00:00Z",
    "expiration": {
      "type": "afterDuration",
      "duration": "PT4H"
    }
  },
  "ticketInfo": {
    "ticketNumber": "INC0012345",
    "ticketSystem": "ServiceNow"
  }
}

HashiCorp Vault

HashiCorp Vaultは、シークレット管理とデータ保護のためのオープンソースソリューションです。動的シークレット生成によるJITアクセスが特徴です。

Vaultの主要機能

flowchart TB
    subgraph vault["HashiCorp Vault"]
        direction TB
        
        subgraph secrets["シークレット管理"]
            kv["KVシークレット"]
            dynamic["動的シークレット"]
            pki["PKI証明書"]
        end
        
        subgraph auth["認証方式"]
            token["トークン"]
            ldap["LDAP"]
            oidc["OIDC"]
            k8s["Kubernetes"]
        end
        
        subgraph engines["シークレットエンジン"]
            database["データベース"]
            aws["AWS"]
            azure["Azure"]
            ssh["SSH"]
        end
    end
    
    app["アプリケーション"]
    
    app --> auth
    auth --> secrets
    secrets --> engines
    engines --> target["ターゲットシステム"]

動的シークレットによるJITアクセス

Vaultの動的シークレットは、要求時に認証情報を生成し、TTL（Time To Live）後に自動的に取り消します。

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

# PostgreSQLシークレットエンジンの設定
vault secrets enable database

# データベース接続の設定
vault write database/config/my-postgresql-database \
    plugin_name=postgresql-database-plugin \
    allowed_roles="readonly,readwrite" \
    connection_url="postgresql://{{username}}:{{password}}@localhost:5432/mydb" \
    username="vault_admin" \
    password="vault_admin_password"

# 読み取り専用ロールの作成（TTL: 1時間）
vault write database/roles/readonly \
    db_name=my-postgresql-database \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
        GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 動的認証情報の取得
vault read database/creds/readonly

# 出力例
Key                Value
---                -----
lease_id           database/creds/readonly/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
lease_duration     1h
lease_renewable    true
password           A1a-xxxxxxxxxxxxxxxxx
username           v-token-readonly-xxxxxxxxx

SSHシークレットエンジンによるJITアクセス

署名付きSSH鍵を生成し、一時的なサーバーアクセスを提供します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# SSHシークレットエンジンの有効化
vault secrets enable -path=ssh ssh

# CA証明書の設定
vault write ssh/config/ca generate_signing_key=true

# ロールの作成（TTL: 30分）
vault write ssh/roles/admin-role \
    key_type=ca \
    default_user=admin \
    allowed_users="admin,ubuntu" \
    allowed_extensions="permit-pty,permit-agent-forwarding" \
    ttl=30m \
    max_ttl=4h

1
2
3
4
5
6

# 署名付き公開鍵の取得
vault write ssh/sign/admin-role \
    public_key=@~/.ssh/id_rsa.pub

# サーバーへの接続（30分間有効）
ssh -i signed-cert.pub -i ~/.ssh/id_rsa admin@target-server

PAMソリューションの比較

主要なPAMソリューションの特徴を比較します。

JITアクセス導入のベストプラクティス

段階的な導入アプローチ

JITアクセスの導入は、以下の段階で進めることを推奨します。

flowchart LR
    subgraph phases["導入フェーズ"]
        direction LR
        
        phase1["Phase 1<br/>評価・計画"]
        phase2["Phase 2<br/>パイロット"]
        phase3["Phase 3<br/>展開"]
        phase4["Phase 4<br/>最適化"]
    end
    
    phase1 --> phase2 --> phase3 --> phase4

Phase 1: 評価・計画（1-2ヶ月）

Phase 2: パイロット（2-3ヶ月）

Phase 3: 展開（3-6ヶ月）

Phase 4: 最適化（継続）

設計時の考慮事項

適切なTTL（有効期間）の設定

flowchart TB
    subgraph ttl["TTL設定の指針"]
        direction TB
        
        routine["日常的なタスク<br/>1-4時間"]
        project["プロジェクト作業<br/>8時間-1日"]
        maintenance["定期メンテナンス<br/>作業時間+バッファ"]
        emergency["緊急対応<br/>必要最小限"]
    end
    
    note["原則：<br/>タスク完了に必要な<br/>最小限の時間"]

承認ワークフローの設計

緊急アクセス（Break Glass）の設計

通常の承認プロセスでは対応できない緊急事態に備え、Break Glassプロセスを設計します。

flowchart TB
    incident["重大インシデント発生"]
    normal{"通常プロセス<br/>で対応可能？"}
    
    incident --> normal
    
    normal --> |"はい"| standard["標準JITプロセス"]
    normal --> |"いいえ"| breakglass["Break Glassプロセス"]
    
    breakglass --> access["緊急アクセス取得"]
    access --> resolve["問題解決"]
    resolve --> review["事後レビュー必須"]
    
    standard --> resolve2["問題解決"]
    
    style breakglass fill:#ff9,stroke:#333
    style review fill:#f99,stroke:#333

Break Glassアカウントの要件は以下の通りです。

• 多要素認証の強制
• 使用時の即座アラート
• すべての操作の詳細ログ
• 使用後の必須事後レビュー
• 定期的な動作確認テスト

運用上の考慮事項

サービスアカウントの扱い

サービスアカウントは自動化プロセスで使用されるため、完全なJIT化が困難な場合があります。

ユーザー体験の最適化

JITアクセスがユーザーの生産性を阻害しないよう、以下を考慮します。

• セルフサービスポータルの提供
• モバイル対応の承認アプリ
• 事前承認（Pre-approved）パターンの活用
• 承認者の応答時間SLAの設定

JITアクセスの効果測定

導入効果を測定するための主要なKPIを設定します。

まとめ

本記事では、Just-In-Time（JIT）アクセスとPrivileged Access Management（PAM）について解説しました。

• 特権アカウントは攻撃者の最重要標的であり、常設権限は重大なリスク
• JITアクセスは「必要な時に、必要な権限を、必要な期間だけ」付与するモデル
• PAMソリューションはパスワードボールト、セッション管理、承認ワークフロー、JITアクセス等を提供
• Microsoft Entra PIMはMicrosoft環境、HashiCorp Vaultはマルチクラウド環境に適している
• 段階的な導入アプローチと適切な設計が成功の鍵

JITアクセスの導入により、特権アカウントの攻撃面を90%以上削減しながら、監査対応やコンプライアンス要件への適合を実現できます。ゼロ常設権限（ZSP）を目指し、継続的な改善を進めていきましょう。

次のステップとして、ゼロトラストにおける継続的検証 - リスクベース認証と行動分析で、アクセス後の継続的な監視について学ぶことをお勧めします。

参考リンク

• Microsoft Entra Privileged Identity Management
• HashiCorp Vault
• NIST SP 800-63B: Digital Identity Guidelines - Authentication and Lifecycle Management
• BeyondTrust - Just-In-Time Access
• Gartner - Privileged Access Management