PostgreSQL監査ログのベストプラクティス

重要なビジネスタスクが行われるすべてのITシステムでは、ポリシーとプラクティスの明示的なセットを用意し、それらが尊重され、遵守されていることを確認することが重要です。

監査の概要

情報技術システムの監査は、特定の一連の目的に対するITインフラストラクチャに関する組織のポリシー、プロセス、手順、および慣行の調査です。 IT監査には、次の2つの一般的なタイプがあります。

限られたデータサブセットの一連の標準と照合する
システム全体をチェックする

IT監査は、特定の一連の規制（SOXなど）をサポートするための財務データに関連するものなど、特定の重要なシステムパーツ、またはニーズに対応する新しいEUGDPR規制などの規制に対するセキュリティインフラストラクチャ全体を対象とする場合があります。プライバシーを保護し、個人データ管理のガイドラインを設定します。 SOXの例は上記の前者のタイプですが、GDPRは後者のタイプです。

監査ライフサイクル

計画

スコープ 監査の範囲は、監査の目的によって異なります。範囲は、財務活動などの特定のビジネス活動によって識別される特別なアプリケーション、またはシステムセキュリティやデータセキュリティなどをカバーするITインフラストラクチャ全体をカバーする場合があります。スコープは、初期計画フェーズの初期段階として事前に正しく識別されている必要があります。組織は、監査の計画を支援するために必要なすべての背景情報を監査人に提供することになっています。これは、機能/技術仕様、システムアーキテクチャ図、またはその他の要求された情報である可能性があります。

管理目標

範囲に基づいて、監査人は監査によってテストされる一連の管理目標を形成します。これらの管理目標は、スコープで説明されている範囲で管理を達成するために実施されることになっている管理手法を介して実装されます。管理目標はテスト計画に関連付けられており、それらが一緒になって監査プログラムを構成します。 監査プログラムに基づく監査対象の組織は、監査人を支援するためにリソースを割り当てます。

調査結果

監査人は、すべての管理目標が達成されているという証拠を入手しようとします。ある管理目的についてそのような証拠がない場合、最初に監査人は会社が特定の管理目的を処理する別の方法があるかどうかを確認しようとします。そのような方法が存在する場合、この管理目的は補償としてマークされます。監査人は、目的が達成されたと見なします。ただし、目的が達成されたという証拠がまったくない場合、これは調査結果としてマークされます。。各調査結果は、条件、基準、原因、結果、および推奨事項で構成されています。 IT管理者は、すべての潜在的な調査結果を通知するために監査人と緊密に連絡を取り、管理目標が達成されることを保証するために、要求されたすべての情報が管理者と監査人の間で共有されるようにする必要があります（したがって、見つける）。

評価レポート

監査プロセスの最後に、監査人は、監査のすべての重要な部分をカバーする要約として評価レポートを作成します。これには、潜在的な調査結果に続いて、目的が適切に対処されているかどうかに関するステートメントと、調査結果の影響を排除するための推奨事項が含まれます。

監査ログとは何ですか。なぜそれを行う必要がありますか？

監査人は、ソフトウェア、データ、およびセキュリティシステムの変更に完全にアクセスできることを望んでいます。彼/彼女は、ビジネスデータの変更を追跡できるだけでなく、組織図、セキュリティポリシー、役割/グループの定義、および役割/グループメンバーシップの変更も追跡できるようにしたいと考えています。監査を実行する最も一般的な方法は、ロギングを使用することです。過去にはログファイルなしでIT監査に合格することは可能でしたが、今日では（唯一ではないにしても）推奨される方法です。

通常、平均的なITシステムは少なくとも2つの層で構成されています。

データベース
アプリケーション（おそらくアプリケーションサーバー上にある）

アプリケーションはユーザーアクセスとアクションをカバーする独自のログを維持し、データベースと場合によってはアプリケーションサーバーシステムは独自のログを維持します。監査人の観点から実際のビジネス価値があるログファイル内のクリーンですぐに使用できる情報は、監査証跡と呼ばれます。。監査証跡は、次の点で通常のログファイル（ネイティブログと呼ばれることもあります）とは異なります。

ログファイルは不要です
取引の履歴は長期間保持する必要があります
ログファイルは、システムのリソースにオーバーヘッドを追加します
ログファイルの目的は、システム管理者を支援することです
取引の履歴の目的は、監査人を支援することです

上記を次の表にまとめます。

ログタイプ	アプリ/システム	オーディットトレイルフレンドリー
アプリログ	アプリ	はい
アプリサーバーログ	システム	いいえ
データベースログ	システム	いいえ

アプリログは、監査証跡として使用するように簡単に調整できます。次の理由により、システムログはそれほど簡単ではありません：

システムソフトウェアによって形式が制限されています
システム全体でグローバルに機能します
特定のビジネスコンテキストに関する直接的な知識はありません
通常、使用可能な監査に適した監査証跡を作成するために、後でオフラインで解析/処理するための追加のソフトウェアが必要です。

ただし、一方で、アプリログは実際のデータの上に追加のソフトウェアレイヤーを配置します。したがって、次のようになります。

監査システムをアプリケーションのバグ/設定ミスに対してより脆弱にする
特権ユーザーやDBAなど、誰かがアプリのログシステムをバイパスしてデータベース上のデータに直接アクセスしようとすると、ログプロセスに潜在的な穴が作成されます
多くのアプリケーションまたは多くのソフトウェアチームがある場合に備えて、監査システムをより複雑にし、管理と保守を困難にします。

したがって、理想的には、2つの最良のものを探します。データベース層を含むシステム全体で最大のカバレッジを備えた使用可能な監査証跡を持ち、1つの場所で構成できるため、ロギング自体を他の方法で簡単に監査できます（システム）ログ。

PostgreSQLを使用した監査ログ

監査ロギングに関してPostgreSQLにあるオプションは次のとおりです。

徹底的なロギングを使用する（log_statement =all）
カスタムトリガーソリューションを作成する
コミュニティが提供する標準のPostgreSQLツール（
- audit-trigger 91plus（https://github.com/2ndQuadrant/audit-trigger）
- pgaudit拡張機能（https://github.com/pgaudit/pgaudit）

少なくともOLTPまたはOLAPワークロードでの標準的な使用法では、次の理由で徹底的なロギングを回避する必要があります。

巨大なファイルを生成し、負荷を増やします
アクセスまたは変更されているテーブルに関する内部知識がなく、不可解な連結ステートメントを含むDOブロックである可能性のあるステートメントを出力するだけです
（監査証跡を作成するために）オフラインでの解析と処理のための追加のソフトウェア/リソースが必要です。これらは、信頼できると見なされるために、監査の範囲に含まれている必要があります。

この記事の残りの部分では、コミュニティが提供するツールを試してみます。監査したい次の単純なテーブルがあるとします。

myshop=# \d orders
                                       Table "public.orders"
   Column   |           Type           | Collation | Nullable |              Default               
------------+--------------------------+-----------+----------+------------------------------------
 id         | integer                  |           | not null | nextval('orders_id_seq'::regclass)
 customerid | integer                  |           | not null |
 customer   | text                     |           | not null |
 xtime      | timestamp with time zone   |           | not null | now()
 productid  | integer                  |           | not null |
 product    | text                     |           | not null |
 quantity   | integer                  |           | not null |
 unit_price | double precision         |           | not null |
 cur        | character varying(20)    |           | not null | 'EUR'::character varying
Indexes:
    "orders_pkey" PRIMARY KEY, btree (id)

audit-trigger 91plus

トリガーの使用に関するドキュメントは、https：//wiki.postgresql.org/wiki/Audit_trigger_91plusにあります。まず、提供されているDDL（関数、スキーマ）をダウンロードしてインストールします。

$ wget https://raw.githubusercontent.com/2ndQuadrant/audit-trigger/master/audit.sql
$ psql myshop
psql (10.3 (Debian 10.3-1.pgdg80+1))
Type "help" for help.
myshop=# \i audit.sql

次に、テーブルの注文のトリガーを定義します。基本的な使用法の使用：

myshop=# SELECT audit.audit_table('orders');

これにより、テーブルオーダーに2つのトリガーが作成されます。insert_update_delere行トリガーとtruncateステートメントトリガーです。次に、トリガーの機能を見てみましょう。

myshop=# insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);      
INSERT 0 1
myshop=# update orders set quantity=3 where id=2;
UPDATE 1
myshop=# delete from orders  where id=2;
DELETE 1
myshop=# select table_name, action, session_user_name, action_tstamp_clk, row_data, changed_fields from audit.logged_actions;
-[ RECORD 1 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name        | orders
action            | I
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:15:10.887268+03
row_data          | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"2", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields    |
-[ RECORD 2 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name        | orders
action            | U
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:16:12.829065+03
row_data          | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"2", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields    | "quantity"=>"3"
-[ RECORD 3 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name        | orders
action            | D
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:16:24.944117+03
row_data          | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"3", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields    |

Update（RECORD 2）のchanged_fields値に注意してください。列を除外したり、ドキュメントに示されているようにWHEN句を使用したりするなど、監査トリガーのより高度な使用法があります。監査トリガーは、audit.logged_actionsテーブル内に有用な監査証跡を作成する役割を果たしているようです。ただし、いくつかの注意点があります：

SELECTがない（SELECTでトリガーが起動しない）またはDDLが追跡されない
テーブルの所有者とスーパーユーザーによる変更は簡単に改ざんされる可能性があります
アプリのユーザー、アプリのスキーマとテーブルの所有者に関しては、ベストプラクティスに従う必要があります

今日のホワイトペーパーをダウンロードするClusterControlを使用したPostgreSQLの管理と自動化PostgreSQLの導入、監視、管理、スケーリングを行うために知っておくべきことについて学ぶホワイトペーパーをダウンロードする

Pgaudit

Pgauditは、監査に関する限り、PostgreSQLに追加された最新の製品です。プロジェクトのgithubページ（https://github.com/pgaudit/pgaudit）に示されているように、Pgauditは拡張機能としてインストールする必要があります。 Pgauditは標準のPostgreSQLログに記録します。 Pgauditは、モジュールのロード時に自身を登録し、executorStart、executorCheckPerms、processUtility、およびobject_accessのフックを提供することで機能します。したがって、pgauditは（前の段落で説明したaudit-triggerなどのトリガーベースのソリューションとは対照的に）READ（SELECT、COPY）をサポートします。通常、pgauditでは、2つの操作モードを使用することも、それらを組み合わせて使用することもできます。

SESSION監査ログ
OBJECT監査ログ

セッション監査ログは、クラスを介してほとんどのDML、DDL、特権、およびその他のコマンドをサポートします。

読む（選択、コピー元）
書き込み（挿入、更新、削除、切り捨て、コピー先）
FUNCTION（関数呼び出しとDOブロック）
役割（役割の付与、取り消し、作成/変更/削除）
DDL（ROLEのものを除くすべてのDDL）
MISC（破棄、フェッチ、チェックポイント、バキューム）

メタクラス「all」には、すべてのクラスが含まれます。 -クラスを除外します。たとえば、postgresql.confの次のGUCパラメータを使用して、MISCを除くすべてのセッション監査ログを構成しましょう。

pgaudit.log_catalog = off
pgaudit.log = 'all, -misc'
pgaudit.log_relation = 'on'
pgaudit.log_parameter = 'on'

次のコマンドを実行する（トリガーの例と同じ）

myshop=# insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);
INSERT 0 1
myshop=# update orders set quantity=3 where id=2;
UPDATE 1
myshop=# delete from orders  where id=2;
DELETE 1
myshop=#

PostgreSQLログに次のエントリがあります：

% tail -f data/log/postgresql-22.log | grep AUDIT:
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:37.352 EEST psql [email protected] line:7 LOG:  AUDIT: SESSION,5,1,WRITE,INSERT,TABLE,public.orders,"insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);",<none>
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:50.120 EEST psql [email protected] line:8 LOG:  AUDIT: SESSION,6,1,WRITE,UPDATE,TABLE,public.orders,update orders set quantity=3 where id=2;,<none>
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:59.888 EEST psql [email protected] line:9 LOG:  AUDIT: SESSION,7,1,WRITE,DELETE,TABLE,public.orders,delete from orders  where id=2;,<none>

AUDIT：の後のテキストは完全な監査証跡を構成し、スプレッドシート対応のcsv形式で監査人に出荷する準備がほぼ整っていることに注意してください。セッション監査ログを使用すると、 allのpgaudit.logパラメーターで定義されたクラスに属するすべての操作の監査ログエントリが得られます。テーブル。ただし、データのごく一部、つまり監査対象のテーブルが少ない場合があります。このような場合、PostgreSQLの特権システムを介して、選択したテーブル/列にきめ細かい基準を提供するオブジェクト監査ログを使用することをお勧めします。オブジェクト監査ログの使用を開始するには、最初にpgauditが使用するマスターロールを定義するpgaudit.roleパラメーターを構成する必要があります。このユーザーにログイン権限を与えないのは理にかなっています。

CREATE ROLE auditor;
ALTER ROLE auditor WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN NOREPLICATION NOBYPASSRLS CONNECTION LIMIT 0;

postgresql.confのpgaudit.roleにこの値を指定します：

pgaudit.log = none # no need for extensive SESSION logging
pgaudit.role = auditor

Pgaudit OBJECTロギングは、ユーザーが auditorかどうかを検出することで機能します。ステートメントで使用されるリレーション/列に対して実行される指定されたアクションを実行する権利が（直接または継承されて）付与されます。したがって、すべてのテーブルを無視する必要があるが、テーブルの順序への詳細なログ記録がある場合は、これがその方法です。

grant ALL on orders to auditor ;

上記の許可により、テーブルオーダーでの完全なSELECT、INSERT、UPDATE、およびDELETEロギングが有効になります。前の例のINSERT、UPDATE、DELETEをもう一度与えて、postgresqlログを見てみましょう：

% tail -f data/log/postgresql-22.log | grep AUDIT:
[local] [60683] 5b040125.ed0b 2018-05-22 14:41:41.989 EEST psql [email protected] line:7 LOG:  AUDIT: OBJECT,2,1,WRITE,INSERT,TABLE,public.orders,"insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);",<none>
[local] [60683] 5b040125.ed0b 2018-05-22 14:41:52.269 EEST psql [email protected] line:8 LOG:  AUDIT: OBJECT,3,1,WRITE,UPDATE,TABLE,public.orders,update orders set quantity=3 where id=2;,<none>
[local] [60683] 5b040125.ed0b 2018-05-22 14:42:03.148 EEST psql [email protected] line:9 LOG:  AUDIT: OBJECT,4,1,WRITE,DELETE,TABLE,public.orders,delete from orders  where id=2;,<none>

出力は上記のSESSIONロギングと同じですが、監査タイプとしてSESSION（AUDIT：の横の文字列）の代わりにOBJECTを取得する点が異なります。

OBJECTロギングに関する1つの注意点は、TRUNCATEがログに記録されないことです。これには、SESSIONロギングに頼る必要があります。ただし、この場合、すべてのテーブルに対してすべてのWRITEアクティビティを取得することになります。各コマンドを別々のクラスにするために関係するハッカーの間で話し合いがあります。

継承の場合、親ではなく子テーブルの監査人へのアクセスを許可すると、子テーブルの行のアクションに変換される親テーブルのアクションはログに記録されないことに注意してください。

上記に加えて、ログの整合性を担当するIT担当者は、PostgreSQLログファイルからの監査証跡の抽出をカバーする、厳密で明確に定義された手順を文書化する必要があります。これらのログは、干渉や改ざんの可能性を最小限に抑えるために、外部の安全なsyslogサーバーにストリーミングされる場合があります。

概要

このブログが、PostgreSQLでの監査ログのベストプラクティスと、IT監査の準備において監査証跡を作成することが非常に重要である理由をよりよく理解するのに役立つことを願っています。監査証跡は、監査を円滑に進めるのに役立つ一連のクリーンで使用可能な情報を提供します。

ClusterControlは、選択したシステムに関係なく、データベースのセキュリティ、可用性、およびパフォーマンスを確保しながら、ほとんどのデータベース関連タスクを自動化および管理するのに役立ちます。 ClusterControlの無料トライアルを今すぐダウンロードして、ツールとツールが実行する操作からビジネスがどのように利益を得ることができるかを確認してください。まだ行っていない場合は、TwitterとLinkedInでフォローし、フィードを購読してください。次のブログでお会いしましょう。