【5分で分かる】信頼できる唯一の情報源とIDaaS
- Gluegent Gate
こんにちは、サイオステクノロジーGluegentサービスラインのジャレド・ウォレスです。
今日は情報システムデザインのコンセプトである「信頼できる唯一の情報源」（英：single source of truth、またはSSOT) とIDaaS（Identity as a Service）またはアイデンティティプロバイダーとの関係について話していきたいと思います。
「信頼できる唯一の情報源」とは
名前の通り、信頼できる唯一の情報源（以降 SSOT）というのは複数のシステムに使われる情報の管理に対して源がひとつだけ存在することを意味します。つまり、情報源ではないシステムのレコードは情報源を参照している状態になります。この仕組みはシステムによって異なりますが、ほとんど考えられる場合は同期を行うことで実現されています。また、広義では、SSOTは限られたシステムにしか適応されていないソリューションより、システムデザインと管理上の心理や概念のようなものと言えます。
IDaaSとの関係
では、この信頼できる唯一の情報源はIDaaSとどう関係しているのでしょうか。IDaaSシステムの主な魅力になるクラウドサービスやシステムとSSOやID同期連携されているのがほとんどであり、IdPが同期情報の情報源になります。その背景の上、よくいただく質問は「どうして同期先のユーザー・グループ変更をIdP側の情報に同期できないのですか？」という質問です。
確かに同期先サービスではそのためのUIが用意されていますし、そちら側でユーザーなどの情報を更新できた方が自然で便利でしょうという意見は、物凄く理解できます。しかし、IdPから対象のサービスの同期が一方通行になっているのには訳があります。皆さんもお気づきだと思いますが、上記のような動きがSSOTの概念違反になり、残念ながら実現することは可能かもしれないとはいえおすすめできません。
① システムごとに管理者権限が同じとは限らない
気づくと当たり前に聞こえますが、同期先のクラウドサービスのユーザーがそのサービスの管理者権限を持っていたとしても、そのユーザーがIdPにも管理者権限を持っていて、かつユーザー・グループなどIdPの同期対象のリソースを更新しても、IdPに害はないという保証はありません。
② 更新履歴は同期元のサービスで確認しなければならない
③ 連鎖同期が発生してしまう
具体例から説明していきますと、IdPがサービスAとサービスBの複数のクラウドサービスにID同期連携している状態であれば、サービスAで行った処理がIdPに同期され、それがさらにIdPから別のサービスであるサービスBに同期される「連鎖同期」が発生してしまいます。仮に①のように権限周りに問題はないと思っているかもしれませんが、エラーが発生してしまったケースを考えてみましょう。
サービスＡで同期対象を更新し、IdPに同期処理がかかった時にエラーが発生しました。その場合には、当然、サービスＢにその同期処理がかかってこないことになります。しかしSSOTで管理していればひとつの同期先が失敗しても、他の同期先サービスに情報が問題なければそのまま同期され、より想定内で理想な状態になります。
