감사 로그

감사 로그는 시스템 안에서 누가 언제 무엇을 했는지를 나중에 따져 볼 수 있게 남겨 둡니다. 일이 벌어진 다음에 무슨 일이었는지 확인하려고 쓰는 기록이라, 한 번 적은 줄은 고치지도 지우지도 않습니다. 권한을 바꾸거나 돈이 오가는 일처럼 나중에 확인할 거리가 생기는 행위가 주된 대상입니다.

상세

계산대에서 결제를 누르면 영수증이 나옵니다. 거기 찍힌 일련번호는 기계가 순서대로 붙인 것이라 점원이 마음대로 바꿀 수 없습니다. 나중에 한 건을 없던 일로 만들면 번호 하나가 비어서 그 자리가 드러납니다.

감사 로그는 사람이 아니라 프로그램이 적습니다. 사람이 적으면 바쁠 때 빠뜨립니다. 프로그램이 적으면 그 행위를 처리하는 길목마다 한 줄이 따라 붙습니다.

감사 로그 한 줄의 여섯 칸

한 줄은 「누가 언제 무엇에 무슨 일을 했나」에 혼자서 답해야 합니다. 나중에 읽는 사람은 그때의 화면도 맥락도 못 보고 이 줄만 봅니다.

칸 하나가 빠지면 그만큼 물을 수 없는 것이 생깁니다.

여섯 칸을 채운 한 줄은 이렇게 생겼습니다.

{
  "actor":  "admin:1042",
  "action": "role.grant",
  "target": "user:8871",
  "result": "success",
  "at":     "2026-09-18T04:12:07Z",
  "from":   "203.0.113.7"
}

관리자 계정 1042 가 사용자 8871 에게 역할을 줬고 그 일이 됐다는 뜻입니다. 시각은 타임스탬프로 적었습니다.

값은 사람이 읽을 이름이 아니라 식별자로 적습니다. 이름과 부서는 나중에 바뀌지만 식별자는 안 바뀌어서, 몇 해 뒤에 읽어도 같은 대상을 가리킵니다.

응용 로그와 가르는 선

개발자가 오류를 쫓으려고 남기는 로그와 감사 로그는 생김새가 비슷합니다. 둘 다 한 줄에 시각과 내용을 적은 글줄입니다.

다른 것은 목적입니다. 응용 로그는 「왜 이게 안 됐나」에 답하려고 남기고, 감사 로그는 「누가 이걸 만졌나」에 답하려고 남깁니다. 목적이 다르니 다루는 규칙도 갈립니다.

가르는 기준은 하나입니다. 그 줄이 사라졌을 때 곤란해지는 사람이 우리 팀 안에 있으면 응용 로그이고, 바깥에 설명해야 하는 사람이면 감사 로그입니다.

한 줄을 남기는 지점

어디에서 줄을 적느냐에 따라 아는 것과 놓치는 것이 갈립니다. 셋 중 하나를 고르거나 겹쳐 씁니다.

애플리케이션 안에서 남기면 의도까지 적을 수 있습니다. 대신 관리자가 데이터베이스에 직접 붙어 값을 고치면 그 줄은 안 남습니다.

트리거는 그 구멍을 메웁니다. 트리거는 어떤 표에 변경이 생길 때마다 데이터베이스가 알아서 실행하는 작은 절차입니다. 경로를 안 가리고 값의 변화를 잡는 대신, 바꾼 사람이 누구인지는 데이터베이스가 모릅니다.

무엇을 남길지도 정해야 합니다. 막힌 요청도 남기는 것이 보통입니다.

flowchart TD
    A["요청이 들어온다"] --> B{"권한이 있나"}
    B -->|없다| C["거부한다"]
    C --> D["거부를 한 줄 남긴다"]
    B -->|있다| E["요청한 일을 처리한다"]
    E --> F["무엇이 바뀌었는지 한 줄 남긴다"]

그림에서 거부된 요청에도 줄이 남습니다. 막힌 시도가 한 계정에서 되풀이되는 것 자체가 나중에 볼 거리이기 때문입니다.

고쳐 쓰지 못하게 막는 세 갈래

감사 로그는 자기를 남긴 시스템을 상대로도 증거가 되어야 합니다. 권한 가진 사람이 자기가 한 일을 지울 수 있으면 그 기록은 증거 노릇을 못 합니다.

첫째는 권한을 가르는 것입니다. 기록을 쌓는 계정에 덧붙이기만 허용하고 수정과 삭제는 주지 않습니다. 최소 권한을 감사 로그에 적용한 꼴입니다.

둘째는 저장소를 떼어 놓는 것입니다. 원본 데이터베이스와 다른 계정, 다른 장비에 쌓으면 한쪽을 장악해도 다른 쪽이 남습니다.

셋째는 줄끼리 엮는 것입니다. 줄을 적을 때 앞 줄의 해시를 같이 넣습니다. 해시는 아무 길이의 데이터를 정해진 길이의 값 하나로 줄이는 계산이고, 입력이 한 글자만 달라져도 값이 달라집니다.

flowchart TD
    L1["1번 줄"] --> L2["2번 줄 · 1번 줄의 해시를 안고 있다"]
    L2 --> L3["3번 줄 · 2번 줄의 해시를 안고 있다"]
    L3 --> L4["4번 줄 · 3번 줄의 해시를 안고 있다"]

2번 줄을 몰래 고치면 3번 줄이 들고 있는 값과 어긋납니다. 손댄 사람은 그 뒤 줄을 전부 다시 계산해야 하고, 그러지 않으면 훑어보기만 해도 어느 줄이 고쳐졌는지 드러납니다.

적으면 안 되는 값

감사 로그는 오래 보관되고 여러 사람이 들여다봅니다. 그래서 무엇을 적느냐가 그 자체로 위험이 됩니다.

비밀번호나 액세스 토큰 같은 비밀 값은 적지 않습니다. 「비밀번호가 바뀌었다」는 남기고 바뀐 값은 남기지 않습니다. 개인 정보도 같습니다. 식별자만 남기고 내용은 원본 저장소에 둡니다.

적는 순간에 사람이 판단하게 두면 새 칸이 생길 때마다 흘러 나갑니다. 지울 칸의 이름을 미리 목록으로 정해 두고 그 목록을 지나서 기록하는 편이 덜 샙니다.

남기는 데 치르는 대가

부피가 늡니다. 변경 한 번에 줄 하나가 붙으므로 오래 굴린 시스템에서는 감사 로그가 원본 표보다 커지기도 합니다. 오래 두어야 하는 기록이라 지우기도 어렵습니다.

기록과 행위를 어떻게 묶을지도 정해야 합니다. 둘을 한 트랜잭션으로 묶으면 기록이 실패할 때 행위도 같이 되돌아갑니다. 트랜잭션은 여러 작업을 한 덩이로 묶어 전부 되거나 전부 안 되게 하는 단위입니다. 따로 떼면 행위는 됐는데 줄은 안 남는 구간이 생깁니다. 어느 쪽을 받아들일지는 그 행위가 얼마나 중한지가 정합니다.

마지막은 읽는 사람입니다. 어떤 줄이 나오면 누구에게 알림을 보낼지 정해 두지 않으면, 쌓아만 두다가 사고가 난 뒤에야 처음 열어 보게 됩니다.

관련 항목

감사 로그 한 줄을 이루는 구성 요소

타임스탬프 · 식별자 · 상관 관계 ID · IP 주소 · 사용자 에이전트

감사 로그와 나란히 분류되는 기록 갈래

로그 · 구조화 로그 · 접근 로그 · 이벤트 로그 · 메트릭 · 트레이스

감사 로그가 주체를 가려내는 데 기대는 수단

인증 · 인가 · 인증과 인가 · 접근 제어 · 역할 기반 접근 제어 · 최소 권한 · 권한 · 서비스 계정

감사 로그를 남기는 지점과 방식

트리거 · 변경 데이터 캡처 · 이벤트 소싱 · 미들웨어 · 게이트웨이 · 인터셉터

감사 로그를 고치지 못하게 지키는 기법

해시 · 해시 함수 · 해시 체인 · 디지털 서명 · WORM 저장소 · 변조 탐지

감사 로그를 쌓아 두고 찾아보는 저장소

로그 수집 · Elasticsearch · 객체 스토리지 · 보존 기간 · 아카이빙

감사 로그를 요구하는 규정과 제도

규정 준수 · PCI DSS · HIPAA · SOC 2 · GDPR · 내부 통제

감사 로그를 열어 보게 되는 상황

사고 대응 · 포렌식 · 침해 사고 · 내부자 위협 · 권한 상승 · GitLab 데이터 삭제 사고

감사 로그에 남기면 안 되는 값

개인 정보 · 액세스 토큰 · 시크릿 관리 · 마스킹 · 가명 처리

감사 로그를 지켜보는 운영 활동

모니터링 · 관측성 · 알림 · 보안 엔지니어링 · 침입 탐지