[18편] 임시 권한에도 끝나는 시간이 필요했다 — QueryPie 정책 예외 관리

“정산 금액만 잠깐 확인하고 싶습니다.”

이런 요청을 받아 권한을 열어 줬다면, 그다음에는 언제까지 허용할지도 챙겨야 한다. 업무는 끝났는데 예외 권한은 계속 남아 있는 상황을 피하고 싶어서다.

13편에서는 QueryPie로 정산 테이블 접근을 요청하고 승인받았다. 이번에는 그때 정해 둔 시간이 지난 뒤 화면과 조회 결과가 어떻게 달라졌는지 확인해 봤다. 승인한 예외를 한곳에서 관리할 수 있다는 점이 특히 편했다.

1시간만 열어 둔 정산 테이블

앞서 개발자 계정인 Demo Developer는 평소 주문 테이블을 조회할 수 있었지만, 정산 정보가 들어 있는 settlement_details에는 접근할 수 없었다. 주문 4002의 정산 금액을 대조하기 위해 이 테이블에 대한 접근을 별도로 요청했다.

요청에는 대상 테이블과 업무 사유뿐 아니라 시작 시각과 이용 시간도 함께 적었다. 이번 실습에서 정한 일정은 2026년 11월 8일 오후 5시부터 1시간이었다.

관리자가 나중에 기억해서 정리할 항목을 처음 요청할 때부터 명확하게 정할 수 있었다. 승인받은 업무와 허용 기간을 함께 남긴다는 점에서 단순히 접근을 열어 주는 것보다 관리하기 좋았다.

시간이 지난 예외는 Expired로 구분됐다

관리자 화면에서 Databases → Policies → Policy Exception을 열었다. 이전에 승인했던 정산 테이블 접근과 전화번호 마스킹 해제 내역이 한 목록에 나왔다.

정산 테이블 예외에는 종료 시각이 오후 6시로 표시돼 있었고, 상태는 Expired로 바뀌어 있었다. 아직 이용 기간이 남은 전화번호 예외는 Active였다. 이번 확인 과정에서 정산 테이블 예외를 수동으로 회수하거나 정책을 수정하지는 않았다.

누구에게 어떤 데이터의 예외를 허용했는지, 언제 끝나는지, 어느 요청에서 승인됐는지를 한 화면에서 볼 수 있었다. 예외 요청이 많아져도 승인 메시지를 하나씩 찾아다닐 필요가 줄어들겠다 싶었다.

웹 에디터에서는 정산 조회가 차단됐다

이번에는 개발자 계정의 웹 SQL 에디터에서 주문 4002의 정산 정보를 조회했다. 결과 대신 settlement_details 테이블에 접근할 권한이 없다는 메시지가 나왔다.

승인 기간 안에는 확인할 수 있었던 정산 정보가 다시 접근 제한 대상이 된 것이다. 관리자가 원래의 테이블 제한 정책을 풀었다가 다시 설정할 필요 없이, 업무에 필요한 예외를 기간과 함께 관리할 수 있었다.

DBeaver에서 다시 연결해 확인해 봤다

DBeaver에서도 QueryPie를 거치는 연결로 같은 SQL을 실행했다. 만료 전에 열어 둔 연결에서는 정산 정보가 계속 조회됐지만, 연결을 끊고 다시 접속하자 테이블 접근 권한이 없다는 메시지와 함께 조회가 차단됐다.

이어서 같은 연결에서 일반 주문 정보를 조회했다. 주문 4002의 배송 상태와 주문 금액은 정상적으로 나왔다.

임시로 승인한 정산 정보와 일상적인 주문 조회를 나눠 관리하는 모습이 좋았다. 민감한 데이터에 대한 예외를 관리하면서도, 담당자가 평소 하던 조회 업무는 이어갈 수 있었다.

조회 시도는 감사 로그에서도 확인했다

관리자의 Query Audit에서 방금 실행한 SQL을 찾아봤다. 개발자 계정, Orders Control Lab 연결, 실행 시각과 Failure 결과가 기록돼 있었다. 목록에는 Prevented도 표시됐다.

상세 화면 아래로 내려가니 실행한 SQL과 접근 권한이 없다는 사유가 함께 나왔다. 사용자에게 조회 문의가 들어왔을 때, 승인 기간은 Policy Exception에서 보고 실제 실행 결과는 Query Audit에서 확인하면 상황을 구체적으로 설명할 수 있겠다.

예외를 허용한 뒤에도 관리가 이어졌다

직접 써보니 Policy Exception의 장점은 임시 허용 내역을 운영자가 계속 파악할 수 있다는 데 있었다. 사용자, 데이터 범위, 시작과 종료 시각, 현재 상태가 함께 보이니 어떤 예외가 아직 유효한지 살펴보기 쉬웠다.

도입 담당자 입장에서는 업무상 필요한 접근을 승인하면서도 예외가 무기한 쌓이지 않도록 관리할 수 있다는 점이 매력적이다. 승인 사유와 이용 기간, 실제 조회 기록을 차례로 확인할 수 있어 권한을 어떻게 관리했는지 설명하기 쉬웠다.

이번 실습은 QueryPie Community 11.6.7, MySQL 8.0.42, DBeaver 26.2.4 환경에서 가상 주문 데이터로 진행했다.