一般的なベストプラクティス記事は、何を付与すべきかを説明します。監査に耐える実践は、何をレビューすべきかを説明します。本ガイドは後者を扱います — 本番グレードのデータベースアクセス制御 (DAC)が、マシン、人、AI エージェントのワークロードでどう見えるか、そして SOC 2、HIPAA、GDPR の監査を落とすミスを整理します。
注: セキュリティ文献では "DAC" は任意アクセス制御 (discretionary access control) — MAC や RBAC と対比される制御モデル — を指すこともあります。本ガイドではすべて「データベースアクセス制御」の意味で DAC を使います。
これらを誤ると、DROP TABLE 1 発で本番障害、または 1 件の資格情報漏洩でコンプライアンス違反になります。多くのチームは共有 admin アカウントといくつかのアプリケーション資格情報から始めます。それは最初の SOC 2 監査 で「3 月 3 日にこのクエリを誰が実行したか？」と聞かれ、誰も答えられない瞬間まで通用します。
コア原則
最小権限
すべてのユーザーとアプリケーションは、その仕事を遂行するために必要な最小限の権限しか持ちません。ステージング DB に対して SELECT を実行する開発者には、本番に対する DROP や ALTER は要りません。
実務上の最小権限とは:
- アプリケーションアカウントは使用するテーブルへの
SELECT、INSERT、UPDATE、DELETEのみを持つ - スキーママイグレーション用アカウントはアプリケーションアカウントと分ける
- 読み取り専用レプリカは書けない資格情報を使う
- Admin アクセスは DBA に限定し、永続ではなくセッション単位で付与する
接続だけでなく文の単位で強制する
恒久的・一時的を問わず、付与はロールが何をできるかを述べるだけです。特定の主体が、特定のテーブルに対して、いまその文を実行してよいかは述べていません。本番グレードの DAC は SQL そのものをレビューします。
- スキーマ変更は提案・レビュー・承認を経てから実行される
- 機微なクエリは SQL レビュールールでフラグまたはブロックされる
- 本番データの書き換えは申請に承認の参照を要求する
- **マスクされたカラム**は、ロールにそのテーブルへの
SELECTがあってもマスクされたままにする
接続時の制御 (RBAC、PAM、VPN) は必要ですが十分ではありません。すべての文が統制ポイントです。
職務分掌
データベース変更を書く人が、その承認とデプロイをしません。これは事故と意図的な濫用の両方を防ぎます。
典型的な分掌:
- 開発者がマイグレーション SQL を書く
- DBA またはテックリードが正しさと安全性のために SQL をレビューする
- 自動パイプラインまたは別ロールが承認済みの変更を実行する
- **監査ログ**が各ステップの誰が何をしたかを記録する
Just-in-Time アクセス
恒久的に存在するアクセスが多くの組織のデフォルトであり、それは間違ったデフォルトです。6 ヶ月前にデバッグセッションで本番 DB にアクセスした開発者は、おそらくまだその資格情報を持っています。その資格情報が漏れれば、被害範囲は本番データセット全体です。
Just-in-Time (JIT) アクセスは、恒久的な資格情報を一時的でスコープ付きの付与に置き換えます。
- ユーザーが特定 DB へのアクセスを理由付きで申請する
- 承認者が申請をレビューし承認する
- システムが時間制限 (例: 2 時間) 付きでアクセスを付与する
- 期間終了で自動的に失効する
JIT は常設の権限をゼロ近くまで減らします。すべてのアクセスイベントに記録された理由と承認チェーンがあるため、監査官に好まれます。
ロールベースアクセス制御 (RBAC)
ユーザーごとに権限を管理するのはスケールしません。RBAC は権限をロールにまとめ、ユーザーにロールを割り当てます。チームに加入した人はそのチームのロールを継承し、離脱時はロールの取り消しだけで関連権限が一度に外れます。
代表的な DB ロール:
| ロール | 典型的な権限 |
|---|---|
app_readonly | アプリケーションテーブルへの SELECT |
app_readwrite | アプリケーションテーブルへの SELECT、INSERT、UPDATE、DELETE |
schema_migrator | スキーマオブジェクトへの CREATE、ALTER、DROP |
dba_admin | フル権限、JIT 経由でのみ付与 |
analyst | レポート用ビューとマテリアライズドビューへの SELECT |
よくあるミス
1. 共有サービスアカウント。 複数の開発者が admin@production を共有すると、すべてのクエリが追跡不能になります。破壊的クエリの実行者を監査官が尋ねれば、答えは「チームの誰か」です。個人アカウントを使い、すべての接続を実在の人物にマップしましょう。
2. 別ユーザーから権限をコピペする。 新人加入時の最速経路は既存ユーザーの付与の複製です。問題は、その既存ユーザーは何ヶ月かにわたって権限を積み重ねていることです。新人は不要な権限を継承し、権限の肥大化が複利で広がります。
3. アクセスを決して失効させない。 人はチームを移り、会社を離れ、特定の DB を使わなくなります。月次や四半期のレビューが無いと、古いアカウントが溜まります。可能な限り ID プロバイダーを通じて自動的にデプロビジョンしましょう。
4. 速いので ALL PRIVILEGES を付与する。 GRANT ALL PRIVILEGES ON *.* TO 'app'@'%' は 5 秒で書け、片付けに数ヶ月かかります。最小から始めて、具体的なニーズが出るたびに足しましょう。
5. アプリと人のアクセスを分けない。 アプリのサービスアカウントと人の開発者アカウントは別物であるべきです。アプリは予測可能で狭い権限を必要とし、人はより広い権限を必要としますが、それは一時的で監査証跡付きであるべきです。
6. スキーマレベルの隔離を無視する。 スキーマをサポートする DB (PostgreSQL、SQL Server) は、アクセス制御の自然な境界を提供します。テーブル個別に付与する代わりに、スキーマ単位で付与し、アクセスパターンに沿ってテーブルを整理しましょう。
7. AI エージェントをマシンとして扱う。 コーディングアシスタントや MCP 接続のエージェントに恒久的なサービスアカウントを与えるのは、このリストで最悪のパターンの合算です — マシン形の永続性に人間形の予測不可能性、そしてどのプロンプトがどの DELETE を生んだかの記録がない。エージェントのアカウントは、文単位のレビュー、マスキング、そしてエージェントセッションから要求した人へのバインディングを必要とします。
Bytebase はデータベースアクセス制御をどう扱うか
Bytebase は、接続レベルの RBAC を後付けするのではなく、文単位のワークフローとしてデータベースアクセス制御を強制します。同じ ID モデル、同じ監査ログ、同じマスキングポリシーを、すべてのエンジンとすべてのワークロード (マシン、人、エージェント) に対して。
人 → DB のあらゆるシナリオが、特定の Bytebase 機能にマップされます。
| シナリオ | 誰 | Bytebase の機能 |
|---|---|---|
| スキーマ変更 | 開発者、DBA | スキーマ変更ワークフロー — 提案、レビュー、承認、デプロイ |
| アドホックなデータ修正 | 開発者、DBA | データ変更ワークフロー — スキーマ変更と同じゲート |
| インタラクティブなクエリ | 開発者、DBA | SQL Editor の読み取り専用モード — 行数制限とマスキングを適用 |
| 管理者操作 | DBA | SQL Editor の Admin モード — ロールで予約され監査される |
下回りの仕組み:
- 2 層 RBAC。 ワークスペースレベルのロール (Admin、DBA、Member) とプロジェクトレベルのロール (Owner、Developer、Releaser、SQL Editor User、Viewer)。各ロールは 100+ の細粒度権限にマップされ、専用の権限セット向けのカスタムロールも可能。
- CEL 式による条件付きアクセス。 IAM バインディングは CEL 条件をサポートし、データベース名、スキーマ、時間ウィンドウでスコープできます。バインディングで特定 DB へのクエリ権限を、設定した日付に失効する形で開発者に付与できます。
- 失効付き付与申請。 開発者は DB、ロール、期間を指定して付与申請を出します。承認されると自動で失効します — DB アクセスにおける JIT に最も近い形。
- 承認ワークフロー。 スキーマ変更とデータエクスポートは、CEL ベースのマッチングルールで設定可能な承認チェーンを通ります。承認者はロールで解決され、申請が適切な DBA やプロジェクトオーナーへ自動ルーティングされます。
- 動的データマスキング。 マスキングルールは CEL 条件で、環境、プロジェクト、インスタンス、データベース、テーブル、カラム、分類レベルでカラムをマッチさせます。免除ポリシーで、特定ユーザーやグループが必要な場合にマスキングをバイパスでき、こちらも CEL 条件と時間ベースの失効を持ちます。
- クエリデータポリシー。 ワークスペースおよびプロジェクトポリシーで SQL Editor の挙動を制御 — 最大結果行数、データエクスポートの可否、コピー & ペーストの可否。
- 監査ログ。 すべてのクエリ、スキーマ変更、権限変更が、実ユーザー ID、申請メタデータ、RPC レイテンシとともに記録されます。ログは CEL フィルタで検索可能、エクスポートも可能。この監査証跡は SOC 2、HIPAA、ISO 27001 で監査官が求めるものです。
- グループ、サービスアカウント、エージェント ID。 ユーザーはグループに編成し、グループ経由でロールを継承します。サービスアカウント、ワークロード ID (OIDC を使う CI/CD 向け)、AI エージェントセッションは IAM バインディングの一級市民で、エージェントが取るすべての操作に申請主体が並んで記録されます。
FAQ
データベースアクセスはどのくらいの頻度でレビューすべきか？
コンプライアンスの最低ラインは四半期レビューです。チーム変動の多い組織には月次がより良いです。未使用アカウントや 90 日間行使されていない権限を自動でフラグするツールが手作業を減らします。
アプリと人のアカウントはロールを共有してよいか？
いいえ。アプリのアカウントは予測可能で狭く、長寿命な権限をアプリと一緒にデプロイすべきです。人のアカウントは広い権限が必要ですが、一時的で監査証跡付きであるべきです。ロールを共有すると両方の悪いとこ取りになります — アプリには広すぎ、人には恒久過ぎる。
JIT アクセスは VPN や踏み台と何が違うか？
VPN はどのネットワークが DB に到達できるかを制御し、JIT は誰が、どのくらいの時間アクセスできるかを制御します。レイヤーが違います。VPN だけでは最小権限を満たせません — VPN 上のすべてのユーザーは同じ到達性を持つからです。JIT はネットワーク制御の上に、ID ベース、時間制限、監査可能なアクセスを加えます。
AI エージェントやコーディングアシスタントのアクセスはどう制御するか？
他のワークロードと同じやり方で、2 点を追加します。エージェントごとに (またはエージェント + プロジェクトごとに) 専用のサービスアカウントを使い、共有はしない。エージェントが取るすべての操作に申請した人の ID をバインドし、どのプロンプトがどの文を生んだかを監査証跡が記録するようにする。人のアカウントが通るのと同じ文単位のレビュー、マスキング、承認ポリシーを適用する。