はじめに
IAMの認証においてMFAを設定することはもはや常識と言っていいことであり、特にルートユーザーに関しては、設定をしていないとAWSコンソール上でも目立つところに警告が出続けることもあって、設定していない人はほぼいないでしょう。
しかし一方で、大半の人はMFAとして仮想MFA(Google Authenticator等)を利用していると思います。
実は、特にルートユーザーに対するMFAとしては、仮想MFAはあまり推奨されておらず、実際AWSは、CIS AWS Foundations Benchmarkにおいて、ルートユーザーへのMFAについて、仮想MFAではなくハードウェアMFAでの設定を、CriticalのSeverityで要求しております。
この背景にあるのは、最近ニュースレベルでも話題に上っている、仮想MFAを用いた多要素認証への攻撃手法の流行であり、ワンタイムコードの詐取や、セッションハイジャックといった手法を用いて、多要素認証を突破する例が散見されるようになっています。これら以外にも、例えば、仮想MFA用のシークレットキーの漏洩、といったケースも考えられます。
これらの課題への有効な対策として存在しているのが、ハードウェアMFA、特にTOTPのタイプではない、U2FタイプのハードウェアMFA、というわけです。
さて、U2FタイプのハードウェアMFAにはいくつかの種類がありますが、中でも有名どころといえばYubikeyが挙げられるでしょう。
本記事では、AWS IAMのMFAとして、特にルートユーザーのMFAとして、Yubikeyを利用する上での、FIDO周りの設定について述べたいと思います。
この記事で述べること
今年5月の、以下URLの変更の影響で、YubikeyをAWS IAMのMFAとして設定しようとするときにFIDO2検証要素の登録が要求されるようになってしまいました。
本記事では、件の変更以前と同様に、FIDO2検証要素の登録なしにYubikeyをAWS IAMのMFAと設定できるようにするための、YubikeyのInterfaces設定の変更について述べます。
FIDO U2FとFIDO2の違い
FIDO U2F(FIDO 1.0)とFIDO2(WebAuthn)の歴史的背景や、技術的な詳細は以下URLに詳しいですが、ユーザー目線からの大きな特徴で言うと、「ユーザー検証が認証器(オーセンティケータ)側で完結するか = パスワードレスに繋がるか」ということがポイントになります。
Webサービスにおけるパスワードは、常に漏洩のリスクにさらされている、パスワード文字列はどこからでも利用可能である、といった課題から、一定以上の長さの要求等のパスワードポリシーの順守や、使いまわしの制限、定期的な変更、といった負荷の高い運用を余儀なくされます。
一方、FIDO2では、(Yubikey自体の所有という)所有の要素以外の要素として、記憶の要素を利用する場合でも、ユーザー検証が認証器に密接に紐づいており、かつ認証器側で完結する、といった特性上、従来のパスワードのような長い文字列による定義は不要で、短い簡単なPINでもリスクが低くなります。また、所有以外の要素として生体の要素が利用できるYubikey Bioなどのデバイスでは、認証における記憶の要素がない、完全なパスワードレスを達成できます。
AWS IAMにおける「WebAuthn対応」の特徴
とはいえ、こと2022/12/20現在において、AWS IAMにおける「WebAuthn対応」においては、こうしたFIDO2の恩恵をほぼ受けることができません。
まず、FIDO2が有効な状態のYubikeyをMFAとして設定したとしても、AWS IAMのパスワード入力が不要になるわけではありません。Yubikeyの設定後も、そのIAMでのAWSコンソールへのログインには、引き続き同じパスワードの入力が必要です。
そして、更に問題なのは、「FIDO2が有効な状態のYubikeyをAWS IAMのMFAとして設定する」際に「MFAとしての初回の設定時には、(そのYubikeyにFIDO2検証要素の登録がまだなされていない場合には)FIDO2検証要素の設定が要求される」にも関わらず、当該IAMでの次回からのログインでは、せっかく設定したFIDO2検証要素が要求されることなく、(IAMのIDとパスワードと)Yubikeyの所有の要素だけでログインができてしまうことです。
これは、今年5月の、こちらの変更以前の、FIDO U2Fのみの対応であった際の挙動と全く同じです。
※ちなみに、例えばAzure ADなど、他サービスのFIDO2機能では、Yubikey等セキュリティキーでの認証の際には、FIDO2検証要素を要求されるようになっています。
更に、登録したFIDO2検証要素の意味がない、という問題だけでなく、追加で大きな問題となることが、特に記憶の要素であるPINを利用する、Yubikey Bio以外のYubikeyを利用するケースにおいて存在します。
先述のAzure ADなど、他の対象に同一のYubikeyをFIDO2として利用する場合は良いのですが、仮にYubikeyをAWS IAMのMFAとしてのみ利用する場合、FIDO2 PINは「設定したのに全く利用されることがない状況」(例えば、BCP訓練の一環として、「ルートユーザーでのログイン」を用意しているとしても、そもそもFIDO2 PINは要求されない)となってしまいます。これはすなわち、FIDO2 PINを紛失する、忘れる可能性が高くなる、ということです。
そして、将来的に別の用途に当該Yubikeyを利用しようとした際、もしくは、AWS IAMの仕様がよりWebAuthnの仕様に即した仕様に変更された際等に、FIDO2 PINが分からない、という形で問題が顕在化します。
FIDO2 PINが分からなくなったYubikeyはリセットすることが可能ですが、リセットを行うと、当該Yubikeyで設定した全サービスに対する認証情報が削除されることとなります。
AWSのルートユーザーを初め、特に特権ユーザーにおけるMFAの再設定は得てして面倒なものです。
これらの事情から、2022/12/20現在においては、AWS IAMに対するMFAの用途のみでYubikeyを利用する場合には、利用しないFIDO2 PINの登録を行わないためにも、FIDO2を無効化して利用する方が望ましいと言えます。
YubikeyでFIDO2 Interfaceを無効化する方法
さて、YubikeyでFIDO2を無効化する方法ですが、Yubikey Managerというソフトウェアを利用します。Yubikey Managerは、Yubikeyの提供元であるYubico社のWebサイトからダウンロードできます。
https://www.yubico.com/support/download/yubikey-manager/
Yubikey Managerは、WIndows用、macOS用、Linux用が用意されております。
次に、端末のUSB端子にYubikeyを挿入し、OSにYubikeyが認識されたらYubikey Managerを起動します。
Interfacesタブをクリックし、Interfaces設定を開きます。
USB及びNFCの「FIDO2」のチェックを外し、右下"Save Interfaces"をクリックします。
NFC機能がないYubikeyでは、以下のようにUSBのみの設定が表示されます。
https://www.pentio.com/yubikey/support/fido2/#step1-1
"Configured interfaces"とバナーが出たら完了です。
この状態になれば、このYubikeyはFIDO2 Keyとしての機能は無効化され、FIDOのプロトコルについては、チェックがついているFIDO U2Fとしての機能のみ有効な状態です。
なので、AWS IAMのMFAとして設定する際に、FIDO2 PINの設定の要求がなされなくなります。
最後に
本記事では、AWS IAMにおけるYubikeyの活用について述べてまいりました。先述の通り、確かに仮想MFAの課題は顕在化しつつあり、その対策としてFIDOは有効なのですが、AWS IAMにおけるFIDO対応の課題の一つに、Yubikey等のセキュリティキーでの認証にしか対応していない、ということがあります。
組織等で複数のAWSアカウントを運用するようなケースで、かつAWSアカウントの管理者が複数存在するようなケースでは、Yubikey自体の調達コストもかかりますし、またYubikeyという追加の物理デバイスを管理する体制も必要になります。
FIDO2の認証器の選択肢としては、外付け認証器であるセキュリティキーの他にも、プラットフォーム認証器として、Windows Helloであったり、Andorid/iOSデバイスでのPassKeyの利用、といった、ユーザーが既に利用中である可能性が高いデバイスへ組み込まれた仕組みが存在します。
競合他社では既にこれら仕組みに対応しているサービスも多く、かつ、実はAWSでも、AWS IAM Identity Center(旧AWS SSO)では既に、多要素認証でこれらの仕組みに対応していたりします。
AWS IAMにおいても、安全な環境を利用者がより低コストで実現できるように、という観点からも、ぜひセキュリティキー以外のFIDO2認証器にも対応を進めていただきたいな、と、本記事を記載する中で改めて思った次第です。
また、本記事では、AWS IAMにおけるWebAuthen対応における課題と、その前提でのFIDO2利用の意味の薄さ、更にYubikeyでのFIDO2 Interfaceの無効化の方法を紹介してまいりましたが、そもそも、「では果たしてAWS IAMのWebAuthn対応とは一体何なのか。WebAuthn対応により何が変わったのか」「実際の認証で使われないFIDO2 PINの設定が、なぜ初回のMFA設定時には要求されてしまうのか」といった疑問が浮上してまいります。
現在、これらの点について、AWSサポートに現在問い合わせを行っておりますので、回答が得られ次第本記事に追記いたします。