RBAC Policy Guide Community

DB GatekeeperのRole-Based Access Control（RBAC）ポリシーの設定ガイドです。

---

1. ロール一覧と権限マトリクス

DB Gatekeeperには4つの組み込みロールがあります。

ロール	説明
read_only	読み取り専用。SELECT以外の全操作を拒否
junior_dev	一般開発者。SELECT/INSERTは自動承認、更新系は人間承認が必要
senior_dev	シニア開発者。全操作を自動承認
admin	管理者。全操作を自動承認

権限マトリクス（デフォルト）

ロール	SELECT	INSERT	UPDATE	DELETE	DDL
read_only	AutoApprove	Deny	Deny	Deny	Deny
junior_dev	AutoApprove	AutoApprove	RequireHuman	RequireHuman	RequireHuman
senior_dev	AutoApprove	AutoApprove	AutoApprove	AutoApprove	RequireHuman
admin	AutoApprove	AutoApprove	AutoApprove	AutoApprove	AutoApprove

Decision（判定結果）の意味

Decision	動作
AutoApprove	AI審査をスキップし、クエリを即時通過させる
RequireHuman	AIリスク評価を実行し、スコアに応じて自動承認または人間承認待ちにする
Deny	クエリを即座に拒否する

ロール別AIスコア自動承認閾値（デフォルト）

RequireHuman 判定の場合、AIリスクスコア（0-100）がこの閾値未満であれば自動承認されます。

ロール	閾値	説明
read_only	0	更新系は全拒否のためこの値は使用されない
junior_dev	10	非常に厳しい（ほぼ全て人間承認）
senior_dev	50	緩めの閾値
admin	100	全て自動承認

未登録ユーザーは junior_dev ロールとして扱われます。

---

2. 環境変数での設定方法

最もシンプルな設定方法です。ユーザーにロールを割り当てます。

GATEKEEPER_ROLES の書式

ロール名:ユーザー1,ユーザー2;ロール名:ユーザー3,ユーザー4

セミコロン（;）でロールを区切り、コロン（:）でロール名とユーザーリストを区切ります。ユーザーリスト内はカンマ（,）で区切ります。

設定例

# 基本的な設定
export GATEKEEPER_ROLES="read_only:report_user;junior_dev:dev1,dev2;senior_dev:lead1;admin:dba_admin"

この設定により：

• report_user → read_only（SELECTのみ許可）
• dev1, dev2 → junior_dev（更新系は人間承認必須）
• lead1 → senior_dev（全操作自動承認）
• dba_admin → admin（全操作自動承認）
• 上記以外のユーザー → junior_dev（デフォルト）

---

3. JSONポリシーファイルの書き方

より詳細な制御が必要な場合、JSONポリシーファイルを使用します。

基本構造

{
  "default_role": "junior_dev",
  "users": {
    "report_user": "read_only",
    "dev1": "junior_dev",
    "lead1": "senior_dev",
    "dba_admin": "admin"
  },
  "roles": {
    "read_only": {
      "allowed_actions": ["SELECT"],
      "denied_actions": ["INSERT", "UPDATE", "DELETE", "DDL"],
      "auto_approve_threshold": 0
    },
    "junior_dev": {
      "allowed_actions": ["SELECT", "INSERT"],
      "denied_actions": [],
      "require_approval_actions": ["UPDATE", "DELETE", "DDL"],
      "auto_approve_threshold": 10,
      "max_jit_ttl_seconds": 3600
    },
    "senior_dev": {
      "allowed_actions": ["SELECT", "INSERT", "UPDATE", "DELETE", "DDL"],
      "denied_actions": [],
      "auto_approve_threshold": 50
    },
    "admin": {
      "allowed_actions": ["SELECT", "INSERT", "UPDATE", "DELETE", "DDL"],
      "denied_actions": [],
      "auto_approve_threshold": 100
    }
  },
  "rules": []
}

フィールド説明

フィールド	型	説明
default_role	string	未登録ユーザーのデフォルトロール
users	object	ユーザー名 → ロール名のマッピング
roles	object	ロール名 → ロール設定のマッピング
rules	array	カスタムルール（後述）

RoleConfig フィールド

フィールド	型	説明
allowed_actions	string[]	自動承認するアクション（AutoApprove）
denied_actions	string[]	即座に拒否するアクション（Deny）
require_approval_actions	string[]	人間承認が必要なアクション（RequireHuman）
auto_approve_threshold	int	AIスコアの自動承認閾値（0-100）
max_jit_ttl_seconds	int	JITアクセスの最大TTL（秒、オプション）

アクション判定の優先順位

ポリシーエンジンは以下の順序でアクションを評価します：

1. denied_actions に含まれる → Deny
2. require_approval_actions に含まれる → RequireHuman
3. allowed_actions に含まれる → AutoApprove
4. いずれにも含まれない → Deny（安全側にフォールバック）

使用方法

export GATEKEEPER_POLICY_FILE=/etc/gatekeeper/policy.json
./gatekeeper

---

4. カスタムルールの追加方法

カスタムルールを使うと、特定の条件にマッチするクエリに対してロール設定よりも優先される判定を適用できます。

ルールの構造

{
  "rules": [
    {
      "description": "ルールの説明",
      "match": {
        "action": "DELETE",
        "query_contains": ["production_data"],
        "query_not_contains": ["WHERE"],
        "users": ["dev1"],
        "roles": ["junior_dev"]
      },
      "decision": "deny"
    }
  ]
}

マッチ条件

全ての条件はAND（全て一致する場合にマッチ）で評価されます。条件が未指定の場合、その条件は無視されます。

フィールド	型	説明
action	string	アクション種別（SELECT, INSERT, UPDATE, DELETE, DDL）
query_contains	string[]	クエリに含まれるべき文字列（いずれか1つが含まれればマッチ、大文字小文字を区別しない）
query_not_contains	string[]	クエリに含まれてはいけない文字列（全て含まれている場合はマッチしない）
users	string[]	対象ユーザー名（いずれか1つにマッチすればOK）
roles	string[]	対象ロール名（いずれか1つにマッチすればOK）

Decision 値

値	説明
"deny"	即座に拒否
"require_human"	人間承認が必要
"auto_approve"	自動承認

ルール評価の優先順位

1. カスタムルール（rules 配列の先頭から順に評価、最初にマッチしたものが適用）
2. ロール設定（roles の allowed_actions / denied_actions / require_approval_actions）
3. ハードコードされたデフォルト（組み込みロールの権限マトリクス）

実用的なカスタムルール例

{
  "default_role": "junior_dev",
  "users": {
    "dev1": "junior_dev",
    "lead1": "senior_dev",
    "dba_admin": "admin"
  },
  "roles": {
    "junior_dev": {
      "allowed_actions": ["SELECT", "INSERT"],
      "require_approval_actions": ["UPDATE", "DELETE", "DDL"],
      "auto_approve_threshold": 10
    },
    "senior_dev": {
      "allowed_actions": ["SELECT", "INSERT", "UPDATE", "DELETE", "DDL"],
      "auto_approve_threshold": 50
    },
    "admin": {
      "allowed_actions": ["SELECT", "INSERT", "UPDATE", "DELETE", "DDL"],
      "auto_approve_threshold": 100
    }
  },
  "rules": [
    {
      "description": "WHERE句なしのDELETEは全ロールで拒否",
      "match": {
        "action": "DELETE",
        "query_not_contains": ["WHERE"]
      },
      "decision": "deny"
    },
    {
      "description": "本番テーブルへのDDLはadminでも人間承認必須",
      "match": {
        "action": "DDL",
        "query_contains": ["production_", "prod_"]
      },
      "decision": "require_human"
    },
    {
      "description": "TRUNCATEは全ユーザーで拒否",
      "match": {
        "query_contains": ["TRUNCATE"]
      },
      "decision": "deny"
    },
    {
      "description": "senior_devのログテーブルへのDELETEは自動承認",
      "match": {
        "action": "DELETE",
        "query_contains": ["access_logs", "audit_logs"],
        "roles": ["senior_dev"]
      },
      "decision": "auto_approve"
    }
  ]
}

---

5. API経由でのポリシー管理

DB Gatekeeperは、稼働中にポリシーをAPI経由でホットリロードできます。

現在のポリシーを取得

# 認証なしの場合
curl http://localhost:8080/policies

# 認証ありの場合
curl -H "Authorization: Bearer ${ADMIN_API_KEY}" \
  http://localhost:8080/policies

レスポンス例：

{
  "roles": {
    "junior_dev": {
      "allowed_actions": ["SELECT", "INSERT"],
      "require_approval_actions": ["UPDATE", "DELETE", "DDL"],
      "auto_approve_threshold": 10
    }
  },
  "users": {
    "dev1": "junior_dev",
    "lead1": "senior_dev"
  },
  "default_role": "junior_dev",
  "rules": []
}

ポリシーを更新（ホットリロード）

curl -X PUT \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${ADMIN_API_KEY}" \
  -d @policy.json \
  http://localhost:8080/policies

成功レスポンス：

{"status": "policy updated"}

注意: PUT /policies はポリシーをメモリ上で即時反映しますが、永続化はされません。永続的な変更には GATEKEEPER_POLICY_FILE のファイルを更新してください。

---

6. ベストプラクティス

最小権限の原則

• デフォルトロールは junior_dev（または read_only）に設定する
• 必要最小限のユーザーにのみ senior_dev / admin を付与する
• admin ロールは本当に必要な管理者のみに限定する

カスタムルールの活用

• WHERE句なしのDELETE/UPDATEは常に拒否するルールを追加する
• 本番データテーブルへのDDL操作には人間承認を必須にする
• TRUNCATE操作は原則として全ユーザーに対して拒否する

AIスコア閾値の調整

• junior_dev の閾値は低く（10以下）設定し、ほぼ全て人間承認にする
• senior_dev の閾値は中程度（30-50）に設定し、明らかに安全なクエリのみ自動承認にする
• 運用開始時は閾値を低く設定し、AIの判定精度を確認しながら徐々に上げる

環境ごとの設定分離

# 開発環境: 緩めの設定
export GATEKEEPER_ROLES="admin:dev1,dev2,dev3"
export GATEKEEPER_APPROVAL_TIMEOUT=10

# 本番環境: 厳格な設定
export GATEKEEPER_POLICY_FILE=/etc/gatekeeper/production-policy.json
export GATEKEEPER_APPROVAL_TIMEOUT=300
export ADMIN_API_KEY=strong-random-token

監査とモニタリング

• ADMIN_API_KEY を必ず設定し、管理APIへのアクセスを制限する
• GATEKEEPER_SLACK_WEBHOOK_URL を設定し、承認リクエストをSlackで通知する
• ダッシュボード（http://localhost:8080）で承認待ちクエリを定期的に確認する
• 監査ログ（GET /audit）を定期的にレビューする