2018年11月27日火曜日

IDaaSとは、何か? (7) 〜その価値とは?〜

今回は、IDaaSについて紐解く人気シリーズ「IDaaSとは何か」の最終回です。各回で、IDaaSが持つ複数の機能を掘り下げてきました。今回は、それらがどのように協調して、IDaaSとしての価値を提供するのか、見てみたいと思います。
それぞれの記事の内容を振り返り、ストーリーがつながることを確認します。


IDの一元的な保存について考える

第二回で、「保存」について説明しました。「Identityに関する情報」が、一箇所に「保存」されていていることの重要性についてです。複数の場所に保存されているのではなく、一元管理されることで、常に新しく、正しい「Identity情報」の保存と、参照が可能であることを説明しました。
一箇所に保存されていない場合には、同期の必要があったり、同期するまでは、一方が古い情報を持つことになります。一箇所に情報があれば、常にそこが正であることを保証することができます。

訪問者は誰?

第三回で、アクセスしてきた人が誰なのかを確認する、「認証」について扱いました。システム側では、アクセスしてきた人が誰なのかを同定し、その人が正しく登録済みの人であるのか確認する必要があります。それが認証です。第二回で説明した「保存」の機能で保持されている「Identity情報」と「アクセスした人」が合致しているか、様々な方法で確認します。

どのサービスを使わせるか

第四回では、認証によって判明したユーザに対して、どのようなサービスを使わせるかを管理する「認可」を扱いました。実際の運用を考えると、
  • 営業担当者には、Salesforceを使わせる
  • サポート担当者には、Zendeskを使わせる
  • 全社員に、G SuiteとSlackを使わせる。
というように、グループに対して、サービスを「認可」することができます。これは、どのユーザがどのグループに属しているかという情報が、IDaaSに「保存」されているためです。

使えるように準備する

第五回では、「プロビジョニング」について扱いました。プロビジョニングが出来ない場合は、対象サービス側の管理画面から、アカウントを作る必要がありますが、プロビジョニングに対応している場合は、連携するサービスに対して、「アカウントの作成・更新・削除」をすることが出来ます。
つまり、IDaaSにアカウントを作成し、対象サービスを認可することで、対象サービス側には、アカウントが作成されますし、認可を取り消せば、削除(あるいは無効化)されることになります。または、認可をグループで管理していれば、特定のグループに所属させることで、対象サービスにアカウントが作成され、グループから外せば、削除(あるいは無効化)されます。ここが自動化されていない場合は、運用において大きな違いがあります。

利便性とセキュリティの両立

第六回では、「シングルサインオン」について扱いました。シングルサインオン(SSO)は、利用者の側からの視点と、管理者からの視点でその意味が大きく異なります。利用者の視点に立つと、
  • 一度ログインすれば、使って良いサービスはすべて使える
  • ID/パスワードをそれぞれ別々に覚えなくても良い
という利点があります。また、管理者にとっては、ユーザが杜撰なパスワード管理をする可能性が低くなる点と、サービス利用の停止が容易である等の利点があります。

運用例にあてはめます

前回までの内容を簡単にまとめてみました。これらの機能は、それぞれ他の機能を利用する立場にあります。ここまでの説明で断片的に出ていますが、全体としてどのように動くのか、簡単な運用例にあてはめてみましょう。登場するのは、「管理者」「利用者」「IDaaS」「サービス」です。
  1. 管理者は、IDaaSに利用者のアカウントを作成する。
  2. 管理者は、IDaaSで、利用者に連携するサービスを認可する。
  3. 利用者は、IDaaSのログイン画面から、ログインする。
  4. 利用者は、サービスを利用する。
この流れを少し詳細に見てみます。1.で利用者の「Identity情報」がIDaaSに保存されます。この段階では、まだIDaaSにあるだけです。2.の認可により、プロビジョニング機能を使って、連携するサービスにアカウントが作成されます。3.では、認証機能により、ログインして、シングルサインオンにより、対象機能にログインしていることになります。これらの機能が協調することで、4.で利用者はサービスを利用することができます。では、もう少し複雑な例として、利用者が他の部署に異動する例を考えましょう。具体的な方が分かりやすいので、以下のような例を想定します。
  • 「山田太郎」が「開発部」から「営業部」に異動する。
  • 開発部では、Slackを利用する。
  • 営業部では、Salesforceを利用する。
  • 全社員が、G Suiteを利用する。
異動のタイミングでの管理者の処理から始まります。ただし、前提条件として、
  • 開発部グループには、Slackが認可されている。
  • 営業部グループには、Salesforceが認可されている。
  • 全社員グループには、G Suiteが認可されている。
という設定がされているものとします。
  1. 管理者は、IDaaS上で、開発部グループのメンバーから、山田太郎を削除する。
  2. 管理者は、IDaaS上で、営業部グループのメンバーとして、山田太郎を追加する。
  3. 山田太郎は、IDaaSのログイン画面から、ログインする。
  4. 山田太郎は、G Suite、Salesforceが利用でき、Slackが利用できない。
この流れも詳細に見てみます。1.でSlackの山田太郎アカウントは、プロビジョニング機能により、削除か無効化されます。削除か無効化としているのは、対象サービスや、IDaaSの仕様によるからです。どちらにしても、山田太郎は、Slackを使えなくなります。2.で、Salesforceに山田太郎アカウントが作成されます。これ以降は、前述の例と同様で、3.で認証機能により、ログインし、4.では、シングルサインオン機能によりG SuiteとSalesforceにはログインしている状態となっているので、そのまま利用可能です。一方で、以前は使えていたSlackは使えないということになります。

まとめ

「IDaaSとは何か」というテーマで、7回にわたってその機能について掘り下げみました。IDaaSという耳なれない言葉について、身近なものとして理解するための一助となればと思います。多くのクラウドサービスが、提供されていますが、それを有効に使うためには、クラウドサービスを管理、運用するためのサービスも必要になります。それがなければ、結局運用は破綻し、せっかく有用なサービスも使われないか、なりすましや、不正利用されることもあり得ます。
IDaaSは、ユーザにも、管理者にも非常に有用なサービスです。導入をご検討ください。弊社では、豊富な実績のあるIDaaSサービス「Gluegent Gate」を提供しています。IDaaSの必要性に納得いただけましたら、ぜひ、ご相談ください。


   Gluegent Gate