Just-in-Time データベースアクセス

Just-in-Time (JIT) データベースアクセスは、データベースの権限を必要なときにだけ、ひとつのタスクに絞って付与し、タスクが終われば自動的に失効させる仕組みです。常設のアクセス権はありません。役目を終えても残り続ける資格情報もありません。権限が生きている時間が短いほど、攻撃者やミスがそれを悪用できる隙も小さくなります。

ユースケース#

もっとも一般的なのはインシデント対応であり、多くの JIT ツールはこのケースを念頭に作られています。オンコール担当者が本番環境の問題に直面し、調査のために読み取り以上の権限を必要とし、問題が解決すればその権限を返上すべき、という流れです。

しかしインシデントは、もっとも目につくケースにすぎません。同じニーズは、アクセス権がロールではなくタスクに紐づくあらゆる場面で現れます。本番の不正な行を修正する開発者。マイグレーションの実行中だけデータベースを必要とする CI ジョブ。一度きりのレポートのために数値を取得するアナリスト。契約終了の当日にすべてのアクセスを失うべき業務委託者。そして緊急時のブレークグラスアクセス — 権限は高くとも、その時間は短く保ち、すべての操作を記録しなければなりません。

どのケースでも原則は同じです。タスクのために付与し、終わったら失効させる。

従来のワークフロー#

既存の JIT データベースアクセスソリューションが提供する典型的なワークフローは次のとおりです。

1. インシデント発生。
2. オンコール担当者が JIT システムにデータベースの昇格権限を申請。
3. 申請が承認される。JIT システムが一時的なデータベースユーザーを払い出し、その資格情報をオンコール担当者に渡す。
4. オンコール担当者はその資格情報を自分の SQL クライアントに設定し、本番データベースに接続してトラブルシュートを開始する。
5. インシデント収束。
6. JIT システムが一時データベースユーザーを失効させる、または自動失効に任せる。

これらのツールは、権限の申請・付与・失効を自動化します。しかしカバーされないのは接続そのものです。アクセスを承認するシステムと、ユーザーが実際に接続するシステムは別物です。資格情報が手渡された時点で、2 つのギャップが生まれます。

1. ユーザーは毎回、SQL クライアントに新しいデータベース資格情報を設定しなければならない。
2. システムはアクセス申請を監査できても、ユーザーが実際に実行する SQL を見ることはできない。

Bytebase のワークフロー#

Bytebase は JIT データベースアクセスに対して、同じセルフサービスの申請・承認フローを提供します。違いは構造にあります。申請と接続が単一のシステムの中で完結するのです。オンコール担当者は一時的なロールを申請し、そのまま Bytebase の組み込み SQL Editor からクエリを実行します。ガバナンスが受け渡しの時点で途切れることはありません。

細粒度の DB 権限#

デフォルトでは、開発者は EXPLAIN 権限しか持ちません。クエリプランを確認するには十分ですが、データを読んだり変更したりはできません。インシデントが起きると、開発者は昇格権限を申請し、それを使い、申請が失効した瞬間に失います。恒久的に付与されるものは何もありません。これが Zero Standing Privileges (ZSP) です。どのアカウントも、いま使っていないアクセス権を持ち続けることはありません。

統合された SQL Editor#

Bytebase は組み込みの SQL Editor を備えているため、ユーザーは別の SQL クライアントに移る必要がありません。従来のワークフローが実行内容を見失うのは、まさにこの移動の先です。すべてのステートメントは Bytebase を経由します。レビュールールが危険なクエリをブロックし、動的データマスキングが機微なカラムを画面に表示される前に隠します。

API ファースト#

Bytebase は API を通じて、既存の Internal Developer Portal (IDP) に統合できます。次のチュートリアルでは、SQL Editor を埋め込み、データベース権限をプログラムから設定する方法を紹介します。

比較#

申請フロー自体は簡単な部分であり、どの JIT ツールにも備わっています。本当に問われるのは、アクセスを付与した後に何が起きるかです。システムは依然として SQL を見て統制できるのか、それとも申請が承認されたという事実しか分からないのか。これが、申請を監査することと、作業そのものを統制することの違いです。