監査要件を有するシステムに対する 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 導入の課題と可能性

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

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

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

Mehr von Ohyama Masanori

Mehr von Ohyama Masanori (6)

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

Hinweis der Redaktion