시작하기
연동 / SDK
사용자 인증
기업 확인
거래 모니터링
변경 내역
감사 로그가 필요한 이유
감사 로그 접근하기
Didit Console에서 Settings > Organization > Audit log를 엽니다. 인터페이스에는 조직 내에서 이루어진 모든 API 요청이 시간순 목록으로 표시됩니다. 각 로그 항목에는 다음 정보가 포함됩니다.조사관이 내린 결정
조사관이 자체적으로 내리는 각 결정은 멤버나 API 키가 아니라 조사관 아래에 기록됩니다. 여기에는 세션 승인 또는 거부, 재제출 요청, 거래 상태 설정, 케이스 해결, 케이스 에스컬레이션 또는 케이스 관련 정보 요청이 포함됩니다. 해당 항목은 그 결정에 대한 조사관 보고서로 연결됩니다. 사람이 조사관의 권고를 수락하거나 재정의하면, 해당 항목은 해당 사용자가 수행한 작업으로 기록됩니다.필터링 및 검색
감사 로그 인터페이스는 원하는 항목을 정확히 찾을 수 있도록 강력한 필터 기능을 제공합니다.스마트 검색
검색창은 찾으려는 내용을 자동으로 판단합니다.사용 가능한 필터
데이터 보존
요금제에 따라 감사 로그를 조회할 수 있는 기간과 내보내기 가능 여부가 결정됩니다.
내보내기를 지원하지 않는 요금제에서 내보내기를 요청하면
403과 "code": "plan_limit_exceeded"가 응답됩니다.
보안 및 개인정보 보호
기록되는 항목
감사 로그는 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, 컴플라이언스 담당자, Developer, Admin, Owner 역할에는 모두 이 권한이 있으며, 사용자 지정 역할은 역할 편집기에서 Audit logs를 선택하면 이 권한을 얻습니다.
일반적인 사용 사례
컴플라이언스 감사
컴플라이언스 감사
감사인에게 누가 인증 데이터에 접근했는지 전체를 확인할 수 있음을 입증하세요:
- 감사 기간에 해당하는 날짜 범위로 필터링합니다
- 필요한 경우 특정 애플리케이션이나 사용자로 필터링합니다
- 문서화를 위해 결과를 내보내거나 스크린샷으로 저장합니다
보안 조사
보안 조사
무단 접근이 의심되는 경우:
- 영향을 받은 사용자의 이메일이나 의심스러운 IP 주소를 검색합니다
- 의심되는 사고 전후의 날짜 범위로 필터링합니다
- 비정상적인 패턴을 찾습니다: 인증 실패 시도, 예상치 못한 엔드포인트, 이상한 시간대 접근
연동 디버깅
연동 디버깅
API 연동 문제를 해결할 때:
- 특정 엔드포인트 경로를 검색합니다
4xx또는5xx상태 코드로 필터링하여 오류를 찾습니다- 애플리케이션 로그와 대조할 수 있도록 타임스탬프를 기록해 둡니다
팀 활동 검토
팀 활동 검토
팀이 플랫폼을 어떻게 사용하는지 모니터링합니다:
- 특정 팀원의 이메일로 필터링합니다
- 해당 팀원이 접근한 세션과 기능을 검토합니다
- 팀원들이 올바른 절차를 따르고 있는지 확인합니다
모범 사례
- 정기 검토: 이상 징후를 조기에 발견하려면 감사 로그를 주기적으로 검토하세요.
- 검색 범위 좁히기: 구체적인 필터를 사용하면 불필요한 항목이 줄어들고 관련 항목을 더 빠르게 찾을 수 있습니다.
- 날짜 범위: 대용량 데이터셋에서 성능을 높이려면 항상 날짜 범위를 지정하세요.
- 검색 조건 북마크: 자주 사용하는 필터 조합을 브라우저 북마크로 저장해 빠르게 접근하세요.