企業のデジタル資産を守る セキュリティゲートウェイ
データベース、AI サービス、サーバーへのアクセスに対するアクセスポリシー、監査、マスキング、異常行動検知をまとめて提供するワンストップサービス
orders=> SELECT name AS customer, grade, my_number, phone FROM customers WHERE id = 1024; customer | grade | my_number | phone ----------+-------+----------------+--------------- **** | VIP | **** **** **** | 090-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 ポート準備中
すべての接続がゲートウェイで通る4つの段階
例:kim.dev@corp による orders-db の参照
- 01
本人確認
共有アカウントの背後にいる実際の人物を特定します。
kim.dev@corp - 02
ポリシー判定
接続、SQL 文、サーバーコマンド、AI リクエストをルールに従って許可またはブロックします。
SELECT 許可 - 03
結果のマスキング
クエリ結果やプロンプトに含まれる個人情報をマスキングします。
090-1234-**** - 04
監査記録
誰が、いつ、何をしたかを1つの監査ストアに記録します。
1 row · 記録済み
BeeHind とは
DB、AI、サーバーへのアクセスを制御し、異常行動まで見つけ出すオールインワンのセキュリティゲートウェイ
BeeHind は、DAC(DB アクセス制御)、AI Gateway、Server Gateway を1つの製品として提供します。3つの製品がユーザー、ポリシー、監査記録を共有し、集まった記録から異常行動を見つけ出します。
3製品で1つずつだけ使用
- ユーザー一覧
- ポリシー画面
- 監査ストア
- デスクトップエージェント
- 退職者のアカウントを無効にすれば、DB、サーバー、AI への接続がまとめてブロックされます。
- 同じ人の SQL 文、サーバーコマンド、AI への質問を1つの名前で検索できます。
解決する課題
重要なデータが行き交う経路が、無防備なままです
DB、サーバー、AI サービスは、企業の重要なデータが出入りする場所です。しかし多くの組織では、この経路が次のような状態のまま残されています。
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つの経路を守ります
3つの製品が、同じユーザー一覧、同じポリシー画面、同じ監査ストア、同じデスクトップエージェントを使用します。国民識別番号を検出するルール1つを、DB のクエリ結果と AI のプロンプトに共通で適用します。
DAC
DB アクセス制御
DB の通信プロトコルを直接解析し、接続、SQL 文、クエリ結果を制御します。
- アクセスルールと時間帯・IP の制約
- SQL 文の種類とパターンによる制御
- リネージに基づく結果のマスキング
- アクセス申請と多段階承認
AI Gateway
AI ゲートウェイ
LLM API、社員が使用する AI アプリ、MCP ツール呼び出しを同じ方法で判定し、記録します。
- 仮想キーによる企業の API キーの保護
- モデルの制限と利用上限
- プロンプトと回答の値パターンによるマスキング
- MCP ツールの許可リスト
Server Gateway
サーバーアクセス制御
誰がどのサーバーにどのアカウントでログインできるかを判定し、接続、実行したコマンド、やり取りしたファイルを記録します。
- サーバーとアカウント単位のアクセスルール
- コマンドの制御とセッション録画
- ファイル転送(SFTP)の制御
- ポートフォワーディングの宛先制限
- 保管した鍵による代理ログイン
異常行動検知
3つの経路の記録は、最終的に「誰がどのような異常行動をしたか」に行き着きます
ブロックして記録するだけでは終わりません。DAC、AI Gateway、Server Gateway が残した監査記録を人単位で集めて検知ルールと照合し、本人の申告とレビュー結果、月次点検レポートまでを1つの製品の中でつなぎます。
標準で提供する検知ルール
- ブロックされた SQL の実行試行
- 制限されたサーバーコマンドの実行試行
- AI への機密情報の送信試行
- 許可されていない接続の試行
- ゲートウェイでブロックされた接続の試行
- 機密情報の頻繁な照会
- 機密情報の大量照会
- 業務時間外のアクセス
- 新しい IP 範囲からの接続
kim.dev@corp
- 行為
- 機密情報の大量照会
- 条件
- 60分以内に1,000行以上
- 接続先
- orders-db (PostgreSQL)
- 時刻
- 22:14、業務時間外
- 返却行数
- 1,240行
説明のための例です。人の名前と数値は実際の記録ではありません。
仕組み
すべての接続がゲートウェイを通過します
以下は構成の一例です。本番 DB ゾーン、サーバーゾーン、インターネットへ出る DMZ にゲートウェイクラスターを1つずつ設置し、1台の Management が3つのクラスターを管理します。サーバー1台に設置した1つのクラスターで、3つすべてを担当することもできます。
- 制御される接続
- ポリシー配布
- 監査記録
社員の PC のデスクトップエージェントは、サービスごとに担当クラスターへトンネルを開きます。各クラスターは、Management から自分が担当するサービスの署名付きポリシーのみを受け取り、監査ログを監査ストアに直接記録します。エージェントをインストールできないアプリやバッチは、発行アドレスや仮想キーでクラスターに直接接続します。
制御と監視
ゲートウェイ
DB、サーバー、AI サービスの前段で動作するプロキシサーバーです。ネットワークごとにクラスターとして設置します。制御と記録が実際に行われる場所です。
管理
Management
ポリシーとアカウントを管理するサーバーです。管理者が使用する管理コンソールも含まれています。
本人確認
デスクトップエージェント
社員の PC にインストールするアプリです。接続しているのが誰なのかを、ゲートウェイに証明します。
活用事例
小さく始めて、全社へ広げます
サーバー1台で本番 DB 1つの制御から始め、複数のネットワークにまたがる構成や AI サービスの制御まで、同じ製品で広げていけます。
- DB
サーバー1台で始める
サーバー1台に Management とゲートウェイを一緒にインストールし、そのサーバーを本番 DB への唯一の入口にします。踏み台サーバーが担っていた役割を、BeeHind が引き受けるのと同じです。
- サーバー
サーバーへの接続を人単位で制御する
サーバーの SSH をサービスとして登録すると、誰がどのサーバーにどのアカウントでログインしたか、何を実行し、どのファイルをやり取りしたかが、人の名前で記録されます。踏み台サーバーが担っていた役割を、ゲートウェイが引き受けます。
- AI
社員が使用する AI アプリから何が送られるかを制御する
デスクトップエージェントが AI サービスへの接続をゲートウェイに送ると、DB への接続と同じ方法で判定し、マスキングし、記録します。社員がアプリの設定を変更する必要はありません。
- DB + サーバー + AI
DB、サーバー、AI を一元的に制御する
接続元が誰であっても、保護対象が DB でもサーバーでも AI サービスでも、同じユーザー一覧、同じポリシー画面、同じ監査ストアを使用します。
設計原則
経路上に置く製品は、それ自体が信頼できるものでなければなりません
BeeHind の設計は、5つの原則に従っています。
- 01
DB のパスワードを集約しません
ゲートウェイは、ユーザーの DB へのログインを代行せず、そのまま中継します。パスワードが正しいかどうかは DB が判断します。パスワードを1か所に集めると、そこが攻撃の標的になるためです。
- 02
分からなければブロックします
解析できなかった SQL 文や、内容を確認できない接続を通過させることはありません。マスキングすべきカラムが結果のどの列にあるかを算出できなければ、その SQL 文を拒否します。
- 03
Management が停止しても制御は続きます
Management は接続経路上にありません。稼働中のゲートウェイは受け取り済みのポリシーで判定を続け、監査ログも監査ストアに直接記録します。
- 04
ポリシーは署名を確認してから適用します
Management がポリシーに署名し、ゲートウェイは署名を検証したポリシーのみを適用します。スキーマを読み取る参照用アカウントのパスワードと AI サービスの API キーはポリシーに含めず、暗号化したうえで担当ゲートウェイにのみ個別に渡します。
- 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 転送
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 のパスワードを保管しますか?
ユーザーの DB パスワードは保管しません。ゲートウェイは DB へのログインを代行せず、クライアントと DB の間でそのまま中継します(認証の中継)。パスワードが正しいかどうかは DB が判断します。テーブルのカラムごとにマスキングを設定する場合は、任意で参照用アカウントを登録できます。管理者が登録したこのアカウントのパスワードは暗号化して保管し、担当ゲートウェイにのみ渡します。
サーバー接続(SSH、SFTP)も制御できますか?
はい。サーバーの SSH ポートをサービスとして登録すると、誰がどのサーバーにどのアカウントでログインできるかを判定し、接続と実行したコマンドを監査ログに記録します。セッションの画面を録画して管理コンソールで再生できるほか、ゲートウェイが保管するパスワードや SSH 鍵を使って、サーバーに代理ログインすることもできます。SFTP でやり取りするファイルは、アップロード、ダウンロード、ファイル変更のうち許可した操作だけを通し、ファイルごとに監査ログに記録します。ポートフォワーディングは、ユーザーごとに許可した宛先(ホストとポート)にのみ接続します。
社員の AI 利用はどのように制御しますか?
デスクトップエージェントが AI サービスへの接続をゲートウェイに送ると、ゲートウェイがリクエストを読み取ってユーザーとモデルを確認し、プロンプトに含まれる個人情報と認証情報を値パターンで検査します。パターンごとに、ブロック、マスキング、検出のみから選択します。内容を読み取れるのは、OpenAI 互換 API、Anthropic API、claude.ai Web アプリです。
お客様の環境で BeeHind をお確かめください
保護したい DB、サーバー、AI サービスとネットワーク構成をお知らせいただければ、環境に合った構成と導入の進め方をご案内します。サーバー1台から始められます。