Oktaで管理セッションを保護

このブログはこちらの英語ブログ（2024年3月21日公開）の翻訳、石橋 禎史によるレビューです。

特権ユーザーは、これまでも、そしてこれからも、活発な攻撃者から絶え間なく攻撃され続けることが予想されます。

この90日間、Oktaはリソースの多くを、Okta Admin Consoleを大幅に強化するための作業プログラムに投入してきました。その結果、以下のような数多くの新機能を実現しました。

​

このブログ投稿の目的は、これらの新機能の使用方法について全体像を把握し、総合的に考えることで、以下の実現を目指しています。

• Okta orgの攻撃対象領域（アタックサーフェス）を減らす
• アカウント乗っ取りを防ぐ
• 盗まれたセッションの被害を最小限に抑える

攻撃対象領域（アタックサーフェス）の削減

特権付きアプリケーションへの不正アクセスを防ぐ第一歩は、特権ロールを持つアカウント数を減らすことです。

Okta標準の管理者ロールは、新規の従業員へのリソース展開に対して最も早く対応することで価値を提供します。最もセキュリティ意識の高い組織は、最小特権アクセスを追求して、カスタム管理者ロールに移行します。

このプロセスは以下の通りです。

• 管理者権限をグループごとに割り当て、個別に割り当てないようにする。これにより、ポリシーの管理とガバナンスが大幅に簡素化される。
• 高度な特権ロールを持つアカウント（スーパー管理者、組織管理者、アプリ管理者）の数を最小限に抑える戦術的な方法を特定する。例えば、委任フローでは、管理者アクセスを必要とするWorkflowsのユーザー数を削減する。
• 一般的な管理機能（ユーザーをアプリに割り当てる、認証要素のライフサイクル操作など）をカスタム管理者ロールに分解し、特定のリソース（グループ、アプリ、ワークフローなど）に割り当てることで、最小権限をさらに促進する。

目標とする状態は、可能な限り「ゼロスタンディング特権（Zero Standing Privileges）」に近づけることです。

ゼロスタンディング特権とは、管理者が指定されたタスクを完了するために必要なリソースと権限へのアクセスをジャストインタイムで取得し、時間が経過するとアクセス権が自動的に取り消されるモデルです。

Okta Privileged Access Management（OPA）は、この原則を利用して、サーバー、データベース、アプリ、その他のターゲットへのアクセスを保護します。OPAをOkta Identity Governance（OIG）のアクセス要求機能と組み合わせると、特権リソースへのすべてのアクセスは必ず許可されたものであり、一時的なものであり、記録されているものであるということが明確化され、監査を容易にします。

しかし、Oktaは、ゼロスタンディング特権を最小規模のお客様にも手の届く設計パターンにしたいと考えています。Oktaは、すべてのOkta Workforce Identity Cloudのお客様が、Oktaを管理するために必要な機能へのアクセスに対し、ゼロスタンディング特権を実現できるよう取り組んでいます。

製品チームは、Okta Privileged AccessとOkta Identity Governanceのプレミアム機能のサブセットをOkta Admin Consoleに直接組み込み、すべてのOkta Workforce Identity Cloudのお客様がこの重要な保護機能を無料で利用できるようにしました。

この設定により、Oktaのゼロスタンディング特権までのプロセスがよりシンプルになります。

1. すべての管理者に、日々の業務に必要な最小限のリソースと権限に設計されたカスタムロールを割り当てる。
2. 一時的な（「ジャストインタイム」の）昇格権限を必要とする管理者のために、リクエスト承認プロセスを作成する。
3. 昇格権限を持つロールにアクセスするには、2人以上の他管理者からの二重承認が求められる。
4. アクセス要求でアクションを作成し、承認後に昇格権限を割り当てられたグループにユーザーを追加し、指定された期間が経過した後にグループからユーザーを削除する。

このプロセスに必要な唯一の例外は以下のとおりです。

1. スーパー管理者ロールを持つ緊急アクセス用アカウント

デプロイによっては、緊急アクセス用アカウントが必要になる場合があります。「break glass account」と呼ばれるこの緊急アクセス用アカウントは、信頼されたネットワークまたは PAMソリューションが利用不可であることを想定したポリシーによって保護しなければなりません。さらに（冗長性のために2次または3次のIP範囲を使用して）ネットワークの場所によってアクセスを制限し、多要素認証を要求することもお勧めします。一般的なアプローチは、アカウントに登録された複数の物理的なFIDO2セキュリティキーのうちの１つを要求するとともに、マシン生成された文字列をパスワードとして要求することです。このアカウントへのアクセスは、絶対的な警戒心を持って監視し、どんな使用であってもSOCの警鐘を鳴らすべきです。

2. M2M（マシンツーマシン）認証で使用されるサービスアカウント

人間以外の（マシンツーマシン）アクセスに使用されるアカウントを放置しないようにします。OAuth 2.0ベースのAPIサービスアプリケーションを使用できる限り使用し、必要最小限のアカウント権限とスコープを適用します。レガシーな静的APIトークンを統合に使用する場合は、OktaのIP許可リスト機能を利用してください。すべての静的APIトークンを保管し、その目的のインベントリを管理し、定期的に監査とローテーションを行います。設定後、サービスアカウントはOktaグループのメンバーとし、そのグループには対話的アクセスを拒否するグローバルセッションポリシーを適用します（注：これはAPIアクセスを制限するものではありません）。メンテナンス作業には、一時的にアカウントを別のポリシーに従わせる正式なアクセス要求プロセスが必要です。それ以外では、サービスアカウントによる未認可の対話的アクセスや共有アクセスを検知するために、注意深く監視する必要があります。

アカウント乗っ取りを防止

前述のように、Oktaは、Okta Admin Consoleへの不正アクセスを防止するために、最高クラスの機能を構築しています。これらの機能の多くは、デフォルトで有効です。

環境のレジリエンスは、ポリシーの適切な構成とそれをサポートする制御に大きく依存します。Okta Securityでは、少なくとも、以下を構成して管理ユーザーを保護することをお勧めします。

• ThreatInsightをログおよび強制モードで有効にします。これにより、パスワードが必要なアカウントに対する大量の認証情報ベースの攻撃を検出し防止します。
• 管理者権限を持つグループに強力な認証ポリシーを適用します。
• 管理者ユーザーには、パスワードレスでフィッシング耐性のある認証機能（Okta FastPass、FIDO2 WebAuthn、スマートカード）を使用したサインインを要求します。
  • ポリシーでフィッシング耐性を強制します。
  • 生体認証チャレンジ（推奨）または PIN によるアイデンティティの確認をユーザーに要求します。
  • Okta Admin Consoleへのアクセスに特定可能な FIDO2認証情報（Passkeys / パスキー）の使用を拒否し、代わりにデバイスにバインドされた FIDO2認証情報の使用を要求します。そうしないと、パスキーは、管理されていないデバイスやクラウドサービスのアカウントから盗まれる可能性があります。
• Okta Admin Consoleへのアクセスには、信頼できる管理対象デバイスからのアクセスを要求します。
• 管理対象のブラウザからのアクセスを要求します（つまり、管理者がブラウザから個人アカウントにサインインすることを許可しません）。
• エンドポイントセキュリティの統合を使用し、セキュリティポスチャの貧弱なデバイスを用いたアクセスを拒否します。
• 動的ネットワークゾーンを使用して、匿名化プロキシやその他の信頼できないネットワークからの管理アプリケーションへのすべてのリクエストを拒否します。
• ポリシーでユーザーの行動とリスクを評価し、異常な認証要求（新しいデバイス＋新しいIPなど）に対して警告を発します。
• 上記の条件を満たさないOkta Admin Consoleへのアクセスに対して、明示的で包括的な拒否ルールを適用します。

盗まれたセッションによる攻撃範囲を縮小

保護対策の強度に関係なく、脅威モデルはマルウェアやその他の手段による管理者のセッショントークンの窃取とその利用も考慮する必要があります。

Oktaは、Okta Admin Consoleのデフォルトのセッション時間を変更し、攻撃者が、盗まれたセッショントークンを悪用する機会を制限するように設計されています。

すべてのOkta orgsでデフォルトで有効になっているASNセッションバインディングは、盗まれたセッションを想定外のコンテキストで利用される能力を制限します。セキュリティチームは、管理セッション中のすべてのリクエストを認証時に使用したのと同じIPにバインドする、Okta Admin ConsoleのIPセッションバインディングの実施をオプションで適用することができます。IPセッションバインディングは、すべての新しいOkta orgでデフォルトで有効になっています。

また、以下も推奨します。

• Okta Admin Consoleで保護対象アクションを有効化します。これにより、管理ユーザーがサードパーティの IDプロバイダを有効にしたり、管理ユーザーのすべての要素をリセットしたりするような重要な設定を変更する前に、ステップアップ認証が強制されるため、攻撃者が盗んだセッショントークンで実行できるアクションが大幅に削減されます。
• すべての管理アプリケーションにて、再認証の頻度を [ユーザーがリソースにサインインするたび] に設定します。これにより、盗まれたユーザーセッションを使用したアプリケーションへのアクセスが大幅に削減されます。
• Okta FastPass をプライマリ認証として選択します。Okta FastPass は、すべての OS/ブラウザプラットフォームにて高速で、一貫したユーザーエクスペリエンスを提供し、リアルタイムの AiTM フィッシング攻撃 (中間者攻撃)を防止・検出し、認証情報を承認されたデバイスに制限する機能を提供します。また、セッショントークンの窃取を軽減する役割も果たします。Okta FastPass は、アクセスを許可する前に、管理対象および非管理対象デバイスのデバイスシグナルを評価するように設定できます。Oktaは、セッション中にユーザーが新しいアプリケーションを要求するたびに、これらのデバイスシグナルを使用してデバイスコンテキストを評価し、デバイスコンテキストが変更されたと評価された場合には再認証を要求することができます。

最後に、管理ロールの使用を監査し、疑わしい管理アクティビティを監視することが重要です。以前の投稿で取り上げたように、管理者ロールを持つユーザーが実行するアクションの監視と監督は、適切に設計されたセキュリティプログラムの要です。

SIEM上でOktaシステムログのイベントに最速でアクセスするには、ログストリーミングを使用することをお勧めします。SplunkおよびGoogle Chronicleとのコラボレーションで公開した一般的な検出のサンプルをご覧いただけます。

ASNとIPセッションバインディングを導入している組織に関連する新しいイベントを以下に示します。

​

Oktaのエンジニアリングチームは、この90日間、Oktaの管理機能へのアクセスの保護に必要なガードレールと追加機能を提供するため、全力で取り組んできました。

リリースから３か月以内に9,000以上のOkta orgがASNセッションバインディングを採用したことで、この機能がいかに必要とされているかを確信し、すべてのWorkforceのお客様にデフォルトで有効化することとなりました。Okta orgs の 95% 以上が、1 月にすべてのお客様に対して有効化したデフォルトの最大セッション時間とアイドルセッション期間の設定を維持しています。

私たちは、Okta Secure Identity Commitmentのもと、特権ユーザーを保護する機能を優先することに引き続き取り組んでいきます。

以上の内容は、原文（英語）の参考和訳であり、原文と内容に差異がある場合は、原文が優先されます。