SQL Server에서 “사용자 감시(User Monitoring)”를 제대로 하려면, 단순히 로그를 남기는 것이 아니라 정책(무엇을/누가/어디에/얼마나) → 구현 → 보관/위·변조 방지 → 모니터링/리뷰 → 사고 대응까지 하나의 운영 체계로 만들어야 합니다.

이 글은 SQL Server Audit(서버/DB 감사) 를 중심으로, 엔터프라이즈 환경에서 바로 적용 가능한 7가지 감사 로그 운영 방법을 “설계 → 구축 → 운영” 관점으로 정리합니다.

---

감사 로그 관리가 왜 중요한가?

1) 내부자 위협·랜섬웨어·규제 대응의 핵심 증거

DB 보안에서 외부 침입만 보는 것은 위험합니다. 실제 사고는 종종 내부자 계정 남용, 운영 실수, 권한 오남용, 설정 변경에서 시작됩니다.
감사 로그가 준비되어 있으면 다음 질문에 증거 기반으로 즉시 답할 수 있습니다.

• 누가(계정/역할) 언제 어떤 DB/객체에 접근했는가?
• 누가 권한을 올렸고(역할 변경/GRANT), 어떤 경로로 접근했는가?
• 민감 데이터(개인정보/급여/거래/의료)를 누가 조회/수정했는가?
• 감사 기능 자체를 누가 껐거나 바꿨는가?

또한 금융/공공/의료/제조 등 많은 산업에서 접근 기록 보관과 추적 가능성(Traceability)을 규정으로 요구합니다. 운영팀이 “로그로 증명”할 수 없으면, 사고가 없어도 감사/심사에서 리스크로 잡힙니다.

2) 장애 분석과 책임 추적(Traceability)

감사 로그는 보안뿐 아니라 운영 장애에서도 강력합니다.

• 특정 테이블 데이터가 갑자기 삭제/변경된 경우
• 스키마/인덱스/권한 변경 이후 성능이 급락한 경우
• 배치나 앱이 의도치 않게 대량 UPDATE/DELETE를 수행한 경우

“누가 어떤 권한으로 어떤 명령을 실행했는지”가 남아 있으면 복구 전략 수립 속도와 정확도가 올라가고, 재발 방지(원인 제거)까지 연결됩니다.

---

MSSQL 감사 기능 한눈에 보기

SQL Server Audit 기본 구성 요소(3개 객체)

SQL Server Audit은 일반적으로 다음 3개 객체 조합으로 설계합니다.

• Server Audit
• “어디에 로그를 기록할 것인가?” (파일/Windows 로그/외부 연동 등)
• Server Audit Specification
• 서버 수준 이벤트(로그인/권한 변경/서버 설정 변경 등) 중 무엇을 기록할지
• Database Audit Specification
• 특정 DB에서 어떤 객체/동작(SELECT/INSERT/UPDATE/DELETE/EXECUTE 등)을 기록할지

SQL Server Audit은 내부적으로 Extended Events 기반 이벤트 수집 메커니즘을 활용하며, 필요한 이벤트만 선택적으로 수집할 수 있어 성능 영향과 로그 용량을 제어하는 것이 가능합니다.

서버 감사 vs 데이터베이스 감사(실무 분리 전략)

• 서버 감사(Server-level): 로그인/실패로그인, 서버 권한/역할 변경, 감사 설정 변경 등
  → “DBA/운영자 활동”과 “보안 설정 변경”을 잡는 데 적합
• DB 감사(Database-level): 민감 테이블 접근, 특정 계정/역할의 DML/DDL, EXECUTE 추적 등
  → “민감 데이터 접근 감시”와 “규정 준수(컴플라이언스)”에 적합

실무에서 가장 흔한 패턴은:

• 서버 감사로 기본 보안/운영 이벤트(베이스라인) 를 잡고,
• DB 감사로 핵심 테이블/핵심 계정 중심으로 정밀 감시를 추가하는 방식입니다.

(참고) C2 Audit 모드와 차이

C2 Audit은 레거시/특수 요건에서 언급되곤 하지만, 이벤트를 대량으로 포괄 기록해 용량·성능·운영 리스크가 매우 커질 수 있습니다.
현대적인 운영 환경에서는 일반적으로 SQL Server Audit 중심으로 “필요 이벤트만” 설계하는 접근이 더 안전합니다.

---

MSSQL 사용자 감시 감사 LOG 운영 “7가지 방법”

아래 7가지는 “기능 7개”가 아니라, 실무 운영에서 실패하지 않기 위한 7개의 설계/구현/운영 원칙입니다.

---

1) 요구사항 수집과 감사 정책(Policy) 정의부터 시작하라

기술 설정 전에 반드시 정책을 고정해야 합니다. 가장 많이 실패하는 원인이 “감사 범위/목적 불명확”입니다.

1.1 최소로 정의해야 할 정책 항목

• 감사 목적: 규제/내부통제/침해사고 대응/운영 장애 추적 등
• 감사 대상
• 서버 수준(로그인, 역할/권한 변경, 감사 설정 변경 등)
• DB 수준(민감 테이블 접근, DDL, EXECUTE 등)
• 감사 주체(Principal)
• DBA 계정/그룹, 개발자 계정, 외주/임시 계정, 애플리케이션 계정
• 보존 기간(Retention): 1년/3년/5년 등(법/규정/내부정책 기준)
• 접근 통제(RBAC): 누가 로그를 읽을 수 있는가? 누가 삭제/이동할 수 있는가?
• 운영 프로세스: 일/주/월 점검, 이상징후 알림, 사고 시 증적 제출 절차

1.2 실무 팁: “누가/무엇을” 먼저 정하면 구현이 쉬워진다

• 누가: 고권한 역할(sysadmin/db_owner/securityadmin 등), 외주 계정, 서비스 계정
• 무엇을: 권한/역할 변경, 로그인 실패, 민감 테이블 SELECT, 대량 변경(UPDATE/DELETE), DDL 변경
  이 5가지는 대부분 산업에서 공통으로 “최소 감사 세트”에 들어갑니다.

---

2) 서버 감사(Server Audit) 설계: 목적지(Destination)와 장애 시 동작을 먼저 결정하라

Server Audit은 “감사 이벤트를 어디에 기록할지”를 정의합니다.

2.1 파일(File) 목적지 기반 Server Audit 생성(T‑SQL)

USE master;
GO

CREATE SERVER AUDIT [Audit_UserMonitoring]
TO FILE (
    FILEPATH = 'D:\SQLAudit\',
    MAXSIZE = 500 MB,
    MAX_ROLLOVER_FILES = 50,
    RESERVE_DISK_SPACE = OFF
)
WITH (
    QUEUE_DELAY = 1000,       -- ms: 이벤트 버퍼링 지연(성능/유실 트레이드오프)
    ON_FAILURE = CONTINUE     -- CONTINUE | FAIL_OPERATION | SHUTDOWN
);
GO

ALTER SERVER AUDIT [Audit_UserMonitoring] WITH (STATE = ON);
GO

옵션 해석(실무 관점)

• QUEUE_DELAY: 성능과 “즉시성”의 균형값. 과도하게 0에 가깝게 하면 I/O 부담이 커질 수 있습니다.
• ON_FAILURE
• CONTINUE: 감사 로그 실패 시에도 업무는 계속(개발/일반 운영에서 현실적)
• FAIL_OPERATION: 감사 실패 시 해당 작업을 실패 처리(민감 환경에서 선택)
• SHUTDOWN: 감사 실패 시 SQL Server 종료(극단적으로 민감한 환경에서만 고려)

운영 환경에서 FAIL_OPERATION/SHUTDOWN은 장애 리스크가 크므로, 보안팀/운영팀 합의와 리허설 없이 적용하면 위험합니다.

2.2 SSMS GUI로 생성(운영 표준화)

• 서버 → Security → Audits 우클릭 → New Audit…
• Destination(File/Application Log/Security Log 등), 파일 경로/옵션 설정
• 생성 후 Enable

GUI는 “초기 구성 이해”에 좋고, 운영 표준화는 T‑SQL 스크립트(형상관리)가 더 안전합니다.
권장: GUI로 한번 만든 후 → Script as Create로 스크립트화.

---

3) 서버 수준 베이스라인 감사(Server Audit Specification): “감사 자체 변경”까지 반드시 감시하라

서버 수준에서는 다음 이벤트 그룹이 가장 빈번히 요구됩니다.

• 로그인/로그아웃/실패 로그인
• 서버 권한/역할 변경(권한 상승 시도 포함)
• 감사 설정 변경(감사 끄기/수정 시도)
• 서버 구성 변경(운영 환경에 따라)

3.1 Server Audit Specification 예시(T‑SQL)

USE master;
GO

CREATE SERVER AUDIT SPECIFICATION [AuditSpec_ServerBaseline]
FOR SERVER AUDIT [Audit_UserMonitoring]
-- 로그인/인증 계열(환경에 맞춰 선택)
ADD (FAILED_LOGIN_GROUP),
ADD (SUCCESSFUL_LOGIN_GROUP),
ADD (LOGOUT_GROUP)

-- 권한/역할 변경 계열(권한상승/내부자 남용 탐지 핵심)
ADD (SERVER_ROLE_MEMBER_CHANGE_GROUP),
ADD (SERVER_PERMISSION_CHANGE_GROUP),
ADD (SERVER_PRINCIPAL_CHANGE_GROUP)

-- 감사 설정 변경 감시(“감사를 끄는 행위”를 감사해야 함)
ADD (AUDIT_CHANGE_GROUP)
WITH (STATE = ON);
GO

위 Action Group 이름은 SQL Server Audit에서 제공하는 그룹 단위 이벤트입니다.
조직 정책에 따라 “필수”와 “선택”을 나누고, 초기에는 꼭 필요한 것부터 시작하는 것이 안전합니다.

3.2 실무 권장: “베이스라인 + 예외 추가” 방식

• 처음부터 너무 많이 넣으면 로그 폭증 → 운영 포기(“로그가 너무 많아 못 봄”)
• 베이스라인(로그인/권한변경/감사변경)으로 시작
  → 리뷰/운영 안정화 후, 필요한 이벤트를 점진적으로 확장합니다.

---

4) 데이터베이스 감사(Database Audit Specification): “민감 테이블 접근”은 넓게 말고 정확히

DB 감사는 설계에 따라 로그가 폭발하기 쉽습니다. 정밀 타겟팅이 핵심입니다.

4.1 접근 감사 전략 2가지(실무 선택)

1) 중요 테이블 중심(권장)

• 급여/개인정보/거래/의료 등 “정말 중요한 테이블”만
• 특정 Principal(역할/사용자)만
  2) 스키마/DB 접근 그룹 기반(강력하지만 비용 큼)
• 객체 접근 그룹을 통째로 잡으면 편하지만, OLTP에서는 로그가 급증할 수 있음

4.2 “중요 테이블 + 특정 Principal” 감사 예시

USE [ImportantDB];
GO

CREATE DATABASE AUDIT SPECIFICATION [AuditSpec_ImportantTables]
FOR SERVER AUDIT [Audit_UserMonitoring]

-- 예시: 개인정보 테이블 접근 감시(SELECT 포함)
ADD (SELECT, INSERT, UPDATE, DELETE
     ON dbo.Customer
     BY [public])

-- 예시: 급여 테이블은 더 좁게(특정 역할/사용자만)
ADD (SELECT, INSERT, UPDATE, DELETE
     ON dbo.Salary
     BY [db_datareader])

WITH (STATE = ON);
GO

설계 팁(실무)

• BY [public]는 “너무 넓게” 잡힐 수 있습니다.
  운영에서는 보통:
• 애플리케이션 계정/역할, DBA 역할, 외주 계정처럼 “추적 가치가 큰 주체” 중심으로 설정합니다.
• 민감 테이블은 가능하면 “읽기(SELECT)”도 포함하되,
• 조회량이 매우 많은 테이블이면 별도 정책(샘플링/특정 시간대/특정 계정)으로 조정합니다.

4.3 감사 동작 테스트(반드시 수행)

• 감사 대상 테이블에서 SELECT/INSERT/UPDATE/DELETE 실행
• SSMS → Security → Audits → 해당 Audit → View Audit Logs
• 로그가 안 보이면 다음부터 점검:
• Audit와 Specification의 STATE=ON
• 파일 경로 쓰기 권한(서비스 계정)
• 대상 DB/스키마/Principal 지정 오류

---

5) 로그 저장소 전략: “어디에 남기느냐”가 위·변조 방지와 운영 난이도를 결정한다

감사 로그는 보안 증거이기 때문에, 저장소 선택이 매우 중요합니다.

5.1 목적지 선택 가이드(요약)

저장 위치	장점	단점	추천 상황
파일(File)	구현 쉬움, 외부 전송/보관 용이	디스크/권한 관리 필요	온프레, 로그 서버 운영, SIEM 연동 전제
Windows Application Log	OS 수집 도구와 연동 쉬움	이벤트 로그 혼잡 가능	단일 서버/중간 규모
Windows Security Log	보안팀 운영 표준에 맞는 경우 많음	권한/정책이 민감, 용량 제한	SOC 중심 운영
Azure Storage / Log Analytics / Event Hub	장기보관/Immutable/SIEM 연동 강력	비용/권한/네트워크 고려	클라우드/하이브리드, 규제 강함

5.2 위·변조 방지(Tamper Resistance) 체크리스트

• 감사 로그는 가능하면 DB 서버와 다른 스토리지로 이관(또는 실시간 전송)
• 감사 로그 폴더 ACL 최소화(“읽기” 권한도 최소)
• 보안 요구가 강하면 WORM/Immutable Storage(변경 불가) 고려
• 감사 구성 자체 변경(AUDIT_CHANGE)을 별도 탐지 대상으로 포함(이미 3번에서 적용)

---

6) 롤오버·보존·아카이빙: “로그가 디스크를 채워서 서버를 망가뜨리지 않게” 운영하라

감사를 켜고 며칠 뒤 가장 흔한 사고는 “디스크 풀”입니다. 운영 안정성은 보존/아카이빙이 좌우합니다.

6.1 용량 설계(실무 기준)

• MAXSIZE / MAX_ROLLOVER_FILES로 무한 증가 방지
• 운영 모니터링에서:
• 감사 디렉터리 용량
• 디스크 Free Space(예: 20% 미만 경고)
• 로그 생성 속도(시간당/일당 파일 증가량)
  을 반드시 알림에 포함

6.2 아카이빙(장기 보관) 운영 패턴

• 일정 주기(일/주)로 .sqlaudit 파일을
• 별도 파일 서버, 오브젝트 스토리지, SIEM 저장소로 이동
• 장기 보관 시:
• 압축 + 저장소 암호화(at-rest)
• 접근 통제(RBAC)
• 무결성(해시/서명)까지 고려하면 좋음

“운영 디스크”는 짧게 유지하고, “장기 보관”은 별도 스토리지로 분리하는 것이 안정적입니다.

---

7) 조회·분석·알림: SSMS 확인에서 끝내지 말고 “자동 탐지”까지 연결하라

감사 로그를 남겨도 “안 보면” 의미가 없습니다. 운영에서는 쿼리 기반 분석 + 알림 + 정기 리뷰가 필수입니다.

7.1 SSMS Log File Viewer(단건 조사/초기 검증)

• SSMS → Security → Audits → View Audit Logs
• 필터링으로 시간/사용자/오브젝트 기준으로 확인
• 장점: 빠르고 직관적
• 한계: 대량 분석/자동화에는 부적합

7.2 sys.fn_get_audit_file 기반 “쿼리 분석”(운영 자동화 핵심)

SELECT
    event_time,
    server_principal_name,
    client_ip,
    application_name,
    database_name,
    schema_name,
    object_name,
    statement,
    action_id,
    succeeded
FROM sys.fn_get_audit_file(
       'D:\SQLAudit\Audit_UserMonitoring_*.sqlaudit',
       DEFAULT, DEFAULT
)
WHERE event_time >= DATEADD(DAY, -7, SYSDATETIME())
ORDER BY event_time DESC;

운영 확장 패턴

• 위 결과를 중간 테이블로 적재(ETL/ELT)하고
• Elasticsearch/Splunk/Sentinel 같은 SIEM/검색 시스템으로 보내서
• 대시보드
• 알림 룰
• 이상 징후 탐지
  로 사용합니다.

7.3 자주 쓰는 “탐지 룰” 예시(아이디어)

• 로그인 실패 급증: 특정 계정/특정 IP에서 실패가 연속 발생
• 야간/비정상 시간대 민감 테이블 접근: Salary/PII 테이블에 평소와 다른 시간대 접근
• 권한 상승 징후: server_role_member_change, permission change 이벤트 발생
• 감사 기능 변경 시도: audit change 이벤트 발생(매우 중요)

감사 로그의 가치는 “사후 조사”만이 아니라, 조기 탐지(Early Detection)에서 극대화됩니다.

---

온프레미스 MSSQL vs Azure SQL Audit: 하이브리드 관점 정리

• 온프레 SQL Server
• Server Audit + Specifications 구조
• 목적지: 파일/Windows 로그 중심
• SIEM 연동은 에이전트/수집 파이프가 필요
• Azure SQL / Managed Instance
• Storage/Log Analytics/Event Hub로 전송 중심
• Immutable, Azure Monitor/Policy와 결합해 규정 준수 운영에 유리
• 하이브리드는 “표준 이벤트 스키마”로 SIEM에 통합하는 설계가 중요

---

실무 체크리스트(요약)

• [ ] “무엇을/누가/어디에/얼마나” 정책을 먼저 확정했다
• [ ] 서버 베이스라인(로그인/권한변경/감사변경)을 먼저 켰다
• [ ] DB 감사는 민감 테이블/핵심 계정 중심으로 타겟팅했다
• [ ] 로그 목적지/권한/위·변조 방지(분리/Immutable)를 설계했다
• [ ] 롤오버/보존/아카이빙/알림으로 운영 안정성을 확보했다
• [ ] sys.fn_get_audit_file 기반 분석/자동 탐지를 구축했다
• [ ] 정기 리뷰 + 사고 대응 Runbook을 문서화했다

---

FAQ

Q1. SQL Server Audit를 켜면 성능에 큰 영향이 있나요?

대부분의 경우 “필요한 이벤트만 선택적으로” 감사하면 영향은 제한적입니다.
다만 고빈도 테이블의 모든 SELECT/DML을 광범위하게 감사하면 로그 I/O와 이벤트 처리 비용이 커질 수 있습니다. 운영에서는 범위를 좁게 시작 → 점진 확장이 안전합니다.

Q2. 애플리케이션 로그가 있는데 DB 감사 로그가 꼭 필요할까요?

앱 로그는 “기능 호출” 중심인 경우가 많고, DB Audit은 “DB 내부에서 실제 실행된 작업”을 포착합니다.
특히 권한 변경/직접 접속/SSMS 실행 같은 케이스는 앱 로그만으로 놓칠 수 있어, 둘을 함께 보는 것이 이상적입니다.

Q3. 어떤 이벤트부터 감사하는 게 현실적일까요?

대부분의 조직에서 아래 4가지를 “최소 세트”로 시작합니다.

• 로그인/실패 로그인
• 권한/역할 변경(권한 상승)
• 민감 테이블 접근(SELECT 포함)
• 감사 설정 변경(감사 끄기/수정)

Q4. 감사 로그는 얼마나 보관해야 하나요?

산업/국가/내부 규정에 따라 다릅니다. 우선 법/규정/계약서/내부 정책을 확인하고, 그 기간 이상 보관하도록 설계합니다.
운영 비용을 위해 “운영 디스크 단기 + 아카이브 장기”로 계층화하는 패턴이 흔합니다.

Q5. 감사 로그도 암호화해야 하나요?

감사 로그에는 계정/클라이언트 정보/실행문/객체명 등 민감한 정보가 포함됩니다.
저장소 암호화(at-rest)와 접근통제(RBAC), 백업/아카이브 암호화를 함께 고려하는 것이 안전합니다.

---

결론

MSSQL 사용자 감시 감사 로그는 “기능을 켜는 일”이 아니라 운영 체계를 만드는 일입니다.
7가지 원칙(정책 → 베이스라인 → 타겟 감사 → 저장소/위·변조 방지 → 보존/아카이빙 → 분석/알림 → 리뷰/개선)을 그대로 적용하면, 보안/규제/운영 장애 대응까지 함께 커버할 수 있습니다.

---