マルチファクター認証 (MFA) の適用に関する FAQSummary 目次 MFA 適用要件 – 内容と理由 MFA とは?MFA の適用が義務付けられているのはなぜですか?MFA を有効にすることが重要なのはなぜですか?ServiceNow で MFA が必要な理由既存の顧客の MFA 要件は何ですか?新規顧客の MFA 要件は何ですか?組織には、既存の企業 MFA ソリューションによって提供される MFA を使用する権限があります。ServiceNow MFA を使用する理由 MFA の適用範囲: MFA が必要なユーザー、ログイン、環境タイプはどれか?シングルサインオン (SSO) ログインに MFA は必要ですか?外部ユーザー (snc_external ロールを持つユーザー) には MFA が必要ですか?モバイルアプリのログインに MFA は必要ですか?準本番環境とテスト環境に MFA は必要ですか?開発者インスタンスに MFA は必要ですか?API 認証/統合に MFA は必要ですか?MFA によるクローンセットアッププロセスへの影響はありますか?MFA による更新セットの取得に影響はありますか?ServiceNow インスタンスにアクセスする RPA ボットに影響はありますか?OAuth ベースの統合に MFA は必要ですか?オンプレミス、セルフホスト型、規制対象の市場環境に MFA は必要ですか? MFA 適用タイムライン MFA はいつ施行されますか?MFA の適用タイムラインを調整するにはどうすればよいですか?この今後の変更についてエンドユーザーにどのように通知されますか?エンドユーザーがログインしたときに、MFA セットアップの完了に関するメッセージをオフにするにはどうすればよいですか?MFA の適用に関してアドミニストレーターに表示されるメッセージをオフにするにはどうすればよいですか?インスタンスにおける組織のセキュリティニーズに基づいて、適応認証を使用して MFA ポリシーを既に定義しています。この義務化はインスタンスに影響しますか? さまざまな MFA タイプ MFA ではどのようなタイプの検証方法を使用できますか?ユーザーは複数の MFA 要素/検証方法を設定できますか?MFA セットアップを完了するために、ユーザーはどのような手順を実行する必要がありますか?SMS とメールの OTP ベースの MFA を特定のユーザーのみに制限することはできますか?ユーザーは、認証アプリを設定できる携帯電話を持っていません。これらのユーザーが MFA を有効にするにはどうすればよいですか?エンドユーザーが MFA を設定するにはどうすればよいですか? MFA 控除 特定のユーザーに対してMFAの義務を緩和するにはどうすればよいでしょうか?特定の役割についてMFAの義務をどのように緩和できますか?特定のグループに対してMFAの義務を緩和するにはどうすればよいでしょうか?信頼できるネットワークに対する MFA の義務をどのように緩和できますか?信頼できる場所に対する MFA の義務をどのように緩和できますか?MFA の適用頻度を制御できますか?複数のユーザーが共有するアカウントでは、MFA はどのように機能しますか? MFA リセット 認証アプリのセットアップが失われました。どうすればリセットできますか?MFA によるアドミンのロックアウトを防ぐにはどうすればよいか? MFA アダプション MFA が行われていないローカルログインの数を確認するにはどうすればよいですか? 1.MFA 適用要件 – 内容と理由 MFA とは? MFA (マルチファクター認証) は、ユーザーがアカウントまたはシステムにアクセスする前に、2 つ以上の形式の検証を提供することを要求するセキュリティプロセスです。単なるパスワードを超えた追加の保護層と考えてください。 たとえば、銀行口座にオンラインでログインした場合、MFA はパスワードの入力 (知っているもの) と、電話に送信されたコード (持っているもの) を確認するように求められる場合があります。そうすれば、たとえ誰かがあなたのパスワードを知っていたとしても、あなたの携帯電話を持っていなければ、あなたのアカウントにアクセスすることはできません。 MFAを使用すると、権限のないユーザーがアカウントに侵入しにくくなり、個人情報を保護し、アカウントの安全性を高めることができます。 MFA の適用が義務付けられているのはなぜですか? Facebookでは、アカウントとデータを可能な限り安全にするために、MFAの義務化を実施しています。サイバー脅威は絶えず進化しており、パスワードだけでは不正アクセスから保護するにはもはや十分ではありません。 MFA では、誰かがパスワードを推測したり盗んだりした場合でも、ログインするには、携帯電話のコードや指紋スキャンなど、2 番目の形式の検証が必要です。この追加レイヤーは、ほとんどの不正な試行をブロックし、情報をより安全に保つのに役立ちます。 MFA をデフォルト設定にすることで、セキュリティ侵害のリスクを軽減し、デフォルトでアカウントが保護されるため、追加のセキュリティを選択することなく、安心感を高めることができます。 MFA を有効にすることが重要なのはなぜですか?ServiceNow で MFA が必要な理由 MFA を有効にすると、アカウントのセキュリティが大幅に強化されるため、MFA を有効にすることが不可欠です。多くの場合、パスワードだけではアカウントを完全に保護するには不十分です。それらは推測されたり、盗まれたり、データ侵害で公開されたりする可能性があり、個人情報を危険にさらします。MFAでは、誰かがあなたのパスワードを知ったとしても、その2番目の認証フォームなしではあなたのアカウントにアクセスすることはできません。 この種の脅威からユーザーを保護するために MFA が必要です。これは、アカウントへの不正アクセスの可能性を減らすためのシンプルかつ強力な方法です。MFAを義務付けることで、すべてのアカウントに強力な保護レイヤーが用意され、あなたとプラットフォーム上のすべての人のセキュリティリスクが軽減されます。 既存の顧客の MFA 要件は何ですか? インスタンスを Yokohama 以降のリリースにアップグレードする 既存の顧客 の場合: インスタンスで 適応認証 - MFA コンテキストポリシー がまだオンになっていない場合は、デフォルトの MFA ポリシーが自動的に有効になります。 つまり、ローカル認証または LDAP 認証を使用してログインするすべての内部ユーザー (snc_externalロールを持たないユーザー) は、最初のログイン成功から 30 日以内に MFA を設定する必要があります。この間、ユーザーは通常どおりログインできますが、ログイン時に MFA への登録を求めるメッセージが表示されます。 30 日が経過すると、デフォルトで MFA が要求され、ユーザーは MFA セットアップを完了しないとログインできなくなります。 Acme Corp のシナリオ 1 の例:現在、インスタンスにはアクティブな MFA ポリシーがありません。Sarah がローカル認証を使用してインスタンスにアクセスするとします。Yokohama リリースにアップグレードすると、ログイン時に MFA の登録に関するメッセージが表示されます。彼女はこのセットアップを完了するために 30 日間の猶予があります。そうしない場合、30 日後、彼女のアカウントにログインするには MFA が必要になり、MFA が設定されるまでアクセスできなくなります。 Acme Corp のシナリオ 2 の例:同じインスタンスで、Anita は既にローカル認証とともに MFA を 使用 していました。彼女は、30日間の自己登録期間なしでMFAを引き続き要求します。 Acme Corp のシナリオ 3 の例:同じインスタンスで、Olivia は認証に SSO を使用します。彼女のログインエクスペリエンスへの影響はなく、MFA は適用されません。 Globex Corp のシナリオ 4 の例:Globex ServiceNow インスタンスには、会社の信頼できるネットワーク外でのすべてのローカルログイン試行に MFA を要求する MFA ポリシーが既に存在します。Yokohama 以降のリリースにアップグレードすると、ユーザーログインの MFA 強制動作はアップグレード前と同じままです。 新規顧客の MFA 要件は何ですか? Yokohama 以降のリリースでプロビジョニングされたインスタンスでは、初日からローカル認証または LDAP 認証でログインするすべての内部ユーザー (snc_externalロールを持たないユーザー) に対して、デフォルトで MFA が有効になります。つまり、SSO なしでログインする内部ユーザーは、最初のログインから MFA を設定して使用する必要があります。 組織には、既存の企業 MFA ソリューションによって提供される MFA を使用する権限があります。ServiceNow MFA を使用する理由ほとんどの企業の MFA ソリューションは、シングルサインオン (SSO) ログインを保護するように設計されています。ただし、ServiceNow では、企業の MFA ソリューションでは保護されていないローカルのユーザー名とパスワードを使用してログインすることもできます。ServiceNow MFA ポリシー は、特にローカルユーザー名とパスワードベースのログイン用にセキュリティレイヤーを追加することで、既存の MFA プロバイダーを補完します。これにより、アカウントの認証情報が侵害された場合でも、不正アクセスが防止されます。ServiceNow MFA を使用すると、エンドユーザーは次のことができます。 既存の認証アプリを使用してTOTP ベースの MFA を構成します。パスキーや生体認証装置などの最新の認証方法を活用して、シームレスなログインエクスペリエンスを実現します。 2.MFA 適用範囲 MFA が必要なユーザー、ログイン、環境タイプはどれか? Yokohama リリース以降、新しいデフォルトのセキュア MFA ポリシーにより、MFA は snc_externalロールを持つユーザーを除くすべてのユーザーユーザー名とパスワードベースのローカル認証または LDAP 認証を実行している場合も同様です。このポリシーは、アップグレード前にアクティブな MFA ポリシーがまだなかったすべての顧客インスタンス (本番インスタンス、準本番インスタンス、テストインスタンスを含む) に対して適用されます。 インスタンスアドミンは、MFA コンテキストポリシー、ポリシー基準、またはポリシー条件を変更することで、適用スコープを変更できます。 シングルサインオン (SSO) ログインに MFA は必要ですか? いいえ。デフォルトの安全な MFA ポリシーでは、SSO (SAML、OIDC、証明書ベースの認証 など) ログインに MFA は必要ありません。 お客様は、シングルサインオン (SSO) プロバイダー (ID プロバイダーまたは IdP) と協力して、IdP 側でマルチファクター認証 (MFA) を適用できます。IdP 側で MFA を適用できない場合は、提供されている こちら) の指示に従って、SSO ログイン用の ServiceNow プラットフォームの MFA を有効にすることもできます。 外部ユーザー (snc_external ロールを持つユーザー) には MFA が必要ですか? いいえ。デフォルトのセキュア MFA ポリシーでは、snc_external ロールを持つユーザーに MFA は必要ありません。 アドミニストレーターは、MFA ポリシー条件を更新することで、この動作を変更し、外部ユーザーに MFA を適用できます。Yokohama へのアップグレード以降のリリース前に既に MFA を受けている外部ユーザーは引き続き MFA を利用できます。外部ユーザーは自分のプロファイルにアクセスして、MFA を自分で登録できます。 モバイルアプリのログインに MFA は必要ですか? はい。MFA ポリシーは、ユーザー名とパスワードベースの非 SSO ログインを使用した Web アプリとモバイルアプリの両方のログインに適用されます。 準本番環境とテスト環境に MFA は必要ですか? はい。Yokohama 以降のバージョンにアップグレードする前にアクティブな MFA ポリシーがインスタンスに存在しない場合、MFA は本番環境、準本番環境、開発環境、およびテスト環境を含むすべての顧客インスタンスに適用されます。 開発者インスタンスに MFA は必要ですか? はい。MFA は、Yokohama 以降のリリースバージョンのすべての開発者インスタンスに適用されます。 API 認証/統合に MFA は必要ですか? いいえ。Yokohama 以降のリリースでは、MFA はユーザー名とパスワードベースのインタラクティブなユーザーログインにのみ必要です。つまり、ベーシック認証を使用した API 認証は MFA を必要とせずに機能します。OAuth や mTLS などの安全な代替の API 認証方法を使用することを強くお勧めします。 MFA によるクローンセットアッププロセスへの影響はありますか? いいえ。クローンセットアッププロセスは引き続きユーザー名とパスワードで動作し、MFA は必要ありません。 MFA による更新セットの取得に影響はありますか? いいえ。更新セットの取得はユーザー名とパスワードで引き続き機能し、MFA は必要ありません。 ServiceNow インスタンスにアクセスする RPA ボットに影響はありますか? RPA ボットがユーザー名とパスワードの対話型ログインを使用して ServiceNow インスタンスにアクセスすると、強制的に MFA が適用されます。アドミニストレーターは、RPA ボットアカウントの MFA を緩和したい場合、RPA ボットアカウントを MFA 適用対象外ユーザーグループ に追加できます。 OAuth ベースの統合に MFA は必要ですか?OAuth リソース所有者のパスワード認証情報 (ROPC) は、MFA を必要とせずにユーザー名とパスワードで動作します。ただし、認証コード権限許可タイプの場合、OAuth に同意する前に、ユーザーログインフローの一部として MFA が必要になります。オンプレミス、セルフホスト型、規制対象の市場環境に MFA は必要ですか? はい、MFA の義務はオンプレミス、セルフホスト型、および規制された市場環境でホストされるインスタンスを含むすべてのインスタンス適用されます 3.MFA 適用タイムライン MFA はいつ施行されますか? MFA ポリシーに従い、MFA セットアップを完了していない対象ユーザーには、30 日間の自己登録期間が与えられます。これは、システムプロパティ glide.authenticate.multifactor.self_enrolment_period を使用して制御されます。プロパティのデフォルト値は 30 日です。最大 90 日間まで更新できます。 ローカル認証または LDAP 認証を使用してログインするすべての内部ユーザー (snc_externalロールを持たないユーザー) は、最初のログイン成功から 30 日以内に MFA を設定する必要があります。この間、ユーザーは通常どおりログインできますが、ログイン時に MFA への登録を求めるメッセージが表示されます。 Yokohama 以降のリリースにアップグレードしてから 90 日後、内部ユーザー (snc_external ロールを持たないユーザー) がローカル認証または LDAP 認証で初めてログインした場合、すぐに MFA を使用する必要があります。これらのユーザーには、30 日間の MFA 自己登録期間はありません。この期間は、システムプロパティ glide.authenticate.multifactor.enforcement.max_relaxation_period によって管理されます。このプロパティの最大値は 270 日です。 MFA の適用タイムラインを調整するにはどうすればよいですか? アドミニストレーターは、プロパティ glide.authenticate.multifactor.self_enrolment_periodの値を更新することで、自己登録期間を増減できます。このプロパティ値を 0 に設定すると、ユーザーは Yokohama 以降のリリースにアップグレードした後、ローカルログインまたは LDAP ログインで最初のログイン試行後に MFA セットアップを完了する必要があります。自己登録期間の最大期間は 90 日間です。90 より大きいプロパティ値は 90 として扱われます。プロパティ glide.authenticate.multifactor.enforcement.max_relaxation_period の値を更新することで、 アドミニストレーターは、Yokohama 以降のリリースへのアップグレード後何日後にユーザーが MFA 自己登録ウィンドウを取得するかを決定できます。 この今後の変更についてエンドユーザーにどのように通知されますか? ローカル認証または LDAP 認証を実行するエンドユーザー (MFA が適用されます) は、ログイン後に情報メッセージが表示されます。ユーザーが自分のプロファイルにアクセスしたときにも、同じメッセージが表示されます。 プラットフォームユーザープロファイル 従業員サービスセンター (ESC) ユーザープロファイル このメッセージは、SSO ログインを実行しているアドミン以外のユーザーには表示されません。 admin ロールを持つユーザーには、ログインに使用された認証方法に関係なく、ログイン成功後に異なる情報メッセージが表示されます。 このメッセージは、アドミンユーザーの 1 人が以下のプロパティ値を true に設定して更新を確認するまで表示され続けます。 glide.authenticate.multifactor.enforcement.acknowledged エンドユーザーがログインしたときに、MFA セットアップの完了に関するメッセージをオフにするにはどうすればよいですか? アドミニストレーターは、以下のシステムプロパティの値を false に更新して、ログイン時にエンドユーザーに表示される MFA 登録情報メッセージをオフにすることができます。 glide.authenticate.multifactor.enforcement.show_user_info_message MFA の適用に関してアドミニストレーターに表示されるメッセージをオフにするにはどうすればよいですか? ログイン時にアドミンユーザーに表示される MFA の適用に関する情報メッセージは、アドミンユーザーの 1 人が以下のシステムプロパティの値を true に更新して確認すると表示されなくなります。 glide.authenticate.multifactor.enforcement.acknowledged インスタンスにおける組織のセキュリティニーズに基づいて、適応認証を使用して MFA ポリシーを既に定義しています。この義務化はインスタンスに影響しますか? いいえ。インスタンスに既にアクティブな 適応認証 - MFA コンテキストポリシー がある場合、新しいデフォルトの安全な MFA ポリシーは適用されません。 インスタンスで MFA プロパティが有効になっている (glide.authenticate.multifactor) が、MFA ポリシーがアクティブではなかった とします。その場合、ユーザー名とパスワードベースのローカルまたは LDAP ログインを実行するすべての内部ユーザー (snc_external ロールを持たないユーザー) に MFA を適用するための、デフォルトの安全な MFA ポリシーが有効になります。 4.さまざまな MFA タイプ MFA ではどのようなタイプの検証方法を使用できますか? ServiceNow プラットフォームでは、以下の検証方法が標準でサポートされています。 パスキーGoogle Authenticator Okta Verify、 Microsoft Authenticator、Authy、DUO などの TOTP 準拠の認証アプリWindows Hello、Apple Touch ID、Face ID、Android 指紋センサーなどの生体認証システム (FIDO2)。YubiKey、Thetis などのハードウェアセキュリティキー (FIDO2) メール OTPSMS OTP:SMS OTP ベースの MFA を有効するには、SMS com.snc.authentication.sms_mfa プラグインを使用したマルチファクター認証と要素構成が必要です。 ユーザーは複数の MFA 要素/検証方法を設定できますか? ユーザーは、自分のユーザープロファイルにアクセスして、複数の MFA 要素を登録できます。たとえば、ユーザーはラップトップの生体認証装置を登録し、携帯電話をパスキーとして使用し、認証アプリをセットアップできます。 MFA セットアップを完了するために、ユーザーはどのような手順を実行する必要がありますか? セットアップ手順の詳細については、「 MFA セットアップ - 製品ドキュメント を参照してください。 SMS とメールの OTP ベースの MFA を特定のユーザーのみに制限することはできますか? アドミニストレーターは、メールおよび SMS OTP ベースの MFA 要素の MFA 要素ポリシーを設定して、これらの要素を特定のユーザーグループ/ロールに制限できます。詳細については、こちらの制作ドキュメントを参照してください。 ユーザーは、認証アプリを設定できる携帯電話を持っていません。これらのユーザーが MFA を有効にするにはどうすればよいですか? Xanadu リリース以降、ユーザーは携帯電話で認証アプリをセットアップしなくても、生体認証装置、パスキー、FIDO2 ハードウェアセキュリティキー、メール OTP ベースの MFA を使用できます。 エンドユーザーが MFA を設定するにはどうすればよいですか? セットアップ手順の詳細については、「 MFA セットアップ - 製品ドキュメント を参照してください。 5.MFA 控除 特定のユーザーに対してMFAの義務を緩和するにはどうすればよいでしょうか? Yokohama リリースの一環として、新しいユーザーグループ「MFA 適用対象外ユーザーグループ」が追加されました。 MFA ポリシーに追加したデフォルトの条件に基づいて、このグループのメンバーであるユーザーは MFA の適用されません。 そのため、ユーザーを MFA の適用対象外にしたい場合は、そのユーザーを「MFA 適用対象外ユーザーグループ」に追加できます。 ステップ 1:ナビゲーターで「MFA コンテキスト」を検索します。MFA コンテキストレコードに関連付けられたステップアップ MFA ポリシーは、「非 SSO ログインに MFA を強制する」である必要があります ステップ 2:[ポリシー入力] 関連リストで、[MFA 適用対象外グループのメンバーである] フィルター基準レコードをクリックします。 ステップ3:グループリストの「MFA適用対象外ユーザーグループ」をクリックします。 ステップ 4:ユーザーをメンバーとしてこのグループに追加して、MFA の適用を免除します。 注: MFA コンテキストに関連付けられた別のポリシーがある場合は、「MFA 適用対象外グループのメンバーである」フィルター基準をポリシーに追加し、このグループのユーザーを MFA の適用から除外するようにポリシー条件を変更できます。 特定の役割についてMFAの義務をどのように緩和できますか? Yokohama リリースの一環として、空の新しいロールフィルター基準 [MFA 免除ロールあり] が追加されました。また、免除されたロール基準のロール部分を持つユーザーを MFA の適用から除外する条件を MFA ポリシーに追加しました。 ステップ 1:ナビゲーターで「MFA コンテキスト」を検索します。MFA コンテキストレコードに関連付けられたステップアップ MFA ポリシーは、「非 SSO ログインに MFA を強制する」である必要があります。 ステップ 2:[ポリシー入力] 関連リストで、[MFA 適用対象外ロールあり] フィルター基準レコードをクリックします。 条件に追加するロールを追加します。OR 演算子を使用して複数のロールを追加できます。 注: MFA コンテキストに関連付けられた別のポリシーがある場合は、[MFA 適用対象外ロールあり] フィルター基準をポリシーに追加し、ポリシー条件を変更して、ロールが免除されているユーザーを MFA の適用から除外することができます。 特定のグループに対してMFAの義務を緩和するにはどうすればよいでしょうか? Yokohama リリースの一環として、新しいユーザーグループ「MFA 適用対象外ユーザーグループ」が追加されました。 MFA ポリシーに追加されたデフォルトの条件に基づいて、このグループのメンバーであるユーザーまたはグループは MFA の適用されません。 そのため、グループを MFA の適用対象外にしたい場合は、そのグループを「MFA 適用対象外ユーザーグループ」に追加できます。 ステップ 1:ナビゲーターで「MFA コンテキスト」を検索します。MFA コンテキストレコードに関連付けられたステップアップ MFA ポリシーは、「非 SSO ログインに MFA を強制する」である必要があります。 ステップ 2:[ポリシー入力] 関連リストで、[MFA 適用対象外グループのメンバーである] フィルター基準レコードをクリックします。 ステップ3:グループリストの「MFA適用対象外ユーザーグループ」をクリックします。 ステップ 4:MFA の適用から除外するグループをこのグループに追加します。 信頼できるネットワークに対する MFA の義務をどのように緩和できますか? ステップ 1:[適応認証] > [フィルター基準] > [IP フィルター基準] に移動し、信頼できるネットワークを指定するための新しい基準を作成します。信頼できるネットワークの一部として IP 範囲またはサブネットのリストを指定できます。 ステップ 2:適応認証>認証ポリシーコンテキスト > MFA コンテキスト に移動し、コンテキストに関連付けられたポリシーを開きます。 ステップ 3:[編集(Edit)] ボタンをクリックして、ステップ 1 で作成した IP フィルタ基準を [ポリシー入力(Policy inputs)] 関連リストに追加します。 手順 4:ポリシー条件を変更して、ユーザーが信頼できるネットワークの一部である場合に false と評価されるようにします。 注: MFA コンテキストに別のポリシーが関連付けられている場合は、ステップ 1 の一部として作成された IP フィルター基準をポリシーに追加し、信頼できるネットワークでの MFA の適用を除外するようにポリシー条件を変更できます。 信頼できる場所に対する MFA の義務をどのように緩和できますか? これは、Zero Trust – Location Based Access プラグインがインストールされている場合に利用可能になる場所フィルター基準 (追加のサブスクリプションが必要) を使用して実現できます。詳細な手順については、 この の記事を参照してください。 MFA の適用頻度を制御できますか? MFA 検証ページには、ブラウザーを記憶するためのチェックボックスがあります。MFA が記憶されたブラウザに適用されない。 このシステムプロパティで指定された期間。 glide.authenticate.multifactor.browser.fingerprint.validity プロパティのデフォルト値は 8 時間です。この期間は、最大 24 時間延長できます。同様に、 glide.authenticate.multifactor.remember.browser.default システムプロパティでは、チェックボックスのデフォルト値を true に設定できます。 マルチファクター認証 > プロパティに移動し、これらの 4 つのプロパティを調整して、ブラウザーの記憶機能を制御できます。 複数のユーザーが共有するアカウントでは、MFA はどのように機能しますか? 複数のユーザーによって共有される単一のアカウントはセキュリティ上のリスクです。アカウントを複数のユーザーと共有することはお勧めしません。 6.MFA リセット 認証アプリのセットアップが失われました。どうすればリセットできますか? MFA によってロックアウトされないように、ユーザーは複数の要素に登録することをお勧めします。たとえば、ユーザーは TOTP 認証アプリ、パスキー、メール OTP ベースの MFA を使用できます。 ユーザーが登録済みの MFA 要素を使用できない場合、システムアドミニストレーターは次の手順に従って MFA をリセットできます。 ステップ 1:認証アプリのセットアップをクリアする: [ユーザーマルチファクターセットアップ] > [マルチファクター認証] に移動します。テーブル内のユーザーの検索ユーザーに関連付けられたレコードを削除します ステップ 2:FIDO2 認証システムとパスキーをクリアする [マルチファクター認証] > [ユーザーの公開認証情報> Web 認証] に移動します。テーブル内のユーザーの検索ユーザーに関連付けられたレコードを削除します ステップ 3:ユーザーに関連する他のマルチファクター設定をクリアする [ユーザーが最近使用した要素] >マルチファクター認証 に移動します。テーブル内のユーザーの検索ユーザーに関連するレコードを削除します アドミンを含め誰もインスタンスにアクセスできない場合、アドミンは Now Support ポータル(https://support.servicenow.com/now)で利用可能なカタログアイテムを使用してセルフサービス MFA リセットを実行できます。 注:NowSupport のサービスカタログアイテムは、4 月 25 日から利用可能になります。 MFA によるアドミンのロックアウトを防ぐにはどうすればよいか? アドミニストレーターがインスタンスへのアクセスをブロックされないように、複数の MFA 要素に登録することをお勧めします。 アドミンを含め誰もインスタンスにアクセスできない場合、アドミンは Now Support ポータル(https://support.servicenow.com/now)で利用可能なカタログアイテムを使用してセルフサービス MFA リセットを実行できます。 7.MFA アダプション MFA が行われていないローカルログインの数を確認するにはどうすればよいですか? 管理者は、セキュリティ測定基準>セキュリティコンソール> Security Center に移動できます。 [ユーザーのメトリクス] で、[MFA で保護されていないローカルログイン (Local logins not protected by MFA)] をクリックします。