こんにちは、クラウド活用推進担当の榊原です。今回もよろしくお願いします。
現在、AWSへのログインの際、MFAを実施していますが、ログイン時にこんな画面が出てきます。
認証アプリを用いたTOTPの検証です。
普段はここにGoogle AuthenticatorやOkta Verifyで表示される数字を入力してログインしています。
しかし公式ドキュメントを眺めていたら、セキュリティキーや組み込み認証ツールといった方式が使えるとの記載を発見しました。
参考：Registering your device for MFA
ということで今回は、セキュリティのさらなる強化のため、AWS IAM Identity Centerでセキュリティキーと組み込み認証ツールでのMFAを有効化し、従来の認証アプリと合わせて3つのMFA方式を比較検証してみました。
まずはじめに、簡単にMFAについてまとめておきます。
MFAは複数の認証要素を組み合わせることでセキュリティを強化する仕組みです。
使用可能な認証要素は以下の3つがあります。
AWS IAM Identity Centerでは以下の3つのMFA方式が利用可能です。
スマートフォンやタブレット等にインストールされた認証アプリケーションを使用する方式です。
基本的にTOTP(Time-based One Time Password)が使用され、認証時にはアプリで表示される6桁の認証コードを入力することで所有物認証を行います。
メリット: スマホ等のデバイスがあれば使用可能なため利用のハードルが低い
デメリット: フィッシング攻撃や中間者攻撃への耐性が低い
Authenticator: Google Authenticator, Microsoft Authenticator, Okta Verify など
FIDO(Fast Identity Online)に準拠した外付けハードウェアセキュリティデバイスを使用する方式です。
FIDO2やFIDO U2F(Universal 2nd Factor)に対応したセキュリティキーを使用することで、所有物認証を行います。使用するセキュリティキーによっては、生体認証などを組み合わせることも可能です。
メリット: 公開鍵認証方式によりフィッシング等の攻撃への耐性があり、認証強度が高い
デメリット: 物理デバイスを用意する必要がある
Authenticator: YubiKey, Feitianデバイス, Google Titan Security Key など
クライアントデバイスに組み込まれた認証システムを使用する方式です。
セキュリティキーと同様にFIDO互換のシステムで認証を行います。デバイス内蔵の認証機能が知識情報や生体情報の認証をサポートする場合、それらを組み合わせた認証が可能です。
メリット: 別のデバイスを用意する必要がなく、利便性が高い
デメリット: クライアントデバイスが複数ある場合、デバイスごとに登録する必要がある
Authenticator: Windows Hello, Apple TouchID など
実際にAWS IAM Identity Centerでセキュリティキーと組み込み認証ツールの使用をアクティブにし、
動作を確認してみます。
検証環境
クライアントデバイス: Lenovo ThinkPad L13 Gen4 21FHS1GJ00
OS: Windows 11 Pro 24H2
ブラウザ: Microsoft Edge version 140.0.3485.81
1. AWS IAM Identity Centerにアクセスします
2. 設定の認証タブを選択し、多要素認証の設定を開きます
3. MFA設定のユーザーはこれらのMFAタイプで認証できますにある、セキュリティキーと組み込みの認証ツールにチェックを入れて設定を変更します
4. 設定が変更されると、多要素認証のMFAの入力を求められた場合にセキュリティキーと組み込みの認証ツールが追加されていることを確認できます
設定が完了したので、実際にAuthenticatorの登録・認証を試してみます。
ここではAuthenticatorとしてYubiKey 5Cを使用します。
YubiKey 5CはPINでの認証のみサポートしており、生体認証機能を持たないセキュリティキーです。
1. AWS access portalで、ユーザ名>セキュリティを選択します
2. セキュリティページでデバイスを登録を選択します
3. MFAデバイスの登録画面に遷移します。設定が変更されているため、認証アプリに加えて、セキュリティキーと組み込みの認証アプリが選択できます。ここではセキュリティキーを選択し次へ
4. するとWindowsセキュリティから認証情報の保存場所を聞かれるので、セキュリティキーを選択して次へ
5. 表示される内容を確認しながら進んで……
6. この画面が表示されたら、指示通りセキュリティキーをUSBポートに挿入します
7. YubiKey 5CのPINを入力してOK
8. キーにタッチして保存されたことが確認出来たらOK
9. これで登録完了です
1. 通常通り、ユーザ名とパスワードを入力します
2. パスワードの検証が完了すると、自動的にAuthenticatorの選択画面が表示されます。セキュリティキーを選択して次へ
3. 指示に従いセキュリティキーを挿入してタッチすると、認証が完了しAWSへサインインできます
次に組み込み認証ツールの確認をします。
AuthenticatorとしてWindows Helloを使用します。
1. MFAデバイスの登録画面で組み込み認証アプリを選択します
2. Windows Helloで設定済みの方式で認証します。ここではPINを使っています
3. 検証が完了すると、認証情報が保存されます
4. これで登録完了です
1. 通常通り、ユーザ名とパスワードを入力します
2. パスワードの検証が完了すると、Windows Helloの認証画面が表示されます
3. 問題なければWindows Helloでの認証を行い、完了するとAWSへサインインできます
これまで使っていた認証アプリでのMFAに加え、
セキュリティキー、組み込み認証ツールでのMFAを試してみました。
ここからは実際に試してみての使用感をまとめていこうと思います。
これまで使用していた方式です。今回試した3つの方式では、最も普及しているかと思います。
セキュリティの観点では気になる点がある方式ですが、他の2つの方式を登録後、デフォルトでTOTPの入力を求められなくなったので、AWS側としても優先順位は下げているように感じられました。
メリット:
表示された数字を打ち込むだけということで非常にわかりやすく、誰でも迷わず使える方式です。
スマートフォンさえあれば使用可能で、設定も簡単なのは大きなメリットだと思います。
また導入コストが低く、企業アカウントと連携可能な場合もあるため、全社展開等に向いている方式だと言えます。
デメリット:
他2つの方式と比較してセキュリティ的に脆弱であることは、無視できないデメリットです。使用の際にはフィッシング攻撃などに十分注意する必要があります。
またセキュリティ上の理由でスマートフォンやタブレットの持ち込みができず、認証アプリが使用できないケースも考えられます。この場合は別の方式の検討が必要です。
加えて、スマートフォンの機種変更時には認証アプリのデータ移行かMFAの再設定が必要になる点には気を付けなければなりません。
しかし最も頻繁に感じるデメリットは、MFAのたびにスマホを取り出す手間がかかったり、文字を打ち込む手間がかかったりすることだと思います。アプリを起動するワンアクションすらめんどくさいこともしばしば……
今回新たに追加・検証した方法その1です。
登録時にはPINの入力を求められましたが、認証時にはキーにタッチするだけでPINの入力は不要でした。これはすでにパスワード認証によって知識情報の認証を完了しているため、FIDO U2Fとして所有物認証のみを実施していると考えられます。
メリット:
メリットとしては何といっても認証強度の高さです。NIST SP800-63Bで定義される認証強度では、最高レベルのAAL3に割り当てられます。
また組み込み認証ツールと異なりAuthenticatorが物理デバイスとして独立しているため、登録時とは別のクライアントデバイスでも同じ認証強度のMFAを実施できます。出社とテレワークで別端末を使っている場合などに有効です。あとガジェット感がかっこいい。
デメリット:
最大のデメリットは、セキュリティキーは誰もが所有しているわけではないことです。
今回使用したYubiKey 5Cで1万円ほど。指紋認証可能なタイプになると2万円を超えることも……。
仮にこの方式を全社展開しようとすると、デバイスのコストだけでなく管理のコストや、故障・紛失時の対応など、多くの問題が想定できます。
またセキュリティキーはインタフェースの制約がつきものなので、クライアントデバイスとセキュリティキーの組み合わせによっては使えないこともあります。
今回新たに追加・検証した方法その2です。
この方式が設定されている状態でMFAを実施しようとすると、認証方式の選択なしに組み込み認証ツールの認証画面が表示されました。
メリット:
すでにデバイスに組み込まれた認証ツールを使えるため、別デバイスを用意する必要がなく、すぐに使用できます。
デバイスが対応していれば指紋認証・顔認証といった生体認証も使用可能で、認証強度を高められます。
別デバイスの操作が不要な分、他の2つの方式と比較して認証にかかるステップが少なく、ユーザの負荷が小さい方式だと思います。
デメリット:
デメリットとして、基本的にデバイスに依存することがあげられます。別デバイスで同じユーザの認証がしたい場合、他の認証方式でMFAを行うか、事前に各デバイスで個別登録しておく必要があります。
しかしデバイスへの依存を和らげようとiCloud Keychain等への同期を行うと、デバイス固有の情報ではなくなるため認証強度が低下してしまいます。
最後に3つのMFA方式について、独断と偏見で総合評価をつけてみます。
| 項目 | 認証アプリ | セキュリティキー | 組み込み認証ツール |
|---|---|---|---|
| セキュリティレベル | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 利便性 | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 設定の簡単さ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| 導入コスト | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ |
| フィッシング耐性 | なし | あり | あり |
| 総合評価 | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
AWS IAM Identity CenterでのMFA方式の追加を行い、実際に試してみての使用感をまとめてみました。
MFAと一口に言っても方式はさまざまで、利便性や認証強度にも違いがありました。
ここで重要なのは、MFA方式は複数用意しておくことです。
今回は組み込み認証ツールがもっとも総合評価が高い方式としましたが、この方式にも弱点はあります。
デバイスがすぐに使えない場合、故障したら？紛失したら？などなど。そうした状況でもリカバリできるように、複数の方式を登録しておきましょう。
