# KeeperDB
## KeeperDB KeeperDBは、Keeperのゼロ知識プラットフォーム上に構築された、安全なマルチプロトコル対応のデータベース管理ツールです。提供形態は2つあります。KeeperPAMのレコードから自動起動される**埋め込みセッション**と、macOS・Windows・Linux向けの**スタンドアロンデスクトップアプリ**です。
特権的なデータベースアクセスは、これまで企業のセキュリティ体制において最も弱い環節でした。認証情報はノートPC上の平文ファイル、キーチェーン、付箋、誰もローテーションしない共有パスワードボルトに散在します。接続は監視されていないTCP上を流れ、セッション内の操作はセキュリティチームから見えません。KeeperDBは、DBAが使いたくなるデータベースクライアントの感触を保ったまま、これらの隙間を埋めます。 {% hint style="success" %} **概要** * **対応プロトコル** — PostgreSQL、MySQL / MariaDB、SQL Server、Oracle、Amazon Redshift、SQLite * **クライアントに認証情報を置かない** — パスワードはボルトからゲートウェイ経由で暗号化のまま配信。入力もローカル保存もしません * **埋め込みKeeperAI** — スキーマを把握した会話型DBAコパイロットが、読み取り専用クエリを自律実行し、DML/DDLは明示的な同意がある場合のみ実行。話題外のコード生成はサーバー側のガードレールで防止 * **組み込みのリアルタイム監視** — プロセス一覧、ブロッキングチェーン、ロック分析、対応エンジン横断のワンクリックセッション終了 * **どこでも利用可能** — ネイティブデスクトップアプリと、KeeperPAM起動のRBIセッション内への完全埋め込み {% endhint %} ### KeeperDBとは KeeperDBは、Keeperプラットフォームに組み込まれたフル機能のデータベースクライアント兼運用監視ツールです。 **ボルトとのゼロ知識連携**
セッションはボルトから直接起動でき、パスワードレスでアクセスできます。データベースレコードの認証情報はお客様のゲートウェイ内で復号され、暗号化チャネル経由でKeeperDBに渡されます。接続はセッション録画およびKeeperAIによるセッション分析向けに構成できます。 ユーザーがPAMデータベース接続を起動すると、KeeperゲートウェイはKeeperDBをサイドカープロセスとして起動し、Keeperのリモートブラウザ分離 (RBI) レイヤーを通じてブラウザにストリーミングし、その他の特権操作と同様にセッション全体を記録します。
**単一UIからのマルチプロトコル** 同一のクエリエディター、データグリッド、ER図、スクラッチパッドのノート、パフォーマンスモニタが、PostgreSQL、MySQL、SQL Server、Oracle、Redshift、SQLiteにまたがって動作します。異種混在環境を扱うDBAがアプリを切り替える必要はありません。 **DBAコパイロットとしてのKeeperAI** スキーマの文脈を把握した埋め込みアシスタントが、自然言語の質問に答え、ユーザーの代わりにクエリの作成・実行、結果セットからのチャート生成を行います。話題外のコード生成や、明示的な承認なしの破壊的操作は、サーバー側のガードレールで禁止されます。
### 2つのデプロイモード、同一の体験 KeeperDBは次の2通りで提供されます。ボルトへの埋め込みとスタンドアロンデスクトップアプリです。いずれも同一のインターフェース、機能、セキュリティモデルを共有します。 ビジュアルテーマでユーザー好みに応じた見た目にできます。
#### KeeperPAMへの埋め込み (特権セッション) 規制対象のゼロトラスト環境向けの配備方法です。ユーザーはボルトを開き、レコード (例: *「本番 Postgres」*) を見つけて **\[KeeperDBを起動]** をクリックします。 {% hint style="info" %} **ユーザーは認証情報を扱いません。** 通信経路上も、メモリ上も、設定ファイル上も同様です。ボルトでは暗号化されたまま保管され、ゲートウェイで短時間メモリ上に復号されたあとKeeperDBへ渡り、KeeperDBでは切断時にゼロ化されます。クライアントのディスクには保存されません。 {% endhint %} #### スタンドアロンデスクトップアプリ (Mac / Windows / Linux) クロスプラットフォームのネイティブデスクトップアプリです。主な用途は以下のとおりです。 * **まだKeeperPAMを導入していないKeeperのお客様**が、ボルト連携で認証情報を取得するモダンで安全なDBクライアントを使いたい場合 * **DBA、データエンジニア、開発者**が、平文でパスワードを保存する不安定なシェアウェアのようなクライアントではなく、日々使えるクライアントを必要とする場合 * **コンサルタントや請負者**が、複数顧客のDBに接続し、顧客ごとに認証情報を分離して汚染を防ぎたい場合
{% hint style="info" %} KeeperDBデスクトップアプリのインストーラは近日公開予定です {% endhint %} | プラットフォーム | インストールリンク | | --------------------- | --------- | | macOS (Apple Silicon) | 近日公開 | | Windows (x64) | 近日公開 | | Linux | 近日公開 | デスクトップアプリからデータベースに接続する方法は3つあります。 1. **直接接続** — ユーザーが一度入力した認証情報をOSネイティブのセキュアストアに保存する、最もシンプルな流れです。DBeaverなどに慣れた人向けで、認証情報は安全に保管されます。 2. **ボルト連携** — アプリがユーザーのKeeperアカウントで認証し、PAMデータベースレコードを列挙し、クリック時に取得した一時または静的認証情報でセッションを開始します (キャッシュしません)。 3. **PAMレコード上のKeeperDBプロキシ** — 後述のセクションで説明します。 ### ユースケース: KeeperDBトンネル **Keeperトンネル**で内部DBをゲートウェイ越しに公開しているお客様にとって、KeeperDBは自然なフロントエンドです。トンネル経由のDBはユーザー端末ではローカルに見え、`127.0.0.1:` へ接続すればよいだけです。トラフィックはバイト単位でKeeperのゼロトラスト / ゼロ知識の暗号化を通り、インバウンドのファイアウォール規則もVPNも不要です。
デスクトップのKeeperDBアプリは、トンネル先エンドポイントへ、通常の直接接続と同じ要領で接続できます。ボルト連携と組み合わせると、流れは次のようになります。 1. ユーザーがボルトのPAMデータベースレコードで **\[トンネルを開始]** をクリックします。 2. Keeperゲートウェイがゼロトラストトンネルを確立し、ローカルポートをボルトに返します。 3. ユーザーがKeeperDBアプリに localhost とローカルポートを入力します。 4. ノートPCと対象DBの間のトラフィックはすべて認証され、エンドツーエンドで暗号化され、Keeperの特権セッションとして記録されます。 {% hint style="success" %} **トンネル + KeeperDBがジャンプホストに勝る理由。** 維持する踏み台サーバーがなく、SSH鍵の配布も不要です。トンネルはユーザー単位で認証され、DBセッションは記録され、案件終了時はボルトの共有を取り消すだけです。 {% endhint %} ### ユースケース: PAMレコードでのKeeperDBプロキシ デスクトップアプリの操作感と、KeeperPAMの「認証情報ゼロ・セッション記録」の両立を望むお客様向けに、PAMデータベースレコードで**KeeperDBプロキシ**を有効にします。
レコードでKeeperDBプロキシが有効な場合の動きです。 * ゲートウェイが、そのレコードのプロトコル (MySQL / PostgreSQL / MSSQLワイヤプロトコル) 用の**KeeperDBプロキシ**リスナーを立ち上げます。 * ユーザーのデスクトップKeeperDBアプリからの接続トラフィックはプロキシに向けられ、プロキシがKeeperで認証し、ゲートウェイ側で認証情報を取得し、プロトコルハンドシェイクに注入したうえで対象DBへ転送します。 * デスクトップのKeeperDBアプリはプロキシエンドポイントを向けます。**実際の認証情報は表示されず、ユーザーが入力することもありません。** 一方で、ネイティブアプリの操作感、OSレベルのキーボードショートカット、帯域制限のない通信、RBIのオーバーヘッドなしの長時間エクスポートは利用できます。 社内の**DBAやSRE**が毎日同じ本番DBを扱う構成として推奨です。 * キーチェーンにパスワードを置かない * ターミナル履歴にパスワードを残さない * コンプライアンス向けにセッションを完全記録 * デスクトップ性能 (大型ER図、長時間エクスポート、ギガバイト級の結果グリッド、ローカルファイルシステム上のオフラインNotebook作業) ### 対応データベース KeeperDBは6プロトコルをネイティブドライバでそのまま扱います。ODBCもJDBCブリッジも、ユーザー端末へのドライバインストールも不要です。 | データベース | メモ | | --------------- | --------------------------------------------- | | PostgreSQL | TLS、SCRAM-SHA-256、現行の認証方式をサポート | | MySQL / MariaDB | DDL互換のテキストプロトコル、データ用バイナリプロトコル | | SQL Server | Azure SQL、AWS RDS、オンプレ。WindowsおよびSQL Server認証 | | Oracle | Autonomous DBやExadata Cloudを含む | | Amazon Redshift | Redshift特有の挙動に対応 | | SQLite | ファイルまたはインメモリ。ローカルの作業用に適する | ### ユーザー体験 セッションの起動方法にかかわらず、同じ画面に入ります。サイドバーにスキーマとテーブル、上部タブで **\[クエリ]**、**\[データ]**、**\[ノートブック]**、**\[監視]**、**\[グラフ]** を切り替え、歯車アイコンから **\[設定]**、吹き出しアイコンからKeeperAIを開きます。 #### クエリエディター **\[クエリ]** タブはSQLワークスペースです。シンタックスハイライト、オートコンプリート、複数文の実行、表形式とレコード形式の切り替えに対応します。 * **複数文の実行** — マイグレーションスクリプトを貼り付け、**\[実行]** で文ごとの結果を取得 * **破壊的クエリの確認** — SELECT以外は、実行前にモーダルで内容を一覧表示 * **セッション単位のクエリ履歴** — 現在のユーザーセッションに紐づく。ユーザー単位またはリソース単位の永続化はデータベースレコードのPAM設定に依存 #### データグリッド サイドバーのテーブルをクリックすると **\[データ]** タブでページング付きのテーブルブラウザが開きます。 * **ページング** — 既定50行、設定で数千行まで拡張可 * **セル内編集** — セルをダブルクリックして値を編集し、実行前にプレビュー付きの `UPDATE` 文を生成 * **CSV、JSON、SQL INSERTへのエクスポート** — 現在のフィルタ / ページ状態からそのまま出力 #### スキーマエクスプローラーとER図 サイドバーは検索・並べ替え可能なスキーマとテーブルのツリーです。スキーマをクリックしてテーブル一覧、テーブルにホバーして行数とサイズ、オーバーフロー **\[...]** でテーブル定義と `CREATE` 文を表示します。 #### ノートブック (スクラッチパッド) 単一クエリに収まらない作業向けです。ノートブックはSQLセルとMarkdownセルを持つユーザー単位の永続スクラッチパッドで、2秒ごとに自動保存されます。 * 調査用の再利用クエリを蓄積 * Markdownで、SQLと並べて所見を記述 * 他のセルの状態を失わずにセル単位で再実行 * ユーザー単位またはレコード単位の永続化はPAMデータベース構成に依存 #### パフォーマンスモニター **\[監視]** タブはリアルタイムの運用ダッシュボードです。DBに負荷が集中しているときに開きたい画面です。 {% hint style="info" %} **「サイトが遅いが原因は」** — **\[監視]** タブなら数秒で把握できます。誰が接続しているか、何を実行しているか、何が何をブロックしているか、終了すべき長時間クエリはどれか。 {% endhint %} DBごとに監視機能がわずかに異なります。 | 機能 | PostgreSQL | MySQL | SQL Server | Oracle | Redshift | SQLite | | ------------ | :--------: | :---: | :--------: | :----: | :------: | :----: | | アクティブプロセス一覧 | ✅ | ✅ | ✅ | ✅ | ✅ | — | | ブロッキングチェーン | ✅ | ✅ | ✅ | ✅ | ✅ | — | | ロック分析 | ✅ | ✅ | ✅ | ✅ | ✅ | — | | セッション終了 | ✅ | ✅ | ✅ | ✅ | ✅ | — | | サーバーパラメータの確認 | ✅ | ✅ | ✅ | ✅ | ✅ | — | | AI支援トリアージ | ✅ | ✅ | ✅ | ✅ | ✅ | — | 各ライブプロセスには接続ID、ユーザー、データベース、現在実行中のSQL、経過時間が表示されます。ブロッキングチェーンのブロッカーをクリックすると全文脈を表示します。**\[Kill]** でセッションを終了します (確認あり)。 ### KeeperAI — 埋め込みDBAコパイロット KeeperAIはKeeperDBに統合されたAIアシスタントです。UI右側のチャットパネルで開き、接続先スキーマを把握し、次の3モードで動作します。 1. **チャットモード** — 自然言語で質問すると、文章で回答します (必要ならSQLも併記)。 2. **自律モード** — クエリではなく成果を依頼します。KeeperAIがSQLを書き、DBに対して実行し、結果を読み、必要なら繰り返します。読み取り専用は確認なしで実行し、書き込みは人が書いた場合と同じ破壊的クエリ確認モーダルを出します。 3. **説明モード** — SQLを貼り付けて解説を求めます。同僚のマイグレーションのレビューや、レガシースキーマへのオンボーディングに便利です。
#### 対応AIプロバイダ KeeperAIはプロバイダを差し替え可能です。管理者がデータガバナンスに合うベンダーを選びます。 * OpenAI * OpenAI互換エンドポイント (セルフホストなど) * Anthropic * Google Gemini * Microsoft Azure OpenAI * AWS Bedrock (Claude、Llama、Titan など) * Google Vertex AI KeeperゲートウェイでKeeperAIを有効化する手順は、[LLMプロバイダのセットアップ手順](/jp/keeperpam/privileged-access-manager/keeperai.md#llm-provider-setup-instructions)をご参照ください。 {% hint style="info" %} **データは自社の境界内に留まります。** エンタープライズのお客様は、KeeperAIを自社のAzure OpenAIやAWS Bedrockエンドポイントに接続でき、プロンプトとスキーマをネットワーク境界の外に出さずに済みます。 {% endhint %} #### KeeperAIのチャート生成 自律モードで *「過去30日の製品カテゴリ別売上を表示」* と依頼すると、KeeperAIは次を行います。 1. スキーマを調べ、関連テーブルを特定する 2. 集計SQLを作成して実行する 3. 結果を棒グラフとして表す `chart` JSON仕様を出力する 4. チャットパネル内にチャートを描画する 対応チャート種別は bar、line、pie、area、scatter です。根拠となるデータはライブクエリから直接取得し、数値の捏造はありません。 #### パフォーマンスモニターでのKeeperAI **\[監視]** タブから **\[KeeperAIでトリアージ]** を実行すると、現在のプロセス一覧、ブロッキングチェーン、サーバーパラメータをプロンプトにまとめ、AIに *「何が悪く、このあとどう動くべきか」* を要約させます。終了候補のクエリ、不足しているインデックス、誤設定のパラメータを提案します。 #### KeeperAIのスコープガードレール KeeperAIはデータベース作業に厳密にスコープされます。SQL、スキーマ設計、インデックス、クエリ最適化、パフォーマンスチューニング、トラブルシューティング、DB理論に関する質問に答えます。 {% hint style="warning" %} **多層防御**: KeeperAIのガードレールは2層です。システムプロンプト先頭の命令型拒否条項と、応答後にブロック内容を定型の「データベースアシスタントです…」拒否に差し替える検証層です。プロンプトインジェクションを試みても、KeeperPAMセッション内で任意のコード生成に流用されることはありません。 {% endhint %} ### KeeperAIとセッション録画 / 監視 KeeperPAMは特権セッションのキーストロークとフレームをすでに記録しています。KeeperAIの操作も同じ記録境界内にありますが、セキュリティチームがAI起点の操作だけを追えるよう、構造化された監査ログも持ちます。 * **AIが実行したSQL文**は、人が入力した場合と同様に、セッションID、文テキスト、成功フラグ、タイムスタンプで記録されます。 * **AIが起こした破壊的な文**も、人と同じ確認モーダルを通ります。書き込みの最終承認者は常にユーザーです。 * **チャート、説明、自律反復**はセッション記録に帰属し、コンプライアンスレビュアーは *「DBAがKeeperAIに30日アクティビティゼロのアカウントを探させ、KeeperAIがクエリX・Y・Zを実行し、DBAが文Wを承認した」* といった流れを単一の画面で再構成できます。 ### セキュリティ上の利点 #### 認証情報をエンドポイントに残さない | 脅威 | KeeperDBの扱い | | ----------------------- | ---------------------------------------- | | 盗難ノートPC、フォレンジックディスクイメージ | ディスク上に認証情報なし。メモリ上のパスワード素材は切断時に `zeroize` | | シェル履歴や設定ファイルの漏えい | ローカルに認証情報を保存しない | | Gitにコミットされた接続文字列 | コミットする接続文字列そのものが存在しない | | 共有パスワードの蔓延 | 起動のたびにボルトから現行パスワードを取得。1回ローテートすれば全員が新値に | | 請負者のオフボーディング | ボルト共有を取り消すだけ。DBパスワードのローテートは不要 | #### ゼロ知識とユーザー単位の分離 KeeperDBはKeeperのゼロ知識設計を継承します。シークレットの復号はユーザーのデバイスまたはお客様のゲートウェイ内のみで、Keeperのサーバー上では行われません。ゲートウェイを複数ユーザーで共有する場合も、スクラッチパッド、設定、スキーマキャッシュはユーザーごとに分離されます。 #### 監査の網羅 * **特権セッション録画** (KeeperPAM経由) が、描画された各フレームを記録 * **構造化監査ログ** (インメモリのリングバッファ、セッション単位) が、クエリ操作を記録 * **KeeperAIスコープログ**が、ガードレールの判定を記録 * **KSMアクセスログ** (Keeperの通常のKSM監査証跡) が、ボルトからの認証情報取得を記録 これらがまとめて、規制業界の *「誰が、いつ、どのDBに対して何を実行し、変更を誰が承認したか」* に、フォレンジック調査なしで答えます。 ### なぜDBeaver / DataGrip / TablePlusだけでは足りないか 汎用DBクライアントは、サンドボックスに自分のDBへ接続する開発者には優れています。エンタープライズ規模では破綻しがちです。 | 懸念 | 一般的なサードパーティ製クライアント | KeeperDB | | ------------- | ------------------------ | ------------------- | | 認証情報の保存 | ローカルキーチェーン / JSONワークスペース | クライアントに保存しない | | 認証情報のローテート | ユーザーが手で再入力 | ボルトを1回更新すれば全員が最新 | | 請負者のオフボーディング | DBパスワードをローテート | ボルト共有を取り消す | | セッション録画 | なし | あり (KeeperPAM経由) | | DBA向けAI | 有償アドオンでベンダークラウドへスキーマ送信 | 同梱。お客様のAIプロバイダに固定可能 | | 複数DBのカバー | プラグイン依存でバラつきがち | 複数プロトコルを単一UIで | | パフォーマンスモニター | 別ツールまたは未実装 | 内蔵 | | ゼロトラストなネットワーク | VPN / 踏み台が必要 | Keeperトンネルで動作 | | エンドポイントへの導入負荷 | ドライバ、JDBC jar、ODBCブリッジ | ローカルドライバゼロ。すべて同梱 | | コンプライアンス監査 | クライアント側ログがあれば限定的 | 中央集約、サーバー強制、改ざん耐性 | {% hint style="danger" %} **監査の穴はコンプライアンスリスクになります。** 監査人が過去90日間の本番DBに対する全クエリを求めても、多くのクライアントは完全な答えを出せません。KeeperDBは中央の監査証跡からその活動を返せます。 {% endhint %} ### はじめに #### KeeperPAMの `pamDatabase` レコードから 1. ボルトでPAMデータベースレコードを開きます。 2. **\[KeeperDBを起動]** をクリックします。 3. RBIのタブが開き、接続済みのKeeperDBが表示されます。 ユーザー側のセットアップは不要です。管理者がレコードを一度構成すれば (ホスト、ポート、プロトコル、認証情報、JIT、ワークフロー、KeeperAI)、ゲートウェイ側のポリシーが起動権限を制御します。 ### よくある質問
KeeperDBにはKeeperエンタープライズのサブスクリプションが必要ですか？ 埋め込みのKeeperPAM体験にはKeeperPAMが必要です。スタンドアロンデスクトップアプリは、シークレットマネージャーのレコード取得に対応するKeeperアカウント層で動作し、Keeperアカウントなしの純ローカルモードでも利用できます。
データはどこに保存されますか？ 行データはKeeperDBが永続化しません。DBからUIへストリームされ、アクティブなセッション中のみメモリに保持されます。ユーザー固有のアーティファクト (ノートブックセル、UI設定) は、エンタープライズ既定ではKeeperシークレットマネージャーのボルト、デスクトップアプリではユーザーのローカルファイルシステム、一時モードではメモリに保存されます。
KeeperAIを自社のAzure OpenAIエンドポイントに向けられますか？ はい。KeeperAIはAzure OpenAI、AWS Bedrock、Vertex AI、およびOpenAI互換のセルフホストエンドポイントを第一級のプロバイダとして扱います。構成はデプロイ単位で、KeeperがホストするAIサービスへトラフィックはルーティングされません。
AIプロバイダが利用できない場合はどうなりますか？ KeeperDBは通常どおり動作します。AIチャットパネルは「利用不可」状態を示しますが、クエリエディター、データグリッド、監視、ER図、スクラッチパッド、インポート/エクスポートなど、その他の機能は動き続けます。
スタンドアロンのデスクトップアプリは、ボルトにないデータベースにも接続できますか？ はい。デスクトップアプリは、ユーザー入力の認証情報による直接接続 (OSセキュアストアに保存、`zeroize` 規律)、Keeperトンネル経由の接続、PAMレコードのプロキシ経由の接続をサポートします。1つのインストールで3つを同時に使えます。
破壊的クエリの確認は、KeeperAIの自律モードでも同じですか？ 人が入力した場合と同じです。KeeperAIは読み取り専用クエリ (`SELECT`、`SHOW`、`EXPLAIN`、`DESCRIBE`) を確認なしで実行できます。書き込み (`INSERT`、`UPDATE`、`DELETE`、`DROP`、`CREATE`、`ALTER`、`TRUNCATE`、方言特有の `BULK INSERT` / `COPY … FROM` / `LOAD DATA` など) は、実行前に正確なSQLを示すモーダルを表示します。承認者は常にユーザーです。
KeeperDBトンネルとKeeperDBプロキシの違いは何ですか？ **トンネル**は、ユーザー端末のローカルポートでDBのネイティブワイヤプロトコルを公開します。デスクトップアプリは `127.0.0.1` に向けて、DBがローカルにあるかのように話し、認証情報はユーザー由来です (手入力またはアプリ層でボルトから取得)。 **KeeperDBプロキシ**はゲートウェイで認証情報注入を追加します。デスクトップアプリはプロキシに接続し、プロキシがKeeperで認証してサーバー側で認証情報を取得し、ユーザーのマシンがパスワードに触れないままDBハンドシェイクを完了します。KeeperDBプロキシのほうがゼロトラストとして厳格な構成です。
KeeperAIの挙動を監査できますか？ はい。AIのやり取りはセッション記録と、承認したユーザーに紐づく監査ログに現れます。
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.keeper.io/jp/keeperpam/privileged-access-manager/keeperdb.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.