블로그 · 2026년 5월 21일

Didit 웹훅으로 DORA 감사 추적 기록 구축하기 (KO)

DORA는 금융 기업이 ICT 시스템 전반에서 '무슨 일이 언제 누구에게 일어났는지' 증명할 것을 요구합니다. Didit의 본인 확인 웹훅을 사용하여 위변조 방지 감사 추적을 구축하는 방법과 JSON 예시를 소개합니다.

작성자: Didit2026년 5월 21일업데이트됨 2026년 5월 21일

DORA(디지털 운영 복원력법)는 금융 기관에 무슨 일이 일어났는지 증명할 수 있는가?라는 겉보기에는 간단하지만 어려운 질문을 던집니다. 감독관이 사건을 조사할 때, 감사관이 통제를 샘플링할 때, 또는 고객이 온보딩 결정에 이의를 제기할 때, 귀하는 정보통신기술(ICT) 시스템의 모든 이벤트에 대한 완전하고, 타임스탬프가 찍히고, 위변조 방지 기능이 있는 기록이 필요합니다. 본인 확인은 이러한 시스템 중 하나이며, 정확히 캡처해야 할 이벤트를 생성합니다.

이 게시물은 실용적인 내용을 다룹니다. Didit의 본인 확인 및 거래 웹훅을 DORA 준비가 완료된 감사 추적 기록으로 전환하는 방법, 저장할 내용, 그리고 조사를 견딜 수 있도록 만드는 방법입니다. 오늘 바로 구축해 볼 수 있는 웹훅 예시가 포함되어 있습니다.

핵심 요약

DORA는 증거를 요구합니다 — 사건 대응, 복원력 테스트 및 감독 검토를 위한 ICT 이벤트의 신뢰할 수 있는 기록.
Didit은 모든 중요한 상태 변경 시 웹훅 이벤트를 발행합니다: status.updated, data.updated, transaction.status.updated, 및 business.status.updated.
각 이벤트는 불변하는 로그에 추가하는 개별적이고 타임스탬프가 찍힌 사실이며, 이는 감사 추적의 기본 구성 요소입니다.
각 웹훅의 서명을 확인하고, 원시 페이로드를 저장하며, 기록된 레코드를 절대로 변경하지 마십시오 — 추가 전용이 규칙입니다.
Didit 자체의 통제가 추적 기록을 뒷받침합니다: SOC 2 Type 1 (ATOM), ISO/IEC 27001:2022 (인증 번호 ES144068), 및 iBeta Level 1 PAD — ICT 제3자 등록을 위한 공급업체 수준의 보증.
그 결과는 DORA가 원하는 무슨 일이 일어났는지에 대한 기록과 접근 제어를 뒷받침하는 누구인지에 대한 증명을 모두 충족합니다.

표준 요구 사항

DORA는 ICT 위험 관리, 사고 보고, 디지털 운영 복원력 테스트, 정보 공유, ICT 제3자 위험 관리의 다섯 가지 기둥 위에 구축됩니다. 감사 추적은 이들 사이의 연결 고리입니다. 특히, 금융 기관은 다음을 수행해야 합니다:

ICT 관련 사고를 감지, 기록 및 보고 — 이는 발생한 일을 재구성할 수 있을 만큼 세분화된 기록을 전제로 합니다.
시스템을 통해 거래 및 이벤트를 추적할 수 있는 능력을 포함하여 복원력을 테스트합니다.
본인 확인 공급업체와 같은 제공자로부터 발생하는 기록을 포함하여 제3자 위험을 관리합니다.
감독관이 요청하고 신뢰할 수 있는 형태로 기록을 보존합니다.

유용한 감사 추적의 암묵적인 요구 사항은 다음과 같습니다: 이벤트는 완전해야 하며 (침묵하는 공백이 없어야 함), 정확해야 하며 (발생한 일에 충실해야 함), 시간 순서대로 정렬되어야 하며 (신뢰할 수 있는 타임스탬프가 있어야 함), 귀속 가능해야 하며 (주체 및 행위자와 연결되어야 함), 위변조 방지 기능이 있어야 합니다 (기록이 사후에 변경되지 않았음을 보여줄 수 있어야 함).

왜 중요한가

의심되는 계정 탈취, 논란이 되는 본인 확인, 플래그가 지정된 거래와 같은 사고가 발생했을 때, 통제된 이벤트와 규제 문제 사이의 차이는 종종 기록의 품질에 달려 있습니다. 완전한 추적 기록은 순서를 재구성하고, 통제가 의도한 대로 작동했음을 증명하며, 감독관에게 제대로 처리했음을 보여줄 수 있게 합니다. 불완전한 추적 기록은 추측하게 만들고, 감독관을 설득하지 못합니다.

본인 확인 이벤트는 시스템의 경계에 있기 때문에 높은 가치를 가집니다. 사람이 확인되거나, 재확인되거나, 상태가 변경되는 순간은 정확히 기록되기를 가장 원하는 순간입니다. 나중에 애플리케이션 로그에서 재구성하는 대신, 그러한 이벤트를 발생 즉시 캡처하는 것은 "이것이 일어났다고 생각합니다"를 "이것이 일어났습니다"로 바꿉니다.

Didit이 돕는 방법

Didit은 본인 확인, 거래 또는 비즈니스 세션의 모든 상태 전환에 대해 웹훅을 발행합니다. 폴링할 필요 없이, 무언가가 변경되는 순간 서명된 이벤트를 수신합니다.

이벤트	발생 시점	감사 가치
`status.updated`	본인 확인 세션의 상태가 변경될 때 (예: `승인됨`, `거부됨`, `검토 중`)	결정 및 시기 기록
`data.updated`	세션의 확인된 데이터가 변경될 때	캡처/변경된 내용 기록
`transaction.status.updated`	모니터링되는 거래의 상태가 변경될 때	모니터링 결정 및 분석가 해결 기록
`business.status.updated`	KYB 비즈니스 엔터티의 상태가 변경될 때 (`활성`/`플래그됨`/`차단됨`)	비즈니스 온보딩 결과 기록

각 이벤트는 독립적인 사실입니다. 귀하의 역할은 이를 확인하고, 원시 상태로 저장하며, 결코 변경하지 않는 것입니다. 이러한 이벤트는 Didit이 귀하를 대신하여 수행한 모든 작업에 대한 추가 전용 원장을 형성하며 — 이는 귀하의 ICT 자산 중 본인 확인 부분에 대해 DORA가 요구하는 감사 추적입니다.

그리고 Didit 자체는 SOC 2 Type 1 (ATOM, 2026-04-09 기준), ISO/IEC 27001:2022 (Bureau Veritas, 인증 번호 ES144068, 2027-06-03까지 유효), 및 iBeta Level 1 PAD로 인증되었기 때문에, 이러한 이벤트 뒤의 제공자는 DORA ICT 제3자 등록을 위한 자체 증거를 가지고 있습니다.

심층 분석: 웹훅을 감사 기록으로 전환하기

다음은 방금 Approved로 확인된 본인 확인 세션에 대한 status.updated 웹훅입니다:

{
  "event": "status.updated",
  "session_id": "sess_7b21e0c4",
  "vendor_data": "user_4521",
  "status": "Approved",
  "previous_status": "In Review",
  "workflow_id": "wf_kyc_eu_substantial",
  "checks": {
    "id_verification": "passed",
    "passive_liveness": "passed",
    "face_match": "passed"
  },
  "created_at": "2026-05-21T10:32:04Z",
  "signature": "t=1747824724,v1=9f86d081884c7d659a..."
}

이를 DORA 준비가 완료된 감사 기록으로 전환하려면, 수신 시 다음 네 가지를 수행하십시오:

서명을 확인하십시오. 엔드포인트의 서명 비밀을 사용하여 원시 요청 본문에 대한 HMAC를 다시 계산하고 페이로드를 신뢰하기 전에 signature 헤더와 비교하십시오. 실패하는 모든 것을 거부하십시오 — 확인되지 않은 이벤트는 증거 가치가 없습니다.
원시 페이로드를 그대로 저장하십시오. 수신한 정확한 바이트를 자체 수집 타임스탬프와 함께 보존하십시오. 저장하기 전에 정규화하거나 재구성하지 마십시오. 원시 이벤트가 증거입니다.
추가만 하고 업데이트하지 마십시오. 추가 전용 저장소(또는 앱 역할에 대한 UPDATE/DELETE 권한이 없는 테이블)에 기록하십시오. 나중 이벤트가 이전 이벤트를 대체하는 경우, 이전 session_id를 참조하는 새로운 행을 기록하십시오 — 절대로 덮어쓰지 마십시오.
위변조 방지 기능을 만드십시오. 각 기록을 해싱하고 해시를 다음 기록에 연결하거나(각 행은 이전 행의 해시를 저장함) 한 번만 기록할 수 있는 저장소에 기록하십시오. 이제 로그가 사후에 변경되지 않았음을 증명할 수 있습니다.

그 결과는 연대순으로, 귀속 가능하며, 위변조 방지 기능이 있는 원장입니다. 모든 session_id에 대해 모든 상태 변경을 재생하고, 어떤 확인이 통과되었는지 확인하며, 결정이 정확히 언제 내려졌는지 보여줄 수 있습니다 — 그리고 기록이 그 이후로 변경되지 않았음을 증명할 수 있습니다. 이것이 감독관이나 감사관이 찾는 표준이며, 모니터링 결정에 대한 transaction.status.updated 및 KYB 결과에 대한 business.status.updated에도 동일한 패턴을 적용할 수 있습니다.

사용 사례

본인 확인 결정을 포함하는 DORA 준수 ICT 이벤트 로그를 구축하는 은행 및 EMI.
감독관에게 온보딩 및 거래 모니터링 결정을 증명해야 하는 암호화폐 VASP.
이벤트를 처음부터 끝까지 추적하는 복원력 테스트를 준비하는 규정 준수 팀.
취약한 폴링을 서명되고 추가 전용 이벤트 수집으로 대체하는 엔지니어링 팀.

자주 묻는 질문

감사 추적을 위해 어떤 웹훅 이벤트를 캡처해야 합니까?

최소한 본인 확인을 위한 status.updated 및 data.updated; 거래 모니터링을 위한 transaction.status.updated 및 KYB를 위한 business.status.updated를 추가하십시오. 모든 이벤트를 캡처하십시오 — 완전성이 핵심입니다.

웹훅 서명을 확인해야 합니까?

예. 확인되지 않은 웹훅은 스푸핑될 수 있으며 증거 가치가 없습니다. 원시 본문에 대한 서명을 다시 계산하고 기록하기 전에 불일치를 거부하십시오.

왜 추가 전용입니까? 상태가 변경될 때 기록을 업데이트할 수는 없습니까?

DORA는 위변조 방지 기능을 중요하게 생각합니다. 기록을 덮어쓰면 기록이 변경되지 않았음을 증명할 수 없습니다. 각 변경에 대해 새 이벤트를 추가하면 완전하고 증명 가능한 순서가 보존됩니다.

Didit의 이벤트를 캡처하는 것이 DORA의 모든 요구 사항을 충족합니까?

아니요 — DORA는 광범위합니다. Didit의 이벤트는 ICT 자산의 본인 확인 및 모니터링 부분을 다룹니다. 완전한 추적 기록을 위해 이를 나머지 시스템의 로그와 결합해야 합니다.

Didit은 DORA 제3자 등록을 위한 자체 증명을 가지고 있습니까?

예 — SOC 2 Type 1 (ATOM), ISO/IEC 27001:2022 (인증 번호 ES144068, 2027-06-03까지 유효), 및 iBeta Level 1 PAD가 있으며, 모두 공급업체 실사를 지원합니다.

시작할 준비가 되셨습니까?

신뢰 허브에서 Didit의 증명을 확인하고, 문서에서 웹훅 통합 세부 정보를 읽고, 가격 페이지에서 투명한 가격을 검토하십시오. 준비가 되면 무료로 시작하십시오 — 매월 500건의 무료 KYC 확인, 핵심 본인 확인 흐름은 $0.33부터 시작합니다.