このブログはこちらの英語ブログ（2024年3月21日公開）の翻訳、石橋 禎史によるレビューです。 特権ユーザーは、これまでも、そしてこれからも、活発な攻撃者から絶え間なく攻撃され続けることが予想されます。 この90日間、Oktaはリソースの多くを、Okta Admin Consoleを大幅に強化するための作業プログラムに投入してきました。その結果、以下のような数多くの新機能を実現しました。 新機能 説明 提供状況について ASN セッションバインディング APIまたはWebリクエスト時に観測されたASN（AS番号）が、セッション確立時に記録されたASNと異なる場合、Oktaは管理セッションを自動的に取り消します。 Okta Admin Consoleでデフォルトで有効、2023年10月23日から一般提供開始 IP セッションバインディング Okta管理者は、APIまたはWebリクエスト中に観察されたIPアドレスが、セッションが確立されたときに記録されたIPアドレスと異なる場合、管理セッションを自動的に取り消します。 Okta Admin Consoleにて、2024年2月7日から早期アクセス Okta Workflows Admin、Okta Access Requests、Okta Privileged Access (OPA)にて、2024年3月1日から早期アクセス 新しいデフォルトの最大セッション時間とアイドルセッション時間 Okta Admin Console アプリのデフォルトのセッションタイムアウトは、セッション有効時間が12時間、アイドル時間が15分に設定されました。 2024年1月8日から一般提供開始 保護対象アクション Okta Admin Consoleで重要なタスクを実行すると、再認証を求めらます。 Okta Admin Consoleにて、2024年2月7日から早期アクセス Okta 管理者ロールを管理 お客様は、期限付きのアクセス要求と自動化されたアクセスレビューによって、Okta管理者ロールを管理できます。 Okta Admin Consoleは、2024年4月から順次展開 Okta Admin ConsoleへのアクセスにMFAを要求 Oktaは、Admin Consoleへのアクセスに1要素のみを要求する認証ポリシーの作成を防ぎます。 Okta Admin Consoleにて2024年5月から早期アクセス このブログ投稿の目的は、これらの新機能の使用方法について全体像を把握し、総合的に考えることで、以下の実現を目指しています。 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のゼロスタンディング特権までのプロセスがよりシンプルになります。 すべての管理者に、日々の業務に必要な最小限のリソースと権限に設計されたカスタムロールを割り当てる。 一時的な（「ジャストインタイム」の）昇格権限を必要とする管理者のために、リクエスト承認プロセスを作成する。 昇格権限を持つロールにアクセスするには、2人以上の他管理者からの二重承認が求められる。 アクセス要求でアクションを作成し、承認後に昇格権限を割り当てられたグループにユーザーを追加し、指定された期間が経過した後にグループからユーザーを削除する。 このプロセスに必要な唯一の例外は以下のとおりです。 スーパー管理者ロールを持つ緊急アクセス用アカウント デプロイによっては、緊急アクセス用アカウントが必要になる場合があります。「break glass account」と呼ばれるこの緊急アクセス用アカウントは、信頼されたネットワークまたは PAMソリューションが利用不可であることを想定したポリシーによって保護しなければなりません。さらに（冗長性のために2次または3次のIP範囲を使用して）ネットワークの場所によってアクセスを制限し、多要素認証を要求することもお勧めします。一般的なアプローチは、アカウントに登録された複数の物理的なFIDO2セキュリティキーのうちの１つを要求するとともに、マシン生成された文字列をパスワードとして要求することです。このアカウントへのアクセスは、絶対的な警戒心を持って監視し、どんな使用であってもSOCの警鐘を鳴らすべきです。 M2M（マシンツーマシン）認証で使用されるサービスアカウント 人間以外の（マシンツーマシン）アクセスに使用されるアカウントを放置しないようにします。OAuth 2.0ベースのAPIサービスアプリケーションを使用できる限り使用し、必要最小限のアカウント権限とスコープを適用します。レガシーな静的APIトークンを統合に使用する場合は、OktaのIP許可リスト機能を利用してください。すべての静的APIトークンを保管し、その目的のインベントリを管理し、定期的に監査とローテーションを行います。設定後、サービスアカウントはOktaグループのメンバーとし、そのグループには対話的アクセスを拒否するグローバルセッションポリシーを適用します（注：これはAPIアクセスを制限するものではありません）。メンテナンス作業には、一時的にアカウントを別のポリシーに従わせる正式なアクセス要求プロセスが必要です。それ以外では、サービスアカウントによる未認可の対話的アクセスや共有アクセスを検知するために、注意深く監視する必要があります。 アカウント乗っ取りを防止 前述のように、Oktaは、Okta Admin Consoleへの不正アクセスを防止するために、最高クラスの機能を構築しています。これらの機能の多くは、デフォルトで有効です。 環境のレジリエンスは、ポリシーの適切な構成とそれをサポートする制御に大きく依存します。Okta Securityでは、少なくとも、以下を構成して管理ユーザーを保護することをお勧めします。 ThreatInsightをログおよび強制モードで有効にします。これにより、パスワードが必要なアカウントに対する大量の認証情報ベースの攻撃を検出し防止します。 管理者権限を持つグループに強力な認証ポリシーを適用します。 管理者ユーザーには、パスワードレスでフィッシング耐性のある認証機能（Okta FastPass、FIDO2 WebAuthn、スマートカード）を使用したサインインを要求します。 ポリシーでフィッシング耐性を強制します。 生体認証チャレンジ（推奨）または PIN によるアイデンティティの確認をユーザーに要求します。 Okta.