RCA 보고서를 증거 번들로 내보내고 무결성을 검증하기

문제는 보고서가 만들어진 다음부터 시작됐다

Node Agent의 Linux·Kubernetes Evidence로 원인 후보를 만들고 화면에서 Report를 조회할 수 있게 됐다. 그다음에는 분석 결과를 공유하고 보존하는 과정에서 필요한 항목이 보였다.

• 장애가 끝난 뒤 당시 근거를 다시 확인하기 어렵다.
• 화면의 요약만 전달하면 어떤 Evidence로 결론을 만들었는지 빠진다.
• JSON 몇 개를 따로 내려받으면 같은 시점의 자료인지 확인하기 어렵다.
• 파일이 전달되는 과정에서 수정돼도 알아차릴 방법이 없다.
• 민감정보가 포함된 원본 수집 결과를 그대로 공유할 수 없다.

결론, 근거, 판단 순서를 함께 보관하려고 Report export를 Evidence bundle로 구성했다.

Evidence bundle 구성

Report나 Incident를 export할 때 다음 파일을 ZIP으로 묶었다.

summary.json
evidence/*.json
signals.json
timeline.json
rca-report.md
manifest.json

summary.json에는 Incident와 Report 식별 정보, 증상, 유력 원인, confidence를 넣었다. evidence/*.json은 분석에 사용한 수집 결과를 redaction한 파일이다. signals.json에는 Rule Engine의 필드와 임계값, timeline.json에는 장애 전파 관계를 담았다. rca-report.md는 사람이 읽을 요약으로 사용했다.

manifest.json에는 번들 버전, 생성 시각, 파일 목록과 파일별 SHA-256을 기록했다. 파일이 변경되면 manifest와 대조해 확인할 수 있도록 했다.

{
  "file": "signals.json",
  "sha256": "<digest>",
  "size": 2841
}

별도 signing secret이 설정된 서버에서는 manifest를 canonical form으로 만든 뒤 HMAC-SHA256 서명을 추가했다. 서명 설정이 없어도 파일별 SHA-256은 남겼다. 개발 환경에서는 서명을 선택할 수 있게 하되 파일 일관성 검사는 유지했다.

원본을 그대로 넣지 않은 이유

Evidence에는 노드 이름, 주소, 로그, 내부 경로가 포함될 수 있었다. export에 필요한 구조를 유지하면서 민감정보를 먼저 제거했다.

처리 순서는 다음과 같이 정했다.

원본 Evidence
  → redaction
  → export용 파일 생성
  → 파일별 SHA-256 계산
  → manifest 생성과 선택적 서명
  → ZIP 생성

redaction 전에 hash를 만들면 사용자가 받은 파일과 값이 달라진다. ZIP 생성 후 파일을 수정하는 경우에도 manifest가 맞지 않는다. 최종 전달할 redacted 파일로 무결성 정보를 계산했다.

권한과 Audit도 함께 묶기

Report와 Evidence export는 ADMIN, OPERATOR로 제한했다. 조회보다 많은 정보가 포함되므로 누가 어느 Report나 Incident를 export했는지도 Audit에 기록했다.

Console에서는 다운로드 전에 다음 정보를 보여줬다.

• 현재 bundle profile
• redaction 적용 여부
• manifest와 signature 활성 상태
• 오프라인 검증 명령

API의 manifest 요약은 확인 편의를 위한 정보로 두고, 검증 기준은 ZIP 안의 manifest.json으로 맞췄다.

왜 PDF 하나로 만들지 않았나

사람이 읽을 Markdown 요약과 자동 검증·재분석에 사용할 JSON을 함께 넣었다. PDF만으로 제공할 때의 후처리 제약과 JSON만 제공할 때의 읽기 불편을 줄이려는 선택이었다.

SHA-256과 HMAC으로 확인하는 것은 파일 변경 여부다. 수집 당시의 모든 사실이 참임을 보장하지는 않는다. 수집 실패나 오래된 데이터는 이후 Evidence Quality에서 따로 표현했다.

구현 후 달라진 점

export한 자료에서 다음 흐름을 확인할 수 있도록 했다.

어떤 collector가 어떤 값을 수집했는가
  → 어떤 Rule signal이 만들어졌는가
  → 어떤 Incident timeline으로 연결됐는가
  → 어떤 권장 조치가 어떤 정책으로 분류됐는가

원인 후보가 나온 과정과 사용한 근거를 같은 번들에서 다시 검토할 수 있게 됐다.

프로젝트 저장소: Kubernetes Cluster Infra RCA Platform