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

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

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이다. Manifest에는 번들 버전, 생성 시각, 포함된 파일과 각 파일의 SHA-256을 기록한다. ZIP에서 파일 하나만 수정돼도 manifest 검증 결과가 달라진다.

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

서버에 별도의 signing secret을 설정한 경우에는 manifest 전체를 canonical form으로 만든 뒤 HMAC-SHA256 서명도 추가한다. 서명이 없어도 각 파일의 SHA-256은 항상 남긴다. 개발 환경까지 서명 secret을 강제하면 사용하기 어려워지고, 반대로 hash조차 없으면 번들의 일관성을 확인할 수 없기 때문이다.

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

Node Agent의 Evidence에는 노드 이름, 주소, 로그 일부, 경로처럼 외부에 공유하면 안 되는 값이 포함될 수 있다. Export 단계에서는 분석에 필요한 구조를 유지하면서 민감정보를 먼저 제거한다.

이 순서를 중요하게 봤다.

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

원본으로 hash를 만든 뒤 redaction하면 사용자가 받은 파일과 hash가 맞지 않는다. 반대로 ZIP을 만든 후 일부 파일만 수정하면 manifest가 무의미해진다. 따라서 사용자가 실제로 받는 redacted 파일을 기준으로 무결성 정보를 만들었다.

권한과 Audit도 함께 묶기

Evidence bundle은 단순 조회보다 더 많은 정보를 포함한다. Report와 Evidence export는 ADMIN, OPERATOR 역할로 제한하고, 누가 어떤 Report 또는 Incident를 export했는지 Audit event를 남겼다.

Web Console에서는 ZIP 자체를 열기 전에 다음 정보를 확인할 수 있게 했다.

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

API가 반환하는 manifest 요약은 편의를 위한 정보다. 최종 기준은 ZIP 안에 포함된 manifest.json이다. 서버 응답과 다운로드 파일이 서로 다른 기준을 갖지 않도록 했다.

왜 PDF 하나로 만들지 않았나

PDF는 사람이 읽기 좋지만 자동 검증과 재분석에는 불편하다. 반대로 JSON만 제공하면 운영자가 빠르게 내용을 이해하기 어렵다. 그래서 Markdown 요약과 구조화된 JSON을 함께 넣었다.

또한 Evidence bundle을 법적 증거처럼 과장하지 않았다. SHA-256과 HMAC은 파일 변경 여부를 확인하는 수단이지, 수집 시점의 모든 사실이 참이라는 보장은 아니다. 수집 실패나 오래된 데이터는 이후 추가한 Evidence Quality에서 별도로 표현한다.

구현 후 달라진 점

이제 Report를 볼 때 “원인은 디스크였다”에서 끝나지 않는다.

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

이 흐름을 하나의 번들에서 다시 확인할 수 있다. 운영자에게 필요한 것은 결론을 믿으라는 요구가 아니라, 결론을 검토할 수 있는 재료라는 점을 다시 확인했다.

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