Amazon Web Services ブログ

第1部： Database Activity Streams と pgAudit を使った Aurora PostgreSQL データベースの監査

昨今のデータの急増に伴い、データの保存、共有、保護、利用の必要性は、より困難で複雑になってきています。

多くの企業組織は、データベースの規制やコンプライアンス要件に準拠することを義務付けられており、最重要課題となっています。また、監査上の観点から関連するデータを保存することも重要な要件です。

この記事では、Amazon Aurora PostgreSQL-Compatible Edition データベースを監査する2つの方法、Database Activity Streams 機能と pgAudit 拡張機能について説明します。それぞれの方法について、利点、制限、その他の考慮事項を確認します。この記事の第2部では、それぞれのオプションを使用してデータベース監査ソリューションを実装するための手順について説明します。

データベース監査の概要

ここ数年、企業が遵守を求められる規制の数と複雑さは著しく増加しています。業界特有のコンプライアンスには、GDPR、SOX、PCI DSS、HIPAA などがあります。また、情報漏えいに伴う賠償金の金額も増加しており、監査の重要性はこれまで以上に高まっています。

IT 部門は、ニアリアルタイムのビジネス・インテリジェンス・レポートを確実に受けとれるようにして、ビジネス関係者を支援することが重要です。これは、レポートを自動化するシステムを導入し、細心の注意を必要とする重要なイベントが発生したときにアラートされるように設定することを意味します。

ほとんどの場合、データベース監査を推進するのはコンプライアンスです。組織では、ユーザーアクセス、セキュリティアクセス、およびその他の監査可能なデータを監査することがあります。以下の機能を実現するための仕組みやシステムが必要です：

  • ニアリアルタイムのデータを保存
  • データベースの活動を監視し、監査
  • データの分析
  • 疑わしいデータベース活動のアラート発報と関係者への通知
  • Imperva の SecureSphere Database Audit and Protection、McAfee の Data Center Security Suite、IBM の Infosphere Guardium などのサードパーティ製コンプライアンスアプリケーションと統合

このようなコンプライアンス要件を達成するには、データベースの外部にあるサービスやスクリプトを使用するか、特定のデータベースネイティブなメカニズムを使用する方法があります。これらのアプローチには、どちらも長所と短所があります。この記事では、ログを使用する Aurora の機能である Database Activity Streams と、エンジン拡張である pgAudit の使用を比較します。

データベース監査を行う場合、以下を考慮する必要があります：

  • 監査を有効にすることによるパフォーマンスのオーバーヘッド
  • ログの粒度に応じて、監査ログを保存するためのストレージ要件
  • 事後のログ改ざんを防止する
  • コストがかかる場合は、その影響
  • インストール、メンテナンス、およびモニタリングの容易さ

Database Activity Streams による監査

Database Activity Streams 機能は、リレーショナルデータベース内のアクティビティのニアリアルタイムのストリームを提供します。 データベースアクティビティ ストリームを監視ツールと統合すると、データベースアクティビティを監視および監査できます。

このソリューションには次の利点があります。

  • ニアリアルタイムのストリームを提供する
  • ネイティブの AWS サービスおよびサードパーティの監視ツールと統合
  • データベースアクティビティを詳細にキャプチャする
  • DBA とセキュリティ担当者の職務を分離する
  • AWS Key Management Service (AWS KMS) カスタマーマネージドキーを使用して、保存時の監査データを暗号化する
  • 監査データを統一された JSON 形式で提供する

2つの監査モードを選択することができます：

  • 非同期 – 非同期モードでは、アクティビティストリームイベントは、データベースがイベントを生成している間、バックグラウンドで持続的に行われ、セッションはすぐに通常のアクティビティに復帰します。非同期モードでは、アクティビティストリームの記録よりもデータベースのパフォーマンスが優先されます。つまり、作業負荷が高い場合、非同期モードではアクティビティストリームのいくつかのレコードのキャプチャをスキップし、ストリームよりもデータベースのパフォーマンスを優先する可能性があります。そのため、記録されたストリームの整合性を保つために、いくつかのトランザクションが失われる可能性があります。
  • 同期 – 同期モードの場合、アクティビティストリームにレコードがキャプチャされるまで、つまりイベントが永続化されるまで、データベースセッションは他のすべてのアクティビティをブロックします。これは、アクティビティストリームにレコードを取り込むことが、パフォーマンスよりも優先される場合に有効です。

どちらのモードでも、データベースのパフォーマンスと耐久性の間にはトレードオフがあります。したがって、データベースのパフォーマンスへの影響に関係なく、アクティビティストリーム内のすべてのレコードをキャプチャする必要がある場合は、同期モードが推奨されます。

考慮すべき点と制限

Database Activity Streams を使用した監査を選択する場合は、パフォーマンスへの影響とコストを考慮してください。 サービスの有効化には追加料金はかかりません。 ただし、ストリームは Amazon Simple Storage Service (Amazon S3) またはその他のストレージソリューションに保存する必要があり、コストがかかります。 レコードを JSON から Apache Parquet または Apache ORC 形式に変換するオプションもあります。通常、JSON よりもクエリの効率が高くなりますが、形式変換コストが発生します。詳細については、こちらをご覧ください。

さらに、データベースクラスターに複数のユーザーデータベースがある場合、ストリームをアクティブ化すると、クラスター内のすべてのデータベースのアクティビティがキャプチャされます。 ユーザーが特定のデータベースのアクティビティをキャプチャしたい場合は、AWS Lambda を使用してキャプチャされたストリームにフィルターを追加できます。

pgAudit を使用した監査

PostgreSQL Audit Extension (pgaudit) は、PostgreSQL の標準的なロギング機能を通して、詳細なセッションとオブジェクトの監査ロギングを提供します。

基本的なステートメントロギングは、log_statement = all、mod、ddl のいずれかで標準のロギング機能によって提供されます。 さらに、log_connections と log_disconnections を使用して、それぞれユーザ接続と切断の詳細をロギングすることができます。

これは、監視のユースケースとしては許容範囲ですが、一般的に監査に必要とされる詳細なレベルを提供するものではありません。データベースに対して実行されたすべての操作のリストを取得するだけでは十分ではありません。監査人は、関心のある特定のステートメントを見つける必要があります。標準のログ機能は、ユーザが何を要求したかを示しますが、pgAudit はデータベースがリクエストに応じている間に何が起こったかの詳細に焦点を当てます。

pgAudit では、インスタンスレベル、ユーザレベル、またはデータベースレベルで監査を設定することができます：

  • インスタンスレベルで監査を設定するには、DB パラメータグループの pgaudit.log パラメータの値を変更します
  • データベース・レベルで監査を設定するには、ALTER DATABASE dbname set pgaudit.log='All'; を使用します
  • ユーザーレベルで監査を設定するには、ALTER ROLE username set pgaudit.log='ROLE,WRITE,DDL,FUNCTION'; を使用します

pgaudit で利用可能なフォーマットは以下の通りです：

  • AUDIT_TYPE – SESSION または OBJECT です。
  • STATEMENT_ID – このセッションの一意のステートメントID。各ステートメントIDは、バックエンドの呼び出しを表します。ステートメントIDは、一部のステートメントがログに記録されない場合でも、連続したものです。複数の関係が記録されている場合、1つのステートメントIDに複数のエントリが存在することがあります。
  • CLASS – 例えば、READ や ROLEなど。
  • COMMAND – 例えば、ALTER TABLE や SELECT など。
  • OBJECT_TYPE – TABLE、INDEX、VIEW など。SELECT、DML、およびほとんどの DDL ステートメントで使用可能です。
  • OBJECT_NAME – 完全修飾オブジェクト名（例：public.account）。SELECT、DML、およびほとんどの DDL ステートメントで使用可能です。
  • STATEMENT – バックエンドで実行されるステートメント。
  • PARAMETER – pgaudit.log_parameter が設定されている場合、このフィールドにはステートメントのパラメータが引用符で囲まれた CSV として含まれます。パラメータがない場合は何も含まれません。 それ以外の場合、フィールドはログに記録されません。

セッション監査ログによってステートメントのどのクラスが記録されるかを指定します。 可能な値は次のとおりです。

  • READ – ソースがリレーションまたはクエリの場合の SELECT および COPY
  • WRITE – 宛先がリレーションの場合の INSERT、UPDATE、DELETE、TRUNCATE、および COPY
  • FUNCTION – 関数呼び出しと DO ブロック
  • ROLE – ロールと権限に関連するステートメント: GRANT、REVOKE、CREATE/ALTER/DROP ROLE
  • DDL – ROLE クラスに含まれないすべての DDL
  • MISC – DISCARD、FETCH、CHECKPOINT、VACUUM、SET などのその他のコマンド
  • MISC_SET – その他の SET コマンド (SET ROLE など)
  • ALL – 上記のすべてを含めます

考察事項と制限

pgAudit を選択する場合、パフォーマンスへの影響とコストを考慮し、AUTOVACUUM と AUTOANALYZE がログに記録されないことに留意してください。さらに、トランザクションがキャンセル状態になった後に実行されるステートメントは、監査ログに記録されません。しかし、エラーの原因となったステートメントと、キャンセルされたトランザクションで実行された後続のステートメントは、標準のロギング機能によってエラーとしてログに記録されます。

トラブルシューティングやパフォーマンスチューニングのために、追加のデータベースアクティビティ情報をログに取り込む必要がある場合、ネイティブデータベースロギングを使用することができます。詳細については、Working with RDS and Aurora PostgreSQL logs: Part 1 と Part 2 を確認してください。

まとめ

この投稿では、コンプライアンスの観点からデータベース監査の必要性について説明しました。 AWS 上のデータベースで利用できる 2つの監査オプション、Aurora のデータベースアクティビティストリーム機能と pgAudit 拡張機能を紹介しました。

第2部では、2つの使用例と、データベース アクティビティ ストリームまたは pgAudit を使用してデータベース監査ソリューションを実装する方法について説明します。

この投稿についてコメントや質問がある場合は、コメント欄で共有してください。

著者について

HariKrishna Boorgadda は、Amazon Web Services のプロフェッショナルサービスチームのシニアコンサルタントです。AWS へのデータベース移行を中心に、Amazon RDS および Aurora アーキテクチャの設計と実装を顧客と仕事で行う。

Swanand Kshirsagar は、アマゾン ウェブ サービスのプロフェッショナル サービス チームの主任コンサルタントです。 彼は顧客と協力して、AWS クラウドでスケーラブルで可用性の高い安全なソリューションを構築しています。 彼の重点分野は、オンプレミス データベースの AWS RDS および Aurora PostgreSQL への同種および異種の移行です。

Rajesh Madiwale は、アマゾン ウェブ サービスの主任コンサルタントです。 彼は、Amazon RDS for PostgreSQL、Aurora PostgreSQL、Redshift、MySQL、Greenplum データベースのデータベース開発と管理に関する深い専門知識を持っています。 彼は PostgreSQL コミュニティの熱心なメンバーであり、在職中ずっと PostgreSQL に取り組んできました。 彼は PostgreSQL カンファレンスでもいくつかのセッションを行っています。

翻訳はソリューションアーキテクトの程が担当しました。原文はこちらです。