要求一行とファイル一か所をつなぐ表を作る

한국어 원문으로 표시합니다.

목표

요구사항마다 어떤 파일이 근거인지를 묶은 증거 색인을 만들고, 해시로 봉인하고, 검증기로 끊어진 곳을 세고, 반출 심사를 거친 사본으로 감사 대응 꾸러미를 닫습니다.

왜 중요한가

감사에서 떨어지는 항목은 대개 하지 않은 일이 아니라 보이지 못한 일입니다. 요구 한 줄과 파일 한 곳 사이에 길이 놓여 있지 않으면 그 자리에서 답할 수 없고, 답하지 못한 항목은 하지 않은 것과 같게 기록됩니다. 그 길은 감사 전날 놓을 수 없습니다 — 근거 파일은 시간이 지나면 덮이고 사라지기 때문입니다. 그래서 색인에는 경로만이 아니라 그때 그 파일의 해시가 들어가고, 내보낼 때 값을 가리면 해시도 함께 바뀝니다. 이 실습에서 어려운 부분은 규칙이 아니라 이 일관성입니다.

단계

python3 로 /root/audit/data 에 요구사항·근거 파일 14개·정책·지난 색인을 만듭니다. 생성 스크립트를 그대로 쓰세요.
근거 파일의 머리말을 읽어 요구별 근거 목록을 /root/audit/index.json 에 적습니다.
근거마다 SHA-256 을 붙여 /root/audit/index-sealed.json 으로 봉인합니다.
지난 점검 때 낸 /root/audit/data/snapshot.json 을 검증해 결과를 /root/audit/verify.json 에 적습니다.
근거를 설계와 운영으로 나눠 요구별 판정을 /root/audit/strength.csv 에 적습니다.
같은 수집을 다시 돌려 /root/audit/index-rerun.json 을 만들고 결정성을 /root/audit/determinism.json 에 적습니다.
반출 심사 규칙으로 가린 사본을 /root/audit/submit/evidence/ 에 만들고 /root/audit/redaction.csv 를 남깁니다.
가린 사본의 해시로 /root/audit/submit/index.json 을 봉인하고 /root/audit/submit/verify.json 과 /root/audit/submit/INDEX.md 로 꾸러미를 닫습니다.

참고

기준일은 /root/audit/data/asof.txt 에 있습니다. date 로 오늘을 쓰면 같은 자료에서 날마다 다른 답이 나옵니다.
근거 파일의 머리말은 두 가지 형식입니다. .json 은 최상위 열쇠(evidence_id·covers·kind·collected_at)에, 나머지는 앞머리 주석 줄(# evidence-id: 처럼)에 들어 있습니다.
색인의 path 는 /root/audit 기준 상대 경로입니다. 꾸러미 안 색인만 /root/audit/submit 기준입니다.
근거 세기 구분과 반출 심사 규칙은 /root/audit/data/policy.json 에 있습니다. 규칙을 코드에 박지 말고 그 파일에서 읽으세요.
6단계의 표준형은 색인에서 generated_at 을 뺀 뒤 json.dumps(..., ensure_ascii=False, sort_keys=True, separators=(",", ":")) 한 글자열의 SHA-256 입니다.
흔한 실수 1: 7단계에서 원본 근거 파일을 고치는 것. 가린 것은 사본이어야 하고 원본은 그대로 남아 있어야 합니다.
흔한 실수 2: 8단계에서 원본 해시를 그대로 옮기는 것. 가린 사본에는 가린 사본의 해시를 붙여야 받는 쪽 검증이 통과합니다.
표준 문서: NIST SP 800-171 Rev 3, NIST SP 800-53 Rev 5, NIST SP 800-92. 이 실습의 REQ 번호와 RED 번호는 표준의 통제 번호가 아니라 자료 안에서만 쓰는 합성 번호입니다.

요구사항과 근거 파일 만들기

python3 로 /root/audit/data 에 requirements.json·policy.json·snapshot.json·asof.txt 와 evidence/ 아래 근거 파일 14개를 만듭니다. 난수를 쓰지 않는 생성 스크립트를 그대로 쓰세요.

폐쇄망에는 내려받을 표본이 없으니 자료부터 직접 만듭니다. 난수를 쓰지 않아야 누가 몇 번을 돌려도 같은 자료가 나오고, 서로의 판정을 대조할 수 있습니다. 채점기는 자료를 표준형으로 바꿔 지문을 대조하므로 자료를 손으로 고치면 뒤 단계가 전부 막힙니다.

요구마다 근거를 잇는 색인 만들기

/root/audit/index.json 에 generated_at·asof·entries 세 열쇠를 두고, entries 는 요구 id 마다 근거 항목 목록(evidence_id·path·kind·collected_at)을 담습니다. 근거가 없는 요구도 빈 목록으로 넣으세요.

근거 파일이 스스로 어떤 요구를 덮는지 머리말에 적어 두었습니다. 디렉터리를 훑어 머리말을 읽고 뒤집으면 색인이 됩니다. 형식이 두 가지라는 점을 잊지 마세요. 항목은 근거 id 순으로 정렬하고, path 는 /root/audit 기준 상대 경로로 적습니다.

근거의 해시를 색인에 못박기

/root/audit/index-sealed.json 에 색인을 그대로 옮기되 근거 항목마다 sha256 을 더합니다. generated_at 은 2단계 색인의 값을 그대로 둡니다.

봉인은 다시 수집하는 일이 아니라 지금 색인에 지문을 더하는 일입니다. 그래서 수집 시각은 바뀌지 않아야 합니다. 해시는 파일 전체 바이트에 대한 SHA-256 을 소문자 16진수로 적습니다.

지난 점검 때 낸 색인을 검증기로 걸러 보기

/root/audit/verify.json 에 /root/audit/data/snapshot.json 을 검증한 결과를 적습니다. missing_file·hash_mismatch·uncovered 세 열쇠에 각각 count 와 목록(evidence_ids 또는 req_ids)을 담으세요.

세 가지는 서로 다른 고장입니다. 가리키는 파일이 없는 것, 파일은 있는데 해시가 어긋난 것, 그리고 근거 항목이 아예 하나도 없는 요구사항입니다. 세 번째는 색인이 그 요구를 아예 적지 않은 경우까지 세야 하니 요구 목록 쪽에서 돌아야 합니다. 항목이 하나 있는데 그것이 끊어진 요구는 근거 없음이 아닙니다.

근거의 세기를 나눠 부족한 자리 찾기

/root/audit/strength.csv 에 첫 줄 req_id,needs,has_design,has_operational,verdict 를 두고 요구 12건을 한 줄씩 적습니다. needs 는 설계 또는 설계+운영, 보유 여부는 예/아니오, 판정은 충족·설계근거없음·운영근거없음·근거없음 중 하나입니다.

설정과 정책 문서는 그렇게 되어 있다를 보이고, 로그와 점검 결과는 실제로 그렇게 동작했다를 보입니다. 어느 종류가 어느 쪽인지는 정책 파일에 있습니다. 근거가 아예 없으면 근거없음이 먼저이고, 그 다음 필요한 쪽이 비었는지를 설계부터 봅니다.

다시 수집해도 같은 색인이 나오는지 보기

같은 방법으로 /root/audit/index-rerun.json 을 새로 만들고, /root/audit/determinism.json 에 generated_at_differs·normalized_sha256_first·normalized_sha256_second·same_without_time 네 열쇠를 적습니다.

두 색인에서 수집 시각만 빼고 표준형으로 직렬화해 해시를 견줍니다. 두 해시가 같아야 이 수집은 결정적입니다. 반대로 수집 시각은 달라야 다시 돌린 것이 되므로, 시각은 마이크로초까지 적으세요.

반출 심사로 가린 사본 만들기

정책의 심사 규칙을 규칙 번호 순으로 적용해 근거 14개의 사본을 /root/audit/submit/evidence/ 아래 같은 상대 경로로 만들고, 규칙이 걸린 파일만 /root/audit/redaction.csv 에 evidence_id,rules,hits,sha256_after 로 적습니다.

걸린 것이 없는 파일도 사본은 만들어야 꾸러미가 완성됩니다. rules 는 걸린 규칙 번호를 더하기로 이어 적고, hits 는 바뀐 자리의 총 개수입니다. sha256_after 는 가린 사본의 해시입니다 — 원본은 손대지 마세요.

꾸러미를 닫고 검증기로 스스로 확인하기

/root/audit/submit/index.json 을 가린 사본 기준으로 봉인하고(경로는 /root/audit/submit 기준), 같은 검증기를 돌린 결과를 /root/audit/submit/verify.json 에, 요구별 근거 수와 판정을 표로 정리한 목차를 /root/audit/submit/INDEX.md 에 남기세요.

꾸러미 안 색인은 가린 사본의 해시를 써야 받는 쪽 검증이 통과합니다. 없는 파일과 해시 불일치는 0 이 되지만, 근거가 아예 없는 요구는 그대로 남습니다 — 그 공백은 감추지 말고 목차에 판정으로 적으세요. 목차의 표는 요구 id, 근거 수, 5단계 판정 세 칸입니다.