AUDIT — 누가 했는가
WAS 인증이 끝나면 실사용자와 WAS 세션 식별자가 DB 세션에 바인딩됩니다. 감사 기록은 그 컨텍스트, SQL, 오브젝트, 칼럼을 한 이벤트에 남깁니다. 모든 SQL을 정규식으로 걷어 가는 방식이 아니라, 사전에 지정한 대상만 봅니다.
01 · 감사 · 접근제어
실사용자를 남기고, 권한은 지금만 엽니다
커넥션 풀 뒤의 공통 계정이 누구인지 감사 로그에 묶고, 객체, 시스템 관한 사용 요청후 최소 작업이 승인된 시간 동안만 Dynamic Role을 세션에 올립니다.
로그를 많이 모으는 것과 로그를 연결하는 것은 다른 문제입니다.
왜 보안 투자에도 유출이 반복되는가
- 01
Connection Pool 뒤 실사용자 소실
WAS에서 인증된 실사용자는 커넥션 풀을 지나며 소실되고, DB에는 APP_USER 공통 계정만 남습니다. 로그를 아무리 많이 모아도 실사용자를 직접 입증하지 못하고 수동 대조와 추정만 반복합니다.
- 02
권한의 상시 활성화 (Always ON)
기존 최소권한 정책은 테이블·컬럼 등 범위만 쪼갤 뿐 활성화 시간·시점은 방치합니다. 업무용 권한과 고권한 계정이 야간·주말에도 상시 열려 있어 내부자 위협과 계정 탈취에 무방비로 노출됩니다.
- 03
네트워크 암호화와 통제·감사의 단절
TLS나 Native Network Encryption으로 전송 구간이 암호화되면 네트워크 패킷 스니핑 방식의 접근제어는 무력화됩니다. 또한 사전 통제(Gate)와 사후 증적(Audit)이 분리되어 일체화된 대응이 어렵습니다.
- 04
교체가 아닌 공존의 보완 연계 레이어
기존 9개 DB 보안 투자를 폐기하지 않습니다. AUDIGATE는 그 위에 얹어져 경량 에이전트로 실사용자 식별자를 바인딩하고, 1회용 AUTH-KEY로 승인된 시간에만 Dynamic Role을 올리는 차세대 레이어입니다.
감사와 권한
GATE — 지금 열어도 되는가
업무 때문에 준 SELECT·UPDATE가 야간과 주말에도 열려 있지 않게 합니다. 승인된 세션만 Dynamic Role을 갖고, 범위 밖 SQL은 데이터베이스가 거부합니다. 기존 접근통제, 계정관리, 감사, SIEM을 교체하지 않고 그 옆에 붙습니다.
권한이 켜지고 꺼지는 순서
- 01 요청 필요한 권한, 대상 객체, 작업 시간을 적습니다.
- 02 승인 승인권자가 요청을 검토합니다.
- 03 AUTH-KEY 작업 세션마다 임시 인증 키를 발급합니다. 키는 다른 세션에서 절대 탈취할 수 없으며, 유효 기간이 있습니다.
- 04 활성화 세션에서 apply_my_roles를 실행하면 그 세션에만 Dynamic Role이 켜집니다. 승인 이후의 SQL 행위는 모두 상세히 추적 기록합니다.
- 05 회수 작업 시간이 끝나거나 세션이 닫히면 Role과 권한을 거둡니다.
접속과 전달
PLATE 04
기존 SQL 도구, 단일 이벤트
접속 클라이언트는 별도 프로그램을 요구하지 않습니다. DBeaver, SQL Developer, PL/SQL Developer로 게이트에 붙습니다. TLS나 Native Network Encryption으로 패킷이 안 보여도, 승인된 Role과 세션 트레이스로 실행 SQL을 남깁니다. 실사용자, WAS/DB 세션, SQL은 한 이벤트로 Syslog 또는 표준 API를 통해 SIEM에 넘길 수 있습니다.