증상: 누가 무엇을 바꿨는지 알 수 없는 시스템 혼란
서버 또는 주요 IT 인프라에서 갑작스러운 성능 저하, 예상치 못한 서비스 중단, 보안 정책 위반 사례가 발생했습니다. 문제의 원인을 파악하기 위해 시스템 로그, 설정 변경 내역을 확인하려 했으나, 변경을 가한 사용자, 정확한 시점, 변경 내용에 대한 명확한 기록이 존재하지 않습니다. “언젠가 누군가가 무언가를 바꾼 것 같다”는 막연한 추측만이 존재하며, 이에 따라 신속한 복구와 재발 방지가 어려운 상황입니다. 이는 단순한 기록 누락이 아닌, 운영 체제나 핵심 애플리케이션의 감사 정책(Audit Policy)이 제대로 구성되지 않았거나, 중앙 집중화된 로그 관리 체계가 부재함을 의미합니다.
원인 분석: 침묵하는 시스템과 무책임한 권한 관리
이러한 감사 추적 불가능성의 근본 원인은 기술적 관리 체계의 결함에서 비롯됩니다, 첫째, windows의 로컬 보안 정책 또는 unix/linux 시스템의 감사 데몬(예: auditd) 설정이 기본값으로 유지되어 핵심 이벤트(사용자 계정 관리, 보안 정책 변경, 객체 접근 등)에 대한 로깅이 활성화되지 않았습니다. 둘째, ‘공용’ 또는 ‘공유’ 관리자 계정(예: 팀 전체가 아는 하나의 root/Administrator 암호)을 사용하는 문화가 만연합니다. 이 경우 로그에 기록되는 것은 ‘Administrator’ 또는 ‘root’라는 추상적인 식별자뿐, 실제 행위자를 특정할 수 없습니다. 셋째, 모든 로그가 각 서버에 산발적으로 저장되어 중앙에서 수집, 분석, 장기 보관되지 않아 사후 조사가 사실상 불가능합니다.
주의사항: 본 가이드에서 제시하는 감사 정책 설정 변경은 시스템 성능과 저장 공간에 직접적인 영향을 미칩니다. 과도한 로깅은 디스크 I/O 부하를 증가시키고 로그 파일을 빠르게 채울 수 있습니다. 변경 적용 전 반드시 테스트 환경에서 검증하고, 프로덕션 시스템에서는 단계적으로 롤아웃해야 합니다. 더욱이, 로그 파일의 회전(rotation) 및 보관 정책을 반드시 함께 수립하십시오.
해결 방법 1: 기본 감사 정책 강화 및 개별 계정 활용
가장 빠르게 적용 가능한 조치는 시스템의 기본 감사 기능을 활성화하고, 공용 계정 사용을 근절하는 것입니다. 이는 책임 소재의 1차적인 추적성을 확보하는 데 필수적입니다.
Windows Server 환경에서의 설정 절차:
gpedit.msc(로컬 그룹 정책 편집기) 또는 도메인 그룹 정책 관리 콘솔을 실행합니다.- 컴퓨터 구성 > Windows 설정 > 보안 설정 > 로컬 정책 > 감사 정책 경로로 이동합니다.
- 다음 정책을 최소한 ‘성공, 실패’ 모두로 설정합니다.
- 감사 계정 관리 활동
- 감사 정책 변경 활동
- 감사 권한 사용 활동
- 감사 프로세스 추적 활동 (주의: 매우 상세한 로그를 생성)
- 관리자 권한 명령 프롬프트(
cmd)를 열어gpupdate /force명령어로 정책을 강제 적용합니다.
Linux (RHEL/CentOS) 환경에서의 설정 절차:
- 터미널에서
sudo vi /etc/audit/audit.rules또는sudo vi /etc/audit/rules.d/audit.rules파일을 편집합니다. - 다음 규칙 라인을 추가합니다.
-w /etc/passwd -p wa -k identity(사용자 계정 파일 변경 감시)-w /etc/sudoers -p rwxa -k privilege_escalation(sudo 권한 설정 변경 감시)-a always,exit -F arch=b64 -S chmod -S chown -F auid>=1000 -F auid!=-1 -k system_mod(파일 권한/소유자 변경 감시)
sudo service auditd restart또는sudo systemctl restart auditd명령으로 감사 데몬을 재시작합니다.
모든 시스템 관리자는 반드시 개별적으로 발급된 고유 계정을 사용해야 합니다. 공용 계정은 즉시 비활성화하고, 모든 권한 상승 작업(예: sudo, runas)은 개인 계정으로 수행되도록 강제합니다.
해결 방법 2: 중앙 집중식 로그 관리(SIEM) 시스템 구축
각 서버의 로그를 수동으로 확인하는 것은 현실적이지 않습니다. 체계적인 감사 추적을 위해서는 중앙 집중화된 로그 수집 및 분석 시스템이 필수적입니다. 이와 같은 sIEM(Security Information and Event Management) 솔루션을 도입하거나, 오픈소스 도구를 활용한 자체 구축이 필요합니다.
ELK Stack (Elasticsearch, Logstash, Kibana) 기반 기본 아키텍처 구축 절차:
- 로그 수집기(Logstash/Beats) 배포: 모든 대상 서버에 Filebeat 또는 Winlogbeat 에이전트를 설치합니다. 에이전트는 로컬의 시스템 로그, 보안 로그, 애플리케이션 로그를 실시간으로 읽도록 구성합니다.
- 로그 전송 구성: 에이전트 설정 파일(예:
filebeat.yml)에서 중앙 Logstash 서버 또는 Elasticsearch 클러스터의 주소와 포트를 지정합니다. SSL/TLS 암호화를 적용하여 전송 구간 보안을 확보합니다. - 중앙 처리 및 저장(Logstash/Elasticsearch): 중앙 서버의 Logstash는 수신한 로그를 파싱(예: 타임스탬프, 이벤트 ID, 사용자 이름 필드 분리)하고 필터링하여 Elasticsearch에 인덱싱합니다.
- 시각화 및 분석(Kibana): Kibana 대시보드를 생성하여 ‘특정 시간대의 실패한 로그인 시도’, ‘정책 변경 이벤트 발생 추이’, ‘특정 사용자의 활동 보고서’ 등을 직관적으로 확인할 수 있습니다.
이를 통해 분산된 로그를 한곳에서 검색하고, 상관 관계를 분석하며, 이상 행위에 대한 실시간 알림을 설정할 수 있습니다.
해결 방법 3: 변경 관리(Change Management) 프로세스와 자동화 도구 연동
기술적 조치와 함께 절차적 장치를 결합해야 지속 가능한 관리가 가능합니다, 모든 시스템 변경은 공식적인 변경 관리 요청(rfc)을 통해 승인받아야 하며, 이 과정이 자동화 도구와 연동되어 물리적인 증거를 남겨야 합니다.
자동화 도구(ansible, puppet)를 활용한 변경 추적 모델:
- 인프라를 코드(infrastructure as code)로 정의: 모든 서버 구성(패키지, 설정 파일, 방화벽 규칙)은 ansible playbook이나 puppet manifest와 같은 코드로 관리합니다. 수동 콘솔 접속을 통한 변경은 원칙적으로 금지합니다.
- 버전 관리 시스템(Git) 연동: 모든 구성 코드는 Git 저장소에 저장됩니다. 변경 사항은 Pull Request를 통해 제안되고, 동료 검토(Peer Review)를 거쳐 승인된 후에만 메인 브랜치에 병합됩니다. Git 히스토리가 변경 이력의 최종 진실 소스(Source of Truth)가 됩니다.
- 자동화된 배포 실행: 승인된 코드 변경 사항은 CI/CD 파이프라인(예: Jenkins, GitLab CI)에 의해 자동으로 테스트되고, 정해진 스케줄 또는 트리거에 따라 대상 서버에 적용됩니다. 실행 결과(성공/실패, 변경 내용 diff)는 자동으로 로깅됩니다.
- 변경 사항의 실시간 검증: 자동화 도구의 보고 기능 또는 별도의 구성 관리 데이터베이스(CMDB)를 통해, ‘코드에 정의된 구성’과 ‘실제 서버의 구성’이 일치하는지 지속적으로 검증합니다. 불일치 시 즉시 경고 발생.
이 모델에서는 “누가” 변경을 요청하고 승인했는지(Git 커밋 이력), “무엇을” 변경했는지(코드 diff), “언제” 실제 시스템에 적용되었는지(자동화 도구 실행 로그)가 철저히 추적됩니다.
주의사항 및 유지 관리 가이드라인
감사 추적 체계를 구축한 후에도 지속적인 관리가 필요합니다. 설정 후 방치하면 시스템 장애나 보안 사고로 이어질 수 있습니다.
- 로그 저장소 용량 관리: 로그는 무한정 쌓이지 않습니다. 로그 로테이션 정책(예: 매일 압축, 30일 후 삭제)과 저장소 용량 모니터링을 반드시 구현하십시오. Elasticsearch 인덱스 라이프사이클 관리(ILM) 정책 활용을 권장합니다.
- 로그 보안: 중앙 로그 서버는 가장 중요한 자산 중 하나입니다. 무단 접근 및 변조를 방지하기 위해 강력한 접근 통제, 암호화, 무결성 검증(예: 해시 값 저장)을 적용해야 합니다. 로그 서버 자체의 로그는 별도 시스템에 중복 저장하는 것이 좋습니다.
- 성능 영향도 모니터링: 감사 정책을 과도하게 설정하면, 일례로 I/O 성능이 낮은 디스크를 사용하는 시스템에서 병목 현상이 발생할 수 있습니다. 프로덕션 적용 후 CPU, 메모리, 디스크 I/O 사용량을 주시하고, 필요시 로깅 수준을 조정하십시오.
- 정기적인 로그 검토 및 훈련: 로그는 검토될 때만 가치가 있습니다. 보안 운영 센터(SOC) 팀이 정기적으로 키바나 대시보드를 확인하고, 이상 징후에 대한 경고 규칙을 지속적으로 개선해야 합니다. 또한, 모든 관리자에게 개인 계정 사용의 중요성과 변경 관리 프로세스에 대한 교육을 정기적으로 실시하십시오.
전문가 팁: 무결성 모니터링 도구 도입
근본적인 예방책으로, 핵심 시스템 파일과 설정의 무결성을 모니터링하는 도구(예: AIDE(Advanced Intrusion Detection Environment) for Linux, Windows의 System File Checker(sfc) 정기 실행 스케줄링)를 배포하십시오. 이 도구들은 중요한 파일의 해시 값을 데이터베이스에 저장해 두고, 정기적으로 스캔하여 무단 변경이 발생했는지를 탐지합니다. SIEM과 연동하여 변경 감지 시 즉시 경보를 발생시키도록 구성하면, 감사 로그가 변조당하는 최악의 상황에서도 마지막 보루 역할을 할 수 있습니다. “변경 자체를 허용하지 않거나, 허용된 경로 외의 변경을 탐지하는” 접근법이 가장 강력한 책임 소재 확보의 기반이 됩니다.