データベース変更は、セキュリティツールのスタックによってゲートされています。接続には踏み台。承認には ITSM。クレデンシャルには PAM。それぞれのレイヤーが制御を 1 つ加え、それぞれが保守すべきツールを 1 つ追加します。
このスタックには 1 つのギャップが残ります — 実行時、承認・クレデンシャル・SQL が出会う場所に、それらを結びつけるシステムがないというギャップです。本記事ではレイヤーを 1 つずつ歩き、ギャップに名前を与え、統合プラットフォームが何を置き換えるかを示します。
「変更ライフサイクルのうちどこまでが人手なしで回るのか」という自動化深度の視点では、データベース自動化の 6 段階を参照してください。
踏み台 / ジャンプサーバー
| ツールカテゴリ | 例 |
|---|---|
| 踏み台 / ジャンプサーバー | AWS Bastion Host、Azure Bastion、Teleport |
踏み台はユーザーとデータベースサーバーの間にあるゲートウェイです。接続は既知のネットワーク経路に制限され、セッション活動はログに残り、実行は管理された環境の内側で行われます。
ゲートするもの: ネットワークアクセス。あらゆる接続が識別され記録される。
届かないところ: 踏み台が見るのは接続であり、変更ではありません。SQL は手打ちで、レビューも、承認も、何が走ったかの構造化された監査もありません。
ITSM と CAB
| ツールカテゴリ | 例 |
|---|---|
| ITSM | ServiceNow、Atlassian Jira、Freshworks |
| 変更諮問委員会 (CAB) | 通常は ITSM ワークフローに乗せて運用される |
ITSM は変更リクエストを形式化します — 誰が提案し、何が走り、誰が承認するか。CAB は人によるガバナンスを加えます — 部門横断のグループが、承認前にリスクを評価します。
ゲートするもの: 意思決定の権限。承認が記録されない限り変更は進みません。多くのコンプライアンスフレームワークが要求する証跡を満たします。
届かないところ: 承認は実行から切り離されています。CAB はチケット内のスクリプトを承認しますが、別のスクリプトが実行されるのを止める仕組みはありません。また、CAB を必要としないルーチン変更にとってはワークフローが遅すぎます。
PAM (特権アクセス管理)
| ツールカテゴリ | 例 |
|---|---|
| PAM | CyberArk、BeyondTrust、HashiCorp Vault |
PAM ツールは、データベースクレデンシャルが人にどう届くかを制御します。クレデンシャルは vault に保管され、チェックアウトには期限があり、すべてのチェックアウトがログに残ります。
ゲートするもの: クレデンシャルの露出。長命のデータベースパスワードが開発者のディスクに残ることがありません。アクセスは申請され、付与され、剥奪されます。
届かないところ: PAM が見るのはクレデンシャルであり、SQL ではありません。開発者がクライアントの中でそれを握った時点で、PAM には何が走るかは見えません。
実運用でのスタック
3 つのレイヤーが揃った状態で、変更は次のように流れます。
- 開発者が ITSM に変更リクエストを起票し、SQL を添付する
- CAB がレビューし、承認する
- 開発者が PAM からクレデンシャルをチェックアウトする
- 開発者が踏み台経由で接続し、SQL を実行する
3 つのツール、4 つの引き継ぎ、そして 1 つのギャップ: 実行された SQL が、承認された SQL と必ずしも一致しない。CAB が承認したのはチケット内のスクリプトでした。踏み台が見たのは接続でした。PAM が見たのはクレデンシャルのチェックアウトでした。実行の場でそれらを結びつけるものは何もありませんでした。
スタックが残す他のギャップ:
- 実行前の検証がない。 スキーマチェックやドライランは、行われたとしても手作業
- ロールバックがない。 DDL も DML もバージョン管理されておらず、復旧はバックアップ復元を意味する
- 統一された監査がない。 証跡は 3 つのツールに分散し、どれも全体像を見ない
統合プラットフォームが置き換えるもの
統合されたデータベース変更プラットフォームはスタックを集約します。1 つのツールが 3 つを置き換え、承認、クレデンシャル、実行が同じレコードを共有します。
Bytebase が各レイヤーにどう対応するか:
- 踏み台を置き換え。 接続は Bytebase の Web UI を通じて行われます。開発者のラップトップからの直接接続はなく、別途維持するジャンプサーバーもありません。
- ITSM を置き換え。 変更リクエスト、承認、監査が Bytebase 内に存在します。既存の ITSM (ServiceNow、Jira) は、チケットが記録の正本である場合に接続します。
- PAM を置き換え。 Bytebase がデータベースクレデンシャルを保持し、開発者はそれを目にしません。外部 vault のケースは IAM 認証とシークレットマネージャー連携でカバーします。
- 実行時のギャップを閉じる。 承認、検証、実行、監査が同じレコードに紐づきます。実行される SQL は承認された SQL です。SQL レビューがデプロイ前に問題を捕捉します。ワンクリックのロールバックが復旧を担います。
比較
| アプローチ | ゲートするもの | 監査証跡 | 保守するツール数 |
|---|---|---|---|
| 踏み台 / ジャンプ | ネットワークアクセス | セッションログ | 1 |
| ITSM + CAB | 意思決定の権限 | チケット履歴 | 1 |
| PAM | クレデンシャルの露出 | チェックアウトログ | 1 |
| 3 つを積み上げ | 各レイヤーを個別に | ツール間で分断 | 3+ |
| 統合プラットフォーム | 全レイヤー、実行時に紐付け済み | 単一でクエリ可能な証跡 | 1 |
スタックは機能します。踏み台、ITSM、PAM はそれぞれ異なるリスクをゲートします。しかしその統合をチームに押し付けます — 3 つのツールを保守し、3 つの監査証跡を突き合わせ、実行時に 1 つのギャップを残します。統合プラットフォームは 3 つのレイヤーすべてを内側に持ち、そのギャップを閉じます。