2022年度内にアイデンティティ・ガバナンスの検討に着手すべき一方、アイデンティティ管理のプロジェクトはつい後回しにしてしまう領域でもある。そこで、「ざんねんな」アイデンティティ管理として、企業・組織内に存在し、DXやゼロトラストへの妨げとなっているアイデンティティ管理システムと、それらが生まれた背景を解説する。なお「ざんねんな」としたのは、『ざんねんないきもの事典』（高橋書店、2016年）の動物たちのように、良かれと思って一生懸命頑張った結果生まれてしまったアイデンティティ管理システムと、IT担当者の方への尊敬・敬意の表明である。「ざんねんな」アイデンティティ管理も覚えやすく話しやすいように動物の名前を使って表現しているので、ぜひ顧客や同僚と話をして顧客先や自社のアイデンティティ管理の状況を改めて考えてみてほしい。

「ざんねんな」アイデンティティ管理　オンプレリス（オンプレミス）

　はじめに紹介するのがオンプレリス（オンプレミス）のアイデンティティ管理システムだ。いまから約10年前、クラウド化が進む前はオンプレミスでのアイデンティティ管理が一般的だった。これには三つの特徴がある。

　一つめは自社やデータセンターのオンプレミス環境に設置し、自社運用していたということだ。当時はクラウドシステムを利用することはほとんどなく、アイデンティティ管理システムの連携元となる人事システムや連携先となる自社開発アプリ、パッケージソフトウェアもオンプレミス環境に構築・運用されていたので、アイデンティティ管理システムもオンプレミス環境に設置し運用することは理にかなっていた。

　二つめは自社開発、パッケージソフトウェアによるガラパゴス仕様だ。連携元や連携先も自社仕様で構築したシステムだったため、自社の要件に応じて仕様や機能を自由に決定できた。独自仕様ではあるが、自社独自のアイデンティティ管理の業務フローやデータモデルに合わせてシステムを構築できる利点が大きかった。

　三つめは、上流工程から下流工程へと順番に開発が進められていく開発手法で基本的に前工程に戻らない前提の「ウォーターフォール開発」一括発注による開発である。自社仕様を社内調整の上決定し、開発後の仕様変更はできなかった。実際、開発当時は仕様変更不可による不利益もあまりなかった。
 
　しかし、クラウド化が進んだ現在のIT環境を考えるとオンプレリス（オンプレミス）のアイデンティティ管理システムは時代遅れで、「ざんねんな」状態になっている。なぜなら、まずオンプレミスで構築されているゆえに、常に最新、迅速、運用コストが低いというクラウドのメリットを享受できない。

　また、アイデンティティ管理システムとして致命的なのは、SaaSをはじめとするクラウドサービスとの連携が難しいことだ。クラウドサービスは自社ガラパゴス仕様に合わせてくれない。かつオンプレシステム間であれば容易であった双方向でのやり取りは、ネットワーク的に分離されているクラウドサービスとオンプレ環境にあるアイデンティティ管理システムとでは困難である。オンプレミスのアイデンティティ管理では多用されているファイルによる連携はクラウドサービスとの間ではできないのである。

　そこで、連携するクラウドサービスごとに連携プログラムを追加開発する必要がある。しかし、新たなクラウドサービスの利用開始や、クラウドサービス側の仕様変更のたびに追加開発を行うのでは非効率である。さらに、細かい機能追加はウォーターフォール型一括発注では迅速な対応ができず、結果として実際のビジネスとアイデンティティ管理システムの乖離が進んでしまう。
 

「ざんねんな」アイデンティティ管理　サイ（ロ）型

　次に紹介するのはサイ（ロ）型のアイデンティティ管理システムである。ここでのポイントは三つの「バラバラ」だ。00年代、10年代と継続して進んでいる業務システムのIT化、企業の海外進出、M＆A、事業拡大などが背景にある。

　一つめのバラバラは「システムごとにバラバラ」である。一言で業務システムといってもそれぞれアイデンティティ管理の要件や管理運用主体が違う。各システムの個別要件は、各システム側が追加で開発し実装されるケースが多かった。これが小さく独立したアイデンティティ管理システム乱立のはじまりである。

　例えば、ERPにアインデンティティ情報を取り込むためにERP更改や改修のタイミングで独自の機能を作りこむ。製造業において部品表や製品設計システムのサブシステムとしてアイデンティティ情報の取込プログラムを作成し、同時に部品表でのアクセスコントロールの機能も実装するなどである。本来であれば、アイデンティティ管理システム側で設計・実装すべきであるが、余計な工数・コストをかけたくないアイデンティティ管理システム側と、個別要件や都合に合わせて独自に開発したい業務システム側の両者にメリットがあったので、業務システム側に存在する小さく独立したアイデンティティ管理機能が増えていった。

　二つめは「組織・子会社ごとにバラバラ」である。企業買収や合併、子会社の吸収が起こると今までは全く別々であった複数のシステムが一つの企業・組織に存在することになる。アイデンティティ管理システムは、会計システムなど買収や合併の目的に直接かかわるシステムに比べて統合する必要性が低く、各組織の独立性や業務の違いなどから、買収や合併前と同じように独自にシステムを開発・維持していくケースも多い。

　三つめは「地域・国ごとにバラバラ」である。以前はネットワークコストやネットワーク帯域の都合で地域や国ごとにバラバラにシステムを開発・運用をすることが多かった。設計開発はA国、製造はB国、販売は全世界でなど、事業においても国ごとに区切られていたので地域や国の間で連携する頻度や必要性も高くなかった。アイデンティティ管理も自然に地域・国ごとにバラバラで開発・運用していた。
 
　しかし、地域や国を超えた業務・事業連携が価値を生み出すグローバル化の進展やDX推進の取り組み、企業に対するガバナンス向上の要請が高まっている現在、バラバラでサイ（ロ）型のアイデンティティ管理はリスクが高く、かつ非効率になってしまっている。

　バラバラに分散管理されているため「誰がどのようなアクセス権を持っているのか」というシンプルな質問に答えることができない。そもそもシステムが統合されていないため「システム上に存在するユーザーは何人ですか？」という問いにもすぐに答えることができない。つまりは可視化・分析をする前提が整っていないのである。「見えないものは守れない」のでセキュリティ強化をするための施策も実施しづらい。

　また、監査・ガバナンスの観点でも大いに問題がある。企業・組織として営む事業の説明責任を各事業・各国に押し付けることはできない。業務で利用するシステムのアクセス権限がバラバラに管理されている状況では企業・組織全体として適切な監査・ガバナンスを行うことは不可能である。

　何より、各システム・組織・国でバラバラなサブシステムが独自に開発・運用されている状態は著しく非効率である。同じような機能が重複して開発されていることも多々あるだろう。利用されている機能が把握できていない状態は可視化・監査・ガバナンスの観点でも問題であるが、どの程度の無駄や重複があるのか把握できないと見えないコストが積みあがっている状態を見過ごすことになる。
 

「ざんねんな」アイデンティティ管理からの脱却

　「ざんねんな」アイデンティティ管理はどんな組織にも存在しうる。約10年前のIT環境を考えると必然ともいえる。問題なのは、「ざんねんな」アイデンティティ管理の存在ではなく、それを放置し、脱却をはからないことである。オンプレリス（オンプレミス）、サイ（ロ）型のアイデンティティ管理システムから脱却し、DXやゼロトラストを推進する「アイデンティティ・ガバナンス」の検討に着手する時は今である。