あらゆるOktaのトラブルの根本を突き止める方法
このブログはこちらの英語ブログ（2025年3月3日公開）の機械翻訳です。
このブログでは、技術的な問題をトラブルシューティングしている場合や、Okta Workforce IdentityのOrg内でフォレンジック調査を行っている場合に役立つ2つの新しいクエリを紹介します。
これらのクエリは、大量のOkta System Logイベントに追加された2つの新しいキー／バリューペアに基づいており、管理者、監査人、インシデント対応者がより迅速に業務を遂行できるよう設計されています。
この便利な方法は、OSICによってもたらされました。ご存知ない方のために説明すると、OSICとは「Okta Secure Identity Commitment」を意味し、アイデンティティ攻撃に対抗するために業界をリードするというOktaの長期的な取り組みです。
APIトークンを使用するすべてのイベント
最初に注目すべきオブジェクトは、RootApiTokenId です。RootApiTokenId は、APIトークンの作成時に初めて target.id として現れます（それが管理APIトークンであっても、OAuthトークンであっても関係ありません）。
eventType eq "system.api_token.create" and target.id eq "[RootApiTokenId]"
それ以降、このトークンが使用されて発生したすべてのログイベントの transaction.detail.rootApiTokenId に、同じ RootApiTokenId が記録されます。
もしこのトークンが侵害されたり、別の問題を引き起こしていたりする場合でも、以下の単一クエリでこのトークンを使用して行われたすべてのAPIアクションを検索できます：
transaction.detail.rootApiTokenId eq "[insert RootApiTokenId value]"
ただし注意点があります：Oktaの管理APIトークン（静的トークンまたはSSWSトークンとも呼ばれる）は、しばしば長寿命です。これらは管理者によって取り消されるかローテーションされるか、30日間使用されないと失効します。トークンが作成されてから90日以上経過している場合、Oktaのシステムログの保持期間外となり、作成イベントのみが見つかる状態になります。この場合は、これらのイベントをSIEMにストリーミングしてアーカイブしている場合にのみ追跡可能です。すべてのアクティブなトークンは、Okta管理コンソールの Security > API > Tokens に一覧表示されます。
本番環境のアプリケーションでは、静的トークンではなくOAuth 2.0トークンの使用を推奨します。後者は短命で送信者制約があり、トークンを作成したアカウントから独立して動作可能だからです。OAuth 2.0が使用できない場合は、統合に必要な最小限の権限のみを持つ専用のカスタム管理者ロールを使用して静的トークンを作成し、OktaがそのアプリへのAPIコールを期待する特定のIPアドレスまたはIPレンジに対してのみトークンの使用を許可するよう設定する必要があります。
ユーザーセッション中のすべてのイベント
次に注目すべきオブジェクトは RootSessionId です。
これはAPIトークンの使用を追跡するロジックとほぼ同じですが、今回はインタラクティブなユーザーセッションに適用されます。
RootSessionId は、インタラクティブユーザーがプライマリ認証で自身のアイデンティティを正常に検証した際に、authenticationContext.rootSessionId の値として最初に現れます：
eventType eq "user.session.start" and authenticationContext.rootSessionId eq "[RootSessionId]"
それ以降、このセッション中のすべてのログイベントに、同じ RootSessionId が authenticationContext.rootSessionId に記録されます。
そのセッションが侵害された可能性がある場合には、以下の単一クエリでそのセッションで行われたすべてのユーザーアクションを検索できます：
authenticationContext.rootSessionId eq "[insert RootSessionId value]"
あれ、どこかで聞いたような？
では、externalSessionId と RootSessionId の違いは何でしょう？似たようなことをするように聞こえますよね？
実際、ほぼ同じことをします。違いは、一部のユーザーアクションが新しい externalSessionId を生成するという点です。
たとえば、ユーザーが多要素認証のライフサイクルイベントを実行する場合、あらかじめ登録された要素を使って本人確認が求められます。これに成功すると、実質的に新しいセッションが開始されることになります。これは論理的には正しいのですが、トラブルシューティングや調査の際に全体像を把握しようとすると、externalSessionId のみを使った検索ではイベントの一部を見逃す可能性があります。これに対して RootSessionId は、セッションの有効期限が切れるか、ユーザーがサインアウトするまでのすべてのユーザーアクションに追加されるため、より包括的です。
このルールの唯一の例外は、以下のようなシステム生成イベントです：
- ユーザーが引き起こしたイベントに対して、Okta Platformが実行するアクション
- Okta Workflows、Okta Privileged Access、Okta Access Requests などによってトリガーされたイベント（これらは固有の識別子を持つ）
こうした例外ケースも捕捉するには、IPアドレスやアクターを基にしたアクションのスキャンも含めることを推奨します。以下のクエリは、rootSessionId の値を持たないアクションを特定するために使えます：
not(authenticationContext.rootSessionId pr) AND <your logic>
特定のユーザーに関連するすべての rootSessionId を持たないイベントを探す：
not(authenticationContext.rootSessionId pr) and actor.alternateId eq "[username value]"
特定のIPに関連するすべての rootSessionId を持たないアクションを探す：
not(authenticationContext.rootSessionId pr) and client.IpAddress eq "[IP address value]"
ユーザーがイベントの対象（target）であったすべてのアクションを探す：
not(authenticationContext.rootSessionId pr) and target.alternateId eq "[username value]"
SOCのその先へ
APIトークンに関連するすべてのイベントや、ユーザーセッションに関連するすべてのイベントを検索できるようになることで、自動化に関するさまざまな可能性も広がります。
これらのクエリを念頭に、検出ライブラリやOkta Workflowsを見直すことをお勧めします。これにより、あらゆる問題に対する創造的な解決策を見つける手助けとなるでしょう。
以上の内容は、原文（英語）の機械翻訳であり、原文と内容に差異がある場合は、原文が優先されます。
