Okta管理者アクセスのセキュリティを保護する一連のベストプラクティスをご用意しています。管理者にはユーザーID、資格情報、アプリケーションアクセスを管理できるように高度なアクセス権が付与されていることを考慮すると、管理者アクセスのセキュリティを保護することは重要です。Oktaは、本記事のベストプラクティスに従って、構築済みの対策を強化することを組織にお勧めします。
- Okta管理者
Oktaは、以下のベストプラクティスに従って、構築済みのセキュリティ対策を強化することを組織にお勧めします。
MFAの適用：すべてのOktaのお客様、特にOkta管理者すべてとOkta Admin Consoleへのアクセス、さらにITやお客様によってハイリスクと定義されるそのほかのユーザーグループに最低限MFAを採用することを強くお勧めします。管理者アクセスのMFAはデフォルトで有効になっています。Okta ClassicまたはOkta Identity Engine（OIE）で管理者アクセスのMFAを確認または有効にする方法については、各リンク先をご覧ください。また、ユーザーによるMFA登録レポートでユーザーごとにMFAの登録を確認することもできます。Okta Admin Consoleなどのアプリケーションへのアクセスを求める実環境のユーザーリクエストをシミュレートするには、Oktaのアクセステストツールの使用をご検討ください。
Okta FastPassなどのフィッシング耐性MFAの適用：フィッシング耐性認証を使用することで、資格情報の紛失や盗難、AiTM攻撃型のフィッシング攻撃、IDに基づくほかの攻撃に対するセキュリティが高まります。WebAuthn（FIDO2）およびFastPassを使用したフィッシング耐性認証の実装方法については、こちらをご覧ください。さらにOktaは、FastPassを有効にすることで、Okta Admin Console認証ポリシーによってユーザーに登録済みデバイスからのアクセスを求めることをお勧めします。
管理者セッションと自律的システム番号（ASN）をバインドして不正なトークンをブロック：管理者セッションのバインディングを有効にして、異なるASNを持つIPアドレスからセッションが再利用された場合に管理者に再認証を要求します。
管理者セッションライフタイムの最小化：管理者は短いアイドル時間後に再認証を求められ、セッションの長さを12時間以内にする必要があります。管理者セッションライフタイムとアイドル時間の設定方法については、こちらをご覧ください。注意：NIST AALフェーズ3では、管理者が再認証を求められるまでのセッションライフタイムを最大12時間、アイドル時間を最大15分とすることが推奨されています。Oktaは、これらの値を24時間と2時間に制限し、セキュリティ侵害時に長時間の管理者セッションが使用されることのないようにしています。
カスタム管理者ロールを使用して最小限の権限を採用：テナント内の管理者およびスーパー管理者の数を最小限に抑え、カスタム管理者ロールを使用して、管理者ユーザーが特権タスクを完了するのに必要な権限の適用範囲を最小化します。管理者ロールの割り当てレポートを使用して、Orgの管理者を監査します。
セキュアなサービスアカウント：Oktaは、Oktaへのサービス統合を目的としてユーザーアカウントを作成することを推奨していません。可能な場合にはAPIサービス統合を使用して、頻繁にクライアントシークレットのローテーションを実行してください。こちらのブログには、この2つの違いとOAuth 2.0クライアントの認証情報が推奨される理由がまとめられています。APIセキュリティに関するベストプラクティスの全リストについては、こちらをご覧ください。
統合にユーザーアカウントを使用しなければならない場合には、こちらで説明されているベストプラクティスに従ってください。サービスアカウントの設定が完了したら、インタラクティブなアクセスを拒否するグローバルセッションポリシーが適用されたグループにアカウントを追加します。
キャッチオール拒否ルールの設定：あらゆるポリシーで明示的に拒否するには、キャッチオール（最終）ルールを設定します。どのルールもリクエストが特定の条件を満たすまで評価されます。ポリシーで設定された条件を満たさない場合に、キャッチオール拒否ルールによってユーザーのサインイン方式の本人確認レベルが低下することはありません。
セルフサービスのパスワードリセット：管理者または特権ユーザーアカウントにパスワードを設定し、セルフサービスのパスワードリセット機能を使用している場合、必ず追加の認証要素（OIE）を要求してください。セルフサービスのパスワードリセットの詳細な設定方法については、こちらをご覧ください。または、セルフサービスのパスワードリセットを無効にして、Okta管理者に本人確認を伴う社内手順に従ってリセットを実行するように求めてください。
MFA登録ポリシー：登録ポリシーを設定して、強力な要素を求めます。これは任意ではありません。特にOkta End-User Dashboardのアクセスポリシーの本人確認レベルがほかの機密アプリよりも低い場合に、追加要素の登録の制限を検討してください。
Okta Admin Consoleへのログインを定期的に確認：通常外の時間のアクセスや想定範囲外のIPアドレスなど、管理者コンソールへの不正なアクセスおよびログインコンテキストを検出します。システムログクエリ「eventType eq "user.session.access_admin_app"」を使用して、Admin Consoleへの異常なログインを識別します。検出の詳細については、こちらの記事をご覧ください。
ThreatInsightを有効にする：Okta ThreatInsightは、Oktaのサインイン試行を評価して、疑わしいアクティビティや悪意のあるアクティビティがないか確認します。構成されたThreatInsightの設定に応じて、これらのサインインをログに記録したり、ログに記録したうえでブロックしたりできます。Okta ThreatInsightの詳細については、こちらの製品ドキュメントを参照してください。
標準的ではない場所からのトラフィックをブロックする：Okta動的ゾーンを使用すると、Oktaのエンドユーザーや管理者が通常使用しないネットワークからのトラフィックをブロックできます。たとえば、脅威者は住宅用プロキシやTORなどの匿名化サービスを多用しますが、従業員や消費者は通常、これらの種類のサービスを必要としません。Okta動的ゾーンの詳細については、こちらのドキュメントをご覧ください。
詳細については、次のビデオを参照してください。
