MongoDBの監査ログを使用した事前のセキュリティ

データベースのセキュリティは、先制的な測定から不要な訪問者の侵入を防ぐことまで、幅広いテーマです。 MongoDBサーバーを完全に保護できたとしても、誰かがシステムに侵入しようとしたかどうかを知りたいと思います。また、セキュリティを侵害してMongoDBの身代金ハックをインストールした場合は、事後分析や新しい予防策を講じるための監査証跡が必要になります。監査ログを使用すると、ログインしようとしている人を追跡し、システムで何をしたかを確認できます。

MongoDB Enterpriseバージョンには監査ログを有効にする機能が含まれていますが、コミュニティバージョンにはこの機能がありません。 Perconaは、MongoDBから派生したMongoDB用のPerconaServerで独自の監査ログ機能を作成しました。 MongoDBとPerconaのアプローチは互いに異なり、両方を構成して使用する方法を説明します。

MongoDB監査ログ

MongoDB監査ログは簡単に設定できます。JSONファイルへの監査ログを有効にするには、構成ファイルに次のセクションを追加して、MongoDBを再起動します。

auditLog:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

MongoDBは、宛先としてファイル、コンソール、syslogをサポートしています。ファイル形式には、JSONとBSONの2つのオプションがあります。 JSONでは、監査ログの行は次のようになります。

{ "atype" : "authCheck", "ts" : { "$date" : "2017-02-15T22:20:08.322-0000" }, "local" : { "ip" : "127.0.0.1", "port" : 27017 }, "remote" : { "ip" : "127.0.0.1", "port" : 63357 }, "users" : [], "roles" : [], "param" : { "command" : "update", "ns" : "test.inserttest", "args" : { "update" : "preauth_case", "updates" : [ { "q" : { "createdByUserId" : -2 }, "u" : { "$set" : { "statusCode" : "Update" } }, "multi" : false, "upsert" : false } ], "ordered" : true } }, "result" : 0 }

上記の構成では、システムのすべてのユーザーによるすべてのアクションの監査ログが有効になります。同時実行性が高い場合、これによりMongoDBクラスターのパフォーマンスが大幅に低下します。幸いなことに、ログに記録されるイベントをフィルタリングするオプションがあります。

監査ログのフィルターは、クエリの種類、ユーザー/ロールクエリ、またはクエリ対象のコレクションに配置できます。 MongoDBでの監査ログに関するドキュメントは非常に幅広く、多くの例があります。以下に最も重要な例をいくつか示します。

特定のコレクションに対する認証：

    filter: '{ atype: "authenticate", "param.db": "test" }'

複数の監査タイプのログ：

    filter: '{ atype: { $in [ "update", "delete" ]}, "param.db": "test" }'

特定のコレクションの挿入/更新/削除に関するすべての認証チェックをログに記録します：

    filter: '{ atype: "authCheck", "param.ns": "test.orders", "param.command": { $in: [ "find", "insert", "delete", "update", "findandmodify" ] } }'

ご覧のとおり、フィルターは非常に柔軟であり、監査証跡に必要なメッセージをフィルターに掛けることができます。

SomeninesがMongoDBDBAになる-MongoDBを本番環境に導入MongoDBDownloadを無料でデプロイ、監視、管理、スケーリングするために知っておくべきことを学びましょう

MongoDB監査ログ用のPerconaサーバー

Percona ServerforMongoDB監査ログはJSONファイルに制限されています。大多数のユーザーはJSONファイルにのみログを記録しますが、Perconaが将来他のログ機能を追加するかどうかは不明です。

Percona Server for MongoDBのバージョンによっては、構成が異なる場合があります。執筆時点では、すべてのバージョンの構文は次のとおりです。

audit:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

ただし、この構成の違いは最近解決されましたが、それでも解放する必要があります。リリース後、MongoDBauditLogディレクティブに再度従う必要があります：

auditLog:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

Perconaによる形式は少し異なります：

{ "atype" : "authenticate", "ts" : { "$date" : { "$numberLong" : "1487206721903" } }, "local" : { "host" : "n3", "port" : 27017 }, "remote" : { "host" : "172.16.140.10", "port" : 50008 }, "users" : [ { "user" : "admin", "db" : "admin" } ], "params" : { "user" : "admin", "db" : "admin", "mechanism" : "SCRAM-SHA-1" }, "result" : 0 }

MongoDBがすべてをログに記録するのとは対照的に、Perconaは重要なコマンドのみをログに記録することを選択しました。 Percona監査プラグインのソースから判断すると、次のクエリがサポートされています：認証、ユーザーの作成/更新/削除、役割の追加/更新/削除、データベース/インデックスの作成/削除、およびほとんどの重要な管理コマンド。

また、MongoDB監査ログ用のPercona Serverのフィルタリングは、MongoDBと同じ標準に準拠していないようです。 Perconaのドキュメントは非常に簡潔であるため、正確なフィルター構文とオプションが何であるかは非常に不明確です。

フィルタリングせずに監査ログを有効にすると、ログファイルに十分な数のエントリが記録されます。ここから、ログエントリのJSON構文に従うため、フィルターを絞り込むことができます。

監査ログを利用する

自分で簡単にできるようにするには、監査ログをログ分析フレームワークにフィードするのが最適な場合があります。 ELKスタックは、分析を行うための優れた環境であり、より詳細なレベルに非常に簡単にドリルダウンできます。フィールドマッパーを使用すると、ELK内で監査証跡を作成することもできます。

はじめに説明したように、監査ログはさまざまなセキュリティ目的で使用できます。最も明白なものは、事後分析中に参照として必要な場合です。 MongoDB監査ログは、正確に何が起こったかの詳細な概要を提供します。 Percona監査ログには少し少ない情報が含まれていますが、ほとんどの事後分析には十分なはずです。事後分析に監査ログを使用することは素晴らしいことですが、そもそも問題を防止したかったのです。

監査ログのもう1つの目的は、発生している傾向を確認することであり、特定の監査ログメッセージにトラップを設定できます。良い例は、（失敗した）認証の試行率をチェックし、これが特定のしきい値を超えた場合は、それに基づいて行動することです。状況に応じて、実行されるアクションは異なる場合があります。 1つのアクションは、要求の送信元のIPアドレスを自動的にブロックすることですが、別のケースでは、パスワードを忘れた理由についてユーザーに相談することができます。それは実際にあなたが働いているケースと環境に依存します。

もう1つの高度なプリエンプティブ測定は、MongoDBをハニーポットとして使用し、監査ログを利用して不要なユーザーをキャッチすることです。 MongoDBを公開し、誰でもMongoDBサーバーに接続できるようにします。次に、監査ログを使用して、ユーザーが通常の能力を超えることを許可された場合にユーザーが何をするかを検出し、必要に応じてブロックします。ほとんどの人間は難しい方法よりも簡単な方法をとるので、ハニーポットは攻撃をそらすことができ、ハッカーは次の標的に移動します。

結論

MongoDBEnterpriseとPerconaServerfor MongoDBの両方の監査ログを設定する方法を説明するほかに、監査ログ内のログデータを使用して実行できる可能性のあることについても説明しました。

デフォルトでは、ClusterControlは監査ログを有効にしませんが、ConfigManagerを使用してクラスター全体で有効にするのは比較的簡単です。新しいクラスターをデプロイする前に、構成テンプレート内で有効にすることもできます。

ハッピークラスタリング！