IDaaSを導入すると、認証基盤そのものの運用をサービス提供元へ任せられます。ただし、誰に利用を認め、異動や退職でどの権限を外すかは、導入企業が設計する必要があります。導入判断では、機能一覧と併せて「作業する人・承認する人・完了を確かめる人」を決めましょう。
この記事は、従業員が使う業務システムの認証を対象に、責任分担を整理します。製品の仕様例にはMicrosoft Entra IDの公式文書を使い、委託範囲や確認手順は編集上の提案として示します。
IDaaSは認証基盤をサービスとして利用する仕組み
IDaaSはIdentity as a Serviceの略で、専門の提供元がホスト・管理するID基盤です。Microsoftの設計ガイドでは、認証情報の保管や認証基盤の信頼性を自社だけで維持する負担を、IDaaSによって外部へ移せると説明しています。MicrosoftのIDaaS設計ガイド
一方、Microsoftの責任共有モデルでは、SaaSでも利用者のID、設定、アクセス管理は顧客側の責任に含まれます。これは運用上の整理であり、個別契約の責任範囲を置き換えるものではありません。クラウドの責任共有モデル
社内の検討では、次の三つを別々の確認項目にすると整理しやすくなります。
- 認証：利用者本人かを確かめる仕組みと、その設定。
- 権限：どの業務やデータにアクセスできるかの承認。
- アカウントの管理：入社・異動・退職に伴う登録、変更、停止。
たとえば「ログインできた」だけでは、異動前の権限が外れたかまでは確認できません。受入確認では、ログインの成否と、許可された操作の範囲を分けて記録することを提案します。
提供元・導入企業・運用委託先の責任分担表
次の表は、契約前に埋めるための運用設計案です。各製品の保証範囲や、特定の委託先が提供するサービスを示すものではありません。社内の承認者欄は、部署名だけでなく担当する役職まで具体化してください。
| 項目 | IDaaS提供元に確認する範囲 | 導入企業が決めること | 委託する場合の作業と完了証跡 |
|---|---|---|---|
| 認証サービスの稼働 | 稼働保証の対象、障害通知、問い合わせ窓口 | 業務への影響を判断する責任者 | 障害情報の確認、影響報告、対応記録 |
| 多要素認証・アクセス設定 | 対応機能、利用条件、設定方法 | 適用対象、例外の承認者、有効期限 | 設定変更、対象者と例外のテスト結果 |
| 入社・異動 | 連携方法、同期対象、エラーの確認方法 | 人事情報の正本、付与する権限、発効日 | 登録・変更、連携先での権限照合 |
| 退職・契約終了 | 無効化・削除の動作、連携の制約 | 停止時刻、対象アプリ、作業完了の判断者 | ID停止、アプリ側の停止、既存セッション確認 |
| ログ確認 | 取得できるログ、保存期間、外部出力の条件 | 監視対象、確認頻度、通知先 | ログ取得、異常の報告、対応履歴 |
| 緊急管理アクセス | 利用できる復旧手段と制約 | 利用権限、保管、使用後の確認者 | 手順の整備、利用テスト、使用記録 |
委託仕様には「アカウント管理一式」だけでなく、「人事の承認後、どのシステムを変更し、何をもって完了とするか」を書きます。これにより、社内の判断待ちと委託先の作業待ちを区別して管理できます。
退職者対応はID停止とアプリ側の確認を分ける
SSOとアカウント連携を別々に確認する
SSOの接続確認に加え、業務アプリのアカウントを作成・変更・停止する連携も確認しましょう。Microsoft Entraの自動プロビジョニングは、SCIMなどを通じて連携先のユーザーを管理する機能です。対象ユーザーの範囲や属性の対応付けも設定対象です。Entraのプロビジョニングの仕組み
導入前の台帳には、アプリごとに「ログイン連携」「アカウント連携」「手動作業の担当者」を別欄で持つことを提案します。特に、停止操作が無効化になるのか削除になるのか、どの属性を同一人物の判定に使うのかは、候補製品とアプリの組み合わせで確認してください。
既存セッションが終わる条件まで確かめる
Microsoft Entraのアクセス失効に関する文書では、利用者が実際にアクセスできなくなる時点は、アプリのトークンやセッションの扱いによって変わると説明しています。自動連携に対応しないアプリには、手動で利用を停止する手順も必要です。緊急時のアクセス失効
退職時の受入テストは、次の順で実施する案が考えられます。
- テスト用利用者で対象アプリへログインしておく。
- 決めた手順でIDを停止し、連携の結果を確認する。
- 新規ログインと、既に開いているアプリの操作をそれぞれ確認する。
- アプリ独自のログイン経路があれば、そこからも利用できないか確かめる。
- 残る作業、停止に要した時間、手動対応の担当者を記録する。
この手順は本番利用者の停止を試すためのものではありません。テスト用のアカウントと対象範囲を用意し、自社が求める停止条件を満たすか評価します。
障害時は管理者の復旧と業務継続を分けて設計する
MicrosoftはEntra IDの緊急アクセス用アカウントについて、通常の管理アカウントとは異なる強固な認証手段、認証情報の保護、使用時の監視、定期的な検証を案内しています。緊急アクセス用管理アカウントの管理
この仕組みを検討するときは、管理者が締め出された場合の復旧と、サービス自体が使えない場合の業務継続を分けましょう。緊急管理用のアカウントを用意しただけで、すべての障害時に業務アプリを使えると想定することは避けます。
運用設計案として、障害時の連絡先、影響を確認するアプリ、業務を待機させる判断者を決めておきます。また、手順書と連絡先を確認するために必要な認証が、障害の影響を受けないかも点検してください。
導入可否は小さな試行で判断する
候補製品を絞ったら、対象アプリを限定して次の順に確認することを提案します。
| 段階 | 確認すること | 次へ進む条件の例 |
|---|---|---|
| 棚卸し | 対象者、アプリ、管理者、現在の登録・停止方法 | 台帳の各項目に担当者がいる |
| 分担合意 | 社内の承認、提供元への問い合わせ、委託先の作業 | 境界の作業に未担当がない |
| 試行 | 入社、異動、退職、管理者が入れない場合の対応 | 期待結果と実測結果を照合できる |
| 運用移行 | 例外の期限、ログ確認、変更時の承認 | 定常作業の手順と確認者が決まっている |
製品比較では、ログ保存期間、必要機能の契約条件、既存アプリとの連携範囲を個別に確認します。機能名が一致していても、必要な運用をその契約で実施できるかは別の確認項目です。
IDaaS導入の判断材料は、認証機能の充足に加えて、退職者のアクセス停止と障害時の対応を説明できることです。委託を検討する際も、この分担表を基に作業範囲を具体化してください。当社の事業内容はインフラ支援の案内で確認できます。