2018年9月4日火曜日

IDaaSとは、何か? (3) 〜訪問者は誰?〜

前々回の記事、[IDaaSとは、何か(1)」で、IDaaSには、以下の機能があるとご紹介しました。

  • 保存:Identityに関する情報を保存・管理する。
  • 認証:利用者が誰なのかを管理する。
  • 認可:利用者が許可されているサービスやリソースを管理する。
  • プロビジョニング: 利用者が許可されているサービスに対して、アカウントを管理する。

前回は、「IDaaSとは、何か? (2) 〜IDの一元的な保存について考える〜」として、「保存」についてみてみました。今回は、「認証」です。



あなたは誰ですか?

「認証」とは何でしょうか。端的に言えば、「アクセスしている人が誰なのかを明らかにすること」です。通常、クラウドサービスは、広くインターネット全体に入り口を公開しています。この入り口(ログイン画面)に来た人が、誰なのかがわからなければ、サービスを利用させることは出来ませんし、その利用者向けの情報を保持していたとしても、提供することができません。
また、次回見る予定の「認可」でも、相手が誰なのかわからなければ、誰に何を認可して良いのかわかりません。すべての人に同一のサービスを提供するというものでもない限り、情報システムでは、利用者が誰であるかを明らかにする、「認証」という機能は必須ということになります。

何をもって、「誰」なのかを証明するか

では、サービス側に登録済みの利用者であることを、どのように確認するのでしょうか。最も一般的なのは、「id」と「パスワード」です。「id」は、重複のないそのシステムでユニークな「名前」と言えます。「パスワード」はその利用者しか知らない前提の文字列です。この2つの組み合わせをログイン画面で入力させることにより、「利用者が正しく、登録済みの誰であるか」を確認します。
ただ、「パスワード」は、前述の通り、「利用者しか知らない」ということを前提としています。そのため、これが流出してしまった場合や、容易に類推できるものである場合には、意図しない人が利用者になりすますことが可能です。パスワードが短すぎる場合や、文字種が少ない場合は、総当りで突破することも可能でしょう。ただ、人が覚えていて入力するものなので、あまり長くては覚えられなかったり、入力時にミスをしたりするため、簡単なものにしてしまうことが多いようです。

パスワード認証の高度化

パスワードは、「認証」機能の基本ですが、前項で述べたとおり、様々な観点で鉄壁のセキュリティとは言い難い仕組みです。IDaaSが備える「認証」機能は、いくつかの仕組みで、パスワードの弱いところを保管していることが多いようです。
利用者が脆弱なパスワードを使うことを防ぐために、パスワードに設定可能な文字種や文字数をポリシーとして設定できれば、パスワード自体を一定以上の強度に保てます。
また、流出に気づいていないようなケースでもなりすましを防ぐために、定期的な変更を促すこともできるようになっています。ただし、昨今では、定期的な変更を促すことで、いくつかの単純なパスワードを使いまわすようになるなど、返って脆弱になるという意見もあります。これについては、パスワードの定期的な変更が不要とされたことの意味とは?で詳しく書いてみましたので、ご覧ください。
また、パスワードの総当りをできないようにするため、同一IDに対する一定回数以上の不正なパスワード入力で、そのID自体をロックするという機能もあります。
このように、人間には便利な認証方法である、「パスワード」を使うために、その認証方法は高度になってきましたが、やはり、パスワードそのものが漏れてしまった場合や、共有アカウントを使っていて、組織のみんながパスワードを知っていて、誰かが組織から離れたような場合には、どうしても不正なアクセスを許してしまいます。

パスワード以外の認証

そこで、パスワード以外の認証方法も発達してきました。方法は様々です。基本的には、IDとそれ以外の情報での組み合わせです。それ以外の情報は、「本人しか持ち得ないもの」です。パスワードは、「本人しか知らないもの」ですので、構造は一緒と言えます。ただ、知っているかどうかということは、漏れたら終わりです。そこで、「物理的に本人しか持っていないもの」として、指紋や虹彩などの生体情報を使う認証方法もあります。ただ、専用のデバイスが必要なので、あまり広くは使われていないようです。
一方で、スマートフォンなどのスマートデバイスは、今や殆どの人が肌見放さず持ち歩くようになっています。ここに目をつけて、スマートデバイス自体を「本人しか持ち得ないもの」として扱う認証方法が広く使われるようになっています。弊社が提供しているGluegent Gateでも、アプリケーションで端末独自のキーを生成することで、そのキーをもってアクセスしなければ、認証しないようにすることができます。紛失した場合には、登録されているキーを取り消すことで、第三者がアクセスすることを防ぐことができます。
このような認証方法を複数組み合わせることで、セキュリティのレベルを格段に上げることができます。IDaaSに限らず、昨今のサービスでは、それぞれで、このような認証(他要素認証)を備えていることも多くなりました。サービス側から、端す。末の電話番号に対して、六桁ほどの数値をSMSで送るというのが一般的なパターンのようです。
他にも、一定期間しか有効にならない、パスワードを一時的に生成する仕組みを提供することで、その仕組みを保有する人が、正しい人であると認証する方法(ワンタイムパスワード)など、認証方法は高度に多様化していると言えるでしょう。

アクセス制御への応用

アクセス制御という考え方は、本来、認証とは直接関係しませんが、認証を通すか通さないかという仕組みを使って、アクセス制御の機能をもたせることができます。よく使われるのが、特定のネットワークからのアクセスに限るという制御です。
前述した、パスワードやその他の認証と同様に、予め定義されたネットワークからのアクセスを認証要素として加えることができると、柔軟なアクセス制御が可能になります。例えば、
  • 社内LANからのアクセスの場合、パスワード認証のみで利用可能とする。
  • 社内LAN以外からのアクセスの場合、パスワード認証と端末認証を組み合わせた認証で利用可能とする。
というように、レベルの差をつけることが出来ます。社内のネットワークにアクセスできる時点で、その人は、社内の人間であることが担保できます。そこで、利便性を上げるために、端末認証は、はずしても良いという考え方です。
このように、認証とは、本来「あなたは誰ですか」というだけのものですが、複数の認証要素を組み合わせることで、利便性とセキュリティの高さを両立させることができます。

誰に何を使わせるか

認証機能により、使っている人が誰であることがわかるようになりました。では、その人にどのようなサービスを使わせれば良いのでしょうか。これを制御するのが、「認可」です。次回をこれを掘り下げてみましょう。

   Gluegent Gate