概要
- サービスアカウントには複数のロールを割り当てられますが、特定のクエリに必要なロールだけを有効化できます。
- サービスアカウントが侵害された場合でも、攻撃者が利用できるのは有効なロールの権限のみです。
- タスクごとに個別の認証情報を用意しなくても、1 つのアカウントでロールを切り替えることでさまざまなタスクを実行できます。
- 個々のユーザーを更新する代わりに 1 つのロールを変更するだけで、サービスアカウントの一群全体の権限を更新できます。
- クエリ実行時にどのロールが有効だったかをログで追跡できるため、セキュリティ監査の文脈がより明確になります。
- 許可された範囲 (read_only、maintenance など) を表すロールを設計します
- それらをサービスアカウントに付与します
- 接続時に
SET ROLE(または role パラメーター) で有効なロールを選択し、そのセッションで実行できる操作を制限します
サービスロールを設定する
1
サービスアカウントにロールを付与する
まず、必要な権限 / 設定を持つロールを作成し、それらをサービスアカウントに付与します。
2
SET ROLE を使用して権限の境界を定義する
セッションの開始時に、サービスアカウントはどのロールをアクティブにするかを選択します。または:または、複数のロールをアクティブ化できます。現在有効なロールは
SET ROLE は現在のユーザーに対してロールを有効化します。実効権限は、有効なすべてのロールの権限と、ユーザーに直接付与された権限を合わせたものです。すべてのロールを無効化することもできます。system.current_roles で確認できます。3
サービスアカウントのデフォルトロールを設定する
サービスアカウントが常に制限されたモードで開始するようにするには、デフォルトロールを設定します。または
4
HTTP 経由 / プログラムから SET ROLE を使用する
サービスアカウントが HTTP 経由で接続する場合、SET ROLE; SELECT … を複数ステートメントとして送信することはできません。代わりに、ロールをクエリパラメータとして渡します。
?role=… は、ステートメントの前に SET ROLE read_only_role を実行するのと同等です。複数の role パラメータは SET ROLE role 1, role 2 と同様に動作します。一部のドライバー (例: Python 向け ClickHouse Connect) では、各リクエストとともに送信される role 設定も利用でき、サーバーはそれをセッションロールとして使用します。