KO
도입 문의

DAC · Database-aware Security Gateway

DB 를 깊이 이해하는 보안 게이트웨이

게이트웨이가 DB 의 통신 규약을 직접 해석해서 누가, 어느 DB 에, 어떤 문장을 실행하는지 판정합니다. 공유 계정 뒤의 사람까지 특정하고, 조회 결과의 개인정보를 마스킹하고, 모든 것을 기록합니다. 데스크톱 에이전트를 사용하면 사용자는 사용하던 DB 도구와 접속 주소를 그대로 사용합니다.

  • MySQL
  • MariaDB
  • PostgreSQL
  • Oracle
  • SQL Server

DAC(DB 접근제어)란

DB 접근제어(DAC, Database Access Control)는 DB 로 향하는 접속을 중간에서 통제하고 감사하는 보안 제품군입니다. 사용자 인증, 명령 통제, 마스킹, 감사가 주된 기능입니다.

BeeHind 의 DAC 는 DB 의 통신 규약(wire protocol)을 직접 해석합니다. 그래서 DB 와 애플리케이션을 고치지 않고도 SQL 문장을 통제하고, 별칭이나 함수 뒤에 숨은 민감한 컬럼까지 마스킹합니다.

클라이언트와 DB 사이에서 동작하는 인라인 프록시이므로, 관찰만 하는 방식과 달리 접속을 거부하고, 문장을 막고, 결과를 마스킹할 수 있습니다. DB 의 방화벽이 게이트웨이에서 오는 접속만 받도록 설정하면 게이트웨이가 유일한 입구가 됩니다.

접속 경로

접속하는 쪽에 맞는 두 가지 경로

직원 PC 의 DB 도구는 데스크톱 에이전트를 거쳐 접속하고, 에이전트를 설치할 수 없는 곳은 관리자가 발급한 접속 주소로 접속합니다. 두 경로 모두 같은 정책과 감사가 적용됩니다.

접속하는 쪽데스크톱 에이전트게이트웨이에 닿는 방법누구인지 아는 방법
직원 PC 의 DB 도구필요에이전트가 접속을 가로채 mTLS 터널로 보냅니다서명된 신원 증명
협력사 PC, BI 도구필요 없음발급받은 접속 주소로 직접 접속합니다주소에 배정한 이름과 허용 대역
배치 서버필요 없음발급받은 접속 주소로 직접 접속합니다허용 대역

에이전트를 사용하면 DB 도구에 실제 DB 주소와 평소의 DB 계정을 그대로 넣습니다. 에이전트에 로그인하면 가로채기가 자동으로 켜집니다.

통제

접속부터 문장까지 단계마다 판정합니다

규칙이 없는 접속은 거부합니다. 규칙이 겹치면 가장 제한적인 것을 따릅니다.

  • 접근 규칙

    사용자나 그룹, 서비스, DB 계정의 조합마다 허용, 거부, 승인 필요 중 하나를 정합니다.

  • 접속 제약

    접속할 수 있는 IP 대역과 요일, 시간대를 정합니다. 허용된 시간이 지나면 열려 있는 세션도 끊습니다.

  • DB 계정 통제

    서비스마다 사용할 수 있는 DB 계정을 정하고, 그 밖의 계정은 DB 에 닿기 전에 거부합니다.

  • SQL 통제

    DELETE, DROP 같은 문장 종류와 정규식 패턴으로 실행을 막습니다. 저장하기 전에 문장을 넣어 규칙을 시험합니다.

  • 승인

    접근 신청을 받아 여러 단계의 결재를 거친 뒤, 신청한 기간 동안만 접속을 허용합니다. 기간이 끝나면 세션을 끊습니다.

  • 세션 관리

    지금 열려 있는 세션을 조회하고 세션 단위나 사람 단위로 강제 종료합니다. 퇴사자의 계정을 끄면 세션도 끊깁니다.

데이터 보호

별칭과 함수 뒤에 숨은 컬럼까지 마스킹합니다

DB 가 돌려준 결과에서 민감한 값을 마스킹한 뒤 사용자에게 전달합니다. DB 와 애플리케이션은 고치지 않습니다.

SELECT name AS customer, grade, rrn, phone FROM customers WHERE id = 1024;

DB 가 돌려준 결과

customergraderrnphone
홍길동VIP900101-1234567010-1234-5678

사용자가 받는 결과

customergraderrnphone
***VIP******-*******010-1234-****
DELETE FROM customers WHERE id = 1024;

운영 DB 에서는 DELETE 문을 실행할 수 없습니다(SQL 통제).

민감 필드

이름이나 주소처럼 모양이 일정하지 않은 값에 사용합니다. customers.name 을 민감 필드로 선택하면 별칭 customer 를 붙이거나 함수로 감싸도 게이트웨이가 원본 컬럼을 따라가서(계보) 마스킹합니다.

값 패턴

주민등록번호, 카드 번호, 전화번호처럼 모양이 정해진 값은 어느 컬럼에 있든 찾아서 마스킹합니다. 개인정보와 자격 증명 패턴 12종이 들어 있고 정규식으로 직접 추가합니다.

  • 원본 컬럼을 계산하지 못한 문장은 실행하지 않고 사유와 함께 거부합니다. 마스킹해야 할 값을 놓친 채 통과시키지 않습니다.
  • 누구에게 마스킹할지는 사용자와 그룹 단위로 정합니다. 마스킹한 글자는 * 로 변경되고 길이는 그대로 남습니다.

암호화된 접속도 내용을 보고 통제합니다

클라이언트 쪽과 DB 쪽의 TLS 를 게이트웨이가 각각 맺습니다. 게이트웨이 클러스터의 인증 기관(클러스터 CA)이 인증서를 발급하고 만료 전에 자동으로 교체합니다. 내용을 볼 수 없는 접속은 기본적으로 거부합니다.

감사

누가 무엇을 했는지 사람 이름으로 남깁니다

게이트웨이가 감사 저장소에 직접 기록합니다. Management 가 멈춰도 기록은 끊기지 않습니다.

  • 기록하는 것

    세션의 시작과 끝, 실행한 문장, 허용과 거부 판정, 행 수, 마스킹한 항목, 사용자 이름과 그 이름의 출처를 기록합니다.

  • 저장소

    OpenSearch, Elasticsearch, 관계형 DB 에 기록합니다. 저장소가 응답하지 않으면 디스크에 저장했다가 다시 보냅니다.

  • 무결성

    기록을 해시 체인으로 연결하고 관리 콘솔에서 검증합니다. 중간 기록을 고치거나 지우면 드러납니다.

  • 열람 통제

    감사 화면에서도 개인정보를 마스킹해서 보여 줍니다. 원문은 권한이 있는 사람이 사유를 적고 한 건씩 열며, 열람한 사실도 기록합니다.

  • SIEM 연동

    syslog(RFC 5424)와 Splunk HEC 로 사본을 보냅니다.

지원하는 DB

2026년 10월 기준

MySQL
에이전트, 에이전트리스(서비스별 전용 포트)
MariaDB
에이전트, 에이전트리스(서비스별 전용 포트)
PostgreSQL
에이전트, 에이전트리스(공용 포트)
Oracle
에이전트, 에이전트리스(공용 포트), TLS(TCPS)
SQL Server
에이전트, 에이전트리스(공용 포트)

알려진 제약

  • Oracle 의 네이티브 네트워크 암호화(Native Network Encryption)를 사용하는 접속은 내용을 볼 수 없어 통제하지 못합니다. TLS(TCPS)로 접속하도록 구성합니다.
  • Oracle 의 OCI 방식 클라이언트로 접속한 세션은 결과를 마스킹할 수 없습니다. 이런 세션에서는 마스킹해야 할 조회를 차단합니다.
  • SQL Server 의 TDS 8.0 strict 암호화는 아직 지원하지 않습니다.
  • DB 방화벽에서 게이트웨이 외의 출발지를 닫아야 게이트웨이가 유일한 입구가 됩니다.

우리 환경에서 BeeHind 를 확인해 보십시오

보호할 DB, 서버, AI 서비스와 망 구성을 알려 주시면 맞는 구성과 도입 순서를 안내해 드립니다. 서버 한 대로 시작할 수 있습니다.

도입 문의하기자주 묻는 질문