Quiz: Audit Logs and Traceability

여신한도 표를 제자리 UPDATE 로 갱신하면서 updated_at 과 updated_by 컬럼을 함께 두었다. 이 설계가 감사에서 답하지 못하는 것은?

• 지금 한도가 얼마인지
• 이 고객의 한도가 이번 달에 몇 번 어떤 값으로 거쳐 왔는지
• 가장 마지막으로 값을 바꾼 계정이 무엇인지
• 값이 마지막으로 바뀐 시각이 언제인지

같은 사건을 두 시스템이 각각 JSON 으로 만들었는데 해시가 달랐다. 내용은 같고 키 순서와 공백만 달랐다면 가장 알맞은 처방은?

• 두 시스템이 같은 JSON 라이브러리를 쓰도록 버전을 맞춘다
• 해시 대신 문자열 길이와 필드 개수를 비교해 같은 사건인지 본다
• 정규 직렬화 규칙을 정해 키를 정렬하고 공백을 없앤 뒤 같은 인코딩으로 해시한다
• 사건마다 UUID 를 붙여 해시 대신 그 값으로 동일성을 판정한다

해시 사슬로 묶인 감사 기록에서 중간 한 줄의 금액만 고치고 그 줄의 entry_hash 는 그대로 두었다. 검증했을 때 나타나는 증상은?

• 그 줄의 내용을 다시 계산한 해시가 저장된 entry_hash 와 달라진다
• 그 줄의 다음 항목부터 prev_hash 가 어긋나기 시작한다
• 사슬의 머리 해시만 달라지고 중간은 그대로 통과한다
• seq 번호가 어긋나 빠진 항목이 있는 것으로 보고된다

감사 기록 전체를 읽고 쓸 수 있는 운영자가 해시 사슬을 처음부터 끝까지 다시 계산해 갈아 끼웠다. 이것을 막기 위해 더해야 할 것은?

• 사슬을 만들 때 SHA-256 대신 더 긴 SHA-512 를 쓴다
• 사슬 항목마다 생성 시각을 넣어 시간 순서를 함께 검사한다
• 기록을 매일 압축해 별도 디렉터리에 복사해 둔다
• 항목마다 열쇠로 MAC 을 만들고 그 열쇠를 기록과 다른 자리에 둔다

협력사에서 받은 사슬 반출본을 검증했더니 seq 288 이 없고 seq 289 의 prev_hash 가 앞 항목의 entry_hash 와 달랐다. 이 관찰에서 내릴 수 있는 결론은?

• 289 의 내용이 조작되었으므로 289 만 재전송받으면 된다
• 사슬의 시작 항목이 잘못되어 그 뒤 전체가 어긋난 것이다
• 협력사와 우리의 해시 규칙이 달라 288 부터 전부 다시 계산해야 한다
• 288 항목이 빠진 채 반출되었고 그 때문에 289 의 연결이 끊긴 것이다

한 번의 한도 변경이 창구 앱, 한도 서비스, 코어 배치, 감사 릴레이를 거쳤다. 조사 시간을 가장 크게 줄이는 설계는?

• 시스템마다 로그 형식을 통일해 같은 컬럼 이름을 쓰게 한다
• 요청에 상관 ID 를 붙여 네 시스템의 로그에 끝까지 흘려보낸다
• 네 시스템의 로그를 한 곳에 모아 시각 순으로 정렬해 보관한다
• 각 시스템이 자기 로그를 매 시간 요약해 지표로 내보낸다