KO
도입 문의

기업의 디지털 자산을 지키는 보안 게이트웨이

데이터베이스, AI 서비스, 서버 접근에 대한 접근 정책, 감사, 마스킹, 이상 행위 탐지를 위한 One Stop Service

도입 문의작동 방식 보기
psql — orders-db.internal:5432
BeeHindkim.dev@corp 로 확인됨
orders=> SELECT name AS customer, grade, rrn, phone FROM customers WHERE id = 1024; customer | grade | rrn            | phone         ----------+-------+----------------+--------------- ***      | VIP   | ******-******* | 010-1234-**** (1 row) · 3 개 값 마스킹 · 감사 기록됨orders=> DELETE FROM customers WHERE id = 1024;✕ BeeHind: 운영 DB 에서는 DELETE 문을 실행할 수 없습니다(SQL 통제).

보호 대상

데이터베이스
  • MySQL
  • MariaDB
  • PostgreSQL
  • Oracle
  • SQL Server
AI
  • OpenAI
  • Anthropic
  • Gemini
  • DeepSeek
  • Azure OpenAI
  • Ollama
  • vLLM
  • MCP
서버
  • SSH
  • SFTP
  • TCP 포트준비 중

모든 접속이 게이트웨이에서 거치는 네 단계

예: kim.dev@corp 의 orders-db 조회

  1. 01

    신원 확인

    공유 계정 뒤에 있는 실제 사람을 특정합니다.

    kim.dev@corp
  2. 02

    정책 판정

    접속, SQL 문장, 서버 명령, AI 요청을 규칙에 따라 허용하거나 막습니다.

    SELECT 허용
  3. 03

    결과 마스킹

    조회 결과와 프롬프트에 든 개인정보를 마스킹합니다.

    010-1234-****
  4. 04

    감사 기록

    누가 언제 무엇을 했는지 한 저장소에 남깁니다.

    1 row · 기록됨

BeeHind 란

DB, AI, 서버 접근을 통제하고 이상 행위까지 찾아내는 올인원 보안 게이트웨이

BeeHind 는 DAC(DB 접근제어), AI Gateway, Server Gateway 를 한 제품으로 제공합니다. 세 제품이 사용자와 정책, 감사 기록을 함께 사용하고, 모인 기록에서 이상 행위를 찾아냅니다.

세 제품이 하나씩만 사용

  • 사용자 목록
  • 정책 화면
  • 감사 저장소
  • 데스크톱 에이전트
  • 퇴사자 계정을 끄면 DB, 서버, AI 접속이 함께 막힙니다.
  • 같은 사람의 SQL 문장, 서버 명령, AI 질문을 한 이름으로 찾습니다.
이상 행위 탐지누가 어떤 이상 행위를 했는지 찾아냅니다.소명검토 결과월간 점검 보고서

해결하는 문제

중요한 데이터가 드나드는 길이 비어 있습니다

DB, 서버, AI 서비스는 회사의 중요한 데이터가 드나드는 곳입니다. 그런데 많은 조직에서 이 경로는 아래와 같은 상태로 남아 있습니다.

  • DB 는 계정 이름만 압니다

    여러 개발자가 app_user 같은 DB 계정 하나를 함께 사용합니다. DB 로그에는 계정 이름만 남아서 실제로 누가 접속했는지 알 수 없습니다.

    BeeHind 는 접속마다 붙는 서명된 신원 증명으로 계정 뒤의 사람을 특정합니다.

  • 누가 무엇을 조회했는지 남지 않습니다

    사고가 나거나 감사를 받으면 누가 어떤 문장을 실행했고 몇 건을 가져갔는지 답해야 합니다. DB 마다 흩어진 로그로는 답하기 어렵습니다.

    BeeHind 는 세션, 문장, 판정 결과, 행 수를 사람 이름과 함께 한 저장소에 기록합니다.

  • 개인정보가 그대로 화면에 나옵니다

    운영 DB 를 조회하면 주민등록번호와 전화번호가 그대로 보입니다. 업무에 그 값 전체가 필요한 사람은 많지 않습니다.

    BeeHind 는 결과가 사용자에게 가기 전에 민감한 값을 마스킹합니다. DB 와 애플리케이션은 고치지 않습니다.

  • 서버의 root 계정을 여럿이 함께 사용합니다

    여러 사람이 root 나 공용 계정, 같은 SSH 키로 서버에 들어갑니다. 서버의 기록에는 계정 이름만 남아서 누가 어떤 명령을 실행했는지 알 수 없습니다.

    BeeHind 는 서버 접속도 같은 게이트웨이를 지나게 해서 명령과 화면을 사람 이름으로 기록합니다.

  • 서버에서 어떤 파일이 나갔는지 모릅니다

    운영 서버의 로그와 덤프 파일은 SFTP 나 scp 로 쉽게 내려받을 수 있습니다. 누가 무엇을 가져갔는지는 남지 않습니다.

    BeeHind 는 SFTP 를 읽어 허용한 파일 기능만 넘기고, 옮긴 파일마다 감사에 남깁니다.

  • AI 도구로 무엇이 나가는지 모릅니다

    직원은 AI 도구에 소스 코드와 고객 데이터를 붙여 넣습니다. 사내 애플리케이션도 LLM API 를 직접 호출합니다.

    BeeHind 는 AI 요청도 같은 게이트웨이를 지나게 해서 규칙을 적용하고 기록합니다.

제품

하나의 제품으로 DB, AI, 서버 접근을 함께 지킵니다

세 제품이 같은 사용자 목록, 같은 정책 화면, 같은 감사 저장소, 같은 데스크톱 에이전트를 사용합니다. 주민등록번호를 찾는 규칙 하나를 DB 조회 결과와 AI 프롬프트에 함께 적용합니다.

  • DAC

    DB 접근제어

    DB 의 통신 규약을 직접 해석해서 접속, SQL 문장, 조회 결과를 통제합니다.

    • 접근 규칙과 시간, IP 제약
    • SQL 문장 종류와 패턴 통제
    • 계보 기반 결과 마스킹
    • 접근 신청과 다단계 결재
    자세히 보기

  • AI Gateway

    AI 게이트웨이

    LLM API, 직원이 사용하는 AI 앱, MCP 도구 호출을 같은 방식으로 판정하고 기록합니다.

    • 가상 키로 회사의 API 키 보호
    • 모델 제한과 사용 한도
    • 프롬프트와 답변의 값 패턴 마스킹
    • MCP 도구 허용 목록
    자세히 보기

  • Server Gateway

    서버 접근제어

    누가 어느 서버에 어느 계정으로 들어갈 수 있는지 판정하고, 접속, 실행한 명령, 주고받은 파일을 남깁니다.

    • 서버와 계정 단위 접근 규칙
    • 명령 통제와 세션 녹화
    • 파일 전송(SFTP) 통제
    • 포트 포워딩 목적지 제한
    • 보관한 키로 대신 로그인
    자세히 보기

이상 행위 탐지

세 제품의 기록은 결국 "누가 어떤 이상 행위를 했는가"로 모입니다

막고 기록하는 것으로 끝나지 않습니다. DAC, AI Gateway, Server Gateway 가 남긴 감사 기록을 사람 단위로 모아 탐지 규칙과 대조하고, 당사자의 소명과 검토 결과, 월간 점검 보고서까지 한 제품 안에서 이어 줍니다.

DACSQL 문장, 조회 결과AI Gateway프롬프트, 도구 호출Server Gateway명령, 파일 전송감사 저장소사람 이름으로 모인 기록이상 행위 탐지탐지 규칙과 대조차단된 시도민감 정보 대량 조회업무시간 외 접근신규 IP 에서 접속누가 어떤 이상 행위를 했는가사람별 검토 건소명당사자가 에이전트로 답합니다검토 결과위반, 정상 업무, 오탐월간 점검 보고서매월 1일에 지난달 보고서

기본으로 제공하는 탐지 규칙

  • 차단된 SQL 실행 시도DAC
  • 제한된 서버 명령 실행 시도Server Gateway
  • AI 에 민감 정보 전달 시도AI Gateway
  • 허용되지 않은 접속 시도DACAI GatewayServer Gateway
  • 게이트웨이에서 막힌 접속 시도공통
  • 민감 정보 잦은 조회DAC
  • 민감 정보 대량 조회DAC
  • 업무시간 외 접근DACServer Gateway
  • 신규 IP 대역에서 접속DACServer Gateway
검토 건 예시소명 대기

kim.dev@corp

행위
민감 정보 대량 조회
조건
60분 안에 1,000행 이상
목적지
orders-db (PostgreSQL)
시각
22:14, 업무시간 외
반환 행 수
1,240행

설명을 위한 예시입니다. 사람 이름과 수치는 실제 기록이 아닙니다.

이상 행위 탐지 자세히 보기

작동 방식

모든 접속이 게이트웨이를 지나갑니다

아래는 구성의 한 예입니다. 운영 DB망, 서버망, 인터넷으로 나가는 DMZ 에 게이트웨이 클러스터를 하나씩 설치하고, Management 한 대가 세 클러스터를 관리합니다. 서버 한 대에 설치한 클러스터 하나가 세 가지를 모두 맡을 수도 있습니다.

사내망인터넷운영 DB망서버망DMZManagement관리 콘솔, 정책, 계정감사 저장소OpenSearch 등, SIEM 으로 사본이상 행위 탐지서명된 정책감사 기록게이트웨이 클러스터DAC노드 3대게이트웨이 클러스터Server Gateway노드 2대게이트웨이 클러스터AI Gateway노드 2대OraclePostgreSQLMySQLweb-01web-02batch-01OpenAIAnthropicGoogle Gemini외부 AI 서비스DB 도구ssh, sftpAI 앱직원 PC데스크톱 에이전트가 서비스마다 담당 클러스터로 터널을 엽니다가상 키사내 앱, 배치가상 키로 LLM API 호출
  • 통제되는 접속
  • 정책 배포
  • 감사 기록

직원 PC 의 데스크톱 에이전트는 서비스마다 담당 클러스터로 터널을 엽니다. 각 클러스터는 Management 에서 자기가 맡은 서비스의 서명된 정책만 받고, 감사 기록은 저장소에 직접 기록합니다. 에이전트를 설치할 수 없는 앱과 배치는 발급 주소나 가상 키로 클러스터에 직접 접속합니다.

  • 통제와 감시

    게이트웨이

    DB, 서버, AI 서비스 앞에서 동작하는 프록시 서버입니다. 망마다 클러스터로 설치하고, 통제와 기록이 실제로 일어나는 곳입니다.

  • 관리

    Management

    정책과 계정을 관리하는 서버입니다. 관리자가 사용하는 관리 콘솔이 함께 들어 있습니다.

  • 신원

    데스크톱 에이전트

    직원 PC 에 설치하는 앱입니다. 접속하는 사람이 누구인지 게이트웨이에 증명합니다.

작동 방식 보기

활용 사례

작게 시작해서 전사로 넓힙니다

서버 한 대로 운영 DB 하나부터 통제하고, 망이 여러 개인 구성과 AI 서비스 통제까지 같은 제품으로 넓힙니다.

  • DB

    서버 한 대로 시작하기

    서버 한 대에 Management 와 게이트웨이를 함께 설치하고, 그 서버를 운영 DB 로 들어가는 유일한 입구로 만듭니다. 베스천 서버가 하던 역할을 BeeHind 가 맡는 것과 같습니다.

  • 서버

    서버 접속을 사람 단위로 통제하기

    서버의 SSH 를 서비스로 등록하면 누가 어느 서버에 어느 계정으로 들어갔는지, 무엇을 실행하고 어떤 파일을 주고받았는지 사람 이름으로 남습니다. 베스천 서버가 하던 일을 게이트웨이가 맡습니다.

  • AI

    직원이 사용하는 AI 앱에서 무엇이 나가는지 통제하기

    데스크톱 에이전트가 AI 서비스로 가는 접속을 게이트웨이로 보내면, DB 접속과 같은 방식으로 판정하고 마스킹하고 기록합니다. 직원은 앱의 설정을 변경하지 않습니다.

  • DB + 서버 + AI

    DB, 서버, AI 를 한곳에서 통제하기

    접속하는 쪽이 누구든, 보호 대상이 DB 든 서버든 AI 서비스든 같은 사용자 목록, 같은 정책 화면, 같은 감사 저장소를 사용합니다.

활용 사례 모두 보기

설계 원칙

모든 접속이 지나가는 제품은 그 자체가 믿을 만해야 합니다

BeeHind 의 설계는 다섯 가지 원칙을 따릅니다.

  1. 01

    DB 패스워드를 한곳에 보관하지 않습니다

    게이트웨이는 사용자의 DB 로그인을 대신하지 않고 그대로 전달합니다. 패스워드가 맞는지는 DB 가 판단합니다. 패스워드를 한곳에 보관하면 그곳이 공격 목표가 되기 때문입니다.

  2. 02

    모르면 막습니다

    해석하지 못한 문장이나 내용을 볼 수 없는 접속을 통과로 처리하지 않습니다. 마스킹해야 할 컬럼이 결과의 어느 칸에 있는지 계산하지 못하면 그 문장을 거부합니다.

  3. 03

    Management 가 멈춰도 통제는 계속됩니다

    Management 는 접속 경로에 있지 않습니다. 동작 중인 게이트웨이는 이미 받은 정책으로 판정을 계속하고, 감사 기록도 저장소에 직접 기록합니다.

  4. 04

    정책은 서명을 확인한 뒤에만 적용합니다

    Management 가 정책에 서명하고, 게이트웨이는 서명을 검증한 정책만 적용합니다. 스키마를 읽는 조회 계정의 패스워드와 AI 서비스의 API 키는 정책에 넣지 않고, 암호화해서 담당 게이트웨이에만 따로 전달합니다.

  5. 05

    감사에는 실제로 일어난 일만 적습니다

    확인하지 못한 것은 확인하지 못했다고 기록합니다. 행 수를 세지 못했으면 0 이 아니라 "알 수 없음"으로 남깁니다. 기록을 해시 체인으로 연결하므로 중간 기록을 고치면 검증할 때 드러납니다.

지원 환경

지원하는 DB, 서버, AI 서비스, 운영 환경

실행 중에 외부 네트워크를 호출하지 않으므로 폐쇄망에 반입해서 사용할 수 있습니다.

2026년 10월 기준

보호 대상 DB
MySQL, MariaDB, PostgreSQL, Oracle, SQL Server
보호 대상 AI 서비스
OpenAI 호환 API(OpenAI, Google Gemini, DeepSeek 등), Anthropic API, claude.ai 웹 앱, MCP 서버(Streamable HTTP)
AI 연결 대상
Amazon Bedrock, Google Vertex AI, Claude Platform on AWS, Microsoft Foundry, Azure OpenAI
서버 접속
SSH(접속 통제, 명령 통제와 감사, 세션 녹화와 재생, 포트 포워딩 목적지 제한), SFTP(파일 전송 통제와 파일별 감사), TCP 포트(준비 중)
데스크톱 에이전트
macOS 13.4 이상(Apple Silicon), Windows 10, Windows 11(x64)
로그인 연동
LDAP, Active Directory, OIDC, SAML 2.0, SCIM 2.0, 패스키
감사 저장소
OpenSearch, Elasticsearch, 관계형 DB(PostgreSQL, MySQL, MariaDB, Oracle)
SIEM 전달
syslog(RFC 5424), Splunk HEC
이상 행위 탐지
탐지 규칙 프리셋 9종, 사람별 검토와 소명, 월간 점검 보고서, SIEM 전달

FAQ

자주 묻는 질문

BeeHind 는 무엇인가요?

BeeHind 는 DB 접근제어(DAC), AI 게이트웨이(AI Gateway), 서버 접근제어(Server Gateway)를 하나로 처리하는 보안 게이트웨이입니다. 사람과 애플리케이션이 데이터베이스, AI 서비스, 서버로 가는 접속이 게이트웨이를 지나는 동안 신원을 확인하고, 정책으로 허용하거나 막고, 개인정보를 마스킹하고, 감사를 기록합니다. 게이트웨이, Management, 데스크톱 에이전트로 이루어집니다.

기존 DB 접근제어 제품과 무엇이 다른가요?

세 가지가 다릅니다. 첫째, 컨테이너로 설치하는 구조로 만들어서 망마다 게이트웨이 클러스터를 설치하고 Management 한 대로 전체를 관리합니다. 둘째, 조회 결과의 각 항목이 어느 원본 컬럼에서 왔는지 계산해서(계보) 별칭이나 함수 뒤에 숨은 민감 컬럼까지 마스킹합니다. 셋째, DB 접근제어, AI 게이트웨이, 서버 접근제어를 한 제품으로 제공해서 사용자 목록, 정책 화면, 감사 저장소, 데스크톱 에이전트를 하나씩만 운영합니다.

누가 어떤 이상 행위를 했는지도 알 수 있나요?

네. Management 가 DAC, AI Gateway, Server Gateway 의 감사 기록을 탐지 규칙과 대조해, 차단된 시도, 민감 정보 대량 조회, 업무시간 외 접근, 신규 IP 접속 같은 행위를 사람별 검토 건으로 묶습니다. 검토자는 당사자에게 소명을 요청하고 검토 결과를 남기며, 매월 1일에 지난달의 월간 점검 보고서가 만들어집니다.

게이트웨이가 DB 패스워드를 보관하나요?

사용자의 DB 패스워드는 보관하지 않습니다. 게이트웨이는 DB 로그인을 대신하지 않고 클라이언트와 DB 사이에서 그대로 전달합니다(인증 중계). 패스워드가 맞는지는 DB 가 판단합니다. 선택적으로 테이블 컬럼별 마스킹을 설정하기 위해서는 조회 계정을 등록할 수 있습니다. 관리자가 등록한 이 계정의 패스워드는 암호화해서 보관하고 담당 게이트웨이에만 전달합니다.

서버 접속(SSH, SFTP)도 통제하나요?

네. 서버의 SSH 포트를 서비스로 등록하면 누가 어느 서버에 어느 계정으로 들어갈 수 있는지 판정하고, 접속과 실행한 명령을 감사에 남깁니다. 세션의 화면을 녹화해 관리 콘솔에서 재생하고, 게이트웨이가 보관한 패스워드나 SSH 키로 서버에 대신 로그인할 수 있습니다. SFTP 로 주고받는 파일은 업로드, 다운로드, 파일 변경 중 허용한 것만 넘기고 파일마다 감사에 남깁니다. 포트 포워딩은 사용자별로 허용한 목적지(호스트와 포트)로만 엽니다.

직원의 AI 사용은 어떻게 통제하나요?

데스크톱 에이전트가 AI 서비스로 가는 접속을 게이트웨이로 보내면, 게이트웨이가 요청을 읽어 사용자와 모델을 확인하고 프롬프트의 개인정보와 자격 증명을 값 패턴으로 검사합니다. 패턴마다 차단, 마스킹, 감지만 중에서 선택합니다. OpenAI 호환 API, Anthropic API, claude.ai 웹 앱의 내용을 읽습니다.

질문 모두 보기

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

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

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