MFA 要素としての FIDO2
FIDO2 を MFA 要素ポリシーとして構成して、MFA を強制できます。
FIDO2 は、ユーザーが物理的なセキュリティキーまたは生体認証を使用して認証できるようにする、パスワードなしの認証標準です。従来の MFA 手法に代わるより安全な代替手段を提供し、フィッシングやその他のサイバー攻撃のリスクを軽減します。
FIDO2 要素ポリシーの機能拡張により、マルチファクター認証 (MFA) ポリシーに安全な認証方法が提供されます。FIDO2 を MFA 要素ポリシーオプションとして構成し、メールや SMS などの従来の方法と比較してより高いレベルのセキュリティを提供できます。
FIDO2 要素ポリシーを構成し、ユーザーが要素ポリシー条件を満たすと、 ServiceNow へのログイン時に、登録済みのハードウェアキーまたは生体認証をプロファイルにまだ追加していないユーザーに対して FIDO2 セットアップが表示されます。
登録が完了すると、ログインするための第 2 要素検証画面が表示されます。
注:
FIDO2 は、ユーザーが自己登録することもできます。自己登録方法の詳細については、「 ユーザープロファイルでのマルチファクター認証の設定」を参照してください。
主なメリット
FIDO2 を MFA 要素として使用する主なメリットは次のとおりです。
- 排他的なFIDO2認証
- 高権限のアカウントは、FIDO2 の強力な認証機能 (生体認証、パスキー、またはハードウェアセキュリティキー) を使用してのみ認証できるようにします。
- 安全性の低い方法の除外
- FIDO2 が唯一の一致するポリシーである場合、他の認証方法を抑制します。
- 強制登録
- まだ登録していない場合は、ユーザーに FIDO2 キーの登録を要求します。
- きめ細かな制御
- ポリシーベースのターゲティングを使用して、特定のロールまたはグループに厳密な適用を適用します。
より高いセキュリティ要素として、FIDO2 には排他的な適用機能があります。ユーザーに一致する唯一のポリシーである場合:
- 登録によって登録された他の要素を上書きします。
- ユーザーが登録されていない場合、FIDO2 登録を強制します。
- 排他的な認証オプションになります。
構成とユーザーの動作例
次の表は、ロールと登録済み要素に基づいてさまざまなユーザーシナリオがどのように処理されるかを示しています。
要素ポリシー条件の例:
- FIDO2 ファクトリポリシー:条件は「ITIL ロールは true である必要があります」です。
- メール 要素ポリシー:条件は「資産ロールは true である必要があります」です。
| ユーザーの例 | ロールあり | 登録済み要素 | 一致するポリシー | 動作 |
|---|---|---|---|---|
| アンドリュー・オック | ITIL | なし | FIDO2 | ユーザーは、FIDO2 のみを使用した MFA セットアップにリダイレクトされます。登録後は、FIDO2 が唯一の認証オプションです。 |
| abel.tuter | ITIL | 認証システム | FIDO2 | ユーザーが自己登録要素として認証システムを持っている場合でも、ユーザーは FIDO2 のみを使用した MFA セットアップにリダイレクトされます。 注: ユーザーが MFA 要素に登録していない場合、ユーザーは FIDO2 を使用した MFA セットアップにリダイレクトされます。 |
| aileen.motterm | 資産 | 認証システム | メール | ログイン時に [メール] と [認証システム] オプションが表示されます。ユーザーは、係数を選択するか、オプションで FIDO2 を登録することができます。 |
| エイブラハム・リンカーン | 資産、 ITIL | 認証システム | メールと FIDO2 | ログイン時に [メールと認証システム] オプションが表示されます。ユーザーは検証中に FIDO2 を登録できます。登録後、ユーザーは 3 つの要素すべてを表示できます。 |
FIDO2 を MFA 要素ポリシーとして構成することで、認証プロセスのセキュリティを大幅に強化できます。