仕組み

3つの構成要素が経路をつくります

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

構成要素

3つの構成要素の役割

すべての接続に3つの構成要素がすべて必要なわけではありません。エージェントをインストールできない接続は、発行アドレスや仮想キーでゲートウェイに直接接続します。

社内ネットワークインターネット本番 DB ゾーンサーバーゾーンDMZManagement管理コンソール、ポリシー、アカウント監査ストアOpenSearch など、SIEM へコピー異常行動検知署名付きポリシー監査記録ゲートウェイクラスターDACノード3台ゲートウェイクラスターServer Gatewayノード2台ゲートウェイクラスターAI Gatewayノード2台OraclePostgreSQLMySQLweb-01web-02batch-01OpenAIAnthropicGoogle Gemini外部の AI サービスDB ツールssh、sftpAI アプリ社員の PCデスクトップエージェントがサービスごとに担当クラスターへトンネルを開きます仮想キー社内アプリ、バッチ仮想キーで LLM API を呼び出し
  • 制御される接続
  • ポリシー配布
  • 監査記録

制御と監視 · Data plane

ゲートウェイ Gateway

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

役割

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

管理 · Control plane

Management 管理コンソールを含む

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

役割

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

本人確認 · ユーザーの PC

デスクトップエージェント Desktop Agent

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

役割

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

    DB、サーバー、AI サービスへ向かうデータは、ゲートウェイだけを通過します。Management が停止しても、稼働中のゲートウェイは受け取り済みのポリシーで制御と記録を続けます。

  • エージェントは接続をブロックする装置ではありません

    エージェントは、接続をゲートウェイに送り、本人を証明します。ほかの経路を遮断するのは DB とサーバーのファイアウォールです。

  • ユーザーは接続アドレスを変更しません

    DB ツールや ssh には、実際のアドレスと普段のアカウントをそのまま入力します。エージェントにログインすると、インターセプトが自動的に有効になります。

処理の流れ

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

開発者が PC の DB ツールで本番 DB に接続し、データを照会する場合を例に、流れを追います。

  1. 1

    ログイン

    ユーザーが会社のアカウントでデスクトップエージェントにログインします。Management は、接続可能なサービスの一覧と署名付きの本人証明を渡します。

  2. 2

    接続の開始

    ユーザーが DB ツールに実際の DB アドレスと DB アカウントを入力して接続します。エージェントは、登録されたサービスへの接続のみをインターセプトします。

  3. 3

    トンネル

    エージェントが担当ゲートウェイへの相互 TLS(mTLS)トンネルを開き、先頭に本人証明と本来の接続先を付けて送ります。

  4. 4

    接続の判定

    この人がこのサービスにこの DB アカウントで接続してよいかを、接続元と時間帯まで含めてゲートウェイが判定します。許可されない場合は、DB に到達する前に切断します。

  5. 5

    ログインの中継

    ゲートウェイが DB に接続し、ログインの手順をそのまま中継します。パスワードが正しいかどうかは DB が判断します。

  6. 6

    SQL 制御

    SQL 文を実行するたびに、禁止された種類の文でないかを確認します。

  7. 7

    結果のマスキング

    DB が返した結果から機密性の高い値をマスキングしたうえで、ユーザーに渡します。

  8. 8

    監査記録

    セッション、SQL 文、判定結果、行数を、ユーザー名とともに監査ストアに記録します。

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

導入形態

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

どこに導入しても、稼働するのは Management 1台とゲートウェイです。ネットワークごとにゲートウェイクラスターを設置し、1台の Management が全体を管理します。

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

設計原則

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

BeeHind の設計は、5つの原則に従っています。

  1. 01

    DB のパスワードを集約しません

    ゲートウェイは、ユーザーの DB へのログインを代行せず、そのまま中継します。パスワードが正しいかどうかは DB が判断します。パスワードを1か所に集めると、そこが攻撃の標的になるためです。

  2. 02

    分からなければブロックします

    解析できなかった SQL 文や、内容を確認できない接続を通過させることはありません。マスキングすべきカラムが結果のどの列にあるかを算出できなければ、その SQL 文を拒否します。

  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 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
判断できないときに、許可せず拒否する方式です。「分からなければブロックする」という原則の別名です。

お客様の環境で BeeHind をお確かめください

保護したい DB、サーバー、AI サービスとネットワーク構成をお知らせいただければ、環境に合った構成と導入の進め方をご案内します。サーバー1台から始められます。