한 부서에 DB를 열어 주면, 보면 안 되는 테이블까지 따라 열릴까

#DB를 통째로 열면 같은 DB의 연봉 테이블도 열린다

관리자가 영업팀 역할에 업무 DB를 열어 줍니다. 영업 사원이 고객별 주문 실적을 물으면 AI가 그 DB에서 답을 찾아옵니다. 그런데 같은 업무 DB에 직원 연봉 테이블도 들어 있다면, 영업팀에 열린 것은 고객 테이블만이 아닙니다.

OwlAI만으로도 역할마다 질의할 수 있는 DB를 정할 수 있습니다. 영업팀에는 영업 DB를, 인사팀에는 인사 DB를 여는 식입니다. 다만 실제 회사 DB는 그렇게 깔끔하게 나뉘어 있지 않아서, 고객 테이블과 연봉 테이블이 한 DB에 함께 있는 경우가 흔합니다. 직접 연결한 DB는 DB 단위로 열리고, 그 안의 경계는 연결에 쓴 계정의 권한이 정합니다. OwlDB와 함께 쓰면 이 경계가 테이블 단위로 내려옵니다. 관리자가 영업팀 역할에 고객·주문 테이블만 고르면, 영업 사원의 질문으로 AI가 조회할 수 있는 테이블은 그 둘뿐입니다.

#OwlDB와 함께 쓰면 권한은 DB가 직접 지킨다

OwlDB로 DB를 연결할 때 관리자는 접속 정보를 따로 넣지 않습니다. OwlAI는 OwlDB가 알려 주는 DB 목록을 그대로 가져다 쓰고, 역할마다 DB 계정이 따로 생깁니다. 관리자가 OwlAI 화면에서 역할에 테이블을 열면 그 역할의 DB 계정에 해당 테이블의 조회 권한이 부여되고, 테이블을 닫으면 권한도 회수됩니다. 영업 사원의 질문으로 AI가 SQL을 쓰면 그 SQL은 영업팀 역할의 계정으로 실행되고, 연봉 테이블을 읽으려는 SQL은 DB가 거절합니다. 이 경계를 지키는 것은 AI가 아니라 DB입니다.

AI가 쓴 SQL을 글자로 훑어 테이블 이름을 막는 방식은 이만큼 단단하지 않습니다. 뷰를 거치거나 하위 질의에 숨기거나 엔진마다 다른 문법을 쓰면 검사를 비켜 가는 길이 생깁니다. 그래서 OwlAI는 DB 계정이 권한을 강제할 수 있는 연결에서만 테이블 단위 권한을 엽니다. OwlDB로 연결한 DB가 바로 그런 연결입니다.

경계는 두 겹입니다. AI는 처음부터 역할에 열린 테이블만 보고 SQL을 쓰고, 혹시 다른 테이블을 건드리는 SQL이 나와도 DB가 막습니다.

#역할은 DB 감사 로그에, 사람은 SQL 실행 이력에 남는다

모든 질문을 계정 하나로 실행하면 DB 감사 로그에는 누가 물었든 같은 계정 이름만 남습니다. DB 관리자가 감사 로그를 열어도 그 조회가 영업팀 질문이었는지 인사팀 질문이었는지 가릴 수 없습니다.

역할마다 계정이 나뉘면 DB 감사 로그에서 실행 주체가 역할 단위로 구분됩니다. 사람 단위의 기록은 OwlAI가 맡습니다. SQL이 실행될 때마다 누가, 언제, 어느 DB에 어떤 SQL을 보냈는지 한 줄씩 남깁니다(「볼 권한이 없는 데이터를 AI에게 물으면 어떻게 될까」). 감사인이 "지난달 연봉 테이블을 조회한 사람"을 물으면 DB 감사 로그에서 역할을 확인하고, OwlAI의 SQL 실행 이력에서 사람과 SQL 원문을 찾으면 됩니다.

#도입 전에 확인할 것

OwlDB로 DB를 연결할 계획이라면 다음 세 가지를 먼저 정해 둡니다.

• 같은 DB 안에서 역할마다 다르게 열어야 하는 테이블 목록
• 역할별 DB 감사 로그를 점검할 담당자
• OwlAI의 SQL 실행 이력과 DB 감사 로그를 함께 보는 감사 절차