GRANTによって利用できるSQL標準の権限システムに加えて、通常の問い合わせでどの行が戻され、データ更新のコマンドでどの行を挿入、更新、削除できるかをユーザ単位で制限する行セキュリティポリシーをテーブルに定義できます。 この機能は行単位セキュリティとしても知られています。 デフォルトではテーブルには何もポリシーはなく、SQLの権限システムによってテーブルのアクセス権限があるユーザは、テーブル内のすべての行について同じように、問い合わせや更新をできます。
テーブルの行セキュリティが有効の場合(ALTER TABLE ... ENABLE ROW LEVEL SECURITYを使います)、行の検索や行の更新のための通常のテーブルアクセスはすべて、行セキュリティポリシーによって許可される必要があります。
(ただし、テーブルの所有者は典型的には行セキュリティポリシーの対象とはなりません。)
テーブルにポリシーが存在しない場合は、デフォルト拒否のポリシーが使われて、どの行も見ることも更新することもできなくなります。
TRUNCATE
やREFERENCES
など、テーブル全体に対する操作は行セキュリティの対象とはなりません。
行セキュリティポリシーは特定のコマンド、特定のロール、あるいはその両方に対して定義できます。
ポリシーはALL
つまりすべてのコマンドに対して適用、あるいはSELECT
、INSERT
、UPDATE
、DELETE
に適用することを指定できます。
1つのポリシーを複数のロールに割り当てることができ、通常のロールのメンバ資格と継承の規則が当てはまります。
ポリシーでどの行が可視である、あるいは更新可能であるかを指定するために、論理値を返す式が必要です。
ユーザの問い合わせにあるどの条件や関数よりも前に、この式が各行について評価されます。
(この規則の例外は、情報リークがないことが保証されるleakproof
関数だけです。
行セキュリティの確認の前にこのような関数を適用することをオプティマイザが選択することがあります。)
式がtrue
を返さない行は処理対象になりません。
可視である行と変更可能な行について独立した制御ができるように、別々の式を指定することも可能です。
ポリシーの式は問い合わせの一部分として、問い合わせをしているユーザの権限で実行されます。
ただし、呼び出しユーザが利用できないデータにアクセスするために、セキュリティ定義関数を使うことができます。
スーパーユーザ、およびBYPASSRLS
属性のあるロールは、テーブルへのアクセス時に、常に行セキュリティシステムを無視します。
テーブルの所有者も通常は行セキュリティを無視しますが、ALTER TABLE ... FORCE ROW LEVEL SECURITYにより、テーブルの所有者も行セキュリティの対象となることができます。
行セキュリティの有効化、無効化、およびポリシーのテーブルへの追加は、常に、テーブルの所有者のみの権限です。
ポリシーはCREATE POLICYコマンドで作成され、ALTER POLICYコマンドで変更され、DROP POLICYコマンドで削除されます。 テーブルの行セキュリティを有効に、あるいは無効にするにはALTER TABLEコマンドを使います。
各ポリシーには名前があり、1つのテーブルに複数のポリシーを定義できます。 ポリシーはテーブルごとに定義されるので、1つのテーブルの各ポリシーは異なる名前でなければなりません。 異なるテーブルであれば、同じ名前のポリシーが存在しても構いません。
ある問い合わせに複数のポリシーが適用される場合、(デフォルトの許容(permissive)ポリシーについては)OR
または(制限(restrictive)ポリシーについては) AND
を使って結合されます。
これは、あるロールが、それが属するすべてのロールの権限を合わせ持つのと類似しています。
許容ポリシーと制限ポリシーについては以下でさらに説明します。
簡単な例として、managers
ロールのメンバだけが行にアクセスでき、かつ自分のアカウントの行のみアクセスできるポリシーをaccount
リレーション上に作成する方法を以下に示します。
CREATE TABLE accounts (manager text, company text, contact_email text); ALTER TABLE accounts ENABLE ROW LEVEL SECURITY; CREATE POLICY account_managers ON accounts TO managers USING (manager = current_user);
上記のポリシーは、上記のUSING
句と同じWITH CHECK
句を暗黙的に提供するので、制約は、コマンドが選択した行にも適用されますし(ですから、マネージャは、違うマネージャに属する既存の行に対してSELECT
、UPDATE
、DELETE
を発行することはできません)、コマンドが変更した行にも適用されます(ですから、違うマネージャに属する行を、INSERT
あるいはUPDATE
で作ることはできません)。
ロールが指定されなかった場合、あるいは特別なユーザ名PUBLIC
が指定された場合、ポリシーはシステム上の全ユーザに適用されます。
すべてのユーザがusers
テーブルの自分自身の行にだけアクセスできるようにするためには、次の簡単なポリシーが使用できます。
CREATE POLICY user_policy ON users USING (user_name = current_user);
これは前の例と同じように動きます。
テーブルに追加される行に対し、可視である行とは異なるポリシーを使用する場合は、複数のポリシーを組み合わせることができます。
組み合わせたポリシーにより、すべてのユーザがusers
テーブルのすべての行を見ることができますが、自分自身の行だけしか更新できません。
CREATE POLICY user_sel_policy ON users FOR SELECT USING (true); CREATE POLICY user_mod_policy ON users USING (user_name = current_user);
SELECT
コマンドでは、OR
を使って2つのポリシーが組み合わされ、すべての行を検索できる効果をもたらします。
他のコマンドに対しては、二番目のポリシーだけが適用され、以前と効果は同じです。
行セキュリティはALTER TABLE
で無効にすることもできます。
行セキュリティを無効にしても、テーブルに定義されているポリシーは削除されず、単に無視されるだけになります。
このときはSQL標準の権限システムに従って、すべての行が可視で更新可能になります。
以下のより大きな例で、この機能が実運用の環境でいかにして使えるかを示します。
passwd
テーブルはUnixのパスワードファイルと同等のものです。
-- passwdファイルに基づく簡単な例 CREATE TABLE passwd ( user_name text UNIQUE NOT NULL, pwhash text, uid int PRIMARY KEY, gid int NOT NULL, real_name text NOT NULL, home_phone text, extra_info text, home_dir text NOT NULL, shell text NOT NULL ); CREATE ROLE admin; -- 管理者 CREATE ROLE bob; -- 一般ユーザ CREATE ROLE alice; -- 一般ユーザ -- テーブルに値を入れる INSERT INTO passwd VALUES ('admin','xxx',0,0,'Admin','111-222-3333',null,'/root','/bin/dash'); INSERT INTO passwd VALUES ('bob','xxx',1,1,'Bob','123-456-7890',null,'/home/bob','/bin/zsh'); INSERT INTO passwd VALUES ('alice','xxx',2,1,'Alice','098-765-4321',null,'/home/alice','/bin/zsh'); -- テーブルの行単位セキュリティを有効にする ALTER TABLE passwd ENABLE ROW LEVEL SECURITY; -- ポリシーを作成する -- 管理者はすべての行を見ることができ、どんな行でも追加できる CREATE POLICY admin_all ON passwd TO admin USING (true) WITH CHECK (true); -- 一般ユーザはすべての行を見ることができる CREATE POLICY all_view ON passwd FOR SELECT USING (true); -- 一般ユーザは自身のレコードを更新できるが、 -- 変更できるのは使用するシェルだけに制限する CREATE POLICY user_mod ON passwd FOR UPDATE USING (current_user = user_name) WITH CHECK ( current_user = user_name AND shell IN ('/bin/bash','/bin/sh','/bin/dash','/bin/zsh','/bin/tcsh') ); -- adminにはすべての通常の権限を付与する GRANT SELECT, INSERT, UPDATE, DELETE ON passwd TO admin; -- 一般ユーザは公開列にSELECTでアクセスできるだけとする GRANT SELECT (user_name, uid, gid, real_name, home_phone, extra_info, home_dir, shell) ON passwd TO public; -- 特定の列についてはユーザによる更新を許可する GRANT UPDATE (pwhash, real_name, home_phone, extra_info, shell) ON passwd TO public;
どんなセキュリティ設定でも同じですが、システムが期待通りに動作していることをテストして確認することが重要です。 上の例を利用して、以下ではパーミッションのシステムが適切に動作していることを示します。
-- adminはすべての行と列を見ることができる postgres=> set role admin; SET postgres=> table passwd; user_name | pwhash | uid | gid | real_name | home_phone | extra_info | home_dir | shell -----------+--------+-----+-----+-----------+--------------+------------+-------------+----------- admin | xxx | 0 | 0 | Admin | 111-222-3333 | | /root | /bin/dash bob | xxx | 1 | 1 | Bob | 123-456-7890 | | /home/bob | /bin/zsh alice | xxx | 2 | 1 | Alice | 098-765-4321 | | /home/alice | /bin/zsh (3 rows) -- Aliceに何ができるか試してみる postgres=> set role alice; SET postgres=> table passwd; ERROR: permission denied for table passwd postgres=> select user_name,real_name,home_phone,extra_info,home_dir,shell from passwd; user_name | real_name | home_phone | extra_info | home_dir | shell -----------+-----------+--------------+------------+-------------+----------- admin | Admin | 111-222-3333 | | /root | /bin/dash bob | Bob | 123-456-7890 | | /home/bob | /bin/zsh alice | Alice | 098-765-4321 | | /home/alice | /bin/zsh (3 rows) postgres=> update passwd set user_name = 'joe'; ERROR: permission denied for table passwd -- Aliceは自分のreal_nameを変更できるが、他は変更できない postgres=> update passwd set real_name = 'Alice Doe'; UPDATE 1 postgres=> update passwd set real_name = 'John Doe' where user_name = 'admin'; UPDATE 0 postgres=> update passwd set shell = '/bin/xx'; ERROR: new row violates WITH CHECK OPTION for "passwd" postgres=> delete from passwd; ERROR: permission denied for table passwd postgres=> insert into passwd (user_name) values ('xxx'); ERROR: permission denied for table passwd -- Aliceは自分のパスワードを変更できる。 -- RLSにより他の行は更新されないが、何も報告されない。 postgres=> update passwd set pwhash = 'abc'; UPDATE 1
ここまでで作成したポリシーはすべて許容ポリシーで、つまり複数のポリシーが適用される場合、それらは論理演算子「OR」を使って結合されるものでした。
意図した場合にのみ行へのアクセスが許されるよう許容ポリシーを構築することは可能ですが、許容ポリシーを制限ポリシーと組み合わせることで、より単純にすることが可能です(制限ポリシーはレコードが満たさなければならないポリシーで、論理演算子「AND」を使って結合されます)。
上記の例に重ねて、管理者がローカルのUnixソケットを通して接続してpasswd
テーブルのレコードにアクセスすることを要求する制限ポリシーを追加してみます。
CREATE POLICY admin_local_only ON passwd AS RESTRICTIVE TO admin USING (pg_catalog.inet_client_addr() IS NULL);
こうすると以下のように、制限ポリシーにより、ネットワーク経由で接続している管理者にはレコードが見えないことがわかります。
=> SELECT current_user; current_user -------------- admin (1 row) => select inet_client_addr(); inet_client_addr ------------------ 127.0.0.1 (1 row) => TABLE passwd; user_name | pwhash | uid | gid | real_name | home_phone | extra_info | home_dir | shell -----------+--------+-----+-----+-----------+------------+------------+----------+------- (0 rows) => UPDATE passwd set pwhash = NULL; UPDATE 0
一意性制約、主キー制約、外部キー制約などの参照整合性確認は、データの整合性を維持するため、常に行セキュリティを無視します。 スキーマと行単位セキュリティの開発において、このような参照整合性確認により「カバートチャネル(covert channel)」の情報漏洩が起こらないようにするため、注意が必要です。
状況によっては、行セキュリティが適用されないことを確実にするのが重要になります。
例えばバックアップを取るとき、行セキュリティのために、何のエラーや警告もなしに一部の行がバックアップされないとすると、破滅的です。
このような状況では、設定パラメータrow_securityをoff
にすることができます。
これ自体は行セキュリティを無視するわけではなく、問い合わせの結果がポリシーによって影響を受ける場合にエラーを発生させます。
その後でエラーの原因を調査して解決することができます。
上の例では、ポリシーの式はアクセス対象または更新対象の行の現在の値のみを考慮していました。
これは最も単純で、しかも効率の良い場合です。
可能であれば、行セキュリティの適用はこのように動作するよう設計するのが最善です。
ポリシーの決定をするために他の行あるいは他のテーブルを参照する必要がある場合は、ポリシーの式で副SELECT
を使う、あるいはSELECT
を含む関数を使うことができます。
ただし、そのようなアクセスは注意深く設計しなければ、情報漏洩を起こすような競合条件を作り出す場合があることに注意してください。
例えば、以下のテーブル設計を考えます。
-- 権限グループの定義 CREATE TABLE groups (group_id int PRIMARY KEY, group_name text NOT NULL); INSERT INTO groups VALUES (1, 'low'), (2, 'medium'), (5, 'high'); GRANT ALL ON groups TO alice; -- aliceが管理者 GRANT SELECT ON groups TO public; -- ユーザの権限レベルの定義 CREATE TABLE users (user_name text PRIMARY KEY, group_id int NOT NULL REFERENCES groups); INSERT INTO users VALUES ('alice', 5), ('bob', 2), ('mallory', 2); GRANT ALL ON users TO alice; GRANT SELECT ON users TO public; -- 保護される情報を保持するテーブル CREATE TABLE information (info text, group_id int NOT NULL REFERENCES groups); INSERT INTO information VALUES ('barely secret', 1), ('slightly secret', 2), ('very secret', 5); ALTER TABLE information ENABLE ROW LEVEL SECURITY; -- セキュリティのgroup_idが行のgroup_idより大きいか等しいユーザは -- その行を見ること、更新することが可能 CREATE POLICY fp_s ON information FOR SELECT USING (group_id <= (SELECT group_id FROM users WHERE user_name = current_user)); CREATE POLICY fp_u ON information FOR UPDATE USING (group_id <= (SELECT group_id FROM users WHERE user_name = current_user)); -- informationテーブルを保護するのにRLSのみに依存する GRANT ALL ON information TO public;
ここでalice
が「slightly secret」の情報を更新したいが、この行の新しい内容に関してmallory
は信頼すべきでないと判断しました。
そこで、彼女は次のようにします。
BEGIN; UPDATE users SET group_id = 1 WHERE user_name = 'mallory'; UPDATE information SET info = 'secret from mallory' WHERE group_id = 2; COMMIT;
これは安全なように見えます。
mallory
が「secret from mallory」の文字列を見ることができる隙はありません。
しかし、ここには競合条件があります。
例えば、mallory
が同時に以下を実行していたとしましょう。
SELECT * FROM information WHERE group_id = 2 FOR UPDATE;
ここで彼女のトランザクションがREAD COMMITTED
モードなら、彼女は「secret from mallory」を見ることが可能です。
それは彼女のトランザクションが、alice
のトランザクションの直後にinformation
の行にアクセスした場合に発生します。
それはalice
のトランザクションがコミットされるのを待ってブロックされ、次にFOR UPDATE
句があるため、更新後の行の内容をフェッチします。
しかし、users
からの暗示的なSELECT
では更新後の行をフェッチしません。
なぜなら、その副SELECT
にはFOR UPDATE
がないため、users
の行は問い合わせの開始時に取得したスナップショットから読まれるからです。
そのため、ポリシーの式はmallory
の権限レベルの古い値について検査し、更新後の行を見ることを許してしまいます。
この問題を回避する方法はいくつかあります。
一つの簡単な答えは行セキュリティポリシーの副SELECT
でSELECT ... FOR SHARE
を使うことです。
しかし、これは影響を受けるユーザに対し、参照先テーブル(この場合はusers
)のUPDATE
権限を付与する必要があり、望ましくないかもしれません。
(しかし、もう一つの行セキュリティポリシーを適用して、彼らが実際にその権限を行使することを防ぐことはできます。
また、副SELECT
をセキュリティ定義関数内に埋め込むことも可能です。)
また、参照先テーブルに行共有ロックが同時に大量に発生するとパフォーマンス問題が起きるかもしれません。
特にそのテーブルの更新が多いときは問題になるでしょう。
別の解決策で、参照先テーブルの更新が少ない場合に現実的なのは、参照先テーブルの更新時にACCESS EXCLUSIVE
ロックを取得するものです。
そうすれば、同時実行のトランザクションが行の古い値を調べることはできません。
あるいは、参照先のテーブルの更新をコミットした後、単にすべての同時実行トランザクションが終わるのを待ってから、新しいセキュリティ状況に依存する変更をする、ということもできます。
さらなる詳細はCREATE POLICYとALTER TABLEを参照してください。