システム管理者を含む特権ユーザーに対するフィッシング耐性のある多要素認証（MFA）の適用準備

適用前：準備方法

1. 変更の影響を受けるユーザーを評価する： 

   • システム管理者プロファイル、またはいずれかの権限（すべてのデータの編集、すべてのデータの参照、アプリケーションのカスタマイズ、Apex 開発）が割り当てられているすべてのユーザーを特定します。Salesforceレポート、ユーザーリストビュー、SOQL、または権限割り当ての分析を使用できます。

   • 「除外ユーザーの多要素認証を放棄」権限が割り当てられているすべてのユーザーを特定してください。この権限は変更が適用されると無効になるため、有効なユースケース（自動テストツールなど）で免除を維持するには、Salesforceサポートに問い合わせる必要があります。

2. 組織の検証オプションを設定する -組織でセキュリティキーや組み込み Authenticatorが有効になっていることを確認してください。設定でこれらの方法を有効にすると、組織のすべてのユーザーが利用できるようになります。管理者やその他の特権ユーザーのみに利用を制限することはできません。 

   • 【推奨】パスキーログインを有効にする：ログインを高速化するために、パスキーによるパスワードなしログインを許可してください。ユーザーは、ユーザー名とパスキー（組み込みAuthenticatorまたはセキュリティキー）のみを使用してログインすることで、フィッシング耐性のあるMFAの要件を満たすことができます。ID 検証設定で、「パスキーによるパスワードなしのログインを許可」をオンにしてください。詳しくは、「パスキーを使用したパスワードなしのログインの有効化」をご覧ください。

3. MFA準拠のためのSSOの設定：SSOには主に2つの方法があります。1つは、IDプロバイダー（IdP）を更新して、フィッシング耐性のあるMFA認証を必須とし、必要なAMR/ACRシグナルを送信する方法、もう1つは、SSOログインでSalesforce MFAを有効にする方法です。IdPのMFAサービスを利用する場合は、IDトークン（OpenID Connect用）またはSAMLレスポンスに必要なAMR/ACRシグナルが含まれていることを確認してください。

   • ログイン履歴を確認して、OIDC AMRシグナルを確認してください。

   • SAML ACR 値はまだログイン履歴に記録されていないため (今後のリリースで記録予定)、サードパーティ製の SAML トレーサーを使用して応答を確認してください。Salesforce SAML Validator は AMR/ACR クレームを評価しますが、現時点では「強力」または「弱い」に分類するだけであり、今回の変更で導入された特定の「弱い」、「標準」、「フィッシング耐性」の認証シグナル強度分類の定義を反映するように更新されていません。

4. フィッシング耐性MFAの実装をテストする：テスト環境でMFAを有効にして、フィッシング耐性のあるMFAを使用してログインできることを確認してください。「Salesforce組織におけるMFA実装のテスト」を参照してください。

5. 事前に登録する：すべての特権ユーザーにスケジュールを事前に伝え、ログインの中断を避けるため、適用前にフィッシング耐性MFA検証方法を登録するよう促してください。 「Salesforce 組織の ID 検証方法の登録」を 参照してください。

適用後：エラーの解決

• SSOシグナルに関する問題：SSOプロバイダーがフィッシング耐性のあるMFAを使用しているにもかかわらず、対応するシグナルを送信しない場合、ユーザーはSalesforce MFAへの登録を求められます。Salesforce内でプロンプトが表示されないようにするには、SSOプロバイダーと連携して、ACRまたはAMRシグナルが正しく送信されるようにしてください。

• 特権ユーザーのロックアウト：特権ユーザーが完全にロックアウトされ、フィッシング耐性のあるMFAを提供できない場合は、別の組織管理者が一時的な本人確認コードを生成し、古い認証方法を無効にして、再登録を支援できます。詳細は、「ユーザー (Salesforce 組織) の MFA アクセスの問題の解決」を参照してください。他に管理者がいない場合は、 Salesforceサポートにお問い合わせください。 

よくある質問

Salesforceは、どのようなフィッシング耐性のある多要素認証（MFA）をサポートしていますか？

Salesforceは、以下のフィッシング耐性のある多要素認証（MFA）方式をサポートしています。

FIDO2 / WebAuthn 認証

• 組み込み Authenticator ：PINまたは生体認証で保護されたデバイスのセキュアハードウェアを使用する、デバイスに紐づけられたパスキー。例：

  • Windows Hello for Business：デバイスのトラステッドプラットフォームモジュール（TPM）チップとPINまたは生体認証を使用します。キーはデバイスに紐付けられており、エクスポートすることはできません。

  • Apple Passkeys（Touch ID / Face ID）：Appleのエコシステム（iPhone、Mac、iPad）に組み込まれており、デバイスに紐付けて使用することも、iCloudキーチェーン経由で同期することもできます。

  • Android/Google Passkeys: デバイスのセキュアエンクレーブと生体認証を使用します。

• セキュリティキー：外部FIDO2/WebAuthnセキュリティキー（例：YubiKey）。USB、NFC、またはBluetooth経由で接続するものも含まれます。

• クラウド同期パスキー：パスワードマネージャーまたはクラウドキーチェーン（例：1Password、Bitwarden、iCloud Keychain）で管理されるパスキー。デバイスに紐づいていませんが、FIDO2に準拠しており、パスワードマネージャーがFIDO2/WebAuthnに準拠していれば、フィッシング耐性のある多要素認証（MFA）要件を満たします。

証明書ベース認証（CBA）

証明書ベース認証では、x.509クライアント証明書を使用してユーザーIDを検証します。企業の証明書がユーザーのデバイスにインストールされ、相互TLS（mTLS）を使用してSalesforceとの認証が行われます。証明書の秘密鍵は、TPM（Trusted Platform Module）やセキュアエンクレーブなどのセキュアなハードウェアで保護されているため、フィッシングや認証情報の盗難に対する耐性があります。設定の詳細については、 「証明書ベースの認証」を参照してください。

APIログインにはどのような影響がありますか？

この変更は、UIベースの従業員ログインのみを対象としています。

Salesforce Mobile SDK を使用した Salesforce モバイルアプリ経由のログインには、どのような影響がありますか？

1. 「管理者ログイン」ボタン：Mobile SDK バージョン 13.2.0 以前では、デフォルトの Mobile SDK 認証モード (WebView) では、フィッシング耐性MFA をサポートできません。このバージョンの管理者ユーザーは、組織が 私のドメイン 設定で高度な認証を事前に構成し、ログイン サーバーとして 私のドメイン を使用しない限り、ログインできません。高度な認証が構成されていない場合、管理者は、2026 年 5 月に Mobile SDK 13.2.1 のリリースで追加される新しい「管理者ログイン」メニュー項目を使用できます。このボタンは、高度なブラウザー ベースの認証を強制し、フィッシング耐性MFA を自動的に有効にします。これは、Mobile SDK を使用するすべての Salesforce 内部アプリケーションおよびサードパーティ アプリケーションに適用されます。さらに、Salesforce モバイル アプリの管理者は、「メールでログイン」オプションを使用できます。

2. すべてのユーザーに対するログインUXの変更：フィッシング耐性のあるMFA（多要素認証）が必須となったため、Salesforceはログインフローを変更し、ユーザーが「ログイン」をクリックした後に、まずユーザー名項目が表示され、次にパスワードまたはパスキー項目が表示されるようにします。この変更は既存のモバイルSDKアプリで機能するため、コードの変更は不要です。ただし、この2段階フローでは、以前のフローに対応するように設定されている既存の自動テストを更新する必要があります。

変更が組織またはインスタンスに反映されたかどうかを確認するにはどうすればよいですか？

Salesforce MFA を使用している特権ユーザーは、セキュリティキーと組み込みAuthenticatorのみを使用することが許可されます。Salesforce Authenticatorやサードパーティ認証アプリ (TOTP) を使用して必要な MFA を完了することはできなくなります。

SSOを使用してログインする場合、SSOプロバイダーが必要なAMRまたはACRシグナルを送信せず、フィッシング耐性のあるMFAが使用されたことが確認されない場合、特権ユーザーにはSalesforce MFAへの登録と使用を促すプロンプトが表示されます。 

フィッシング耐性MFA要件において、「特権ユーザー」とみなされるのは誰ですか？

特権ユーザーとは、システム管理者プロファイルを持つユーザー、または以下のいずれかの権限（権限セットによるものを含む）が付与されたユーザーを指します。

すべてのデータの編集、すべてのデータの参照、アプリケーションのカスタマイズ、またはApex 開発

特権ユーザーは、TOTPアプリを有効なMFA方法として使用できますか？

いいえ。Salesforce Authenticatorを含むモバイルTOTPアプリケーションは、システム管理者を含む特権ユーザー向けの新しいフィッシング耐性のあるMFA要件を満たしていません。これらのツールは標準MFAに分類されますが、フィッシング攻撃に対して脆弱なままです。フィッシング耐性のあるハードウェアまたは生体認証の導入に関して技術的または組織的な障壁に直面している特権ユーザーは、Salesforceサポートまたは担当営業に問い合わせてガイダンスを受けてください。

フィッシング耐性のあるMFA要件は、特権ユーザーのシングルサインオン（SSO）ログインにも適用されますか、それともユーザー名とパスワードによる直接ログインのみに適用されますか？

これは どちらにも適用されます。SSO経由でログインする特権ユーザーは、IdPからフィッシング耐性のあるMFA ACR/AMRシグナルを受信する必要があります。そのようなシグナルを受信しない場合、特権ユーザーはSalesforceのフィッシング耐性のあるMFAへの登録を求められます。MFAが適用される前に、アプリケーション内で登録を完了するためのプロンプトが表示されます。 

フィッシング耐性のあるMFAを有効にすると、すべてのユーザーの登録プロセスが変更されますか、それとも特権ユーザーのみが変更されますか？

この変更が実施されると、新しいMFA検証方法の設定を求められたユーザーは、フィッシング対策を確実にするため、セキュリティキーや組み込みAuthenticatorなどのパスキーを登録するよう指示されます。フィッシング耐性MFAオプションの使用が義務付けられていないユーザーについては、サードパーティ製の認証アプリを選択するオプションが引き続き利用可能です。

Salesforceは、SSOプロバイダーから提供されるフィッシング耐性のあるMFAシグナル値のうち、どれを認識しますか？

Salesforceは、SSO MFAの強度を3つの異なるレベルに分類しています。

許容される値のリストについては、上記の「認証強度レベル」というタイトルのセクションにある表を参照してください。 フィッシング耐性MFAシグナルが検出された場合、ユーザーは追加の認証要件なしに即座にアクセスできるようになります。

ただし、標準MFA、または脆弱なMFA/MFAなしのシグナルを検出した場合は、SalesforceのUIを介してユーザーに検証方法を選択し、Salesforceアカウントに登録するように促されます。

「除外ユーザーの多要素認証を放棄」権限は引き続き使用できますか？

適用日以降、この権限ではMFA要件が自動的に免除されなくなります。この権限を持つユーザーは、Salesforce UIでMFAの登録と使用を求められます。有効なユースケース（自動テストツールなど）で免除を復元するには、Salesforceサポートに連絡して承認を得る必要があります。

組織の唯一の管理者がロックアウトされてしまった場合はどうなりますか？

管理者アカウントが完全にロックアウトされ、フィッシング耐性のあるMFAを提供できない場合は、別の組織管理者が一時的な本人確認コードを生成し、古い認証方法を無効にして、再登録を支援できます。詳細は、「ユーザー (Salesforce 組織) の MFA アクセスの問題の解決」を参照してください。他に管理者がいない場合は、 Salesforceサポートにお問い合わせください。 

パスキーを使用したパスワードなしログインは、フィッシング耐性のある多要素認証（MFA）として認められますか？

はい。パスワードがなくても、パスキー（組み込みAuthenticatorやセキュリティキー）は本質的に複数の認証要素を使用します。

Sandboxのリフレッシュ後、SSOが無効になりMFA認証情報が失われた場合、管理者はどのようにしてアクセス権を回復できますか？

Sandbox が本番組織からリフレッシュされると、SAML SSO 設定は部分的に引き継がれますが、受信者 URL が新しいSandbox の URL に合わせて更新されるため、Sandboxでは自動的に無効になります。そのため、リフレッシュ直後は SSO 経由でログインできず、SSO アクセスを復元するには SAML 設定を再構成する必要があります。コピーされる SSO 設定と変更点の詳細については、「シングルサインオン設定および Sandbox の更新」を参照してください。

加えて、MFA検証は組織固有のものであるため、Sandboxの更新後には引き継がれません。管理者は、SSOを再設定する前に、Salesforceに直接ログインして、フィッシング耐性のある新しいMFA検証を登録する必要があります。

Sandbox更新後の推奨手順：

1. ユーザー名とパスワードを使用してSalesforceに直接ログインし、フィッシング耐性MFA検証ツール（セキュリティキーまたは組み込みAuthenticator）を登録してください。

2. 更新されたSandboxのSAML SSO設定を再構成して再度有効化し、受信者URLを更新します。

注：SAML設定が再構成されるまでSSOは利用できないため、Sandboxの更新を開始する前に、少なくとも1人の管理者が互換性のあるフィッシング耐性検証ツール（ハードウェアセキュリティキーなど）を直接ログインできる状態にしておくなど、事前に計画を立ててください。

フィッシング耐性MFAの要件は、Developer Edition、Trail、スクラッチ組織、またはその他の無償組織にも適用されますか？ 

いいえ。フィッシング耐性MFAの要件は、有償の本番組織とSandbox組織のみに適用されます。Developer Edtion、Trail、スクラッチ組織、その他の無償組織は、この要件の適用対象外です。

「除外ユーザーの多要素認証を放棄」というユーザー権限を持つユーザーを確認するためのSOQLクエリはありますか？

オプション1：PermissionSetAssignmentによるクエリ（権限セットを通じて権限を持つユーザーを検索）

  SELECT AssigneeId, Assignee.Name, Assignee.Email, Assignee.Username,             

         Assignee.IsActive、PermissionSet.Name                                     

  FROM PermissionSetAssignment                                                      

  WHERE PermissionSet.PermissionsBypassMFAForUILogins = true                       

オプション2：プロファイルによるクエリ（権限が有効になっているプロファイルを検索）

  SELECT Id, Name, PermissionsBypassMFAForUILogins                                 

  FROM Profile                                                                      

  WHERE PermissionsBypassMFAForUILogins = true                                     

注:   API 項目名: PermissionsBypassMFAForUILoginsは、UI の「除外ユーザーの多要素認証を放棄」のユーザー権限に対応します。

フィッシング耐性MFA実装におけるユーザーへの影響範囲を判断するために、管理者権限または特権権限を持つユーザーを確認するためのSOQLクエリはありますか？

標準システム管理者プロファイルを持つユーザーを検索するクエリ

  SELECT Id, Name, Email, Profile.Name, IsActive

  FROM User

  WHERE Profile.Name = 'System Administrator'

特権ユーザー権限を持つユーザーを検索するクエリ

  フィッシング耐性MFA強制における主要となる「特権ユーザー」権限：

  - PermissionsModifyAllData — すべてのデータの編集

  - PermissionsViewAllData — すべてのデータの参照

  - PermissionsCustomizeApplication — アプリケーションのカスタマイズ

  - PermissionsAuthorApex — Apex 開発

   上記権限のいずれかを持つユーザーを検索するクエリ- 権限セット経由

  SELECT AssigneeId, Assignee.Name, Assignee.Email, Assignee.Username,

         Assignee.IsActive、PermissionSet.Name

  FROM PermissionSetAssignment 

  WHERE PermissionSet.PermissionsModifyAllData = true

     OR PermissionSet.PermissionsViewAllData = true

     OR PermissionSet.PermissionsCustomizeApplication = true

     OR PermissionSet.PermissionsAuthorApex = true

   上記権限のいずれかを持つユーザーを検索するクエリ- プロファイル経由

  SELECT Id, Name, Email, Profile.Name, IsActive

  FROM User

  WHERE Profile.PermissionsModifyAllData = true

     OR Profile.PermissionsViewAllData = true

     OR Profile.PermissionsCustomizeApplication = true

     OR Profile.PermissionsAuthorApex = true

フィッシング耐性MFAの義務化は、パートナー管理共有ログインにどのような影響を与えますか？また、コンプライアンス遵守のための選択肢にはどのようなものがありますか？

パートナー管理共有ログインでは、フィッシング耐性のあるMFAを使用する必要があります。この要件は、FIDO2/WebAuthn準拠のパスワードマネージャー（1PasswordやBitwardenなど）を使用してパスキーを保存および共有することで満たすことができます。現在使用しているツールがこれらの標準をサポートしていない場合は、パスキーをサポートするパスワード管理ツールにアップグレードするか、可能な場合は個別のユーザーライセンスに切り替えて、各管理者が個人のパスキーまたはハードウェアセキュリティキーを登録できるようにしてください。

変更履歴

 ※本ナレッジ記事は英語版ナレッジ記事の翻訳版となります。最新情報は英語版ナレッジ記事をご参照ください。