概要
この記事では、Admin Consoleへの多要素認証(MFA)の強制に関するよくある質問にお答えします。
この要件の詳細については、「Okta Admin Consoleへのアクセスに多要素認証(MFA)を要求する」をご覧ください。
解決策
緊急アクセス用管理者アカウント
Q:管理者パスワードをvaultに保存し、使用するたびにローテーションしています。「単一要素」を使用しているため、緊急時に「パスワードのみ」でアクセスできます。この場合のOktaの推奨事項を教えてください。
A:管理者パスワードをvaultに保存し、使用するたびにローテーションするのはよいことです。しかし、Oktaはクラウドサービスであり、Admin Consoleにはクラウドからアクセスできるため、単一要素だけでは十分に保護できません。
このアカウントにもう1つの要素としてセキュリティキーを登録し、パスワードとともに使用することをお勧めします。緊急アクセス用管理者アカウントのパスワードに複数の管理者ユーザーがアクセスする必要がある場合は、アクセスが必要な管理者ごとに固有のセキュリティキーインスタンスを登録することが推奨されます。本製品では現在、同じアカウントで複数のセキュリティキーを追加の要素として登録できるため、この方法を使用できます。また、複数のWebAuthn AuthenticatorとSMS電話番号を同じアカウントのMFA要素として登録することも可能です。
Oktaサポートは、管理者ユーザーが緊急時にMFAを提供できない場合に、Admin Consoleへの一時的なアクセス権を提供することもできます。一時的なアクセス権を使用することで、管理者は制限時間内にパスワードのみでAdmin Consoleにログインできます。この機能は指定された期間の終了時に自動的に失効します。
共有管理者アカウント
Q:共有アカウントを使用してAdmin ConsoleからAPIトークンを作成しています。これらの共有アカウントでMFAを使用するのは面倒なのですが、どうすればよいでしょうか。
A:同じOkta管理者アカウントで複数のAPIトークンを作成すると、これらのトークンを使用しているアプリケーションの単一障害点が発生するため、この方法は避けることをお勧めします。SSWSトークンが必要な場合は、これらのトークンを使用している統合ごとに1つのOkta管理者アカウントを使用し、強力なMFAでそのアカウントを保護してください。可能であれば、全体でAPIトークンの使用をやめ、代わりにOAuthサービスアカウントを使用することで、人的要素を排除できます。ただし、この方法では時間がかかる可能性があり、Okta機能の中にはAPIトークンを要求するものも存在します。
共有管理者アカウントが必要な場合は、このアカウントにもう1つの要素としてセキュリティキーを登録し、パスワードとともに使用することをお勧めします。このアカウントに複数の管理者ユーザーがアクセスする必要がある場合は、管理者ごとに固有のセキュリティキーインスタンスを登録することが推奨されます。本製品では現在、同じアカウントで複数のセキュリティキーを追加の要素として登録できるため、この方法を使用できます。また、複数のWebAuthn AuthenticatorとSMS電話番号を同じアカウントのMFA要素として登録することも可能です。複数の管理者がパスワードを共有する場合でも、管理者ごとに固有のMFA要素を登録することで、MFAを完了してAdmin Consoleにアクセスできます。
エージェントアカウント
Q:エージェント用のサービスアカウントに影響はありますか。
A:今回の変更では、通常のAD/LDAPエージェントの運用には影響ありません。同じサービスアカウントを使用してAdmin Consoleにログインしている場合は、MFAを完了してAdmin Consoleにアクセスする必要があります。
テストの自動化
Q:ユーザー名とパスワードを使ってAdmin Consoleにログインする自動テストが多数あります。自動テストでMFAを完了するにはどうすればいいですか。
A:テストユーザーをTOTP要素に登録し、登録レスポンスの共有シークレットを使用して時間ベースのOTP値を生成することで、MFAを完了できます。
インバウンドフェデレーション
Q:管理者は別のIdPからAdmin Consoleにフェデレーションしており、すでにそのIdPでMFAを完了しています。管理者に対して、現在のテナントでMFAの要件を満たすために追加の要素を登録するよう要求することはできません。どうすればよいでしょうか。
A:Admin ConsoleへのアクセスにMFAを強制適用すると、お客様のセキュリティポスチャが大幅に強化されます。Oktaには、外部Okta IdP orgおよびサードパーティーのIDプロバイダー(IDP)完了したMFAを尊重する機能があります。詳細については、Okta Developerの「クレーム共有を構成する」を参照してください。
- 認証クレームを送信するカスタムSAML属性session.amrを定義します。Entra IdP SAML統合の場合は、「Define custom attributes - Microsoft Entra External ID」で説明されているように、認証クレームを送信するカスタムSAML属性「session.amr」を定義する必要があります。また、「Add attributes to token claims - Microsoft Entra External ID」で説明されているように、属性をトークンクレームに追加する必要があります。
- SAMLの代わりにOpenID Connect統合を使用します。
詳細については、Okta Developerの「クレーム共有を構成する」を参照し、[手順]ドロップダウンオプションで適切なトピックを選択します。
Q:すでにOktaでパスワード検証を完了し、外部IdPで認証を完了しています。この2つをMFAとしてカウントするにはどうすればよいですか。
A:[Security(セキュリティ)]>[IDプロバイダー]><構成済みのIdP名>で、[IdPの用途]を[SSOのみ]に設定した場合、このIdPでの検証は知識要素としてカウントされます。[IdPの用途]を[要素のみ]に変更してIDP Authenticatorとして構成すると、所有要素としてカウントされます。このIdP検証とパスワード検証が正常に完了すると、MFAの保証要件が満たされます。
MFAの強制後のロックアウトと復旧
Q:Admin Consoleからロックアウトされています。どうすればよいですか。
A:orgで他のAuthenticatorが有効になっている場合、Okta End User Dashboardの設定アプリにアクセスしてMFA要素を有効にした後で、Admin Consoleにアクセスできます。詳細についてはサポートまでお問い合わせください。
関連資料
- Okta Admin Consoleへのアクセスに多要素認証(MFA)を要求する
- 製品アップデート - 近々予定されているOktaのセキュリティ強化
- 多要素認証
- Okta Admin ConsoleのMFAを有効にする
