Oktaサービスには、すべてのイベントを包括的に確認して監査証跡を取得できる機能があります。管理者は、この証跡を基に、プラットフォームのアクティビティを把握して潜在的な問題を診断できます。 

この記事では、Okta管理者、またはテクニカルサポートエンジニア（TSE）によるパスワードとその他の要素のリセットまたは更新が記録されたOkta System Logを監査する方法について詳しく説明します。この記事では、TSEによるなりすましアクセスのクエリを検索する方法についても取り上げています。このアクセスはOktaサポートによるユーザー対応時にのみOkta管理者が許可できるものです。 

Okta System Logにイベントが保持されるのは3か月間のみであることに注意してください。お客様は独自のSIEM（セキュリティインシデントイベント管理システム）を利用して、それよりも長い期間データを保持できます。 

OktaではOkta System Logのイベント確認手順を網羅したリファレンスドキュメントを公開していますが、この記事の目的は、2022年1月16日～1月21日にSitel社のネットワークで発生したデバイス侵害についてお客様から寄せられた質問に具体的に回答することです。そのため、TSE（テクニカルサポートエンジニア）がOktaのお客様のテナントに対して行える管理上のアクションを監査する方法や、TSEがサポートの問題を解決するために一時的に管理者に「なりすまし」てAdmin ConsoleへアクセスするようにOkta管理者から依頼された場合に、実行する可能性のあるイベントを監査する方法の説明に今回の議論のスコープを限定しています。また、この記事では必要に応じてパスワードリセットやMFAの登録を行う方法についても順を追って説明しています。

この機能の詳細についてお知りになりたい場合は、Oktaカスタマーサポートでケースをオープンしてください。 

エンドユーザーのパスワードリセット：Okta System Logの検索

次の手順により、Okta管理者またはセキュリティアナリストは、エンドユーザーが開始したパスワードリセット、Okta org内で管理者が開始したパスワードリセット、TSEが開始したパスワードリセットを検索できます。成功したパスワードリセットのログは、パスワードリセットが発生したことを意味し、そのパスワードリセットがいつ行われたのかを示しています。

重要なのは、TSEはパスワードリセットを開始できますが、新しいパスワードを確認したり、パスワードを変更したりすることができない点を理解することです。なぜなら、TSEが新しいパスワードを確認したり、パスワードを正常に変更するには、当該ユーザーのメール受信ボックスにアクセスするか、多要素認証の要素/チャレンジに応答する必要があるからです。

1. Okta Admin Consoleにログインします。
2. ［レポート］>［System Log］の順に移動します。
3. 検索セクションで、次のクエリを貼り付けて、Okta Admin Consoleで認証された管理者によるリセットと、エンドユーザーによるセルフサービスリセットの両方を対象に、成功したパスワードリセットのイベントを検索します。

eventType eq "user.account.reset_password"

4. サポートエンジニアが開始したリセットのイベントを検索するには、次のクエリを使用します。

eventType eq "user.account.reset_password" AND actor.alternateId eq "system@okta.com" AND transaction.id eq "unknown"

5. 管理者がOkta Admin Consoleで「パスワードリセットのメール」のリンクから開始したリセットのイベントを検索するには、次のクエリを使用します。

eventType eq "system.email.password_reset.sent_message"

6. パスワード更新を含むイベントを検索するには、次のクエリを使用します。

eventType eq "user.account.update_password"

注：このイベントは管理者がAdmin Consoleで「一時パスワード」のリンクからリセットを開始した場合にもログに記録されます。

 

7. TSEが送信した一時パスワードによるイベントを検索するには、次のクエリを使用します。

eventType eq "user.account.update_password" AND actor.alternateId eq "system@okta.com"

エンドユーザーのMFAリセット：Okta System Logの検索

次の手順により、Oktaテナント内で行われたMFA要素のリセットを検索できます。成功したMFA要素のリセットのログエントリーは特定の要素がリセットされたことを意味し、リセットされた要素と、その要素がリセットされた時期を示しています。

1. Okta Admin Consoleにログインします。
2. ［レポート］>［System Log］の順に移動します。
3. 検索セクションで、次のクエリを貼り付けて、Okta Admin Consoleで認証された管理者による成功したMFAリセットを検索します。

eventType eq "user.mfa.factor.deactivate"

4. Admin Consoleで認証されたOkta管理者、またはTSEによるMFAの全要素のリセットを検索するには、次のクエリを使用します。

eventType eq "user.mfa.factor.reset_all"

注意：TSEがリセットを開始した場合、アクター名にはTSE名が表示されます。Okta管理者がAdmin Consoleでリセットを開始した場合、アクター名にはOkta管理者名が表示されます。 

Okta ClassicですべてのユーザーアカウントのMFAを有効にする

Oktaではアイデンティティ管理のベストプラクティスとして多要素認証（MFA）を推奨しています。以下では、Okta管理者としてMFAアカウントを有効にする手順を詳しく説明します。

1. Okta Admin Consoleにログインします。
2. ［セキュリティ］>［多要素］に移動します。
3. ［要素の登録］タブをクリックします。
4. ［多要素ポリシーを追加］をクリックします。ポリシー名と説明を入力します。
5. ポリシーを適用する必要のあるグループを選択します。全員に適用するのではなく、組織のセキュリティ要件に基づく特定のグループを選択することをお勧めします。この例では、「Everyone」グループを使用します。
6. ［有効な 要素］から、組織でサポートする必要のあるすべての要素を選択します。必須要素はユーザーによって登録される必要があります。任意要素によって、その他の一般的な要素をサポートできます。弱い要素を使用するとセキュリティ強度もその分低くなる点に注意してください。そのため、Oktaでは、SMS、音声、セキュリティ質問の使用を推奨しません。
    
7. 上の例では、すべてのユーザーが、Okta orgに次回ログインするときに、Okta Verify/プッシュ、Google Authenticator、FIDO2（WebAuthn）を登録する必要があります。これは一例です。組織のセキュリティ要件に合わせてその他の要素を選択できます。  
8. ［ポリシーを作成］をクリックします。

Okta Identity Engine（OIE）ですべてのユーザーアカウントのMFAを有効にする

1. Okta Admin Consoleにログインします。
2. ［セキュリティ］>［Authenticator］に移動します。
3. ［登録］タブをクリックします。
4. ［多要素ポリシーを追加］をクリックします。ポリシー名と説明を入力します。
5. ポリシーを適用する必要のあるグループを選択します。全員に適用するのではなく、組織のセキュリティ要件に基づく特定のグループを選択することをお勧めします。この例では、「Everyone」グループを使用します。 
6. ［有効な 要素］から、組織でサポートする必要のあるすべての要素を選択します。必須要素はユーザーによって登録される必要があります。任意要素によって、その他の一般的な要素をサポートできます。弱い要素を使用するとセキュリティ強度もその分低くなる点に注意してください。そのため、Oktaでは電話またはセキュリティ質問の使用を推奨しません。
    
7. 上の例では、すべてのユーザーが、Oktaテナントにログインするときに、Google Authenticator、Okta Verify、FIDO2（WebAuthn）を登録する必要があります。 
8. ［ポリシーを作成］をクリックします。

管理者としてユーザーパスワードのリセットを実行する

セキュリティアドバイザリーで以前述べたように、Oktaサービスは侵害されておらず、お客様がエンドユーザーのパスワードをリセットして是正措置を講じる必要はないという結論にOktaは確信を持っています。Oktaは今後もお客様にこのアクティビティに関する情報を提供し、Okta org内でOkta管理者が自律的に行える管理アクティビティの包括的な指針を示していきます。Oktaのセキュリティイベントに関するその他の情報については、Oktaの「よくあるご質問」と「Oktaセキュリティブログ」を参照してください。
 

Okta管理者として、Okta Admin Consoleでユーザーのパスワードをリセットする必要がある場合は、以下の手順に従うことで簡単にリセットできます。

1. Okta Admin Consoleにログインします。
2. ［ディレクトリ］>［ユーザー］の順に移動します。
3. ［ユーザーとユーザー名］列で対象のユーザーをクリックしてアクティブユーザーを選択します。 
4. ［パスワードのリセット］をクリックします。
    
5. 次の画面は2つのオプションを示しています。適用するオプションを選択します。

このユーザーのメインおよび予備のメールアドレスにパスワードのリセット用リンクが送信されます。Oktaをソースとするパスワードは自動的にリセットされるため、ユーザーはこのリンクをクリックしてパスワードを変更する必要があります。ユーザーのパスワードがADまたはLDAPの場合、ユーザーがこのリンクをクリックするまでパスワードはリセットされません。リンクの有効期限は1時間です。

対象のアカウントに一時パスワードが作成され、作成者である管理者に表示されます。アカウントは期限切れとしてマークされるため、ユーザーは次回のサインイン時にパスワードの変更を求められます。

Oktaサポートによってなりすましのアクセスが開始されたかどうかを確認する

お客様のスーパー管理者は、お客様のOkta orgに対するOktaカスタマーサポートのなりすましアクセスを許可できます。お客様のスーパー管理者は、このなりすましアクセスを8時間または24時間単位で許可することができます。Oktaサポートエンジニアが問題を解決するためにorgへのなりすましアクセスを開始すると、Okta System Logにエントリーが常に記録されます。なりすましのエントリーを検索する手順は次のとおりです。 

1. Okta Admin Consoleにログインします。
2. ［レポート］>［System Log］の順に移動します。
3. 検索セクションで、次のクエリを貼り付けてなりすましのアクセスを検索します。

eventType eq "user.session.impersonation.initiate"

Oktaサポートによってなりすましのアクセスが終了されたかどうかを確認する

サポートセッションを終えたサポートエンジニアはアクティブセッションからサインアウトします。このアクションによりOkta System Logにエントリーが記録されます。なりすまし終了のログエントリーを検索する手順は次のとおりです。 

1. Okta Admin Consoleにログインします。
2. ［レポート］>［System Log］の順に移動します。
3. 検索セクションで、次のクエリを貼り付けてなりすましのアクセスを検索します。

eventType eq "user.session.impersonation.end"

2022年4月12日修正

この記事の元のテキストに記載された「SuperUserからユーザーのメールアカウントに送信されたユーザーのパスワードリセット」のために提案されたクエリは、誤検出を生成するものでした。同じクエリで、セルフサービスのパスワードリセットも返されるためです。修正されたクエリ（「transaction.id eq "unknown"」を追加）は、正しい結果を返します。「not equals」演算子を使用する次のクエリは、セルフサービスのパスワードリセットのイベントを返します。

eventType eq "user.account.reset_password" and actor.alternateId eq "system@okta.com" and transaction.id ne "unknown"

関連資料

• アカウントの乗っ取り試行を検索するSystem Logクエリ