アカウントは1つ。権限は多すぎませんか？

いいえ。集中管理されたログインはアイデンティティの管理を簡素化しますが、対象システムにおける権限の確認に代わるものではありません。

それはセッション管理の方式と、アプリケーション側の連携可能性によって異なります。この限界を検証し、残存する時間枠と対応策を文書化します。

従業員には自らの業務に見合った権限でサインインしてもらい、異動の際には不要な権限を残さないようにする必要があります。エンタープライズシステムを貴社のID管理と接続し、シングルサインオン（SSO）を構築し、アカウントとアクセス権のライフサイクルを自動化します。

システムごとのロールと職務分離を含む権限設計 ERP、CRM、イントラネット、ワークフロー向けのSAMLおよびOpenID Connectによるシングルサインオン FIDO2と条件付きアクセスによる多要素認証 HRシステムと連携したSCIMによるユーザー管理の自動化 権限の再認証と監査用のログ記録

職務分離を含む権限設計 SSOとMFAを備えた連携済みシステム 監査ログを伴う再認証プロセス

SSOが答えるのは、誰がサインインするのかという問いです。その人物がERPやCRMで何を行ってよいかは、それぞれの権限モデルで別途定める必要があります。ロール、特権的な操作、必要な職務分離を整理します。対応するアプリケーションはSAMLまたはOpenID Connectを通じて接続します。多要素認証の方式とアクセス条件は、保護要件に応じて設定します。既存のローカル緊急アカウントについては、文書化され、統制された取り扱いが必要です。

人事データの正となるシステムが、アカウント作成、ロール変更、退社に関するイベントを供給します。プロビジョニングにはSCIMまたは対応するコネクタを使用できますが、対象システムによって対応する機能は異なります。無効化、グループ変更、既存セッションへの対応をテストします。転送に失敗した場合は、差異を可視化する必要があります。定期的な見直しでは、グループメンバーシップが際限なく増えるのを放置せず、どの権限が引き続き必要かを確認します。

検収には、異なるロールによる正常系および異常系のアクセステストが含まれます。また、ID管理サービスの障害や、合意した緊急アクセスもテストします。文書には、業務上の承認と技術的な管理それぞれの責任者を明記します。アプリケーション一覧、既存のロール、典型的な入社・異動・退社のケースがあると役立ちます。

プロセス、システム構成、データ品質 業務部門、IT部門、データ保護担当、OTOKO®プロセスコンサルタント プロセスマップ、システム台帳、データ品質レポート、優先度付けされた取り組み領域

目標プロセス、アーキテクチャ、統合計画 業務部門、アーキテクチャ担当、情報セキュリティ担当 目標プロセス、システムアーキテクチャ、インターフェース台帳、権限設計

1つのプロセスまたは拠点で本稼働 OTOKO®コンサルタント、キーユーザー、貴社のIT部門 実データによるパイロット運用、キーユーザーからのフィードバック、展開に関する意思決定

設定、インターフェース、移行、トレーニング OTOKO®コンサルタントおよび開発者、キーユーザー、貴社のIT部門 設定済みシステム、インターフェース、移行済みデータ、トレーニング、検収

監視、リリース、サポート OTOKO®の運用チーム、または貴社のチーム 監視、リリース計画、サポート、年次の権限確認

目標プロセス、要件、キーユーザーとの調整

システムアーキテクチャ、インターフェース、データ責任