조직의 모든 API 요청은 콘솔, 연동, 팀원 모두를 대상으로 365일 동안 기록됩니다. 설정 → 감사 로그에서 확인하세요.
조직 내 모든 API 요청은 콘솔, 자체 연동, 팀원 모두를 대상으로 자동 기록되어 365일 동안 보관됩니다. 설정 → 감사 로그에서 확인할 수 있습니다. 인베스티게이터가 스스로 내린 결정도 조사관으로 이곳에 기록됩니다.
#기록되는 내용
무엇을 통해 이루어졌든 조직 내에서 Didit 플랫폼에 요청된 모든 것이 기록됩니다. 각 항목에는 다음이 포함됩니다.
| 필드 | 내용 |
|---|---|
| Timestamp | 요청이 이루어진 시각 |
| User | 수행자: 요청을 보낸 멤버. API 키 요청의 경우 API 키 태그와 함께 키 이름이 표시되고, Didit이 스스로 한 일은 Didit, 인베스티게이터가 스스로 내린 결정은 조사관으로 표시됩니다 |
| Method | GET, POST, PUT, DELETE |
| Path | 호출된 엔드포인트 |
| Status | HTTP 응답 상태 |
| IP address | 요청이 온 위치 |
| Application | 어떤 애플리케이션에 속한 요청인지 |
로그는 365일 동안 보관된 뒤 자동으로 삭제됩니다.
각 변경 사항을 문장으로 설명하고 보고 있는 내용을 내보낼 수 있는, 새로 디자인된 감사 로그가 순차적으로 적용되고 있습니다. 조직에 적용되기 전까지는 이 페이지에 여기서 설명하는 요청 로그가 표시됩니다.
#실제 쓰임새
이 화면이 유용한 네 가지 상황입니다.
- "누가 이 워크플로우를 바꿨나요?" 어제와 다르게 동작하는 플로우는 대개 그 뒤에 변경 이력이 있으며, 로그는 누가 바꿨는지 알려줍니다.
- 인시던트 조사. 무엇이, 누구에 의해, 어느 주소에서, 어떤 순서로 접근됐는지 정확히 추적합니다.
- 연동 디버깅. 자신의 코드가 실제로 어떤 요청을 보냈는지 - 4xx로 끝난 요청까지 포함해서 - 짐작이 아니라 확인할 수 있습니다.
- 접근 통제 증빙. 인증 데이터 접근이 귀속되고 검토 가능하다는 것을 감사자에게 보여줄 수 있습니다.
#필터링
사용자(멤버, API 키, Didit 또는 조사관), 엔드포인트, 날짜 범위로 필터링해 긴 목록을 좁힐 수 있습니다. 특정 사안을 조사할 때는 타임스탬프에서 시작해 바깥쪽으로 확장하세요. 요청은 좀처럼 단독으로 발생하지 않으며, 그 주변의 호출들이 대개 전체 맥락을 알려줍니다.
#API 키 요청은 사람이 아니라 키에 귀속됩니다
API 키 요청에는 귀속시킬 사람이 없으므로 대신 키 이름이 표시됩니다. 이는 정직한 표현입니다. 플랫폼은 여러분의 어떤 서비스나 엔지니어가 그 호출을 만들었는지 실제로 알지 못하기 때문입니다.
실질적인 결과는 이렇습니다. 여러 서비스가 키 하나를 공유하면 사고 조사가 훨씬 어려워집니다. 귀속이 중요하다면 서비스마다 별도의 키를 부여하세요. API 키 관리하기를 참고하세요.
#인베스티게이터가 스스로 내린 결정은 인베스티게이터에게 귀속됩니다
인베스티게이터가 부여받은 자율성 범위 안에서 스스로 결정하면, 항목에는 사람이나 키가 아니라 조사관이 표시됩니다. 인베스티게이터가 내리는 모든 결정이 해당됩니다. 세션 승인 또는 거부, 사용자에게 재제출 요청, 거래 상태 설정, 그리고 케이스 해결, 에스컬레이션 또는 정보 요청입니다. 이러한 각 항목은 결정의 근거가 된 인베스티게이터 보고서로 연결되므로, 무엇을 발견했고 정책의 어떤 규칙을 적용했는지 확인할 수 있습니다.
사람이 인베스티게이터 보고서에 대해 결정하면, 즉 권고를 수락하거나 변경하면, 그 항목은 그 사람이 하는 다른 모든 변경과 마찬가지로 그 사람에게 귀속됩니다. 보고서, 질문, 안전 규칙을 포함한 인베스티게이터의 전체 기록은 계속 자체 활동 로그에 남습니다. 인베스티게이터 제어 및 감독하기를 참고하세요.
#로그에 담기는 것과 담기지 않는 것
이 로그는 활동을 기록합니다. 누가 무엇을 호출했는지, 언제, 어디서, 어떤 상태 코드가 반환됐는지입니다. 인증 데이터의 사본이 아니라 메타데이터 추적입니다.
이 항목에 고객 개인정보가 나타나는지 알아야 한다면 - 개인정보 보호 검토 과정에서 흔히 나오는 질문입니다 - 도움말 페이지에서 추론하지 말고 Didit 담당자에게 답을 받아 기록해 두세요. 이는 여러분의 DPIA에서 증빙을 요구받게 될 바로 그런 종류의 진술입니다.
#볼 수 있는 사람
감사 로그 접근 권한은 역할을 따릅니다. Compliance Officer는 포함되지만 Reader는 폭넓은 접근 권한을 갖지 않습니다. 오너는 커스텀 역할에 이 권한을 부여할 수 있습니다. 팀원 초대와 역할 설정을 참고하세요.
팀원을 제거해도 그 사람의 이력이 로그에서 사라지지 않습니다. 그것이 핵심입니다. 편집할 수 있는 추적 기록은 추적 기록이 아닙니다.
#내보내기와 리포트도 기록됩니다
세션 PDF나 CSV 내보내기를 생성하는 것도 API 호출이므로 누가 했는지와 함께 여기에 나타납니다. 인증 증거에 대한 접근이 통제되고 있음을 보여줘야 할 때 유용합니다. 검증 리포트 다운로드를 참고하세요.
#365일보다 길게 필요하다면
보존 기간은 365일로 고정되어 있습니다. 여러분의 의무 기간이 더 길다면, 필요한 만큼을 정기적으로 내보내 자체 시스템에 보관하세요. 세션 증거를 직접 보관하는 것과 같은 방식입니다. 필요한 기간을 정하는 것은 여러분 팀의 컴플라이언스 판단이며, 추측으로 설계해서는 안 됩니다.
감사 로그 보존 기간과 인증 데이터 보존 기간은 별개의 설정입니다. 세션 데이터의 보존 기간을 짧게 설정해도 감사 로그가 짧아지지 않으며, 그 반대도 마찬가지입니다. Didit가 사용자 데이터를 보호하는 방법을 참고하세요.
아직 해결되지 않았나요? 담당자와 이야기하세요.
조직 ID와 문의할 세션 ID를 함께 보내 주세요.