連載「ID管理だけでは足りない？ “IGA”でガバナンスを確立」では、ID管理にガバナンスという観点を加えた「IGA：Identity Governance and Administration」をキーワードに、これからの時代に必要なID管理を考えていきます。第3回となる本稿では、認証・認可の基盤とID管理基盤の関係性に注目。それぞれにどのような役割を分担し、どのような構成で運用するのが適切なのでしょうか。
認証基盤とID管理基盤の違いとは？
IDガバナンスに焦点を当てた本連載。第1回は認証基盤の見直しにおけるID管理の課題としてシステム移行を中心に、第2回はガバナンス不全に陥りがちな運用課題をテーマにお届けしてきました。第3回となる本稿ではアーキテクチャ寄りのテーマとして、認証・認可基盤とID管理基盤の関係性について掘り下げていきたいと思います。
認証基盤とID管理基盤を簡単な言葉で表現すると、「IDを使う」ものと「IDを作る」ものといった関係性にあるといえます。たとえるなら「ドアを開けるためにカギを使う」ことと「新しい住人に新しいカギを用意する」ことといったように表現できるでしょうか。
こうして考えると明らかなように、この2つはまったくの別物ですが、デジタルな仕組みの上では認証基盤とID管理基盤が一元化できていると便利なケースも多いです。しかし一方で、気が付くと複雑性が増して、後々解けないパズルのようになってしまうこともあるので注意が必要です。
同じ属性で括れるIDは1ヵ所で管理できていることが望ましく、同じ組織の中で利用されるIDは一つのレポジトリ（データベース）に集約されているのが理想です。「ここを見れば社員全員分のIDがわかる」といったような一覧があれば、IDの作成・変更・利用の一時停止などの管理運用が容易になり、問題発生時の調査もすぐに行えます。とはいえ、これはあくまで理想の運用。現実は多様なシステムがあるばかりか、認証の仕組みも一つでは済まないケースが多いため、そう単純にはいきません。
図1：色々なパターンのネットワーク（NW）
[画像クリックで拡大]
認証基盤は柔軟性が大切も、ポリシーは適切に守るべし
アプリケーションを利用したいという要求やネットワーク上の利用者の配置、場合によってはシステム構成上の理由などで認証の入り口が複数にわたることが増えています。大きな組織であれば、大多数がインターネット上の認証の入り口と内部ネットワークでの認証の入り口をそれぞれ持っているのではないでしょうか。
認証は複数使われることが多いだけでなく、変更・更新のサイクルがID管理と比較して短い傾向があります。もちろん、ID管理も何らかの修正が必要になることはあるものの、「あるシステムを使うために新しいIDaaSサービスを使わなければいけない」「多要素認証導入のために認証の方式を変える必要がある」といったように、変更や更新をかけるきっかけが多くなる傾向にあるのが認証基盤の特徴です。
こうした点を踏まえると、IGAとIAM（Identity and Access Management）はシステムを分けて疎結合にしておくことが望ましいといえます。認証は機動的に変更できるようにしておくことが大切で、IGAは独立したシステムとしておいた方が良いです。これは、IGAがセキュリティルールをID管理基盤に落とし込むためのもので、組織が合併したり、統廃合したりしない限り大きな変更は必要ない一方、認証は組織に合わせたカスタマイズを行うことが多いため、入れ替えを容易にできる方が使いやすいからです。
ただ、認証の入れ替えが容易であったとしても、セキュリティポリシーは適切に守られる必要があります。環境の変化にシステムは追随する必要がありますが、その柔軟さに引きずられてセキュリティポリシーの管理が甘くなってはいけないわけです。そのため、組織のガバナンスを集約して管理するためにIGAは一元化し、認証基盤や特権ID管理基盤は企業のセキュリティポリシーに則ったルールを設定できるような仕組みになっていることが重要なのです。
“統合されたID管理”を実現するシステム構築のポイントとは
では、実際にシステムを構築するにあたってはどのような点に留意すべきなのか。図2を参考にしながら見ていきましょう。
[画像クリックで拡大]
ID管理が守るべきルールは組織によって異なりますが、たとえばISMS（情報セキュリティマネジメントシステム）を導入している、または内部統制に準拠した組織であれば、セキュリティポリシーに則ったルールが既に企業で定められているでしょう。IGAが実現すべき事項にはID改廃の規定、アクセス権限管理規定に則って管理できる「ライフサイクル」、その状況が確認できる「レポーティング」「証跡確認」が挙げられます。加えて、「ワークフロー」や「セルフサービス」による変更を自ら行ったり、承認依頼したり、実装に反映したりできる機能もID管理基盤には必要でしょう。
一方でIAM/IDaaSが担う認証と認可はシステムを分けることを想定し、プロビジョニングされた情報を元に認証するための機能をもっておく必要があります。ここでいう機能とは、「多要素認証」や「シングルサインオン」「認証連携」といったシステム利用可否を判断するもの。
ID管理の中で特に重要なのは、IDの生成、アクセス権限管理に関連することは一元化しておくべきだということです。一時的に作るIDや、組織外で生成されるIDを取り込むといったイレギュラー対応が現状の業務で発生していない場合でも、発生した場合にどうするかは事前に決めておいた方が良いですね。
[画像クリックで拡大]
また、ゼロトラストモデルの中には「IGAとIAMを分けて、ガバナンスの機能と認証の機能はそれぞれ別で管理すべき」と説明されているものがあります。門番にあたるIAMと、通行手形を発行する役所にあたるIGAは別であるべきだということを考えると、このモデルは理にかなっているのだと筆者も感じます。
特に最近は、IDaaSの機能が多様化してきており、一時的なIDを作ってくれる機能なども出てきました。しかし中には、外部の人に使わせても問題ないかきちんと確認すべき機能も見られます。「IDaaSには、簡単なIGAとしての機能を持たせるべき」という意見もありますが、目指すべきは「統合ID管理」なので、ガバナンスを効かせるためには中央集約型の一元管理を行う前提で設計することを筆者はお勧めします。
2つの役割分担モデルを正しく理解し、自社に合った選択を
認証・認可をIAM/IDaaSが担うこと、ID管理としてIGAがアクセス権限の改廃やIDの更新を担うことを説明してきました。次は「どこまでの機能をどの程度まで認証もしくはID管理基盤が引き受け、連携先の業務システムとの役割を決めるか」について考えていく必要があります。
図4は単純化したモデルになりますが、業務システム側では、認証基盤（IAM/IDaaS）で認証されたIDと、IGAから取得したIDと属性情報を照らし合わせ、追加認証を行います。認証基盤（IAM/IDaaS）はシステム利用可否までを認可しますが、業務システム内で有する権限については関知しないモデルを表しています。業務システムに権限階層や、属性に基づく判定をお任せする形です。
一方で、業務システムを含めアクセス権限管理のルールをすべて統一する場合、IAM/IDaaSの認可ルールにて承認されたアクセス権限を、認可情報として業務システム側に渡すという方式を採ります。このモデルの場合、連携先のシステムでは追加の認可機能を実装する必要はなくなりますが、アクセス権限の階層基準や実装の情報はシステムごとに異なっているため、統一された基準に寄せる対応もそれぞれのシステムで発生することになります。
[画像クリックで拡大]
先に示した単純なモデルの場合、システム側の対応が個別化してしまいますが、その分基盤としては複雑なルールを必要とせず、作りやすいという特徴があります。対して、認可時にアクセス権限まで決めてしまうやり方は中央集権的にシステムの中の権限階層を統一しやすいですが、各システム側はそれに合わせることが求められます。どちらも一長一短があり、各企業の状況に応じて適切なモデルを選択していくことが大切です。
また、アクセス権限の考え方については業務システムに決定権が委ねられるため、各業務システムの自由選択になってしまいがち。アクセス権限管理の目指す姿を実現するために、選択したモデルに寄せるルールに変更していく運用を原則とすることをお勧めします。
次回は、本連載のまとめとして「これからのIDガバナンスを考える」をテーマに、組織内におけるIDガバナンスの在り方とシステム化のポイントについてお伝えしたいと思います。
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.