[27편] DBeaver는 그대로, DB 직접 접속은 닫아봤다 — QueryPie 접속 경로 정리

QueryPie로 DB 권한을 관리하고 작업 기록을 남겨도, 사용자가 예전 DB 주소로 직접 접속한다면 그 경로는 따로 정리해야 한다. 도입을 준비하는 입장에서는 “앞으로 어디로 접속하게 할 것인가”도 중요한 문제다.

이번에는 DBeaver에서 같은 DB에 두 가지 방법으로 접속해 봤다. 먼저 DB에 직접 연결하고, 다음에는 QueryPie를 거쳤다. 두 연결에서 같은 주문을 조회한 뒤 직접 접속하던 포트를 닫았다. 그 후에도 QueryPie로 새로 접속해 주문을 조회할 수 있었고, 실행 기록은 관리자 화면에 남았다.

비교할 DB와 조회 권한을 준비했다

실습용 MySQL을 별도로 만들고 가상의 주문 세 건을 넣었다. QueryPie에는 DB Route Lab이라는 이름으로 등록했다. 연결에 사용할 route_reader 계정에는 주문 테이블을 읽는 권한만 줬다.

관리자 화면에서 DB 연결 정보를 입력하고 Test Connection을 눌렀다. 연결이 성공한 것을 확인한 뒤, 사용자 연결 목록에서는 이 DB 계정 정보를 숨기도록 설정했다. 프록시 접속에는 QueryPie에 등록한 계정을 사용하게 했다.

Demo Developer에게는 DB Route Lab의 Read-Only 권한을 부여했다. DB를 등록하는 일과 사용자에게 접근 권한을 주는 일이 나뉘어 있었다. 관리자는 DB 연결 정보를 관리하고, 사용자는 자신에게 허용된 연결을 선택하는 방식이다.

DBeaver에 직접 연결과 QueryPie 연결을 만들었다

비교를 위해 DBeaver에 연결 두 개를 추가했다. 직접 연결은 Mac의 127.0.0.1:13307을 사용했고, QueryPie 연결은 사용자 화면의 Proxy Info에 나온 127.0.0.1:40002를 사용했다. 두 연결이 가리키는 DB는 같은 route_lab이다.

QueryPie 연결에는 Demo Developer로 발급받은 프록시 토큰을 입력했다. 사용자용 접속 정보를 사용하면서 실제 DB 연결에는 관리자가 등록한 계정이 쓰이는 구성이다. 이번에는 Agentless Proxy를 사용해 DBeaver에서 바로 접속했다.

먼저 직접 연결에서 주문 27002번을 조회했다. 주문 상태는 SHIPPED, 금액은 18,500이었다. 이 결과를 기준으로 QueryPie 연결에서도 같은 SQL을 실행했다.

QueryPie를 거쳐도 같은 SQL로 조회할 수 있었다

QueryPie 연결에서도 주문 번호, 상태, 금액이 똑같이 나왔다. DBeaver의 SQL 편집기에서 문장을 실행하고 결과 표를 확인하는 사용 방식도 같았다.

이미 쓰고 있는 DB 도구를 계속 사용할 수 있다는 점이 좋았다. 사용자에게는 접속할 연결을 안내하고, 관리자는 QueryPie에서 해당 사용자의 권한을 관리할 수 있었다. DB 비밀번호를 사용자별로 전달하는 대신 사용자에게 발급한 프록시 접속 정보를 활용할 수 있다는 점도 눈에 들어왔다.

DB에 직접 접속하던 포트를 닫아봤다

이제 실습용 DB의 직접 접속 경로를 정리했다. DBeaver의 두 연결을 끊은 뒤, Docker 설정에서 Mac으로 공개하던 13307 포트를 제거했다. 데이터와 내부 네트워크 설정을 유지한 채 실습 DB 컨테이너를 다시 띄웠다.

이 포트를 닫는 작업은 Docker의 네트워크 설정에서 진행했다. QueryPie는 남겨 둔 프록시 접속에서 사용자 인증과 권한 확인, SQL 감사 기록을 담당한다. 접속 경로와 사용자 권한을 함께 정리하는 구성이었다.

변경 후 DBeaver의 직접 연결에서 다시 접속을 시도했다. 이번에는 “Connection refused (connect failed)”가 표시됐다. 앞서 조회에 사용했던 DB 계정 정보가 저장돼 있어도, 닫힌 주소로는 새 연결을 맺을 수 없었다.

QueryPie로 다시 접속하니 조회와 감사 기록이 남았다

이어서 DBeaver의 QueryPie 연결을 선택해 새로 접속했다. 같은 SQL을 실행하자 주문 27002번이 다시 조회됐다. 상태는 SHIPPED, 금액은 18,500으로 이전과 같았다.

관리자 화면의 Audit → Databases → Query Audit도 열어 봤다. 방금 실행한 SELECT의 결과는 Success였다. 사용자 이름은 Demo Developer, 연결 이름은 DB Route Lab, 권한은 Read-Only로 표시됐다. Executed From에는 Agentless Proxy가 남아 있었다.

DB 쪽에서 사용하는 계정은 route_reader였지만, QueryPie 기록에서는 실제 접속한 Demo Developer를 함께 확인할 수 있었다. 상세에는 주문 27002번을 조회한 SQL과 실행 시각도 들어 있었다. 어떤 DB 계정으로 처리됐는지와 누가 요청했는지를 한 화면에서 볼 수 있어 운영 이력을 확인하기 편했다.

사용하던 도구를 유지하면서 접속 관리를 모을 수 있었다

이번 실습에서 가장 마음에 든 점은 사용자의 작업 방식이 크게 달라지지 않았다는 것이다. DBeaver에서 주문을 조회하는 일은 그대로였고, 접속할 곳을 QueryPie로 정리한 뒤에는 사용자 권한과 조회 기록을 관리자 화면에서 확인할 수 있었다.

도입 담당자에게는 이 조합이 유용하겠다. DB 네트워크에서는 직접 접속할 수 있는 범위를 정리하고, QueryPie에서는 누가 어떤 권한으로 사용할지 관리한다. 현업이 익숙한 도구를 계속 쓰면서도, 접근 허용과 작업 이력을 사용자 기준으로 모아 볼 수 있었다.

이번 실습은 QueryPie Community 11.6.7, DBeaver 26.2.4, 별도로 구성한 MySQL에서 진행했다. 주문 정보는 모두 실습용 가상 데이터다.

참고: QueryPie Database Proxy · 시스템 구조와 네트워크 접근