認証基盤とID管理基盤の違いとは？
IDガバナンスに焦点を当てた本連載。第1回は認証基盤の見直しにおけるID管理の課題としてシステム移行を中心に、第2回はガバナンス不全に陥りがちな運用課題をテーマにお届けしてきました。第3回となる本稿ではアーキテクチャ寄りのテーマとして、認証・認可基盤とID管理基盤の関係性について掘り下げていきたいと思います。
認証基盤とID管理基盤を簡単な言葉で表現すると、「IDを使う」ものと「IDを作る」ものといった関係性にあるといえます。たとえるなら「ドアを開けるためにカギを使う」ことと「新しい住人に新しいカギを用意する」ことといったように表現できるでしょうか。
こうして考えると明らかなように、この2つはまったくの別物ですが、デジタルな仕組みの上では認証基盤とID管理基盤が一元化できていると便利なケースも多いです。しかし一方で、気が付くと複雑性が増して、後々解けないパズルのようになってしまうこともあるので注意が必要です。
同じ属性で括れるIDは1ヵ所で管理できていることが望ましく、同じ組織の中で利用されるIDは一つのレポジトリ（データベース）に集約されているのが理想です。「ここを見れば社員全員分のIDがわかる」といったような一覧があれば、IDの作成・変更・利用の一時停止などの管理運用が容易になり、問題発生時の調査もすぐに行えます。とはいえ、これはあくまで理想の運用。現実は多様なシステムがあるばかりか、認証の仕組みも一つでは済まないケースが多いため、そう単純にはいきません。
[画像クリックで拡大]
認証基盤は柔軟性が大切も、ポリシーは適切に守るべし
アプリケーションを利用したいという要求やネットワーク上の利用者の配置、場合によってはシステム構成上の理由などで認証の入り口が複数にわたることが増えています。大きな組織であれば、大多数がインターネット上の認証の入り口と内部ネットワークでの認証の入り口をそれぞれ持っているのではないでしょうか。
認証は複数使われることが多いだけでなく、変更・更新のサイクルがID管理と比較して短い傾向があります。もちろん、ID管理も何らかの修正が必要になることはあるものの、「あるシステムを使うために新しいIDaaSサービスを使わなければいけない」「多要素認証導入のために認証の方式を変える必要がある」といったように、変更や更新をかけるきっかけが多くなる傾向にあるのが認証基盤の特徴です。
こうした点を踏まえると、IGAとIAM（Identity and Access Management）はシステムを分けて疎結合にしておくことが望ましいといえます。認証は機動的に変更できるようにしておくことが大切で、IGAは独立したシステムとしておいた方が良いです。これは、IGAがセキュリティルールをID管理基盤に落とし込むためのもので、組織が合併したり、統廃合したりしない限り大きな変更は必要ない一方、認証は組織に合わせたカスタマイズを行うことが多いため、入れ替えを容易にできる方が使いやすいからです。
ただ、認証の入れ替えが容易であったとしても、セキュリティポリシーは適切に守られる必要があります。環境の変化にシステムは追随する必要がありますが、その柔軟さに引きずられてセキュリティポリシーの管理が甘くなってはいけないわけです。そのため、組織のガバナンスを集約して管理するためにIGAは一元化し、認証基盤や特権ID管理基盤は企業のセキュリティポリシーに則ったルールを設定できるような仕組みになっていることが重要なのです。
