グリッドでのデータベースの監査パート2：導入後の観察

公開: 2018-09-29

このシリーズの前回の投稿では、このプロジェクトの要件を収集する方法、使用するツールを決定する方法、およびサービスの中断を回避するための展開を計画する方法について説明しました。 約束どおり、このフォローアップ投稿では、展開後の観察と、これが私たちにとって成功したストーリーとなった要因に焦点を当てています。

プリペアドステートメントとコマンドクラスフィルタリング

このプロジェクトの最初の設計は、perconaプラグインの機能を活用して、発行されたイベントをフィルタリングし、スコープを実際に監査する必要があるものに制限する方法として、含まれるコマンドまたは除外されるコマンドのリストを使用できるようにすることを目的としています。

この機能は、検出されたすべてのsqlコマンドをmysqlに固有のリストに基づくクラスでマークし、そこから検出されたコマンドクラスを抑制または発行するかどうかを出力層で決定するプラグインに依存しています。

そのため、最初のブループリントを作成して、 audit_log_exclude_commands機能を活用し、行データへの書き込みや変更を引き起こさなかったSQLコマンドを除外しました。包含リストにはスコープコマンドクラスのいずれかが欠落するリスクがあり、監査ログにギャップがある理由になる可能性があると考えたため、除外リストを選択しました。

ただし、テストした最初のクラスターでは、これらのステートメントが正常に実行され、データを変更した場合にも正常に実行されたにもかかわらず、監査対象のすべてのコマンドがエラーとして分類されていることがわかりました。また、エラー分類と相関していると思われる除外リストに関係なく、すべてのクエリが中央のsyslogサーバーに送信されていることもわかりました。

これは、実際に必要な数よりもはるかに多くのイベントをelasticsearchに保存していたことを意味します。これは、誤った動作をタイムリーに分析および検出する能力に最も確実に影響します。セキュリティチームと協力して、バグトラッカーを介して問題をPerconaに通知することにしましたが、コマンドベースのフィルタリングを中央のsyslogレイヤーに移動することも決定しました。

エンジニアリングのすべてと同様に、ここでのトレードオフは、DBネットワーク層を介してより多くのデータを送信し、集中型syslog層でのフィルタリングをより複雑にし、その見返りとして、Elastic Searchスケーリングのニーズをより管理しやすくし、データベース側の構成をより簡単にすることでした。

パフォーマンス

このプロジェクトで私たちに多くの苦痛を与えた最も重要な決定の1つは、これらのログをトラップして中央のsyslogサーバーに送信するためにrsyslog機能を使用することを決定することです。

しかし、賛否両論がなければ何もありません。

この決定は、別のシステムの稼働時間とその間のネットワークスタックの信頼性が、監査チームにこの監査ソリューションへの信頼を与えるために必要なSLAを提供するために重要になることを意味しました。

その妥協を望まず、DBスタック内で監査ログの永続性の責任を維持する必要がある場合は、監査プラグインでFILEハンドラーを使用してから、ローカルlogstashを使用してログを取得し、の分析システムに転送することをお勧めします。選択。

後者の選択は、データベースプロセスから消費され、監査プラグインとlogstashによって使用されるディスクIOPがはるかに多いことを意味します。つまり、データベーステーブルファイル、操作ログ、および監査の間でインスタンスのディスクスペースのバランスを慎重にとる必要があります。プラグインログ。あなたの選択肢を比較検討することは、どちらがビジネスによって操作しやすく/受け入れられるかだけに依存していますが、それでもあなたには選択肢があります。

私たちの場合、rsyslogの選択は、ビジーなデータベースへの影響が最も少なく、ピーク時は約5400トランザクション/秒でしたが、通常の操作ではパフォーマンスへの影響は見られませんでした。監査プラグインは、データベースのパフォーマンスに影響を与えることなくイベントを送信していました。これはすべて、データベース側でディスクベースの操作を消費しないアーキテクチャを選択したためです。

過去の決定が報われる

このプロジェクトに着手したときに最初に懸念したことの1つは、パフォーマンスへの影響でした。スコープ内のデータベースクラスターの1つは非常に混雑しており、そのアプリケーションはラグに敏感であるため、プラグインをデプロイした後の数値を比較するために、1秒あたりのトランザクション数、ディスクとCPUの使用率などのパフォーマンスメトリックを追跡する必要がありました。そのペナルティが何であるかを参照してください。

通常の運用でペナルティがあまり発生しなかったのは嬉しい驚きでした。前述のように、SYSLOGハンドラーを使用することにしたため、通常、これらの監査イベントを追跡するためにローカルディスク容量を使用する必要はありませんでした。

しかし、「通常の運用」時間のみに基づいて計画することも望んでいませんでした。

また、rsyslogがローカルスプールファイルにフォールバックする必要がある場合、これらのイベントがサービスに影響を与えて、より重要なDBクラスターの停止に影響を与えないことも知っておく必要がありました。本番環境で注意深く監視しながらrsyslogスプーリングの動作をテストすることにより、データベースを機能的にシャーディングするための過去数年間の作業により、ディスクへのrsyslogスプーリングなどのイベントを吸収し、再送信する必要がある多くのディスクIOPS容量という計画外のメリットが得られたことがわかりました。これらすべてのイベント。

これらのイベント中にディスク使用率が増加したことは間違いありませんが、dbインスタンスが重大な状態になったり、顧客向けのアクティビティに影響を及ぼしたりすることはありませんでした。

トレードオフ

ソフトウェアエンジニアリングのすべてのように、常にトレードオフがあります。このプロジェクトでは、信頼性が高く、ログが失われる可能性が少ないログ配信方法を検討しました。これには、ログをディスクに書き込んでから、logstashなどを使用して取り込み、セキュリティチームが使用できるように分析先に送信することが含まれます。

ただし、これは、データベース側でのディスクIOPSの大幅な消費を意味し、これらのデータベースへの顧客対応の通話のサービス品質に影響を与える可能性があることがわかっていました。

rsyslogで復元力のあるロギングを使用し、適度なサイズのスプールを使用し、TCPを使用してイベントをログ監視スタックに送信することで、ビジネスニーズを十分に満たすことができると判断しました。人生のすべてのように、永遠のものはありません。そして、私たちはこの決定が将来再検討される必要があるかもしれないことを認識しています。

ついに

このプロジェクトは、半ダースのクラスターと多数のインスタンスを含みながら、DB opsチームがまだ急成長しているビジネスで明かりを灯し続けている間に、単一の四半期で完了しました。これは、DBEとセキュリティチームの緊密なコラボレーションなしには実現できませんでした。また、範囲を限定し、ビジネスをより安全にするという最終目標に全員が目を向けていることを確認する強力な製品管理がなければ実現できませんでした。