5.7. 行セキュリティポリシー

PostgreSQL 11.5文書
		第5章データ定義
前へ	上へ	5.7. 行セキュリティポリシー	次へ

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)


-- Test what Alice is able to do
postgres=> set role alice;
SET
postgres=> table passwd;
ERROR:  permission denied for relation 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 relation 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 relation passwd
postgres=> insert into passwd (user_name) values ('xxx');
ERROR:  permission denied for relation 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)

=> SELECT current_user;
 current_user 
--------------
 admin
(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をセキュリティ定義関数内に埋め込むことも可能です。）また、参照先テーブルに行共有ロックが同時に大量に発生するとパフォーマンス問題が起きるかもしれません。特にそのテーブルの更新が多いときは問題になるでしょう。別の解決策で、参照先テーブルの更新が少ない場合に現実的なのは、参照先テーブルの更新時に排他ロックを取得するものです。そうすれば、同時実行のトランザクションが行の古い値を調べることはできません。あるいは、参照先のテーブルの更新をコミットした後、単にすべての同時実行トランザクションが終わるのを待ってから、新しいセキュリティ状況に依存する変更をする、ということもできます。

更なる詳細はCREATE POLICYとALTER TABLEを参照して下さい。

前へ	上へ	次へ
5.6. 権限	ホーム	5.8. スキーマ