組織内のすべてのAPIリクエストは365日間記録されます。誰が、何を、いつ、どこから、どのアプリケーションで行ったかがわかります。

簡単な回答

組織内のすべてのAPIリクエストは自動的に記録され、コンソール、自社の連携、チームメンバーのものを問わず、365日間保持されます。設定 → 監査ログからご覧いただけます。インベスティゲーターが自ら下した決定も、調査担当としてここに記録されます。

#記録される内容

タイムスタンプとステータスコード付きのAPI活動を表示するDiditコンソールの監査ログ
組織内のすべてのAPIリクエストを365日間保持します。

組織内でDiditプラットフォームに対して行われたすべてのリクエストが、何によって行われたかを問わず記録されます。各エントリには次の情報が含まれます。

フィールド内容
Timestampリクエストが行われた日時
User実行者:リクエストを行ったメンバー。APIキーによるリクエストの場合は、キーの名前とAPIキータグが表示されます。Didit自身が行った操作はDidit、インベスティゲーターが自ら下した決定は調査担当と表示されます
MethodGET、POST、PUT、DELETE
Path呼び出されたエンドポイント
StatusHTTPレスポンスのステータス
IP addressリクエストの発信元
Applicationどのアプリケーションに属するリクエストか

ログは365日間保持された後、自動的に削除されます。

各変更を文章で説明し、表示中の内容をエクスポートできる、刷新された監査ログを順次提供中です。組織に提供されるまでは、このページにはここで説明しているリクエストログが表示されます。

#実際にどう使うか

これが適切なツールとなる4つの状況です。

  • 「このワークフローを誰が変更したか」 昨日と挙動が違うフローは、通常その裏に編集があり、ログが実行者を教えてくれます。
  • インシデントの調査。 何が、誰によって、どのアドレスから、どの順序でアクセスされたかを正確に追跡します。
  • 連携のデバッグ。 自社のコードが実際に行ったリクエストを確認できます。想定しているものではなく、実際に行われたもの(4xxになったものも含めて)です。
  • アクセス制御の証跡。 検証データへのアクセスが記録・確認可能であることを監査担当者に示せます。

#フィルタリング

ユーザー(メンバー、APIキー、Didit、調査担当)、エンドポイント、期間でフィルターし、長い一覧を絞り込めます。何か特定の事象を調査する場合は、タイムスタンプを起点に周辺を確認していってください。1件のリクエストが単独で起きることは稀で、その直前直後の呼び出しが状況を物語ることがほとんどです。

#APIキーによるリクエストは人物ではなくキーに紐づけられる

APIキーによるリクエストには紐づけるべき人物がいないため、代わりにキーの名前が表示されます。これは誠実な表現です。プラットフォームは、どのサービスやエンジニアがその呼び出しを行ったのかを実際には把握していません。

実務上の帰結として、複数のサービスで1つのキーを共有していると、インシデントの調査が大幅に難しくなります。帰属先を明確にしたい場合は、サービスごとに専用のキーを用意してください。APIキーの管理をご覧ください。

#インベスティゲーター自身の決定はインベスティゲーターに帰属します

インベスティゲーターが、あなたが与えた自律性の範囲内で自ら決定した場合、その記録には人やキーではなく調査担当と表示されます。対象は、インベスティゲーターが下すすべての決定です。セッションの承認・拒否・ユーザーへの再提出の依頼、取引のステータスの設定、ケースの解決・エスカレーション・情報リクエストが含まれます。これらの記録にはそれぞれ、決定の根拠となったインベスティゲーターのレポートへのリンクが付いており、何が見つかったのか、ポリシーのどのルールが適用されたのかを確認できます。

人がインベスティゲーターのレポートについて決定した場合(推奨を受け入れた場合も、変更した場合も)、その記録は、その人が行う他の変更と同じく、その人に帰属します。レポート、質問、安全ルールを含むインベスティゲーターの完全な記録は、引き続き専用のアクティビティログに残ります。インベスティゲーターの管理と監督をご覧ください。

#ログに含まれるものと含まれないもの

ログは活動を記録します。誰が何を、いつ、どこから呼び出し、どのステータスが返ってきたかです。これはメタデータの証跡であり、検証データのコピーではありません。

これらのエントリに顧客の個人データが含まれるかどうか(データ保護のレビューでよく出てくる質問です)を知る必要がある場合は、ヘルプページから推測するのではなく、Diditの担当窓口から回答を得て記録してください。まさに、自社のDPIAで証跡として求められる類いの記述です。

#誰が見られるか

監査ログへのアクセスはロールに従います。コンプライアンス担当者には含まれますが、閲覧者には広範なアクセス権はありません。オーナーはカスタムロールに付与できます。チームメンバーの招待とロールの設定をご覧ください。

チームメンバーを削除しても、ログ上の履歴は削除されません。それがこの仕組みの意義です。編集できる証跡は証跡とは言えません。

#エクスポートやレポートも記録される

セッションのPDFやCSVエクスポートの生成もAPI呼び出しであるため、誰が行ったかとともにここに記録されます。検証エビデンスへのアクセスが管理されており、誰でも見られるわけではないことを示す必要がある場合に有用です。検証レポートのダウンロードをご覧ください。

#365日を超える保持が必要な場合

保持期間は365日で固定されています。自社の義務がそれより長い場合は、必要な分を定期的にエクスポートして自社のシステムに保管してください。セッションのエビデンスを自社で保持する場合と同じ考え方です。必要な期間を決めるのは自社のコンプライアンス上の判断であり、思い込みで設計しないでください。

注記

監査ログの保持期間と検証データの保持期間は別の設定です。 セッションデータの保持期間を短く設定しても監査ログの期間は短くならず、その逆も同様です。 Diditによるユーザーデータの保護方法をご覧ください。

まだ解決しませんか?担当者に相談する。

組織 ID と、問い合わせたいセッション ID を添えてください。

サポートに問い合わせる