sql >> データベース >  >> RDS >> PostgreSQL

pgAuditを使用したPostgreSQLの監査

    情報技術(IT)での監査は、組織のITインフラストラクチャを調査して、承認された標準または確立されたポリシーによって課せられた要件に準拠していることを確認するプロセスです。新しいGDPR規制などのデータ保護ルールは、ユーザーデータを保護するためにますます厳しくなっています。そのため、アプリケーションとユーザーデータの両方が脆弱性から保護されていることを確認するために、データベース監査を適切に設定することが重要です。このブログ投稿では、PostgreSQLの監査を容易にするために必要な監査ログを生成するツールであるpgAuditについて説明します。

    pgAuditとは何ですか?

    PostgreSQL監査拡張機能pgAuditは、PostgreSQLデータベースのイベントを詳細な監査ログに記録するオープンソース拡張機能です。ネイティブのPostgreSQLログ機能を使用するため、監査ログはPostgreSQLログの一部になります。この拡張機能は、Simon Riggs、Abhijit Menon-Sen、およびIanBarwickによって作成された2ndQuadrantpgAuditプロジェクトに基づいており、CrunchyDataのDavidSteeleによる拡張機能が含まれています。

    なぜpgAudit over log_statement =all?

    log_statement=allを設定するだけで、PostgreSQLのすべてのステートメントをログに記録できます。 。では、なぜpgAuditを使用するのでしょうか。基本的なステートメントロギング(log_statementを使用) )は、データベースに対して実行された操作のみを一覧表示します。操作をフィルタリングする機能は提供されず、ログは監査に必要な適切な形式になりません。 pgAuditはさらに、READなどの特定のクラスのステートメントをログに記録するための粒度を提供します。 (SELECT およびCOPY )、WRITEINSERTUPDATEDELETE など)、DDL さらに、特定の関係に対する操作のみがログに記録されるオブジェクトレベルの監査を提供します。

    基本的なステートメントログに対するpgAuditのもう1つの利点は、要求された操作をログに記録するだけでなく、実行された操作の詳細を提供することです。たとえば、DOステートメントを使用して匿名コードブロックを実行することを検討してください。

    DO $$
    BEGIN
    	EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
    END $$;
    

    基本的なステートメントのログは次のようになります:

    2020-12-20 23:40:11 UTC:157.230.232.139(53064):sgpostgres@test:[9091]: LOG:  statement: DO $$
            BEGIN
                EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
            END $$;
    

    pgAuditは、次と同じ操作をログに記録します:

    2020-12-20 23:40:11 UTC:157.230.232.139(53064):sgpostgres@test:[9091]: LOG:  AUDIT: SESSION,4,1,FUNCTION,DO,,,"DO $$
            BEGIN
                EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
            END $$;",<not logged>
    2020-12-20 23:40:11 UTC:157.230.232.139(53064):sgpostgres@test:[9091]: LOG:  AUDIT: SESSION,4,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT),<not logged>
    

    上記は、操作とその内部をログに記録するpgAudit機能を、検索を容易にする構造化された出力で明確に示しています。

    pgAuditClickを使用してPostgreSQLを監査する方法

    pgAuditをインストールするにはどうすればよいですか?

    pgAuditは、PostgreSQLリポジトリからダウンロードできる拡張機能です。または、ソースからコンパイルしてビルドすることもできます。最初のステップとして、パッケージをダウンロードしてPostgreSQLを実行しているマシンにインストールする必要があります(この拡張パッケージは、すべてのScaleGrid PostgreSQLデプロイメントにプレインストールされています)。

    インストールしたら、PostgreSQLにロードする必要があります。これは、pgauditを追加することで実現されます shared_preload_librariesに 構成パラメーター。この構成変更を有効にするには、PostgreSQLを再起動する必要があります。次のステップは、CREATE EXTENSION pgauditを実行して、データベースで拡張機能を有効にすることです。 。

    拡張機能の準備ができたので、ログ記録を開始するために拡張機能の構成パラメーターを設定する必要があります。これは、パラメータpgaudit.logを設定するのと同じくらい簡単です。 allを評価する pgAuditはsessionへのログインを開始します モード。

    pgAuditをインストールして有効にする方法がわかったので、pgAuditが提供する2つの監査ログモードであるセッションとオブジェクトについて説明しましょう。

    セッション監査ログ

    セッションモードでは、pgAuditはユーザーが実行したすべての操作をログに記録します。 pgaudit.logの設定 NONE以外の定義された値のパラメータ 、セッション監査ログを有効にします。 pgaudit.log パラメータは、セッションモードでログに記録されるステートメントのクラスを指定します。可能な値は次のとおりです。READWRITEFUNCTIONROLEDDLMISCMISC_SETALL およびNONE

    pgaudit.logの設定 ALLへのパラメータ すべてのステートメントをログに記録します。パラメーターは、コンマ区切りのリストを使用して複数のクラスを受け入れることができ、特定のクラスは–記号で除外できます。たとえば、MISCを除くすべてのステートメントをログに記録する場合 クラス、pgaudit.logの値 ALL, -MISC, -MISC_SETになります 。 pgaudit.log_relationを設定することにより、pgAuditがステートメント内のリレーション参照ごとに個別のログエントリを作成できるようにすることもできます。 オンにします。

    テーブルの作成例を考えてみましょう。 SQLステートメントは次のようになります。

    CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));
    

    対応する監査ログエントリは次のとおりです。

    2020-12-21 00:00:11 UTC:157.230.232.139(53178):sgpostgres@test:[11514]: LOG:  AUDIT: SESSION,5,1,DDL,CREATE SEQUENCE,SEQUENCE,public.persons_id_seq,"CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));",<not logged>
    2020-12-21 00:00:11 UTC:157.230.232.139(53178):sgpostgres@test:[11514]: LOG:  AUDIT: SESSION,5,1,DDL,CREATE TABLE,TABLE,public.persons,"CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));",<not logged>
    2020-12-21 00:00:11 UTC:157.230.232.139(53178):sgpostgres@test:[11514]: LOG:  AUDIT: SESSION,5,1,DDL,CREATE INDEX,INDEX,public.persons_pkey,"CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));",<not logged>
    2020-12-21 00:00:11 UTC:157.230.232.139(53178):sgpostgres@test:[11514]: LOG:  AUDIT: SESSION,5,1,DDL,ALTER SEQUENCE,SEQUENCE,public.persons_id_seq,"CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));",<not logged>
    

    オブジェクト監査ログ

    特定のケースでは、特定の関係のセットのみを監査する必要がある場合があります。このような場合、セッションモードを使用すると、必要な関係に対応しない監査ログが不必要に大量に発生するだけです。オブジェクトモードはこの目的に特に適しており、特定の関係のセットのみを監査できます。

    オブジェクト監査ログは、PostgreSQLの役割を使用して実行されます。役割を作成して、特定の関係のセットにのみアクセスするためのアクセス許可を割り当てることができます。この役割は、構成パラメーターpgaudit.roleで指定する必要があります 。オブジェクトモードはSELECTのみをサポートします 、INSERTUPDATE およびDELETE ステートメント。ログに記録されるステートメントのクラスは、ロールに付与された権限によって異なります。たとえば、ロールにSELECTのみを実行する権限がある場合 、次にSELECTのみ ステートメントはログに記録されます。

    以下は、オブジェクト監査ログの例です:

    ロールを作成し、SELECTのみを付与します 権限。 pgaudit.roleを設定します その役割に移動し、SELECTを実行します SQLステートメント:

    CREATE ROLE audit_person;
    GRANT SELECT ON persons TO audit_person;
    SET pgaudit.role = 'audit_person';
    SELECT * FROM persons WHERE ID=404;
    

    上記のselectステートメントは次のようにログに記録されます:

    2020-12-21 00:27:09 UTC:157.230.232.139(54900):sgpostgres@test:[21835]: LOG:  AUDIT: OBJECT,10,1,READ,SELECT,TABLE,public.persons,select * from persons where ID=404;,<not logged>
    
    の人から*を選択します

    フルマネージドPostgreSQLソリューションに興味がありますか?

    ScaleGridなどのDBaaSプロバイダーがPostgreSQLデータベースの管理にどのように役立つかについて詳しくは、PostgreSQLページをご覧ください。 ScaleGridを使用すると、データベースの管理ではなく、製品の開発に集中できるようになります。

    監査ログエントリを解釈する方法

    これまで、監査ログエントリの外観について詳しく説明してきました。次に、監査ログエントリの形式を見てみましょう。各エントリは、PostgreSQLロギングについて説明したlog_line_prefixで始まり、残りの出力はCSV形式になります。次の簡単な監査ログエントリについて考えてみます。

    2020-12-21 00:27:09 UTC:157.230.232.139(54900):sgpostgres@test:[21835]: LOG:  AUDIT: OBJECT,10,1,READ,SELECT,TABLE,public.persons,select * from persons where ID=404;,<not logged>
    
    の人から*を選択します

    上記のエントリの値

    2020-12-21 00:27:09 UTC:157.230.232.139(54900):sgpostgres@test:[21835]: 

    log_line_prefix形式からのものです%t:%r:%u@%d:[%p]: 。監査エントリの内容は、LOG: AUDIT: から始まります。 値であり、CSV形式に従います。値の形式は次の形式です:

    AUDIT_TYPE,STATEMENT_ID,SUBSTATEMENT_ID,CLASS,COMMAND,OBJECT_TYPE,OBJECT_NAME,STATEMENT,PARAMETER

    各フィールドを1つずつ見ていきましょう:

    になります。
    フィールド 説明 監査エントリの例からの値
    AUDIT_TYPE 監査モードを示します:SESSIONまたはOBJECT オブジェクト
    STATEMENT_ID 各セッションの一意のステートメント識別子 10
    SUBSTATEMENT_ID メインステートメント内の各サブステートメントの識別子 1
    クラス pgaudit.logパラメーターの定義値であるREAD、WRITEなどのステートメントのクラスを示します。 読む
    コマンド SQLステートメントで使用されるコマンド SELECT
    OBJECT_TYPE TABLE、INDEX、VIEWなどにすることができます。 テーブル
    OBJECT_NAME 完全修飾オブジェクト名 public.persons
    ステートメント 実際に実行されたステートメント ID=404の人から*を選択;
    PARAMETER pgaudit.log_parameterがtrueに設定されている場合、引用符で囲まれたパラメーターのCSVがリストされます(存在する場合)。パラメーターがない場合は「none」です。 pgaudit.log_parameterが設定されていない場合、値は「<ログに記録されません>」<ログに記録されていません>

    推論

    pgAuditは、そのすべての機能を備えており、監査証跡ログを生成することにより、監査プロセスを簡素化します。名前が変更されたオブジェクトを同じ名前でログに記録するなど、いくつかの注意点がありますが、それでも必要な機能を提供する堅牢なツールです。ただし、ログに書き込まれる監査情報は、監査プロセスにとって理想的ではない場合があります。これらのログをデータベーススキーマに変換でき、監査データをデータベースにロードできるため、監査プロセスはさらに優れているため、簡単にクエリを実行できます。情報。ここで、PostgreSQL監査ログアナライザー(pgAudit Analyze)が役立ちます。詳細については、pgAuditおよびpgAuditAnalyzeのgithubページを参照してください。


    1. Oracleの日付にAD/BCインジケーターを追加する方法

    2. SQLitePRIMARYキーの自動インクリメントが機能しない

    3. SQL Server Management Studioで複合キーを作成するにはどうすればよいですか?

    4. ClusterControl CMON HA for Distributed Database High Availability-パート2(GUIアクセスセットアップ)