Identity & Access Management

Provisioning / SCIM

プロビジョニング(自動ID管理)

Category: Identity & Access Management / Updated: 2026-05-26

📖

Overview

プロビジョニング(Provisioning)とは、ユーザーアカウントの作成・変更・削除を自動的に実行するプロセスです。新入社員のアカウント作成から退職者のアカウント無効化まで、IDライフサイクル全体を自動化することで、セキュリティリスクの低減と運用効率の向上を実現します。デプロビジョニング(Deprovisioning)は、不要になったアカウントやアクセス権限を速やかに削除・無効化するプロセスであり、プロビジョニングと対をなす重要な機能です。

SCIM(System for Cross-domain Identity Management)は、異なるシステム間でユーザーID情報を自動的に同期するための標準プロトコルです。SCIM 2.0はRFC 7642〜7644で規定されており、REST APIベースでユーザーやグループの作成・読み取り・更新・削除(CRUD)操作を標準化します。これにより、IDプロバイダー(IdP)と各SaaSアプリケーション間のID同期を統一的な方法で実現できます。

現代の企業では、一人の従業員が平均して数十のSaaSアプリケーションを利用しており、手動でのアカウント管理は現実的ではありません。自動プロビジョニングは、入社初日から必要なすべてのツールへのアクセスを即座に提供し、退職時には数分以内にすべてのアクセスを遮断します。この自動化により、孤立アカウントのリスクを排除し、コンプライアンス要件への準拠を確実にします。

🔬

Details

SCIMプロトコルの仕組み

SCIM 2.0は、RESTful APIを通じてユーザーおよびグループのID情報を管理するための標準プロトコルです。JSON形式でデータを交換し、HTTP標準メソッド(GET、POST、PUT、PATCH、DELETE)を使用します。主要なリソースエンドポイントとして、/Users(ユーザー管理)、/Groups(グループ管理)、/ServiceProviderConfig(プロバイダー設定情報)が定義されています。

SCIMの大きな利点は、IDプロバイダーとサービスプロバイダー間のインターフェースを標準化することで、個別のAPI連携開発を不要にする点です。Microsoft Entra ID、Okta、Google Workspaceなどの主要IDaaSプラットフォームはSCIMに対応しており、SCIM対応のSaaSアプリケーションとの連携を容易に実現できます。

JITプロビジョニング(Just-In-Time Provisioning)

JITプロビジョニングは、ユーザーが初めてアプリケーションにアクセスした時点でアカウントを自動的に作成する方式です。事前のアカウント作成が不要なため、管理負荷を最小化できます。主にSAMLやOIDCなどのフェデレーション認証と組み合わせて使用されます。

JITプロビジョニングでは、IdPからのSAMLアサーションやOIDCトークンに含まれるユーザー属性情報(名前、メールアドレス、部署、ロールなど)を基にアカウントが作成されます。ただし、JITプロビジョニングだけではデプロビジョニングが自動化されないため、SCIMと併用してアカウントの削除・無効化も自動化することが推奨されます。

HR駆動型プロビジョニング

HR駆動型プロビジョニング(HR-Driven Provisioning)は、人事システム(HRIS)を信頼できるソース(Source of Truth)として、人事イベントに基づいてID管理を自動化するアプローチです。新入社員の登録、部署異動、休職、退職などの人事イベントがトリガーとなり、関連するすべてのシステムでアカウントの作成・変更・削除が自動実行されます。

Workday、SAP SuccessFactors、SmartHRなどのHRISと連携し、入社予定日の数日前にアカウントを事前作成したり、退職日に自動的にすべてのアクセスを無効化したりすることが可能です。これにより、IT部門の手動作業を大幅に削減し、人為的ミスによるセキュリティリスクを排除します。

主要IDaaSプラットフォーム

自動プロビジョニングを実現する主要なIDaaSプラットフォームとして、Microsoft Entra ID(旧Azure AD)OktaGoogle WorkspaceOneLoginPing Identityなどがあります。これらのプラットフォームは、数千のSaaSアプリケーションに対するプリビルトのSCIMコネクタを提供しています。

プラットフォーム選定にあたっては、対応アプリケーションカタログの充実度、カスタムコネクタの開発容易性、プロビジョニングログの詳細度、エラーハンドリング機能、およびSCIM以外のプロビジョニング方式(LDAP、データベース連携、REST API)への対応状況を総合的に評価することが重要です。

プロビジョニングの監視とトラブルシューティング

自動プロビジョニングの運用においては、同期エラーの迅速な検出と対応が不可欠です。属性マッピングの不一致、ターゲットシステム側のスキーマ変更、API レート制限超過など、さまざまな原因でプロビジョニングが失敗する可能性があります。

主要IDaaSプラットフォームは、プロビジョニングログ、同期ステータスダッシュボード、アラート通知機能を提供しています。運用チームは、失敗したプロビジョニングイベントを監視し、迅速に対応する体制を構築する必要があります。

🛡️

Security Measures

  • 01
    デプロビジョニングの即時実行体制の構築:退職・契約終了時のアカウント無効化を即座に実行できる自動化ワークフローを構築してください。HRシステムとの連携により、退職日にすべてのシステムへのアクセスが自動的に遮断される仕組みが不可欠です。
  • 02
    SCIMトークンの厳格な管理:SCIM連携に使用するAPIトークン(Bearer Token)は、最小権限で発行し、定期的にローテーションしてください。トークンの漏洩は全ユーザーのID情報への不正アクセスにつながるため、シークレット管理サービスでの保管を推奨します。
  • 03
    属性マッピングの定期的な検証:IdPとターゲットシステム間の属性マッピングが正確であることを定期的に検証してください。誤ったマッピングにより、ユーザーに意図しないロールや権限が付与されるリスクがあります。
  • 04
    プロビジョニングログの監視とアラート設定:プロビジョニングの成功・失敗をリアルタイムで監視し、失敗イベントに対するアラートを設定してください。特にデプロビジョニングの失敗は、不要なアカウントの残存につながるため最優先で対応しましょう。
  • 05
    孤立アカウントの定期スキャン:プロビジョニング対象外のレガシーシステムや手動管理のアプリケーションを含め、全システムを対象とした孤立アカウントの定期スキャンを実施してください。SCIMで管理されていないシステムのアカウントは特に注意が必要です。
  • 06
    プロビジョニングポリシーのテスト環境での事前検証:新しいプロビジョニングルールや属性マッピングの変更は、必ずテスト環境で事前検証してください。本番環境への直接適用は、大規模なアカウント誤作成やアクセス障害を引き起こす可能性があります。
⚠️

Incidents

📋 大手IT企業における退職者アカウント残存による情報漏洩(2020年)

ある大手IT企業において、デプロビジョニングプロセスの不備により、退職した元従業員のアカウントが複数のSaaSアプリケーション上で有効なまま放置されていました。同社はIdPでのSSOアクセスは無効化していたものの、個別のSaaSアプリケーションにローカルパスワードで直接ログインできる状態が残存していました。

元従業員は退職後もSaaSアプリケーションにアクセスし、顧客リストや営業戦略資料を競合他社に持ち出しました。調査により、SCIM連携が一部のアプリケーションにしか適用されておらず、手動でのデプロビジョニングが漏れていたことが判明しました。

📋 SCIMトークン漏洩による全ユーザーデータの不正取得(2022年)

あるSaaS企業において、GitHubのパブリックリポジトリに誤ってコミットされたSCIM APIトークンが攻撃者に発見されました。このトークンはフルスコープの権限を持っており、攻撃者はSCIM APIを通じて同社の全ユーザーアカウント情報(氏名、メールアドレス、部署、ロール情報)を取得しました。

さらに攻撃者は、SCIM APIのPATCHエンドポイントを使用して一部のユーザーのロールを管理者に昇格させ、システムへの持続的なアクセスを確立しました。この事件は、SCIMトークンの適切な管理とスコープの最小化の重要性を浮き彫りにしました。

📋 HR連携の誤設定による大規模アクセス障害(2023年)

ある金融機関において、HRシステムとIDaaSプラットフォーム間の属性マッピングの誤設定により、約3,000名の従業員のアカウントが一斉に無効化される大規模なアクセス障害が発生しました。HRシステムの組織改編データが誤って「退職」ステータスとして同期され、自動デプロビジョニングが実行されました。

業務時間中に発生したため、対象の従業員はメール、業務アプリケーション、VPNを含むすべてのシステムにアクセスできなくなり、約半日にわたって業務が停止しました。この事故は、プロビジョニング設定の変更時における十分なテストと段階的なロールアウトの必要性を示しています。

🔗

Related Terms