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セキュリティ総復習

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

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

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

More from Uptime Technologies LLC (JP)

More from Uptime Technologies LLC (JP) (9)

PostgreSQLセキュリティ総復習