ID管理の導入条件に不安が生じる背景
導入条件の判断が難しくなるのは、製品ごとに公開している情報の粒度が異なるためです。ここでは、比較検討の段階で情報が集まりにくくなる理由を2つの側面から整理します。
公開情報だけでは判断できない項目
ID管理システムの製品サイトには、対応機能の一覧や連携可能なサービス名が掲載されています。ただし、その連携でどの項目まで同期できるのか、更新の間隔はどのくらいかといった詳細までは記載されていない場合があります。自社の要件が細かいほど、公開情報との差が判断の妨げになります。
この場合は、資料請求や問い合わせの段階で、確認したい項目を箇条書きにして渡す方法が有効です。「連携できるか」ではなく「どの項目を、どの頻度で、どの方向に同期できるか」という形で聞くと、回答が具体的になります。回答は記録に残し、複数製品を同じ基準で並べて比べられるようにしておきましょう。
自社要件と製品仕様の照合の難しさ
自社の要件が社内の慣習にもとづいて決まっている場合、製品側の用語と一致せず、対応可否の判断がつかないことがあります。例えば、社内で使っている役職区分や兼務の扱いが、製品の権限モデルにそのまま当てはまらないケースです。
照合を進めるには、まず自社の要件を業務の流れとして書き出し、製品側の機能名に置き換えずに伝えるとよいでしょう。ベンダー側で該当する機能を提示してもらえば、認識の食い違いを減らせます。実現方法が複数ある場合は、それぞれの運用負荷もあわせて聞いておくと、導入後の判断に役立ちます。
海外SaaSとの連携でID管理に求められる条件
海外のクラウドサービスとの連携は、製品の開発元がどこかという点だけでは判断できません。対応状況は製品ごとの開発方針や体制によって異なるため、確認できる項目に置き換えて比べる必要があります。
対応サービス一覧の更新頻度を確認する
連携できるサービスの一覧が公開されている場合でも、その一覧がいつ時点のものかを確認しておきましょう。掲載から時間が経っていると、現在の対応状況と差がある可能性があります。国内の開発元だから海外サービスへの対応が遅いとは限らず、製品ごとの開発体制や優先順位によって状況は分かれます。
確認の方法としては、直近1年でどのサービスへの対応が追加されたかを聞く、対応一覧の更新履歴が公開されているかを見るといった手段があります。自社で使う予定のサービス名を具体的に挙げて、対応の有無と時期を確認しておくと、導入後のずれを抑えられます。
新しいサービスへの対応方針を聞く
将来的に新しいクラウドサービスを導入する予定がある場合、その時点で連携できるかどうかも判断材料です。一覧に載っていないサービスへの対応を依頼できるのか、追加費用が発生するのか、どのくらいの期間がかかるのかは製品によって異なります。
標準の一覧にない場合でも、SAMLやSCIMといった業界標準の仕組みに対応していれば、連携できる場合があります。SAMLはログイン情報を安全に受け渡す規格、SCIMはアカウント情報を自動でやり取りする規格です。これらへの対応状況を確認しておくと、選択肢の幅を把握できます。
連携方式の違いを理解する
ひとくちに連携といっても、ログイン時の認証だけを引き受ける方式と、アカウント情報そのものを作成・更新する方式では、実現できることが異なります。前者だけの対応では、アカウントの作成や削除は各サービス側での作業が残ります。
自社が求めているのがログインの一本化なのか、アカウント発行の自動化なのかを整理したうえで、製品ごとの対応方式を確かめてください。同じサービス名が対応一覧に載っていても、対応している方式が異なる場合があります。方式の違いは資料に明記されていないこともあるため、問い合わせで確認するとよいでしょう。
ITトレンドでは、最新の製品・サービスを多数比較・掲載しています。まず資料を取り寄せて機能や特徴をさまざまな製品で比較してみてください。忙しい業務時間内でも、各社に問い合わせる手間なく、たった1回の入力（約60秒）でID管理の一括資料請求が可能です。浮いた時間で、じっくりと製品を比較検討し進めましょう。
セキュリティ認証の記載の読み取り方
ID管理システムの資料には、取得している認証の名称が記載されていることがあります。名称だけで安全性を判断するのではなく、何を対象とした認証なのかを確認する必要があります。
ISMS認証が示す範囲の確認
ISMSとは、情報セキュリティを組織として管理する仕組みのことで、その運用状況について第三者機関の審査を受ける制度があります。認証を取得しているという記載は、審査の対象となった範囲で管理の仕組みが整えられていることを示します。個別の製品機能の安全性を保証するものではない点に留意しましょう。
資料に認証名が記載されている場合は、認証登録番号や登録証を確認すると、対象組織と適用範囲を照らしあわせられます。認証機関の登録簿で公開されていることもあります。自社が求めるのが組織的な管理体制なのか、製品固有の機能なのかを整理してから確認すると、判断の軸が定まります。
認証の対象組織と適用範囲の読み取り
認証の適用範囲は、企業全体の場合もあれば、特定の事業所や事業部門に限られる場合もあります。開発拠点とサポート拠点が異なる企業では、どちらが範囲に含まれるかで意味あいが変わります。
確認したい場合は、登録証に記載された適用範囲の文言をそのまま見せてもらう方法があります。あわせて、データを保管するサーバの所在地や、再委託先の管理方法についても聞いておくとよいでしょう。自社の業種によっては、業界固有の基準への準拠状況が必要になることもあるため、社内の担当部署にも要件を確認してください。
API連携が前提の環境で起こる制限
複数のクラウドサービスをAPIでつなぐ運用では、ID管理システム側の仕様が制約になることがあります。ここでは、事前に確認しておきたい3つの制限を取り上げます。
APIの呼び出し回数に上限が設けられている
多くのサービスでは、一定時間内に実行できるAPIの呼び出し回数に上限が設けられています。上限に達すると、処理が一時的に受け付けられなくなり、同期の遅延や失敗が起こる場合があります。組織変更にともなう一括更新など、短時間に大量の処理を行う場面で影響が出やすくなります。
検討段階では、上限値と、上限に達した際の動作をベンダーへ確認しておきましょう。自動で再試行されるのか、エラーとして通知されるのかで、運用の手当てが変わります。プランによって上限が異なる製品もあるため、自社の利用者数と処理の頻度を伝えたうえで相談することをおすすめします。
連携できる項目の範囲が限られる
APIで受け渡しできる項目は製品ごとに決まっており、自社で使っている独自の属性が含まれない場合があります。例えば、社内独自のコード体系や、複数部署の兼務情報が対象外になるケースです。項目が渡せないと、その情報を使った権限の判定も行えません。
対応としては、自社で必須とする項目を一覧にして、対応可否を確認する方法があります。カスタム属性を追加できる製品もありますが、追加した項目が連携時にどう扱われるかは別途確認が必要です。項目が渡せない場合の代替手段についても、あわせて聞いておくとよいでしょう。
エラー発生時の再実行の可否が分かれる
連携処理が失敗した場合の扱いは製品によって異なります。失敗した分だけを後から再実行できるものもあれば、全件をやり直す必要があるものもあります。件数が多い環境では、この違いが運用の負荷に影響します。
確認しておきたいのは、エラーが発生したときに管理者へ通知が届くか、どのデータが失敗したか一覧で確認できるか、手動での再実行ができるかという点です。連携の不具合は、ID管理システム側と連携先サービス側のどちらにも要因があり得るため、切り分けに使えるログが残る仕様かどうかも見ておきましょう。
独自の権限設計とアップデートの兼ねあい
自社独自の権限設計を実現するために設定を作り込むと、製品の更新時に影響が出ることがあります。ここでは、更新のたびに設定を見直す負担を抑える考え方をまとめます。
標準機能の範囲で権限を設計する考え方
製品の標準機能から外れた作り込みを行うほど、更新時に動作を確かめる範囲が広がります。まずは、標準で用意されている権限の組み合わせで自社の要件をどこまで満たせるかを検討し、どうしても必要な部分だけを個別対応にとどめる進め方が現実的です。
設計の際は、現在の組織構造をそのまま反映するのではなく、将来の組織変更にも耐えられる粒度を意識するとよいでしょう。部署名を直接指定するのではなく、役割の区分で定義しておけば、組織変更のたびに設定を作り直す手間を抑えられます。設計の意図は文書に残しておきましょう。
更新時の影響確認とベンダーへの確認事項
クラウド型の製品では、提供側の判断で機能の更新が行われます。更新の予告がどのくらい前に通知されるか、変更内容の一覧が公開されるか、検証環境で事前に確認できるかは、運用の負荷に関わる項目です。
個別対応を行っている場合は、更新後に確認する項目をチェックリストとして用意しておくと、影響の把握が早くなります。設定が想定どおりに動かなくなった際の相談先と対応範囲も、契約前に確認しておきたい内容です。自社での対応が難しい場合は、運用支援サービスの利用も選択肢です。
導入条件を確かめたいID管理システム
連携できるサービスの範囲や、国内での提供体制は条件として確認しておきたい部分です。提供の形が異なる製品を並べました。
Okta Workforce Identity
- フィッシングに強い認証フローでログインをより簡単・安全にする
- ADやLDAP等と統合。全てのIDを単一コントロールプレーンから管理
- ユーザーのアクセスを1か所で管理しアクティビティを適切に把握
Okta Japan株式会社が提供する「Okta Workforce Identity」は、従業員が業務で使うサービスへのアクセスを管理するID管理のサービスです。シングルサインオンや多要素認証に対応し、利用者ごとのアクセス権限を管理画面から扱えます。多くのクラウドサービスとの接続を想定した作りのため、社外の製品を幅広く使う環境で検討されます。自社の利用サービスを伝えて対応状況を確認しましょう。
IIJ IDガバナンス管理サービス
- 散在するIDやアカウント情報を一元管理
- 簡単設定のプロビジョニングで業務負荷を解消
- 不正なID・権限設定が一目で分かる
株式会社インターネットイニシアティブが提供する「IIJ IDガバナンス管理サービス」は、社内で使われているアカウントと権限の状況を把握し、見直しを進めるためのサービスです。誰にどの権限が付与されているかを整理でき、定期的な棚卸しの運用を支えます。国内の事業者が提供しており、契約やサポートの条件を日本語で確認できる点も検討の材料になります。
Gluegent Gate（グルージェント ゲート）
- 連携サービスとのシングルサインオン設定で利便性を向上
- 連携サービスのIDを一元管理することで管理者の負荷を軽減
- 多要素認証、アクセス制限をサービスごとに自由に組み合わせ可能
サイオステクノロジー株式会社が提供する「Gluegent Gate（グルージェント ゲート）」は、シングルサインオンとID管理を行うクラウドサービスです。接続元や利用者の条件に応じたアクセスの制御に対応し、認証の強さを状況にあわせて変える設定を検討できます。国内の事業者による提供のため、要件の相談を日本語で進められます。
Keycloak （レッドハット株式会社）
- シングルサインオンで複数のサービスを統合認証
- OIDCやSAML等の標準規格に対応
- 多要素認証や外部ID連携による柔軟な認証管理
ID管理の導入条件に関するFAQ
ID管理システムの導入条件についてよくある質問と回答をまとめました。
- Q1： 海外のクラウドサービスとの連携は国内製品では難しいですか？
- 開発元の所在地だけで判断はできません。対応状況は製品ごとの開発体制や方針によって分かれます。使う予定のサービス名を挙げて、対応の有無と連携方式を個別に確認することをおすすめします。
- Q2： 認証を取得している製品なら安全といえますか？
- 認証は審査の対象となった範囲で管理の仕組みが整えられていることを示すもので、製品機能の安全性を保証するものではありません。適用範囲やデータの保管場所とあわせて確認してください。
- Q3： APIの上限に達した場合はどうなりますか？
- 製品によって動作が異なり、自動で再試行されるものと、エラーとして処理が止まるものがあります。上限値と超過時の動作、通知の有無をベンダーへ確認しておきましょう。
- Q4： 独自の権限設計はどこまで実現できますか？
- 標準機能の範囲で対応できる部分と、個別の設定が必要な部分に分かれます。個別対応が増えるほど更新時の確認が必要になるため、要件の優先順位を整理したうえで相談してください。
まとめ
ID管理システムの導入条件に不安がある場合は、抽象的な対応可否ではなく、確認できる項目に置き換えて聞くと判断材料が得られます。連携対応の更新頻度や方式、認証の適用範囲、APIの上限と再実行の可否、更新時の通知方法は、いずれもベンダーへ確認できる内容です。整理した項目をもとに複数製品を比べたい方は、資料請求を活用してください。
