증빙 패키지 (Evidence Package)
증빙 패키지는 한 기간 동안의 산출물 네 가지 — 통제가 성립하는가, 데이터가 어디 있는가, 권한을 누가 검토했는가, 무엇이 바뀌었는가 — 를 서명된 zip 파일 하나로 묶은 것입니다. 화면 네 곳을 오가며 사람이 모은 자료 묶음과 달리, 이 zip은 "이 내용이 그때 그 상태 그대로임"을 스스로 증명합니다.
1. 만들기
프로젝트(또는 연결 그룹)의 Evidence 화면에서 다음을 지정해 패키지를 요청합니다.
- 기간 — 시작일과 종료일
- 프레임워크 — 통제 리포트를 포함할 프레임워크(하나 이상 필수)
- 접근권한 검토·감사 이력 포함 여부(기본 포함)
요청을 받으면 즉시 만들어지지 않고, 실행 이력에 조립 작업이 등록되어 진행됩니다. 완료까지 몇 분이 걸릴 수 있고, 화면에서 진행 상태를 볼 수 있습니다.
조립 중 어느 입력 하나라도 읽지 못하면(예: 통제 리포트를 만들 수 없거나, 감사 이력을 가져오지 못하는 경우) 패키지는 실패로 끝나고 사유가 남습니다. 절이 비어 있는 zip을 내보내지 않습니다 — 받는 사람이 빈 절을 "그 기간에 그런 일이 없었다"로 잘못 읽을 수 있기 때문입니다. 대상 범위에 연동된 저장소가 전혀 없으면 요청 자체가 거부됩니다.
2. zip 안의 구성
| 파일 | 내용 |
|---|---|
manifest.json | 색인. zip 안 모든 파일의 이름·종류·크기·SHA-256 |
signature.json | 매니페스트의 다이제스트에 대한 서명 |
README.txt | 이 문서 3절과 같은 검증 절차(도구 없이도 검증할 수 있도록 파일로 동봉) |
1-controls/<프레임워크>.json·.pdf | 프레임워크별 통제 리포트 — 3분할 지표와 분모, 요구사항 전량, 근거, 예외 |
2-data-location.json·.pdf | 연결별 리전·저장소, 데이터 분류표, 원문 가용성 |
3-access-reviews/<검토>.json·.pdf | 기간 안에 완료된 접근권한 검토(주체별 판정 포함), 각자의 서명 |
4-change-history/audit-events.json | 그 기간·범위의 감사 이력 전량 |
executions.json | 같은 기간에 기록된 실행(스캔·동기화 등) 목록과 그 진행 이력 |
ledger-verify.json | 실행 이력의 해시 사슬을 다시 검증한 결과와, 그 시점의 사슬 머리 해시 |
3. 서명은 매니페스트 하나에 걸립니다
zip 안 모든 파일의 이름·크기·해시가 manifest.json에 들어 있으므로, 그 매니페스트의 다이제스트 하나에 대한 서명이 패키지 전체를 덮습니다. 검증은 두 단계입니다.
- 파일 확인 —
manifest.json의 각 항목에 적힌 이름으로 zip 안의 파일을 찾아 SHA-256을 다시 계산하고, 매니페스트의 값과 크기가 같은지 확인합니다. - 서명 확인 —
manifest.json을 정규화(키 정렬·공백 없음·UTF-8)해 다시 해시하고, 그 값이signature.json에 적힌 값과 같은지, 그 값에 대한 서명이 유효한지 확인합니다.
이 두 단계 밖에서 이 제품을 믿어야 하는 부분은 없습니다 — 툴 없이 해시 계산기와 서명 검증 라이브러리만 있으면 누구나 직접 확인할 수 있습니다. README.txt에 같은 절차가 그대로 적혀 있어, 계약이 끝난 뒤의 감사인이나 이 화면에 접근할 수 없는 규제 기관도 검증할 수 있습니다.
원한다면 ledger-verify.json으로 실행 이력의 해시 사슬도 다시 확인할 수 있습니다 — 이 값은 패키지를 만든 그 순간의 결과이고, 그 사슬은 이후로도 계속 이어지므로 나중에 플랫폼에 다시 검증을 요청하면 그 사이에 사슬이 끊기지 않았는지도 알 수 있습니다.
4. HMAC과 KMS, 두 서명 방식
이 제품은 두 가지 서명 방식을 지원하고, 어느 쪽인지는 패키지의 서명 정보와 서명 키 화면에서 확인할 수 있습니다.
- HMAC(공유 비밀) — 플랫폼이 비밀 키로 서명합니다. 공개할 수 있는 반쪽이 없으므로, 이 방식으로 서명된 패키지는 같은 비밀을 가진 쪽(이 플랫폼)만 서명을 검증할 수 있습니다. 외부 검증이 필요하면 플랫폼 운영자에게 확인을 요청해야 합니다.
- KMS(비대칭 키) — 개인키는 플랫폼만 갖고, 공개키는
signature.json과 화면의 서명 키 메뉴로 공개됩니다. 감사인은 이 공개키만으로, 플랫폼에 다시 묻지 않고 독립적으로 서명을 검증할 수 있습니다.
어느 방식이든 서명 정보(mode)가 패키지·화면에 그대로 표시되어, 검증하는 사람이 "우리가 이 서명을 검증하려면 플랫폼이 필요한지 아닌지"를 바로 알 수 있습니다.
5. 수령·다운로드·검증
만들어진 패키지는 프로젝트(또는 그룹)의 Evidence 화면과, 감사인이 접근할 수 있는 포털의 Evidence 메뉴에서 동일하게 목록으로 보이며, 각각 다음을 할 수 있습니다.
- 다운로드 — zip 파일을 그대로 받습니다. 아직 준비되지 않았거나 실패한 요청은 다운로드할 수 없습니다.
- 검증 — 저장된 zip을 다시 읽어 세 가지를 각각 답합니다.
zip 안 파일이 매니페스트와 같은가,그 매니페스트가 이 플랫폼의 키로 서명된 것인가,그 시점의 실행 이력 해시 사슬이 지금도 온전한가. 셋을 하나로 합치지 않습니다 — 파일이 바뀐 것과 서명이 깨진 것과 이력이 끊긴 것은 서로 다른 문제이고 대응도 다르기 때문입니다.
감사인 권한으로 로그인한 사람은 자신에게 허용된 범위의 패키지만 볼 수 있고, 그 범위 안에서는 목록·다운로드·검증 모두 할 수 있습니다.
6. 관련 문서
패키지에 담기는 내용의 자세한 뜻은 각 문서를 참고하세요 — 통제, 데이터 위치, 접근권한 검토, 점수의 근거는 위험 점수 설명.