監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性

Copyright©2015 NTT Corp. All Rights Reserved.
監査要件を有するシステムに対す
る PostgreSQL 導入の課題と可能
性
NTT OSSセンタ
大山真実

2Copyright©2015 NTT corp. All Rights Reserved.
突然ですが、、、
DBの監査って重要ですよね！

最近の内部不正事件
引用元：IPA 「組織における内部不正対策」 http://www.ipa.go.jp/files/000047237.pdf

最近の内部不正事件
引用元：IPA 「組織における内部不正対策」 http://www.ipa.go.jp/files/000047237.pdf
を用いて犯
行に至ることも！

DB管理者が疑われてしまう！？
示唆した。また情報に対する侵害を分類し、漏えい（機密性）、破壊（可用性）、改ざん（完
全性）についてそれぞれ質問し、加えてパスワードの漏えいについても質問したが、結果
はほぼ同じ傾向を示した。
Q: 将来、データベースに格納されている情報をこっそり売却するかも知れない。（図 3-20）
そう思う
3.6%
ややそう思う
7.1%
どちらともい
えない
13.4%
あまりそう思
わない
10.4%
そう思わない
65.5%
引用元：DBSC 「DBA 1,000 人に聞きました」アンケート調査報告書
http://www.db-security.org/report/dbsc_dba_ver1.0.pdf
約1割のDB管理者がDBに
格納されている情報を売
却するかもしれない!?

Q: 将来、データベースに格納されている情報をこっそり改ざんするかも知れない。（図 3-22）
そう思う
2.4%
ややそう思う
7.4%
どちらともい
えない
14.4%
あまりそう思
わない
10.7%
そう思わない
65.1%
約1割のDB管理者がDBに
格納されている情報を改
ざんするかもしれない!?

Q: 将来、データベースを壊して業務を妨害することがあるかも知れない。（図 3-21）
Q: 将来、データベースに格納されている情報をこっそり改ざんするかも知れない。（図 3-22）
そう思う
2.9%
ややそう思う
6.5%
どちらとも
いえない
15.5%
あまりそう
思わない
9.6%
そう思わない
65.5%
約1割のDB管理者がDBを
破壊するかもしれない!?

不正対策 3ポイント
1. 管理者の誘因
雇用条件/職場環境/幸福度の向上
「一般的に職場環境、雇用条件が満たされている管理者であれば
業務に対して責任を持った行動を取るはずである。」
2. 管理者の抑制
 アクセス制御/権限分掌/暗号化/鍵管理
3. 運用の実施
「2.管理者の抑制」が有効になっていることを定期的に監査・監視する仕組
み・体制
 ポリシーの制定
 監査・監視
体制/ログの取得/ログ確認/ログ保全
引用元：DBSC 「DB 内部不正対策ガイドライン」
http://www.db-security.org/report/antifraud_guide_ver1.0.pdf

操作ログの取得が有効
引用元：IPA「組織における内部不正対策」 http://www.ipa.go.jp/files/000047237.pdf
Q. 「内部不正防止効果が期待できる対策は？」
以降、監査目的で取得するDBの操作ログのことを監査ログと呼称する。

でもPostgreSQLって監査ログ出力機能無いですよね？

でもPostgreSQLって監査ログ出力機能無いですよね？
log_statement = all
があるじゃない！

log_statement = all があるじゃない！
＊ 2014 年度 WG3 活動報告セキュリティ編,
https://www.pgecons.org/downloads/101
PostgreSQLエンタープライズコンソーシアムでは、PCI DSS 要
件を満たす必要があるシステムに対して、PostgreSQL を導入し
ようとした場合に、対応可能か、どのように対応すればいいかを
調査し、上記のように報告*
OSの機能やサードパーティ/商用製品と組み合わ
せることで、概ね課題をクリアできる
PGEConsの報告
詳細は「付録A」参照

しかしながら...

サーバログを
監査ログとして使う上での課題

サーバログを
監査ログとして使う上での課題
PGEConsの検討結果も参考に、より堅牢な監査が可能
か、性能上の課題がないかについて調査した

サーバログを監査ログとして使う上での課題
監査するのが大変なログ問題
運用ログと監査ログ混ざっちゃう問題
性能低下問題
スーパーユーザなんでもできちゃう問題

• オブジェクト名
• SQLで渡されたパラメータ
• スキーマ名
サーバログでは下記のような情報が出力されない。
１．Do文などの利用時にどのオブジェクトに対して
どのような操作が行われたのか判別するのが困難
２．異なるスキーマの同一名テーブル判別不可
=>監査ログの分析が困難
これらの情報が出力されないのは大きな課題
例えば...

１．Do文利用時
ログ出力例(log_statement = all)：
SQL例：
LOG: statement: DO $$
BEGIN
EXECUTE 'SELECT * FROM import' || 'ant_table';
END $$;
testdb=# DO $$
BEGIN
END $$;
ログ分析時に’important_table’で検索しても上記のSELECTは発見
できない。

2．PREPARE文利用時
ログ出力例(log_statement = all, log_error_verbosity = default)：
SQL例：
testdb=# PREPARE test (int) AS SELECT * FROM
pgbench_accounts WHERE aid = $1;
...
testdb=# EXECUTE test (3);
このようなログでは、どのようなテーブルにどのようなクエリが投げら
れたかを確認するのは大変。
LOG: statement: PREPARE test (int) AS
SELECT * FROM pgbench_accounts WHERE aid = $1;
...
LOG: statement: EXECUTE test (3);
DETAIL: prepare: PREPARE test (int) AS SELECT * FROM

3．異なるスキーマの同一名テーブル判別不可
ログ出力例(log_statement = all)：
SQL例その１：
testdb=# CREATE TABLE schm1.tbl();
testdb=# SET search_path TO schm1;
testdb=# SELECT * FROM tbl;
search_pathが設定されていた場合、上記のようにSQLの実行対象が
判別不可。
LOG: statement: CREATE TABLE schm1.tbl();
LOG: statement: CREATE TABLE schm2.tbl();
LOG: statement: SET search_path TO schm1;
LOG: statement: SELECT * FROM tbl;

性能低下
ログ出力対象の範囲は一番小さい粒度でも
• データベースごと
• ロールごと
大量のログ出力に伴う性能低下の恐れ
=>監査要件に必要な最小限の情報のみ出力したい
例えば...
特定のテーブル、列に関するSELECTのみ出力

0.0
500.0
1000.0
1500.0
2000.0
2500.0
3000.0
3500.0
4000.0
20000 22000 24000 26000 28000 30000
1.log_statement=none
2.log_statement=all
DBT-1ベンチマーク結果
EU数
スループット[BT]
Dell PowerEdge R410
CPU:Xeon(R)E5645 2.40GHz 2CPU12core
Memory:32GB
OS:RHEL6u6
PostgreSQL:9.3.5rpm
DBsize:148Gbyte
約20%性能ダウン
性能低下

１．運用者が業務に関係ない重要情報に触れてしまう
サーバログは運用で利用する。
DB運用者が監査ログを閲覧できてしまうことになる。
２．分析するのが大変
３．サーバログ自体の監査が難しい
「2014 年度 WG3 活動報告セキュリティ編」
ではOSの機能(auditd)の利用を推奨。
=>サーバログと監査ログを分離したい。
監査ログのみを別サーバに転送するなどして、
運用者、管理者が閲覧、改ざんできなくしたい。

スーパーユーザは監査ログを容易に改変可能
監査ログに関する設定はGUCなので様々な方法で
設定を変更できる。
=>スーパーユーザの監査ログを適切に取得したい。
スーパーユーザでも簡単に監査ログ出力設定を
変更できないようにしたい。
例：
$ env PGOPTIONS="-c log_statement=none" psql
上記の設定変更はサーバログに出力されない。
全く気づかれずに設定変更可能。

性能低下問題

PostgreSQLの監査ログ出力ツール
「pgaudit」
そこで！

pgauditとは？
 PostgreSQLの監査ログ出力用外部ツール
 PostgreSQL9.5対応
 pgaduitのこれまでの経緯
 2014年の初めくらいからPostgreSQLコミュニティで議論。
 2ndQuadrantが開発していた「pgaudit」を David Steele
@ Crunchy Data Solutions が引き継ぎ「pg_audit」として
コミュニティ開発を継続。
 2015年5月、PostgreSQLのcontribにコミットされるも、数日
後に除外される。
 2015年7月、「pgaudit」と名前を変えてGithubに公開。
https://github.com/pgaudit/pgaudit
※複数の pgaudit, pg_audit が存在しているので注意！

pgauditの特徴
 pgauditの設定値は全てGUC
• postgresql.conf、SQLでデータベースクラスタ全体に設定
• データベース単位で設定可能
• ロール単位で設定可能
 ログはサーバログに出力される
 shared_preload_librariesにpgauditを設定
設定値の詳細は「付録B」参照
 サーバログより粒度の細かいログ出力設定が可能
 コマンドの種類(クラス)ごと
Session Audit Logging モード
 テーブル、列ごと
Object Auditing モード
 サーバログで取得できない情報を取得可能
 テーブル名、スキーマ名
 SQLで渡したパラメータ

pgauditの出力項目
出力項目名説明
AUDIT_TYPE ログ出力モード：SESSION または OBJECT
STATEMENT_ID 1セッション内の1SQLを識別する数字
SUBSTATEMENT_ID 関数の実行など、1SQL内で複数のSQLが実行された
場合に識別する数字
CLASS SQLの種類(クラス)→後述
COMMAND SQLの種類(コマンド単位)：SELECTなど
OBJECT_TYPE オブジェクトの種類：TABLEなど
OBJECT_NAME オブジェクト名
STATEMENT 実行されたSQL文全体
PARAMETER 実行されたSQLに渡されたパラメータ
＋ log_line_prefixで設定可能な出力項目

pgauditの出力項目
出力項目名説明
AUDIT_TYPE ログ出力モード：SESSION または OBJECT
STATEMENT_ID 1セッション内の1SQLを識別する数字
SUBSTATEMENT_ID 関数の実行など、1SQL内で複数のSQLが実行された
場合に識別する数字
CLASS SQLの種類(クラス)→後述
COMMAND SQLの種類(コマンド単位)：SELECTなど
OBJECT_TYPE オブジェクトの種類：TABLEなど
OBJECT_NAME オブジェクト名
STATEMENT 実行されたSQL文全体
PARAMETER 実行されたSQLに渡されたパラメータ
オブジェクト情報やSQL中のパラメータ情報を出力可能
＋ log_line_prefixで設定可能な出力項目

Session Audit Logging と Object Auditing
Session Audit Logging
特定のクラスに属するSQLが実行されたらログ出力。
例えば...
WRITEとDDLクラスに属するSQLが実行されたら出力。
Object Auditing
特定のオブジェクトに対して操作が実行されたらログ出力。
例えば...
特定のテーブルの特定の行に対してSELECTが
実行されたらログ出力。
ログ出力を制御する2つのログ出力モードが存在。
併用可。

Session Audit Logging について
・ログを出力したいSQLのクラスを指定する。
‘ALL, -MISC’でMISCだけ除く、といった設定も可能
利用方法
pgaudit.log = クラス名, ...
クラス名一覧
READ SELECT, VALUES, COPY など
WRITE INSERT, UPDATE, DELETE, TRUNCATE, COPY など
FUNCTION DO
ROLE CREATE|ALTER|DROP USER|ROLE|GROUP, GRANT, REVOKE など
DDL CREATE ... , ALTER ... , DROP ... , REINDEX, SELECT INTO など
MISC VACUUM, ANALYZE, BEGIN, COMMIT, ROLLBACK, SET, LOCK など
ALL 全てのSQL

Session Audit Logging について
postgresql.conf
LOG: AUDIT: SESSION,1,1,MISC,BEGIN,,,BEGIN;,<not logged>
LOG: AUDIT: SESSION,2,1,WRITE,UPDATE,,,
UPDATE pgbench_accounts SET bid = '4'
WHERE aid = '1';,<not logged>
LOG: AUDIT: SESSION,3,1,MISC,COMMIT,,,COMMIT;,<not logged>
設定例
shared_preload_libraries = pgaudit
pgaudit.log = 'WRITE, DDL, MISC’
出力例
SQL実行：
testdb=# BEGIN;
testdb=# SELECT * FROM pgbench_accounts LIMIT 1;
testdb=# UPDATE pgbench_accounts SET bid = '4' WHERE aid = '1';
testdb=# COMMIT;
出力結果：SELECTは出力されていない

Object Auditingについて
‘ロール名’に特定のロールを設定。
このロールがオブジェクトに対して
実行可能な操作のログを出力する。
利用方法
・ログを出力したいオブジェクトに対する
権限を付与したロールを指定する。
pgaudit.role = ロール名
設定可能な操作
SELECT, INSERT, UPDATE, DELETE

postgresql.conf（ロール名は任意）
LOG: AUDIT: OBJECT,19,1,READ,SELECT,TABLE,public.pgbench_accounts,
SELECT * FROM pgbench_accounts JOIN pgbench_branches
ON (pgbench_accounts.bid = pgbench_branches.bid);,<none>
表単位のログ出力設定例
shared_preload_libraries = pgaudit
pgaudit.role = 'auditor‘
出力例
SQL実行：
testdb=# SELECT * FROM pgbench_accounts JOIN pgbench_branches
ON (pgbench_accounts.bid = pgbench_branches.bid);
出力結果：pgbench_branchesに関するログは出力されていない
auditorロールを作成。ログを出力したいオブジェクトに対する権限を設定。
testdb=# CREATE ROLE auditor;
testdb=# GRANT SELECT ON pgbench_accounts TO auditor;

LOG: AUDIT: OBJECT,21,1,READ,SELECT,TABLE,public.pgbench_accounts,
SELECT aid FROM pgbench_accounts;,<none>
LOG: AUDIT: SESSION,21,1,READ,SELECT,TABLE,public.pgbench_accounts,
SELECT aid FROM pgbench_accounts;,<none>
select bid from pgbench_accounts;,<none>
列単位のログ出力設定例
出力例
SQL実行：
testdb=# SELECT aid FROM pgbench_accounts;
testdb=# SELECT bid FROM pgbench_accounts;
出力結果：bid列に関するObjectログは出力されていない
auditorロールにpgbench_accountsのSELECT権限のみ付与
testdb=# GRANT SELECT (aid) ON pgbench_accounts TO auditor;
確認のため“pgaudit.log=READ”を設定。
sessionログは上記の2クエリに対して出力されている。

pgauditはサーバログの課題を解決可能か？

• スキーマ名

• スキーマ名
前述の具体例を使って pgaudit がどのような
ログを出力するのか確認する。
pgaudit
で出力可！

１．Do文利用時
ログ出力例(pgaudit.log = READ)：
SQL例：
LOG: AUDIT: SESSION,2,1,READ,SELECT,TABLE,
public.important_table,
SELECT * FROM important_table,<none>
testdb=# DO $$
BEGIN
END $$;
オブジェクト名としてテーブル名が表示されている。
DO文の中で実行されたSQLが出力されている。
特定のテーブルに対するSELECT操作であることを容易に確認可。

2．PREPARE文利用時
SQL例その２：
testdb=# PREPARE test (int) AS SELECT * FROM
...
testdb=# EXECUTE test (3);
pgbench_accountsに対して“aid=3”の条件で
SELECTが実行されたことが1行のログで確認可能。
LOG: AUDIT: SESSION,5,1,READ,SELECT,TABLE,
public.pgbench_accounts,PREPARE test (int)
AS SELECT * FROM pgbench_accounts
WHERE aid = $1;,3

3．異なるスキーマの同一名テーブル判別不可
SQL例その１：
testdb=# SET search_path TO schm1;
testdb=# SELECT * FROM tbl;
search_pathが設定されていたとしても、schm1スキーマの
テーブルに対してSELECTが実行されていることが1行のログで
確認可能。
LOG: AUDIT: SESSION,4,1,READ,SELECT,TABLE,schm1.tbl,
SELECT * FROM tbl;,<none>

解決メタ情報が出力されるので監査し易くなった！

 不必要なログ出力を抑制することが可能な
ので、必要な情報のみを扱うことができる。
解決メタ情報が出力されるので監査し易くなった！
• スキーマ名
 下記のようなメタ情報が出力されるので、
サーバログより監査が容易。

性能低下

性能低下
解決ログ出力に伴う性能低下を抑えることが可能！

性能低下
解決ログ出力に伴う性能低下を抑えることが可能！
 特定のテーブル、列、操作のみに限定して
ログ出力が可能
 監査要件に合わせて最小限の情報のみ
取得可能
ただし、
• 出力項目の柔軟なカスタマイズ
• 時間帯を指定したログ出力
など、より粒度の細かいログ量調整は不可能。

未解決
全てのログはサーバログに出力される

未解決
全てのログはサーバログに出力される
 pgauditの全てのログはサーバログに出力
 サーバログを監査ログとして使う時と同じ
問題が依然として存在している。
１．運用者が業務に関係ない重要情報に触れてしまう
２．分析するのが大変
３．改ざんし易い
再掲：

未解決
スーパーユーザはpgauditの設定を自由に変更可能

未解決
スーパーユーザはpgauditの設定を自由に変更可能
 pgauditの全ての設定値はGUC
 スーパーユーザの監査ログをいかに取得す
るかは依然として大きな課題。
 設定ファイルや監査ログをOSレベルで監査
することも必要。OSの機能(auditd)などを
利用することを検討する。

pgauditまとめ

pgauditまとめ
pgauditは「サーバログを監査ログとして使う上での
課題」を解決することができるか？
再掲：
性能低下問題

pgauditまとめ
pgauditは「サーバログを監査ログとして使う上での
課題」を解決することができるか？
再掲：
性能低下問題
pgauditで
解決！
pgauditで
解決！
pgauditでも
解決できず...
pgauditでも
解決できず...

pgauditまとめ
 サーバログによる監査ログ出力と同様の権限分
掌問題は依然として解決しておらず、DB管理者
の操作ログを取得する目的での使用は適さない。
 オブジェクト情報、スキーマ情報などサーバロ
グで取得できなかったメタ情報が取得可能に
なった。
 細やかなログ出力設定が可能になり、監査ログ
出力要件に応じてログ出力量を抑えることが可
能になった。

pgauditに対する要望
 スーパーユーザに設定を自由に変更させない
 pgauditの設定値をGUCではない値としたい
 設定ファイルを分けたい
 サーバログと監査ログの出力先を分離
 これに伴い接続やSQLやトランザクションの成功失敗を
出力させる必要ある
 別のサーバに送信などできるとベスト
 任意の出力項目、より柔軟なフィルタ
 個別の監査要件に必要な出力項目を自由に設定
 特定の時間帯に絞ったログ出力

ちなみに

Audit Log Analyzer
現状はβ版。
今後に期待！
 サーバログに出力されたpgauditのログをパースして
pgauditテーブルに格納する。監査者はSQLを使って監
査ログを分析可能。
 pgaudit_analyzeデーモンがサーバログ(CSV形式)を
自動で読み込み、pgauditテーブルに監査ログを格納す
る。
pgaudit.audit_statement
pgaudit.audit_substatement
pgaudit.audit_substatement_detail
pgaudit.log_event
pgaudit.logevent_pk
pgaudit.session
pgaudit.vw_audit_event
下記テーブルを作成するスクリプトが提供されている。

付録

引用元：PGECons「2014 年度 WG3 活動報告セキュリティ編」 https://www.pgecons.org/downloads/101
※スライドのスペースの都合上、引用元より一部省略・要約しています。
# 要件対応レベル対応策
10.2.1 カード会員情報への全てのアクセス ◯ log_statement
10.2.2 スーパーユーザの全ての操作 ◯ log_statement
10.2.3 監査ログに対する全てのアクセス △ OS機能(auditdなど)
10.2.4 無効な操作の試行 ◯ log_min_messages
10.2.5 ログイン/ログアウト ◯ log_connection,
log_disconnection
10.2.6 ログ出力機能の設定変更、初期化 △ OS機能(auditdなど)
10.2.7 DBオブジェクトの生成、削除 ◯ log_statement
10.2 ログの出力契機の要件
付録A：PostgreSQLログ出力機能のPCI DSS 対応状況
◯： PostgreSQL標準機能で対応可
△：一部だけ、または外部ツールやOS機能を組み合わせれば対応可
☓：対応不可
PCI DSS のログ出力契機の要件にほぼ対応することができる

引用元：PGECons「2014 年度 WG3 活動報告セキュリティ編」 https://www.pgecons.org/downloads/101
※スライドのスペースの都合上、引用元より一部省略・要約しています。
# 要件対応レベル対応策
10.3.1 DB、OSアカウント名 △ log_line_prefix
10.3.2 SQLの種類、タイプなど ◯ log_line_prefix
10.3.3 日付と時刻 ◯ log_line_prefix
10.3.4 成功または失敗を示す情報 ◯ log_line_prefix
10.3.5 DB クライアントの IP アドレスなど ◯ log_line_prefix
10.3.6 オブジェクト名、オブジェクトID、
カラム名、カラムIDなど
☓ ー
10.3.1 DBのアカウント名、OSアカウント名 △ log_line_prefix
10.3 ログの出力項目の要件
付録A：PostgreSQLログ出力機能のPCI DSS 対応状況
◯： PostgreSQL標準機能で対応可
△：一部だけ、または外部ツールやOS機能を組み合わせれば対応可
☓：対応不可
PCI DSS のログ出力項目の要件にほぼ対応することができる

付録A:PostgreSQLログ出力機能のPCI DSS 対応状況
既存のログ出力機能（サーバログ）でも
PCI DSS 監査ログ出力要件に”ほぼ”対応できる
 postgresqsl.confを適切に設定
 OSの権限を適切に設定
 postgresqsl.confやサーバログへの操作ログを取得
auditdなどOSの機能を利用
スーパーユーザになれるOSユーザは postgresqsl.conf 変更不可
スーパーユーザになれるOSユーザはサーバログ改ざん不可
log_statement = all
log_min_error_statement、log_min_messages
log_connection、log_disconnection
log_line_prefix
log_error_verbosity
log_file_mode = 0000

付録B：pgauditのインストール
 PostgreSQLのインストール
 pgauditのインストール
# git clone https://github.com/postgres/postgres.git
# git checkout REL9_5_STABLE
# ./configure
# make install -s
# cd contrib
# git clone https://github.com/pgaudit/pgaudit.git
# cd pgaudit
# make -s check
# make install

付録B：pgaudit その他の設定
• pgaudit.log_relation
セッションログ利用時に使用するパラメータ。
オブジェクトタイプ、オブジェクトネームを出力するかどうかを
設定。Object Auditing を利用している場合、必要ないのであれ
ば出力させない。
• 設定例
pgaudit.log_relation = on （default: off）
• 出力例
LOG: AUDIT: SESSION,1,1,MISC,BEGIN,,,BEGIN;,<not logged>
LOG: AUDIT: SESSION,2,1,WRITE,UPDATE,TABLE,public.pgbench_accounts,
UPDATE pgbench_accounts SET bid = '4'
WHERE aid = '1';,<not logged>
LOG: AUDIT: SESSION,3,1,MISC,COMMIT,,,COMMIT;,<not logged>

• pgaudit.log_parameter
SQL中のパラメータで渡した値を出力する。
• 設定例
pgaudit.log_parameter = on（default: off）
• 出力例
LOG: AUDIT: SESSION,1,1,READ,PREPARE,,,PREPARE test (int) AS SELECT * FROM pgbench_accounts where aid =
$1;,<none>
LOG: AUDIT: SESSION,2,1,READ,SELECT,TABLE,public.pgbench_accounts,PREPARE test (int) AS SELECT * FROM
pgbench_accounts where aid = $1;,1
LOG: AUDIT: SESSION,2,2,MISC,EXECUTE,,,EXECUTE test (1);,<none>
LOG: AUDIT: SESSION,1,1,READ,PREPARE,,,PREPARE test (int) AS SELECT * FROM pgbench_accounts where aid =
$1;,<not logged>
LOG: AUDIT: SESSION,2,1,READ,SELECT,TABLE,public.pgbench_accounts,PREPARE test (int) AS SELECT * FROM
pgbench_accounts where aid = $1;,<not logged>
LOG: AUDIT: SESSION,2,2,MISC,EXECUTE,,,EXECUTE test (1);,<not logged>
ON設定時
OFF設定時

• pgaudit.log_statement_once
同じSQL文を複数回出力しない。
• 設定例
pgaudit.log_statement_once = on（default: off）
• 出力例
LOG: AUDIT: OBJECT,19,1,READ,SELECT,TABLE,public.pgbench_accounts,select * from pgbench_accounts join
pgbench_branches
on (pgbench_accounts.bid = pgbench_branches.bid) limit 1;,<none>
<previously logged>,<previously logged>
LOG: AUDIT: SESSION,19,1,READ,SELECT,TABLE,public.pgbench_branches,
select * from pgbench_accounts join pgbench_branches on (pgbench_accounts.bid = pgbench_branches.bid) limit 10;,<not
logged>
LOG: AUDIT: SESSION,1,1,READ,SELECT,TABLE,public.pgbench_branches,
ON設定＋オブジェクトログ混在時
ON設定時

• pgaudit.log_catalog
pg_catalogに対するログを出力かを設定する。
• pgaudit.log_level
pgauditが出力するログのログレベルを設定する。
• 設定例
pgaudit.log_level = warning （default: log）
• 出力例
WARNING: AUDIT: SESSION,9,1,MISC,SET,,,
set pgaudit.log_level = warning;,<none>
WARNING: AUDIT: SESSION,10,1,READ,SELECT,TABLE,public.pgbench_accounts,
select bid from pgbench_accounts;,<none>

監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性

Recommended

More Related Content

What's hot (20)

Similar to 監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性 (20)

監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性

Editor's Notes