PostgreSQLセキュリティ総復習

Copyright 2015 Uptime Technologies, LLC. All rights reserved. 1
PostgreSQLセキュリティ総復習
アップタイム・テクノロジーズ
永安悟史
PostgreSQLカンファレンス2015

アジェンダ
• 本セッションの⽬的
• 全体感
• クライアントからデータベースに
接続するまで
– アクセス制御
– 通信の暗号化
– ユーザ認証
– パスワードの設定
• コマンドの実⾏やオブジェクトへ
のアクセス
– ロール
– ロールとシステム権限の管理
– システム権限
– システム権限の獲得
– オブジェクト権限の管理
– 権限の棚卸、クリーニング
– SQLファイアーウォール
• テーブル内部の詳細な権限制御
– テーブル内部における権限設定
– ⾏レベルの制御
– 列レベルの制御
– データの暗号化
• ログと監査
– 「監査ログ」とは？
– pg_auditモジュール
– ログの収集と監査の実施
– ログの可視化
• その他
– バックアップファイルのセキュリ
ティ
– システムカタログ
– Postgres Advanced Security Pack
• 参考⽂献
• Q&A

本セッションの⽬的
• データベースを狙ったセキュリティインシデントが後を絶ちません
。そういう時代になりました。
• PostgreSQLを利⽤している、または利⽤しようとしている⽅に、
「今、PostgreSQLで何ができるのか？」を整理して提供したいと
思います。
• PostgreSQL単体でできること、周辺モジュールを使ってできるこ
と、設計や開発でできること、等。
• 「PostgreSQLとセキュリティ」を考える上で、「⾒取り図」的な
情報としてお役に⽴てれば幸いです。

PostgreSQLセキュリティの全体感
• データベースのさまざまなセキュリティ機能
– 検討事項が多岐に渡るため、⼤きな枠ごとに⾒ていく
PostgreSQLインスタンス
postgres
（リスナプロセス）
postgres
（サーバプロセス）
テーブル
インデックス
サーバログ
バックアップ
ファイル
クライアント
アクセス制御、認証、
セッション暗号化
セッション暗号化、
データ暗号化
エラーログ、
監査ログ
バックアップファイルの
セキュリティ
認可、アクセス制御、
データ暗号化

第1部
クライアントからデータベースに接続するまで

アクセス制御
• リモートからの接続を受け付ける
– postgresql.conf の listen_addresses パラメータ
– デフォルトはローカル（Unixドメインソケット）のみ可
• localhost も不可（TCP/IPをListenしていない）
• ホストベース認証（Host-Based Authentication）
– 設定ファイル pg_hba.conf
– 接続⽅法、データベース、ユーザ、接続元ホスト（またはネットワー
ク）の組み合わせに応じて、認証⽅法を設定。
• 認証⽅法
– “trust”, “reject”, “md5”, “password”, “gss”, “sspi”, "ident",
"peer", "pam", "ldap", "radius" or "cert"
https://www.postgresql.jp/document/9.4/html/runtime-config-connection.html
https://www.postgresql.jp/document/9.4/html/auth-pg-hba-conf.html

通信の暗号化
• SSLによる暗号化通信のサポート
– 認証セッション、データセッション、全部SSLで暗号化。
– postgresql.conf の ssl パラメータ
– SSLを強制する場合には pg_hba.conf で hostssl を指定。
• クライアント証明書のサポート
– クライアント証明書を利⽤することも可能。
– 認証局（CA）の設定が必要。
https://www.postgresql.jp/document/9.4/html/ssl-tcp.html

ユーザ認証
• クライアントサイドの認証設定
– 認証情報を .pgpass ファイルに指定することが可能。
– ホームディレクトリか環境変数 PGPASSFILE で指定。
– JDBCの場合は .pgpass は未サポート。
• その他、環境変数などでも設定可能
– libpqライブラリを使うクライアントツール（psqlなど）で共通で使え
る環境変数
https://www.postgresql.jp/document/9.4/html/libpq-pgpass.html
https://www.postgresql.jp/document/9.4/html/libpq-envars.html

パスワードの設定
• パスワードの設定⽅法
– ALTER ROLE foo PASSWORD ʻpasswdʼ;
– ¥password コマンド（psql）
• MD5で暗号化してパスワードを保存
– password_encryptionパラメータ（デフォルトon）
– ALTER ROLE foo ENCRYPTED PASSWORD ʻpasswdʼ;
• パスワードを設定する際の注意
– ALTER ROLEで平⽂パスワードを指定すると、サーバログに残る可能
性あり。（サーバログ設定に依存）
– MD5暗号化済みパスワードを指定するか、¥password コマンドを使⽤
すること。

第2部
コマンドの実⾏やオブジェクトへのアクセス

ロール
• PostgreSQLの権限制御はロールによる制御
– CREATE ROLE / ALTER ROLE / DROP ROLE
– システムビュー pg_roles
• PostgreSQLの「ユーザ、グループ」は「ロール」と同義
– ユーザはロールのエイリアス
– システムビュー pg_user と pg_group
• コマンド権限やオブジェクト権限をロールに割り振る
– 実⾏できる処理の権限（後述）
– ORACLEなどのように細かくない。
– 付与できる権限は次ページの通り。

ロールとシステム権限の管理
• ロールの設定（pg_roles）
– 権限（システム権限）
• rolsuper, rolcreaterole, rolcreatedb, rolcanlogin, rolreplication
– ロール権限の派⽣
• rolinherit
– 接続上限数
• rolconnlimit
– パスワード
• rolpassword
– 有効期限
• rolvaliduntil
– ロールごとの設定項⽬
• rolconfig
https://www.postgresql.jp/document/9.4/html/sql-createrole.html
https://www.postgresql.jp/document/9.4/html/view-pg-roles.html

システム権限
• 注意すべき権限
– rolsuperはすべての権限管理より優先する権限
– rolcreateroleは任意の権限（super除く）を持ったロールを作成可能
– rolcanloginはログイン可能な権限
データベースは rolcreatedb で作れても、EXTENSIONのインストールは
rolsuper が必要だったりするが・・・
‐‐ データベースの作成・削除が可能な admin_r ロールを作成
CREATE ROLE admin_r NOSUPERUSER CREATEDB NOCREATEROLE INHERIT
NOLOGIN NOREPLICATION;
‐‐ データベースやロールの作成などが⼀切できない webapp_r ロールを作成
CREATE ROLE webapp_r NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT
NOLOGIN NOREPLICATION
‐‐ ユーザ snaga を作成して admin_r ロールに割り当てる
CREATE ROLE snaga LOGIN INHERIT IN ROLE admin_r;
‐‐ ユーザ webapp を作成して webapp_r ロールに割り当てる
CREATE ROLE webapp LOGIN INHERIT IN ROLE webapp_r;

システム権限の獲得
• 所属しているロールのシステム権限を得るにはSET ROLEを使う
– 接続直後には、他のロールのシステム権限は持っていない。
postgres=> select
rolname,rolsuper,rolcreatedb from pg_roles;
rolname  | rolsuper | rolcreatedb
‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐
postgres | t        | t
webapp   | f        | f
webapp_r | f        | f
snaga    | f        | f
admin_r  | f        | t
(5 rows)
postgres=> select current_user;
current_user
‐‐‐‐‐‐‐‐‐‐‐‐‐‐
snaga
(1 row)
postgres=> create database testdb;
ERROR:  permission denied to create
database
postgres=>
postgres=> set role admin_r;
SET
postgres=> select current_user;
current_user
‐‐‐‐‐‐‐‐‐‐‐‐‐‐
admin_r
(1 row)
postgres=> create database testdb;
CREATE DATABASE
postgres=>
権限を持っていないユーザー snaga が、
admin_rに昇格してデータベースを作成。
→ 必要な時だけ権限を獲得する

ロールとアクセス制御の設定例
• ロールの設定
– postgresロール以外はロール操作権限なし。
– （管理者含む）⼀般のロールとpostgresロールは分離。SET ROLEも不可。
• pg_hba.confの設定
– ローカル（Unix domain socket）からの接続はすべてMD5認証。
– リモート（TCP/IP）からの postgres ユーザの接続はすべて拒否。
– リモート（127.0.0.1 or 10.0.2.0/24）からの他のユーザの接続はすべてMD5認証。
• 結果、ロールの操作はpostgresユーザでローカルから直接接続した場合のみ。
postgres=> ¥du
List of roles
Role name |                   Attributes                   | Member of
‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐
admin_r   | Create DB, Cannot login                        | {}
postgres  | Superuser, Create role, Create DB, Replication | {}
snaga     | No inheritance                                 | {admin_r}
webapp    | No inheritance   | {webapp_r}
webapp_r  | No inheritance, Cannot login                   | {}
local   all             all                                     md5
host    all             postgres        0.0.0.0/0               reject
host    all             all             127.0.0.1/32            md5
host    all             all             10.0.2.0/24             md5

オブジェクト権限の管理
• GRANT/REVOKEによるオブジェクト権限の管理
– テーブル
– テーブルカラム
– シーケンス
– データベース
– ドメイン
– 外部データラッパ
– 関数
– プロシージャ⾔語
– ラージオブジェクト
– スキーマ
– テーブルスペース
– データ型
https://www.postgresql.jp/document/9.4/html/sql-grant.html

オブジェクト権限の読み⽅
• psqlの¥dpコマンドの出⼒
– 「=」の左側は権限の保有者、右側は権限内容、「/」の右側は付与者
– ユーザ snaga の権限
• INSERT(a), SELECT(r), UPDATE(w), DELETE(d), TRUNCATE(D),
REFERENCES(x), TRIGGER(t)
– ロール webapp_r の権限
• SELECT(r)
• ユーザ snaga が付与した
testdb=> grant select on pgbench_accounts to webapp_r;
GRANT
testdb=> ¥dp pgbench_accounts
Access privileges
Schema | Name | Type | Access privileges | Column access
privileges
‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
public | pgbench_accounts | table | snaga=arwdDxt/snaga+|
| | | webapp_r=r/snaga |
(1 row)
testdb=>

権限の棚卸、クリーニング
• 権限の棚卸、クリーニングはセキュリティ管理の基本
• 最⼩権限分析
– ユーザーに実際に必要な権限のみを与える
• 不使⽤権限分析
– ユーザーが実際には使わなかった権限について分析する
• 「実際に使っているかどうか」を確認するのは
PostgreSQL単体では難しい
– 後述のSQLファイアーウォールや監査ログモジュールなどを⽤
いる

オブジェクト権限の確認⽅法
• システムテーブル pg_class の relacl カラム
– データ型は aclitem[]
• これらのカラムを確認することで、すべてのオブジェク
トに対する権限付与の状況を確認することができる
– 記録として残していけば、変更状況も追える
testdb=> select relname,relacl from pg_class where relname like 'pgbench%‘ and
relkind = ‘r’ order by relname;
relname        |                 relacl
‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
pgbench_accounts      | {snaga=arwdDxt/snaga,webapp_r=r/snaga}
pgbench_branches      | {snaga=arwdDxt/snaga,=r/snaga}
pgbench_history       |
pgbench_tellers       |
(4 rows)
testdb=>

SQLファイアーウォール
• いかにして「想定していないSQLの実⾏」を防ぐか
– SQLインジェクションに代表される問題
– アプリケーション、フレームワークでの対応は限界
– テーブル単位やDML単位の権限管理でも⼗分ではない
• 実⾏できるSQLを制限してしまえば良い
– SQLを好き放題何でも実⾏できる必要はない
• 技術的な課題
– リテラルが異なる場合
– スペースやコメントなどが異なる場合

sql_firewall
• 実⾏できるSQL⽂を制限することによって、SQLインジェクション
攻撃からの防御を実現。
– PostgreSQL内部の「フック」を利⽤
– pg_stat_statementsと同様の仕組みで、同⼀クエリIDごとに制御
• 学習モードで実⾏を許可するSQL⽂を学習させ、警告モードまたは
防御モードで動作させる。
– 学習モード（learning）
– 警告モード（permissive）
– 防御モード（enforcing）
• オープンソースで公開
– http://www.github.com/uptimejp/sql_firewall
– ライセンスはPostgreSQL License
http://pgsqldeepdive.blogspot.jp/2015/08/postgresql-sql-firewall.html

実⾏例
学習していないSQLの実⾏を防⽌

第3部
テーブル内部の詳細な権限制御

テーブルにおける権限設定
• テーブルとビューの権限の分離
• ⾏レベルの権限制御
– ビューによる制御
– RLSによる制御
• 列レベルセキュリティ
– ビューによる制御
– GRANT TABLE COLUMN
• トリガーによる更新の制御

テーブルとビューの権限の分離
• ビューは参照可能だが、テーブルは参照不可
You are now connected to database "testdb" as user "webapp".
testdb=> select * from t1;
ERROR:  permission denied for relation t1
testdb=> select * from v1;
rolname  | rolsuper | rolcreaterole | rolcreatedb
‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐
postgres | t        | t             | t
webapp   | f        | f             | f
webapp_r | f        | f             | f
snaga    | f        | f             | f
admin_r  | f        | f             | t
(5 rows)
testdb=>

ビューによる⾏レベルの制御
• どのような⾏を⾒せるかをビューの条件で制御する
• 例えば、実効ロールと⼀致する⾏だけ⾒せたい場合
postgres=> CREATE VIEW pg_all_roles AS SELECT * FROM pg_roles WHERE rolname =
current_user;
CREATE VIEW
ostgres=> SELECT rolname,rolsuper,rolcreaterole,rolcreatedb FROM pg_all_roles;
‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐
snaga | f | f | f
(1 row)
postgres=> SET ROLE admin_r;
SET
postgres=> SELECT rolname,rolsuper,rolcreaterole,rolcreatedb FROM pg_all_roles;
‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐
admin_r | f | f | t
(1 row)

⾏レベルセキュリティ（RLS）
• ⾏レベルセキュリティ（Row Level Security; RLS)
– テーブルに含まれるどの⾏が返却されるべきか、という、アク
セスポリシーの定義を可能にする
– デフォルトでは無効化されている
– CREATE POLICY, ALTER POLICY, DROP POLICY
• 制約
– PostgreSQL 9.5からの機能
– 現時点では、システムカタログには適⽤できない

実⾏例
• CREATE POLICY roles_table_policy1 ON roles_table
FOR ALL USING (rolname = current_user);
ユーザ名でフィルタするように
ポリシーを定義

実⾏例
• 各ユーザは、⾃分のユーザ名と⼀致した⾏のみを参照で
きる
“user01” は rolename が
‘user01’ レコードのみ
“user02” は rolename が
‘user02’ レコードのみ

Pgcryptoによるデータの暗号化
• pgcryptoモジュール
– contribに含まれるEXTENSION
– RPMの場合は postgresql94-contrib パッケージ
• 暗号化に関連するSQL関数を提供
– 汎⽤ハッシュ関数
– パスワードハッシュ化関数
– PGP暗号化関数
– 単純な暗号化関数
– ランダムデータ関数
• アプリケーションやプロシージャから呼び出すことでデータを暗号
化する
– ORACLEのDBMS_OBFUSCATION_TOOLKIT/DBMS_CRYPTOパッケ
ージと似ている。
https://www.postgresql.jp/document/9.4/html/pgcrypto.html
http://lets.postgresql.jp/documents/technical/contrib/pgcrypto/

実⾏例（1/2）
• pgp_sym_encrypt()関数を使って暗号化
– 暗号化済みデータはbytea型となる
testdb=> select pgp_sym_encrypt('Park Gyu‐ri', 'foo');
pgp_sym_encrypt
‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
¥xc30d040703029a823af0155d0c7d74d23c01827e1cea52f9a4bcb1485e727b25d76f5e8877cfaf7cd1c72
b9286db13150628023054a82fe514edfa319af9d1e2f20a046b8fcc98508e0d6c43d7
(1 row)
testdb=> insert into k1 values (1, pgp_sym_encrypt('Park Gyu‐ri', 'foo'));
INSERT 0 1
testdb=> select * from k1;
uid | uname
‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
1 | ¥xc30d04070302a4a1cac0e5c0194873d23c01a208db4f5cd40a5fe6c31560fc80d3e942d348 ...
(1 row)
testdb=> insert into k1 values (2, pgp_sym_encrypt('Nicole Jung', 'foo')),(3,
pgp_sym_encrypt('Goo Ha‐ra', 'foo')),(4, pgp_sym_encrypt('Han Seung‐yeon', 'foo')),(5,
pgp_sym_encrypt('Kang Ji‐young', 'foo'));
INSERT 0 4
testdb=>

実⾏例（2/2）
• pgp_sym_decript()関数を使って復号化
uid | uname
‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
1 | ¥xc30d04070302a4a1cac0e5c0194873d23c01a208db4f5cd40a5fe6c31560fc80d3e942d348 ...
2 | ¥xc30d0407030274f9225d4f781acb6cd23c01788a101491c122666504b28340924809722054 ...
3 | ¥xc30d04070302e748374655543b1f65d23a01e4002fa0dc18cdf9548741340645dceb8580ea ...
4 | ¥xc30d040703026b81ffb5501910046fd23f01defc373ba444e9978e89b12ed02e1039aab40e ...
5 | ¥xc30d04070302305cbe84633d5e877bd23e018471bff50d4eb2f12a8cab0f5c66f751b56e1d ...
(5 rows)
testdb=> select uid,pgp_sym_decrypt(uname, 'foo') as dec from k1;
uid | dec
‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
1 | Park Gyu‐ri
2 | Nicole Jung
3 | Goo Ha‐ra
4 | Han Seung‐yeon
5 | Kang Ji‐young
(5 rows)
testdb=>

透過的暗号化（TDE）
• TDE; Transparent Data Encryption
– SQL関数の呼び出しにはアプリケーションの改修が必要
– アプリの改修なしで「透過的に」暗号化を実現する
– 透過的 ≒ 明⽰的な処理をすることなく
– Pgcryptoモジュールを利⽤して暗号化データ型を実現
• Transparent Data Encryption for PostgreSQL
– 開発はNEC、2015年6⽉公開
– http://jpn.nec.com/press/201506/20150605_01.html
• Free Edition
– フリー版は暗号化textと暗号化byteaをサポート
– ライセンスはGPLv3
– https://github.com/nec-postgres/tdeforpg

実⾏例（1/2）
• カラムにencrypt_text型を指定してテーブルを作成
testdb=> create table k1 (uid integer primary key, uname encrypt_text );
CREATE TABLE
testdb=> select pgtde_begin_session('foo');
pgtde_begin_session
‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
t
(1 row)
testdb=> insert into k1 values (1, 'Park Gyu‐ri'),(2, 'Nicole Jung'),(3, 'Goo
Ha‐ra'),(4, 'Han Seung‐yeon'),(5, 'Kang Ji‐young');
INSERT 0 5
uid | uname
‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
1 | Park Gyu‐ri
2 | Nicole Jung
3 | Goo Ha‐ra
5 | Kang Ji‐young
(5 rows)
testdb=> ¥q
{1020}snaga@devvm04:~$

実⾏例（2/2）
• 別のセッションでは、鍵を設定しないと読み取り不可。
– 実際の鍵の設定前後には cipher_key_{disable,enable}_log() が必要
– 鍵情報がサーバログに残らないようにするため
{1020}snaga@devvm04:~$ psql ‐U snaga testdb
ERROR: TDE‐E0017 could not decrypt data, because key was not set(01)
testdb=> select pgtde_begin_session('foo');
pgtde_begin_session
‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
t
(1 row)
uid | uname
‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
1 | Park Gyu‐ri
2 | Nicole Jung
3 | Goo Ha‐ra
5 | Kang Ji‐young
(5 rows)

第4部
ログと監査

「監査ログ」とは？
• 監査のためのログ
– ⼀般的には「誰が、いつ、どこから、何に対して、何をして、どうな
ったか」（⽬的によって変わる）
• 監査の⽬的例
– 重要情報に関するアクセス
– 不正が疑われるアクセス
– 特権ユーザによるアクセス
– データベースに関する全てのアクセス
• 監査項⽬の例
– アクセスに失敗したユーザ
– 発⾏されたSQLクエリ
– アクセス頻度、時間帯
– DBスキーマの変更・削除
– アカウント変更・削除
– オブジェクト権限の変更・削除

pg_auditモジュール
• PostgreSQLのフックの機能を使い、実⾏したSQLのログを出⼒す
るEXTENSION
• 出⼒項⽬
– タイムスタンプ
– DB名
– ユーザ名、実効ユーザ名（SET ROLEした場合）
– クラス、コマンドタグ
– オブジェクトタイプ、オブジェクト名
– 実⾏コマンド
• 上記を既存の log_line_prefix と組み合わせて出⼒する
• DB、ユーザ、クラスなどは選択的に出⼒可能
https://github.com/2ndQuadrant/pgaudit

実⾏例（1/2）
• テーブルの作成とデータ挿⼊
– すべての監査ログイベントを出⼒するように設定
– クライアント側にもログを表⽰するように設定して実⾏
testdb=# set client_min_messages to log;
SET
testdb=# create table k1 (uid integer primary key, uname text );
LOG:  AUDIT,2015‐11‐27 11:46:56.526683+09,testdb,snaga,snaga,DEFINITION,CREATE
TABLE,TABLE,public.k1,create table k1 (uid integer primary key, uname text );
LOG:  AUDIT,2015‐11‐27 11:46:56.546729+09,testdb,snaga,snaga,DEFINITION,CREATE
INDEX,INDEX,public.k1_pkey,create table k1 (uid integer primary key, uname text );
CREATE TABLE
testdb=# insert into k1 values (1, 'Park Gyu‐ri'),(2, 'Nicole Jung'),(3, 'Goo Ha‐
ra'),(4, 'Han Seung‐yeon'),(5, 'Kang Ji‐young');
LOG:  AUDIT,2015‐11‐27
11:47:01.647673+09,testdb,snaga,snaga,WRITE,INSERT,TABLE,public.k1,insert into k1
values (1, 'Park Gyu‐ri'),(2, 'Nicole Jung'),(3, 'Goo Ha‐ra'),(4, 'Han Seung‐
yeon'),(5, 'Kang Ji‐young');
INSERT 0 5
testdb=#

実⾏例（2/2）
• データの参照と権限の付与
testdb=# select * from k1;
LOG:  AUDIT,2015‐11‐27 11:47:07.221334+09,testdb,snaga,snaga,READ,SELECT,TABLE,pub
lic.k1,select * from k1;
uid |     uname
‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
1 | Park Gyu‐ri
2 | Nicole Jung
3 | Goo Ha‐ra
5 | Kang Ji‐young
(5 rows)
testdb=# grant select on k1 to public;
LOG:  AUDIT,2015‐11‐27 11:47:11.328344+09,testdb,snaga,snaga,PRIVILEGE,GRANT,,,gra
nt select on k1 to public;
GRANT
testdb=#

ログの収集と監査の実施
• 「コンプライアンス上、ログを残します」という要件は多いが…
– 本当に「監査」していますか？
– 例えば、以下のようなエラーメッセージ
• FATAL: role "foo" does not exist
• FATAL: password authentication failed for user "postgres"
• FATAL: permission denied for database "postgres"
• ERROR: permission denied for relation orders
• セキュリティインシデントをすぐに検知できますか？
– 検知をしないと回復はできない
– 「実は半年前からデータを抜かれてました」（←よくある話）
• セキュリティコントロールの4機能
– 「抑⽌／予防／検知／回復」
– ⽇本の企業は「検知」と「回復」が弱い傾向（PwC 林⽒）

ログの可視化
• 監査に向けての第⼀歩として、可視化して分布、パターンを⾒る
– BIツールの利⽤がオススメ（⾃在な分析軸とレポート機能）

第5部
その他

バックアップファイル
• バックアップファイルは暗号化されない
– PostgreSQLとしては機能も提供していない
• D2Dのバックアップのリスク
– 最新世代はディスクに置きっぱなし
– ファイルシステムやファイルなどのレベルで保護を

システムカタログ
• 関連するシステムカタログ⼀覧
– pg_auth_members
– pg_authid
– pg_db_role_setting
– pg_default_acl
– pg_group
– pg_roles
– pg_seclabel
– pg_shadow
– pg_user
– pg_user_mapping, pg_user_mappings

Postgres Advanced Security Pack
• セキュリティ関連モジュールをオールインワン・パッケージ化
– 導⼊時に個別にビルドしたり検証したりする必要がなくなる
– 独⾃の追加ドキュメントも同梱
– オープンソースライセンス（各モジュールのライセンスに依存）
– 現在、テクノロジープレビュー版（バージョン0.8）
• Postgres Advanced Security Pack 0.8に含まれるモジュール
– tdeforpg （透過的暗号化）
– pgaudit （監査ログ）
– sql_firewall （SQLファイアーウォール）
• リリース案内、導⼊⽅法など
– http://pgsqldeepdive.blogspot.jp/2015/10/postgres-advanced-
security-pack.html

参考⽂献
• データベースセキュリティガイドライン第2.0版（データベースセ
キュリティコンソーシアム）
• DB内部不正対策ガイドライン第1.0版（同上）
• データベース暗号化ガイドライン第1.0版（同上）
• 統合ログ管理サービスガイドライン第1.0版（同上）
• Oracleデータベースセキュリティセキュアなデータベース構築・
運⽤の原則（翔泳社）

Q&A
コメント、質問など
Twitter: @snaga
E-Mail: snaga@uptime.jp

PostgreSQLセキュリティ総復習

More Related Content

What's hot

Viewers also liked

Similar to PostgreSQLセキュリティ総復習

More from Uptime Technologies LLC (JP)

PostgreSQLセキュリティ総復習