데이터베이스 활동 모니터링: 무엇을 관찰하고 어떻게 수행할지

데이터베이스에는 규제 기관, 공격자 및 감사인이 가장 중요하게 여기는 고객, 결제 및 건강 기록이 저장되어 있습니다. SQL Server, Oracle, MySQL 및 PostgreSQL의 기본 감사 기능은 객체 및 권한 변경 사항을 캡처하지만 민감한 행을 누가 읽었는지에 대한 가시성은 거의 제공하지 않습니다.

Netwrix 2026 데이터 및 Identity 보안 보고서에 따르면 민감한 데이터 노출의 75%가 손상된 ID 또는 잘못 구성된 권한에서 시작됩니다. 기본 감사는 이러한 ID가 가장 큰 권한을 가진 곳, 즉 감사 기록을 직접 편집할 수 있는 privileged accounts에 대한 가시성이 가장 낮습니다.

데이터베이스 활동 모니터링은 접근, 변경 및 관리 작업에 대한 독립적인 기록을 생성하여 보안 팀이 사고를 조사하고, 준수를 입증하며, 손상된 계정이나 조용한 구성 변경이 보고 대상 위반으로 이어지기 전에 오용을 감지할 수 있도록 합니다.

데이터베이스 활동 모니터링이란 무엇인가요?

데이터베이스 활동 모니터링(DAM)은 데이터베이스 엔진과 독립적으로 데이터베이스 내 사용자 및 관리자 활동을 캡처, 저장 및 분석하는 보안 분야입니다. 필요 시 누가 접속했는지, 무엇을 읽거나 변경했는지, 감사 구성을 변경했는지 여부를 알려줍니다.

DAM은 성능 모니터링과 함께 사용되지만 다른 목적을 가집니다. 성능 도구는 CPU, I/O, 쿼리 지연 시간을 추적하여 엔진을 건강하게 유지합니다. 반면 DAM은 SQL 문, 사용자 신원, 클라이언트 IP 주소 및 타임스탬프를 캡처하여 활동을 특정 사용자나 서비스와 연결할 수 있게 합니다.

DAM 도구는 network tap, 호스트 에이전트 또는 데이터베이스 자체 감사 기능을 통해 해당 정보를 수집한 후, 기록이 손상된 관리자 계정을 견딜 수 있도록 데이터베이스 외부의 저장소로 전달합니다.

데이터베이스 활동 모니터링이 중요한 이유

데이터베이스 관리자(DBA)나 보안 분석가에게 사건이나 감사에서 가장 어려운 부분은 누가 무엇을 건드렸는지 입증하는 것입니다. 독립적인 데이터베이스 추적이 없으면 팀은 부분 로그에서 수작업으로 증거를 재구성하며, 보통 기한 내에 수행합니다.

민감한 데이터는 데이터베이스 계층에 집중됩니다

고객 기록, 카드 소지자 데이터 및 protected health information (PHI)는 데이터베이스 테이블에 저장됩니다. 모든 규제 데이터는 어느 시점에서 데이터베이스를 통과합니다. 데이터베이스 접근이 모니터링되지 않으면 환경에서 가장 민감한 자산이 가장 가까운 책임 계층을 잃게 되고, 모든 하위 제어는 기록되지 않은 흔적에 의존하게 됩니다.

네이티브 데이터베이스 로그는 조사를 지원할 수 없습니다

SQL Server의 기본 추적은 객체 및 권한 변경 사항은 캡처하지만 SELECT 활동은 캡처하지 않으며, 100MB의 기록만 보관합니다. 더 나쁜 것은, Microsoft는 경고합니다 sysadminsExpand가 감사 추적 자체를 조작할 수 있으므로, NIST SP 800-53 AU-9(2)는 감사 기록을 감사 대상 시스템과 분리된 시스템에 저장할 것을 요구합니다.

컴플라이언스 프레임워크는 데이터베이스 감사 추적을 요구합니다

모든 주요 프레임워크는 데이터베이스 활동을 증거로 취급합니다. PCI DSS v4.0.1 요구사항 10은 카드 소지자 데이터 접근 및 감사 로그 무결성에 대해 12개월간 기록을 의무화합니다. HIPAA의 45 CFR 164.312(b) 는 ePHI 시스템에서 활동을 기록하고 검사하는 메커니즘을 요구합니다.

Ernst & Young Incorporated에 대한 2023년 검사 보고서에서 (PCAOB 발표 번호 104-2024-113), PCAOB는 SOX에 따른 재무 보고 내부 통제 감사에서 고객의 통제 소유자가 회계 시스템 뒤 데이터베이스에 대한 직접 변경 사항을 어떻게 검토했는지 평가하지 않은 점을 지적했습니다.

GDPR 제5조 2항은(는) 관리자가 규정의 원칙 준수를 입증하도록 요구하며, 여기에는 누가 개인 데이터에 접근했는지 보여주는 것이 포함됩니다.

손상된 계정과 내부자의 오용은 데이터베이스에서 먼저 나타납니다

유효한 로그인은 수행한 작업을 기록하는 시스템을 제외한 모든 시스템에 합법적으로 보입니다. 이 때문에 자격 증명 도용과 내부자 오용은 거의 경계 제어를 작동시키지 않습니다. Verizon의 2026 Data Breach Investigations Report에 따르면 자격 증명 남용은 공격 체인 어느 시점에서 39%의 침해 사례에 나타났으며, 지속적인 데이터베이스 모니터링이 종종 그 다음에 발생하는 측면 이동을 가장 먼저 포착하는 장소입니다.

모니터링해야 하는 데이터베이스 활동

아래 범주는 자체 탐지 규칙을 정당화할 만큼 충분한 보안 또는 준수 중요도를 지닙니다. 이들은 함께 누가 접근했는지, 무엇을 읽거나 변경했는지, 기록을 조작했는지 여부를 다룹니다. 이는 모든 조사에서 시작되는 질문들입니다.

인증 및 연결 이벤트

로그온 기록은 도난당한 자격 증명이 처음으로 드러나는 장소입니다. 로그인 실패는 비밀번호 추측 또는 credential stuffing을 나타내며, 비정상적인 출처에서의 성공적인 로그인은 자격 증명이 사용되어서는 안 되는 곳에서 사용되고 있음을 보여줍니다.

특권 및 서비스 계정 로그온은 특히 주의가 필요합니다. 서비스 계정이 평소 애플리케이션 계층 대신 새 워크스테이션에서 갑자기 연결되는 경우 거의 항상 조사할 가치가 있습니다. Oracle은 새 데이터베이스에서 기본적으로 predefined failed-logon policy를 활성화하지만, 업그레이드된 데이터베이스는 수동으로 켜야 하는 경우가 많습니다.

민감 데이터 읽기 및 대량 내보내기

규제된 테이블을 조회한 사용자를 직접 확인하면 노출 사실을 아는 것과 무엇이 유출되었는지를 증명하는 것이 구분됩니다. 사용자가 한 번도 접근하지 않은 테이블에 처음 접근하거나 bcpExpand 또는 expdpExpand와 같은 도구를 통한 대량 추출은 가장 주목해야 할 읽기 패턴이며, 이는 엔드포인트에서 data loss prevention 제어가 감시하는 동일한 행동입니다.

스키마 및 구성 변경

스키마 및 구성 변경은 데이터를 파괴하거나 나머지를 모두 감지하도록 설계된 모니터링을 무력화할 수 있습니다. CREATE, ALTER, Expand및 DROPExpand 문장은 테이블 및 저장 프로시저에 대해 별도의 경고가 필요하며, 감사 구성 변경은 가장 빠른 대응이 필요합니다. Microsoft는 xp_cmdshellExpand 을 SQL Server에서 기본적으로 비활성화하여 활성화 시 공격자에게 명령 셸을 제공합니다.

새로운 또는 상승된 권한

단일 권한 부여는 제한된 계정을 모든 것을 읽거나 감사 추적을 완전히 비활성화하는 계정으로 바꿀 수 있습니다. 역할 구성원 변경, 새로운 로그인, SQL Server의 sysadmin 역할 또는 Oracle의 동등한 DBA 역할에 대한 추가는 협상 불가능한 경고이며, 동일한 privilege escalation 패턴이 ID 계층에서 감시됩니다. 최소 권한이 기본 제어입니다. Oracle의 ORA_ACCOUNT_MGMT 정책이 이를 다루지만 기본적으로 비활성화되어 있습니다.

민감한 테이블에 대한 데이터 변경

급여나 계좌 잔액이 무단으로 변경될 때, 첫 번째 질문은 변경 전 값이 무엇이었는지입니다. 기본 감사 기록은 명령문 텍스트만 기록하고 행 값은 기록하지 않으므로 SQL Server의 Change Data Capture, MySQL의 행 이미지 이진 로깅 또는 PostgreSQL triggers와 같은 별도의 메커니즘이 변경 전후 내용을 보존해야 합니다. 규제된 테이블에 대한 대량 또는 근무 시간 외 변경에 대한 경고는 MITRE T1565, Data Manipulation에 매핑됩니다.

정상 패턴을 깨는 활동

기본 규칙은 개별적으로는 평범해 보이지만 해당 계정에서는 이례적인 활동을 포착합니다. 예를 들어 사용자가 5분 내에 갑자기 10개의 테이블을 조회하거나, 알려진 애플리케이션 계정이 새로운 IP 주소에서 연결하는 경우입니다.

이것은 기본 감사 구성이 아닌 SIEM 분석에 의존하는 유일한 범주이며, 계정 계층에서 identity threat detection이 사용하는 동일한 행동 기준 접근 방식입니다.

데이터베이스 활동 모니터링 구현 방법

각 단계는 이전 단계에 의존하므로 다섯 단계를 순서대로 진행하세요. 1단계에서 범위를 정하면 2단계에서 적합한 수집 방법이 결정됩니다.

또한 모든 이벤트를 수동으로 검토할 수 없는 소규모 팀을 가정하므로, 아래 여러 단계는 수동 분류 대신 단계적 배포와 자동 기준선을 사용합니다.

1. 모니터링할 범위를 정의합니다

급여, 카드 소지자, 건강 또는 지적 재산과 같은 규제 대상 또는 비즈니스 민감 데이터를 보유한 데이터베이스를 인벤토리로 작성하고 규제 동인별로 순위를 매기는 것부터 시작하세요. 민감한 필드를 포함하는 테이블을 알아야만 해당 인벤토리가 의미가 있으므로 먼저 data classification을 실행하세요. 이를 건너뛰면 급여 감사 명세서에 참고할 내용이 없습니다.

위험은 현실적입니다: Netwrix 2026 Data and Identity Security Report의 설문조사에 따르면 57%의 조직이 민감한 데이터 목록을 지속적으로 유지하지 않아 대부분의 팀이 이 단계를 맹목적으로 시작합니다.

민감한 데이터베이스를 매핑한 후, 해당 데이터베이스에 접근하는 privileged, 공유 및 서비스 계정에도 동일한 인벤토리를 확장하고, 일반 사용자 로그가 선택적으로 유지되는 경우에도 모든 privileged 세션을 완전히 모니터링하는 데 전념하세요.

CIS Safeguard 8.5 는 그 약속의 최소 기준을 설정합니다. 최소한, 민감한 데이터를 보유한 모든 자산에 대해 사용자 이름, 타임스탬프, 출발지 및 목적지 주소를 캡처하세요.

2. 환경에 맞는 수집 방법을 선택하세요

서버에 부하를 전혀 주지 않아야 할 경우 SPAN 포트를 통한 수동 네트워크 캡처가 시작점입니다. 그러나 부하가 전혀 없는 이 절충안은 forward-secret Transport Layer Security (TLS), 로컬 연결 및 클라우드 관리 데이터베이스에 대한 가시성을 잃게 만듭니다.

명령문 차단이 보는 것보다 더 중요할 때, 인라인 프록시가 더 적합합니다. 인라인 프록시는 TLS를 직접 종료하지만, 이 제어는 지연을 추가하고 프록시를 가용성 의존성으로 만듭니다.

그 이후에도 로컬 연결에 대한 커버리지가 필요하고 팀이 CPU 비용과 커널 또는 데이터베이스 업그레이드 시마다 발생하는 재검증 작업을 감당할 수 있다면, 호스트 에이전트가 그 격차를 메웁니다. 데이터베이스를 서비스(DBaaS)로 운영하거나 저장 프로시저 및 암호화에 대한 가시성이 필요한 팀은 네이티브 감사와 에이전트 없는 수집을 결합하여 이를 달성합니다.

Oracle는 네이티브 감사를 위한 중간 단일 자리 CPU 오버헤드를 보고합니다 시간당 최대 360,000개의 감사 기록에서. 에이전트 없는 수집은 추가 부하를 더하므로, 도입 전에 조합을 테스트하세요.

실제로 대부분의 팀은 Oracle의 AVDF 문서가 네트워크 모니터링과 데이터베이스 감사를 함께 사용하여 서로의 사각지대를 보완할 것을 권장하기 때문에 방법을 결합합니다.

3. 소규모 팀이 대응할 수 있는 정책과 경고 임계값을 설정하세요

규칙을 한꺼번에 모두 켜지 말고 단계별로 켜세요. 첫날 모든 것을 활성화하면 소규모 팀이 오탐에 시달리게 됩니다. 위의 여섯 가지 활동 범주에서 매핑된 감사 변조와 sysadmin 권한 부여부터 단계적 배포를 시작하세요. 이 두 가지는 놓친 경고에 대한 허용도가 가장 낮기 때문입니다.

NIST SP 800-94은 새로 배포된 시스템이 환경에 완전히 맞춰지기 전까지 과도한 오탐을 발생시키는 경향이 있다고 경고하며, 이것이 단계적 접근 방식이 중요한 이유입니다.

볼륨 및 액세스 패턴 규칙은 다른 처리가 필요합니다. 최소 일주일의 기준 데이터에 맞춰 조정된 이상치로 실행하세요. 이는 Microsoft Sentinel이 자체 영향 받은 행 이상치 규칙에 사용하는 14일 훈련 기간과 동일한 규모입니다.

이 임계값은 보편적인 숫자를 따르기보다 환경에 국한될 것으로 예상하세요. 한 팀의 이상치는 100행인 반면, 다른 팀은 500,000행이며, 오직 자신의 기준선만이 어느 것이 어느 것인지 알려줍니다.

4. 데이터베이스 이벤트를 중앙 집중화하고 이를 identity 컨텍스트와 연관시키세요

먼저 로그 수집을 중앙 집중화하세요, CIS Safeguard 8.9에서 요구하는 대로, 그리고 NIST SP 800-61 Rev. 3에서 권장하는 대로 사람이 검토할 수 있는 범위로 대규모 이벤트 데이터를 필터링하는 도구를 사용하세요. 이 파이프라인이 구축되면 각 이벤트를 해당 계정과 연관시키세요. 신원 컨텍스트가 없는 중앙 집중식 로그는 여전히 이름 대신 원시 SQL 문을 읽게 만듭니다.

Microsoft Sentinel에서는 해당 상관관계가 특정 테이블을 통해 이루어집니다. Azure SQL 감사 이벤트를 SQLSecurityAuditEventsExpand 테이블(또는 이전 설정에서는 AzureDiagnosticsExpand)으로 라우팅하고, SQL Server Windows 이벤트는 SecurityEventExpand로, Defender 경고는 SecurityAlert;Expand 그런 다음 IdentityInfoExpand 테이블을 사용하여 각 계정 뒤의 사용자를 연결합니다.

Splunk 및 IBM QRadar 사용자는 자체 ID 조회를 사용하여 동일한 패턴을 따를 수 있습니다. 그 결과는 "누군가가 대규모 SELECT를 실행했다"는 것을 "두 시간 전에 sysadmin에 추가된 계약자 계정이 대규모 SELECT를 실행했다"로 바꾸는 것입니다.

5. 모니터링 파이프라인을 테스트, 조정 및 유지 관리하세요

운영 환경에서 신뢰하기 전에 대표 활동으로 전체 파이프라인을 테스트하세요. 서버 역할에 테스트 로그인을 추가하고, 감사 사양을 변경하며, 600행 내보내기를 실행한 후 각 경고가 올바른 신원과 함께 도착하는지 확인하세요. 이벤트를 기록하지만 신원 컨텍스트를 잃는 파이프라인은 절반만 완성된 것입니다.

애플리케이션이 변경될 때마다 기준선을 재구축하고, Oracle's AVDF documentation에서는 DBA가 이를 수정하거나 삭제할 수 있다고 경고합니다. 설정을 정기적으로 확인하고 검토하세요; CIS Safeguard 8.1에서는 최소 연 1회 검토를 권장합니다.

보존은 동일한 규율이 필요합니다. PCI DSS의 12개월 기준을 바탕으로 적용 가능한 가장 엄격한 규정을 설정하고, Azure SQL 파이프라인에 데이터를 제공하는 진단 설정도 모니터링 목록에 유지하세요. 삭제하면 수집이 조용히 중단될 수 있습니다.

Netwrix가 데이터베이스 활동을 모니터링하는 방법

위 작업의 대부분은 범위 정의부터 아이덴티티 컨텍스트 상관관계까지 사용 도구와 관계없이 적용됩니다. Netwrix Auditor는 SQL Server 및 Oracle에 대한 수집, 경고, 전후 세부 정보를 다루며, Netwrix Access Analyzer는 권한 및 민감 데이터 계층을 추가합니다.

로그온 및 특권 액세스 추적

Netwrix Auditor의 SQL Server monitoring는 성공 및 실패한 로그인 기록을 남기고 DBA 활동을 추적하며, 권한 있는 작업 및 서버 역할 변경을 포함합니다. 그 Oracle Database monitoring 소프트웨어는 성공 및 실패한 로그인 기록을 추적하고 SQL 문 및 권한을 모니터링합니다. 두 소스 모두에 대해 분석가에게 이메일을 보내거나 사용자가 정의한 스크립트를 실행하는 응답 작업을 구성할 수 있습니다.

Auditor 보고서는 규정 준수 증거로도 사용됩니다. First National Bank and Trust of Beloit는 OCC 준수를 위해 Netwrix Auditor를 주요 솔루션으로 사용하며, 이제 감사 준비에 일주일 대신 한 시간만 소요합니다. Bank of the South는 비즈니스에 중요한 데이터를 보호하고 PCI DSS 및 GLBA를 준수하기 위해 이를 사용하며, 연간 최소 40시간의 감사 준비 시간을 절약합니다.

데이터 변경 전후 값 캡처

Netwrix Auditor for SQL Server는 기본적으로 트리거 없는 모드로 작동하며, 추가 부하 없이 5분마다 추적 로그를 읽고 누가 언제 무엇을 변경했는지 보고합니다. 트리거 기반 모드는 INSERT, UPDATE, DELETE에 대해 이전 및 이후 값을 추가하는데, 이는 기본 감사에서는 제공할 수 없으며, 거래량이 많은 서버에서는 추가 부하가 발생합니다.

활동을 민감한 데이터에 연결하기

Netwrix Auditor는 트리거 없는 모드에서 구성한 테이블과 정책을 사용하여 테이블 수준에서 민감한 데이터 컨텍스트를 적용하므로, 보고서가 규제 대상 테이블에 대한 활동을 표시할 수 있습니다. SQL Server 및 Oracle 전반에 걸친 더 깊은 탐색 및 권한 분석을 위해, Netwrix Access Analyzer는 효과적인 권한을 매핑하고 Auditor 단독으로 커버하는 범위를 넘어 과도하게 노출된 데이터를 표시합니다.

최소한의 운영 영향으로 배포

Netwrix Auditor는 원격으로 수집하므로 트리거 기반 모드만 모니터링되는 테이블에 접근합니다. Oracle 수집은 Auditor 서버의 Oracle Instant Client를 통해 10분마다 실행되며, SQL Server 추적 읽기는 5분마다 실행됩니다. 애드온은 이미 SIEM에 집중하는 팀을 위해 활동 기록을 Splunk, IBM QRadar 및 ArcSight로 전달합니다.

데이터베이스 활동 모니터링을 실천하세요

가장 엄격하게 규제되는 데이터를 보유한 인스턴스부터 시작하여 기준선을 설정하고 첫 번째 경고 세트가 실행 가능한 결과를 생성한 후에만 확장하세요.

클라우드 관리 워크로드의 경우, 적용 범위는 데이터 소스와 배포 모델에 따라 다릅니다. Netwrix Access Analyzer는 민감한 데이터를 발견하고 SQL Server, Azure SQL, Amazon RDS for SQL Server 및 Oracle에 대한 권한을 분석합니다.

데모 요청하여 Netwrix가 데이터베이스 활동을 모니터링하고, 감사 추적을 중앙 집중화하며, 침해가 발생하기 전에 오용을 감지하는 방법을 확인하세요.