[40편] DB 접속 권한은 그대로 두고 허용 IP를 정해봤다
2026년 11월 13일
DB 조회 권한을 받은 사람이라도 접속할 수 있는 IP까지 함께 정해 두고 싶을 때가 있다. 업무에 필요한 권한은 주되, 정해진 네트워크에서만 DB를 사용하게 하는 방식이다.
이번에는 QueryPie의 Allowed Zone을 써봤다. 같은 사용자에게 같은 조회 권한을 둔 채 허용 IP만 바꿔 보고, 다시 원래 값으로 되돌렸을 때 조회가 이어지는지 확인했다.
먼저 접속 기록에서 현재 IP를 확인했다
실습용 연결은 DB Allowed Zone Lab으로 만들었다. 기존 MySQL의 주문 데이터를 사용하고, Demo Developer에게 이 연결의 Read-Only 권한을 부여했다.
허용할 IP를 입력하기 전에 웹 SQL 에디터로 한 번 접속했다. 관리자 화면의 Audit → DB Access History에서 방금 접속한 기록을 열어 보니 사용자와 DB 연결 이름, 접속 방식이 함께 표시됐다. 이번 환경에서 QueryPie에 기록된 Client IP는 172.21.0.1이었다.

이 주소를 기준으로 허용 범위를 정했다. 접속 기록에 실제로 남는 주소를 확인하고 설정할 수 있어서, 어떤 IP를 등록해야 하는지 분명했다.
허용 IP는 이번 DB 연결에만 적용했다
General → Company Management → Allowed Zones에서 새 Zone을 만들었다. 이름은 EP40 - DB Client Zone, IP 범위는 172.21.0.1/32로 넣었다. 뒤의 /32는 IPv4 주소 한 개만 지정한다는 뜻이다.

이어서 DB Allowed Zone Lab의 연결 설정을 열고, Allowed Zone에 방금 만든 항목을 선택해 저장했다. Zone 상세의 적용 목록에서도 이번 DB 연결 한 개만 표시되는 것을 확인했다.

허용 범위를 이름 있는 Zone으로 만들어 두고 DB 연결에서 선택하는 구성이었다. 연결마다 어떤 접속 범위를 적용했는지 확인하기 쉽고, Zone 쪽에서도 적용된 DB를 찾아볼 수 있다는 점이 편했다.
Demo Developer로 새 연결을 열고 주문번호 27002를 조회했다. 결과는 SHIPPED, 18500.00 한 행이었다. 허용 목록에 현재 IP가 들어 있으니 평소처럼 웹 에디터에서 조회할 수 있었다.

조회 권한이 있어도 IP 조건이 맞아야 접속됐다
이번에는 연결을 끊고, 같은 Zone의 IP 범위만 192.0.2.254/32로 바꿨다. 현재 접속 IP가 허용 목록에 없는 상황을 만들기 위해 넣은 문서용 주소다. 사용자를 바꾸거나 Read-Only 권한을 회수하지는 않았다.

같은 연결에서 Connect를 눌렀다. 이번에는 SQL 에디터로 넘어가지 않고 다음 안내가 나왔다.
“This database is not accessible by this network zone.”
현재 네트워크 Zone에서는 이 DB에 접근할 수 없다는 뜻이다. 뒤에 보이는 연결 정보에는 Read-Only 권한과 Active 상태가 그대로 남아 있었다. 조회 권한이 있다는 것만으로 접속이 허용되는 것은 아니었고, DB에 지정한 IP 조건도 함께 적용됐다.

허용 IP를 되돌리자 같은 조회가 다시 됐다
같은 Zone의 범위를 다시 172.21.0.1/32로 되돌렸다. 별도로 권한을 다시 부여하거나 DB 계정을 바꿀 필요는 없었다.
Demo Developer로 새로 접속해 앞서 실행한 SQL을 그대로 실행했다. 주문번호 27002, 상태 SHIPPED, 금액 18500.00이 다시 조회됐다. 사용자와 DB 권한을 유지하면서, 허용 IP 설정으로 접속할 수 있는 조건을 관리할 수 있었다.

이번 비교는 같은 접속 환경에서 Zone의 허용 목록을 바꾸며 진행했다. 각 단계에서는 연결을 끊고 새로 접속해 결과를 확인했다.
접속을 막은 이유도 기록에서 확인할 수 있었다
DB Access History에는 이번 접속 흐름이 차례로 남았다. 허용 IP가 포함됐을 때의 접속은 Success, 제외했을 때는 Failure, 원래 값을 복원한 뒤에는 다시 Success였다. 세 접속의 사용자와 DB 연결, Client IP도 일치했다.
실패 기록을 열어 보니 Error Message에 현재 IP에서는 이 DB에 접근할 수 없다는 사유와 해당 IP가 함께 표시됐다. 사용자 화면의 안내를 관리자도 접속 이력에서 다시 확인할 수 있었다.

Query Audit에서는 허용 전후에 실행한 두 SELECT가 모두 성공한 것도 확인했다. 접속 허용 여부는 접속 이력에서, 실제로 실행한 조회는 SQL 감사에서 이어서 볼 수 있었다.
직접 써보니 “누가 조회할 수 있는가”와 “어떤 IP에서 접속할 수 있는가”를 함께 관리할 수 있다는 점이 좋았다. 사용자에게 필요한 조회 권한은 유지하면서, DB 연결별로 허용할 네트워크 범위를 정할 수 있었다. 설정한 조건이 접속에 적용되고 그 결과와 사유까지 기록으로 남으니, 운영 담당자 입장에서도 관리 흐름이 명확했다.
실습은 QueryPie Community 11.6.7과 MySQL 8.0.42에서 진행했다. 화면의 사용자와 주문 데이터는 실습용이다.
참고: Allowed Zones · DB Connections · DB Access History
![[39편] DB 담당자가 바뀌어도 결재 규칙은 그대로였다](/assets/content/acp-lab-notes/approval-rules/01.webp)
![[41편] 조회용 권한과 작업용 권한에 서로 다른 DB 계정을 연결해봤다](/assets/content/acp-lab-notes/database-account-mapping/01.webp)