DB のユーザーと権限

2つの登録のしかた

• 管理者の接続文字列を登録する: ユーザーを作れる権限 (PostgreSQL の CREATEROLE、MySQL の CREATE USER など) を持つ接続文字列を登録すると、Scandock が監視用の読み取り専用のユーザー (scandock_ で始まる名前) を自動で作り、監視と調査にはそのユーザーだけを使います。管理者の接続文字列は暗号化して保存し、人が承認した SQL の対処を実行するときだけ使います。接続を削除すると、自動で作ったユーザーも削除します。
• 読み取り専用のユーザーを自分で作って登録する: 下の手順で作ったユーザーの接続文字列を登録します。この場合、SQL の対処は使えません (通知などの対処は使えます)。

読み取り専用かどうかの確かめ方

登録のとき、Scandock はそのユーザーが書き込めないことを確かめます。書き込める権限が1つでもあると管理者の接続文字列として扱い、監視用のユーザーを作ろうとします。ユーザーを作る権限がなければ、登録できません。

• PostgreSQL: スーパーユーザーと CREATEROLE を持たず、どのテーブルにも INSERT・UPDATE・DELETE・TRUNCATE の権限がないこと。リードレプリカへの接続は、読み取り専用として扱います。
• MySQL・MariaDB・TiDB: 一時テーブルを作れないこと (CREATE TEMPORARY TABLES の権限を与えない)。
• SQL Server: db_owner・db_datawriter・db_ddladmin のロールと CREATE TABLE の権限を持たず、どのテーブルにも INSERT・UPDATE・DELETE の権限がないこと。読み取り専用の DB は、読み取り専用として扱います。

PostgreSQL

CREATE ROLE scandock_ro LOGIN PASSWORD '強いパスワード';
GRANT CONNECT ON DATABASE app TO scandock_ro;
-- PostgreSQL 14 以降: すべてのスキーマのテーブルを読める
GRANT pg_read_all_data TO scandock_ro;
-- 実行中のクエリやロックなどの統計を見るため
GRANT pg_monitor TO scandock_ro;

GRANT USAGE ON SCHEMA public TO scandock_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO scandock_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO scandock_ro;

MySQL・MariaDB・TiDB

CREATE USER 'scandock_ro'@'%' IDENTIFIED BY '強いパスワード';
GRANT SELECT ON app.* TO 'scandock_ro'@'%';
-- 実行中のクエリを見るため
GRANT PROCESS ON *.* TO 'scandock_ro'@'%';
-- クエリごとの統計を見るため
GRANT SELECT ON performance_schema.* TO 'scandock_ro'@'%';

Azure SQL Database

-- 監視する DB で実行
CREATE USER scandock_ro WITH PASSWORD = '強いパスワード';
ALTER ROLE db_datareader ADD MEMBER scandock_ro;
GRANT VIEW DATABASE STATE TO scandock_ro;

SQL Server

-- master で実行
CREATE LOGIN scandock_ro WITH PASSWORD = '強いパスワード', CHECK_POLICY = ON;
GRANT VIEW SERVER STATE TO scandock_ro;
-- 監視する DB で実行
CREATE USER scandock_ro FOR LOGIN scandock_ro;
ALTER ROLE db_datareader ADD MEMBER scandock_ro;
GRANT VIEW DATABASE STATE TO scandock_ro;

読み取りの制限

監視用の接続では、セッションも読み取り専用に固定します。AI が作るクエリは、1文の読み取りに限って実行します。