리소스

/

ACP 실습 노트

[34편] 같은 서버에 있는 DB도 업무별로 권한을 나눠봤다

DB 접근 제어

2026년 11월 9일

같은 DB 서버에 여러 업무의 데이터베이스를 함께 두는 경우가 있다. 그렇다고 주문을 확인하는 담당자에게 정산 자료까지 모두 열어 줄 필요는 없다. 이번에는 QueryPie에서 담당자가 조회할 수 있는 DB를 따로 정해 봤다.

 

앞서 테이블별 접근 제한을 다뤘다면, 이번에는 DB 자체를 나누는 설정이다. 하나의 MySQL 서버에 주문 DB와 정산 DB를 두고, 주문 DB만 사용할 수 있도록 권한을 줬다.

 

 

먼저 두 DB가 모두 조회되는지 확인했다

 

주문 DB는 기존 실습의 route_lab을 사용했다. 같은 서버에 ep34_finance라는 정산 DB를 추가하고 가상 정산 내역 세 건을 넣었다. QueryPie에는 DB Schema Scope Lab이라는 실습용 연결을 만들었다.

 

처음에는 Demo Developer에게 이 연결의 Host 단위 Read-Only 권한을 줬다. 웹 SQL 에디터에서 주문 한 건을 조회한 다음, 같은 연결에서 정산 번호 34002도 조회했다. 두 쿼리 모두 결과가 나왔다.

 

화면 1. 권한을 나누기 전에는 같은 연결에서 정산 데이터도 조회됐다.
화면 1. 권한을 나누기 전에는 같은 연결에서 정산 데이터도 조회됐다.

 

연결에 등록한 DB 계정은 두 테이블을 모두 읽을 수 있는 계정이다. 이 계정의 권한은 그대로 두고, QueryPie에서 Demo Developer에게 허용하는 범위를 바꿨다.

 

 

권한을 줄 때 주문 DB를 지정했다

 

기준 조회에 사용한 연결을 끊고, 방금 부여한 Host 권한을 회수했다. 이어서 Grant Privilege를 열어 Access Control Level을 Schema (Logical DB)로 선택했다.

 

대상 연결은 DB Schema Scope Lab, Host Level Privilege는 Read-Only로 골랐다. Add Item을 눌러 주문 DB 이름인 route_lab을 넣고 Select를 선택했다. MySQL에서는 여기에 테이블 이름까지 쓸 필요 없이 DB 이름을 입력하면 됐다.

 

화면 2. 논리 DB 단위로 권한을 주고, 업무용 DB는 route_lab만 추가했다.
화면 2. 논리 DB 단위로 권한을 주고, 업무용 DB는 route_lab만 추가했다.

 

화면에 기본으로 들어 있던 information_schema와 mysql의 Select 항목은 유지했다. 정산 DB인 ep34_finance는 추가하지 않았다.

 

저장한 권한을 다시 열어 보니 Schema Level 목록에 지정한 DB와 Select가 남아 있었다. 사용자 화면에서도 같은 권한 범위를 확인할 수 있었다.

 

 

주문은 조회됐고, 정산은 제한됐다

 

Demo Developer로 새로 접속한 뒤 앞에서 사용한 주문 조회 SQL을 다시 실행했다. 주문 27002의 상태 SHIPPED와 금액 18,500원이 그대로 나왔다.

 

화면 3. 허용한 주문 DB에서는 필요한 데이터를 계속 조회할 수 있었다.
화면 3. 허용한 주문 DB에서는 필요한 데이터를 계속 조회할 수 있었다.

 

이어서 같은 정산 조회 SQL을 실행했다. 이번에는 결과 대신 “No permission to execute SELECT statement”라는 권한 안내가 표시됐다. 조금 전까지 조회되던 정산 데이터가, 새로 정한 DB 범위에 따라 제한된 것이다.

 

화면 4. 주문 DB에만 권한을 주자 정산 DB의 SELECT는 실행되지 않았다.
화면 4. 주문 DB에만 권한을 주자 정산 DB의 SELECT는 실행되지 않았다.

 

그 상태에서 주문을 다시 조회해도 정상적으로 결과가 나왔다. 정산 조회가 제한된 뒤에도 주문 확인 업무는 이어갈 수 있었다.

 

DB에 등록한 계정으로 별도 조회했을 때는 여전히 두 테이블을 모두 읽을 수 있었다. DB 계정은 유지하면서 QueryPie 사용자별로 필요한 업무 DB만 허용할 수 있다는 점이 잘 드러났다.

 

 

어느 DB를 조회하려 했는지도 기록에 남았다

 

관리자 화면의 Query Audit에서 Demo Developer와 DB Schema Scope Lab을 골라 봤다. 처음 실행한 두 조회와 권한을 바꾼 뒤의 세 조회, 총 다섯 건이 모였다.

 

정산 조회는 Failure와 Prevented로 표시됐다. 상세에는 사용자 이름, 실행 시각, DB 계정 ep34_reader, 대상 DB ep34_finance와 테이블 settlements, 실제 SQL과 권한 거부 메시지가 함께 남아 있었다.

 

화면 5. 제한된 정산 조회의 사용자와 대상 DB, SQL, 오류 메시지를 확인했다.
화면 5. 제한된 정산 조회의 사용자와 대상 DB, SQL, 오류 메시지를 확인했다.

 

마지막 주문 조회 기록은 Success였고, Schema Level 권한도 route_lab의 Select로 표시됐다. 조회 결과뿐 아니라 어떤 DB 권한으로 실행됐는지까지 함께 볼 수 있었다.

 

 

권한을 바꾼 내역도 함께 확인했다

 

Access Control Logs에서는 이 연결에 권한을 부여하고 회수한 기록을 확인했다. 대상 사용자와 권한, 변경 시각이 남았고, Action By에서는 설정한 관리자를 확인할 수 있었다. 실습을 마친 뒤 이번 연결에 준 권한을 회수한 내역도 이어서 표시됐다.

 

화면 6. 같은 연결 이름으로 권한 부여와 회수 이력을 모아 볼 수 있었다.
화면 6. 같은 연결 이름으로 권한 부여와 회수 이력을 모아 볼 수 있었다.

 

주문을 보는 담당자에게 주문 DB만 열어 주고, 정산 DB는 별도로 관리할 수 있었다. DB 서버를 따로 늘리지 않아도 담당 업무에 맞춰 조회 범위를 나눌 수 있어 편했다. 권한 설정과 실제 조회 기록을 함께 확인할 수 있다는 점도 운영 담당자에게 유용했다.

 

실습은 QueryPie Community 11.6.7과 MySQL 8.0.42의 웹 SQL 에디터에서 진행했다. 사용자와 데이터는 모두 실습용이다.

 

참고: Access Control · Privilege Type · Query Audit