감사 및 불변의 로그

감사 및 불변의 로그

1) 왜 필요한가

감사의 목적은 보안, 조사, 재무보고 및 규정 준수를 유지하기 위해 입증 가능한 무결성으로 "누가, 무엇을, 언제, 왜" 를 캡처하는 것입니다.
불변의 로그-이벤트가 추가 전용으로 만 기록되고 암호화 수단 및 스토리지 정책으로 후속 변경/삭제가 불가능하거나 감지 될 수있는 형식 및 스토리지.

2) 위협 모델 및 제어 목표

• 내부자에 의한 이벤트의 의도적 편집/삭제.
• 시간/소스 대체 (재생/백데이트).
• 노드에서 "Quiet" 로깅 종료.
• 사고/마이그레이션 중 통나무 일부 손실.
• 과도한 PII 수집 및 프라이버시와의 불일치.

1. 무결성: 수정/삭제로부터 보호하여 입증되었습니다.

2. 완벽성: 키 흐름 폐쇄 (제어 평면, 데이터 평면, 액세스, 돈).

3. 시간 정확도: 재현 가능하고 동기화 된 시간.

4. 접근성: SLO 내에서 읽고 검색합니다.

5. 개인 정보 보호: PII 최소, 토큰 화/암호화, 사용 합법성.

3) 분류 및 이벤트 우선 순위

보존 및 불변성의 우선 순위를 정하여 이벤트를 계층으로 나눕니다

제어 평면: 인증/인증, 구성 변경, 주요 작업 (KMS), 비밀 관리, 정책 변경.
데이터 평면: 객체/레코드/점검/지불에 대한 액세스; 읽기/생성/삭제.
관리자 및 DevOps: SS/콘솔, CI/CD, 인프라/IaC 변경, 권한 확대.
제품: 거래, 청구, 고객 운영.
시스템/네트워크: 커널/에이전트/프록시/밸런서, 중개인, 데이터베이스.
보안: IDS/IPS/EDR, WAF, anti-DDoS, 사기 방지, DLP.

각 클래스마다 중요, 제도, 필수 필드, 유효 기간, 불변성 요구 사항을 수정합니다.

4) 필요한 필드 및 형식

상관 ID는 'trace _ id', 'span _ id', '요청 _ id', 'actor _ id' (사용자/서비스), 'tenant _ id', 'resource _ id' 입니다.
A&A 컨텍스트: 작업 시점의 인증 방법, 역할/정책.
시간: RFC3339/UTC, 밀리 초/나노초; 동기화 소스.
동작 및 결과: 작동 유형, 목적, 상태, 영향을받는 객체 수.
무결성: 로컬 HMAC 레코드, 시퀀스 번호, 해시 프레브.
스키마: 안정적인 모델을 가진 JSON (예: 일반적인 이벤트 사전과 호환).

금지: 비밀, 키, 토큰, 전체 PAN, 암호, 개인 키. PII - 마스킹/토큰 화와 함께 필요한 경우에만.

5) 시간 및 동기화

타임 소스: 적어도 두 개의 독립 소스 (NTP/PTP) + 바이어스 모니터링.
중요한 시간 서명: 이벤트 배치에 신뢰할 수있는 타임 스탬프 (TSA) 서비스 또는 내부 타임 실링 서비스를 사용하십시오.
규칙: 현지 시간대 없음, UTC 만 해당; 로그 및 오프셋/시간 품질.

6) 로그 스트림 아키텍처

에이전트 → 버퍼 → 운송 → 랜딩 → 해시 체인/시그니처 → 콜드/아카이브 → 검색 색인.

노드에서 수집: 디스크에 버퍼가있는 라이트 에이전트 (daemonset/sidecar) (백 압력).
전송: 보호 된 채널 (SL/mSL), 보장 된 전달 (적어도 한 번), demempotent-ingest입니다.
랜딩 영역: "원시" 형태의 객체 스토리지 (날짜/테넌트/유형별 배치).
색인: 온라인 쿼리 (핫 레이어) 에 대한 검색/분석 엔진.
아카이브 (WORM): 보존 정책과 법적 보류가있는 불변의 버킷/테이프.
앵커/인감: 해시 체인 팩의주기적인 "밀봉" (아래 참조).

7) 암호화 불변성

7. 해시 체인 1 개 (추가 전용)

각 항목에는 'hash _ curr = H (레코드)', 이전 항목의 'hash _ prev', 'seq' 가 포함됩니다. 편집하면 체인이 끊어집니다.

prev = GENESIS for record in stream:
payload = canonical_json(record_without_integrity_fields)
h = H(payload          prev.hash          record.seq)
store(record + {hash_prev: prev.hash, hash_curr: h})
prev = {hash: h}

7. 팩과 타임 스탬프 2 개

N 초/MB마다 모든 'hash _ curr' 의 머클 루트: 블록을 형성합니다.
감사 키로 블록에 서명합니다 (KMS/HSM에 안정적으로 저장).
TSA 타임 스탬프를 추가하고 "투명도 로그" 를 게시하십시오.
옵션: 루트 해시를 주기적으로 외부 입증 가능한 공간 (예: 독립 저널 또는 공개 변경 불가능한 스토리지) 에 고정합니다.

7. 3 감사 키 관리

서명 키-KMS/HSM, 일정에 따른 회전, 다단계 액세스, 내보내기위한 이중 제어.
주요 철회 → 새로운 신탁 지점; 오래된 서명은 검증 가능합니다.

8) 유지 및 세계 정책

WORM/불변성: P0/P1 클래스에 대한 유지 및 법적 보류 정책이있는 불변의 컨테이너/버킷이 포함됩니다.
검증: 활성화; 삭제 - 지연이있는 절차에 대해서만 (즉시 퍼지 금지).
보존: 뜨거운 (7-30 일), 따뜻한 (3-6 개월), 차가운/보관 (1-7 년 이상-규제 기관/계약에 따라).
멀티 테넌시: 임차인 당 별도의 네임 스페이스/계정/암호화 키; 로그 액세스보고.

9) 개인 정보 보호 및 최소화

필요성의 원칙에 따라 수집: 우리는 불필요하게 기록하지 않습니다.
민감한 필드의 토큰 화/가명, 식별자의 솔트 해시.
공유 객체 스토리지에 저장될 때 생산자 측 필드 암호화 (AEAD).
삭제할 권리 (해당되는 경우): 컨테이너의 불변성 (설계 중 계획) 을 위반하지 않고 필드/파트 키의 암호화 소거를 통해 구현됩니다.

10) 감사 자체의 액세스, 역할 및 감사

스플릿: 프로듀서

WORM에서 읽기 전용; 승인을받은 별도의 역할과 절차를 통한 보존 정책 변경.
모든 읽기/내보내기 작업은 보조 로그 (메타 감사) 에 기록됩니다.
해시 블록 디렉토리 및 트러스트 체인을 사용하여 암호화 된 형태로 조사/준수를 위해 내보냅니다.

11) 관찰 및 SLO

측정 항목: 주입 속도, 지연 지연,% 손실/반복, 동기화되지 않은 시간의 일부, 서명/고정 오류, 버퍼 충전.
SLO: 99 이상입니다. 이벤트의 9% 가 10 초를 핫 인덱스로 전달했습니다. 서열에서 설명 할 수없는 "구멍" 0; 블록의 100% 가 서명되고 타임 스탬프됩니다.
경고: 주입 일시 정지> N 분, 유효하지 않은 해시 성장, 체인 발산, 시그니처/타임 스탬프 실패, 임계 값을 초과하는 시간 오프셋.

12) 테스트 및 검증

빨간색/파란색 테스트: 다른 단계에서 레코드를 편집/삭제하려는 시도; 탐지 점검.
혼돈: 노드에서 에이전트를 비활성화하고 네트워크를 끊고 버퍼 오버플로, "시간 스푸핑".
암호화 점검: 체인의 정기적 인 검증, 머클 뿌리 및 우표의 조정.
법의학: 엔드 투 엔드 로그에서 조사 스크립트를 재생합니다.

13) 운영 및 절차

런북 "무결성 점검" (주문형 및 예약).
당사자의 법적 보유 및 임시 "동결" 절차.
신뢰 체인을 유지하면서 발견 및 수출 절차.
감사 키의 회전 및 타협에 대한 대응 계획 (새로운 신탁 지점, 블록 재서명, 알림).

14) 미니 레시피

records = read_partition(ts_window)
leaves = [H(canonical_json(r)) for r in records]
root  = merkle_root(leaves)
sig   = KMS.sign(root          ts_now)
tsa   = TSA.timestamp(sig)
store_block({root, sig, tsa, count=len(leaves), window})
append_transparency_log(H(root          sig          tsa))

for i in 1..N:
assert rec[i].hash_prev == rec[i-1].hash_curr assert rec[i].hash_curr == H(canonical_json(rec[i]_no_hash)          rec[i].hash_prev          rec[i].seq)

• 제어/데이터 평면 P0: 뜨거운 30 일 → 따뜻한 6 개월 → 아카이브 7 년 (WORM).
• DevOps: 뜨거운 14 일 → 따뜻한 3 개월 → 아카이브 1 년.
• Securiti 신호: 뜨거운 90 일 (조사 용), 1-3 년.

15) 빈번한 오류

"로그는 스키마가없는 텍스트입니다. "스키마가 없으면 결정 론적 무결성과 검색이 없습니다. 표준 JSON 및 고정 필드가 필요합니다.
상관 관계가 없습니다. 'trace _ id' 가 없으면 조사가 중단됩니다.
현지 시간. UTC 전용 및 상쇄 제어.
수정 가능한 볼륨으로 작성하십시오. WORM이 없으면 불변성은 허구입니다.
읽기를 기록하지 마십시오. 민감한 데이터를 읽는 것은 쓰기 이상을 수정하는 데 중요합니다.
통나무의 비밀. 패턴의 "빨간색 목록" 을 보내기 전에 소독제를 켜십시오.
모든 것을위한 하나의 열쇠. 서명 및 암호화 키-역할 및 회전이 별도로 있습니다.

16) 준수 및 규제

유효 기간/불변성에 대한 요구 사항은 도메인 (금융, 지불, 통신 등) 에 따라 다릅니다.
확실성: WORM/유지 프로토콜의 가용성, 회로 검증 보고서, 로그 액세스 로그, 법적 보유 및 내보내기 절차.

17) 점검표

판매하기 전에

• 이벤트 분류 및 스키마 승인 (필요한 필드).
• 에이전트, 버퍼, 보호 된 운송, 역압 구성.
• 포함: 해시 체인, 블록 서명, 타임 스탬프, 투명도 로그.
• WORM/프리젠 테이션 스토리지가 활성화되었습니 덮어쓰기/삭제할 수 없음을 테스트합니다.
• 민감한 필드를 마스킹/토큰 화합니다.
• 시간 동기화 및 오프셋 모니터링.
• KMS/HSM에서 감사 키의 회전 계획 및 저장.

작동

• 체인과 블록의 주간 검증 (+ 보고서).
• 회로 중단/시그니처 오류/시간 오프셋 경고.
• 정기적 인 적색 팀 대체/삭제 테스트.
• 보류 및 비용에 대한 정기적 인 검토.

18) FAQ

Q: 데이터베이스 수준에서 "그냥 추가" 하는 것이 충분합니까?
아뇨 암호화 보증 (해시 체인, 블록 서명, 타임 스탬프) 및 WORM 정책이 필요합니다.

Q: 데이터를 삭제할 권리는 어떻습니까?
A: 필드/파티를위한 암호화 소거 (키 제거) 를 설계하여 미디어를 변경할 수없고 로그를 입증 할 수 있습니다.

Q: 블록에 서명하려면 별도의 키가 필요합니까?
오, 그래 스토리지 암호화 키와 별도의 블록 서명 키; 회전 및 감사와 함께 KMS/HSM에 저장하십시오.

Q: 공공 장소에 "고정" 할 수 있습니까?
A: 선택 사항. 이것은 검증 성을 향상시키고 회로 내에서 "재 작성 기록" 을 차단합니다.

• "휴식 암호화 중"
• "대중 교통 암호화"
• "비밀 관리"
• "키 관리 및 회전"
• "서명 및 확인 요청"