LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

SCIMとは——IdPとSaaSをつなぐID自動プロビジョニングの標準

SCIM（System for Cross-domain Identity Management、クロスドメインID管理システム）とは、IdP（Identity Provider、ID提供基盤）と各SaaS間でユーザーIDやグループの情報をやり取りし、アカウントの作成・更新・無効化を自動化するための標準規格です。仕様はIETF（インターネット技術標準化団体）がRFC7643とRFC7644として公開しています^*1*2。

従来、SaaSを追加するたびに管理者が個別にアカウントを手作業で登録していました。SCIMに対応したIdPとSaaSをつなぐと、IdP側でユーザーを1回登録するだけで、連携先SaaSにアカウントが自動生成されます。属性の変更や退職時の無効化も、IdP側の操作が各SaaSへ伝わる仕組みです。

手動運用が抱える課題——登録漏れ・削除漏れ・属人化

SaaSの利用数が増えると、手作業のアカウント管理には限界が生じます。入社時の登録漏れは業務開始の遅延につながり、退職時の削除漏れは退職者アカウントの放置というセキュリティ上の弱点になります。

作業手順が特定の担当者に依存すると、対応の遅れやミスも起きやすくなります。SCIMは、これらの作業をIdPを起点に自動化し、人手による抜け漏れを減らす狙いを持つ規格です。

RFC7643とRFC7644——スキーマとプロトコルで見るSCIMの中身

SCIM 2.0は2つの仕様で構成されます。RFC7643がリソースの「型」を定めるコアスキーマ、RFC7644がその型をやり取りする通信手順を定めるプロトコルです^*1*2。両者は2015年にIETFから公開されています。

RFC7643（Core Schema）——UserとGroupのリソースと属性

RFC7643は、SCIMが扱う中心的なリソースとしてUser（利用者）とGroup（グループ）を定義しています^*1。Userリソースには、システム内部の識別子であるid、連携元のIdPが管理する識別子であるexternalId、ログイン名にあたるuserName、有効・無効を示すactive、emailsなどの属性が含まれます。

スキーマはurn:ietf:params:scim:schemas:core:2.0:UserのようなURI（識別子）で示されます。Groupリソースは、所属メンバーを表すmembers属性を持ちます。これらの属性名が標準化されているため、IdPとSaaSが同じ意味でデータを解釈できます。

RFC7644（Protocol）——エンドポイントとPATCH・filter操作

RFC7644は、リソースをやり取りするREST API（HTTPベースの通信規約）の手順を定めています^*2。主なエンドポイント（接続先パス）は/Users、/Groups、複数操作をまとめる/Bulk、対応スキーマを返す/Schemasなどです。

操作にはHTTPメソッドを用います。作成はPOST、全置換はPUT、削除はDELETE、取得はGETが対応します。属性の部分更新にはPATCHを使い、add（追加）・remove（削除）・replace（置換）の操作を指定できます。

対象ユーザーを絞り込むfilterもRFC7644で規定されています^*2。eq（等しい）・co（含む）・sw（前方一致）といった演算子で条件を書き、例えば特定のuserNameを持つユーザーだけを検索できます。この標準化により、IdPは相手のSaaSごとに個別の呼び出し方を作らずに済みます。

入退社ライフサイクル——作成・更新・無効化をactive属性で自動化

SCIMが実務で効果を発揮するのは、入社・異動・退職というアカウントのライフサイクル管理です。IdPを人事情報の起点とし、各局面の操作をSCIM経由で連携先SaaSへ反映させます。

入社時——POSTでアカウント作成、グループで権限付与

入社時は、IdPにユーザーを登録すると、連携先SaaSへPOSTでアカウントが作成されます。所属部署に対応するグループへ割り当てれば、Group連携によって必要なSaaSへの権限がまとめて付与されます。

手作業で複数SaaSに個別登録していた工程が、IdP側の1操作に集約されます。これにより、初日から必要なツールを使える状態を用意しやすくなります。

異動・属性変更時——PATCHで差分だけを更新

部署異動や氏名変更が発生した場合は、変更のあった属性だけをPATCHで更新します。全項目を送り直すPUTと違い、PATCHは差分のみを扱うため、連携の負荷を抑えられます。

グループの所属をreplaceで切り替えれば、旧部署の権限を外し新部署の権限を付与する処理も同時に進みます。権限の付け替え漏れを減らせる点が利点です。

退職時——active=falseによる無効化で放置アカウントを防ぐ

退職時に重要になるのがactive属性です。IdPで利用者を退職扱いにすると、SCIM経由で連携先SaaSのUserリソースがactive=falseに更新され、アカウントが無効化されます^*1。

退職者アカウントの削除漏れは、不正アクセスの入口になりかねません。この無効化を誤ると、契約が続くSaaSに使えるアカウントが残り続けるおそれがあります。SCIMによる無効化の自動化は、退職処理の抜け漏れというリスクを下げる仕組みです。IdP側の設定によっては、無効化ではなくアカウント削除を選ぶ運用もあります。

SSO（SAML/OIDC）・JITとの違い——認証とプロビジョニングの役割分担

SCIMはSSOやJITプロビジョニングと混同されやすい仕組みです。役割の違いを整理すると、SSO（SAML/OIDC）は「認証」、SCIMは「プロビジョニング（アカウントの供給と管理）」を担います。

SSO（SAML/OIDC）——ログイン時の本人確認を担う

SSO（Single Sign-On、シングルサインオン）は、SAMLやOIDC（OpenID Connect）といった規格を使い、利用者が各SaaSにログインする際の本人確認を担います。1度の認証で複数サービスを使えるようにする仕組みです。

ただしSSOだけでは、SaaS側にアカウント自体を作る・消すという管理はできません。SCIMは、そのアカウントのライフサイクルを受け持ちます。SSOとSCIMは競合せず、認証とプロビジョニングを分担する補完関係にあります。Oktaの解説でも、SCIMはユーザー情報の同期を担う標準として位置づけられています^*3。

JITプロビジョニング——初回ログイン時に都度作成する方式

JIT（Just-In-Time）プロビジョニングは、利用者が初めてSaaSにSSOでログインした瞬間に、その場でアカウントを作成する方式です。事前の一括登録が不要で、導入の手数を減らせます。

一方、JITはログインを起点とするため、ログインしないユーザーのアカウントは作られません。退職時の無効化や、ログイン前のグループ割り当ても不得手です。SCIMはログインの有無に関わらずIdP起点で作成・更新・無効化を反映できるため、ライフサイクル全体の管理に向きます。両者は排他ではなく、要件に応じて組み合わせる選択肢もあります。

SCIM対応SaaSと非対応SaaS——連携可否で変わる導入設計

SCIM導入の成否は、対象SaaSがSCIMに対応しているかどうかに大きく左右されます。連携の可否を最初に棚卸しすることが、設計の出発点です。

SCIM対応SaaS——IdPの設定でコネクタを有効化

SCIM対応のSaaSであれば、IdP側の設定でプロビジョニングを有効化し、SaaSが発行するSCIMエンドポイントのURLと認証トークンを登録します。Microsoft Entra IDはSCIM 2.0に基づくプロビジョニングをアプリ連携機能として提供しています^*4。

属性のマッピング（IdPの属性とSaaSの属性の対応づけ）を設定すれば、userNameやemails、グループ所属が同期されます。Google Cloudも、Workforce Identity Federation向けにSCIMによるユーザー・グループ同期の仕組みを提供しています^*5。

SCIM非対応SaaS——手動運用・CSV連携・API個別開発で補う

SCIMに対応していないSaaSでは、別の手段でライフサイクル管理を補う必要があります。手動運用を続ける、CSVの一括取り込みで定期同期する、提供されている独自APIに合わせて連携処理を個別開発する、といった選択肢があります。

個別開発は、SaaSごとにAPI仕様の調査・実装・保守が発生します。対象SaaSの数が多い環境では、この非対応SaaSへの対応が工数の大部分を占めることがあります。どこまで自動化し、どこを手動で残すかの線引きが設計の要点です。

内製と外注の判断軸——スキル・工数・運用体制で比較

SCIM連携の構築・運用を内製で進めるか外注するかは、必要なスキル・工数・運用体制の観点で判断します。標準規格とはいえ、実装には専門知識が求められます。

内製に必要なスキルと工数の目安

SCIM連携を内製で進めるには、次の知識を持つ人材が必要です。

• RFC7643/7644の仕様理解（スキーマ属性・PATCH操作・filter構文）
• IdP（Okta・Microsoft Entra ID・Google等）のプロビジョニング設定・属性マッピングの実務
• SCIM非対応SaaSに対応するためのREST API連携の設計・開発
• 人事システムとIdPを連携させる場合のデータ設計・突合ルールの整理
• 同期エラー時のログ調査・リカバリ手順の運用設計

属性マッピングの設計を誤ると、意図しない権限付与や退職者の無効化漏れが起きるおそれがあります。設定を誤ったまま多数のSaaSへ同期すると、影響が広範囲に及びかねません。IdPとSaaSの仕様差を検証しながら進める慎重さが求められます。

初期構築フェーズでは、対象SaaSの棚卸し・属性設計・連携テストに専任担当者の工数が集中します。運用フェーズでも、同期エラーの監視やSaaS追加への対応が継続的に発生する点を見込む必要があります。

SCIM自動化と手動運用の比較

SCIMによる自動化と従来の手動運用を、主な観点で対比します。

手動運用は初期の準備が軽い一方、SaaSと従業員が増えるほど作業量と抜け漏れのリスクが積み上がります。SCIMは初期に設計・検証の負荷がかかる代わりに、運用段階の作業を減らせる仕組みです。

委託先の選び方——IdP連携実績と元請体制の3チェック

SCIM連携の外注先を選ぶ際は、次の3軸で確認することが大切です。

チェック軸1：IdPとSaaSの連携実績と仕様への理解

SCIMは標準規格ですが、IdPやSaaSごとに属性マッピングの癖や対応範囲の差があります。Okta・Microsoft Entra ID・Googleなど利用中のIdPでの構築経験や、対象SaaSとの連携実績を持つ委託先を選ぶことが望ましいでしょう。

確認したい点は、過去のプロビジョニング導入実績・SCIM非対応SaaSへの個別連携の経験・人事システムとの突合の設計経験です。仕様の背景まで理解している委託先ほど、想定外の同期挙動に対処しやすくなります。

チェック軸2：元請（プライムベンダー）体制の有無

ID管理は、従業員の個人情報やアクセス権限に近い領域を扱います。委託先が実務を多重下請けに回す場合、責任の所在や情報管理の範囲が不明確になりかねません。

元請（プライムベンダー、契約上の一次請負）として直接対応できる体制かを確認することが大切です。契約時には、実際に作業する担当者の所属・インシデント時の窓口・再委託の有無と範囲を明示的に確かめます。

チェック軸3：導入後の運用・SaaS追加への継続対応

SCIM連携は導入して終わりではありません。新しいSaaSの追加、IdP側の仕様変更への追随、同期エラー時の調査など、継続的な運用が発生します。

初期構築だけでなく、運用フェーズの監視・エラー対応・SaaS追加支援まで対応できるかを確認します。SLA（Service Level Agreement、サービス品質の合意）として、障害時の初動対応時間や定期報告の内容を契約前に明確にしておくと、運用開始後の齟齬を防げます。

まとめ——SCIM自動化・役割分担・外注判断の3軸

本稿では、SCIMによるID・グループのプロビジョニング自動化を、仕様から外注判断まで整理しました。要点を3つに集約します。

第一に、SCIMはIdPと各SaaSをつなぎ、アカウントの作成・更新・無効化を自動化する標準規格です。RFC7643がUser/Groupのスキーマを、RFC7644が/Users・/GroupsエンドポイントやPATCH・filterの手順を定めています。入退社ライフサイクルでは、退職時のactive=false無効化が放置アカウントのリスクを下げます。

第二に、SCIMはSSO（SAML/OIDC）やJITと役割が異なります。SSOは認証、SCIMはプロビジョニングを担う補完関係です。JITはログイン起点のため、ライフサイクル全体の管理にはSCIMが向きます。

第三に、外注の判断は「仕様理解とIdP連携のスキル」「元請体制」「導入後の継続運用」の3軸で評価します。SCIM非対応SaaSへの対応や属性設計の誤りは影響が広がりやすく、実装と運用の両面で専門知識が問われます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IETF「RFC 7643 System for Cross-domain Identity Management: Core Schema」（2015年）
2. *2　出典：IETF「RFC 7644 System for Cross-domain Identity Management: Protocol」（2015年）
3. *3　出典：Okta「Understanding SCIM」
4. *4　出典：Microsoft「SCIM support for provisioning in Microsoft Entra ID」
5. *5　出典：Google Cloud「Workforce Identity Federation SCIM」

Tweet