グリッドでのデータベースの監査

公開: 2018-09-29

SendGridは最近上場企業になったため、データベースのサブセットに対するすべての変更の完全な監査ログを用意する必要がありました。このサブセットには、大量のトラフィックが見られなかったいくつかの小さなインスタンスだけでなく、カスタマーポータルの稼働時間とサインアップフローに不可欠な古いクラスターのいくつかも含まれていました。

これは、稼働時間の需要が高く、オンラインロールアウト（書き込みのダウンタイムなし）が望ましい一部のデータストアにも影響を与えました。外部の締め切りが迫っており、プロジェクトの範囲を知って、私たちは計画を立てることに着手しました。

計画段階で、回答が必要ないくつかの未解決の質問を特定しました。

これを実行できるソフトウェアに関して、どのようなオプションがありますか？
どのようなパフォーマンスへの影響が予想され、それを事前にどの程度テストできますか？
書き込みの可用性のためにダウンタイムなしでこれを行うことはできますか？

選択肢、選択肢

SendGridでは、大規模なプロジェクトやチーム間のプロジェクトの設計図プロセスに従います。このプロジェクトには、次のような利害関係者として多くのチームが関与しました。

どのデータストアがこのコンプライアンス管理の範囲内にあるかを定義し、証拠を収集することを担当するチームとしての内部監査は、監査の時期に来ます
これらのデータベース監査ログから得られたインシデント対応を分析および処理するチームとしてのInfoSec
この新機能をスコープ内のデータベースにデプロイ、管理、調整するコードを作成するチームとしてのDB Ops

私はこの青写真を書き始め、すべての利害関係者によってレビューされ、アーキテクチャチームによって承認されたことを確認しました。数年前にMySQLの監査ロギングのトピックについて調査し、オプションの状況がどのように見えるかをある程度理解していましたが、偏見を持ってプロジェクトにアプローチしたくはなく、複数の調査を行いたいと思いました。オプションを選択し、あるソリューションを別のソリューションよりも選択する理由の確かな事例を全員に提供します。

この青写真は、ビジネスニーズの解決策がどうなるかを調査しながら同時に書いていたという点で珍しいものでした。ですから、調査を行ううちに、多くの詳細が記入されることを知っていました。

私たちのオプションは次のとおりです。

Percona監査プラグイン
マカフィーMySQL監査

市場に出回っているオプションはこれらだけではありませんが、実際のベイクオフに含まれることを保証するために、これらは私たちの規模に最も近く、DevOpsプラクティスであると感じました。市場に出回っている他の商業オプションは、ベンチマークに含まれるためにその基準を通過しませんでした。

後者は、Mcafeeによって最近オープンされたばかりの新しいソリューションであり、Perconaプラグインではサポートされていなかったテーブルレベルのフィルタリングをサポートしていると主張しているため、調査するのに十分な興味をそそられました。スコープ内のクラスターの1つが実際に合計300の約24のテーブルを監査する必要があることを知っていたので、これはMcafeeプラグインを競争相手にするのに十分な価値のある機能のようでした。

一方、Percona Auditプラグインは、この機能で最も広く使用されているオープンソースソリューションでした。組み込みですが、すでに使用しているPerconaServerでは無効になっています。ただし、イベントのテーブルレベルのフィルタリングは提供されないため、データベースレイヤーの外部でフィルタリングする必要がありました。

ベイクオフ

Pythianのパートナーチームの助けを借りて、ベイクオフの比較を開始しました。最初に、各オプションのインストールと調整の方法を比較しました。チームはすぐに、私たちの手にトレードオフがあると判断しました。 Mcafeeプラグインはテーブルフィルターをネイティブにサポートしていましたが、イベントをストリーミングする方法としてrsyslogを使用することはサポートしていませんでした。つまり、これを使用する場合は、ファイルをローカルでディスクに書き込み、監視スタックへの送信を管理する必要があります。

これは、監査プラグインを使用した場合のパフォーマンスの低下を招く可能性が高いため、望ましくないと見なされました。監査イベントをローカルに書き込んでから別のプロセスで再度読み取ると、実際の本番トラフィックからIOPS容量が失われ、データベースインスタンスのリスクが高まります。これは、これらのファイルが肥大化してデータベースが発生しないように、ディスク上のこれらのファイルのサイズを管理する必要があるためです。ダウンタイム。

一方、妥協案はPerconaプラグインでした。イベントをsyslogにネイティブに送信することをサポートしますが、テーブルフィルターは提供しません。これは、スコープ内のビジーなクラスターが多数のイベントを送信することを意味することを私たちは知っていましたが、そのほとんどは実際には監査したいテーブルからのものではありません。これは、InfoSecの監視スタックのsyslog-receive/logstash層にリスクをもたらしました。 DB opsはそれにアクセスできないため、このプロジェクトの成功は共有所有権の取り組みであったことを意味します。

最終的に、可動部品の少ないソリューションを使用し、1秒間に数千のイベントのフィルタリングを処理するためにlogstashをスケールアウトする必要があるかどうかをできるだけ早く知るように展開を計画することにしました。そのため、Perconaの監査プラグインを使用して前進することが決定されました。

展開計画

設置範囲

特定のクラスター内のすべてのノードにプラグインをインストールして有効にすることで、この展開をシンプルに保つことにしました。つまり、クラスター内のライターノードが変更されたときに監査機能をオンまたはオフにする調整の必要がなくなりました。プラグインは設計上、レプリケーションストリームの変更を記録しないため、変更が適用されるときにレプリケーションストリームが重複イベントを引き起こすことについては何の懸念もありませんでした。

ダウンタイムなし

影響を受けるクラスターでダウンタイムが発生することなく、これをシームレスな展開にしたいと考えました。これにより、これらのクラスターを使用するデリバリーチームで行う必要のある計画とオーケストレーションの量が大幅に削減され、顧客への影響が大幅に削減されます。ただし、プラグインがイベントを特定の施設のrsyslogに送信し、InfoSecチームのsyslogアグリゲーションサーバーにイベントを送信するカスタム構成を使用することも必要でした。これらの構成の一部は、Perconaによって動的ではないと文書化されており、必要な監査プラグイン構成を使用してmysqlインスタンスを再起動すると、このプロジェクトのスコープ内のすべてのインスタンスでダウンタイムが発生する可能性があります。

ステージング環境に専用のテストインスタンスを使用してプラグインをデプロイする際にさまざまな操作順序のテストを開始し、構成管理で最初に必要なすべての構成を配置してから、 load pluginコマンドを実行すると、コマンドが目的の構成で起動します。

これは、このプロジェクトを完了するための計画を簡素化し、本番環境でリリースするまでの時間を短縮し、イベントフィルタリングを微調整する時間を確保し、分析と検出についてセキュリティチームと協力することの両方に役立ちました。

構成管理を使用する

私たちはchefクックブックを使用してデータベースを管理しているため、監査プラグインのデプロイ、調整、監視にchefを使用することを計画していました。ただし、これはクラスターのサブセットでのみ有効にする必要があるため、ここでのビジネス目標に関係のないデータでログストレージを妨げないように、有効にする場所を制御する方法が必要でした。

MySQLデータベースを管理するために、ラッパークックブックモデルを使用して構成を管理します。コアの「ベース」クックブックは、データベースインスタンスがどのように見えるかを定義し、クラスターごとのクックブックはそれをラップして、特定のクラスターに関連する属性を変更したり、構成を追加したりします。この設計により、必要な構成ファイルを作成するコードの大部分を簡単に追加し、プラグインを1つの新しいレシピにロードして、chef属性に基づいてオンとオフを切り替えることができます。また、変更の範囲を考慮して、このコードをクックブックの新しいマイナーバージョンとしてリリースする必要があると判断しました。

また、属性がfalseに設定されている場合は、シェフに関連するsensuチェックを削除し、監査ストリーミングをオフにするようにしました。これは、クラスターがスコープ内でなくなったと見なされたり、断続的な理由で停止する必要が生じた場合に、シェフが正しいことを行えるようにするためでした。そのため、属性の変更を反映するためにノードを手動で変更する必要はありません。

モニタリング

監視していないものの成功を宣言することはできません。しかし、監視は、監視している障害のケースや、これらのチェックがいつか失敗した場合にどのようなアクションを期待するかを考えずに、いくつかのsensuチェックを叩くだけではありません。そこで、2つのことを念頭に置いてこのパイプラインでの監視を計画することにしました。

特に、個別のオンコールローテーションで2つのチームの責任にまたがるため、このシステムの明示的な所有権の範囲について全員が合意する必要があります。
このために追加された新しいチェックには、チェックでリンクするRunbookが付属している必要があり、このチェックが失敗した原因と修正方法が説明されています。

これらの2つのルールを考慮して、非常に具体的なチェックを追加しました。この時点で、エンドツーエンドの「合成」チェックも追加することを検討しましたが、システムのどの部分が失敗したかを正確に伝えることができないため、エンドツーエンドのチェックを行うことを控えました。適切なチームをそれでページングする時間さえあります。そして、私は「万が一に備えて」夜に人々をページングすることの支持者ではありません

以下を監視することにしました。

監査プラグインのライブmysql構成をチェックして、次のことを確認します。
- プラグインはアクティブな状態でした
- audit_log_policyがQUERIESに設定されました

このチェックは、これらの設定が動的であり、ディスク上のmy.cnfファイルの外部で変更される可能性があるため、スコープ内のDBの構成がオンザフライで変更されていないことを確認します。

ログを監視スタックに送信するポートをチェックして、データが流れていることを確認します。基本的に、syslogストリームのもう一方の端が機能していることを確認します。このチェックは、意味が集約チェックと呼ばれるものとして処理されるため、InfoSecチームをひどくページングすることはありません。

途中のハードル

プラグイン構成の監査

このプロジェクトの最初の反復の1つは、 audit_log_exclude_commands機能を利用して、発行するイベントをデータまたはスキーマの操作のみに制限することを目的としています。この構成の基になっているリストは、予想よりもはるかに長いことがすぐにわかりました。

rsyslog構成

これは、このプロジェクトの前に私が知らなかったことです。 Rsyslog構成は、ほぼ独自の言語です。例えば：

リモート宛先の前に2番目の@を使用して、UDPではなくTCPを介してログを送信します。この機能を利用して、ログが配信されていることをもう少し保証したいと思いました。
rsyslogには、信頼性の高い転送用に構成する方法に関する専用のページがあります。これは、私のようなツールの初心者にとって非常に便利です。
rsyslogは、デフォルトで、そのデータを/ var / log / messagesにティーしますが、これは多くのイベントであるため、私の場合は望ましくありませんでした。使用している機能を作成する必要がある場合は、それを行わないでください。構成の最後にlocal5。*〜を追加する必要があります。

消防訓練

スコープ内のデータベースのパフォーマンスへの影響については後で説明しますが、rsyslogはこの設計の重要な部分として使用されていたため、リモートの宛先が利用できない場合や応答しない場合のrsyslogの動作もファイアドリルする必要がありました。そのための最善の方法は、トランザクションスループットが高く、したがって1秒あたりの監査イベントが大量であることがわかっているスコープ内のデータベースの1つで、本番環境でiptablesルールを使用して通信を中断させることでした。これがそのファイアドリルがどのように行われたかです。

監査イベントが指定されたTCPポートを介して流れていることを確認します
iptablesルールを使用して、そのポートのすべてのトラフィックをドロップします/ sbin / iptables -A OUTPUT -p tcp –dport {PORT-NUMBER-HERE} -j DROP
rsyslogの構成で構成されたWorkDirectory内のディスク書き込みアクティビティとファイルを監視します。ファイル名は、これらのイベントを受信するファシリティのActionQueueFileNameに基づきます。

予想どおり、ファイルはこのディレクトリでスプーリングを開始しました。ディスクIOPSアクティビティの急増が見られました。キュー名を定義したファイルの数がActionQueueMaxDiskSpaceの値まで合計されると、rsyslogはこれらのファイルの作成を停止し、ディスクIOPは正規化され、rsyslogレイヤーのフロアにイベントをドロップしていることが明らかになりました。注目すべき点は、飲用ルールを削除した後、rsyslogがディスクにスプールしたすべてのイベントを再送信したため、スプールサイズを超えない限り、分析ストアのイベントが失われることはありませんでした。その実験に基づいていくつかのことを学びました

rsyslogは文書化されているように動作しています。直接の実験でそれを証明することは常に良いです
それぞれが生成するイベントの量に応じて、クラスターごとに異なるキューディスクスペースを定義する必要がある可能性が非常に高くなります。ディスクでのキューイングはIOPS容量とディスク容量にリスクをもたらすため、定期的に再検討して再検討する必要があります。

次の投稿では、このプロジェクトを本番環境にデプロイした後の観察結果と、これが本番環境にできるだけ影響を与えないようにした理由について説明します。