IGAプロジェクトを成功させる方法:ペルソナから始める

IGAプロジェクトが失敗すべき水準以上に頻繁に失敗する理由

アイデンティティ ガバナンスおよびアドミニストレーション(IGA)は、失敗率が低くて当然と思えるほど長く存在してきた分野です。コンセプトは十分に確立されており、主要なプラットフォームは成熟しており、導入経験を持つ人材にも事欠きません。それにもかかわらず、プロジェクトは依然として予定を超過したり、当初のスコープから外れたり、動作はするもののその組織にはしっくりこないソリューションを納品したりしています。

その理由は、たいてい見慣れた一連のテーマに集約されます。

経営層の合意はよく取り沙汰され、実際に重要です。上層部からの確固たるコミットメントがなければ、予算が厳しくなったり優先順位が変わったりしたときに、プロジェクトは縮小されやすくなります。

プログラムの目標も、よくある原因の一つです。技術が現実的に提供できる範囲に対して目標が野心的すぎたか、そもそも測定可能なほど精緻に設定されていなかったかのどちらかです。

計画をおろそかにしてステークホルダーに何かを早く見せることを優先すると、納期は後ろにずれます。文書化された要件ではなくベンダーのデモに引きずられて評価を行うと、技術選定を誤ります。機能豊富なプラットフォームに惹かれた末に、本当に必要だった機能こそが最もカスタマイズを要する機能だったと後になって気づくのはよくあることです。実装の途中で要件が変わったり、構成と統合にかかる労力を当初から過小評価していたりすると、コストが超過します。

これらはすべて実在する問題であり、すべてすでに詳しく論じられてきました。しかし、これらのいくつかの背後に静かに潜み、はるかに注目されていない失敗モードが一つあります。それは、プロジェクトが誰のために作られているのかを、そもそもきちんと定めていなかったということです。

苦戦しているIGAプロジェクトの大半は、問題の少なくとも一部を、初期段階で立てたユーザー・アイデンティティ・アクセスシナリオの種類に関する前提——結果的に誤りだったと判明する前提——にまで遡ることができます。

解決策は複雑ではありませんが、規律は必要です。それは、技術でもなく、連携でもなく、ワークフローでもなく、御社のアイデンティティのランドスケープ全体像を描くことからプロジェクトを始めるということです。ガバナンスプログラムがカバーすべき人とアイデンティティだけを描くのです。それ以外のすべては、そこから導かれます。

この記事の残りの部分では、そのランドスケープの全体像をどう構築するか、そしてそれを行うことがなぜほとんどの組織が想定するよりも大きな違いを生むのかを説明します。

つまり、皆さんはアイデンティティ ガバナンスを検討しています

IGAプロジェクトが苦戦する理由が技術そのものであることはめったにありません。根本原因は、ほぼ常に、人を理解する前に製品から始めてしまうことです。

IGAプラットフォームの評価を依頼されたのであれ、すでにプロジェクトの途中で状況が複雑になりつつあるのであれ、技術がたいてい難しい部分ではないことに、おそらくもう気づいているはずです。

IGAプラットフォーム(誰が何にアクセスできるかを制御し、オンボーディングとオフボーディングを自動化し、誰かがそのアクセス権を定期的にレビューすることを保証するソフトウェア)は成熟しており、よく理解されており、幅広い能力を備えています。主要なプラットフォームの大半は、コアとなるユースケースを大きな問題なく処理します。

では、なぜこれほど多くのIGAプロジェクトが予算を超過し、想定より時間がかかり、あるいはしっくりこないソリューションで終わってしまうのでしょうか。

私たちの経験では、それはほぼ常に同じ根本原因に行き着きます。組織が自らの人々を理解するのではなく、製品を選ぶことから始めたということです。

一社のベンダーでも評価する前にできる最も価値あることは、実際に組織内で誰が働いているのか、そして彼らとアイデンティティとの関係がどのようなものかを理解することです。

「社員が入り、社員が出る」ほど単純ではありません

表面的には、IGAは単純そうに聞こえます。誰かが会社に加わり、アカウントを得る。誰かが辞め、そのアカウントは無効化される。その間、誰かが定期的に、人々が今でも自分の持っているものを必要としているかを確認する。

ほとんどの組織における現実は、はるかに込み入っています。プロジェクトが進行し始めると浮上しがちな、いくつかの問いを考えてみてください。

契約社員や派遣スタッフはどうなるのか。彼らは御社のHRシステムに現れるのか。現れないなら、IGAプラットフォームは彼らの情報をどこから取得するのか。

特定のシステムへのアクセスを必要とするサードパーティのサプライヤーはどうか。彼らはどのようにオンボーディングされ、誰がそのライフサイクルを管理するのか。

複数の法人や地域にまたがって働き、それぞれで異なる役割を担う可能性のある社員はいるか。

人間のユーザーと並んでガバナンスが必要な、サービスアカウント、共有アカウント、マシン アイデンティティは存在するか。

より厳格な統制や異なる承認プロセスを必要とするかもしれない、役員、財務チーム、IT管理者といった機微な役割を担うユーザーはどうか。

規制当局や監査人が具体的に問うであろうアクセス権を持つペルソナはあるか、そしてそれによって権限のレビューや文書化の方法は変わるのか。

権限は永久に持続すべきか、それとも一部の権限、特に機微な権限は、期限付きであるべきか。

これらはどれもエッジケースではありません。数百人を超える規模の組織であれば、これらはむしろ標準です。そして選んだIGAプラットフォームがこうした問いに照らして評価されていなければ、たいていは方向転換にコストがかかる実装段階で、それを苦い形で思い知ることになります。

ペルソナの登場

アイデンティティ ガバナンスの用語で言えば、ペルソナとは、アイデンティティのライフサイクル、アクセス要件、またはデータソースが他と有意に異なる、独立したユーザータイプのことです。個々の人間ではなく、人間のタイプを指します。

ソフトウェア エンジニアリングから元々借用され、数十年にわたり構造化システム分析の一部であり続けてきた手法があり、この問題を解決するのにぴったり合っています。ユーザーペルソナ、アクター、アイデンティティ アーキタイプなど呼び方はさまざまですが、考え方はシンプルです。

システムが何をすべきかを定義する前に、まずそのシステムが対応すべきあらゆる種類の人(そして人でないもの)を定義するのです。

私たちの経験では、中規模の組織は通常、30から50の異なるアイデンティティ ペルソナを識別します。ヘルスケア、教育、小売業の組織では、この数は容易に倍増します。

これを具体的にイメージするためのいくつかの例です。

HRシステムを通じて入社する正社員で、標準的なオンボーディングの流れ、直属マネージャーの承認、そして定義済みの初期アクセス権(birthright access)一式を持つケース。

エージェンシー経由で調達される契約社員で、その記録がHRではなくスプレッドシートやサプライヤーポータルに存在し、同時に複数のクライアントで働く可能性があるケース。

有期のエンゲージメントを持つ学生またはインターンで、その配置期間の終了時にアクセス権がきれいに失効する必要があるケース。

昇格された監視、分離統制、そして常時の権限ではなく潜在的にジャストインタイム アクセスを必要とする、管理者アカウントを保持する特権ITユーザー。

アプリケーションのサービスアカウントやAPI連携のような、権限を持ちガバナンスが必要でありながら、セルフサービスのアクセス申請フォームには決して記入しない、非人間アイデンティティ。

これらのペルソナはそれぞれ、御社のIGAプラットフォームと異なる形で相互作用します。ソースシステムから自動的にオンボーディングされるものもあれば、手作業のプロセスや代替データソースが必要なものもあります。専門化された承認チェーンが必要なものもあれば、スケジュールに従ってアクセスを失効させる必要があるものもあります。

これがプラットフォーム選定にとってなぜ重要なのか

ペルソナ一覧が手元にあれば、要件はほとんど自然に書き上がります。

「このプラットフォームはjoiner/mover/leaverに対応していますか」(どれも「はい」と答えます)と尋ねるのをやめて、はるかに具体的な問いを立て始めます。

HRIS、スプレッドシート、LDAP、SCIMエンドポイントなど複数のソースからアイデンティティデータを取り込み、単一のアイデンティティ レコードに統合できるか。

HRレコードをまったく持たないアイデンティティを、別のオンボーディング ワークフローを使って処理できるか。

異なるユーザータイプに異なるガバナンス ポリシーを適用でき、契約社員には90日ごとのアクセス レビュー サイクルを、特権ユーザーには毎月のサイクルを適用できるか。

誰かの役割が変わったとき、人手を介さず、孤立した権限(orphaned entitlement)を生み出すことなく、差分を計算して適切なものをプロビジョニングまたはデプロビジョニングできるか。

個々のアクセス権が付与された時点では無害に見えたとしても、その組み合わせがリスクを示すようになった場合にそれをフラグできるか。監査人に対し、各ペルソナのアクセスがなぜ、誰によって承認されたかを、そのペルソナが持つリスクに見合ったレビュー頻度で示せるか。

よく設計されたIGAプラットフォームであれば、以上のすべてに対応できるはずです。ペルソナの演習は、これらの能力のうちどれが自組織にとって真に重要で、どれがあれば嬉しい程度のものかを教えてくれます。

また、ベンダーを評価する際に何を実演してもらうべきかも教えてくれます。一般的な製品ウォークスルーに座って耳を傾ける代わりに、ベンダーに一連のペルソナを渡し、それぞれを自社のプラットフォームがどう扱うかを具体的に示すよう求めることができます。

ペルソナの演習は、ベンダー評価を機能比較から真の能力テストへと変えます。一般的な能力ではなく特定のシナリオを求められたときには、ギャップを覆い隠すことははるかに難しくなります。

実践で見る良い姿

うまく構成されたIGA導入を見ると、ペルソナに基づく思考がアーキテクチャの中に見て取れます。異なるアイデンティティ タイプは異なるオンボーディング経路をたどります。アクセスは手動でキュレーションされたリストではなく、役割とコンテキストに基づいて割り当てられます。誰かの状況が変わったとき(昇進、異動、契約延長)、プラットフォームは自動的に対応します。

アクセス レビューは知的にスコープが絞られます。適切な人が、リスクレベルに見合った頻度で、適切な権限をレビューします。レビュー担当者が本来そこにあるべきでないものを見つけたとき、削除は自動的かつ監査可能な形で行われます。緊急にアクセスが必要な場合は、明確な証跡を残す申請・承認ワークフローが存在します。

機微なアクセスの組み合わせ(例えば発注書を作成し、かつそれを承認する能力)は、監査の際に発見されるのではなく、事前に能動的に特定されます。例外は静かに積み重なるのではなく、監督のもとで管理されます。

これらのいずれも、特に風変わりなプラットフォームを必要としません。必要とされるのは、プロジェクトの初期に誰かが時間をかけて、組織が実際にどのような種類の人とアイデンティティを持っているかを理解し、それを中心にソリューションを設計したということだけです。

その見返りは、アクセスがビジネスに触れるあらゆる場所に現れます。権限は手動介入を必要としないためより速く動き、静的なリストではなくコンテキストに紐づいているためより正確であり、証拠が事後に再構築されるのではなく作業の進行とともに記録されるため、コンプライアンスは慌ただしいものではなくなります。

実務上のメリット

IGAプロジェクトの成功可能性を高めることに加え、ペルソナの演習にはいくつかの有用な副次効果があります。

他のプロジェクトにも役立ちます。アイデンティティは組織内のほぼすべてに関わります。御社のペルソナ一覧は、特権アカウント管理(PAM)ソリューション、エンドポイント管理ツール、あるいはユーザーが誰で何をするかを知る必要のあるその他のあらゆるものを評価する際にも、同様に役立ちます。

ステークホルダーとの対話が容易になります。抽象的な技術要件を説明する代わりに「契約社員のペルソナ」や「特権管理者のペルソナ」を指し示せるようになると、対話はより具体的になります。ビジネス側のステークホルダーは、権限スキーマを常に理解できるとは限りませんが、ペルソナは理解できます。

プロジェクト ガバナンスのための自然な入力を生み出します。プロジェクトの責任分担を管理するためにRACI(Responsible、Accountable、Consulted、Informed)マトリクスを使用しているなら、ペルソナ一覧がその素材を提供します。それぞれのペルソナの背後には、ビジネスオーナー、技術的な管理責任者、そして相談・通知・直接関与のいずれかを必要とする一連のステークホルダーが存在します。

Netwrix Identity Managerのようなプラットフォームが果たす役割

これらすべては、プラットフォーム選定を先延ばしにする理由にはなりません。むしろ、御社のペルソナ一覧の働き方に逆らうのではなく、それに沿って機能するよう作られたプラットフォームを選ぶ理由になります。

Netwrix Identity Managerは、内部、外部、ゲスト、技術、IoT、そしてAIエージェントのアイデンティティを同一のモデルの下でガバナンスします。そのため、スプレッドシートから調達された契約社員も、HR部門の誰も存在を知らないサービスアカウントも、自らのアクセスをプロビジョニングするAIエージェントも、HRフィードを通じて入ってくる正社員も、すべてが4つの異なる応急処置ではなく、同じライフサイクル規律のもとで扱われます。サードパーティおよび非人間のアイデンティティは、契約や配置の終了後も居座り続けるのではなくスケジュールどおりに失効する期間限定アクセスを含め、独自のライフサイクル パスを持ちます。新しいシステムのオンボーディングにも、特注の統合プロジェクトは必要ありません。標準コネクタがAD、LDAP、SQL、CSV、SCIMをそのままカバーし、環境固有のより特殊な要件には高度なコネクタと汎用APIが利用できます。

ロール管理も同じように機能します。全員に一律のポリシーを適用する代わりにペルソナごとにロールおよびポリシーモデルを定義でき、ロールマイニングは機械学習を用いて実際のアクセスパターンを分析し、ロール構造を発見し、利用状況の変化に合わせてモデルを最新の状態に保ちます。そのため、モデルは構築された日の組織図を映すだけのものにとどまりません。

リスク面も同じ現実に合わせて構築されています。ポリシーエンジンが職務分掌の競合を検知・防止し、継続的な監視が孤立アカウントや外れ値を、監査で表面化する前に、後ではなく事前にフラグします。

これらのいずれも、ペルソナの演習に取って代わるものではありません。むしろそれこそが、設計から実装への迅速な移行を可能にするものです。各アイデンティティは、単一のパイプラインに無理やり通されて例外でつぎはぎされるのではなく、それぞれの条件のもとで定義され、ガバナンスされます。結果として得られるのは、より低いリスク、より速い実装、そしてより低いコストです。

まとめ

アイデンティティ ガバナンス プラットフォームは成熟しており、十分な能力を備えています。プロジェクトを苦戦させる原因は、通常、技術ではありません。プロジェクトを苦戦させるのは、製品から始めて、その後に組織の現実をそこへ無理やり当てはめようとすることです。

その代替案(まず自社のアイデンティティ ペルソナを特定し、それを使って要件を定義し、その要件に照らしてプラットフォームを評価する)は、説明を聞けば当たり前に聞こえます。しかし実際にはそれが行われることは驚くほど稀であり、それが埋めるギャップは大きなものです。

これには専門的なツールも深い技術知識も必要ありません。必要なのは時間と良い問い、そしてプロセスの早い段階からビジネス全体の適切な人々を巻き込む意志です。

ペルソナを正しく定めれば、プロジェクトの残りの部分ははるかに単純になります。ペルソナを誤るか、あるいは完全に省略すれば、購入時には十分理解していなかった問題に対して、後からソリューションを改修する羽目になるかもしれません。

アイデンティティ プログラムに問題を抱えていませんか。私たちは、御社がペルソナを理解し、Netwrix Identity Managerがどのようにプロジェクトを成功に導けるかを把握するお手伝いができます。デモをご請求ください。