Amazon Web Services ブログ

Amazon Aurora Clusterに監査機能を追加

re:InventでMySQLデータベースと互換性があり、コマーシャルデータベースの性能と可用性、オープンソースデータベースのコストパーフォーマンスの両面をそなえた、Amazon Auroraの新機能を発表しました。

今日、advanced auditing機能が全てのお客様にご利用頂けるようになったことを発表致します。

advanced auditingとは

Auditingとは特定のイベントを収集して手動もしくは他のアプリケーションで分析出来るように提供する機能を指します。これらのログはコンプライアンス規定やガバナンスのベースになる情報として利用可能です。advanced auditingの例には、ログ分析、ユーザーアクションの監査(過去のイベントおよび、ニアリアルタイムの脅威検出など)、セキュリティ関連のイベントに設定されたアラームのが含まれます。 Auroraのadvanced auditing機能は、データベースのパフォーマンスに与える影響を最小限に抑えながら、これらの機能を提供するように設計されています。

advanced auditingを利用するには

まずはじめに、advanced auditingを有効にし、audit logを参照します。

advanced auditingの有効化

DBクラスタパラメータグループにあるパラメータを設定することでadvanced auditingの有効化や設定を行うことができます。これらのパラメータの変更がDBクラスタの再起動は必要ありません。また、動作は Aurora DB instance parametersと同様です。

機能を有効/無効化するために server_audit_loggingパラメータを利用します。server_audit_eventsパラメータでどのイベントをログに記録するか設定します。

server_audit_excl_usersとserver_audit_incl_usersパラメータでどのユーザを監査対象にするか設定可能です:

  • server_audit_excl_usersとserver_audit_incl_usersが未指定の場合(デフォルト値)は全てのユーザが記録されます
  • server_audit_incl_usersにユーザを設定し、server_audit_excl_usersを指定しない場合、server_audit_incl_usersに指定したユーザのみ記録されます
  • server_audit_excl_usersにユーザを設定し、server_audit_incl_usersを指定しない場合、server_audit_excl_usersに指定したユーザ以外が記録の対象になります
  • server_audit_excl_usersとserver_audit_incl_usersに同一のユーザを設定した場合は、server_audit_incl_usersの優先度が高いため記録の対象になります

advanced auditingのパラメータの詳細を以下でご説明します

server_audit_logging　監査ログの有効/無効化を指定します。標準ではOFFになっているので、ONに指定することで有効になります

  • Scope: Global
  • Dynamic: Yes
  • Data type: Boolean
  • Default value: OFF (disabled)

server_audit_events　イベントのリストをカンマで区切って指定します。リスト中のエレメント間にスペースは入れなように気をつけて下さい

  • Scope: Global
  • Dynamic: Yes
  • Data type: String
  • Default value: Empty string
  • 有効な値: 以下のイベントの好きな組み合わせを指定可能
    • CONNECT – ユーザ情報を含む、接続の成功・失敗・切断を記録
    • QUERY – シンタックスや権限不足で失敗したクエリを含む、全てのクエリ文字列とクエリの結果をplane textで記録
    • QUERY_DCL – DCLクエリのみを記録 (GRANT, REVOKEなど)
    • QUERY_DDL – DDLクエリのみを記録 (CREATE, ALTERなど)
    • QUERY_DML – DMLクエリのみを記録 (INSERT, UPDATEなど)
    • TABLE – クエリの実行で利用されたテーブルを記録

server_audit_excl_users　ログに記録しないユーザをカンマ区切りで指定します。エレメント間にスペースは入れないよう気をつけて下さい。接続・切断のイベントはこの設定に影響を受けないため記録されます。server_audit_excl_usersに指定されていたとしてもserver_audit_incl_usersにも指定されていた場合は、server_audit_incl_usersの優先度が高いため記録の対象になります

  • Scope: Global
  • Dynamic: Yes
  • Data type: String
  • Default value: Empty string

server_audit_incl_users　ログに記録するユーザをカンマ区切りで指定します。エレメント間にスペースは入れないよう気をつけて下さい。接続・切断のイベントはこの設定に影響を受けません。ユーザがserver_audit_excl_usersに指定されていたとしても、server_audit_incl_usersの優先度が高いため記録の対象になります

  • Scope: Global
  • Dynamic: Yes
  • Data type: String
  • Default value: Empty string

audit logを参照する

AWS Management Consoleからaudit logを参照可能です。Instancesページから、DBクラスタを選択し、Logを選択します。

audit-log

MariaDB Audit Pluginの事をご存知であれば、auditingについてAuroraが取っているアプローチとの幾つかの違いに気づくかと思います。

  • Aurora advanced auditingのタイムスタンプはUnix timeフォーマットで記録されます
  • イベントは複数のログファイルに記録され、ログはシーケンシャルには並んでいません。必要に応じてファイルの結合やタイムスタンプやquery_idを使用してソートを行えます。Unixをお使いの場合は以下のコマンドで実現出来ます。 cat audit.log.* | sort -t”,” -k1,1 –k6,6
  • ファイル数はDBインスタンスサイズに応じて変化します
  • ファイルのローテーションは100MB毎に行われ、閾値の変更は行なえません

MySQLからマイグレーションした後のAurora advanced auditingの有効化は方法が異なります。 Audit logの設定はDBクラスタ向けのパラメータグループで行ないます。

Auroraがどのようにadvanced auditingを実装したか

監査機能はコマーシャルデータベスでもオープンソースデータベース一般的に利用出来る機能です。この機能は一般的にパフォーマンスへ大きな影響を与えます。特にデータベースの利用率が高い場合は顕著です。Auroraでの実装の1つのゴールは様々な情報をパフォーマンスの犠牲なくユーザに提供することです。

パフォーマンスを維持するために

パフォーマンスの課題をどの様に解決したか理解するために、私達のadvanced auditingの実装とMariaDB Audit Pluginの実装を比較してみます。MySQL Community Editionではnative audit logを提供していないため、私たちは比較のためにこちらを利用します。そして、 MariaDB Audit Pluginはオープンソースコミュニティの中で、これらの制約を埋める一般的なオプションとしてあげられます。

MariaDB Audit Pluginは、シングルスレッドでシングルミューテックスを処理と各イベントの書き出しに利用します。このデザインは、ログの書き出しのボトルネックに起因するパフォ＝マンスの低下を起こしますが、イベントの順序を厳密に保存することが出来ます。もし、このアプローチをAuroraに利用すると、データベースエンジンの期待するスループットや高いスケーラビリティにより、パフォーマンスへのインパクトが更に大きくなってしまいます。

高いパフォーマンスを維持するために、イベント処理とイベントの書き出しロジックを再設計しました。入力面では、ラッチフリーキューを他のスレッドをロックすること無くaudit logを保存するために利用しました。出力面では、ラッチフリーキューから複数のファイルへイベントを書き出すためにマルチスレッドモデルを利用しています。このファイルを処理することで、イベント順に並んだ1つの監査ログとして生成出来ます。

advanced-auditing-how

ログフォーマット

audit logは各インスタンスのローカル(エフェメラル)ディスクに保存されます。各Auroraインスタンスは4つのログファイルに書き込みます。

  • Encoding: UTF-8
  • ファイル名パターン: audit.log.0-3.%Y-%m-%d-%H-%M-rotation
  • 保存場所: /rdsdbdata/log/audit/ (各ホスト毎)
  • ローテーション: 各ログファイル毎に100MBで、現在は変更不可。4つのログファイルの内、もっとも大きなファイルサイズが100MBになった場合、システムは新しいログファイルのセットへローテーションを行ないます
  • クリーンアップ: ディスクスペースを解放するために、ディスク消費量やファイルの世代に応じて古くなったaudit logを削除します
  • ログフォーマット: timestamp,serverhost,username,host,connectionid,queryid,operation,database,object,retcode
パラメータ 説明
timestamp 秒精度のログが記録された時点のUnixタイムスタンプ
serverhost ログが記録されたホスト名
username 接続ユーザ
host ユーザの接続元ホスト
connectionid ログを記録するためのコネクションID
queryid 関連するテーブルやクエリを特定するために利用するクエリID。TABLEイベントでは複数行記録される
operation 記録されたactionタイプ (CONNECT, QUERY, READ, WRITE, CREATE, ALTER, RENAME, DROP)
database USEコマンドで指定されたデータベース名
object QUERYイベントでは、実行されたクエリ。TABLEイベントではテーブル名
retcode ログを記録するためのリターンコード

他の方法と比較を行った場合

前述のように、多くのデータベースでは監査ログ機能が提供されていますが、監査機能が有効になっているとパフォーマンスが低下します。参照のみのワークロードを用いて、8xlargeインスタンス使用し、MariaDB Audit Pluginを有効にしたMySQL 5.7とパフォーマンス比較を行ないました。以下の結果のとおり、MySQLではAudit log機能が有効になっていると性能の大幅な低下が起こっています。Auroraでの性能低下は抑えられています。Auroraでは、15%の低下で抑えられていますが、MySQL5.7では65%の低下となっています。結果として、audit機能が有効になっている場合、AuroraのパフォーマンスはMySQL 5.7と比較して倍以上に向上しました。

advanced-auditing-benchmark

Advanced auditingは本日からご利用頂けます！機能の詳細はドキュメントをご覧ください。

注: こちらの機能はAurora version 1.10.1からご利用頂けます (https://forums.thinkwithwp.com/ann.jspa?annID=4349)

— Sirish Chandrasekaran (product manager at Amazon Web Services) (翻訳は星野が担当しました。原文はこちら)