ゼロトラスト 2021.02.17

『FIDO2』を企業で採用する際の最適解とは？

はじめに

パスワード認証に依存したセキュリティ対策の弱点が浮き彫りになる中、FIDO2（ファイドツー）が注目を集めています。
このブログでは、FIDO2がなぜ注目されているのか、どういったものであるか、そして企業で使うにはどの様なアプローチがあるのかについて解説していきます。

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

パスワード認証は、ネットバンクやショッピングサイト、クラウドサービスなど、本人特定が必要なシーンにおいて古くから採用され、現在も使われています。

しかし、パスワード認証には不正サイトでだますこと（フィッシング詐欺）による漏洩、ブルートフォース（パスワードの総当たり）攻撃による不正突破など、常に不正ログインの危険性を孕んでいます。

また、サービス側で流出してしまうケースなど、自分自身の対策の及ばない範囲での流出リスクもあります。

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

パスワード認証のメリット

・構成がシンプルで導入も容易

パスワード認証のデメリット

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

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

FIDO（FIDO2）って何？

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

基本的な動作としては、認証器と呼ばれるFIDO対応デバイスにて認証を行い、認証結果をアプリケーション（FIDO Server）に送信することでアプリケーションへログインする方法です。また、生体認証技術と組み合わせ、パスワードに代わって本人特定を行う認証技術であるという側面も持っています。

つまり、生体認証を使用することでいわゆるパスワードレス認証が実現可能です。また、アプリケーション（Webサイト）には直接パスワードを入力しませんので、詐欺サイトなどの影響を受けない認証方式とも言えます。

FIDO2を企業で利用するための基礎知識

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

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

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

現在、WebAuthnは、Google社のChromeやMicrosoft社のEdge、Apple社のSafariなど、主要なブラウザでサポートされています。

また、FIDO認証器は、iOSのTouch IDやWindows 10のWindows Hello、Android生体認証などFIDO認証器を内包しているデバイスでサポートされています（これらのデバイスに内包されているFIDO認証器を内部認証器と呼びます。）

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

FIDO構成要素

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

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

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

FIDO登録・認証フロー

理解しやすくするため、前提として「FIDO2に対応したコンシューマー向けのウェブアプリ」に対して、「Windows 10に搭載されているWindows Helloを使って」ログインする想定で解説します。

なお、この場合、一般的にはウェブアプリがRELYING PARTYおよびFIDOサーバーを兼ねていることが多いため、アプリケーションと表現し説明していきます。また、フローを理解するため簡略化して記載しています。

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

FIDOのメリットについて

FIDO認証のポイントは、先のパスワード認証のようにアプリケーション側でユーザー認証を行うのではなく、ユーザー側でユーザー認証が完結できる点です。

FIDOでは、認証器となるFIDO対応デバイス、およびFIDO Clientにて生体認証などを実施することで、ユーザー側で認証を行います。

アプリケーション側にはFIDO認証の結果が渡されますので、（アプリケーション側で）FIDO認証の結果の妥当性を検証すればユーザー認証が実現できます。

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

パスワードをユーザー側に渡す必要がありませんので、フィッシングのリスクもなく、パスワードではなく生体認証でユーザー認証を行うのでパスワード忘れの対応も不要です。

たとえば、パスワードに代わる、顔認証（Windows Hello、Face ID）や指紋認証（Touch ID）などの生体認証で、普段使用されるアプリケーションの利用（ログイン）が実現できます。

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

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

まず１つ目に、ユーザーに使用させるアプリケーションの管理面での懸念があります。

FIDOでは、個々のアプリケーション用に秘密鍵と公開鍵のペアを認証器側で保持し、各アプリケーション側では認証結果を検証するためユーザーの公開鍵を保持しています。

言い換えると、個々のアプリケーションごとにユーザー登録作業が必要となります。

仮に、ユーザーが使用しているアプリケーションが100あった場合、デバイス紛失や故障の際には、100のアプリケーションに対して再登録が必要となります。

また、企業で使用する際には、ユーザーが必要とするアプリケーションをどう提供していくかといったユーザー管理面での課題が存在しています。

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

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

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

すでに、業務で利用するSaaSの多くがSAML認証に対応しています。そのため、シングルサインオンを採用されている企業も多いのではないでしょうか。

SAML認証は企業のAD（+IdP）やIDaaSで認証を行い、認証結果（Assertion）を送信することでアプリケーションへログインする方法です。

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

認証自体はADやIDaaS側で行いますので、アプリケーション（Webサイト）には直接パスワードを入力しませんが、依然としてユーザー特定にパスワードを使用することにはなります。

そこで、公開鍵を保持するFIDOサーバーの機能をIDaaS（SAML認証）側で行うことで、ユーザー認証部分にFIDOを使用し、アプリケーション側の管理面（登録、認証）ではSAMLを使用することで、企業認証における認証（パスワードレス+シングルサインオン）が実現可能です。

Okta（IDaaS）+パスワードレス（FIDO）の実例

一例として、Oktaでは、FIDOによるユーザー認証をサポートしていますので、簡単に「FIDO認証+シングルサインオン」の環境を実現できます。

具体的には、下記のような構成になります。

ゼロトラFIDO.png

下記一連の動作フローで、FIDO+SAMLの実現が可能です。

※SAML（Brower SSO）の認証情報は、実際はブラウザ（以下では説明上SAML Clientと表記）経由で渡されますが、以下では省略（IDaaSに直接渡されるような表記に）しています。

SAML（SP Initiated）を開始
SAML（Auth Request）
FIDO（Auth Request）
FIDO（生体認証）
FIDO（Auth Approval/Response）
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セキュリティキー、モバイルデバイス）を使用することを想定したプロトコル（接続仕様）です。

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

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

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