### セキュリティ上の利点
#### 認証情報をエンドポイントに残さない
| 脅威 | KeeperDBの扱い |
| ----------------------- | ---------------------------------------- |
| 盗難ノートPC、フォレンジックディスクイメージ | ディスク上に認証情報なし。メモリ上のパスワード素材は切断時に `zeroize` |
| シェル履歴や設定ファイルの漏えい | ローカルに認証情報を保存しない |
| Gitにコミットされた接続文字列 | コミットする接続文字列そのものが存在しない |
| 共有パスワードの蔓延 | 起動のたびにボルトから現行パスワードを取得。1回ローテートすれば全員が新値を使う |
| 請負者のオフボーディング | ボルト共有を取り消すだけ。データベースパスワードのローテートは不要 |
#### ゼロ知識とユーザー単位の分離
KeeperDBはKeeperのゼロ知識設計に基づきます。シークレットの復号はユーザーのデバイスまたはお客様のゲートウェイ内のみで行われ、Keeperのサーバー上では行われません。ゲートウェイを複数ユーザーで共有する場合も、スクラッチパッド、設定、スキーマキャッシュはユーザーごとに分離されます。
#### 監査の網羅
* **特権セッション録画** (KeeperPAM経由): 描画された各フレームを記録
* **構造化監査ログ** (インメモリのリングバッファ、セッション単位): クエリ操作を記録
* **KeeperAIスコープログ:** ガードレールの判定を記録
* **KSMアクセスログ** (Keeperの通常のKSM監査証跡): ボルトからの認証情報取得を記録
これらを合わせると、規制業界の *「誰が、いつ、どのデータベースに対して何を実行し、変更を誰が承認したか」* に、フォレンジック調査なしで答えられます。
### なぜDBeaver / DataGrip / TablePlusだけでは足りないか
汎用のデータベースクライアントは、自分のサンドボックスDBに接続する開発者には適しています。エンタープライズ規模では力不足になりがちです。
| 懸念 | 一般的なサードパーティ製クライアント | KeeperDB |
| ------------- | ------------------------ | ------------------- |
| 認証情報の保存 | ローカルキーチェーン / JSONワークスペース | クライアントに保存しない |
| 認証情報のローテート | ユーザーが手で再入力 | ボルトを1回更新すれば全員が最新 |
| 請負者のオフボーディング | データベースパスワードをローテート | ボルト共有を取り消す |
| セッション録画 | なし | あり (KeeperPAM経由) |
| DBA向けAI | 有償アドオンでベンダークラウドへスキーマ送信 | 同梱。お客様のAIプロバイダに固定可能 |
| 複数DBのカバー | プラグイン依存でバラつきがち | 複数プロトコルを単一UIで |
| パフォーマンスモニター | 別ツールまたは未実装 | 内蔵 |
| ゼロトラストなネットワーク | VPN / 踏み台が必要 | Keeperトンネルで動作 |
| エンドポイントへの導入負荷 | ドライバ、JDBC jar、ODBCブリッジ | ローカルドライバ不要。すべて同梱 |
| コンプライアンス監査 | クライアント側ログがあれば限定的 | 中央集約、サーバー強制、改ざん耐性 |
{% hint style="danger" %}
**監査の穴があると、コンプライアンスリスクになります。** 監査人が過去90日間の本番データベースに対する全クエリを求めても、多くのクライアントでは完全な答えを出せません。KeeperDBなら、中央の監査証跡からその活動を確認できます。
{% endhint %}
### はじめに
#### KeeperPAMレコードから
1. ボルトでPAMデータベースレコードを開きます。
2. **\[KeeperDBを起動]** をクリックします。
3. RBIのタブが開き、接続済みのKeeperDBが表示されます。
ユーザー側のセットアップは不要です。管理者がレコードを一度構成すれば (ホスト、ポート、プロトコル、認証情報、JIT、ワークフロー、KeeperAI)、ゲートウェイ側のポリシーで起動権限を制御できます。
### よくある質問
KeeperDBにはKeeperエンタープライズのサブスクリプションが必要ですか？
ボルトから起動する埋め込み型のKeeperDBを使うには、KeeperPAMが必要です。スタンドアロンのデスクトップアプリは、シークレットマネージャーでレコードを取得できるKeeperアカウントであれば利用でき、Keeperアカウントなしのローカル専用モードでも使えます。
データはどこに保存されますか？
行データはKeeperDBに保存されません。データベースから画面へストリームされ、セッションが有効なあいだだけメモリに保持されます。ノートブックのセルや画面設定などユーザー固有のデータは、エンタープライズ環境の既定ではKeeperシークレットマネージャーのボルトに、デスクトップアプリではローカルのファイルシステムに、一時モードではメモリに保存されます。
KeeperAIを自社のAzure OpenAIエンドポイントに接続できますか？
はい。KeeperAIでは、Azure OpenAI、AWS Bedrock、Vertex AI、OpenAI互換のセルフホストエンドポイントをプロバイダとして利用できます。設定はデプロイごとに行い、通信がKeeper側のAIサービスへ送られることはありません。
AIプロバイダが利用できない場合はどうなりますか？
KeeperDB自体は通常どおり動作します。AIチャットパネルには「利用不可」と表示されますが、クエリエディター、データグリッド、監視、ER図、スクラッチパッド、インポート/エクスポートなど、その他の機能は引き続き使えます。
スタンドアロンのデスクトップアプリは、ボルトにないデータベースにも接続できますか？
はい。デスクトップアプリでは、以下の3通りの接続ができます。ユーザーが入力した認証情報による直接接続 (OSのセキュアストアに保存し、破棄時に `zeroize`)、Keeperトンネル経由の接続、PAMレコードのKeeperDBプロキシ経由の接続です。1つのインストールで3つを同時に使えます。
KeeperAIの自律モードでも、破壊的クエリの確認は行われますか？
人が入力したSQLと同じ扱いです。KeeperAIでは読み取り専用クエリ (`SELECT`、`SHOW`、`EXPLAIN`、`DESCRIBE`) を確認なしで実行できます。一方、書き込み系 (`INSERT`、`UPDATE`、`DELETE`、`DROP`、`CREATE`、`ALTER`、`TRUNCATE`、および `BULK INSERT` / `COPY … FROM` / `LOAD DATA` など方言固有の文) は、実行前に実際のSQLを示す確認ダイアログが表示されます。承認するのは常にユーザーです。
KeeperDBトンネルとKeeperDBプロキシの違いは何ですか？
**トンネル**では、ユーザー端末のローカルポートでデータベース本来の接続プロトコルが公開されます。デスクトップアプリから `127.0.0.1` に接続し、あたかもデータベースが手元にあるかのように利用できます。認証情報はユーザー側から供給されます (手入力、またはアプリ経由でボルトから取得)。
**KeeperDBプロキシ**では、ゲートウェイ側で認証情報が注入されます。デスクトップアプリからプロキシに接続すると、プロキシ側でKeeper認証とサーバー側での認証情報取得が行われ、ユーザーの端末がパスワードに触れることなくデータベースのハンドシェイクが完了します。より厳格なゼロトラスト構成です。
KeeperAIの操作を監査できますか？
はい。AIの操作はセッション録画と、承認したユーザーに紐づく監査ログに記録されます。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## 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, and the optional `goal` query parameter:
```
GET https://docs.keeper.io/keeperpam/jp/privileged-access-manager/keeperdb.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.