보안 투자의 역설: 9개 솔루션과 채워지지 않는 공백

기업은 정보 보안을 위해 막대한 비용과 인력을 투입합니다. 데이터베이스 환경만 보더라도 일반적으로 9개에 달하는 보안 솔루션을 겹겹이 도입해 운용하고 있습니다.

DB 접근통제: 허가된 IP와 계정의 접속 허용·차단
계정관리 (IAM): 계정 생성, 라이프사이클 관리, 정적 권한 할당
SQL 감사: 실행된 쿼리 이력과 결과 수집
개인정보 접근통제: 주민번호·계좌 등 개인정보 테이블/컬럼 접근 통제
DB 모니터링: 실시간 세션 및 부하 행위 감시
로그관리: 감사 로그의 장기 보관 및 검색
SIEM: 이종 보안 장비 이벤트의 통합 상관 분석
서버 접근통제: 관리자·운영자의 OS 레벨 접속 제어
내부통제: 결재 승인 절차 및 직무 분리(SoD)

그럼에도 불구하고 대규모 개인정보 유출과 내부자 보안 사고는 끊임없이 되풀이됩니다. 사고가 발생한 후 포렌식 조사를 시작하면, 수많은 보안 장비가 쌓아둔 테라바이트 단위의 로그 속에서 정작 누가 실제로 데이터를 빼돌렸는가를 명확히 밝히지 못해 수주 동안 수작업 로그 대조를 반복하다 '추정'으로 결론을 내리곤 합니다.

근본 원인은 개별 솔루션의 성능 부족이 아닙니다. 현행 DB 보안 아키텍처가 지닌 3가지 구조적 단절 때문입니다.

1. Connection Pool 뒤에서 실사용자가 사라집니다 (식별 단절)

현대 엔터프라이즈 환경에서 모든 웹·모바일 서비스는 웹 애플리케이션 서버(WAS)의 커넥션 풀(Connection Pool)을 통해 데이터베이스에 접속합니다.

WAS 레이어 (웹/앱): 실사용자(홍길동), 세션 ID, 접근 URL, 출발지 IP를 알고 있습니다.
DB 레이어 (데이터베이스): 커넥션 풀을 통과하는 순간 실사용자 정보는 사라지고, 사전에 설정된 공통 애플리케이션 계정(APP_USER)과 WAS 서버의 내부 IP만 보입니다.

DB 입장에서는 수천 명의 직원이 조작하는 모든 SELECT·UPDATE 쿼리가 단 하나의 APP_USER가 실행한 것으로 기록됩니다.

사고가 터지면 다음과 같은 수작업 역추적이 시작됩니다:

DB 감사 로그에서 유출 쿼리와 타임스탬프 확인
해당 시각 전후의 WAS 로그 타임스탬프 대조
WAS 세션 ID 검색 및 웹 접속 URL 경로 추적
당시 해당 화면을 열람 중이던 사용자를 "추정"

초 단위로 수많은 트랜잭션이 오가는 시스템에서 타임스탬프 기반 대조는 오차가 발생할 수밖에 없으며, 법적 효력을 갖는 증적으로서의 한계를 드러냅니다. 로그를 많이 모으는 것과 로그를 연결하는 것은 완전히 다른 문제입니다.

2. 권한은 필요하지 않은 시간에도 열려 있습니다 (시간 방치)

"오늘 필요하지 않은 DB 권한을 왜 오늘도 계속 가지고 있어야 합니까?"

현행 접근통제와 최소권한(Least Privilege) 모델은 권한의 범위(대상 테이블이나 컬럼)⁠만 쪼갤 뿐, 그 권한이 활성화되는 시간과 시점은 방치합니다.

상시 활성(Always ON)의 위험: 개발자나 운영자가 유지보수나 데이터 검증을 위해 승인받은 SELECT·UPDATE 권한은 작업이 끝난 야간, 주말, 공휴일에도 계정에 그대로 남아 있습니다.
내부자 위협과 계정 탈취: 퇴사 예정자, 불만 직원에 의한 정보 유출이나 피싱 등으로 탈취된 크리덴셜은 시스템 관리자가 자리를 비운 새벽이나 주말에 활성화된 상시 권한을 악용해 대량 데이터를 탈취합니다.
고권한 계정 오남용: DBA, SYSTEM, 배치 작업 계정이 탈취될 경우, 24시간 내내 풀 권한이 열려 있어 방어할 수단이 없습니다.

계정을 만들고 역할을 묶어두는 계정 관리(Account Management)⁠만으로는 부족합니다. 실제 작업이 승인된 골든타임에만 권한을 켜고 끄는 권한 사용 통제(Privilege Usage Control)⁠가 필수적입니다.

3. 네트워크 암호화와 통제·감사의 분리

보안 강화 추세에 따라 DB 접속 구간은 TLS나 Native Network Encryption(NNE)으로 강력하게 암호화되고 있습니다. 하지만 이는 역설적으로 네트워크 패킷을 감청(Sniffing)하여 감시하던 기존 DB 접근제어 솔루션을 무력화시킵니다. 패킷 내부를 볼 수 없기 때문입니다.

더 나아가, 현행 체계는 사전 접근통제(Gate)⁠와 사후 감사(Audit)⁠가 서로 다른 제품으로 분리되어 있습니다:

접근통제 솔루션: "누가 로그인할 수 있는가(Who can access)"만 보고 문을 열어줍니다.
감사 솔루션: 문 안에서 무슨 일이 일어났는지만 뒤늦게 기록합니다.

누가 승인을 받아 권한을 열었는지와 실제로 어떤 SQL이 실행되었는지가 단일 맥락으로 연결되지 않아, 사후 감사 로그에는 '권한 승인 여부'가 결합되지 못합니다.

AUDIGATE의 해법: 패러다임의 전환

AUDIGATE는 기존 9개 보안 투자를 폐기하거나 교체하지 않습니다. 기존 보안 인프라 위에 얹어져 증거를 연결하고 시간 차원의 통제를 부여하는 보완 연계 레이어입니다.

AUDIT — 누가 했는가 (Real User Attribution)

경량 WAS Agent를 통해 사용자 인증 컨텍스트를 DB 세션 메모리에 직접 바인딩합니다. 지정된 중요 테이블과 컬럼에 쿼리가 실행되는 순간, 실사용자 식별자 + WAS 세션 ID + DB 세션 + 실행 SQL + 대상 컬럼이 하나의 무결한 감사 이벤트로 묶여 기록됩니다. 사고 발생 시 수일이 걸리던 대조 작업이 1초 만에 종결됩니다.

GATE — 지금 열어도 되는가 (Just-In-Time Dynamic Role)

상시 권한(Always ON)을 폐지하고, 작업 건별 1회용 승인키(AUTH-KEY) 기반의 JIT(Just-In-Time) Dynamic Role 모델을 적용합니다. 승인권자가 승인한 작업 시간 동안에만 세션 레벨에서 권한이 동적으로 활성화되고, 시간이 만료되거나 세션이 종료되면 권한은 데이터베이스 레벨에서 즉시 소멸합니다.

종단간 일체화 (Prevent + Prove)

사전 통제: 승인된 시간, 승인된 Role의 작업만 데이터베이스가 허용
사후 증적: TLS/NNE 암호화 환경에서도 세션 트레이스를 통해 실사용자가 귀속된 완벽한 증적 보존

보안 투자가 진정한 보안으로 이어지려면, "계정과 IP"를 감시하는 수준을 넘어 실사용자를 추적하고, 권한의 시간을 닫는 것에서 출발해야 합니다.