BeeHind とは何ですか?
BeeHind は、DB アクセス制御(DAC)、AI ゲートウェイ(AI Gateway)、サーバーアクセス制御(Server Gateway)を1つにまとめたセキュリティゲートウェイです。人やアプリケーションからデータベース、AI サービス、サーバーへの接続がゲートウェイを通過する間に、本人を確認し、ポリシーで許可またはブロックし、個人情報をマスキングし、監査ログを記録します。ゲートウェイ、Management、デスクトップエージェントで構成されます。
FAQ
ここにないご質問は、導入のご相談フォームからお寄せください。
BeeHind は、DB アクセス制御(DAC)、AI ゲートウェイ(AI Gateway)、サーバーアクセス制御(Server Gateway)を1つにまとめたセキュリティゲートウェイです。人やアプリケーションからデータベース、AI サービス、サーバーへの接続がゲートウェイを通過する間に、本人を確認し、ポリシーで許可またはブロックし、個人情報をマスキングし、監査ログを記録します。ゲートウェイ、Management、デスクトップエージェントで構成されます。
違いは3つあります。1つ目に、コンテナとして導入する構造で設計しており、ネットワークごとにゲートウェイクラスターを設置し、1台の Management で全体を管理します。2つ目に、クエリ結果の各列がどの元のカラムに由来するかを算出し(リネージ)、エイリアスや関数の背後に隠れた機密カラムまでマスキングします。3つ目に、DB アクセス制御、AI ゲートウェイ、サーバーアクセス制御を1つの製品として提供するため、ユーザー一覧、ポリシー画面、監査ストア、デスクトップエージェントをそれぞれ1つだけ運用すれば済みます。
はい。Management が DAC、AI Gateway、Server Gateway の監査記録を検知ルールと照合し、ブロックされた試行、機密情報の大量照会、業務時間外のアクセス、新しい IP からの接続などの行為を、人ごとのレビュー件にまとめます。レビュー担当者は本人に申告を依頼してレビュー結果を記録し、毎月1日に前月の月次点検レポートが作成されます。
MySQL、MariaDB、PostgreSQL、Oracle、SQL Server に対応しています。ゲートウェイが各 DB の通信プロトコル(wire protocol)を直接解析するため、JDBC ドライバーや DB 側へのインストールは必要ありません。
デスクトップエージェントを使用する場合は、変更する必要はありません。DB ツールに実際の DB アドレスと普段の DB アカウントをそのまま入力し、エージェントにログインすると、インターセプトが自動的に有効になります。エージェントを使わずに接続する場合は、ホストとポートをゲートウェイに変更します。PostgreSQL、Oracle、SQL Server では DB 名の前に発行された UUID を付け、MySQL と MariaDB ではサービスごとに割り当てられた専用ポートに接続します。
管理者が発行した接続アドレスで、ゲートウェイに直接接続します(エージェントレス)。アドレスごとに、監査ログに記録する名前と接続を許可する IP 範囲を設定します。アクセスルール、SQL 制御、マスキングは、エージェントを使用する場合と同じように適用されます。
サーバー1台に Docker Compose で Management、ゲートウェイ、PostgreSQL、Caddy をまとめてインストールする形態と、ゲートウェイを Linux VM に systemd サービスとしてインストールする形態を提供しています。Kubernetes(Helm)、AWS、Azure 向けのテンプレートは準備中です。
はい。Management とゲートウェイは、実行中に外部ネットワークへアクセスしません。イメージとインストールスクリプトを一式にまとめて持ち込み、インストールします。
サーバー1台で、本番 DB 1つから始めることをおすすめします。その後、エージェントを使わずに接続する環境を追加し、ネットワークごとにゲートウェイを増やし、AI サービスを登録します。導入のご相談をお寄せいただければ、環境に合った構成をご案内します。
いいえ。ライセンスで確認するのは利用期間のみです。期間が終わっても、接続制御と監査は停止しません。
ユーザーの DB パスワードは保管しません。ゲートウェイは DB へのログインを代行せず、クライアントと DB の間でそのまま中継します(認証の中継)。パスワードが正しいかどうかは DB が判断します。テーブルのカラムごとにマスキングを設定する場合は、任意で参照用アカウントを登録できます。管理者が登録したこのアカウントのパスワードは暗号化して保管し、担当ゲートウェイにのみ渡します。
はい。ゲートウェイが必要に応じてスキーマを読み取り、クエリ結果の各列がどの元のカラムに由来するかを算出して、結果の位置に基づいてマスキングします。算出できなかった SQL 文は、マスキングすべき値を見逃さないよう、理由とともに拒否します。国民識別番号のように形式が決まっている値は、どのカラムにあっても値パターンで検出します。
はい。ゲートウェイがクライアント側と DB 側の TLS をそれぞれ確立し、内容を確認して制御します。証明書はゲートウェイクラスターの認証局が発行し、自動で更新します。内容を確認できない接続は、黙って通過させることなく拒否します。
稼働中のゲートウェイは受け取り済みのポリシーで判定を続け、監査ログも監査ストアに直接記録します。承認期間が終わったセッションの切断も、ゲートウェイが自ら行います。ただし、ログインとポリシーの変更は、Management が復旧してから行えます。
ゲートウェイが、OpenSearch、Elasticsearch、リレーショナル DB(PostgreSQL、MySQL、MariaDB、Oracle)のうち選択したストアに直接記録します。記録はハッシュチェーンでつないで完全性を検証し、syslog(RFC 5424)や Splunk HEC で SIEM にコピーを送信します。
デスクトップエージェントが AI サービスへの接続をゲートウェイに送ると、ゲートウェイがリクエストを読み取ってユーザーとモデルを確認し、プロンプトに含まれる個人情報と認証情報を値パターンで検査します。パターンごとに、ブロック、マスキング、検出のみから選択します。内容を読み取れるのは、OpenAI 互換 API、Anthropic API、claude.ai Web アプリです。
はい。企業の実際のキー(組織キー)はゲートウェイだけが使用し、ユーザーとアプリケーションには仮想キーを発行します。ゲートウェイがリクエストを送信する際に、組織キーに置き換えます。仮想キーは個別に失効させることができ、ユーザーやサービスごとにモデルと利用上限を設定できます。
はい。ネットワーク経由で呼び出す MCP サーバー(Streamable HTTP)をサービスとして登録すると、ツール名を許可リストで制限し、引数に含まれる値を値パターンで検査し、呼び出し履歴を利用者の名前で記録します。
はい。サーバーの SSH ポートをサービスとして登録すると、誰がどのサーバーにどのアカウントでログインできるかを判定し、接続と実行したコマンドを監査ログに記録します。セッションの画面を録画して管理コンソールで再生できるほか、ゲートウェイが保管するパスワードや SSH 鍵を使って、サーバーに代理ログインすることもできます。SFTP でやり取りするファイルは、アップロード、ダウンロード、ファイル変更のうち許可した操作だけを通し、ファイルごとに監査ログに記録します。ポートフォワーディングは、ユーザーごとに許可した宛先(ホストとポート)にのみ接続します。
インストールするプログラムはありません。ゲートウェイが SSH をクライアント側とサーバー側でそれぞれ終端するため、対象サーバーの sshd をそのまま使用します。保管した SSH 鍵で代理ログインするアカウントは、公開鍵を authorized_keys に追加します。証明書でログインするアカウントは、サーバーごとに1回、クラスターのユーザー CA を信頼するように sshd を設定します。
現在は SSH のポートフォワーディングで対応します。ユーザーが ssh -L や ssh -D で開くフォワーディングを、ユーザーごとに許可した宛先(ホストとポート)にのみ通します。SSH を経由せずにサーバーのポート(例: Web 管理画面、Redis、RDP)へ直接接続する場合をユーザーごとに許可して記録する機能は、現在準備中です。
対象サーバーが送信した画面出力とウィンドウサイズを録画し、管理コンソールで再生します。ユーザーが入力した文字は保存しないため、パスワードは残りません。ファイル転送(SFTP)は録画せず、転送したファイルごとに監査ログに記録します。録画は S3 互換ストレージに保存します。
保護したい DB、サーバー、AI サービスとネットワーク構成をお知らせいただければ、環境に合った構成と導入の進め方をご案内します。サーバー1台から始められます。