2017年6月に、米国政府機関であるアメリカ国立標準技術研究所(NIST)が「Electronic Authentication Guideline(電子的認証に関するガイドライン、以下『本ガイドライン』と略)」の最新版である「NIST SP 800-63-3」を発表しました。
本ガイドラインが世界の電子認証にどのような影響を及ぼすのか、特にパスワードと関連が多い部分に特化して解説します。
NIST SP800-63-3の位置づけ
NISTは、アメリカ政府(商務省)傘下にある国営の研究所です。本ガイドラインは「現在の技術的動向を踏まえたうえで、アメリカ政府はこのような電子認証を取り入れるべき」というアメリカ政府向けの報告・提言という位置づけになります。この報告書を受けて、アメリカ政府はあらゆる電子認証に関するシステムを徐々に更新することで、不正アクセスや攻撃などの脅威から政府のデータを守ります。
繰り返しになりますが、本ガイドラインは「アメリカの政府機関が、アメリカ政府各省庁・各機関に対しての電子認証ガイドライン」です。よって、アメリカ政府機関に対しては「事実上」強制力があるもの、他国政府、またアメリカ内外の民間企業にとっては何の強制力もありません。
しかしながら本ガイドラインは、パスワード認証を含む世界の電子認証のあり方を大きく変える性質を持っています。それは、本ガイドラインが情報セキュリティ分野において世界をリードするアメリカにより作られており、かつ網羅的・中立的であり信頼性が高いため、世界中から参考にされているためです。各国の政府や民間企業も本ガイドラインを元に、自国ならび自社の電子認証ガイドラインを作成・改定を行っています。既に日本企業の中でも、本ガイドラインを参照に自社の認証システムの改訂を始めている企業が多数あります。
このように、本ガイドラインは「アメリカ政府」に留まらず、事実上世界の電子認証に関する標準ガイドラインとして機能することになるのです。
なお、本ガイドライン(英語)ならびOpen IDファウンデーション ジャパンによる日本語訳は以下から確認できます。
- (英語の原典: 2017/6更新)
https://pages.nist.gov/800-63-3/ - (日本語訳[2017/12時点での最新版、リンク先PDF参照])
https://www.jipdec.or.jp/sp/topics/event/20171013.html
NIST SP800-63-3の考え方を理解する
さて、本ガイドラインではパスワードを含めた認証について、これまでとは何が異なるのか見ていきましょう。本ガイドラインの付属文書である「Authentification and Lifecycle Management(認証とライフサイクル管理)」に取りまとめられています。
はじめに、Authenticator (認証するもの・デバイス)について以下の通りまとめられています。
*OTPは、One-Time Passwordの略
*FIDOは、Fast Identity Onlineの略
*U2Fは、Universal Second Factorの略
次に、これらを利用した認証について、その強度の応じて3段階に分けられています。AAL (Authenticator Assurance Level)という強度で、AAL1、AAL2、AAL3となり、数字が大きい方が強度が高いことを意味しています。
ちなみに、実際の導入において重要な点は、守るべき情報の重要性、深刻度によって、電子認証の強度を分けるべきということです。電子認証の強度が高ければ高いほど良い、というわけではありません。強度が高いということは、認証に時間がかかったり、デバイスを持ち歩く必要が生じたりするため、手間がかかります。電子認証においては、常に「セキュリティの重要度」と「手間」の両面を考える必要があります。
*上記2つの表の引用元
https://www.slideshare.net/kthrtty/20171027-nist-sp80063bkthrtty-81333156
パスワード管理運用に大きな変更あり
パスワードの設定に関する変更
本ガイドラインで特徴的であることの一つとして、さきほどのAuthenticatorでいうところの「記憶シークレット」、つまりパスワードやPINに関して大きな変更がされていることです。以前のガイダンスからの変更点、ならび変更はされていないものの重要となる点について、まずはパスワード自体の設定からご説明させて頂きます。以下の通りです。
- 利用者が設定する場合、最小8文字
- 管理者側が設定する場合、最小6文字
- 複雑性など、他の要素を課すべきではない。すべて数字でもよい
多くの組織では「大文字、小文字、数字、記号の組み合わせで8文字以上」といった設定を推奨していますが、本ガイドラインでは「全て数字で8文字でもOK」というように、一見セキュリティが弱くなったように見受けられますが、そうではありません。パスワード設定時に脆弱なパスワードが設定されないように、利用者が考えて工夫するのではなく、認証側(システム管理者など)で脆弱なパスワードをはじく仕組みを導入することを推奨しています。以下がその例です。
- 過去に漏えいが確認されたパスワード
- 辞書に含まれる言葉
- 文字の繰り返しや順番で用いること
- 「aaaaaaaa」といった繰り返しや「1234abcd」のようなアルファベットや数字の順番での使用 - サービス名、ユーザー名など文脈から特定可能な単語。以下例
- 「QRXYZ」というサービス名のログイン認証時に、「QRXYZ」という語をパスワードに含ませない
- ユーザー名「mtanaka」の場合、パスワードに「mtanaka」を含ませない
さらに、AAL1, AAL2, AAL3という分類がある通り、重要な情報へのアクセスであればパスワードだけでなく、より高い強度の認証方法を用いることが推奨されています。パスワードのみでアクセスできる情報は、重要度が低いもののみで、重要度が高い情報へのアクセスはパスワードと他の要素を用いるようになっていくという流れです。こうした変化により、認証のシステム変更が必要となる組織も多いと考えられます。
パスフレーズ利用のための変更
次に、パスフレーズ(認証用の文字列でパスワードより文字数が多く長いもの)に対応するための項目があることです。
- パスワードの最大文字数は64字まで設定可能とすること
- スペースを入力可能すること
パスワードであれば、例えば「ZhY63#mX」(8文字)というような少ない文字数でしたが、これがパスフレーズになると単語ではなく、単語の組み合わせによるフレーズ・文章を使うため長文化します。長文化すると、セキュリティ上は強固になりますが、文字数が多すぎるため、無意味なフレーズをパスフレーズにすると記憶できなくなります。よって、ある程度意味のある文章をパスフレーズとすることが一般的です。
(例)my father was a firefighter he worked very hard (47文字)
これは「私の父は消防士でした彼は一生懸命働きました」という意味の英文ですが、これをパスフレーズとするとき、スペースを入れられるようにした方が入力しやすくなります。このため、スペースをパスワードの1文字として使えるようにすべきと提唱されています。
「秘密の質問」についての変更
新しくアカウントを作成する際に、「母親の旧姓」「好きなフルーツ」「最初に飼ったペットの名前」など、本人しか分からない秘密の質問を設定したことがある方は多いかと思います。秘密の質問は普段は利用しませんが、パスワードを忘れてしまった場合に、秘密の質問に回答することでアクセスが許可されるという、ある意味保険的な用途で利用されていました。
本ガイドラインでは、こうした秘密の質問は使うべきでないとされました。これは、秘密の質問自体が文字数が少ないことが多く強固ではない点、またパスワードを忘れた際にSMSを利用して多段階認証を行うといった仕組みが一般的になったためと考えられます。
パスワード強度メーター
本ガイドラインでは、利用者が自分でパスワードを設定する場合、パスワード強度メーター(利用者がこれから設定するパスワードの強度を示すもの)を表示すべきとしています。
パスワード強度メーターの例 (レンタルサーバー「ロリポップ」登録画面)
パスワード強度メーターについては、既に幅広いサービスで利用されていますが、今後もさらに普及が進むと考えられます。
認証失敗回数の制限
現在はほとんどすべてのサービスで搭載されていますが、度重なる攻撃による不正アクセスを防ぐために、「何回以上パスワード入力失敗したら、ロックされる」機能を搭載すべきとされています。
パスワードの強制変更禁止
メディアなどでも大きく報じられた点となります。これまで多くのサービスでは、「90日に1度」など、パスワードの定期的な変更を義務付けてきましたが、こうした定期的な強制的な変更を行うべきではないとしています。例外は、認証方法自体が破られる事態が発生した場合で、この場合には強制的に変更すべきとされています。
ペースト機能(パスワード管理ツールの利用を前提)
また、本ガイドラインからパスワードのペースト機能を許可すべきとされています。これまでは、パスワードの入力ミスを防ぐためペースト機能を許可していないサービスが多くありました。この変更は、より強固なパスワードやパスフレーズを設定して、それを記憶するのではなく、パスワード管理ツールで管理すべきという考えに従ったものとなります。
システム・サービスの運営管理者が行うべきこと
冒頭で解説した通り、本ガイドラインはNISTがアメリカ政府に対して「電子認証はこのようにすべき」と提唱しているドキュメントであり、日本政府ならび日本企業に何ら強制力があるものではありません。しかしながら、これまでの流れを見る限り、本ガイドラインが世界の電子認証におけるスタンダードになることは明確です。
よって、どのように自社が管理するシステム・サービスに対して変更・修正を行っていくかの計画が重要となります。以下でご説明します。
1.本ガイドラインを踏まえた自社ガイドラインの作成
不正アクセスを防ぐためには、AAL3のような強度の高い電子認証を適用するほうが望ましいです。しかし、強度の高い電子認証を適用することは、システム・サービスの利用者の利便性が著しく低下するため、全てにおいてAAL3を適用することは望ましくありません。
よって、自社で運用しているシステム・サービスについて、「どのような情報にアクセスできるか」「どのような情報を操作できるか」「誰が閲覧するのか」「社内向けか社外向けか」「無償のサービスか、有償のサービスか」といった点を判断したうえで、「どのようなシステム・サービスの場合、どの強度の電子認証を義務づけるか」を、自社のセキュリティガイドライン上で明確にすることを推奨します。
システム・サービスを構築するために、都度、電子認証の強度について頭を悩ませるのではなく、どのような場面でも適用できる客観的な基準を設けることで、検討工数を削減できます。
2.自社のシステム・サービスのギャップ分析
自社ガイドラインを策定することで、自社の各システム・サービスにおいて「どの強度の電子認証が必要か」が明確になります。次のアクションは、各システム・サービスで求められる強度を満たすために、何が足りないかを明確にすることです。
この中には、AAL1, AAL2, AAL3といった強度に加えて、「パスワード強度メーターの設置」「秘密の質問の廃止」といった項目についても合わせて分析します。
3.電子認証の変更計画を作成
それぞれのシステム・サービスは相対的に重要度が異なり、また本ガイドラインに対応した変更を導入する際の工数、またエンドユーザーへの影響度合いも異なるはずです。このため、全てのシステム・サービスを同時に変更することは事実上不可能ですし、リソースを考慮するとやるべきではありません。
よって、工数や予算、影響度合いなど複数の点を考慮した上で、いつ、どの順番で、どのような変更内容を盛り込んでいくかの計画を策定する必要があります。本ガイドラインは、法的な強制力はありません。法的強制力がないものは、どうしても後回しにされがちなので、網羅的な計画を持って取り組まないと、取りこぼしが出る可能性があります。
パスワード管理ツール・IDaaSの組織的適用
上記では、システム・サービスの運用管理者として、変更にどのように対応するかについて記載しましたが、同時に自社の従業員が電子認証の強度に応じて、負担が少なくシステム・サービスに認証できる環境を作ることも重要となります。
本ガイドラインでは、ペースト機能の記載と共にパスワード管理ツールに関して記載があり、パスワード管理ツールの利用促進については肯定的に記載されています。かつてパスワード管理ツールは、組織内のサーバーへの認証・シングルサインオンを前提とされてきましたが、クラウドの導入進展により、社外のクラウドサービスを含めた認証が求められるようになりました。現在では、IDaaS (クラウド型IDパスワード管理サービス)として提供され、シングルサインオン機能も搭載されています。
IDaaSを利用すると、一般従業員がアクセスする社内・社外システムについて、システム管理者がパスワードを設定して利用させることができるため、一般従業員はパスワード入力が不要になります。つまり、IDaaSを利用すれば、一般従業員に各クラウドサービスのパスワードを知らなくても、サービスを利用できるようになります。覚えておくのはIDaaSのパスワード1つのみです。
これにより、かつては現実的ではなかった運用、例えば「管理者が作成した複雑なパスワード利用の義務化」「長文のパスフレーズ利用の義務化」を行えるようになり、パスワードの強度を高めることが可能です。また、パスワード忘れの問合せ工数を減らすことも可能となります。
弊社が提供するIDaaS「トラスト・ログイン」は、本ガイドラインに沿って電子認証の強度を高めようとする全ての企業が利用できる製品となっています(なおトラスト・ログイン自体も、本ガイドラインに準拠すべく現在改修を進めております)。トラスト・ログインは、他のIDaaS製品と異なり、ユーザー数、アプリ数無制限に制限なしで無料で利用することが可能です。ぜひご評価いただければと存じます。