[48편] 외부 유지보수 담당자에게 필요한 작업만 맡겨봤다

외부 유지보수 담당자에게 DB 점검을 맡길 때면 권한을 어디까지 열어줘야 할지부터 고민하게 된다. 주문 상태를 확인하는 일인데 데이터를 바꿀 권한까지 줄 필요는 없고, 작업이 끝난 뒤에도 접속 권한을 남겨둘 이유는 없다.

이번에는 QueryPie에서 이 과정을 처음부터 끝까지 해봤다. 테스트 사용자에게 외부 유지보수 담당자 역할을 맡겨 조회 권한을 요청하고, 별도 승인자가 승인한 뒤 주문 한 건을 확인했다. 점검을 마친 뒤에는 권한을 회수하고 실제로 더 이상 조회할 수 없는지도 살펴봤다.

1. 어떤 DB에서 무슨 일을 할지 먼저 적었다

작업은 간단하게 잡았다. 주문 41001의 상태와 금액을 확인하는 점검이다. 실제 고객 자료를 쓰지 않고, 앞서 만든 실습 DB와 테스트 계정을 사용했다.

작업자 계정으로 Workflow의 DB Access Request를 열었다. 대상은 DB Privilege Account Lab 하나, 요청 권한은 Read-Only로 골랐다. 요청 사유에도 주문 상태 확인이 목적이고, 데이터 변경은 하지 않으며 점검 후 권한을 회수한다고 적었다.

접근 만료일은 실습 당일로 정했다. 요청을 받아보는 담당자가 DB 이름뿐 아니라 작업 목적, 권한 범위, 기한을 함께 확인할 수 있는 구성이었다.

2. 승인을 받으니 조회 권한이 반영됐다

이번 요청에는 기존에 준비한 승인 규칙을 사용했다. 지정 승인자인 Demo Approver로 들어가 요청 내용을 확인하고, 주문 상태 점검 목적의 조회 권한을 승인한다는 의견을 남겼다.

승인을 마치자 요청 상태가 Approved로 바뀌었다. 요청한 사람과 승인한 사람이 구분되고, 요청·처리 시각도 남았다. 담당자가 바뀌거나 나중에 작업 경위를 찾아볼 때 설명의 출발점으로 삼기 좋겠다.

다시 작업자 화면으로 돌아오니 해당 DB에 Read-Only 권한이 생겼다. 허용된 SQL은 Select였고, 접근 만료 시각은 당일 23시 59분 59초로 표시됐다. 승인 이후 관리자가 같은 권한을 한 번 더 부여할 필요는 없었다.

3. 주문은 조회할 수 있었고, 변경은 막혔다

Connect를 눌러 SQL Editor에 접속한 뒤 주문 41001을 조회했다. 상태는 READY, 금액은 25,000원이었다. 요청서에 적었던 점검은 이 조회로 진행할 수 있었다.

권한 범위도 확인해봤다. 같은 주문의 상태를 바꾸는 UPDATE를 입력하자, QueryPie가 UPDATE 실행 권한이 없다는 메시지와 함께 막았다. 별도로 원본 데이터를 확인해보니 상태와 금액은 그대로였다.

조회 업무를 맡기면서 변경 권한까지 함께 주지 않아도 된다는 점이 좋았다. “확인만 해주세요”라고 말로 전달한 작업 범위를 실제 실행 권한으로 정해둘 수 있었다.

4. 점검이 끝나자 권한도 회수했다

작업 종료를 가정하고 관리자 화면에서 이번에 승인받은 DB 권한만 회수했다. 작업자의 다른 기존 권한은 그대로 두었다.

작업자 화면을 새로 열자 대상 DB가 접속 목록에서 사라졌다. 앞서 사용하던 SQL Editor에서도 같은 SELECT를 다시 실행해봤는데, 이 연결에서 쿼리를 실행할 권한이 없다는 안내가 나왔다.

이번에는 설정한 만료 시각을 기다리지 않고 점검 직후 직접 회수했다. 작업을 끝낸 시점에 접근 권한도 함께 정리할 수 있어, 예정된 기한보다 일찍 끝난 유지보수 업무에도 적용하기 편하겠다.

5. 요청부터 회수까지 기록이 남았다

마지막으로 감사 화면을 열었다. Access Control Logs에는 13시 41분 48초에 권한이 부여된 기록과 13시 44분 24초에 회수된 기록이 나란히 남았다. 상세 항목에서는 요청을 통한 부여와 관리자의 회수를 구분할 수 있었다.

Query Audit에서는 실제 조회 성공과 UPDATE 차단 기록을 확인했다. 차단된 SQL을 열어보니 사용한 DB 계정, 대상 테이블, SQL 원문과 차단 사유까지 볼 수 있었다. 접속을 허용했다는 사실에 더해, 그 권한으로 무엇을 했는지까지 이어서 확인할 수 있었다.

직접 해보니 외부 유지보수 업무에 필요한 기능들이 한 흐름으로 이어졌다. 작업자는 목적과 범위를 적어 요청하고, 승인자는 그 내용을 보고 권한을 열어준다. 작업 중에는 허용된 조회만 수행할 수 있고, 종료 후에는 권한을 회수한다. 그 과정에서 누가 승인했고 어떤 SQL을 실행했는지도 남는다.

도입 담당자 입장에서 특히 마음에 들었던 부분은 작업을 허용하면서도 관리할 범위가 분명하다는 점이었다. 필요한 업무는 진행하게 하고, 허용하지 않은 변경은 막고, 끝난 권한은 정리하는 모습을 한 번의 점검으로 확인할 수 있었다.