PostgreSQLの監査ログ ～セキュリティ対策は万全! 監査ログで情報漏えいを検知～ －富士通の技術者に聞く！PostgreSQLの技術－
PostgreSQLインサイド

近年、ICTの急速な普及に伴い、サイバー攻撃や情報漏えいに対する企業や社会でのセキュリティ対策がますます急務になっています。特に、個人情報や機密情報を管理するデータベースにおいては、セキュリティ対策は必須条件である。セキュリティの国際評価基準（ISO15408）では、データベースのセキュリティ脅威として、「不正な接続（なりすまし）」、「不正なアクセス」、「情報漏えい」を定義しています。
FUJITSU Software Enterprise Postgres（以降、Enterprise Postgresと略します）では、これらを予防 / 阻止するための機能はすでに実装されていたが、検知するための機能が十分ではありませんでした。これを実現するのが「監査ログ機能」です。監査ログ機能を実装することで、セキュリティが強化されたデータベースシステムの提供を目指しました。頑強なセキュリティを実現する監査ログ機能とはどのようなものなのか？その真相に迫ります。

データベースのセキュリティ対策に必要とされる“監査ログ”とはどのようなものでしょう？

二宮
データベースの監査ログは、データベースに対するアクセスや操作の記録です。具体的には、データベースに対する、「いつ」、「誰が」、「どこから」、「何に対して」、「どんな処理を」、「実行結果は」の情報です。これらの情報から、たとえば「接続元xxxから不正接続された」や「△△テーブルのデータが不正に変更された」などが検知できます。セキュリティ事故の中で最も社会的影響が大きいといわれる情報漏えいは、「なりすまし」、「不正アクセス」などを要因として起こります。もし、情報漏えいが発生したとしても、データベースに対するアクセス記録の情報が残っていれば、その原因や影響範囲などを特定でき、被害を最小限に食い止めることができます。また、その情報を定期的に監視することで、セキュリティ被害を未然に防ぐことも可能です。この情報が監査ログなのです。

データベースのセキュリティ対策に必要不可欠なログということですね。PostgreSQLには、監査ログを出力する機能があるのでしょうか？

二宮
PostgreSQLでは、postgresql.confのパラメーターでログの出力を制御しています。監査ログに相当するのは、log_statementパラメーターです。log_statementパラメーターを使用することで、実行したSQLをログとして出力できます。ただし、このログは、サーバーログとして出力されるので、ログの出力量が膨大となり、データベース自身の性能に影響を及ぼしかねません。また、サーバーログには、メッセージや運用操作ログが出力されています。サーバーログを参照できるユーザーなら監査ログも容易に参照できてしまいます。さらに、監査のために必要な「接続に関する情報」や、SQLでオブジェクトを特定するための「スキーマ名」といった情報が出力されないといった問題もあります。このため当社では、PostgreSQLのログ出力にセキュリティや運用面での課題があると考えていました。

その課題をEnterprise Postgresで改善したということですね？

二宮
そうです。Enterprise Postgresでは、データベース監査を行うためのログ出力を強化した監査ログ機能を実装しました。

Enterprise Postgresでは監査ログの強化をどのように実現しているのでしょうか？

二宮
Enterprise Postgresでは、PostgreSQLの監査ログ取得拡張モジュールであるpgauditに対して、コネクションに関する情報やエラーメッセージといったSQL文の実行結果情報を取得できるように機能強化された「pgaudit refactored版」を採用しています。これにより「誰が」何をして「どうなったか」を紐付けることが可能になり、不正アクセスや改ざんが検知し易くなりました。pgauditでは、「SELECTが発行された」という情報だけですが、pgaudit refactored版の採用で、「xxxxという不正な接続元からSELECTが発行された。SELECTが成功していたので情報が流出した可能性がある」といったところまで分析できるのです。

なるほど。その他に監査ログの機能を強化したポイントはありますか？

二宮
Enterprise Postgresで最も強化したポイントは、専用のログファイルに監査ログだけを出力できるようにしたことです。サーバーログでは、監査ログだけでなく、その他のいろいろなメッセージや操作ログが混在した状態で出力されるので、ログの見落としや監査が行い難いという問題がありました。監査ログを専用ログファイルに出力することで、監査ログだけを扱えるようになり、監査が行い易くなります。
運用の面では、監査ログとサーバーログが別ファイルなので、監査ログは毎日ローテーション、サーバーログは週に1回ローテーションというように、それぞれのローテーションでログ運用ができるといったメリットもあります。監査ログは一定期間保持しておくことが望ましいとされています。監査ログを1日ごとに新しい専用ログファイルに出力させ、古いファイルをアクセス制限のある別サーバーなどに保存するなどの運用が考えられます。また、専用ログファイルに対するアクセス権を設定することで、参照できるユーザーを限定することができます。具体的な実装としては、postgresql.confのlog_file_modeパラメーターと同様の考え方で、監査ログ機能で使用する動作環境設定ファイルのパラメーター（log_file_modeパラメーター）で権限を設定します。デフォルトは、「0600」でデータベース管理者のみ参照可能です。「0000」を設定すると、データベース管理者も参照不可になります。

専用ログファイルとすることで、いろいろなメリットがあるわけですね。専用ログファイルへの出力は、どのように実現されているのですか？

二宮
基本的には、サーバーログへの出力と同じしくみです。専用ログファイルへの出力は、非同期出力としているため、監査ログを利用することでのアプリケーションへの性能影響は、ほとんどありません。今回の開発では、「専用ログファイルを利用することによるアプリケーションへの影響を極力なくす」というところに一番こだわりました。前述した、log_statementパラメーターにall（すべてのSQLを出力）を指定した場合、ログが大量に出力されるため、約20%性能が劣化するというデータがあります。Enterprise Postgresでは、専用ログファイルに監査ログを出力する場合と出力しない場合とで比較しても、約5%程度の性能低下に抑えられています。また、専用ログファイルが満杯で出力できないなど、専用ログファイルへの出力に失敗した場合は、サーバーログへの出力に切り替えて、ログ抜けが起きないようにしています。

アプリケーションへの性能影響がないのは、お客様にはとてもメリットがありますね。今回強化された専用ログファイルですが、お客様はどのように活用できるのでしょうか？

二宮
たとえば、PostgreSQLの拡張モジュールであるfile-fdwを利用して、アプリケーションからSQLでログを参照して監査を行ったり、また、ALog EVA（株式会社網屋様）などのログ管理ツールを利用して、GUIベースでのログ参照やレポート出力など、サーバーログを利用する場合と比べると、簡単にログの内容を確認できるようになりました。

例

それでは、監査ログがどのように出力されるのか見せていただけますか？

二宮
Enterprise Postgresの監査ログ機能には、「Session Audit Logging」と「Object Audit Logging」の2種類の出力モードがあります。「Session Audit Logging」は、ログを出力するためのルールを指定し、そのルールに合致するログだけを出力します。「Object Audit Logging」は、対象となるオブジェクトに対して権限を付与されているロールを指定し、そのロールで実行された操作のログを出力します。今回は、「Session Audit Logging」を例に説明します。
例えば、「更新系と参照系のSQLに対するログだけを出力する」というログの出力ルールを指定し、以下のSQLを実行します。

SQL実行後、以下の監査ログが出力されます。CREATE TABLE、INSERT、SELECTの3種類のSQLが実行されているのですが、INSERTとSELECTのみがルールに該当するため、この操作が監査ログとしてファイルに出力されます。CREATE TABLEは、更新系や参照系のSQLではないため、出力されていません。
また、実行したSQLで資源名がスキーマ修飾（account）されていなくても、監査ログには、アクセス資源の対象として、スキーマ修飾された資源名（myschema.account）が出力されます。それによりSQLがどのスキーマ配下の資源に対するアクセスなのか判断できます。これもサーバーログよりも監査ログが優れているメリットの1つなのです。

なるほど、ルールに従ってログ出力が制御されるわけですね。

二宮
はい、そうです。また、前述した、pgaudit refactored版として強化された、コネクション情報やSQLの実行結果を出力する例も紹介します。コネクション情報（CONNECT）やエラー情報（ERROR）を出力ルールとして指定することで、「どこから接続されたのか」や接続成功や失敗のメッセージ、また操作がエラーとなった場合のエラーメッセージを出力することができます。このようなログは、pgauditでは出力することができません。

では、出力された監査ログから情報漏えいや改ざんをどのように検知するのですか？

二宮
Enterprise Postgresの監査ログでは、SQL実行が成功した場合は、成功したSQLを含むログが出力されます。また、SQL実行が失敗した場合は、SQLSTATEとエラーメッセージが出力されるしくみになっています。このしくみと今回強化されたコネクション情報 / エラー情報から、不正なアクセスが検知できます。たとえば、以下の監査ログを取得したとします。

（2）のログから、通常では考えられない時間に、不正な接続元からの接続が成功していたことがわかります。また、（3）と（4）のログから、SELECTとUPDATEが成功しており、tbl1のデータ参照とデータ更新が行われていることがわかります。これらのことから、「不正な接続元からの接続により、情報漏えいとデータ改ざんが行われた」ことがわかるのです。

Enterprise Postgresの監査ログ機能では収集する情報の種類を増やしたことで、データベースのセキュリティ脅威の検知が行い易くなったということですね。最後に、今後のエンハンス計画などあれば教えてください

二宮
今後は、監査ログを専用ファイルではなくデータベースに格納することを考えています。データベースとして扱うことで、きめ細かいアクセス制御が可能となり、ファイル出力よりもログの改ざん抑止をより強固なものにすることができるからです。

監査ログの改ざん抑止を強化することで、より万全なセキュリティ対策が行えるようになるということですね。Enterprise Postgresでは、今後も高レベルなセキュリティ機能を提供していく、ということでこれからも注目です。ありがとうございました。

2019年1月18日公開