はじめに
連携 / SDK
ユーザー認証
法人確認
トランザクションモニタリング
変更履歴
監査ログを使う理由
監査ログへのアクセス
Didit ConsoleでSettings > Organization > Audit logを開きます。組織内で行われたすべてのAPIリクエストが時系列で一覧表示されます。 各ログエントリには次の情報が含まれます。調査担当が下した判定
調査担当が自ら下した判定は、メンバーやAPIキーではなく調査担当として記録されます。対象となるのは、セッションの承認・却下や再提出の要求、取引のステータス設定、ケースの解決・エスカレーション・情報要求です。 エントリには、その判定に対応する調査担当のレポートへのリンクが含まれます。 担当者が調査担当の推奨を受け入れた場合や覆した場合、エントリはその担当者として記録されます。フィルターと検索
監査ログの画面には強力なフィルター機能があり、探している情報を正確に見つけられます。スマート検索
検索バーは、入力内容から検索対象を自動的に判別します。利用できるフィルター
データ保持
監査ログをどこまでさかのぼって閲覧できるか、またエクスポートできるかどうかは、プランによって決まります。
エクスポートに対応していないプランでエクスポートを行うと、
"code": "plan_limit_exceeded"を含む403が返されます。
セキュリティとプライバシー
記録される情報
監査ログには、APIリクエストに関する次のメタデータが記録されます。- リクエストのタイムスタンプと所要時間
- ユーザーの識別情報(メールアドレス、ユーザーID)、またはリクエストを行ったAPIキー(キーの名前とシークレットの先頭数文字のみで、シークレット全体は決して記録されません)
- リクエストパスとクエリパラメーター
- レスポンスのステータスコード
- クライアントのIPアドレスとユーザーエージェント
APIキーによる呼び出しのリクエスト本文とレスポンス本文
APIキーで行われた呼び出しについては、書き込みのJSONリクエスト本文と、書き込みまたはエラーに対するレスポンスのマスキング済みコピーも監査ログに保持されるため、呼び出しが失敗した理由を確認できます。 成功した読み取りに対するレスポンスは保持されません。 マスキングはデフォルト拒否方式です。- 構造は保持されます。フィールド名、ネスト、値の型、配列の長さ、文字列の長さが対象です。
- 値が保持されるのは、Diditが定義するフィールド内にあり、そのフィールドが想定する形式を持つ、Didit独自の識別子、ステータス、コード、件数、タイムスタンプのいずれかである場合のみです。
- 真偽値が保持されるのは、Diditが定義するフィールド内にある場合のみです。
- それ以外の値はすべて、
[redacted:string:12]、[redacted:number:5]、[redacted:boolean]のように型と長さを示すマーカーに置き換えられます。nullはnullのまま保持されます。 - キーとして使われたメールアドレスや電話番号など、単純な識別子ではないフィールド名は
[redacted:key:23]に置き換えられます。 - フォームやファイルアップロードなど、JSONではない本文は、その内容の種類を示す注記に置き換えられます。
- 残った内容は4,096文字で切り詰められます。
content-type、user-agent、レート制限ヘッダーなどの標準ヘッダーのみで、それ以外のヘッダーは値ごと破棄されます。
metadataやvendor_dataなど、お客様のシステムから送信される値は、フィールド名がDiditのフィールドと同じ名前であっても、決して保持されません。
記録されない情報
機密データを保護するため、次の情報は自動的に除外されます。- 認証トークンと認証情報
- パスワードとシークレット
- 検証セッションの個人データ
アクセス制御
監査ログを閲覧するには、audit-logsの読み取り権限と一覧表示権限が必要です。Reader、Compliance Officer、Developer、Admin、Ownerの各役割にはこれらの権限があり、カスタム役割の場合は役割エディターでAudit logsを選択すると付与されます。
主なユースケース
コンプライアンス監査
コンプライアンス監査
誰が検証データにアクセスしたかを完全に把握できていることを監査人に示します。
- 監査対象期間に合わせて日付範囲でフィルターします
- 必要に応じて、特定のアプリケーションやユーザーでフィルターします
- 記録用に結果をエクスポートするか、スクリーンショットを撮ります
セキュリティ調査
セキュリティ調査
不正アクセスが疑われる場合は、次の手順で調査します。
- 影響を受けたユーザーのメールアドレスや不審なIPアドレスで検索します
- インシデントが疑われる時期の前後の日付範囲でフィルターします
- 認証の失敗、想定外のエンドポイント、不自然な時間帯など、通常と異なるパターンを探します
連携のデバッグ
連携のデバッグ
API連携の問題をトラブルシューティングする場合は、次の手順で確認します。
- 対象のエンドポイントパスで検索します
4xxまたは5xxのステータスコードでフィルターしてエラーを見つけます- タイムスタンプを控え、自社アプリケーションのログと照合します
チームのアクティビティ確認
チームのアクティビティ確認
チームがプラットフォームをどのように利用しているかをモニタリングします。
- 特定のチームメンバーのメールアドレスでフィルターします
- どのセッションや機能にアクセスしたかを確認します
- チームメンバーが適切な手順に従っていることを確認します
ベストプラクティス
- 定期的な確認: 監査ログを定期的に確認し、異常を早期に発見します。
- 検索を絞り込む: 具体的なフィルターを使ってノイズを減らし、関連するエントリーをすばやく見つけます。
- 日付範囲: 大規模なデータセットでパフォーマンスを高めるため、常に日付範囲を指定します。
- 検索をブックマークする: よく使うフィルターの組み合わせをブラウザのブックマークに保存し、すばやくアクセスできるようにします。