시스템 로그·감사·파일 무결성 | 정보보안기사 필기

1. 로그와 감사의 역할

로그는 운영체제·서비스·응용프로그램이 상태와 사건을 남긴 기록이다. 감사는 그중 보안 정책상 추적할 행위를 정해 기록하는 데 초점이 있다. 로그에 없다는 이유만으로 사건이 없었다고 결론 내리면 안 된다. 기록 설정, 보존 기간, 수집 실패, 위·변조 여부를 함께 확인해야 한다.

기록 체계	주된 역할	대표 도구
systemd journal	커널·서비스 등의 구조화된 로그 수집	journalctl
syslog 계열	출처·긴급도별 분류와 로컬·원격 저장	rsyslog 등
Linux Audit	감사 규칙에 따른 보안 행위 기록	auditd, ausearch, aureport

journald와 rsyslog는 함께 동작할 수 있다. auditd가 실행 중이라고 모든 파일 접근이 자동 기록되는 것은 아니다. 해당 사건이 감사 규칙과 일치해야 한다.

2. syslog의 facility와 severity

facility는 메시지의 출처 분류다. kern은 커널, mail은 메일, daemon은 데몬, auth/authpriv는 인증 관련 메시지에 사용된다. severity는 긴급도이며 숫자가 작을수록 긴급도가 높다.

값	이름	의미
0	emerg	시스템 사용 불가 수준의 비상
1	alert	즉시 조치 필요
2	crit	치명적 상태
3	err	오류
4	warning	경고
5	notice	정상이나 주의할 상태
6	info	정보성 메시지
7	debug	디버깅 정보

예를 들어 ‘authpriv의 warning’은 인증 관련 출처의 경고 메시지다. authpriv 자체가 가장 높은 긴급도를 뜻하지 않는다. 프로그램이 부여한 수준과 실제 보안 영향도 구분해야 한다.

3. 저장 위치와 로그인 이력

인증 기록은 배포판과 설정에 따라 /var/log/secure 또는 /var/log/auth.log 등에 저장될 수 있다. 일반 메시지는 /var/log/messages나 /var/log/syslog에서 볼 수 있지만 모든 Linux가 같은 파일을 사용하는 것은 아니다. journal만으로 기록하는 구성도 있다.

전통적인 기록	내용	대표 조회 명령
utmp	현재 로그인 세션	who, w
wtmp	로그인·로그아웃 등 이력	last
btmp	실패한 로그인 이력	lastb
lastlog	사용자별 최근 로그인	lastlog

파일의 존재와 기록 방식은 환경에 따라 다르다. 사용자 셸의 history는 누락되거나 사용자가 수정할 수 있으므로 완전한 감사 로그로 취급하지 않는다.

4. 시간과 사건을 연결하는 방법

로그를 읽을 때 ‘시간 → 사용자·세션 → 프로세스 → 대상 → 행위·결과’를 찾는다. 여러 서버의 기록을 합칠 때는 시간대와 시계 동기화 상태도 맞춰야 한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

10:31 계정 ops 로그인 성공
10:33 api 서비스 재시작
10:34 설정 파일의 기준 해시 불일치 발견

이 기록에서 확정할 수 있는 것은 로그인과 재시작이 기록됐고 파일 내용이 기준선과 달라졌다는 사실이다. 시간상 가깝다는 이유만으로 ops가 공격자라거나 해당 사용자가 파일을 바꿨다고 단정하지 않는다. 같은 시점의 감사 기록과 승인된 변경 내용을 함께 확인한다.

성공한 로그인도 탈취 계정을 이용한 행위일 수 있고 실패한 로그인은 단순 입력 실수일 수 있다. 성공·실패는 행위의 결과이며 정상·공격 여부와 같지 않다.

5. 보존과 로그 보호

로그 회전은 파일을 교체·압축하고 보존 기간이 지난 기록을 정리하는 정상 관리 기능이다. 오래된 기록이 없으면 삭제 공격뿐 아니라 회전·보존 정책도 확인한다. journal은 설정에 따라 휘발성 저장소를 쓰므로 재부팅 후 기록이 사라질 수도 있다.

중요 로그에는 최소권한, 시간 동기화, 충분한 보존, 별도 서버로의 수집을 적용한다. 중앙 수집은 침해된 호스트에서 증거를 지우는 위험을 줄이지만, 수집 서버 자체의 계정과 기록도 보호해야 한다.

6. 파일 무결성은 신뢰할 수 있는 기준선과 비교한다

정상 상태의 파일 해시·권한·소유자 등의 정보를 기준선으로 보관하고 현재 상태와 비교한다. AIDE와 Tripwire는 이런 파일 무결성 검사에 사용하는 대표 도구다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

정상 상태 확인 → 기준선 생성·보호 → 현재 파일과 비교
                                      ↓
                          변경 발견 → 원인과 승인 여부 확인

해시가 다르면 내용이 변경된 것이다. 그러나 정상 패치나 설정 변경도 해시를 바꾸므로 악성 변경 여부는 별도로 판단한다. 해시는 누가 왜 바꿨는지 직접 알려주지 않는다. 감사 기록은 변경 주체와 행위를 추적하는 데 도움을 준다.

공격자가 대상 파일과 기준선까지 함께 바꾸면 비교의 신뢰성이 무너진다. 기준선은 별도로 보호하고 승인된 변경을 확인한 뒤에만 갱신한다. 파일 크기와 수정 시각이 같아도 내용은 다를 수 있다.

7. 체크섬과 보안 해시

CRC는 우발적인 전송·저장 오류 검출에 적합하며 악의적인 조작 방지를 위한 암호학적 해시가 아니다. MD5와 SHA-1은 충돌 취약성이 알려져 있어 새로운 보안 무결성 기준선에 적합하지 않다. SHA-256 같은 암호학적 해시를 사용하더라도 기준선 보호가 함께 필요하다.

핵심은 ‘로그는 사건의 흔적, 감사는 보안 행위 추적, 무결성 검사는 기준선 대비 변경 탐지’라는 역할 차이다.