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

> BeeHind 는 DB 접근제어(DAC), AI 게이트웨이, 서버 접근제어를 하나로 처리하는 보안 게이트웨이입니다. 공유 계정 뒤의 사람을 특정하고, SQL 과 서버 명령과 AI 요청을 정책으로 판정하고, 개인정보를 마스킹하고, 누가 어떤 이상 행위를 했는지 찾아냅니다.

https://beehind.me/ko · Unvus Co., Ltd. · contact@unvus.com · 2026-11-09

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

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

- **DAC**: DB 접근제어
- **AI Gateway**: AI 게이트웨이
- **Server Gateway**: 서버 접근제어

세 제품이 하나씩만 사용: 사용자 목록, 정책 화면, 감사 저장소, 데스크톱 에이전트
- 퇴사자 계정을 끄면 DB, 서버, AI 접속이 함께 막힙니다.
- 같은 사람의 SQL 문장, 서버 명령, AI 질문을 한 이름으로 찾습니다.

모든 접속이 게이트웨이에서 거치는 네 단계:
- **신원 확인**: 공유 계정 뒤에 있는 실제 사람을 특정합니다.
- **정책 판정**: 접속, SQL 문장, 서버 명령, 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 접근제어**: DB 의 통신 규약을 직접 해석해서 접속, SQL 문장, 조회 결과를 통제합니다. (접근 규칙과 시간, IP 제약, SQL 문장 종류와 패턴 통제, 계보 기반 결과 마스킹, 접근 신청과 다단계 결재)
- **AI 게이트웨이**: LLM API, 직원이 사용하는 AI 앱, MCP 도구 호출을 같은 방식으로 판정하고 기록합니다. (가상 키로 회사의 API 키 보호, 모델 제한과 사용 한도, 프롬프트와 답변의 값 패턴 마스킹, MCP 도구 허용 목록)
- **서버 접근제어**: 누가 어느 서버에 어느 계정으로 들어갈 수 있는지 판정하고, 접속, 실행한 명령, 주고받은 파일을 남깁니다. (서버와 계정 단위 접근 규칙, 명령 통제와 세션 녹화, 파일 전송(SFTP) 통제, 포트 포워딩 목적지 제한, 보관한 키로 대신 로그인)

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

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

## DB 를 깊이 이해하는 보안 게이트웨이 (https://beehind.me/ko/dac)

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

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

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

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

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

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

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

- **접근 규칙**: 사용자나 그룹, 서비스, DB 계정의 조합마다 허용, 거부, 승인 필요 중 하나를 정합니다.
- **접속 제약**: 접속할 수 있는 IP 대역과 요일, 시간대를 정합니다. 허용된 시간이 지나면 열려 있는 세션도 끊습니다.
- **DB 계정 통제**: 서비스마다 사용할 수 있는 DB 계정을 정하고, 그 밖의 계정은 DB 에 닿기 전에 거부합니다.
- **SQL 통제**: DELETE, DROP 같은 문장 종류와 정규식 패턴으로 실행을 막습니다. 저장하기 전에 문장을 넣어 규칙을 시험합니다.
- **승인**: 접근 신청을 받아 여러 단계의 결재를 거친 뒤, 신청한 기간 동안만 접속을 허용합니다. 기간이 끝나면 세션을 끊습니다.
- **세션 관리**: 지금 열려 있는 세션을 조회하고 세션 단위나 사람 단위로 강제 종료합니다. 퇴사자의 계정을 끄면 세션도 끊깁니다.

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

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

- **민감 필드**: 이름이나 주소처럼 모양이 일정하지 않은 값에 사용합니다. customers.name 을 민감 필드로 선택하면 별칭 customer 를 붙이거나 함수로 감싸도 게이트웨이가 원본 컬럼을 따라가서(계보) 마스킹합니다.
- **값 패턴**: 주민등록번호, 카드 번호, 전화번호처럼 모양이 정해진 값은 어느 컬럼에 있든 찾아서 마스킹합니다. 개인정보와 자격 증명 패턴 12종이 들어 있고 정규식으로 직접 추가합니다.
- 원본 컬럼을 계산하지 못한 문장은 실행하지 않고 사유와 함께 거부합니다. 마스킹해야 할 값을 놓친 채 통과시키지 않습니다.
- 누구에게 마스킹할지는 사용자와 그룹 단위로 정합니다. 마스킹한 글자는 * 로 변경되고 길이는 그대로 남습니다.

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

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

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

- **기록하는 것**: 세션의 시작과 끝, 실행한 문장, 허용과 거부 판정, 행 수, 마스킹한 항목, 사용자 이름과 그 이름의 출처를 기록합니다.
- **저장소**: OpenSearch, Elasticsearch, 관계형 DB 에 기록합니다. 저장소가 응답하지 않으면 디스크에 저장했다가 다시 보냅니다.
- **무결성**: 기록을 해시 체인으로 연결하고 관리 콘솔에서 검증합니다. 중간 기록을 고치거나 지우면 드러납니다.
- **열람 통제**: 감사 화면에서도 개인정보를 마스킹해서 보여 줍니다. 원문은 권한이 있는 사람이 사유를 적고 한 건씩 열며, 열람한 사실도 기록합니다.
- **SIEM 연동**: syslog(RFC 5424)와 Splunk HEC 로 사본을 보냅니다.

### 지원하는 DB

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

### 알려진 제약

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

## AI 로 나가는 데이터도 같은 게이트웨이에서 통제합니다 (https://beehind.me/ko/ai-gateway)

직원이 사용하는 AI 앱, 사내 앱과 개발 도구의 LLM API 호출, AI 가 호출하는 MCP 도구까지 게이트웨이가 판정하고 마스킹하고 기록합니다. DB 에 적용하는 값 패턴을 AI 요청에 그대로 사용합니다.

AI 게이트웨이는 조직과 AI 서비스 사이에서 요청을 검사하고, 키를 관리하고, 사용량을 기록하는 프록시입니다.

BeeHind 의 AI Gateway 는 DAC, Server Gateway 와 같은 게이트웨이, 같은 계정, 같은 감사 저장소를 사용합니다. 같은 사람이 실행한 SQL 문장, 서버 명령, AI 에 보낸 질문을 같은 이름으로 찾습니다.

### AI 를 사용하는 방식마다 맞는 통제

- **직원이 사용하는 AI 앱** — 직원이 PC 에서 계정으로 로그인해 사용하는 AI 앱(예: Claude 데스크톱 앱). 데스크톱 에이전트가 AI 서비스로 가는 접속을 게이트웨이로 보냅니다. 직원은 앱의 설정을 변경하지 않습니다. (누구인지 아는 방법: 서명된 신원 증명)
- **사내 앱과 개발 도구의 LLM 호출** — LLM API 를 호출하는 사내 서비스와 배치, Claude Code, Codex, Gemini CLI. API 주소를 게이트웨이로, API 키를 가상 키로 변경합니다. 게이트웨이가 회사의 실제 키(조직 키)로 교체해 보냅니다. (누구인지 아는 방법: 가상 키)
- **AI 가 호출하는 사내 도구(MCP)** — 사내 시스템을 MCP 서버로 제공하는 조직. MCP 서버를 서비스로 등록하고 도구 호출 단위로 허용 목록을 정합니다. 인자에 든 값도 값 패턴으로 검사합니다. (누구인지 아는 방법: 서명된 신원 증명)

### AI 사용을 통제하는 기능

- **가상 키**: 회사의 실제 API 키는 게이트웨이만 사용하고, 사용자와 애플리케이션에는 가상 키를 발급합니다. 가상 키는 하나씩 폐기합니다.
- **모델 제한**: 토큰 단가가 상한을 넘는 모델과 사용하지 않기로 한 모델을 막습니다. 사용자와 그룹마다 사용할 수 있는 모델을 정합니다.
- **내용 검사**: 프롬프트와 스트리밍 답변에 값 패턴을 적용합니다. AWS 액세스 키, 개인키, DB 접속 문자열 같은 자격 증명 패턴이 기본으로 들어 있습니다.
- **사용 한도**: 사용자와 서비스별로 하루 또는 한 달의 토큰 수와 요청 수를 제한합니다.
- **도구 통제**: MCP 서버의 도구 호출을 허용 목록으로 제한하고, 인자를 값 패턴으로 검사합니다.
- **연결 대상 변환**: Amazon Bedrock, Google Vertex AI 같은 클라우드의 모델 서비스로 보낼 때 요청 형식을 변경해 줍니다. 연결 대상을 옮겨도 애플리케이션의 설정은 그대로입니다.
- **사내 모델 서버**: vLLM, Ollama 같은 사내 모델 서버도 OpenAI 호환 서비스로 등록해 같은 규칙으로 검사합니다.
- **도구별 설정 파일**: 관리 콘솔이 Claude Code, Codex, Gemini CLI, SDK 의 설정 파일을 만들어 줍니다.

### 지원하는 AI 서비스

- 내용을 읽고 통제: OpenAI 호환 API(OpenAI, Google Gemini, DeepSeek 등), Anthropic API, claude.ai 웹 앱, MCP 서버(Streamable HTTP)
- 연결 대상: Amazon Bedrock, Google Vertex AI, Claude Platform on AWS, Microsoft Foundry, Azure OpenAI
- 사내 모델 서버: vLLM, Ollama 등 OpenAI 호환 서버
- 개발 도구: Claude Code, Codex, Gemini CLI, SDK

### 알려진 제약

- 목록 밖의 서비스와 인증서를 고정한 앱은 내용을 읽지 못하고 접속한 사실만 기록합니다.
- PC 에서 AI 서비스로 직접 나가는 길이 열려 있으면 에이전트를 끄고 우회할 수 있습니다. 방화벽에서 그 길을 닫습니다.
- 사용 한도는 몇 초 간격으로 집계하므로 그 사이의 초과분은 통과합니다. 비용을 관리하는 장치이고 보안 통제가 아닙니다.
- MCP 도구가 돌려준 결과에는 아직 마스킹을 적용하지 않습니다.

## 서버에서 누가 무엇을 했는지 사람 이름으로 남깁니다 (https://beehind.me/ko/server-gateway)

게이트웨이가 SSH 를 양쪽에서 종단해서 누가, 어느 서버에, 어느 계정으로 들어가는지 판정하고, 실행한 명령과 주고받은 파일을 통제하고, 세션의 화면을 녹화합니다. 사용자는 평소처럼 ssh 와 sftp 를 사용합니다.

Server Gateway 는 사람이 서버에 SSH 로 접속하는 경로에서 동작하는 서버 접근제어 게이트웨이입니다. 베스천 서버(점프 서버)가 하던 일을 맡으면서, 접속한 사람과 그 사람이 한 일을 함께 기록합니다.

BeeHind 는 SSH 를 양쪽에서 종단합니다. 사용자의 SSH 를 게이트웨이가 받고, 대상 서버에는 게이트웨이가 따로 접속합니다. 그래서 암호화된 SSH 안의 명령, 파일 전송, 포트 포워딩을 읽고 판정합니다. 대상 서버에는 프로그램을 설치하지 않습니다.

DAC, AI Gateway 와 같은 사용자 목록, 같은 정책 화면, 같은 감사 저장소를 사용합니다.

### 서버 계정마다 로그인 방식을 선택합니다

| 방식 | 사용자가 하는 일 | 게이트웨이가 하는 일 | 대상 서버에 할 일 |
| --- | --- | --- | --- |
| 사용자 입력 | 서버 계정의 패스워드를 입력합니다 | 입력한 것을 대상 서버에 그대로 전달하고 보관하지 않습니다 | 없음 |
| 보관한 패스워드 | 없음 | 보관한 패스워드로 대신 로그인합니다 | 없음 |
| 보관한 SSH 키 | 없음 | 보관한 SSH 키로 대신 로그인합니다 | 계정마다 공개키를 authorized_keys 에 넣습니다 |
| 인증서 | 없음 | 접속마다 단기 인증서를 만들어 대신 로그인합니다 | 서버마다 한 번, 클러스터의 사용자 CA 를 신뢰하도록 설정합니다 |
서버에 들어가는 길은 데스크톱 에이전트의 터널입니다. 서버 접속용 포트를 따로 열지 않고, 사용자는 실제 서버 주소와 서버 계정으로 ssh 를 실행합니다.

### 접속부터 명령, 파일까지 판정합니다

- **접근 규칙**: 사용자나 그룹, 서버, 서버 계정의 조합마다 접속을 허용하거나 거부합니다. 접속할 수 있는 IP 대역과 시간대도 정합니다.
- **명령 통제**: 명령 템플릿으로 막을 명령이나 허용할 명령을 정합니다. ssh 서버 명령 으로 실행하는 명령과 대화형 쉘에 입력한 명령을 모두 판정합니다.
- **승인받아 사용하는 명령**: 서비스 재시작이나 sudo 처럼 작업할 때만 필요한 명령은 평소에 막고, 명령 권한을 승인받은 동안만 실행하게 합니다.
- **파일 통제**: SFTP 를 읽어 업로드, 다운로드, 파일 변경 중 허용한 기능만 넘깁니다. scp 와 rsync 도 같은 규칙으로 판정하고, 옮긴 파일마다 감사에 남깁니다.
- **포트 포워딩**: ssh -L, ssh -D 로 여는 포워딩을 사용자별로 허용한 목적지(호스트와 포트)로만 넘깁니다. 기본은 꺼져 있고, 되돌아오는 포워딩(ssh -R)은 거부합니다.
- **세션 녹화**: 세션의 화면을 녹화해 관리 콘솔에서 재생합니다. 사용자가 입력한 글자는 저장하지 않으므로 패스워드가 녹화에 남지 않습니다.
- **세션 관리**: 열려 있는 세션을 강제로 종료합니다. 접근 규칙을 회수하면 열려 있는 세션도 끊기고, 유휴 시간과 최대 세션 시간을 정할 수 있습니다.
- **호스트 키 확인**: 대상 서버의 호스트 키를 등록할 때 확정하고 접속마다 대조합니다. 에이전트가 PC 에 클러스터의 호스트 CA 를 등록하므로 사용자는 지문 확인 질문을 받지 않습니다.

### 지원 범위

- 접속 경로: 데스크톱 에이전트(macOS, Windows)의 터널
- 확인한 도구: OpenSSH 의 ssh, sftp, scp, rsync
- 로그인 방식: 사용자 입력, 보관한 패스워드, 보관한 SSH 키, 인증서
- 파일 전송: SFTP(버전 3), scp, rsync
- 감사: 접속, 명령, 파일 전송, 포트 포워딩, 세션 녹화
- 녹화 저장소: S3 호환 저장소
- TCP 포트(준비 중): SSH 를 거치지 않는 서버의 포트(예: 웹 관리 화면, Redis, RDP)를 사용자별로 허용하고 접속 기록을 남기는 기능을 준비하고 있습니다. 연결의 내용은 해석하지 않습니다.

### 알려진 제약

- 대화형 쉘에 입력한 명령은 화면에 그려진 줄을 읽어 판정합니다. ssh 서버 명령 으로 실행하는 명령과 달리 추정입니다.
- 차단 방식의 명령 템플릿만으로는 쉘을 거쳐 파일이 드나드는 것을 막지 못합니다.
- 포워딩한 연결의 내용은 보지 않습니다. 그 연결로 DB 에 접속하면 SQL 이 감사에 남지 않으므로, DB 는 DAC 의 서비스로 등록합니다.
- 화면에 나온 시크릿은 녹화에 그대로 남습니다.
- 에이전트 없는 접속, 웹 터미널, RDP, Telnet, FTP 는 아직 지원하지 않습니다.

## 누가 어떤 이상 행위를 했는지 찾아내고 소명까지 받습니다 (https://beehind.me/ko/anomaly-detection)

세 제품의 감사 기록을 사람 단위로 모아 탐지 규칙과 대조합니다. 걸린 행위는 사람별 검토 건이 되고, 당사자의 소명과 검토자의 검토 결과를 거쳐 월간 점검 보고서로 남습니다.

이상 행위 탐지는 감사 기록에서 정책을 어긴 행위나 평소와 다른 행위를 찾아 사람별로 묶고, 검토자가 결론을 내게 하는 기능입니다.

Management 가 감사 저장소를 10초마다 읽어 켜진 탐지 규칙과 대조합니다. DAC 의 SQL 문장과 조회 결과, Server Gateway 의 명령과 파일 전송, AI Gateway 의 프롬프트가 모두 같은 사람 이름으로 남아 있으므로, 한 사람이 DB, 서버, AI 서비스에서 한 일을 함께 봅니다.

탐지에서 끝나지 않고 당사자에게 이유를 묻는 소명, 검토자의 검토 결과, 정상 업무로 확인한 행위의 예외, 한 달의 점검을 모은 월간 점검 보고서까지 이어집니다. 별도의 분석 제품을 연결하지 않아도 됩니다.

### 프리셋 아홉 개로 시작합니다

규칙은 프리셋을 복사해 시작하고, 범위(목적지, 사람, 그룹), 횟수, 중요도, 자동 소명 요청을 정합니다. 모든 값은 목록에서 선택하므로 오타 하나로 규칙이 조용히 꺼지지 않습니다.

| 탐지 규칙 | 제품 | 기본 조건 | 중요도 |
| --- | --- | --- | --- |
| 차단된 SQL 실행 시도 | DAC | 한 건마다 | 보통 |
| 제한된 서버 명령 실행 시도 | Server Gateway | 한 건마다 | 보통 |
| AI 에 민감 정보 전달 시도 | AI Gateway | 한 건마다 | 높음 |
| 허용되지 않은 접속 시도 | DAC, AI Gateway, Server Gateway | 60분 안에 3건 이상 | 보통 |
| 게이트웨이에서 막힌 접속 시도 | 공통 | 60분 안에 3건 이상 | 보통 |
| 민감 정보 잦은 조회 | DAC | 60분 안에 100건 이상 | 보통 |
| 민감 정보 대량 조회 | DAC | 60분 안에 1,000행 이상 | 높음 |
| 업무시간 외 접근 | DAC, Server Gateway | 한 건마다 | 보통 |
| 신규 IP 대역에서 접속 | DAC, Server Gateway | 한 건마다(사람마다 14일 학습 뒤) | 보통 |
프리셋은 모두 검토 건이 생기면 당사자에게 소명을 자동으로 요청합니다. 규칙은 켠 뒤에 발생한 기록에만 적용하고, 업무시간과 공휴일, 출발지 학습 기간은 탐지 설정에서 정합니다.

### 탐지한 행위마다 결론을 남깁니다

- **검토 건**: 같은 규칙, 같은 사람, 같은 목적지, 같은 날의 탐지 기록을 한 건으로 묶습니다. 감사 원문(SQL, 프롬프트)은 복사하지 않고 요약만 남깁니다.
- **소명 요청**: 당사자에게 그 행위를 왜 했는지 묻습니다. 당사자에게는 "이상 행위" 라는 말 대신 "소명 요청" 으로 보입니다.
- **소명**: 당사자는 데스크톱 에이전트에서 자신이 실행한 문장을 보고, 분류(업무 수행, 테스트, 실수, 지시나 승인, 내가 하지 않음 등)와 설명을 적어 답합니다.
- **소명 승인**: 사용하도록 설정하면 당사자의 소명 승인자가 에이전트에서 소명을 확인합니다. 확인은 근거이고 결론은 검토자가 냅니다.
- **검토 결과**: 위반, 정상 업무, 오탐(규칙 문제), 오탐(데이터 문제), 판단 불가 중에서 선택하고 의견을 적습니다. 위반이면 취한 조치를 함께 남깁니다.
- **예외**: 정상 업무로 확인한 행위는 범위와 만료일을 정해 그때까지 다시 탐지하지 않습니다.

### 월간 점검 보고서

매월 1일에 지난달의 탐지, 검토, 소명, 예외를 모은 보고서를 만듭니다. 「개인정보의 안전성 확보조치 기준」 제8조 제2항이 요구하는 월 1회 이상의 접속기록 점검을 했다는 근거로 남깁니다. 보고서는 고치지 않고, 다시 만들면 새 보고서가 생깁니다.

- 탐지: 검토 건 수, 사람 수, 규칙별과 중요도별 수
- 검토: 결과별 수와 위반으로 검토한 건의 조치
- 소명: 요청, 제출, 늦은 제출, 본인 부인, 미제출
- 예외: 새로 만든 것, 해제한 것, 적용 중인 것
- 점검하지 못한 구간: 검증하지 못한 감사 기록과 체인 단절

### 함께 동작하는 것

- 읽는 기록: DAC, AI Gateway, Server Gateway 의 감사 기록(OpenSearch, Elasticsearch, 관계형 DB)
- 소명 답변: 데스크톱 에이전트(macOS, Windows)
- SIEM 전달: 검토 건의 생성, 소명 제출, 소명 승인, 검토 결과, 다시 열기(syslog, Splunk HEC)
- 이력: 규칙, 검토, 소명, 예외의 모든 변경을 체인으로 봉인하고 하루 한 번 검증합니다
- 알림: 당사자가 "내가 하지 않음" 으로 답하면 검토자에게 바로 메일을 보냅니다

### 알려진 제약

- 규칙은 켠 뒤에 발생한 기록에만 적용합니다. 지난 기록을 소급해 탐지하지 않습니다.
- 원문 조회 기록을 끈 서비스에서는 마스킹하지 않은 민감 필드 조회가 기록되지 않아 탐지되지 않습니다.
- 업무시간 외 접근과 신규 IP 접속은 계정이 있는 사람의 기록만 봅니다.
- 에이전트 없이 접속한 기록(발급 주소, 가상 키)은 자동으로 소명을 요청하지 않습니다. 검토자가 직접 요청할 수는 있습니다.
- 소명은 최근 90일 안에 데스크톱 에이전트로 로그인한 사람에게만 요청할 수 있습니다.

## 세 구성요소가 모든 접속을 통제하고 기록합니다 (https://beehind.me/ko/how-it-works)

게이트웨이가 통제와 기록을 하고, Management 가 정책을 정해 내려보내고, 데스크톱 에이전트가 접속하는 사람을 증명합니다. Management 는 접속 경로에 있지 않습니다.

### 게이트웨이

DB, 서버, AI 서비스 앞에서 동작하는 프록시 서버입니다. 통제와 기록이 실제로 일어나는 곳입니다.

- DB 의 통신 규약을 직접 해석해서 접속, SQL 문장, 조회 결과를 읽습니다.
- SSH 를 양쪽에서 종단해서 서버 명령과 파일 전송을 읽습니다.
- 접속, 문장, 명령, AI 요청을 정책에 따라 허용하거나 막습니다.
- 조회 결과와 AI 요청의 민감한 값을 마스킹합니다.
- 감사 기록을 저장소에 직접 기록합니다.
- 위치: 보호할 DB 와 서버가 있는 망, AI 서비스로 나가는 출구. 망마다 클러스터를 만들고 필요한 만큼 여러 대에 설치하여 실행합니다.

### Management

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

- 사용자와 그룹을 관리하고 사내 인증 시스템과 연동합니다.
- 보호할 서비스를 등록하고 접근 규칙, 마스킹, SQL 통제를 정의합니다.
- 정책에 서명해서 담당 게이트웨이에 배포합니다.
- 접근 신청의 결재를 진행하고 감사 기록을 보여 줍니다.
- 감사 기록에서 이상 행위를 탐지하고 소명과 검토를 진행합니다.
- 위치: 한 대. 게이트웨이와 에이전트가 접속할 수 있는 곳에 설치합니다.

### 데스크톱 에이전트

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

- 회사 계정으로 로그인하고 서명된 신원 증명을 받습니다.
- 등록된 서비스로 가는 접속만 가로채서 담당 게이트웨이로 보냅니다.
- 접속마다 신원 증명을 붙여 DB 계정을 함께 사용해도 사람을 구분합니다.
- 접속할 수 있는 서비스 목록을 보여 주고 접근 신청을 받습니다.
- 위치: 직원 PC. macOS 와 Windows 를 지원합니다.

### 접속 한 번이 처리되는 과정

1. **로그인**: 사용자가 데스크톱 에이전트에 회사 계정으로 로그인합니다. Management 는 접속할 수 있는 서비스 목록과 서명된 신원 증명을 내려줍니다.
2. **접속 시도**: 사용자가 DB 도구에 실제 DB 주소와 DB 계정을 넣고 접속합니다. 에이전트는 등록된 서비스로 가는 접속만 가로챕니다.
3. **터널**: 에이전트가 담당 게이트웨이로 상호 TLS(mTLS) 터널을 열고, 맨 앞에 신원 증명과 원래 목적지를 실어 보냅니다.
4. **접속 판정**: 게이트웨이가 이 사람이 이 서비스에 이 DB 계정으로 접속해도 되는지, 위치와 시간대까지 판정합니다. 허용되지 않으면 DB 에 닿기 전에 끊습니다.
5. **로그인 중계**: 게이트웨이가 DB 에 연결하고 로그인 과정을 그대로 전달합니다. 패스워드가 맞는지는 DB 가 판단합니다.
6. **SQL 통제**: 문장을 실행할 때마다 금지된 종류의 문장인지 확인합니다.
7. **결과 마스킹**: DB 가 돌려준 결과에서 민감한 값을 마스킹한 뒤 사용자에게 전달합니다.
8. **감사 기록**: 세션, 문장, 판정 결과, 행 수를 사용자 이름과 함께 감사 저장소에 기록합니다.

접속이 유지되는 동안에도 게이트웨이는 주기적으로 다시 판정합니다. 허용된 시간이 지나거나 정책이 변경되면 열려 있는 세션을 끊습니다.

### 서버 한 대에서 여러 망의 클러스터까지

- **서버 한 대(Docker Compose)** (제공): Management, 게이트웨이, PostgreSQL, Caddy 를 호스트 한 대에 설치합니다. 설치 스크립트가 설치, 버전 변경, 되돌리기를 맡습니다. 폐쇄망에는 한 묶음으로 반입합니다.
- **게이트웨이를 Linux VM 에(systemd)** (제공): 컨테이너 없이 게이트웨이 노드를 VM 에 설치합니다. 관리 콘솔에서 교체를 지시하면 노드가 새 버전을 받아 스스로 교체합니다.
- **Kubernetes(Helm), AWS, Azure** (준비 중): 설치 템플릿을 실제 환경에 배포할 수 있도록 마무리하고 있습니다.

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

- **DB 패스워드를 한곳에 보관하지 않습니다**: 게이트웨이는 사용자의 DB 로그인을 대신하지 않고 그대로 전달합니다. 패스워드가 맞는지는 DB 가 판단합니다. 패스워드를 한곳에 보관하면 그곳이 공격 목표가 되기 때문입니다.
- **모르면 막습니다**: 해석하지 못한 문장이나 내용을 볼 수 없는 접속을 통과로 처리하지 않습니다. 마스킹해야 할 컬럼이 결과의 어느 칸에 있는지 계산하지 못하면 그 문장을 거부합니다.
- **Management 가 멈춰도 통제는 계속됩니다**: Management 는 접속 경로에 있지 않습니다. 동작 중인 게이트웨이는 이미 받은 정책으로 판정을 계속하고, 감사 기록도 저장소에 직접 기록합니다.
- **정책은 서명을 확인한 뒤에만 적용합니다**: Management 가 정책에 서명하고, 게이트웨이는 서명을 검증한 정책만 적용합니다. 스키마를 읽는 조회 계정의 패스워드와 AI 서비스의 API 키는 정책에 넣지 않고, 암호화해서 담당 게이트웨이에만 따로 전달합니다.
- **감사에는 실제로 일어난 일만 적습니다**: 확인하지 못한 것은 확인하지 못했다고 기록합니다. 행 수를 세지 못했으면 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 전달

### 자주 나오는 용어

- **게이트웨이 클러스터** (gateway cluster): 같은 서비스를 함께 맡는 게이트웨이 노드의 묶음입니다. 망마다 클러스터를 만들고, 서비스마다 담당 클러스터를 정합니다.
- **인터셉트** (interception): 데스크톱 에이전트가 등록된 서비스로 가는 접속을 PC 안에서 가로채 게이트웨이로 보내는 것입니다. 사용자는 접속 주소를 변경하지 않습니다.
- **에이전트리스** (agentless): 에이전트 없이 발급받은 접속 주소로 게이트웨이에 직접 접속하는 경로입니다. 협력사 PC, BI 도구, 배치 서버가 사용합니다.
- **신원 증명** (assertion): Management 가 로그인한 사용자에게 서명해서 내주는 짧은 수명의 증명입니다. 게이트웨이가 서명을 확인해 사람을 특정합니다.
- **인증 중계** (authentication relay): 게이트웨이가 DB 로그인을 대신하지 않고 클라이언트와 DB 사이에서 그대로 전달하는 것입니다. 패스워드는 DB 가 확인합니다.
- **대리 로그인** (credential injection): 게이트웨이가 보관한 패스워드나 SSH 키, 또는 접속마다 만든 인증서로 대상 서버에 대신 로그인하는 것입니다. 사용자는 서버의 패스워드를 몰라도 됩니다.
- **TLS 종단** (TLS termination): 암호화된 접속을 게이트웨이가 풀어서 내용을 확인한 뒤 다시 암호화해 DB 로 보내는 것입니다.
- **계보** (lineage): 조회 결과의 각 항목이 어느 원본 컬럼에서 왔는지를 계산한 것입니다. 별칭이나 함수 뒤에 숨은 민감 필드를 찾는 근거입니다.
- **값 패턴** (value pattern): 주민등록번호, 카드 번호처럼 모양이 정해진 값을 찾는 규칙입니다. DB 결과와 AI 요청에 함께 사용합니다.
- **가상 키** (virtual key): BeeHind 가 사용자와 애플리케이션에 발급하는 키입니다. 게이트웨이가 요청을 보낼 때 회사의 실제 키(조직 키)로 교체합니다.
- **fail-closed**: 판단할 수 없을 때 허용하지 않고 거부하는 방식입니다. "모르면 막는다"는 원칙의 다른 이름입니다.

## 작은 구성에서 시작해 전사 구성까지 (https://beehind.me/ko/use-cases)

### 1. 서버 한 대로 시작하기

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

서버 한 대에 Management, 게이트웨이, 감사 저장소를 함께 설치한 구성입니다. 직원 PC 의 에이전트가 mTLS 터널로 게이트웨이에 접속하고, 게이트웨이가 사내망의 운영 DB 로 접속을 중계합니다. PC 에서 DB 로 직접 가는 길은 방화벽에서 닫습니다.

- 이런 상황에 사용합니다: 보호할 DB 가 한 망에 모여 있는 팀, 작게 도입해서 먼저 사용해 보려는 경우
- 얻는 것: 운영 DB 에 누가 언제 어떤 문장을 실행했는지 사람 이름으로 남습니다. 마스킹, SQL 통제, 접근 규칙을 바로 적용합니다. 개발자에게 베스천 서버의 SSH 계정을 나눠 주지 않아도 됩니다.
- 참고할 점: DB 방화벽에서 다른 출발지를 닫아야 게이트웨이가 유일한 입구가 됩니다. 장애 때 사용할 비상 접속 경로를 미리 정합니다.

### 2. 에이전트를 설치할 수 없는 곳에서 접속하기

협력사 PC, BI 도구, 배치 서버는 관리자가 발급한 접속 주소로 게이트웨이에 직접 접속합니다. 에이전트가 없는 접속에도 같은 정책과 감사가 적용됩니다.

협력사 PC, BI 도구, 배치 서버가 발급받은 접속 주소로 게이트웨이에 직접 접속합니다. 게이트웨이는 출발지 대역을 확인하고 정책으로 판정한 뒤 운영 DB 로 접속을 중계합니다.

- 이런 상황에 사용합니다: 협력사 PC, 프로그램 설치가 막힌 PC, Tableau 나 Redash 같은 BI 도구, 배치 서버
- 얻는 것: 사람을 더해도 방화벽을 다시 열 필요가 없습니다. 주소를 폐기하면 그 주소로는 곧바로 접속할 수 없습니다.
- 참고할 점: 발급 대상은 감사에 남는 이름이고 본인 확인이 아닙니다. 실제로 접속을 제한하는 것은 허용 대역입니다. 사람을 정확히 구분해야 하는 접속에는 에이전트를 사용합니다.

### 3. 운영 DB 의 개인정보를 안전하게 다루기

외주 개발자의 운영 DB 접속을 평소에는 막고, 승인을 받은 기간에만 열어 줍니다. 열려 있는 동안에도 개인정보는 마스킹하고 데이터를 변경하는 문장은 막습니다.

외주 개발자의 접근 신청을 결재자가 승인하면 Management 가 기간 한정 정책을 게이트웨이에 보냅니다. 게이트웨이는 기간을 확인하고 SQL 을 통제하고 결과를 마스킹한 뒤 운영 DB 로 접속을 중계합니다.

- 이런 상황에 사용합니다: 외주 인력과 운영 지원 인력의 운영 DB 조회, 개인정보가 든 테이블이 있는 DB 전반
- 얻는 것: 필요한 사람에게 필요한 기간만 접속을 허용합니다. 조회 결과의 개인정보는 마스킹되고 모든 문장이 기록됩니다.
- 참고할 점: 기간 만료는 게이트웨이가 스스로 확인합니다. Management 가 멈춰 있어도 세션이 끊깁니다.

### 4. 망이 여러 개인 기업에서 게이트웨이를 나눠 설치하기

본사 전산실, 클라우드, 개발망처럼 DB 가 흩어져 있으면 망마다 게이트웨이 클러스터를 설치하고 Management 한 대가 전체를 관리합니다.

본사 전산실, 클라우드, 개발망에 게이트웨이 클러스터를 하나씩 설치하고 Management 한 대가 관리합니다. 직원 PC 의 에이전트는 서비스마다 담당 클러스터로 터널을 열고, 각 클러스터는 감사 저장소에 직접 기록합니다.

- 이런 상황에 사용합니다: DB 가 여러 망에 흩어져 있는 조직, 접속이 많아 게이트웨이를 여러 대로 늘려야 하는 경우
- 얻는 것: DB 가 어느 망에 있든 정책과 감사를 한곳에서 관리합니다. 개발망의 게이트웨이는 운영 DB 의 정책과 접속 정보를 갖지 않습니다. 같은 등록 토큰으로 새 노드를 띄우면 곧바로 일을 시작합니다.
- 참고할 점: 방화벽은 게이트웨이에서 Management 로 나가는 방향만 열면 됩니다. Management 는 한 대로 운영합니다.

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

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

직원 PC 의 ssh 와 sftp 접속이 게이트웨이를 지나 서버망의 서버로 갑니다. 게이트웨이는 명령과 파일 전송을 판정하고, 보관한 키로 대신 로그인하고, 세션의 화면을 녹화 저장소에 저장합니다.

- 이런 상황에 사용합니다: 여러 사람이 root 나 공용 계정으로 서버에 접속하는 팀, 외주 인력에게 운영 서버 접속을 열어 줘야 하는 경우
- 얻는 것: 공용 계정 뒤의 사람을 구분해서 기록합니다. 대리 로그인을 사용하면 서버의 패스워드와 SSH 키를 사용자에게 나눠 주지 않아도 됩니다. 위험한 명령은 막고, 작업할 때만 필요한 명령은 승인받은 동안만 실행하게 합니다.
- 참고할 점: 서버의 방화벽에서 게이트웨이 외의 SSH 출발지를 닫아야 게이트웨이가 유일한 입구가 됩니다. 에이전트 없는 접속과 웹 터미널은 아직 지원하지 않습니다.

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

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

직원 PC 의 AI 앱이 보낸 요청을 에이전트가 게이트웨이로 보냅니다. 게이트웨이는 요청을 읽어 값 패턴을 검사하고 걸린 값을 마스킹한 뒤 인터넷의 AI 서비스로 전달합니다.

- 이런 상황에 사용합니다: 직원이 PC 에서 AI 앱에 계정으로 로그인해 사용하는 조직(예: Claude 데스크톱 앱)
- 얻는 것: AI 앱의 사용 내역을 사람 단위로 파악합니다. 개인정보와 자격 증명이 나가기 전에 마스킹하거나 막습니다.
- 참고할 점: 요금은 로그인한 계정에 그대로 청구됩니다. 게이트웨이는 직원의 로그인 정보를 저장하지 않습니다. PC 에서 AI 서비스로 직접 나가는 길은 방화벽에서 닫습니다.

### 7. 사내 앱과 개발 도구의 LLM 호출을 회사 키로 모으기

회사의 실제 키(조직 키)는 게이트웨이만 사용하고, 사용자와 애플리케이션에는 가상 키를 발급합니다. 누가 어떤 모델을 얼마나 사용했는지 한곳에서 봅니다.

사내 서버 앱과 개발 도구가 가상 키로 게이트웨이를 호출합니다. 게이트웨이는 가상 키와 사용 한도를 확인하고 조직 키로 교체해 OpenAI, Anthropic, Amazon Bedrock 으로 보냅니다.

- 이런 상황에 사용합니다: LLM API 를 호출하는 사내 서비스와 배치, API 키로 사용하는 개발 도구(Claude Code, Codex, Gemini CLI)
- 얻는 것: 조직 키를 누구에게도 나눠 주지 않습니다. 비싼 모델을 막고 사용자마다 사용 한도를 정합니다. 연결 대상을 Amazon Bedrock 으로 옮겨도 애플리케이션의 설정은 그대로입니다.
- 참고할 점: 클라이언트는 게이트웨이 클러스터의 루트 CA 를 신뢰해야 합니다.

### 8. AI 가 호출하는 사내 도구를 통제하기

MCP 서버를 서비스로 등록하고 도구 호출 단위로 통제합니다. AI 가 사내 시스템에서 할 수 있는 일을 사람마다 다르게 정합니다.

관리자가 허용할 도구를 선택하면 Management 가 게이트웨이에 정책을 보냅니다. 직원 PC 의 AI 클라이언트가 사내 MCP 서버의 도구를 호출하면 게이트웨이가 도구와 인자를 검사한 뒤 전달합니다.

- 이런 상황에 사용합니다: 사내 시스템을 MCP 서버로 제공하는 조직, AI 가 할 수 있는 일을 사람마다 다르게 정해야 하는 경우
- 얻는 것: 조회 도구는 허용하고 삭제 도구는 막습니다. 도구 호출 이력이 사람 이름과 함께 남습니다.
- 참고할 점: 허용 목록이 비어 있으면 모든 도구를 허용합니다. PC 안에서만 실행되는 MCP 서버는 대상이 아닙니다.

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

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

사내 인증 시스템과 연동한 Management 한 대가 여러 게이트웨이 클러스터를 관리합니다. 직원 PC, 협력사와 배치 서버, 사내 서버 앱의 접속이 모두 게이트웨이 클러스터를 지나 DB, 서버, AI 서비스로 갑니다. 감사 기록은 한 저장소에 모이고 사본이 SIEM 으로 갑니다.

- 이런 상황에 사용합니다: DB 접근 통제, 서버 접근 통제, AI 사용 통제를 함께 운영하려는 조직
- 얻는 것: 퇴사자의 계정을 끄면 열려 있는 DB 세션이 끊기고 AI 사용도 막힙니다. 값 패턴 하나를 DB 결과와 AI 프롬프트에 함께 사용합니다. 같은 사람의 SQL 문장, 서버 명령, AI 질문을 같은 이름으로 찾습니다.
- 참고할 점: 감사 사본은 SIEM 으로 보냅니다.

### 10. 누가 어떤 이상 행위를 했는지 찾고 소명받기

세 제품의 감사 기록에서 탐지 규칙에 맞는 행위를 찾아 사람별로 묶고, 당사자에게 소명을 받아 검토 결과를 남깁니다. 한 달의 점검은 월간 점검 보고서로 남습니다.

DAC, AI Gateway, Server Gateway 의 감사 기록이 감사 저장소에 모이고, Management 의 이상 행위 탐지가 탐지 규칙과 대조해 사람별 검토 건을 만듭니다. 당사자는 에이전트로 소명하고, 검토자는 검토 결과를 남기며, 매월 점검 보고서가 만들어집니다.

- 이런 상황에 사용합니다: 개인정보 접속기록을 월 1회 이상 점검해야 하는 조직, 막는 것만으로는 부족하고 누가 왜 그랬는지 확인해야 하는 경우
- 얻는 것: 차단된 시도, 대량 조회, 업무시간 외 접근, 신규 IP 접속을 사람 단위로 봅니다. 정상 업무로 확인한 행위는 만료일까지 예외로 처리해 검토가 쌓이지 않습니다. 월간 점검 보고서가 점검하지 못한 구간까지 함께 알려 줍니다.
- 참고할 점: 규칙은 켠 뒤에 발생한 기록에만 적용합니다. 소명은 데스크톱 에이전트로만 받습니다. 메일로는 받지 않습니다.

## 자주 묻는 질문 (https://beehind.me/ko/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 를 지원하나요?

MySQL, MariaDB, PostgreSQL, Oracle, SQL Server 를 지원합니다. 게이트웨이가 각 DB 의 통신 규약(wire protocol)을 직접 해석하므로 JDBC 드라이버나 DB 쪽 설치가 필요하지 않습니다.

### 사용자는 DB 도구의 설정을 변경해야 하나요?

데스크톱 에이전트를 사용하면 변경하지 않습니다. DB 도구에 실제 DB 주소와 평소의 DB 계정을 그대로 넣고, 에이전트에 로그인하면 가로채기가 자동으로 켜집니다. 에이전트 없이 접속하는 경우에는 호스트와 포트를 게이트웨이로 변경합니다. PostgreSQL, Oracle, SQL Server 는 DB 이름 앞에 발급받은 UUID 를 붙이고, MySQL 과 MariaDB 는 서비스마다 배정된 전용 포트로 접속합니다.

### 에이전트를 설치할 수 없는 PC, BI 도구, 배치 서버는 어떻게 하나요?

관리자가 발급한 접속 주소로 게이트웨이에 직접 접속합니다(에이전트리스). 주소마다 감사에 남길 이름과 접속을 허용할 IP 대역을 정하고, 접근 규칙, SQL 통제, 마스킹은 에이전트를 사용할 때와 똑같이 적용됩니다.

### 어떤 형태로 설치하나요?

서버 한 대에 Docker Compose 로 Management, 게이트웨이, PostgreSQL, Caddy 를 함께 설치하는 형태와, 게이트웨이를 Linux VM 에 systemd 서비스로 설치하는 형태를 제공합니다. Kubernetes(Helm), AWS, Azure 용 템플릿은 준비하고 있습니다.

### 폐쇄망에 설치할 수 있나요?

네. Management 와 게이트웨이는 실행 중에 외부 네트워크를 호출하지 않습니다. 이미지와 설치 스크립트를 한 묶음으로 반입해서 설치합니다.

### 어떻게 시작하면 되나요?

서버 한 대로 운영 DB 하나부터 시작하는 것을 권합니다. 이후 에이전트 없이 접속하는 곳을 더하고, 망마다 게이트웨이를 늘리고, AI 서비스를 등록합니다. 도입 문의를 보내 주시면 환경에 맞는 구성을 안내해 드립니다.

### 라이선스가 만료되면 접속이 막히나요?

아니요. 라이선스는 사용 기간만 확인합니다. 기간이 끝나도 접속 통제와 감사는 멈추지 않습니다.

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

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

### 별칭이나 함수로 감싼 컬럼도 마스킹되나요?

네. 게이트웨이가 필요할 때 스키마를 읽어 조회 결과의 각 항목이 어느 원본 컬럼에서 왔는지 계산하고, 결과의 위치로 마스킹합니다. 계산하지 못한 문장은 마스킹할 값을 놓치지 않도록 사유와 함께 거부합니다. 주민등록번호처럼 모양이 정해진 값은 어느 컬럼에 있든 값 패턴으로 찾습니다.

### 암호화된(TLS) DB 접속도 통제할 수 있나요?

네. 게이트웨이가 클라이언트 쪽과 DB 쪽의 TLS 를 각각 맺어 내용을 보고 통제합니다. 인증서는 게이트웨이 클러스터의 인증 기관이 발급하고 자동으로 교체합니다. 내용을 볼 수 없는 접속은 조용히 통과시키지 않고 거부합니다.

### Management 가 멈추면 어떻게 되나요?

동작 중인 게이트웨이는 이미 받은 정책으로 판정을 계속하고 감사 기록도 저장소에 직접 기록합니다. 승인 기간이 끝난 세션을 끊는 일도 스스로 합니다. 다만 로그인과 정책 변경은 Management 가 돌아온 뒤에 할 수 있습니다.

### 감사 기록은 어디에 저장되나요?

게이트웨이가 OpenSearch, Elasticsearch, 관계형 DB(PostgreSQL, MySQL, MariaDB, Oracle) 중 선택한 저장소에 직접 기록합니다. 기록은 해시 체인으로 이어 무결성을 검증하고, syslog(RFC 5424)나 Splunk HEC 로 SIEM 에 사본을 보냅니다.

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

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

### 회사의 LLM API 키를 직원에게 나눠 주지 않고 사용할 수 있나요?

네. 회사의 실제 키(조직 키)는 게이트웨이만 사용하고, 사용자와 애플리케이션에는 가상 키를 발급합니다. 게이트웨이가 요청을 보낼 때 조직 키로 교체합니다. 가상 키는 하나씩 폐기하고, 사용자와 서비스마다 모델과 사용 한도를 정합니다.

### MCP 도구 호출도 통제하나요?

네. 네트워크로 호출하는 MCP 서버(Streamable HTTP)를 서비스로 등록하면 도구 이름을 허용 목록으로 제한하고, 인자에 든 값을 값 패턴으로 검사하고, 호출 이력을 사람 이름으로 기록합니다.

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

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

### 대상 서버에 무엇을 설치해야 하나요?

설치할 프로그램은 없습니다. 게이트웨이가 SSH 를 양쪽에서 종단하므로 대상 서버의 sshd 를 그대로 사용합니다. 보관한 SSH 키로 대신 로그인하는 계정은 공개키를 authorized_keys 에 넣고, 인증서로 로그인하는 계정은 서버마다 한 번 클러스터의 사용자 CA 를 신뢰하도록 sshd 를 설정합니다.

### SSH 가 아닌 포트도 사용자별로 허용할 수 있나요?

지금은 SSH 포트 포워딩으로 합니다. 사용자가 ssh -L 이나 ssh -D 로 여는 포워딩을 사용자별로 허용한 목적지(호스트와 포트)로만 넘깁니다. SSH 를 거치지 않고 서버의 포트(예: 웹 관리 화면, Redis, RDP)에 바로 접속하는 경우를 사용자별로 허용하고 기록하는 기능은 준비하고 있습니다.

### 세션 녹화에는 무엇이 남나요?

대상 서버가 보낸 화면 출력과 창의 크기를 녹화해 관리 콘솔에서 재생합니다. 사용자가 입력한 글자는 저장하지 않으므로 패스워드가 남지 않습니다. 파일 전송(SFTP)은 녹화하지 않고 옮긴 파일마다 감사에 기록합니다. 녹화는 S3 호환 저장소에 저장합니다.

## BeeHind 도입을 상담해 드립니다

https://beehind.me/ko/contact · contact@unvus.com