[8편] 누가 고객 정보를 조회했을까? — QueryPie 감사 로그로 DB 사용 이력 찾아보기

지난 7편에서는 고객의 전화번호와 이메일에 마스킹을 적용했다. 개발자는 가려진 연락처를 보고, 원문이 필요한 담당자에게만 예외를 주는 것까지 확인했다.

이번에는 그다음 상황을 생각해 봤다. 배송 문의를 처리한 뒤 “4002번 주문은 누가 조회했나요?”라는 확인 요청이 들어온다면, 관리자는 어디에서 무엇을 찾아보면 될까.

QueryPie ACP의 감사 로그에서 직접 찾아보기로 했다. 개발자는 DBeaver로 배송 대기 주문을 조회하고, 고객 담당자는 웹 SQL Editor로 특정 주문의 연락처를 확인했다. 서로 다른 도구로 수행한 작업이 관리자 화면에 어떻게 남는지 살펴봤다.

평소처럼 주문을 조회하는 것부터 시작했다

이번에도 기존 Orders Control Lab 연결과 실습용 주문 데이터를 사용했다. 고객명과 연락처는 모두 가상 데이터다. QueryPie ACP Community 11.6.7 환경에서 두 사용자 모두 조회 전용 권한으로 접속했다.

먼저 개발자 계정으로 DBeaver를 열었다. 주문번호와 상태를 조회하되, 조건은 status = 'PENDING'으로 지정했다. 결과에는 배송 대기 상태인 4001번과 4003번 주문이 나왔다.

고객 담당자 역할의 Demo Approver 계정은 QueryPie 웹 SQL Editor를 사용했다. 주문과 연락처 테이블을 JOIN하고, WHERE o.order_id = 4002 조건으로 한 건만 조회했다. 이 계정에는 7편에서 설정한 연락처 원문 확인 예외가 적용돼 있다.

개발자 계정에서도 같은 4002번 주문의 연락처를 한 번 더 조회했다. 개발자에게는 전화번호와 이메일이 가려져 보였다. 이렇게 배송 대기 목록 조회, 담당자의 연락처 조회, 개발자의 마스킹된 연락처 조회라는 세 가지 기록을 만들었다.

날짜와 DB 연결을 정해 기록을 찾았다

관리자 화면에서 Audit → Databases → Query Audit으로 이동했다. 당일 기록을 확인하고, Connection Name 필터에 Orders Control Lab을 지정했다.

목록에는 조금 전 작업들이 최신 기록으로 올라와 있었다. 실행 시각, 성공 여부, 사용자 이름과 이메일, 연결 이름, 사용한 권한을 함께 볼 수 있었다. 개발자와 담당자의 기록이 같은 목록에 모여 있으니 두 화면을 번갈아 확인할 필요가 없었다.

그다음 검색 기준을 Name으로 두고 Demo Developer를 입력했다. 개발자가 실행한 기록만 추려졌고, DBeaver에서 확인했던 실행 시각을 기준으로 배송 대기 주문 조회를 찾을 수 있었다.

DBeaver에서 실행한 SQL을 관리자 화면에서 확인했다

15시 48분 39초 기록을 열었다. 상세 화면에는 사용자가 Demo Developer, 결과는 Success, 권한은 Read-Only로 표시됐다. 실행 경로인 Executed From은 Agentless Proxy였다.

아래로 내려가니 실제 실행 SQL이 나왔다. orders_control.orders를 조회했고, WHERE status = 'PENDING' 조건도 그대로 확인할 수 있었다. SQL 앞에는 DBeaver가 붙인 ApplicationName 주석도 남아 있었다.

직접 확인해 보니, 접속한 사람을 아는 것에서 한 걸음 더 나아갈 수 있었다. 어느 테이블을 어떤 조건으로 조회했는지 실행 SQL을 보고 설명할 수 있었다. 개발자는 평소 쓰던 DBeaver에서 작업했고, 관리자는 QueryPie에서 그 기록을 찾았다.

4002번 주문을 확인한 담당자도 찾았다

이번에는 이름 검색을 Demo Approver로 바꿨다. 15시 48분 31초에 실행한 기록을 열자 담당자 이름과 Success 결과가 표시됐다. 실행 경로는 Web Editor였다.

상세 SQL에는 orders와 customer_contacts 테이블을 JOIN한 내용, 전화번호와 이메일을 선택한 컬럼 목록, 그리고 WHERE o.order_id = 4002 조건이 남아 있었다. 찾으려던 주문을 조회한 기록이라는 것을 SQL로 확인할 수 있었다.

여기서 눈에 들어온 부분은 사용자 구분이었다. 두 연결의 DB User는 같은 control_writer였지만, QueryPie의 사용자 이름은 Demo Developer와 Demo Approver로 각각 남았다. DB 접속 계정만 보는 것보다 실제 작업자를 파악하기 쉬웠다.

이제 처음의 확인 요청에도 구체적으로 답할 수 있었다. 담당자는 웹 편집기로 4002번 주문의 연락처를 조회했고, 개발자는 DBeaver에서 배송 대기 목록을 조회한 뒤 같은 주문의 연락처도 조회했다. 각 작업의 실행 시각과 SQL을 기록에서 확인했다.

개인정보가 가려졌는지는 마스킹 로그로 확인했다

조회 SQL을 찾았으니, 개발자의 연락처 조회에 마스킹이 적용됐는지도 확인해 봤다. Databases → Policies → Data Masking에서 기존 연락처 정책의 Logs 탭을 열었다.

15시 49분 1초에 실행한 개발자 조회가 Data Masked로 기록돼 있었다. phone과 email 컬럼에 각각 1행이 표시됐다. 앞서 DBeaver에서 확인한 마스킹 결과와 같은 시간대의 기록이었다.

Query Audit에서는 누가 어떤 SQL을 실행했는지 살펴보고, 마스킹 로그에서는 해당 컬럼에 보호 정책이 적용됐는지 확인했다. 두 기록을 사용자와 실행 시각으로 맞춰보니, 실제 조회 업무와 개인정보 보호 결과를 함께 설명하기 좋았다.

도입 후 운영 업무까지 생각하게 됐다

접근제어 제품을 검토할 때는 차단이나 승인 기능부터 보기 쉽다. 직접 사용해 보니, 정상적으로 진행된 업무를 나중에 찾아볼 수 있는 기능도 운영 담당자에게 도움이 크겠다는 생각이 들었다.

이번에는 별도의 작업 보고서를 받아서 맞춰보지 않았다. QueryPie에서 날짜와 DB 연결을 정하고, 사용자 이름으로 검색한 뒤 실제 SQL을 확인했다. DBeaver와 웹 SQL Editor에서 수행한 작업을 같은 감사 화면에서 살펴볼 수 있었다.

필요한 사람에게 DB 사용을 허용하고, 사용한 뒤에는 기록을 근거로 작업 내용을 설명할 수 있다는 점. 이번 실습에서는 그 장점이 분명하게 보였다. 앞서 설정한 권한과 마스킹 정책이 감사 기록과 함께 남으니, 도입 이후 운영하는 모습도 한결 구체적으로 그려졌다.