「認証」の仕組みと身近な「認証」について
情報セキュリティが注目されるなか、「2段階認証」や「生体認証」といった「認証」という単語が含まれる言葉に触れる機会も多くなってきたのではないでしょうか？
今回は認証でどんなことができるのか？どんな仕組みなのか？私たちの身近にある認証とはどういったものか？について紹介したいと思います。
そもそも「認証」とは？
情報セキュリティを確保するうえで、誰に、どの情報へ、どの権限でアクセスさせるかをコントロールすることは非常に大切なことです。
物理空間では警備員の存在や施錠によってアクセスの制御をしていますが、インターネット空間では物理的に遮断することができないので、アクセスしてきた人が本当に本人なのかを確認する必要があります。
「認証」とは、「本人であることの正当性」を確認するための機能で、いわゆる「関所」の役割を果たすものになります。
認証の対象となるのは人であることが多いですが、システムだったり、ソフトウェアだったり、物理端末だったりする場合もありますので、ここでは以下のように呼び方を統一したいと思います。
- 関所を通ろうとする人(認証を受ける人、被認証者)を「主体」
- 関所にいる門番や扉(認証をする人、認証者)を「サービス提供者」
「Certification」「Authentication」の違い
「認証」は「Certification」「Authentication」などに英訳されます。この2つの英単語はITの世界ではよく見かけるのではないでしょうか？
例えばSSL/TLSでは通信の暗号化に用いる暗号鍵の正当性を証明するために証明書の発行が必要ですが、その証明書発行機関として「認証局(Certificate Authority)」という言葉が出てきますし、様々なクラウドサービスで2段階認証のために利用されるモバイルアプリのなかには「Google Authenticator」という名称のものもあります。
今回、対象としているのは「Authentication」の方になるのですが、これらの違いは何なのか？というと概ね下記のような違いがあります。
- Certification ：信頼できる機関や装置(認証局)が発行した証明書を基に主体の正当性を確認すること
- Authentication：主体とサービス提供者が事前に共有している情報で主体の正当性を確認すること
※参考としたサイトはこちら
そういった違いがあることを前提に考えると、先に挙げたものについてそれぞれの違いが分かると思います。
- 認証局(Certificate Authority) → Webサーバー(サービス提供者)とWebブラウザ(主体)間の正当性を確認するための証明書を発行する
- Google Authenticator → Google(サービス提供者)とアプリケーション(主体)間で事前に共有した情報(キー)を確認する
認証によって何が実現できるのか？
前置きが長くなってしまいましたが、結局のところ認証によって何ができるのかと言えば、主体の正当性を認めて証することで、本来通ってはいけない(利用してないけない)主体を遮断することができます。
クラウドサービスの場合などを考えると、この「本来通ってはいけない」ユーザーが通ってしまうことをいわゆる「不正アクセス」と言い換えることができ、認証によって不正アクセスの脅威を防ぐことができるということになります。
認証の要素とは？
認証のために必要となってくるのは何をもって「本人であることの正当性」を確認するのか？という「認証の要素」です。
しかし、いきなり認証の要素と言われても何のことだか分からないので、情報セキュリティに関して幅広く網羅されている「NIST文書」で定義されている認証の要素を紹介します。
情報セキュリティの参考となるNIST文書とは？
NIST文書とは米国の政府機関であるNIST(National Institute of Standards and Technology,米国国立標準技術研究所)のなかにあるCSD(Computer Security Division)というセキュリティに関する部門が発行している文書です。
ここでは特に「SP800-63」という認証にフォーカスした「電子的認証に関するガイドライン」で定義されている内容を引用して紹介します。
NIST文書(日本語訳)はこちら
認証の3要素
NIST文書が定義する認証の3要素は以下の3つです。
- 主体の知識による認証(Something you know)
- 主体の所持するものによる認証(Something you have)
- 主体の身体的な特徴による認証(Something you are)
それぞれの要素について実例を挙げて概要を説明します。
主体の知識による認証
主体が「知っている」ことに基づいた認証で、いわゆる「パスワード」や「PINコード」のことを指します。「秘密の合言葉」を「知っている人」じゃないと「関所」は通さない、という仕組みです。
主体の所持するものによる認証
主体が「持っている」ことに基づいた認証です。最も身近な例としてはクレジットカードやキャッシュカードになります。もう少しIT寄りになると「2段階認証で利用するモバイルデバイス」や「ハードウェアトークン」などが該当します。関所を通るための手形を「持っている人」じゃないと通れない、というイメージです。
主体の身体的な特徴による認証
主体の「身体的な特徴」に基づいた認証です。いわゆる生体認証のことを指していて、「指紋」「顔の特徴」「眼球の虹彩パターン」「声紋」などといった本人でしかあり得ない要素で認証を行います。ちょっとニュアンスが違いますが、誤解を恐れずに言うと「顔パス」みたいなイメージになります。
以上が認証の3要素となり、これらの1つあるいは複数を使って、「本人であることの正当性」を確認することが認証になります。
様々な認証の種類とそれらの実例
それではこれら要素を用いた認証の種類とはどういったものがあるのでしょうか？普段私たちが何気なく利用している認証の方法が3要素の何を用いているのか、実例を挙げて紹介していきます。
パスワード
ユーザーが自分で決めて自分の記憶にだけ残すもので、「主体の知識による認証(Something you know)」の要素による認証となります。NIST文書では「記憶シークレット」と定義されているもののひとつです。
鍵となるのはパスワードだけで、用いられている要素の数は1つであるため、パスワードが漏洩したり解析されてしまうと「関所」を突破されてしまいます。
この脆弱性に対する対処法としてNIST文書では「パスワードは長くて複雑なものにする」「使い回しは禁止」「よく使われるような文字列(password、admin、abcd、1234)は禁止」にすることや、サーバー側ではハッシュ化(復元できないような一方向性の関数で加工して格納)すること等が必要と定義しています。
クレジットカード
クレジットカードの裏面にあるセキュリティコードやインターネットバンキング操作時に利用する「乱数表」などが該当し、「主体の所持するものによる認証(Something you have)」の要素による認証となります。インターネットショッピングやネットバンキングにおいて、カードが本当に「本人の手元にある」ことを証明するために必要なもので、NIST文書では「ルックアップシークレット」と定義されているもののひとつです。
この場合も用いられている要素の数は1つで、自分以外の誰かの手元に渡ってしまうと「持っていること」の要素が成立して、「関所」を突破されてしまいます。
クレジットカードは財布に入れて大切に保管したり、紛失した場合はすぐに利用停止をする等の対策をするかと思いますが保管や管理は厳重に行う必要があります。
利用するためにパスワードや生体認証が必要なハードウェアトークン
ワンタイムパスワード(OTP)を生成するデバイス(モバイル端末にインストールした認証アプリやハードウェアトークン)に対して、更に「指紋認証」や「端末パスワードとは別のパスワード」を設定しているようなイメージで、NIST文書では「多要素OTPデバイス」と定義されているもののひとつです。
これは「主体の所持するものによる認証(Something you have)」 + 「主体の身体的な特徴による認証(Something you are)」 or 「主体の知識による認証(Something you know)」の合わせ技です。
ハードウェアトークン自体が盗まれたとしても、そこから「関所」を通るためのワンタイムパスワードを用意するには「身体的な特徴」か「知っていること」が必要になるため、より強固な認証の種類と言えます。
NIST文書では「認証の要素が多くなるほどシステムは強固になる」としています。認証の3要素を2つ以上組み合わせた認証を「多要素認証(Multi Factor Authentication)」と言います。
混同しやすい言葉に「2段階認証」がありますが、これは「1つの要素を2段階利用する」ことで、2つ以上の要素は利用しません。
例としてIDとパスワードでログインする前に「契約者しか知らないID or 番号」の入力を求める等の方法が「2段階認証」に該当します。
この場合、どちらも「主体の知識による認証(Something you know)」の要素になり、セキュリティレベルとしては一定の強度はあるものの、「多要素認証」よりは低いと言われています。
最後に
ここまでで「認証」がどんなものなのか、イメージしてもらえたと思います。
それでは「認証」が強固であればあるほど良いのか？というとそういう訳でもありません。
システムのセキュリティ強化のために必要なことではありますが、強化するだけして「使えない頻度」が多くなったり、「使えなくなってからの復元」ができない、では意味がありません。
例えばPCで利用するシステムに対して、パスワードとスマートフォンにインストールした認証アプリで生成されたワンタイムパスワードを必要とする2段階(要素)認証を設定したとします。
そうなるとシステムを利用するためには「スマートフォン」が必要ですが、それが故障してしまったり、機種変更してしまったらワンタイムパスワードを生成できずに、システムを利用することができなくなってしまいます。
こういった事態を想定して、大抵の場合は2段階(要素)認証を設定する際に「バックアップコード」と呼ばれる「1回だけ利用できる」数字の列などが数個生成されたりします。
前述した例のようにワンタイムパスワードを生成するデバイスが利用できなくなった場合は、パスワード + バックアップコードによってシステムを利用することができます。(前述した「ルックアップシークレット」の方法に該当します。)
この例では復元にそれほど手間はかからないかと思いますが、生体認証で利用できるワンタイムパスワード生成デバイスの生体認証が何等かの理由でうまく動作しない、などになってしまうと生体認証自体を登録し直したり、デバイス自体を再発行する必要が出てきてしまい、システムが「使えなくなってから復元」するまで時間がかかってしまいます。
「認証」については強固にするだけではなく、可用性、利便性や業務効率を確保するための考え方に戻づいた設計が重要になってきます。
認証について具体的な例を挙げて紹介してきましたが、これらの技術や仕組みはまだほんの一部に過ぎません。
システムごとに違うパスワードを管理、入力する工数を緩和するために、「アカウント連携」や「SSO(シングルサインオン)」といった技術もあります。
今回は認証について基本的な内容を紹介しましたが、機会があればセキュリティレベルを担保したまま可用性や利便性を向上する、それらの技術についても触れられたらと思います。
