Databricks における認証情報の悪用攻撃の検出

Databricksでは、お客様にとってデータが最も価値のある資産であることを理解しています。Databricksは、何千もの顧客と協力し、セキュリティ、プライバシー、および規制の要件を満たすために適切な機能を備えたDatabricks Data + AI Platformを安全にデプロイしてきました。

現代のサイバー攻撃は、常に強固な境界の突破から始まるとは限りません。正当なログインから始まります。攻撃者が漏洩したセッションクッキー、個人アクセストークン（PAT）、またはサービスプリンシパル認証情報を取得した時点で、最初の侵害はすでに完了しています。その瞬間から、彼らの主な目的は紛れ込み、侵害されたユーザーやサービスのふりをして活動することです。

しかし、鍵を持っているからといって、建物の構造を知っているわけではありません。侵入者がバッジをスワイプして安全なオフィスに入る場面を想像してみてください。回転ドアを通過できたとしても、警備員をかわし、アクセスできるフロアを推測し、金庫の場所を見つけ出さなければなりません。攻撃者には実際の従業員が持つ深いローカルな文脈が欠けているため、その行動はやがてボロを出します。そうした異常を見つけることが、攻撃者を捕らえる方法です。

この記事では、Databricksプラットフォーム上で認証情報駆動型攻撃がどのように展開されるか、Databricksの詳細な監査ログとGenieを使用してIDの行動の変化を検知する方法、侵害を確認した後の対応方法、そしてそもそも盗まれた認証情報の被害を制限する制御について解説します。

認証情報駆動型攻撃を追跡するためのモデル

正当な認証情報を介してアクセスを確立する場合、攻撃者は、セキュリティ担当者と同様に、IDの期待される行動から大きく逸脱した時点でいつでもアクセスが取り消される可能性があることを理解しています。攻撃者は非線形の攻撃シーケンスに依存します。たとえば、1組の認証情報を検証して環境をマッピングし、その後別の組の認証情報を取得して、偵察活動が関連付けられていない新しいIDやワークスペースを通じて戻ってくるといった具合です。さらに、攻撃者は永続性を確立せずに情報を収集したり、目的を完了する前にDatabricksプラットフォームに戻る方法を確立したりすることがあります。

実際の例

誤設定された継続的インテグレーションおよびデリバリー（CI/CD）ログから個人アクセストークンがコピーされたデータエンジニアを考えてみてください。数分以内に、そのトークンが新しいIPから使用され、ワークスペース全体のシークレットスコープ、カタログ、およびリポジトリがリストされます。これはこのエンジニアが一度も行ったことのない行為です。サービスプリンシパル認証情報を保持するシークレットが読み取られます。1時間後、エンジニアではなくそのサービスプリンシパルが関数を作成し、自身を管理者グループに追加し、いくつかの初期化スクリプトをエクスポートします。これらのイベントのそれぞれは通常のプラットフォームの使用に見えるかもしれませんが、これらを総合すると、1件の侵入が攻撃チェーンを進んでいることがわかります。

Databricksでは、認証情報駆動型攻撃に関連する非線形のイベントシーケンスを想定しており、個別のイベントとして扱うのではなく、このモデルを使用して個々のイベントを1つの調査に結びつけています。

認証情報駆動型攻撃の6つの段階

攻撃者がDatabricksなどのPlatform-as-a-Service（PaaS）環境で侵害された認証情報を悪用する場合、その活動は6つの段階に分類できますが、直線的に進むことはめったにありません。以下の各段階では、攻撃者が何をしようとしているか、およびDatabricksの監査ログテーブルで何を探すべきかを説明しています。このガイダンスを出発点とし、環境の通常の自動化に合わせて調整してください。

注：イベントは次のように書き込まれます service_name.action_name、例： secrets.getSecret。

1. 攻撃者が有効な認証情報でアクセスを取得する

ログイン自体が異常に見えることはめったにありません。認証情報は本物であるため、正当な所有者の場合と同様に認証は成功します。しかし、サインインした直後の数分間にIDが行うことは、通常の活動とは大きく異なることが多く、その変化こそがレスポンダーが検知できるものです。データエンジニアの例では、盗まれたトークンでの認証が成功し、ログイン時の唯一の違いはエンジニアが使用したことのない送信元IPです。その後の活動が際立っています。

攻撃者の目標： 盗まれたブラウザセッション、リプレイされたPAT、またはサービスプリンシパル認証情報など、有効な認証情報を使用してワークスペースにアクセスし、コントロールが許可するように設計された活動に紛れ込むことです。

確認すべき事項：

• 認証イベントをタイムラインの出発点として使用します。ログイン単体でアラートのトリガーになることはめったにありませんが、その user_identity、 source_ip_address, user_agent、 sessionId、 request_id、および workspace_id を使用して、認証情報のその後の動きを追うことができます。
• 見慣れないクライアントから短時間のバーストで到着し、その後異なる送信元IPから同じトークンが使用される accounts.tokenLogin イベントにフラグを立てます。このパターンは、誰かが盗まれたトークンをテストしていることを示している可能性があり、 requestParams.tokenId を使用してこれらのイベントを同じトークンに関連付けることができます。
• 予想されるネットワークから予想外のユーザーエージェントで生成されたサービスプリンシパルOAuthトークンにフラグを立てます。特に、新しい送信元IPからの活動が1分以内に続く場合に注意してください。

2. 攻撃者が環境をマッピングする

次に、攻撃者はアクセスが取り消される前に、認証情報がどこに到達できるかを把握する必要があります。その結果、侵害されたIDは、数秒以内に通常の活動からデータ、シークレット、コード、ネットワーク制御のリスト化へと切り替える可能性があります。この偵察は通常、複数のサービスにまたがり、UIを操作する人間よりも速く進みます。私たちのシナリオでは、この段階は、トークンが使用されてから数分以内にシークレットスコープ、カタログ、リポジトリをリストする一連の呼び出しであり、これはエンジニアがこれまでに行ったことのない活動です。

攻撃者の目標： アクセスが取り消される前に環境のより深い場所へのパスを計画するために、アクセス可能なデータ、認証情報、リポジトリ、およびガードレールのマップを作成します。

確認すべき事項：

• 単一のIDがワークスペースおよびアカウントプレーン全体で迅速なリスト呼び出しを行っていること（例： secrets.listScopes / listSecrets、 unityCatalog.listMetastores / listCatalogs / listSchemas / listExternalLocations / listStorageCredentials、 repos.listRepos、およびアカウントレベルの accountsManager.listWorkspaceConfigurations / listNetworkConfigurations / listStorageConfigurations）を確認します。たとえば、1分以内に5つ以上の異なる検出APIが呼び出された場合、プラットフォームを操作している人間である可能性は低いと言えます。
• 活動をIDのベースラインと比較します。確立されたIDによって行われた最初のシークレット列挙、またはビジネス用のクエリからアクセス制御および構成スキーマに対する SHOW TABLES に切り替わるSQLセッションは、大量の呼び出しよりも意味があります。詳細な監査ログが有効になっている場合、 commandSubmit は commandText 内でクエリを保持します。
• 検索に失敗したリクエストも含めます。IDによる最初の IpAccessDenied を調査します。特にそれが accounts.oidcTokenAuthorization に続く場合や、ワークスペース間で繰り返される場合に調査します。その場合、承認は成功したものの、リクエストがブロックされたネットワークから発信されたことを意味し、これは信頼されていないロケーションから認証情報がリプレイされたことを示す最も古い記録であることがよくあります。

3. 攻撃者がさらに多くの認証情報を収集する

認証情報の収集には通常、複数のステップが含まれます。攻撃者はシークレットスコープをリストし、その中のシークレットをリストし、役立ちそうなものを読み取ります。取得した値により、異なる、多くの場合より特権の高いIDとして戻ることが可能になります。このため、不審なIDによって読み取られたすべてのシークレットは追跡する価値があります。データエンジニアの例では、攻撃者はサービスプリンシパル認証情報を保持するシークレットを読み取ります。その時点から、調査ではエンジニアとサービスプリンシパルの2つのIDを追跡する必要があります。

攻撃者の目標： トークン、APIキー、またはサービスプリンシパルシークレットを取得し、初期の足場を新しいIDの下での環境全体へのアクセスに格上げします。

確認すべき事項:

• 呼び出しの進行状況に関するアラート。secrets.listScopes単体での発生は一般的であり、ノイズを生み出します。しかし、listScopesの後にlistSecrets、そしてgetSecretが続き、複数のスコープにわたって短期間に繰り返される場合は、データ収集が行われていることを示します。listSecretsはスコープを記録し、getSecretはスコープとキーの両方を記録します。
• 拒否された読み取りと、その後の成功した読み取りを関連付けます。厳密に制御されたスコープに対する拒否されたgetSecretの後に、制限の少ないスコープで同じキーまたは関連するキーの読み取りが成功した場合、そのIDがアクセス可能なコピーを探していることが示唆されます。
• シークレット API に加えて、コンピュート側のアクセスも監視します。詳細な監査ログが有効になっている場合、ノートブックのsubmitCommandおよび Databricks SQL のcommandSubmitイベントには、シークレットユーティリティを呼び出すコードや、資格情報を含むパスに対してread_files()を実行するコードが表示されることがあります。送信されたテキストは実行された内容を示しているものの、値が返されたことを確約するものではないことに注意してください。
• 各シークレットの読み取りを、新しいaccounts.tokenLogin、初めて検出されたサービスプリンシパルのアクティビティ、変更された IP またはユーザーエージェント、あるいはgenerateTemporaryTableCredential / generateTemporaryVolumeCredentialの呼び出しなどの後続のアクションと関連付けます。レスポンス時には、そのIDが到達可能性のあったすべての資格情報をローテーションし、保管されていた場所だけでなく、それぞれが使用されていた場所も確認します。

4. 攻撃者が実行可能な実行パスを見つける

アクセスが確立されると、攻撃者は独自のコードを実行する方法を探します。Databricks では、これは通常、ユーザー定義関数 (UDF) とジョブを通じて行われます。関数はペイロードを通常のコードのようにラップして繰り返し呼び出すことができ、ジョブはそのコードをさまざまなコンピュート上でスケジュールに従って実行できます。そのため、検出における重要な疑問は、IDがこれまで実行したことのないアクションを開始したかどうかです。データエンジニアに戻ると、シークレットが読み取られてから1時間後、サービスプリンシパルが関数を作成します。エンジニアではなくサービスプリンシパルがこのアクションを実行するため、エンジニアのアクティビティのみを対象とした検索では見逃してしまいます。

攻撃者の目標: 1つのコンピュート経路がブロックされた場合のフォールバックを備え、ペイロードを実行するための信頼性が高く再利用可能な方法を確立する。

確認すべき事項:

• 関数を作成した履歴のないID、IP、またはカタログからの createFunction イベントを優先して検出します。特に、短期間に複数のイベントが発生した場合は注意が必要です。関数定義を利用できる場合は、プロセスを実行するコード、動的にコードを評価するコード、インスタンスメタデータにアクセスするコード、アウトバウンドネットワーク接続を開くコード、またはクラウドストレージに書き込むコードにフラグを設定します。また、一見無害に見えるラッパーが高リスクの UDF を呼び出す可能性があるため、関数間の参照も追跡します。system.access.audit内のfunction_infoは、アカウント管理者とdatabricks_pii_accessを除いてマスクされるため、監査データを関数インベントリと組み合わせて使用してください。
• ID、IP、およびジョブまたは実行IDごとに Jobs のパスを追跡します。一般的なシーケンスは、importNotebook、次にchangeJobAcl、Jobs create、runNow、そしてgetRunOutputです。これらのイベントはノートブックの本文を保持することがほとんどないため、ノートブックのバージョンとジョブ構成をそれらと一緒に保持してください。1つのソースからのインポートと実行の繰り返しアクティビティは、どちらか一方のアクション単体よりも強力なシグナルとなります。
• 障害後にコンピュートを切り替えるIDを探します。たとえば、クラスター作成の失敗やsubmitRunの直後にstartWarehouseが発生したり、異なるコンピュート上で新しいジョブが実行されたりする場合、攻撃者がブロックされたパスを回避している可能性があります。レスポンスコードとイベント間の短い間隔が、このシーケンスを通常のエラーから区別する要素となります。サーバーレスコンピュートは一般的なフォールバックです。

5. 攻撃者が永続性を確立する

コードを実行する手段を手に入れた攻撃者は次に、元の資格情報が取り消された後でも戻ってこられるようにしようとします。一般的な永続化の方法には、アクセス許可、新しく作成されたトークン、グループおよびワークスペースのメンバーシップの変更、コントロールプレーンの編集などがあります。最も有用なシグナルは、見慣れないIDや実行コンテキストによって行われた機密性の高い変更です。たとえば、ジョブ内から行われた権限の変更は、コンソールで管理者によって行われた同じ変更よりも厳密に調査する必要があります。シナリオの続きとして、サービスプリンシパルが自身を管理者グループに追加します。エンジニアのトークンが取り消されたとしても、そのグループメンバーシップにより攻撃者のアクセスが維持されます。

攻撃者の目標: 侵害された資格情報が取り消されても存続する、持続的で独立したアクセスパスを作成する。

確認すべき事項:

• シークレットスコープ、updatePermissionAssignment、addPrincipalToGroup、またはsetAdminに対するputAclなど、予期しないコンテキストからの権限およびIDの付与に関するアラートを出します。サービスプリンシパルが別のIDにアクセス権を付与した場合や、短期間に複数の割り当てが発生した場合は特に注意を払ってください。
• セキュリティ制御を変更しようとする試みは、失敗した場合でも高重要度として扱います。これには、setSetting / deleteSetting、IPアクセスリストの編集、およびcreatePrivateAccessSettingsが含まれます。制御が実際にバイパスされたかどうかを結論付ける前に、要求された変更、レスポンス、およびソースを確認してください。また、期待される IdP 以外からの SCIM グループの変更も確認してください。
• 見慣れないソースからの、またはジョブの実行中のgenerateDbTokenの呼び出しにフラグを設定します。結果として得られる各トークンは、取り消しが必要となる個別の資格情報になります。
• 自身で継続するワークロードに注意します。コントロールプレーンのイベントを、run_by、run_as、および期待される実行ウインドウと相関させます。攻撃者のインタラクティブなアクティビティが停止した後もジョブがグループ、権限、または設定の変更を続けている場合、それ自体でアクセスを維持している可能性があります。ジョブを終了する前に、ジョブの定義と成果物を保存してください。

6. 攻撃者がデータを収集しアクセスをクリーンアップする

データ収集はいくつかのターゲットを絞ったエクスポート程度のごく小規模な場合があり、クリーンアップにはファイルの削除以上の作業が含まれることがあります。ターゲットを絞ったエクスポート、一時的な資格情報の要求、短命なツールの削除、およびアクティビティの再構築を困難にする難読化されたコマンドに注意してください。これらのイベントのいずれか単体ではルーチンワークのように見えるため、個々のエクスポートや削除よりも、それらを囲むシーケンスの方が重要になります。最後に、私たちのシナリオのサービスプリンシパルが少数の初期化スクリプトをエクスポートします。それ単体では小規模なエクスポートです。しかし、同じサービスプリンシパルによるシークレットの読み取りと新しい関数の作成に続くものであるため、同じ侵入の一部として調査する必要があります。

攻撃者の目標: 重要なデータを持ち出し、最も明白なツールを消去する一方で、より静かなアクセスを残しておく。

確認すべき事項:

• エクスポートの数ではなく、各エクスポートのコンテキストを確認します。workspaceExportは、パス、形式、および直接ダウンロードされたかどうかを記録します。見慣れないIDによるエクスポート、通常とは異なるパスや形式へのエクスポート、これまでに見られなかったネットワークからのエクスポート、またはシークレットへのアクセスや新しい実行に続くエクスポートを優先して調査します。初期化スクリプトの小さく絞り込まれたエクスポートは、一括のSOURCEのダンプよりも多くの情報を漏洩させる可能性があります。
• 短命なオブジェクトの記録を保持します。1つのセッション内で同じ関数に対してcreateFunctionの後にdeleteFunctionが実行されたり、作成、削除、再作成のサイクルが繰り返されたりする場合は、証拠隠滅の試みである可能性があります。何かを元に戻す前に、定義とタイミングを保存してください。存続したオブジェクトには、削除されたものよりももっともらしい名前が付けられていることがよくあります。
• 一時的な認証情報とデータ読み取りのバースト（generateTemporaryTableCredential、generateTemporaryVolumeCredential、Delta Sharing、クラウドストレージの読み取り）を、以前の偵察活動に関連付けます。エンコードされたスクリプトやコマンドはよく使われるため、それ単体でアラートを出すのは難しいため、見慣れないユーザーエージェント、自動化のようなタイミング、シークレットへのアクセス、新しい関数などと関連付けて確認してください。

Genieを使用した認証情報ベースの攻撃の調査

認証情報ベースの攻撃チェーンを手引きとして使用することで、すべてのクエリを最初から記述することなく、Genieに攻撃ステージを進めさせることができます。この投稿のすべての検出は、すでに持っているテレメトリー上で実行されます。Databricksは、コントロールプレーンのアクティビティをsystem.access.auditシステムテーブルに書き込みます。

始めるには、Detection Appをインストールします。これにより、Databricksの監査ログ用のGenieエージェントが追加されます。Genie Oneからは、次の2つの方法で利用できます：

• 「user@example.comが昨日エクスポートしたノートブックは何ですか？」のように、自分の言葉で質問します。GenieがSQLを記述して実行します。
• 組み込みの検出機能を使用します。Detection AppのGenieエージェントには、トークンの悪用から管理者権限の付与まで、30を超える検出機能が含まれています。「先週、個人用アクセストークンを作成したのは誰ですか？」と質問すると、Genieは新しいSQLを書く代わりに一致する検出を実行します。「過去90日間に侵害されましたか？」などの目標を設定すると、検出を1つずつ実行していきます。

2つの制限事項に留意してください。まず、結果が空であっても、何も起こらなかったとは限りません。イベントが時間枠の外にあるか、詳細な監査ログが無効になっている可能性があります。次に、監査ログには「何が変更されたか」と「誰が変更したか」は記録されますが、変更前や変更後の値は記録されないことがよくあります。

検出から対応へ

ハントによって通常のパターンに当てはまらないアイデンティティが浮上したら、攻撃者が依然としてどのようなアクセス権を持っているかに焦点が移ります。認証情報ベースの攻撃は非線形であるため、最初に見つかったアクセス権が唯一のアクセス権であることはめったにありません。データエンジニアの例では、エンジニアのトークンを取り消しても、サービスプリンシパルの認証情報、その管理グループのメンバーシップ、およびそれが作成した関数はそのまま残ります。完全な対応では、元の認証情報だけでなく、悪意あるユーザーが無効化された後も実行され続ける権限、トークン、関数、ジョブなど、攻撃者がその後に作成したすべてのパスも削除します。

ワークスペースの侵害が疑われる場合、対応担当者は次の手順を実行する必要があります：

1. アイデンティティを無効化する。アカウントレベルでユーザーを非アクティブ化すると、すべてのワークスペースがブロックされます。ユーザーのブラウザセッションを終了するためのAPIはありませんが、非アクティブ化によりブロックされます。サービスプリンシパルの場合は、OAuthシークレットを削除し、アカウントSCIM APIを使用して非アクティブ化します。サービスプリンシパルがすでに持っているOAuthトークンは、最大1時間有効なままになります。
2. 個人用アクセストークンを取り消す。ユーザーを非アクティブ化してもトークンは削除されず、ユーザーが再度有効化されるとトークンは再び機能します。トークン管理APIまたはアカウントコンソールのトークンレポートを使用してください。
3. 必要なものを保存し、コンピュートを停止する。最初にジョブ定義とノートブックのバージョンをエクスポートします。次に、ジョブ実行をキャンセルし、クラスターを終了し、SQLウェアハウスを停止します。サーバーレスの場合は、実行またはステートメントをキャンセルします。ユーザーを非アクティブ化しても、すでに実行中のコンピュートは停止しません。
4. アクターが読み取ったすべてのシークレットをローテーションする。元凶で変更してから、保存された値を更新します。攻撃者が侵入に使用した認証情報もローテーションします。
5. アクターが作成した永続性を元に戻す。シークレットスコープのACL、ワークスペースの割り当て、グループメンバーシップを削除します。関数をドロップし、権限を取り消します。独自の記録からコンテキストベースのイングレスポリシー（および使用している場合はIPアクセスリスト）を復元します。
6. アイデンティティが変更する可能性のあるコードを確認する（初期化スクリプトやクラウドストレージ内のETLコードなど、Databricks外のコード）。
7. 停止したことを確認する。アクターによるアクティビティを検索します。詳細な監査ログがオフになっていた場合は、オンにします。コマンドテキストは、オンになっている間に限りログに記録されます。

認証情報ベースの攻撃の防止

オフィスビルに例えるなら、コンテキストベースのイングレスは回転ドアを通過できる人を決定し、最小権限はバッジで開けられるフロアを決定します。早期の検出は対応時間を稼ぎますが、予防的コントロールは盗まれた認証情報ができることを制限します。以下のコントロールは、攻撃チェーンを断ち切る順序に近い形で、攻撃者から奪うものごとにグループ化されています。

盗まれた認証情報の侵入を防ぐ

認証情報の再利用に対する最も強力な予防的コントロールは、コンテキストベースのイングレスコントロールです。これは、単一のネットワーク境界に頼るのではなく、誰がリクエストを行っているか、どこから来たのか、何のためのものかを評価します。これは、多くの組織がVPNから移行するにつれて特に役立ちます。拠り所とする企業ネットワークがなくても、盗まれたトークンを所有者が実際に使用するコンテキストに制限できます。たとえば、権限のあるサービスプリンシパルからのリクエストを信頼できるネットワークからのAPIリクエストに制限しつつ、一般ユーザーには異なるポリシーを適用することができます。

• ワークスペースリクエストとアカウントリクエストの両方にポリシーを適用します。ワークスペースポリシーは、アカウントコンソールやアカウントレベルのAPIをカバーしていません。
• ドライランモードで開始します。system.access.inbound_networkで拒否とドライラン違反を確認し、特権サービスプリンシパルを最初に保護し、正当な自動化やパートナー連携を考慮した後に適用を有効にします。
• サーバーレスおよびプライベート接続のワークフローは異なるポリシー規則に従うため、幅広い適用の前にテストしてください。例外を文書化し、その使用状況を監視します。
• IPアクセスリストを追加のレイヤーとして扱います。両方が適用される場合、リクエストは両方を通過する必要があります。まだ使用している場合は、ワークスペースとアカウントコンソールのリストを設定してください。

収集された認証情報の価値を下げる

• サービスプリンシパルの認証情報、連携の認証情報、および個人用アクセストークンの有効期限とローテーション要件を設定し、使用されなくなった認証情報を廃止します。長期間使用されていない認証情報は、侵害が数カ月間気付かれない可能性があるため、攻撃者にとって特に魅力的な標的となります。
• シークレットスコープに対して最小権限を適用します。異なるACLを持つスコープに強力な認証情報のコピーを保存することは避け、スコープの内容をリストできるユーザーと値を取得できるユーザーの両方を確認してください。

認証情報が実行または変更できる範囲を制限する

• 影響度の高い操作を制限します。UDFの作成、シークレットスコープのACL変更、ワークスペースの権限変更、ジョブ管理、およびイングレスポリシーの変更を、承認されたアイデンティティと制御された自動化のみに制限します。
• 管理パスとコンピュートパスを分離します。通常のジョブランタイムからアカウントやネットワークの制御を変更できないようにし、変更が試行された場合はアラートを生成するようにします。
• クラウドの実行環境を保護します。必要に応じてハードニングされたメタデータサービスの構成を使用し、ワークロードが資格情報の エンドポイントや未承認の宛先に自由にアクセスできないようにコンピュートからの外向き通信を制限します。
• アカウントIDの管理、ワークスペースアクセスの割り当て、ジョブの作成を行うIDを制限します。

証拠の保持

• セキュリティ侵害の可能性に備え、調査にすぐ利用できるテレメトリーを保存します。
• 監査ログ、ノートブックとジョブのバージョン履歴、UDFの定義と依存関係、権限変更の履歴、クラウドストレージの書き込みイベント、コンテキストベースのイングレス拒否ログを、不正アクセスの全容を再構築するのに十分な期間保持します。

認証情報が盗まれた場合の影響範囲は、それに割り当てられている権限の大きさに比例することを覚えておいてください。次の手順を実行してリスクを軽減し、不審なアクティビティを検出できるようにしましょう。

• Databricks セキュリティのベストプラクティスを確認して、ワークスペースとアカウントのセキュリティを強化します。
• 詳細な監査ログを有効にし、両方のプレーンをカバーできるようにコンテキストベースのイングレス制御を設定します。
• Detection Appをデプロイして探索を開始し、Genieに最初の質問を投げかけてみましょう。「過去90日間に侵害を受けましたか？」

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事