벤더를 신뢰하지 않고도 감사인이 검증할 수 있는 컴플라이언스 로그

컴플라이언스 증거는 그것을 만든 시스템 바깥에 고정될 때 더 설득력을 가집니다. 방식은 단순합니다. 보고서와 감사 로그, 통제 스냅샷을 주기적으로 해시하고, 그 해시들을 하나의 Merkle 루트로 묶어, 그 루트를 Cardano에 Label 309 존재 증명으로 게시하면 됩니다. 이후 리프와 트랜잭션 참조만 가진 감사인은 특정 항목이 커밋된 배치의 일부였다는 것과 그 배치가 공개된 블록 타임까지 존재했다는 것을 확인할 수 있습니다. 여러분의 데이터베이스도, 대시보드도, 말도 신뢰할 필요가 없습니다.

이것이 기록된 모든 사건이 사실임을 증명하지는 않습니다. 다만 조용히 다시 쓰는 행위를 훨씬 더 숨기기 어렵게 만듭니다.

"우리 시스템에 있습니다"가 감사인에게 약한 답변인 이유는 무엇입니까?

대부분의 컴플라이언스 증거는 벤더 시스템 안에 있습니다. 편리하지만 신뢰 문제를 낳습니다. 증거가 보고서를 만든 바로 그 플랫폼에만 저장되어 있다면, 나중에 검토하는 사람은 그 시스템이 스스로에 대해 답할 수 없는 질문을 안게 됩니다.

그 로그가 사후에 편집되었을 가능성은 없습니까?
보고서가 마감 전에 생성되었습니까, 아니면 후에 생성되었습니까?
이 통제 스냅샷이 그 시점에 정말로 존재했습니까?
증거가 사고 이후에 소급해서 채워진 것은 아닙니까?
내보낸 PDF가 검토에 쓰인 바로 그 PDF입니까?
벤더나 관리자가 레코드를 다시 썼을 가능성은 없습니까?

내부 시스템은 잘 통제될 수 있지만 그래도 여전히 내부 시스템입니다. 타임스탬프, 변경 이력, "기준 시점" 상태는 모두 그 행위가 검토 대상인 바로 그 당사자에게서 나옵니다. 존재 증명은 그 타임라인에 외부 증인을 더합니다. 즉, 특정 다이제스트가 특정 공개 시점까지 존재했다는 독립적인 레코드입니다.

어떤 증거를 고정해야 합니까?

나중에 중요해질 수 있는 증거를 고정하십시오. 규제 기관, 고객, 이사회, 또는 법원이 언젠가 특정 날짜 기준 그대로 재현하라고 요구할 수 있는 모든 것입니다. 흔한 후보는 다음과 같습니다.

컴플라이언스 및 투명성 보고서;
위험 평가;
통제 스냅샷;
감사 로그;
접근 권한 검토;
정책 승인;
AI 거버넌스 및 모델 평가 레코드;
콘텐츠 모더레이션 보고서;
사고 타임라인;
취약점 대응 로그;
고객용 보안 산출물;
규제 기관 제출물;
데이터 처리 기록.

증거 자체는 비공개로 둘 수 있습니다. 공개 레코드는 하나의 해시, 또는 여러 해시를 묶은 Merkle 루트에만 커밋하며, 그 안의 콘텐츠 원본에는 결코 커밋하지 않습니다.

파일마다 고정하지 않고 증거를 Merkle 루트로 묶는 이유는 무엇입니까?

컴플라이언스 증거는 대개 하나의 파일이 아니라 흐름입니다. 하루에도 수백 또는 수천 건의 레코드가 생길 수 있고, 한 번의 감사 기간이 여러 시스템에 걸칠 수 있으며, 하나의 플랫폼이 콘텐츠 모더레이션, 고객 지원, 보안, 모델 평가, 사고 대응에서 나오는 로그를 한꺼번에 만들어 낼 수 있습니다. 항목마다 별도의 트랜잭션으로 고정한다면 느리고 비싸질 것입니다.

Merkle 트리가 이 문제를 해결합니다. 모든 항목을 해시해 리프로 만들고, 그 리프들을 하나의 32바이트 루트로 접어, 그 단일 루트를 게시합니다. 순서가 정해진 리프 목록은 체인 바깥에 남습니다. 이후 리프를 가진 누구든 특정 보고서나 로그 항목이 포함되었음을 간결한 포함 증명으로 증명할 수 있는데, 이 증명의 크기는 배치 크기의 로그에 비례해서만 커집니다. 어떤 비공개 레코드도 체인에 올릴 필요가 없습니다.

루트는 공개되지만, 그 바탕의 증거는 여러분 자신의 통제 아래 남습니다. 이를 파일마다 처리하는 방식과 견주어 보고 있다면, 수천 개 파일을 하나의 레코드로가 그 절충점을 짚어 줍니다.

감사인은 실제로 무엇을 검증합니까?

감사인은 하나의 증거 조각에서 블록체인까지 이어지는 사슬을 검증합니다. 한 항목에 대한 단계는 다음과 같습니다.

파일, 보고서, 또는 로그 항목 자체;
그 해시;
그 해시를 루트에 연결하는 Merkle 포함 증명;
Label 309 레코드에 기록된 루트;
Cardano 트랜잭션 시간;
레코드에 있는 서명(있는 경우);
로깅 주기를 설명하는 여러분의 정책.

트리를 만들고 포함 증명을 확인하는 일은 순수한 계산입니다. 서버도, 계정도, 네트워크도 필요 없습니다. 리프와 온체인 루트를 가진 누구든 어떤 증명이든 독립적으로 다시 도출할 수 있으며, 바로 이것이 핵심입니다. 즉, 검증은 여러분의 협조에 의존하지 않습니다.

이것은 좁지만 유용한 질문에 답합니다. 이 정확한 증거가 그 시점에 커밋된 배치의 일부였는가? 이는 완전한 감사 의견은 아니지만, 어떤 내부 시스템도 제공할 수 없는 외부 기준점을 증거 타임라인에 부여합니다.

이것은 커지는 규제 압박에 어떻게 맞물립니까?

많은 규제 체계가 더 많은 문서화, 보고, 그리고 기계 판독 가능한 투명성을 향해 움직이고 있습니다. EU의 디지털 서비스법(Digital Services Act)이 분명한 예입니다. 이 법은 중개 서비스에 투명성 보고서 게시를, 호스팅 서비스에 모더레이션 결정에 대한 사유서 발행을 요구하며, 초대형 온라인 플랫폼과 검색 엔진에는 더 무거운 의무를 더합니다. 더 잦은 보고, 검증된 연구자의 데이터 접근, 익명 내부고발자 채널, 그리고 독립 감사 보고서와 함께 제출하는 연례 위험 평가가 그것입니다. 집행위원회는 또한 투명성 보고를 비교 가능하고 기계 판독 가능한 형식으로 표준화했습니다.

증거 해시를 고정하는 것만으로 규제를 충족하지는 못하며, 이 글은 법률 자문이 아닙니다. 적절한 증거는 법률, 관할권, 회사, 워크플로에 따라 달라집니다. 그러나 그 바탕의 필요는 일관됩니다. 즉, 팀은 점점 더 검증을 견딜 수 있는 재현 가능한 증거를 만들어 내야 합니다. 타임스탬프가 찍힌 커밋은 증거가 검토, 마감, 사고, 또는 분쟁에 대응해 짜맞춰진 것이 아니라 그 이전에 존재했음을 보여 주는 데 도움이 될 수 있습니다.

여기서 "벤더 신뢰 없이"란 실제로 무엇을 뜻합니까?

벤더 신뢰란 한 플랫폼의 데이터베이스를 증거 이야기 전부로 의존하는 것입니다. 익숙한 세 가지 상황이 그 한계를 보여 줍니다.

컴플라이언스 대시보드가 지난달에 어떤 통제가 정상(녹색)이었다고 말한다면, 그 대시보드가 어제 편집된 것이 아니라 지난달에 그렇게 말했다는 것을 증명할 수 있습니까?
AI 거버넌스 도구가 어떤 모더레이션 보고서가 공개된 사고 이전에 존재했다고 말한다면, 그 보고서가 사후에 다시 생성된 것이 아니라는 것을 증명할 수 있습니까?
GRC 플랫폼이 PDF를 내보낸다면, 바로 그 PDF가 검토된 것이라는 것을 증명할 수 있습니까?

Label 309 레코드가 여러분의 워크플로에서 벤더를 없애지는 않습니다. 벤더는 여전히 보고서를 생성하고 증거를 저장할 수 있습니다. 달라지는 점은, 증명이 벤더가 나중에 해시 사슬을 깨뜨리지 않고는 조용히 다시 쓸 수 없는 외부 커밋을 만들어 낸다는 것입니다. (여기서 "GRC"는 거버넌스, 리스크, 컴플라이언스를 뜻하며, Vanta, Drata 및 유사 플랫폼을 포함하는 도구 범주입니다.)

매니페스트에는 무엇이 들어가야 합니까?

매니페스트는 나중에 검증하는 누구에게든 증명을 이해할 수 있게 만들어 줍니다. 컴플라이언스 매니페스트는 다음을 기록할 수 있습니다.

증거 기간;
시스템 이름;
통제 및 보고서 식별자;
파일 이름과 파일 해시;
레코드 유형;
소유자;
내보내기 타임스탬프;
정책 버전;
서명 상태;
스토리지 위치;
포함 증명에 대한 참조.

매니페스트는 비공개로 두거나, 공개하거나, 특정 수신자를 대상으로 봉인할 수 있습니다. 중요한 것은 나중에 그에 맞춰 검증할 수 있을 만큼 안정적이고 문서화되어 있어야 한다는 점입니다. 문서화가 부실한 매니페스트는 암호학적으로는 유효하지만 운영상으로는 혼란스러운 증명을 남길 수 있습니다. 바이트는 들어맞지만, 무엇에 커밋한 것인지 아무도 알 수 없는 상황입니다.

얼마나 자주 고정해야 합니까?

주기를 위험에 맞추십시오. 어떤 팀은 매일 고정하고, 어떤 팀은 매시간, 사고마다, 릴리스마다, 감사 주기마다, 또는 규제 보고서마다 고정합니다.

지속적 모니터링 의무의 경우, 규칙적인 주기 자체가 핵심입니다. 감사 전날 생성된 보고서는, 증거가 시간에 걸쳐 수집되었음을 보여 주는 주기적 커밋의 사슬보다 훨씬 설득력이 떨어집니다. 주기는 통제 그 자체의 일부가 될 수 있습니다. 정책상 루트를 매일 게시하기로 했다면, 빠진 날은 모두에게 드러납니다. 같은 논리가 존재 증명을 법적 증거와 전자증거개시(e-discovery)에 자연스럽게 들어맞게 만듭니다. 그곳에서는 무언가가 언제 기록되었는지가 바로 다툼의 핵심이기 때문입니다.

컴플라이언스 레코드를 봉인해야 합니까?

대개는 그렇습니다. 컴플라이언스 증거에는 민감한 운영 데이터, 개인 정보, 보안 세부 사항, 또는 기밀 사업 기록이 담길 수 있습니다. 평문을 게시하는 것은 실수일 것입니다. Label 309는 세 가지 방식을 지원하며, 이를 섞어 쓸 수 있습니다.

해시 전용 — 커밋만 게시하고 증거는 내부에 둡니다.
Merkle 루트 — 여러 비공개 증거 항목을 묶은 루트를 게시합니다.
봉인 — 암호화된 증거나 매니페스트를 콘텐츠 주소 지정 URI에 저장하고 복호화 키를 특정 수신자에게 감싸 둡니다. 그러면 증명과 암호문은 함께 이동하면서도, 권한이 있는 키 보유자만 콘텐츠를 읽을 수 있습니다.

봉인은 검증 가능한 타임스탬프와 기밀성을 동시에 원할 때 유용합니다. 예를 들어 나중에 규제 기관이나 감사인에게 넘겨야 할 수 있지만 오늘 공개할 수는 없는 증거가 그렇습니다. 그 한계를 염두에 두십시오. 봉인된 레코드는 시점과 무결성을 증명하지, 영원한 비밀을 증명하지는 않습니다. 콘텐츠를 복호화한 수신자는 그 후에 평문을 유출할 수도 있습니다.

이것이 증명하지 못하는 것은 무엇입니까?

존재 증명은 정확히 그 바이트가 공개된 시점까지 존재했음을 보여 줍니다. 그 점에 대해서는 정확하고, 나머지 모든 것에 대해서는 침묵합니다.

바탕의 사건이 사실이었음을 증명하지는 않습니다. 거짓 보고서가 생성되어 커밋되면, 증명은 그 거짓 보고서가 존재했음을 보여 줄 뿐, 그것을 정확하게 만들지는 못합니다.
컴플라이언스 프로그램이 효과적임을 증명하지는 않습니다.
접근 통제, 변경 관리, 로깅 무결성, 직무 분리, 법률 검토, 또는 감사 절차를 대체하지는 않습니다.
여러분의 프로세스와 통제가 그 주장을 독립적으로 뒷받침하지 않는 한, 증거가 완전함을 증명하지는 않습니다.

존재 증명은 증거 무결성 계층이지, 컴플라이언스 프로그램이 아닙니다. 한계의 전체 목록은 증명이 증명하지 못하는 것을 참고하십시오.

첫 구현으로 무엇이 좋습니까?

이미 생성하고 있는 보고서로 시작하고, 모든 시스템을 한꺼번에가 아니라 하나의 증거 흐름으로 시작하십시오.

컴플라이언스 보고서나 통제 스냅샷 하나를 고릅니다.
안정적이고 재현 가능한 형식으로 내보냅니다.
파일을 해시합니다.
그 해시를 일일 또는 주간 매니페스트에 추가합니다.
해당 기간에 대한 Merkle 루트를 만듭니다.
Label 309 레코드를 게시하고, 선택적으로 서명합니다.
매니페스트, 리프 목록, 포함 증명, 그리고 트랜잭션 참조를 저장합니다.
감사인이 증명의 의미를 알 수 있도록 프로세스를 문서화합니다.

그런 다음 다음 증거 흐름으로 확장하십시오. 같은 형태는 자동화에 깔끔하게 들어맞습니다. 즉, 빌드와 게시 단계는 매 실행이 끝날 때 루트를 고정하는 CI/CD 파이프라인에 잘 맞습니다.

수천 개 파일을 하나의 레코드로 — Merkle 배칭과 포함 증명이 어떻게 작동하는지 다룹니다.
증명이 증명하지 못하는 것 — 존재 증명의 한계를 짚습니다.
오픈 표준과 참조 구현은 label309.org와 github.com/cardanowall에 있습니다. Label 309는 Cardano CIP 절차에 제출되었으며, Metadata 범주 제안으로 CIP 편집자들의 검토를 받고 있습니다(공개 PR).
유럽 집행위원회의 DSA 투명성 의무 개요는 규제 대상 플랫폼이 점점 더 만들어 내야 하는, 재현 가능하고 기계 판독 가능한 증거가 어떤 것인지 설명합니다.