雰囲気理解からの卒業 『FIDO2』企業で採用する際の最適解とは?

zerotrust_cmmn_top_headb1.jpg

はじめに

ネットバンクやショッピングサイト、クラウドサービスなど、本人特定が必要なシーンにおいて、IDやパスワードを用いるセキュリティ方式は古くから採用され、現在も使われています。
しかし、パスワード認証には不正サイトでだます事(フィッシング詐欺)による漏洩、ブルートフォース(パスワードの総当たり)攻撃による不正突破など、常に不正ログインの危険性を孕んでいます。
また、サービス側で流出してしまうケースなど、自分自身の対策の及ばない範囲での流出リスクもあります。

このようなパスワードの弱点が浮き彫りになる中で、今FIDO2が注目されています。
このブログでは、FIDO2がなぜ注目されていて、それがどういったものであるか、そして企業で使うにはどの様なアプローチがあるのかについて解説していきます。

パスワード認証における問題点について

まずはパスワード認証におけるメリット・デメリットをおさらいしていきましょう。

figure1.png

メリット
・構成がシンプルで導入も容易

デメリット
・アプリケーションごとにパスワードを生成、記憶が必要
・偽のアプリケーション[Webサイト]へ入力してしまう可能性(フィッシング詐欺)
・アプリケーション/Webサイト側の脆弱性によるパスワード流出リスク
・(特にスマートフォンなどでの)入力の不便さ
・ユーザーによるパスワードの使いまわし
・パスワード忘れに対する運用コストの増大

上記の通り、パスワード認証は広く使われている一方で、管理面、セキュリティ面、そしてユーザービリティの面で数多くの問題がある点は、きっと皆さんにもご理解いただけると思います。

FIDO(FIDO2)って何?

では続いて、FIDO(FIDO2)がどういったものであるかについて解説していきます。FIDO(ファイド)は、ユーザー認証におけるパスワードへの依存を軽減するためにFIDOアライアンス(https://fidoalliance.org/?lang=ja)が提唱している技術仕様です。

figure2.png

基本的な動作としては、認証器と呼ばれるFIDO対応デバイスにて認証を行い、認証結果をアプリケーション(FIDO Server)に送信する事でアプリケーションへログインする方法です。また、生体認証技術と組み合わせ、パスワードに代わって本人特定を行う認証技術という側面も持っています。
つまり、生体認証を使用する事でいわゆるパスワードレス認証が実現可能です。また、アプリケーション(Webサイト)には直接パスワードを入力しませんので、詐欺サイトなどの影響を受けない認証方式とも言えます。

FIDO2について

最初に制定されたFIDOでは、U2F(*1)、UAF(*2)という2つが定義されていました。その後に制定されたFIDO2では、ブラウザにてFIDO認証を可能にするための標準Web APIを定義しているWebAuthn、認証器との接続仕様で従来U2Fと呼ばれていた、主に二段階認証を想定した接続仕様を定義しているCTAP1(*3)、同様に主にパスワードレスを想定した接続仕様を定義しているCTAP2(*4)が定義されています。

本ブログでは、最終的に企業での利用におけるアプローチを想定し、追加で機器が必要なく導入が容易なWebAuthnと、今後普及が進むと考えられる生体認証にフォーカスを当てて詳しく解説していきます。(FIDOでは生体認証以外の方式もサポートされています。)

W3C WebAuthn(Web認証)では、FIDO認証を可能にするための、ブラウザおよびプラットフォームに組み込まれている標準Web APIを定義しています。

現在、WebAuthnは、Google社のChromeやMicrosoft社のEdge、Apple社のSafariなど、主要なブラウザでサポートされています。
また、FIDO認証器は、iOSのTouchIDやWindows 10のWindows Hellow、Android生体認証などFIDO認証器を内包しているデバイスでサポートされています。(これらのデバイスに内包されているFIDO認証器の事を内部認証器と呼びます。)

WebAuthnで定義されているAPIを使用する事でこれらの内部認証器(のクレデンシャル情報)にアクセスする事が出来ますので、認証側はWebAuthn+内部認証器にてFIDO認証が実現可能です。

FIDO構成要素

FIDOでは、次のような構成要素があります。

figure3.png RELYING PARTY
ユーザーが利用したいサービス
figure4.png FIDOサーバー
FIDO認証を実際に行うサーバー
figure5.png FIDO Client (Relying Party Client/WebAuthn Client)
FIDO認証に対応したクライアントアプリケーション(FIDO対応ブラウザ、クライアントソフトなど)
figure6.png Authenticator(認証器)
FIDO認証(本人性を検証)するためのデバイス、本ブログでは内部認証器を想定
figure7.png ユーザー
FIDO認証を実施する本人(指紋、顔認証などの持ち主)


これらの構成要素を踏まえて、FIDO登録・認証フローを見ていきましょう。

FIDO登録・認証フロー

まず、理解しやすくするため、「FIDO2に対応したコンシューマー向けのウェブアプリ」に対して、「Windows 10に搭載されているWindows Helloを使って」ログインする想定で解説します。なお、この場合、一般的にはウェブアプリがRELYING PARTYおよびFIDOサーバーを兼ねていることが多いため、アプリケーションと表現し説明していきます。また、フローを理解するため簡略化して記載しています。

figure8.png

1. 新しい認証器を登録、または既存の認証器で認証するため、WebAuthn(認証)を開始
2. アプリケーション(FIDOサーバー)よりチャレンジ情報が送信
3. ブラウザ(WebAuthn Client)は、ブラウザ(Relyng Party Client)から渡されるJavaScriptの情報を使用して認証プロセスを開始
4. ブラウザ(WebAuthn Client)は、内部認証器に認証を要求
5. ユーザー認証を実施
6. 認証成功後、登録の場合は秘密鍵と公開鍵のペアを生成。認証器にて(登録の場合は生成した公開鍵を含めた)署名されたレスポンスを作成
7. レスポンスを返答
8. ブラウザ(WebAuthn Client)はJavaScriptにてレスポンスを提供
9. アプリケーション(FIDOサーバー/RELYING PARTY)はレスポンスを検証し、ユーザーが認証(登録の場合は認証器が登録)

FIDOのメリットについて

FIDO認証の"ポイント"は、先のパスワード認証の様にアプリケーション側でユーザー認証を行うのではなく、ユーザー側でユーザー認証が完結出来る事だと思います。

FIDOでは、認証器となるFIDO対応デバイス、及びFIDO Clientにて生体認証などを実施する事で、ユーザー側で認証を行います。
アプリケーション側にはFIDO認証の結果が渡されますので、(アプリケーション側で)FIDO認証の結果の妥当性を検証すればユーザー認証が実現できます。

認証に使用される秘密鍵は認証器から取り出せない仕様ですので、秘密鍵流出によるなりすましも防止できます。

パスワードを渡す必要がありませんので、フィッシングのリスクも無く、パスワードでは無く生体認証にてユーザー認証を行うことでパスワード忘れの対応も不要となります。
たとえば、パスワードに代わる、顔認証(Windows Hello、FaceID)や指紋認証(Touch ID)などの生体認証にて、普段使用されるアプリケーションの利用(ログイン)が実現出来ます。

企業で実現するパスワードレス(FIDO)認証

ここまで読まれた方は、もしかするとFIDOを採用すれば良い事尽くめの様に感じていらっしゃるかもしれません。ただ、企業で採用するにあたっては、大きく2つのハードルがあります。

まず1つ目に、ユーザーに使用させるアプリケーションの管理面での懸念があります。
FIDOでは、個々のアプリケーション用に秘密鍵と公開鍵のペアを認証器側で保持し、各アプリケーション側では認証結果を検証するためユーザーの公開鍵を保持しています。
言い換えると、個々のアプリケーション毎にユーザー登録作業が必要となります。

figure9.png

仮に、ユーザーが使用しているアプリケーションが100あった場合、デバイス紛失や故障の際には、100のアプリケーションに対して再登録が必要となります。
また、企業で使用する際には、必要なユーザーに必要なアプリケーションをどう提供してくかといったユーザー管理面での課題が存在しています。

2つ目のハードルとして、FIDOを採用するためには、採用する企業側だけではなく、使用するアプリケーション側もFIDOに対応している必要があります。今後、FIDOの普及が進むと考えられますが、企業が使用するアプリケーションではまだ採用が過渡期になるかと思います。

これら2つのハードルをクリアし、企業で採用するためには、シングルサインオン(SAML認証)との組み合わせが考えられます。

SAML認証(SSO[シングルサインオン])について

既に、業務で利用するSaaSの多くがSAML認証に対応していることもあり、採用されている企業も多いのではないでしょうか。

figure10.png

SAML認証は企業のAD(+IdP)やIDaaSで認証を行い、認証結果(Assertion)を送信する事でアプリケーションへログインする方法になります。
ADやIDaaSに保持しているパスワード情報を元にIdP(SAML認証)側でユーザー認証を行い、認証結果(SAML Assertion)をアプリケーションに渡す事で、ユーザーログインを実現しています。また、この認証では事前に認証した結果をクッキーなどに保持しておくことでSSO(シングルサインオン)が実現出来ます。

認証自体はADやIDaaS側で行いますので、アプリケーション(Webサイト)には直接パスワードを入力しませんが、依然としてユーザー特定にパスワードを使用することにはなります。
そこで、公開鍵を保持するFIDOサーバーの機能をIDaaS(SAML認証)側で行う事で、ユーザー認証部分にFIDOを使用し、アプリケーション側の管理面(登録、認証)はSAMLを使用する事で、企業認証における認証(パスワードレス+シングルサインオン)が実現可能です。

figure11.png

Okta(IDaaS)+パスワードレス(FIDO)の実例

一例として、Oktaでは、FIDOによるユーザー認証をサポートしていますので、簡単に「FIDO認証+シングルサインオン」の環境を実現する事が出来ます。
具体的には、下記の様な構成になります。

ゼロトラFIDO.png

下記一連の動作フローで、FIDO+SAMLの実現が可能です。
※SAML(Brower SSO)は、ブラウザ(以下では説明上SAML Clientと表記)経由で渡されますが、以下では省略(IDaaSに直接渡されるような表記に)しています。

figure13.png

1. SAML(SP Initiated)を開始
2. SAML(Auth Request)
3. FIDO(Auth Request)
4. FIDO(生体認証)
5. FIDO(Auth Approval/Response)
6. SAML(Assertion)

まとめ

FIDOとIDaaS(Okta)を連携する事で、企業はユーザーが使用するアプリケーションをコントロールする事が可能になります。
認証面ではFIDOの生体認証を使用する事で、ユーザーに、より安全にログインさせる環境が提供でき、パスワードが持つ諸問題より開放されます。また、FIDOサーバーの役割をIDaaSに持たせることで、企業はユーザーが利用できるアプリケーションのコントロールが可能となり、ユーザーは個々のアプリケーションに対する登録作業から解放されます。
この機会に、企業におけるパスワードレスによる認証面の向上や、管理面におけるメリットなどをご検討されるのは如何でしょうか。

*1 U2F(Universal 2nd Factor)は、2段階認証を想定したプロトコル(接続仕様)になります。認証の際に外部認証器と呼ばれるUSBなどで接続する認証器(Yubico社のYubikeyなど)のボタンを押す、NFCのタップなどの方法をユーザーに促し、認証器を所持している事を証明する事で本人確認の実現を想定しています。
*2 UAF(Universal Authentication Framework)は、パスワードを使用せず、UAFに準拠したスマートフォンなどの認証器を用いた生体認証や指のスワイプ、PIN入力などによる本人確認の実現を想定したプロトコル(接続仕様)になります。
*3 CTAP1/2は、外部認証器を使用する事を想定したプロトコル(接続仕様)になります。
CTAP1は、従来のFIDO U2Fを包括したプロトコル(接続仕様)になります。FIDO2対応ブラウザおよびUSB、NFC、またはBLEを介したオペレーティングシステムでの認証に、既存のFIDO U2Fデバイス(FIDOセキュリティキーなど)を使用する事を想定したプロトコル(接続仕様)になります。
*4 CTAP2は、パスワードレス、第2要素、または多要素の認証体験を実現するために、USB、NFC、またはBLEを介したFIDO2対応ブラウザおよびオペレーティングシステムでの認証に外部認証システム(FIDOセキュリティキー、モバイルデバイス)を使用する事を想定したプロトコル(接続仕様)になります。

------------------------

【ホワイトペーパー:"絵に描いた餅"はもういらない 検証から見えてきた現実的なゼロトラストの最適解】

今回は、ゼロトラストがなぜ求められているのかについて改めて振り返りながら、 ベンダが語る"都合のいい"ゼロトラストに踊らされないための、 その考え方について紐解いていきたい。

WPはこちら1.2.png

------------------------