統合ID管理システムとは、人事情報などを元に、社内外の複数のシステムのIDと権限をまとめて作成、変更、削除する仕組みです。法律や規格で決まった定義はなく、製品によって範囲が違います。名前で判断せず、自社のどのシステムまでIDを配れるかで確かめます。
今日やることは、社内で使っているシステムを全部書き出し、「IDを誰が作っているか」「退職した時に誰が止めているか」の2列を付けることです。この表が、製品を選ぶ時の材料になります。
統合ID管理は何を解決する？
人の動きと、IDの動きのずれです。入社、異動、退職のたびに、担当者が各システムの画面で作業していると、消し忘れや権限の残りが起きます。
IPAの中小企業の情報セキュリティ対策ガイドライン第4.0版は、IDの発行から削除までを管理するプロセスを定め、必要最小限の割り当てにすることを求めています。異動や退職に伴う権限の変更や削除の漏れを防ぐよう、見直しのルールも求めています。統合ID管理システムは、この決まりを手作業から機械に移す道具です。
具体的な動きは、Microsoft Entra IDの人事主導のプロビジョニングの説明が分かりやすい例です。人事システムに新しい社員が登録されると、それをきっかけにアカウントを作ります。名前や役職が更新されれば反映し、退職すればアカウントを無効にします。
ここでいう「プロビジョニング」は、IDを各システムに自動で作って配ることです。統合ID管理の中心はこの部分で、ログインを楽にする機能とは別の話です。
IDaaSとの違いは？
見ている軸が違います。統合ID管理は「IDを配って管理する機能」に注目した呼び方で、IDaaSは「ID管理や認証をクラウドから提供する形」に注目した呼び方です。これは言葉の使われ方を私たちが整理したもので、公的な定義ではありません。
そのため、対立する2つの製品分類ではなく、重なる部分があります。
| 型 |
得意なこと |
残りやすいこと |
| SSOと認証が中心のIDaaS |
1回の認証で複数のサービスへ入る、多要素認証 |
各システムへのIDの作成 |
| SSOと人事連携を持つIDaaS |
ログインに加えて、人事情報からIDを作る |
連携先にない社内システム |
| ID管理に絞った製品 |
組織と権限の情報を各システムへ配る |
SSOは別の製品と組み合わせる |
| 社内に置く従来型の製品 |
社内のシステムへ細かく合わせる |
自社での運用と保守の手間 |
製品の案内でも確かめられます。Okta Lifecycle Managementは人事システムを情報源として、入社、異動、退職の処理を自動化すると説明しています。KeyspiderはクラウドのID管理サービスで、公式に「IDaaSを補完強化します」と案内し、対象システムへのユーザー登録がIDaaSの稼働の前提になると説明しています。
IDaaS自体の製品ごとの違いは、IDaaSの製品比較で、SSOの方式と人事連携の列を見ると分かります。
製造業ではどこが難しい？
クラウドのサービスより、社内のシステムと現場のIDが多いことです。たとえば、次のようなシステムを持つ部品メーカーの場合で考えます。
| システム |
連携で確かめること |
| Active Directory |
ファイルサーバーの権限とどう結び付けるか |
| Microsoft 365 |
Active Directoryと同期するか、クラウドだけか |
| 基幹システムと生産管理 |
独自のIDか、データベースやファイルで入れられるか |
| 図面管理 |
部門や協力会社ごとの権限をどう持たせるか |
| 検査装置や設備の端末 |
共有のIDがないか、個人のIDにできるか |
| 協力会社の接続 |
社員ではない人のIDを誰が管理するか |
上の表で手間がかかるのは、下の4行です。基幹システムは独自のID表を持っていることがあり、クラウド向けの標準の方式だけでは届かない場合があります。
共有のIDは、現場の事情で残りやすいものです。IPAのガイドラインは、共有IDはなるべく使わず、やむを得ず使う場合は使った人を特定できる仕組みを整えるよう求めています。統合ID管理を入れても、共有のIDの問題は残るので、別に手当てをします。
人事異動の時期にも注意します。4月1日付けの一斉異動があると、発令日に合わせて権限を切り替える必要があります。Keyspiderは、異動の情報を事前に登録して発令日に同期する機能を案内しています。こうした機能が要るかどうかは、異動の人数と頻度で変わります。
連携先でどう選ぶ？
機能の表を比べる前に、社内のシステムごとに「どの方式でIDを入れられるか」を調べます。製品を選ぶ順番は、次のようになります。
1. 連携の方式を調べる
システムの提供元に、次のどれが使えるかを聞きます。
- SCIM：IDの管理を標準化したHTTPベースのプロトコル
- LDAP：Active Directoryのようなディレクトリとのやり取り
- データベース：社内システムの利用者の表へ直接入れる
- REST、SOAP：システムのAPIを使う
- CSVなどのファイル：定期的に出して読み込む
- 何もない：人の手で入れるしかない
Microsoft Entra IDのアプリプロビジョニングの説明は、SCIM、LDAP、SQL、REST、SOAP、フラットファイルなどとコネクタの対応を表で示していて、確かめる時の項目の見本になります。製品の案内で「連携できる」と書かれていても、方式によって必要な準備が変わります。
2. IDの元をどこにするかを決める
人事システムを元にするのが基本の形です。ただし、中小企業の人事システムが、社員の異動や部門の情報を正しく持っているとは限りません。派遣社員や協力会社の人が入っていないこともあります。
元のデータの更新が遅ければ、自動化しても遅れたまま配られます。人事の入力の締め切りと、IDの反映の時刻を先に決めます。
3. ログインもまとめるかを決める
配る機能とログインの機能を同じ製品にするか、分けるかを決めます。Microsoft 365を使っているなら、すでに手元にある機能の確認が先です。Microsoft Entraの説明によると、Microsoft 365のサブスクライバーは、すでにMicrosoft Entra IDを使っています。ハイブリッドIDの説明は、社内とクラウドの両方で共通のIDを持つ仕組みを説明しています。
社内のシステムのSSOは、さらに条件を確かめます。Microsoftの計画の手引きでは、社内のアプリの選択肢はパスワードベース、統合Windows認証、ヘッダーベース、リンクで、アプリケーションプロキシの構成が前提です。古いシステムがどれに当てはまるかを調べます。
4. 管理者のIDは別に考える
社員のIDと、システムの管理者のIDは扱いが違います。管理者のIDは漏れた時の影響が大きいので、貸し出しや操作の記録まで必要なら、特権ID管理（PAM）の比較を別に見ます。
中小企業に統合ID管理は必要？
人数よりも、手作業で管理しているIDの数で判断します。システムが3つか4つで、異動も少ない会社なら、台帳とIDaaSで足りる場合があります。
決まった基準はありません。次は私たちが考える条件で、重なるなら検討する理由があります。
- 退職や異動のたびに、5つ以上のシステムで作業している
- 社内のシステムと、クラウドのサービスが混ざっている
- 監査や取引先の調査票で、権限の棚卸しの記録を求められている
- 異動が一斉にあり、発令日に合わせた切り替えが負担になっている
導入の前に、今あるIDの棚卸しをします。使っていないIDや、退職者のIDが残っていると、そのまま仕組みに載せることになります。PCやソフトの一覧がないなら、IT資産管理ツールの比較で台帳の作り方から確かめます。
失敗しやすいのは、全システムをつなごうとして止まることです。退職の処理が漏れると困るシステムから順に、2つか3つで始めます。手作業が残るシステムは、表に残して担当者を決めます。
IDを止めても、持ち出された情報は戻りません。退職時の決まりと誓約書は社員への損害賠償の考え方で触れています。情報漏えい対策の全体は情報漏えいのカテゴリから確かめられます。
