리소스

/

ACP 실습 노트

[21편] 감사 담당자에게 필요한 권한만 맡겨봤다 — QueryPie 관리자 역할 분리

승인 · 감사 · 운영

2026년 11월 9일

앞선 글에서는 관리자 계정으로 DB 감사 기록을 보고 파일로 내려받았다. 실제 운영에서는 DB를 설정하는 사람과 그 기록을 점검하는 사람이 다를 수 있다. 감사 담당자가 자기 계정으로 필요한 자료를 확인할 수 있으면 좋겠다는 생각이 들었다.

 

이번에는 QueryPie에 감사 담당자 역할을 따로 만들었다. 그 계정으로 주문 변경 기록과 DML Snapshot을 열고, 감사 파일도 내려받았다. DB 운영 설정 화면은 권한이 없어 열리지 않았다. 역할을 나눠 놓으니 각자 맡은 일을 어디까지 할 수 있는지 분명해졌다.

 

 

감사 업무에 필요한 정책으로 역할을 만들었다

 

관리자 화면의 General → User Management → Roles에서 DB Audit Reviewer라는 역할을 만들었다. 설명에는 ‘주문 DB 감사 기록 확인 및 감사 자료 추출 담당’이라고 적었다.

 

Assign Policies를 누르면 역할에 넣을 정책을 고를 수 있다. 먼저 Database Audit Full Access를 찾았다. DB 감사 메뉴를 사용할 수 있게 하는 정책이다.

 

화면 1. 감사 역할에 넣을 Database Audit Full Access 정책을 선택했다.
화면 1. 감사 역할에 넣을 Database Audit Full Access 정책을 선택했다.

 

이번 역할에는 Database Audit Full Access와 Report Audit Full Access, 두 정책을 넣었다. DB 감사 기록을 확인하고 Reports 메뉴에서 감사 자료를 받을 수 있도록 구성한 것이다. 사용자 관리나 DB 연결 설정을 변경하는 정책은 추가하지 않았다.

 

화면 2. DB Audit Reviewer에 DB 감사와 Reports 접근 정책 두 개를 구성했다.
화면 2. DB Audit Reviewer에 DB 감사와 Reports 접근 정책 두 개를 구성했다.

 

정책 이름과 설명이 역할 상세에 함께 나와서, 이 담당자에게 어떤 일을 맡긴 것인지 확인하기 쉬웠다. 이 역할의 범위에는 감사 자료 다운로드도 포함된다.

 

 

감사 담당자에게 만든 역할을 부여했다

 

실습용 Demo Auditor 계정을 추가한 뒤 Users 목록의 Admin Role에서 DB Audit Reviewer를 선택하고 Apply를 눌렀다. 기존 관리자 계정은 Owner로 유지했다.

 

화면 3. Demo Auditor에는 DB Audit Reviewer를, 기존 관리자는 Owner를 유지했다.
화면 3. Demo Auditor에는 DB Audit Reviewer를, 기존 관리자는 Owner를 유지했다.

 

이제 감사 담당자 계정으로 로그인했다. 관리자 화면에 들어가니 상단에는 Audit이, 왼쪽에는 Reports와 DB 감사 메뉴가 보였다. Owner로 로그인했을 때 보이던 General이나 DB 운영 설정 메뉴는 나타나지 않았다.

 

화면 4. Demo Auditor로 로그인한 관리자 화면. 감사 업무에 필요한 메뉴를 확인할 수 있다.
화면 4. Demo Auditor로 로그인한 관리자 화면. 감사 업무에 필요한 메뉴를 확인할 수 있다.

 

 

개발자가 실행한 주문 변경 기록을 열어 봤다

 

Query Audit에서 19편의 주문 변경 기록을 찾았다. No.293, 실행자는 Demo Developer, 결과는 Success였다. 상세 화면에는 Orders Control Lab과 실행 시각, 69ms, SQL Request 출처가 표시됐다.

 

화면 5. 감사 담당자 계정에서 개발자가 실행한 UPDATE의 상세 정보를 확인했다.
화면 5. 감사 담당자 계정에서 개발자가 실행한 UPDATE의 상세 정보를 확인했다.

 

작업자나 운영 관리자의 계정을 빌릴 필요 없이, 감사 담당자 자신의 계정으로 기록을 확인할 수 있었다. 누가 실행했고 어떤 경로로 처리한 작업인지 바로 살펴볼 수 있어 좋았다.

 

 

변경 전후 값도 감사 담당자가 직접 확인했다

 

DML Snapshots에서도 같은 UPDATE를 열었다. Before에는 주문 4003의 status가 PENDING으로, After에는 DELIVERED로 기록돼 있었다. 이전 글에서 관리자 계정으로 확인했던 변경 내용이었다.

 

화면 6. 감사 담당자가 확인한 DML Snapshot의 After. 주문 4003의 상태가 DELIVERED로 남아 있다.
화면 6. 감사 담당자가 확인한 DML Snapshot의 After. 주문 4003의 상태가 DELIVERED로 남아 있다.

 

SQL이 성공했다는 기록에 더해 실제로 어떤 값이 바뀌었는지까지 볼 수 있었다. 담당자가 변경 내용을 확인하려고 운영 관리자에게 화면을 따로 요청하는 수고를 줄일 수 있겠다.

 

 

DB 운영 설정은 열 수 없었다

 

감사 조회가 되는 것을 확인한 뒤, 같은 계정으로 DB 운영 설정 주소를 열어 봤다. 결과는 No Permission이었다. 화면에 이 페이지에 접근할 권한이 없다고 표시됐다.

 

화면 7. 감사 담당자 계정으로 DB 운영 설정 페이지를 열자 No Permission이 표시됐다.
화면 7. 감사 담당자 계정으로 DB 운영 설정 페이지를 열자 No Permission이 표시됐다.

 

감사 담당자는 기록을 확인하고, DB 설정을 바꾸는 일은 운영 관리자에게 맡길 수 있었다. 메뉴를 구분해 보여 주는 데 그치지 않고, 주소로 직접 들어가도 설정 페이지가 열리지 않는 것을 확인했다.

 

 

감사 자료 다운로드까지 같은 계정으로 처리했다

 

Audit Log Export를 열자 20편에서 만들어 둔 감사 자료가 Completed 상태로 보였다. Demo Auditor 계정에서 Download를 눌러 파일을 받았다.

 

화면 8. 감사 담당자가 Audit Log Export에서 완료된 감사 자료를 내려받았다.
화면 8. 감사 담당자가 Audit Log Export에서 완료된 감사 자료를 내려받았다.

 

압축을 풀어 CSV를 대조해 보니, 앞서 관리자 계정으로 받은 자료와 내용이 같았다. 주문을 조회한 SELECT와 승인받아 실행한 UPDATE 두 건이 들어 있었다. 감사 담당자가 기록을 확인하고 필요한 파일을 받는 과정까지 직접 처리할 수 있었다.

 

역할을 나눠 보니 운영 관리자에게 자료 확인을 일일이 부탁하지 않아도 되겠다는 생각이 들었다. 감사 담당자는 자기 계정으로 작업 이력과 변경된 값을 살펴보고 파일까지 받을 수 있었다. DB 운영 설정 권한은 별도로 유지했다. 조직에서 맡은 업무에 맞춰 QueryPie의 관리 권한을 나눌 수 있다는 점이 좋았다.

 

이번 실습은 QueryPie Community 11.6.7에서 가상 사용자와 주문 DB의 감사 기록으로 진행했다.

 

참고: QueryPie 공식 Roles 문서 · 사용자에게 관리자 역할 부여하기