# BeeHind — 企業のデジタル資産を守るセキュリティゲートウェイ

> BeeHind は DB アクセス制御（DAC）、AI ゲートウェイ、サーバーアクセス制御を統合したセキュリティゲートウェイです。共有アカウントの利用者を特定し、SQL、サーバーコマンド、AI リクエストを判定し、個人情報をマスキングし、異常行動を検知します。

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

## DB、AI、サーバーへのアクセスを制御し、異常行動まで見つけ出すオールインワンのセキュリティゲートウェイ

BeeHind は、DAC（DB アクセス制御）、AI Gateway、Server Gateway を1つの製品として提供します。3つの製品がユーザー、ポリシー、監査記録を共有し、集まった記録から異常行動を見つけ出します。

- **DAC**: DB アクセス制御
- **AI Gateway**: AI ゲートウェイ
- **Server Gateway**: サーバーアクセス制御

3製品で1つずつだけ使用: ユーザー一覧, ポリシー画面, 監査ストア, デスクトップエージェント
- 退職者のアカウントを無効にすれば、DB、サーバー、AI への接続がまとめてブロックされます。
- 同じ人の SQL 文、サーバーコマンド、AI への質問を1つの名前で検索できます。

すべての接続がゲートウェイで通る4つの段階:
- **本人確認**: 共有アカウントの背後にいる実際の人物を特定します。
- **ポリシー判定**: 接続、SQL 文、サーバーコマンド、AI リクエストをルールに従って許可またはブロックします。
- **結果のマスキング**: クエリ結果やプロンプトに含まれる個人情報をマスキングします。
- **監査記録**: 誰が、いつ、何をしたかを1つの監査ストアに記録します。

**異常行動検知**: 誰がどのような異常行動をしたかを見つけ出します。 (申告 → レビュー結果 → 月次点検レポート)

### 重要なデータが行き交う経路が、無防備なままです

- **DB はアカウント名しか知りません** 複数の開発者が app_user のような DB アカウントを1つ共有しています。DB のログにはアカウント名しか残らず、実際に誰が接続したのか分かりません。 → BeeHind は 接続ごとに付与される署名付きの本人証明で、アカウントの背後にいる人物を特定します。
- **誰が何を照会したのかが残りません** インシデントの発生時や監査の際には、誰がどの SQL 文を実行し、何件のデータを取得したのかを説明しなければなりません。DB ごとに散らばったログでは、答えるのは困難です。 → BeeHind は セッション、SQL 文、判定結果、行数を実際の利用者名とともに1つの監査ストアに記録します。
- **個人情報がそのまま画面に表示されます** 本番 DB を照会すると、マイナンバーや電話番号がそのまま表示されます。業務でその値をすべて見る必要がある人は、多くありません。 → BeeHind は 結果がユーザーに届く前に、機密性の高い値をマスキングします。DB やアプリケーションは変更しません。
- **サーバーの root アカウントを複数人で共有しています** 複数の人が、root や共用アカウント、同じ SSH 鍵でサーバーにログインしています。サーバーのログにはアカウント名しか残らず、誰がどのコマンドを実行したのか分かりません。 → BeeHind は サーバーへの接続も同じ経路を通すことで、コマンドと画面を人の名前で記録します。
- **サーバーからどのファイルが持ち出されたのか分かりません** 本番サーバーのログやダンプファイルは、SFTP や scp で簡単にダウンロードできます。誰が何を持ち出したのかは記録に残りません。 → BeeHind は SFTP を読み取り、許可したファイル機能だけを通し、転送したファイルごとに監査ログに記録します。
- **AI ツールに何が送られているのか分かりません** 社員は AI ツールにソースコードや顧客データを貼り付けています。社内アプリケーションも LLM API を直接呼び出しています。 → BeeHind は AI へのリクエストも同じ経路を通すことで、ルールを適用して記録します。

### 1つの製品で3つの経路を守ります

- **DB アクセス制御**: DB の通信プロトコルを直接解析し、接続、SQL 文、クエリ結果を制御します。 (アクセスルールと時間帯・IP の制約, SQL 文の種類とパターンによる制御, リネージに基づく結果のマスキング, アクセス申請と多段階承認)
- **AI ゲートウェイ**: LLM API、社員が使用する AI アプリ、MCP ツール呼び出しを同じ方法で判定し、記録します。 (仮想キーによる企業の API キーの保護, モデルの制限と利用上限, プロンプトと回答の値パターンによるマスキング, MCP ツールの許可リスト)
- **サーバーアクセス制御**: 誰がどのサーバーにどのアカウントでログインできるかを判定し、接続、実行したコマンド、やり取りしたファイルを記録します。 (サーバーとアカウント単位のアクセスルール, コマンドの制御とセッション録画, ファイル転送（SFTP）の制御, ポートフォワーディングの宛先制限, 保管した鍵による代理ログイン)

### 3つの経路の記録は、最終的に「誰がどのような異常行動をしたか」に行き着きます

ブロックして記録するだけでは終わりません。DAC、AI Gateway、Server Gateway が残した監査記録を人単位で集めて検知ルールと照合し、本人の申告とレビュー結果、月次点検レポートまでを1つの製品の中でつなぎます。

## DB を深く理解するセキュリティゲートウェイ (https://beehind.me/ja/dac)

ゲートウェイが DB の通信プロトコルを直接解析し、誰が、どの DB で、どの SQL 文を実行するのかを判定します。共有アカウントの背後にいる人まで特定し、クエリ結果の個人情報をマスキングし、すべてを記録します。デスクトップエージェントを使用すれば、ユーザーは使い慣れた DB ツールと接続アドレスをそのまま使用できます。

DB アクセス制御（DAC、Database Access Control）は、DB への接続を途中で制御し、監査するセキュリティ製品の分野です。ユーザー認証、コマンドの制御、マスキング、監査が主な機能です。

BeeHind の DAC は、DB の通信プロトコル（wire protocol）を直接解析します。そのため、DB やアプリケーションを変更することなく SQL 文を制御し、エイリアスや関数の背後に隠れた機密カラムまでマスキングします。

クライアントと DB の間で動作するインラインプロキシであるため、観察するだけの方式とは異なり、接続を拒否し、SQL 文をブロックし、結果をマスキングできます。DB のファイアウォールでゲートウェイからの接続のみを受け付けるように設定すれば、ゲートウェイが唯一の入口になります。

### 接続元に合わせた2つの経路

| 接続元 | デスクトップエージェント | ゲートウェイへの到達方法 | 利用者の識別方法 |
| --- | --- | --- | --- |
| 社員の PC の DB ツール | 必要 | エージェントが接続をインターセプトし、mTLS トンネルで送ります | 署名付きの本人証明 |
| 協力会社の PC、BI ツール | 不要 | 発行された接続アドレスに直接接続します | アドレスに割り当てた名前と許可 IP 範囲 |
| バッチサーバー | 不要 | 発行された接続アドレスに直接接続します | 許可 IP 範囲 |

### 接続から SQL 文まで、段階ごとに判定します

- **アクセスルール**: ユーザーまたはグループ、サービス、DB アカウントの組み合わせごとに、許可、拒否、承認が必要のいずれかを設定します。
- **接続の制約**: 接続できる IP 範囲と曜日、時間帯を設定します。許可された時間を過ぎると、開いているセッションも切断します。
- **DB アカウントの制御**: サービスごとに使用できる DB アカウントを決めておき、それ以外のアカウントは DB に到達する前に拒否します。
- **SQL 制御**: DELETE や DROP などの SQL 文の種類と、正規表現のパターンで実行をブロックします。保存する前に SQL 文を入力して、ルールをテストできます。
- **承認**: アクセス申請を受け付け、多段階の承認を経た後、申請された期間に限って接続を許可します。期間が終わるとセッションを切断します。
- **セッション管理**: 現在開いているセッションを確認し、セッション単位またはユーザー単位で強制終了します。退職者のアカウントを無効にすると、セッションも切断されます。

### エイリアスや関数の背後に隠れたカラムまでマスキングします

DB が返した結果から機密性の高い値をマスキングしたうえで、ユーザーに渡します。DB やアプリケーションは変更しません。

- **機密フィールド**: 氏名や住所のように、形式が一定でない値に使用します。customers.name を機密フィールドとして選択すると、エイリアス customer を付けたり関数で囲んだりしても、ゲートウェイが元のカラムをたどって（リネージ）マスキングします。
- **値パターン**: 国民識別番号、カード番号、電話番号のように形式が決まっている値は、どのカラムにあっても検出してマスキングします。個人情報と認証情報のパターンが12種類組み込まれており、正規表現で独自に追加できます。
- 元のカラムを算出できなかった SQL 文は実行せず、理由とともに拒否します。マスキングすべき値を見逃したまま通過させることはありません。
- 誰に対してマスキングするかは、ユーザーとグループ単位で設定します。マスキングした文字は * に置き換えられ、長さはそのまま保たれます。

### 暗号化された接続も、内容を確認して制御します

クライアント側と DB 側の TLS を、ゲートウェイがそれぞれ確立します。ゲートウェイクラスターの認証局（クラスター CA）が証明書を発行し、有効期限が切れる前に自動で更新します。内容を確認できない接続は、既定で拒否します。

### 誰が何をしたかを、人の名前で記録します

- **記録する内容**: セッションの開始と終了、実行した SQL 文、許可・拒否の判定、行数、マスキングした項目、ユーザー名とその名前の出所を記録します。
- **ストア**: OpenSearch、Elasticsearch、リレーショナル DB に記録します。ストアが応答しない場合は、ディスクに蓄積してから再送します。
- **完全性**: 記録をハッシュチェーンでつなぎ、管理コンソールで検証します。途中の記録を改ざんしたり削除したりすると、検出されます。
- **閲覧の制御**: 監査画面でも、個人情報はマスキングして表示します。元の値は、権限を持つ人が理由を入力して1件ずつ開き、閲覧した事実も記録します。
- **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/ja/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 接続文字列などの認証情報のパターンが標準で組み込まれています。
- **利用上限**: ユーザーやサービスごとに、1日または1か月のトークン数とリクエスト数を制限します。
- **ツールの制御**: 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 Web アプリ、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/ja/server-gateway)

ゲートウェイが SSH をクライアント側とサーバー側でそれぞれ終端し、誰が、どのサーバーに、どのアカウントでログインするのかを判定します。実行したコマンドとやり取りしたファイルを制御し、セッションの画面を録画します。ユーザーは普段どおり ssh と sftp を使用します。

Server Gateway は、人がサーバーに SSH で接続する経路で動作する、サーバーアクセス制御のゲートウェイです。踏み台サーバー（ジャンプサーバー）が担っていた役割を引き受けながら、接続した人とその人が行った操作をあわせて記録します。

BeeHind は SSH を両側で終端します。ユーザーの SSH 接続をゲートウェイが受け、対象サーバーにはゲートウェイが別に接続します。そのため、暗号化された SSH の中のコマンド、ファイル転送、ポートフォワーディングを読み取って判定します。対象サーバーにはプログラムをインストールしません。

DAC、AI Gateway と同じユーザー一覧、同じポリシー画面、同じ監査ストアを使用します。

### サーバーアカウントごとにログイン方式を選択します

| 方式 | ユーザーが行うこと | ゲートウェイが行うこと | 対象サーバーで必要な作業 |
| --- | --- | --- | --- |
| ユーザー入力 | サーバーアカウントのパスワードを入力します | 入力された内容を対象サーバーにそのまま渡し、保管しません | なし |
| 保管したパスワード | なし | 保管したパスワードで代理ログインします | なし |
| 保管した SSH 鍵 | なし | 保管した SSH 鍵で代理ログインします | アカウントごとに公開鍵を authorized_keys に追加します |
| 証明書 | なし | 接続ごとに有効期間の短い証明書を作成し、代理ログインします | サーバーごとに1回、クラスターのユーザー 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 を経由しないサーバーのポート（例: Web 管理画面、Redis、RDP）をユーザーごとに許可し、接続の記録を残す機能を準備しています。接続の内容は解析しません。

### 既知の制約

- 対話型シェルに入力したコマンドは、画面に表示された行を読み取って判定します。ssh サーバー コマンド で実行するコマンドとは異なり、推定に基づく判定です。
- ブロック方式のコマンドテンプレートだけでは、シェルを経由したファイルの出し入れを防げません。
- フォワーディングした接続の内容は確認しません。その接続で DB に接続すると SQL が監査ログに残らないため、DB は DAC のサービスとして登録してください。
- 画面に表示されたシークレットは、録画にそのまま残ります。
- エージェントを使わない接続、Web ターミナル、RDP、Telnet、FTP には、まだ対応していません。

## 誰がどのような異常行動をしたかを見つけ出し、申告まで受け付けます (https://beehind.me/ja/anomaly-detection)

3つの経路の監査記録を人単位で集め、検知ルールと照合します。一致した行為は人ごとのレビュー件になり、本人の申告とレビュー担当者のレビュー結果を経て、月次点検レポートに残ります。

異常行動検知は、監査記録からポリシーに違反した行為や普段と異なる行為を見つけて人ごとにまとめ、レビュー担当者が結論を出せるようにする機能です。

Management が監査ストアを10秒ごとに読み取り、有効な検知ルールと照合します。DAC の SQL 文とクエリ結果、Server Gateway のコマンドとファイル転送、AI Gateway のプロンプトがすべて同じ人の名前で残っているため、1人が3つの経路で行ったことをまとめて確認できます。

検知だけで終わらず、本人に理由を尋ねる申告、レビュー担当者のレビュー結果、通常業務と確認した行為の例外、1か月の点検をまとめた月次点検レポートまでつながります。別の分析製品を連携する必要はありません。

### 9つのプリセットから始めます

ルールはプリセットをコピーして作成し、範囲（接続先、人、グループ）、回数、重要度、自動申告依頼を設定します。すべての値を一覧から選択するため、1文字の入力ミスでルールが気付かないうちに機能しなくなることはありません。

| 検知ルール | 製品 | 既定の条件 | 重要度 |
| --- | --- | --- | --- |
| ブロックされた SQL の実行試行 | DAC | 1件ごと | 中 |
| 制限されたサーバーコマンドの実行試行 | Server Gateway | 1件ごと | 中 |
| AI への機密情報の送信試行 | AI Gateway | 1件ごと | 高 |
| 許可されていない接続の試行 | DAC, AI Gateway, Server Gateway | 60分以内に3件以上 | 中 |
| ゲートウェイでブロックされた接続の試行 | 共通 | 60分以内に3件以上 | 中 |
| 機密情報の頻繁な照会 | DAC | 60分以内に100件以上 | 中 |
| 機密情報の大量照会 | DAC | 60分以内に1,000行以上 | 高 |
| 業務時間外のアクセス | DAC, Server Gateway | 1件ごと | 中 |
| 新しい IP 範囲からの接続 | DAC, Server Gateway | 1件ごと（人ごとに14日間の学習後） | 中 |
どのプリセットも、レビュー件が作成されると本人に申告を自動で依頼します。ルールは有効にした後に発生した記録にのみ適用されます。業務時間と祝日、送信元の学習期間は検知設定で指定します。

### 検知した行為ごとに結論を記録します

- **レビュー件**: 同じルール、同じ人、同じ接続先、同じ日の検知記録を1件にまとめます。監査記録の原文（SQL、プロンプト）はコピーせず、要約だけを保持します。
- **申告依頼**: 本人に、その行為をなぜ行ったのかを尋ねます。本人には「異常行動」という言葉ではなく、「申告依頼」として表示されます。
- **申告**: 本人はデスクトップエージェントで自分が実行した文を確認し、分類（業務の遂行、テストまたは開発、誤って実行、指示または承認を受けた、自分ではない など）と説明を記入して回答します。
- **申告承認**: 使用するように設定すると、本人の申告承認者がエージェントで申告を確認します。確認はレビューの根拠となり、結論はレビュー担当者が出します。
- **レビュー結果**: 違反、通常業務、誤検知（ルールの問題）、誤検知（データの問題）、判断不可から選択し、コメントを記入します。違反の場合は、実施した措置もあわせて記録します。
- **例外**: 通常業務と確認した行為は、範囲と有効期限を決め、その日まで再び検知しないようにします。

### 月次点検レポート

毎月1日に、前月の検知、レビュー、申告、例外をまとめたレポートを作成します。韓国の「個人情報の安全性確保措置基準」第8条第2項が求める月1回以上のアクセスログ点検を行った根拠として残します。作成したレポートは変更されず、再度作成すると新しいレポートが作成されます。

- 検知: レビュー件数、人数、ルール別と重要度別の件数
- レビュー: 結果別の件数と、違反とレビューした件の措置
- 申告: 依頼、提出、期限後の提出、本人による否認、未提出
- 例外: 新しく作成したもの、解除したもの、適用中のもの
- 点検できなかった区間: 検証できなかった監査記録とチェーンの途切れ

### 連携して動作するもの

- 読み取る記録: DAC、AI Gateway、Server Gateway の監査記録（OpenSearch、Elasticsearch、リレーショナル DB）
- 申告の回答: デスクトップエージェント（macOS、Windows）
- SIEM 転送: レビュー件の作成、申告の提出、申告承認、レビュー結果、再オープン（syslog、Splunk HEC）
- 履歴: ルール、レビュー、申告、例外のすべての変更をチェーンで封印し、1日1回検証します
- 通知: 本人が「自分ではない」と回答すると、レビュー担当者にすぐメールを送信します

### 既知の制約

- ルールは有効にした後に発生した記録にのみ適用されます。過去の記録をさかのぼって検知することはありません。
- 元の値の照会記録をオフにしたサービスでは、マスキングされずに行われた機密フィールドの照会が記録されないため、検知されません。
- 業務時間外のアクセスと新しい IP からの接続は、アカウントがある人の記録だけを確認します。
- エージェントを使わずに接続した記録（発行アドレス、仮想キー）には、申告を自動で依頼しません。レビュー担当者が直接依頼することはできます。
- 申告は、直近90日以内にデスクトップエージェントにログインした人にのみ依頼できます。

## 3つの構成要素が経路をつくります (https://beehind.me/ja/how-it-works)

ゲートウェイが制御と記録を行い、Management がポリシーを決めて配布し、デスクトップエージェントが接続する人を証明します。Management は接続経路上にはありません。

### ゲートウェイ

DB、サーバー、AI サービスの前段で動作するプロキシサーバーです。制御と記録が実際に行われる場所です。

- DB の通信プロトコルを直接解析し、接続、SQL 文、クエリ結果を読み取ります。
- SSH をクライアント側とサーバー側でそれぞれ終端し、サーバーコマンドとファイル転送を読み取ります。
- 接続、SQL 文、コマンド、AI リクエストを、ポリシーに従って許可またはブロックします。
- クエリ結果と AI リクエストに含まれる機密性の高い値をマスキングします。
- 監査ログを監査ストアに直接記録します。
- 設置場所: 保護する DB やサーバーがあるネットワークと、AI サービスへの出口。ネットワークごとにクラスターを構成し、必要な台数に設置して稼働させます。

### Management

ポリシーとアカウントを管理するサーバーです。管理者が使用する Web 画面である管理コンソールも含まれています。

- ユーザーとグループを管理し、社内の認証システムと連携します。
- 保護するサービスを登録し、アクセスルール、マスキング、SQL 制御を定義します。
- ポリシーに署名し、担当ゲートウェイに配布します。
- アクセス申請の承認を進め、監査ログを表示します。
- 監査記録から異常行動を検知し、申告とレビューを進めます。
- 設置場所: 1台。ゲートウェイとエージェントが接続できる場所に設置します。

### デスクトップエージェント

社員の PC にインストールするアプリです。接続しているのが誰なのかを、ゲートウェイに証明します。

- 会社のアカウントでログインし、署名付きの本人証明を受け取ります。
- 登録されたサービスへの接続のみをインターセプトし、担当ゲートウェイに送ります。
- 接続ごとに本人証明を付与し、DB アカウントを共有していても人を区別します。
- 接続できるサービスの一覧を表示し、アクセス申請を受け付けます。
- 設置場所: 社員の PC。macOS と Windows に対応しています。

### 1回の接続が処理される流れ

1. **ログイン**: ユーザーが会社のアカウントでデスクトップエージェントにログインします。Management は、接続可能なサービスの一覧と署名付きの本人証明を渡します。
2. **接続の開始**: ユーザーが DB ツールに実際の DB アドレスと DB アカウントを入力して接続します。エージェントは、登録されたサービスへの接続のみをインターセプトします。
3. **トンネル**: エージェントが担当ゲートウェイへの相互 TLS（mTLS）トンネルを開き、先頭に本人証明と本来の接続先を付けて送ります。
4. **接続の判定**: この人がこのサービスにこの DB アカウントで接続してよいかを、接続元と時間帯まで含めてゲートウェイが判定します。許可されない場合は、DB に到達する前に切断します。
5. **ログインの中継**: ゲートウェイが DB に接続し、ログインの手順をそのまま中継します。パスワードが正しいかどうかは DB が判断します。
6. **SQL 制御**: SQL 文を実行するたびに、禁止された種類の文でないかを確認します。
7. **結果のマスキング**: DB が返した結果から機密性の高い値をマスキングしたうえで、ユーザーに渡します。
8. **監査記録**: セッション、SQL 文、判定結果、行数を、ユーザー名とともに監査ストアに記録します。

接続が続いている間も、ゲートウェイは定期的に判定し直します。許可された時間を過ぎたり、ポリシーが変更されたりすると、開いているセッションを切断します。

### サーバー1台から、複数ネットワークのクラスターまで

- **サーバー1台（Docker Compose）** (提供中): Management、ゲートウェイ、PostgreSQL、Caddy を1台のホストにインストールします。インストール、バージョンの変更、ロールバックはインストールスクリプトが行います。閉域網には一式にまとめて持ち込みます。
- **ゲートウェイを Linux VM に（systemd）** (提供中): コンテナを使わずに、ゲートウェイノードを VM にインストールします。管理コンソールから更新を指示すると、ノードが新しいバージョンをダウンロードして自ら入れ替えます。
- **Kubernetes(Helm)、AWS、Azure** (準備中): インストールテンプレートを実環境に展開できるよう、仕上げを進めています。

### 経路上に置く製品は、それ自体が信頼できるものでなければなりません

- **DB のパスワードを集約しません**: ゲートウェイは、ユーザーの DB へのログインを代行せず、そのまま中継します。パスワードが正しいかどうかは DB が判断します。パスワードを1か所に集めると、そこが攻撃の標的になるためです。
- **分からなければブロックします**: 解析できなかった SQL 文や、内容を確認できない接続を通過させることはありません。マスキングすべきカラムが結果のどの列にあるかを算出できなければ、その SQL 文を拒否します。
- **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 Web アプリ、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/ja/use-cases)

### 1. サーバー1台で始める

サーバー1台に Management とゲートウェイを一緒にインストールし、そのサーバーを本番 DB への唯一の入口にします。踏み台サーバーが担っていた役割を、BeeHind が引き受けるのと同じです。

サーバー1台に Management、ゲートウェイ、監査ストアをまとめてインストールした構成です。社員の PC のエージェントが mTLS トンネルでゲートウェイに接続し、ゲートウェイが社内ネットワークの本番 DB への接続を中継します。PC から DB へ直接つながる経路は、ファイアウォールで遮断します。

- 適した場面: 保護する DB が1つのネットワークにまとまっているチーム、小規模に導入してまず試したい場合
- 得られること: 本番 DB で誰がいつどの SQL 文を実行したかが、人の名前で記録されます。 マスキング、SQL 制御、アクセスルールをすぐに適用できます。 開発者に踏み台サーバーの SSH アカウントを配布する必要がなくなります。
- 留意事項: 経路として機能させるには、DB のファイアウォールでほかの接続元を遮断する必要があります。 障害時に使用する緊急用の接続経路を、別に決めておきます。

### 2. エージェントをインストールできない環境から接続する

協力会社の PC、BI ツール、バッチサーバーは、管理者が発行した接続アドレスでゲートウェイに直接接続します。エージェントのない接続にも、同じポリシーと監査が適用されます。

協力会社の PC、BI ツール、バッチサーバーが、発行された接続アドレスでゲートウェイに直接接続します。ゲートウェイは接続元の IP 範囲を確認し、ポリシーで判定した後、本番 DB への接続を中継します。

- 適した場面: 協力会社の PC、ソフトウェアのインストールが制限された PC、Tableau や Redash などの BI ツール、バッチサーバー
- 得られること: 利用者を追加しても、ファイアウォールを開け直す必要はありません。 アドレスを失効させると、そのアドレスではすぐに接続できなくなります。
- 留意事項: 発行先は監査ログに記録される名前であり、本人確認ではありません。実際に接続を制限するのは許可 IP 範囲です。 人を正確に区別する必要がある接続には、エージェントを使用します。

### 3. 本番 DB の個人情報を安全に扱う

外部委託の開発者による本番 DB への接続を普段はブロックしておき、承認を得た期間だけ許可します。許可している間も個人情報はマスキングし、データを変更する SQL 文はブロックします。

外部委託の開発者によるアクセス申請を承認者が承認すると、Management が期間限定のポリシーをゲートウェイに配布します。ゲートウェイは期間を確認し、SQL を制御し、結果をマスキングしたうえで、本番 DB への接続を中継します。

- 適した場面: 外部委託の要員や運用サポート担当者による本番 DB の照会、個人情報を含むテーブルがある DB 全般
- 得られること: 必要な人に、必要な期間だけ接続を許可します。 クエリ結果の個人情報はマスキングされ、すべての SQL 文が記録されます。
- 留意事項: 期間の満了はゲートウェイが自ら確認します。Management が停止していても、セッションは切断されます。

### 4. 複数のネットワークを持つ企業でゲートウェイを分散して設置する

本社のサーバールーム、クラウド、開発ネットワークのように DB が分散している場合は、ネットワークごとにゲートウェイクラスターを設置し、1台の Management が全体を管理します。

本社のサーバールーム、クラウド、開発ネットワークにゲートウェイクラスターを1つずつ設置し、1台の Management が管理します。社員の PC のエージェントはサービスごとに担当クラスターへトンネルを開き、各クラスターは監査ストアに直接記録します。

- 適した場面: DB が複数のネットワークに分散している組織、接続数が多くゲートウェイを複数台に増やす必要がある場合
- 得られること: DB がどのネットワークにあっても、ポリシーと監査を1か所で管理できます。 開発ネットワークのゲートウェイは、本番 DB のポリシーや接続情報を持ちません。 同じ登録トークンで新しいノードを起動すると、すぐに稼働を始めます。
- 留意事項: ファイアウォールは、ゲートウェイから Management へ向かう方向だけを開ければ十分です。 Management は1台で運用します。

### 5. サーバーへの接続を人単位で制御する

サーバーの SSH をサービスとして登録すると、誰がどのサーバーにどのアカウントでログインしたか、何を実行し、どのファイルをやり取りしたかが、人の名前で記録されます。踏み台サーバーが担っていた役割を、ゲートウェイが引き受けます。

社員の PC からの ssh と sftp の接続が、ゲートウェイを通ってサーバーゾーンのサーバーへ向かいます。ゲートウェイはコマンドとファイル転送を判定し、保管した鍵で代理ログインし、セッションの画面を録画ストアに保存します。

- 適した場面: 複数の人が root や共用アカウントでサーバーに接続しているチーム、外部委託の要員に本番サーバーへの接続を許可する必要がある場合
- 得られること: 共用アカウントの背後にいる人を区別して記録します。 代理ログインを使用すれば、サーバーのパスワードや SSH 鍵をユーザーに配布する必要がありません。 危険なコマンドはブロックし、作業時にだけ必要なコマンドは承認を得ている間だけ実行できるようにします。
- 留意事項: 経路として機能させるには、サーバーのファイアウォールでゲートウェイ以外の SSH 接続元を遮断する必要があります。 エージェントを使わない接続と Web ターミナルには、まだ対応していません。

### 6. 社員が使用する AI アプリから何が送られるかを制御する

デスクトップエージェントが AI サービスへの接続をゲートウェイに送ると、DB への接続と同じ方法で判定し、マスキングし、記録します。社員がアプリの設定を変更する必要はありません。

社員の PC の AI アプリが送信したリクエストを、エージェントがゲートウェイに送ります。ゲートウェイはリクエストを読み取って値パターンを検査し、一致した値をマスキングしたうえで、インターネット上の AI サービスに転送します。

- 適した場面: 社員が PC で AI アプリに自分のアカウントでログインして使用している組織（例: Claude デスクトップアプリ）
- 得られること: AI アプリの利用状況を、人単位で把握できます。 個人情報や認証情報が外部に送られる前に、マスキングまたはブロックします。
- 留意事項: 料金は、ログインしたアカウントにそのまま請求されます。ゲートウェイは社員のログイン情報を保存しません。 PC から AI サービスへ直接つながる経路は、ファイアウォールで遮断します。

### 7. 社内アプリと開発ツールの LLM 呼び出しを会社のキーに集約する

企業の実際のキー（組織キー）はゲートウェイだけが使用し、ユーザーとアプリケーションには仮想キーを発行します。誰がどのモデルをどれだけ使用したかを、1か所で確認できます。

社内のサーバーアプリと開発ツールが、仮想キーでゲートウェイを呼び出します。ゲートウェイは仮想キーと利用上限を確認し、組織キーに置き換えて 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 サービスでも、同じユーザー一覧、同じポリシー画面、同じ監査ストアを使用します。

社内の認証システムと連携した1台の Management が、複数のゲートウェイクラスターを管理します。社員の PC、協力会社やバッチサーバー、社内のサーバーアプリからの接続は、すべてゲートウェイクラスターを通って DB、サーバー、AI サービスへ向かいます。監査ログは1つの監査ストアに集まり、コピーが SIEM に送られます。

- 適した場面: DB アクセス制御、サーバーアクセス制御、AI の利用制御を一体で運用したい組織
- 得られること: 退職者のアカウントを無効にすると、開いている DB セッションが切断され、AI の利用も止まります。 1つの値パターンを、DB の結果と AI のプロンプトに共通で使用します。 同じ人の SQL 文、サーバーコマンド、AI への質問を、同じ名前で検索できます。
- 留意事項: 監査ログのコピーは SIEM に送信します。

### 10. 誰がどのような異常行動をしたかを見つけ、申告を受け付ける

3つの経路の監査記録から検知ルールに一致する行為を見つけて人ごとにまとめ、本人から申告を受け付けてレビュー結果を記録します。1か月の点検は月次点検レポートに残ります。

DAC、AI Gateway、Server Gateway の監査記録が監査ストアに集まり、Management の異常行動検知が検知ルールと照合して、人ごとのレビュー件を作成します。本人はエージェントで申告し、レビュー担当者はレビュー結果を記録し、毎月、月次点検レポートが作成されます。

- 適した場面: 個人情報のアクセスログを月1回以上点検する必要がある組織、ブロックするだけでは不十分で、誰がなぜそうしたのかを確認する必要がある場合
- 得られること: ブロックされた試行、大量照会、業務時間外のアクセス、新しい IP からの接続を人単位で確認できます。 通常業務と確認した行為は有効期限まで例外として扱うため、レビュー待ちがたまりません。 月次点検レポートが、点検できなかった区間もあわせて知らせます。
- 留意事項: ルールは有効にした後に発生した記録にのみ適用されます。 申告はデスクトップエージェントでのみ受け付けます。メールでは受け付けません。

## よくある質問 (https://beehind.me/ja/faq)

### BeeHind とは何ですか？

BeeHind は、DB アクセス制御（DAC）、AI ゲートウェイ（AI Gateway）、サーバーアクセス制御（Server Gateway）を1つにまとめたセキュリティゲートウェイです。人やアプリケーションからデータベース、AI サービス、サーバーへの接続がゲートウェイを通過する間に、本人を確認し、ポリシーで許可またはブロックし、個人情報をマスキングし、監査ログを記録します。ゲートウェイ、Management、デスクトップエージェントで構成されます。

### 従来の DB アクセス制御製品とは何が違いますか？

違いは3つあります。1つ目に、コンテナとして導入する構造で設計しており、ネットワークごとにゲートウェイクラスターを設置し、1台の Management で全体を管理します。2つ目に、クエリ結果の各列がどの元のカラムに由来するかを算出し（リネージ）、エイリアスや関数の背後に隠れた機密カラムまでマスキングします。3つ目に、DB アクセス制御、AI ゲートウェイ、サーバーアクセス制御を1つの製品として提供するため、ユーザー一覧、ポリシー画面、監査ストア、デスクトップエージェントをそれぞれ1つだけ運用すれば済みます。

### 誰がどのような異常行動をしたかも分かりますか？

はい。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 制御、マスキングは、エージェントを使用する場合と同じように適用されます。

### どのような形態で導入しますか？

サーバー1台に Docker Compose で Management、ゲートウェイ、PostgreSQL、Caddy をまとめてインストールする形態と、ゲートウェイを Linux VM に systemd サービスとしてインストールする形態を提供しています。Kubernetes(Helm)、AWS、Azure 向けのテンプレートは準備中です。

### 閉域網に導入できますか？

はい。Management とゲートウェイは、実行中に外部ネットワークへアクセスしません。イメージとインストールスクリプトを一式にまとめて持ち込み、インストールします。

### どのように始めればよいですか？

サーバー1台で、本番 DB 1つから始めることをおすすめします。その後、エージェントを使わずに接続する環境を追加し、ネットワークごとにゲートウェイを増やし、AI サービスを登録します。導入のご相談をお寄せいただければ、環境に合った構成をご案内します。

### ライセンスの期限が切れると、接続がブロックされますか？

いいえ。ライセンスで確認するのは利用期間のみです。期間が終わっても、接続制御と監査は停止しません。

### ゲートウェイは DB のパスワードを保管しますか？

ユーザーの DB パスワードは保管しません。ゲートウェイは DB へのログインを代行せず、クライアントと DB の間でそのまま中継します（認証の中継）。パスワードが正しいかどうかは DB が判断します。テーブルのカラムごとにマスキングを設定する場合は、任意で参照用アカウントを登録できます。管理者が登録したこのアカウントのパスワードは暗号化して保管し、担当ゲートウェイにのみ渡します。

### エイリアスや関数で囲んだカラムもマスキングされますか？

はい。ゲートウェイが必要に応じてスキーマを読み取り、クエリ結果の各列がどの元のカラムに由来するかを算出して、結果の位置に基づいてマスキングします。算出できなかった SQL 文は、マスキングすべき値を見逃さないよう、理由とともに拒否します。国民識別番号のように形式が決まっている値は、どのカラムにあっても値パターンで検出します。

### 暗号化された（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 Web アプリです。

### 会社の LLM API キーを社員に配布せずに使用できますか？

はい。企業の実際のキー（組織キー）はゲートウェイだけが使用し、ユーザーとアプリケーションには仮想キーを発行します。ゲートウェイがリクエストを送信する際に、組織キーに置き換えます。仮想キーは個別に失効させることができ、ユーザーやサービスごとにモデルと利用上限を設定できます。

### MCP ツールの呼び出しも制御できますか？

はい。ネットワーク経由で呼び出す MCP サーバー（Streamable HTTP）をサービスとして登録すると、ツール名を許可リストで制限し、引数に含まれる値を値パターンで検査し、呼び出し履歴を利用者の名前で記録します。

### サーバー接続（SSH、SFTP）も制御できますか？

はい。サーバーの SSH ポートをサービスとして登録すると、誰がどのサーバーにどのアカウントでログインできるかを判定し、接続と実行したコマンドを監査ログに記録します。セッションの画面を録画して管理コンソールで再生できるほか、ゲートウェイが保管するパスワードや SSH 鍵を使って、サーバーに代理ログインすることもできます。SFTP でやり取りするファイルは、アップロード、ダウンロード、ファイル変更のうち許可した操作だけを通し、ファイルごとに監査ログに記録します。ポートフォワーディングは、ユーザーごとに許可した宛先（ホストとポート）にのみ接続します。

### 対象サーバーには何をインストールする必要がありますか？

インストールするプログラムはありません。ゲートウェイが SSH をクライアント側とサーバー側でそれぞれ終端するため、対象サーバーの sshd をそのまま使用します。保管した SSH 鍵で代理ログインするアカウントは、公開鍵を authorized_keys に追加します。証明書でログインするアカウントは、サーバーごとに1回、クラスターのユーザー CA を信頼するように sshd を設定します。

### SSH 以外のポートもユーザーごとに許可できますか？

現在は SSH のポートフォワーディングで対応します。ユーザーが ssh -L や ssh -D で開くフォワーディングを、ユーザーごとに許可した宛先（ホストとポート）にのみ通します。SSH を経由せずにサーバーのポート（例: Web 管理画面、Redis、RDP）へ直接接続する場合をユーザーごとに許可して記録する機能は、現在準備中です。

### セッション録画には何が残りますか？

対象サーバーが送信した画面出力とウィンドウサイズを録画し、管理コンソールで再生します。ユーザーが入力した文字は保存しないため、パスワードは残りません。ファイル転送（SFTP）は録画せず、転送したファイルごとに監査ログに記録します。録画は S3 互換ストレージに保存します。

## BeeHind の導入をご相談ください

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