DAC · Database-aware Security Gateway
DB を深く理解するセキュリティゲートウェイ
ゲートウェイが DB の通信プロトコルを直接解析し、誰が、どの DB で、どの SQL 文を実行するのかを判定します。共有アカウントの背後にいる人まで特定し、クエリ結果の個人情報をマスキングし、すべてを記録します。デスクトップエージェントを使用すれば、ユーザーは使い慣れた DB ツールと接続アドレスをそのまま使用できます。
- MySQL
- MariaDB
- PostgreSQL
- Oracle
- SQL Server
DAC(DB アクセス制御)とは
DB アクセス制御(DAC、Database Access Control)は、DB への接続を途中で制御し、監査するセキュリティ製品の分野です。ユーザー認証、コマンドの制御、マスキング、監査が主な機能です。
BeeHind の DAC は、DB の通信プロトコル(wire protocol)を直接解析します。そのため、DB やアプリケーションを変更することなく SQL 文を制御し、エイリアスや関数の背後に隠れた機密カラムまでマスキングします。
クライアントと DB の間で動作するインラインプロキシであるため、観察するだけの方式とは異なり、接続を拒否し、SQL 文をブロックし、結果をマスキングできます。DB のファイアウォールでゲートウェイからの接続のみを受け付けるように設定すれば、ゲートウェイが唯一の入口になります。
接続経路
接続元に合わせた2つの経路
社員の PC の DB ツールはデスクトップエージェントを経由して接続し、エージェントをインストールできない環境からは、管理者が発行した接続アドレスで接続します。どちらの経路にも、同じポリシーと監査が適用されます。
| 接続元 | デスクトップエージェント | ゲートウェイへの到達方法 | 利用者の識別方法 |
|---|---|---|---|
| 社員の PC の DB ツール | 必要 | エージェントが接続をインターセプトし、mTLS トンネルで送ります | 署名付きの本人証明 |
| 協力会社の PC、BI ツール | 不要 | 発行された接続アドレスに直接接続します | アドレスに割り当てた名前と許可 IP 範囲 |
| バッチサーバー | 不要 | 発行された接続アドレスに直接接続します | 許可 IP 範囲 |
エージェントを使用する場合は、DB ツールに実際の DB アドレスと普段の DB アカウントをそのまま入力します。エージェントにログインすると、インターセプトが自動的に有効になります。
制御
接続から SQL 文まで、段階ごとに判定します
ルールのない接続は拒否します。ルールが重なる場合は、最も制限の厳しいルールに従います。
アクセスルール
ユーザーまたはグループ、サービス、DB アカウントの組み合わせごとに、許可、拒否、承認が必要のいずれかを設定します。
接続の制約
接続できる IP 範囲と曜日、時間帯を設定します。許可された時間を過ぎると、開いているセッションも切断します。
DB アカウントの制御
サービスごとに使用できる DB アカウントを決めておき、それ以外のアカウントは DB に到達する前に拒否します。
SQL 制御
DELETEやDROPなどの SQL 文の種類と、正規表現のパターンで実行をブロックします。保存する前に SQL 文を入力して、ルールをテストできます。承認
アクセス申請を受け付け、多段階の承認を経た後、申請された期間に限って接続を許可します。期間が終わるとセッションを切断します。
セッション管理
現在開いているセッションを確認し、セッション単位またはユーザー単位で強制終了します。退職者のアカウントを無効にすると、セッションも切断されます。
データ保護
エイリアスや関数の背後に隠れたカラムまでマスキングします
DB が返した結果から機密性の高い値をマスキングしたうえで、ユーザーに渡します。DB やアプリケーションは変更しません。
SELECT name AS customer, grade, my_number, phone FROM customers WHERE id = 1024;DB が返した結果
| customer | grade | my_number | phone |
|---|---|---|---|
| 山田太郎 | VIP | 1234 5678 9012 | 090-1234-5678 |
ユーザーが受け取る結果
| customer | grade | my_number | phone |
|---|---|---|---|
| **** | VIP | **** **** **** | 090-1234-**** |
DELETE FROM customers WHERE id = 1024;本番 DB では DELETE 文を実行できません(SQL 制御)。
機密フィールド
氏名や住所のように、形式が一定でない値に使用します。customers.name を機密フィールドとして選択すると、エイリアス customer を付けたり関数で囲んだりしても、ゲートウェイが元のカラムをたどって(リネージ)マスキングします。
値パターン
国民識別番号、カード番号、電話番号のように形式が決まっている値は、どのカラムにあっても検出してマスキングします。個人情報と認証情報のパターンが12種類組み込まれており、正規表現で独自に追加できます。
- 元のカラムを算出できなかった SQL 文は実行せず、理由とともに拒否します。マスキングすべき値を見逃したまま通過させることはありません。
- 誰に対してマスキングするかは、ユーザーとグループ単位で設定します。マスキングした文字は
*に置き換えられ、長さはそのまま保たれます。
暗号化された接続も、内容を確認して制御します
クライアント側と DB 側の TLS を、ゲートウェイがそれぞれ確立します。ゲートウェイクラスターの認証局(クラスター CA)が証明書を発行し、有効期限が切れる前に自動で更新します。内容を確認できない接続は、既定で拒否します。
監査
誰が何をしたかを、人の名前で記録します
ゲートウェイが監査ストアに直接記録します。Management が停止しても、記録は途切れません。
記録する内容
セッションの開始と終了、実行した SQL 文、許可・拒否の判定、行数、マスキングした項目、ユーザー名とその名前の出所を記録します。
ストア
OpenSearch、Elasticsearch、リレーショナル DB に記録します。ストアが応答しない場合は、ディスクに蓄積してから再送します。
完全性
記録をハッシュチェーンでつなぎ、管理コンソールで検証します。途中の記録を改ざんしたり削除したりすると、検出されます。
閲覧の制御
監査画面でも、個人情報はマスキングして表示します。元の値は、権限を持つ人が理由を入力して1件ずつ開き、閲覧した事実も記録します。
SIEM 連携
syslog(RFC 5424)と Splunk HEC でコピーを送信します。
対応 DB
2026年10月時点
- MySQL
- エージェント、エージェントレス(サービスごとの専用ポート)
- MariaDB
- エージェント、エージェントレス(サービスごとの専用ポート)
- PostgreSQL
- エージェント、エージェントレス(共用ポート)
- Oracle
- エージェント、エージェントレス(共用ポート)、TLS(TCPS)
- SQL Server
- エージェント、エージェントレス(共用ポート)
既知の制約
- Oracle のネイティブネットワーク暗号化(Native Network Encryption)を使用する接続は、内容を確認できないため制御できません。TLS(TCPS)で接続するように構成してください。
- Oracle の OCI 方式のクライアントで接続したセッションでは、結果をマスキングできません。このようなセッションでは、マスキングが必要な照会をブロックします。
- SQL Server の TDS 8.0 strict 暗号化には、まだ対応していません。
- ゲートウェイを唯一の入口にするには、DB のファイアウォールでゲートウェイ以外の接続元を遮断する必要があります。
お客様の環境で BeeHind をお確かめください
保護したい DB、サーバー、AI サービスとネットワーク構成をお知らせいただければ、環境に合った構成と導入の進め方をご案内します。サーバー1台から始められます。