[9편] 주문 조회는 허용하고 정산 정보는 보호했다 — QueryPie 테이블 접근 제한 실습

DB 접속을 허용했다고 해서 그 안의 모든 데이터를 볼 필요는 없다. 주문 상태를 확인하는 개발자에게 정산 금액이나 내부 메모까지 필요한 것은 아니기 때문이다.

이번에는 그 구분을 QueryPie ACP에서 직접 해봤다. 같은 DB 안에 주문 테이블과 정산 테이블을 두고, 개발자는 주문을 계속 조회하되 정산 정보에는 접근하지 못하게 설정했다.

평소 하던 조회는 그대로 두면서, 보호할 테이블만 따로 제한할 수 있을까. DBeaver에서 정책 적용 전후로 같은 SQL을 실행해 봤다.

먼저 정산 정보가 조회되는 상태를 확인했다

QueryPie ACP Community 11.6.7의 Orders Control Lab 연결을 사용했다. 기존 orders 테이블 옆에 settlement_details라는 실습용 테이블을 만들고, 가상의 정산 번호와 주문번호, 정산 금액, 내부 메모 3건을 넣었다. 실제 고객이나 회사의 정산 자료는 사용하지 않았다.

개발자 계정은 앞선 실습에서 사용한 Demo Developer다. QueryPie를 거쳐 DBeaver로 접속했고, DB에 등록한 접속 계정에는 두 테이블을 조회할 수 있는 권한을 준비했다.

정책을 설정하기 전에 정산 테이블을 조회했다. 9001번부터 9003번까지 3건이 나왔고, 금액과 메모도 함께 보였다. 이 화면을 기준으로 정책 적용 후 달라지는 모습을 비교했다.

정산 테이블을 보호하는 정책을 만들었다

관리자 화면에서 Databases → Policies → Data Access로 이동했다. Create Policy를 누르고 이름을 Orders Lab - Settlement Access로 입력한 뒤, 대상 연결은 Orders Control Lab으로 지정했다.

정책을 열어 Add Rule List를 눌렀다. Database Name에는 orders_control, Table Name에는 settlement_details를 선택했다. 이번에는 정산 테이블 전체를 보호하려고 Column Name은 따로 지정하지 않았다. Allowed Users에도 예외 사용자를 추가하지 않았다.

저장하고 나니 규칙 목록에 DB와 테이블 이름이 표시됐다. 주문 테이블은 이 규칙에 포함하지 않았다. 어떤 데이터를 제한하는지 목록에서 바로 알아볼 수 있어 설정 내용을 확인하기 편했다.

같은 SQL을 다시 실행하자 정산 조회가 차단됐다

DBeaver로 돌아와 조금 전과 똑같은 정산 조회문을 실행했다. 이번에는 결과 데이터 대신 접근 권한을 확인하라는 메시지가 나왔다.

메시지에는 “You don't have permission to access the table 'orders_control.settlement_details'”라고 대상 테이블까지 표시됐다. 정책을 설정하기 전에는 보였던 정산 정보가, 적용 후에는 조회되지 않았다.

이 과정에서 DBeaver의 연결 정보를 바꾸거나 DB 계정의 SELECT 권한을 회수하지 않았다. 관리자 화면에서 추가한 Data Access 규칙이 QueryPie를 거치는 조회에 적용된 것이다.

접속 권한을 받은 사용자라도 업무에 필요하지 않은 테이블까지 읽을 수 없도록 범위를 좁힐 수 있었다. 도입 담당자 입장에서는 DB 연결을 허용한 다음의 권한 설계까지 구체적으로 볼 수 있는 부분이었다.

주문 조회는 평소처럼 계속할 수 있었다

정산 조회가 막힌 것을 확인한 뒤, 같은 DBeaver 연결에서 orders 테이블의 주문번호와 상태를 조회했다. 4001번과 4003번은 PENDING, 4002번은 DELIVERED로 정상적으로 나왔다.

이번 실습에서 가장 마음에 든 부분은 여기에 있었다. 개발자가 필요한 주문 상태를 확인하는 업무는 계속하면서, 정산 정보는 별도로 보호할 수 있었다. 사용자는 익숙한 DBeaver를 그대로 사용했고, 관리자는 보호 대상 테이블을 QueryPie에서 지정했다.

같은 DB를 여러 부서가 함께 쓰는 상황이 떠올랐다. 접속 허용 여부에 더해 어떤 테이블까지 볼 수 있는지를 정하면, 업무별로 필요한 데이터 범위를 더 세밀하게 관리할 수 있겠다.

차단된 조회도 관리자 화면에 기록됐다

다시 정책 화면으로 돌아가 Logs 탭을 열었다. 방금 실행한 조회가 Access Denied로 남아 있었다. 사용자 이름은 Demo Developer, 대상 테이블은 settlement_details였고 실행 시각도 표시됐다.

기록을 누르자 Query Details가 열렸다. DB 연결과 테이블, 사용자뿐 아니라 DBeaver에서 실행한 정산 조회 SQL도 확인할 수 있었다. Rows는 0으로 표시됐다.

운영 중 “이 조회가 왜 안 되나요?”라는 문의를 받았을 때도 설명할 근거가 남는다. 사용자와 시각을 확인하고, 어떤 테이블을 조회하려 했는지 실제 SQL을 보면서 정책 적용 결과를 설명할 수 있겠다.

접속을 허용한 뒤에도 데이터 범위를 정할 수 있었다

이번 실습은 작은 설정 하나로 차이가 분명하게 드러났다. 정책 적용 전에는 주문과 정산 정보를 모두 조회할 수 있었고, 적용 후에는 정산 조회가 차단되면서 주문 조회는 계속 가능했다.

7편에서는 연락처의 일부를 가렸다면, 이번에는 테이블 자체에 대한 접근을 제한했다. 데이터의 성격과 업무에 따라 보호 방식을 다르게 적용할 수 있다는 점이 좋았다.

필요한 업무는 이어가고, 볼 필요가 없는 데이터는 보호한다. QueryPie의 Data Access를 직접 써보니 이 구분을 관리자 화면에서 설정하고, 사용자의 DB 도구에서 결과를 확인한 뒤, 로그로 이력까지 살펴볼 수 있었다. DB 접근 권한을 업무에 맞게 나누려는 담당자에게 소개하고 싶은 기능이다.