0. はじめに

上司やお客様から突然「多要素認証／二要素認証を検討して」と言われた場合、どうしますか？
いずれ弊社（オープンソース・ソリューション・テクノロジ株式会社）のような専門ベンダに連絡するとしても、その前に、ベースの知識を得ておくためにWeb上で情報を探してみるのではないでしょうか。

多要素認証／二要素認証の基本的な考え方については既に多くのウェブページで解説されてますが、実現のための検討観点についてはあまり情報がないかも...という印象です。

というところで本記事では、SE様のように多要素認証／二要素認証を導入なさる側の皆様を意識し、
導入検討時にベース知識を得るための情報源となるべく執筆します。
もし記事をお読みくださったら、ベンダ候補として弊社も加えていただけますと嬉しいです。

1. 検討観点１：どのような多要素認証にするか

多要素認証の一要素目は従来と同様パスワードによる認証だとして（必ずしもパスワードでなくてもよいですが。）、二要素目としてどのような認証を実現すると良いでしょうか。弊社OpenAMで既に用意されているものから代表的なものを挙げるだけでも結構あります。

#	二要素目認証に使えるもの	説明
1	クライアント証明書による認証	あらかじめユーザ端末にクライアント証明書を入れておき、認証時にユーザ端末から認証サーバへクライアント証明書＆署名が送付される。　認証サーバは証明書＆署名を検証することで正しいユーザであることを確認する。
2	送付されたワンタイムパスワードで認証（SMS, LINE, email）	ユーザが所有するSMS, LINE, emailアカウント宛てに、認証サーバがワンタイムパスワードを送付する。　このワンタイムパスワードの入力をもって正しいユーザであることを確認する。
3	ワンタイムパスワード生成器と連動した認証	ハードウェアまたはソフトウェア（Google Authenticatorなど）のワンタイムパスワード生成器をユーザに所持してもらい、生成用の鍵を認証サーバとあらかじめ共有しておく。　生成器に表示されたワンタイムパスワードの入力をもって正しいユーザであることを確認する。
4	FIDO2/WebAuthn（HOT!!）	FIDO2仕様に準拠したデバイス（Windows, Android, iOS, 専用USBデバイス, etc...）をユーザに所持してもらい、あらかじめ鍵情報などを認証サーバとの間で紐づけ登録しておく。　認証サーバでの認証時にデバイスの利用が促され（多くの場合はデバイス上で指紋認証などの認証を伴う）、その成功をもって認証サーバとしても正しいユーザであると確認する。

このように様々ある二要素目認証の選択肢から、どれを選ぶと良いでしょうか。
その検討材料となる情報として、主に以下のようなものが考えられます。

#	二要素目認証を選択する際に検討材料となる情報	情報の例	二要素目認証の選定に与える影響例
1	アプリケーションの重要性	・全く個人情報を扱わない・個人情報やユーザの資産を扱う・...etc	・そもそも二要素認証を実施するのか？・重要性がユーザ次第であれば、二要素認証をオプション化する？・個人情報を扱うなら最低でもワンタイムパスワード生成器での二要素認証を必須とする？・...etc
2	ユーザ層、扱うユーザ情報	・閉じたユーザ層／誰でもアカウント作れるユーザ層・電話番号や住所をサーバ側で持っている？・...etc	・閉じたユーザ層であればクライアント証明書も適用可能？・ユーザ層様々であれば、使い勝手の良いものを優先し、かつ、いくつかの認証方法から選択可能にする？・住所情報をサーバ側で持っているのであれば、ハードウェアのワンタイムパスワード生成器を送付可能？・...etc
3	掛けられるコスト	・〇〇〇〇万円・△△△万リラ・...etc	・クライアント証明書を使う場合、発行コストに耐えられるか？・ハードウェアのワンタイムパスワード生成器を使う場合、配布コストに耐えられるか？・...etc

2. 検討観点２：実現方法

ざっくりとでも何を実現するか決まったら、どのように実現するかも検討するかと思います。
以下のように大別してみます。

#	実現方法	内容
1	自社開発	実現したい多要素認証／二要素認証の機能を自社開発する形です。　全くの私見ですが、コストに見合った成果や安全性が得られるかは微妙なところだと思います。
2	多要素認証／二要素認証のソフトウェアを導入	世の中に多要素認証／二要素認証の機能を提供しているソフトウェアがあるので、それを導入する形です。　適用したいソフトウェアが他社製だった場合、適用の可否から検討する必要があるなど留意点もあります。
3	シングルサインオンのソフトウェアを導入	弊社OpenAMもそうですが、シングルサインオンのソフトウェアには、多要素認証のための仕組みも備わっていることが多いです。　SAMLやOpenID Connectといった標準仕様によってアプリケーションと認証連携接続できるので、（将来のアプリ追加時も含め）アプリとの接続性という面でも比較的安心です。

3. 検討観点３：運用

パスワードのみの認証に比べ、多要素認証の運用は多かれ少なかれ複雑になります。
利用者にとって＆管理者にとって実用に耐えられる運用が可能か、という観点を早期に検討しておく必要があります。
運用検討が必要な主な点を以下に記します。

#	実現方法	内容
1	新規ユーザ作成時の運用	・発行時にユーザに渡さないといけないものは？（クライアント証明書？ハードウェアのワンタイムパスワード生成器？）・ワンタイムパスワードの鍵登録やFIDO2デバイスとの紐づけ登録を行う場合、どのように安全に行うか？（登録作業が可能な端末をIP等で制限する？1段階目パスワード初期化と合わせて時限的に行えるようにする？eKYCの実現？...etc） ...etc
2	平時の運用	・ハードウェアのワンタイムパスワード生成器を使用する場合、定期的な時刻調整や電池切れへの対応が必要。・クライアント証明書の場合は、証明書の有効期限への対応などが必要。・FIDO2デバイスの場合、利用しなくなった端末の紐づけ情報の削除や、新たに利用する端末の紐づけ手段の用意などが必要。・...etc
3	ユーザ端末紛失時の運用	・ユーザ自身または管理者による鍵情報などの削除手段などが必要。

4. おわりに

上記までに記してきましたように、多要素認証の検討にあたっては、「どのような多要素認証にするか」「どのように実現するか」「実用性に問題ない運用が可能か」など、様々な検討を行う必要があります。

詳細を詰めるのは弊社のような専門ベンダと一緒に行うとしても、まずは大枠でも良いので、これら観点での検討をしておくとスムーズにプロジェクトを進められると思います。