監査とは、選択したユーザーデータベースのアクションを監視および記録することです。これは通常、疑わしいアクティビティを調査したり、特定のデータベースアクティビティに関するデータを監視および収集するために使用されます。たとえば、データベース管理者は、更新されているテーブル、実行されている操作の数、または特定の時間に接続している同時ユーザーの数に関する統計を収集できます。
このブログ投稿では、オープンソースデータベースシステム、特にMySQL、MariaDB、PostgreSQL、MongoDBの監査の基本的な側面について説明します。この記事は、主にデータベースシステムのインフラストラクチャを管理する際に、監査コンプライアンスのベストプラクティスと優れたデータガバナンスの経験や経験が少ないDevOpsエンジニアを対象としています。
MySQLステートメントの監査
MySQLには一般的なクエリログ（またはgeneral_log）があり、基本的にmysqldが実行していることを記録します。サーバーは、クライアントが接続または切断したときにこのログに情報を書き込み、クライアントから受信した各SQLステートメントをログに記録します。一般的なクエリログはトラブルシューティングの際に非常に役立ちますが、継続的監査用に作成されているわけではありません。これはパフォーマンスに大きな影響を与えるため、短い時間帯にのみ有効にする必要があります。代わりにperformance_schema.events_statements*テーブルまたは監査プラグインを使用する他のオプションがあります。
PostgreSQLステートメント監査
PostgreSQLの場合、log_statmentを「all」に有効にすることができます。このパラメーターでサポートされる値は、none（off）、ddl、mod、およびall（すべてのステートメント）です。 「ddl」の場合、CREATE、ALTER、DROPステートメントなどのすべてのデータ定義ステートメントをログに記録します。 「mod」の場合、すべてのDDLステートメントに加えて、INSERT、UPDATE、DELETE、TRUNCATE、COPYFROMなどのデータ変更ステートメントをログに記録します。
次の例に示すように、log_directory、log_filename、logging_collector、log_rotation_ageなどの関連するパラメーターを構成する必要があります。
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_statement = 'all'
logging_collector = on
log_rotation_age = 10080 # 1 week in minutes 上記の変更にはPostgreSQLの再起動が必要なため、実稼働環境に適用する前に慎重に計画してください。その後、pg_logディレクトリの下に現在のログを見つけることができます。 PostgreSQL 12の場合、場所は/ var / lib / pgsql / 12 / data /pg_log/です。ログファイルは時間の経過とともに大きくなる傾向があり、ディスク領域を大幅に消費する可能性があることに注意してください。ストレージスペースが限られている場合は、代わりにlog_rotation_sizeを使用することもできます。
MongoDBステートメント監査
MongoDBの場合、ステートメントの監査に役立つ3つのログレベルがあります（MongoDB用語の操作または操作）：
-
レベル0-これは、プロファイラーがデータを収集しないデフォルトのプロファイラーレベルです。 mongodは常に、slowOpThresholdMsしきい値よりも長い操作をログに書き込みます。
-
レベル1-低速操作のみのプロファイリングデータを収集します。デフォルトでは、低速操作は100ミリ秒より低速です。 「遅い」操作のしきい値は、slowOpThresholdMsランタイムオプションまたはsetParameterコマンドを使用して変更できます。
-
レベル2-すべてのデータベース操作のプロファイリングデータを収集します。
すべての操作をログに記録するには、db.setProfilingLevel（2、1000）を設定します。ここで、定義されたミリ秒（この場合は1秒（1000 ms））よりも長い操作ですべての操作をプロファイリングする必要があります。 。タイムスタンプの降順で1秒以上かかったすべてのクエリについて、システムプロファイルコレクションを検索するクエリは次のようになります。操作を読み取るには、次のクエリを使用できます。
mongodb> db.system.profile.find( { millis : { $gt:1000 } } ).sort( { ts : -1 } )また、Mongotailプロジェクトがあります。これは、プロファイルコレクションに直接クエリを実行する代わりに、外部ツールを使用して操作プロファイリングプロセスを簡素化します。
本番データベースサーバーで完全なステートメント監査を実行することはお勧めしません。これは、通常、大量のログが記録されるデータベースサービスに大きな影響を与えるためです。推奨される方法は、代わりにデータベース監査プラグインを使用することです（下に示すように）。これは、政府、金融、またはISOの認定に準拠するために必要となることが多い監査ログを作成する標準的な方法を提供します。
MySQL、MariaDB、PostgreSQLの特権監査
特権監査は、データベースオブジェクトへの特権とアクセス制御を監査します。アクセス制御により、データベースにアクセスするユーザーが確実に識別され、資格のあるデータにアクセス、更新、または削除できるようになります。この領域は、データベースユーザーを作成して付与するときによくある間違いを過剰に特権化するDevOpsエンジニアによって一般的に見落とされています。
-
ユーザーのアクセスホストは、たとえばユーザーホスト[email protected]を許可するなど、非常に広い範囲から許可されます。個々のIPアドレスの代わりに％'。
-
非管理データベースユーザーに割り当てられている管理特権。たとえば、アプリケーションのデータベースユーザーが割り当てられています。 SUPERまたはRELOAD特権を使用します。
-
最大ユーザー接続数、1時間あたりの最大クエリ数、最大数など、あらゆる種類の過度の使用に対するリソース制御の欠如1時間あたりの接続数。
-
特定のデータベースユーザーが他のスキーマにもアクセスできるようにします。
MySQL、MariaDB、およびPostgreSQLの場合、付与、ロール、および特権に関連するテーブルを照会することにより、情報スキーマを介して特権監査を実行できます。 MongoDBの場合は、次のクエリを使用します（他のデータベースにはviewUserアクションが必要です）：
mongodb> db.getUsers( { usersInfo: { forAllDBs: true } } )ClusterControlは、データベースユーザーに割り当てられた特権の概要を提供します。 [管理]->[スキーマとユーザー]->[ユーザー]に移動すると、ユーザーの特権のレポートと、[SSLが必要]、[1時間あたりの最大接続数]などの高度なオプションが表示されます。
ClusterControlは、同じユーザーの下でMySQL、MariaDB、およびPostgreSQLの特権監査をサポートしますインターフェース。
スキーマオブジェクトは、ユーザーによって作成された論理構造です。スキーマオブジェクトの例としては、テーブル、インデックス、ビュー、ルーチン、イベント、プロシージャ、関数、トリガーなどがあります。基本的に、データを保持するオブジェクト、または定義のみで構成できるオブジェクトです。通常、スキーマオブジェクトに関連付けられた権限を監査して、不十分なセキュリティ設定を検出し、オブジェクト間の関係と依存関係を理解します。
MySQLとMariaDBには、基本的にスキーマオブジェクトの監査に使用できるinformation_schemaとperformance_schemaがあります。 Performance_schemaは、その名前が示すように、インストルメンテーションの少し深みがあります。ただし、MySQLには、performance_schemaのユーザーフレンドリーなバージョンであるバージョン5.7.7以降のsysスキーマも含まれています。これらのデータベースはすべて、クライアントが直接アクセスしてクエリを実行できます。
ステートメント監査を実行するための最も推奨される方法は、使用中のデータベーステクノロジ用に特別に構築された監査プラグインまたは拡張機能を使用することです。 MariaDBとPerconaには独自のAuditプラグインの実装があり、MySQLEnterpriseで利用可能なMySQLのAuditプラグインとは少し異なります。監査レコードには、監査された操作、操作を実行したユーザー、および操作の日時に関する情報が含まれます。レコードは、データベース監査証跡と呼ばれるデータディクショナリテーブル、またはオペレーティングシステム監査証跡と呼ばれるオペレーティングシステムファイルのいずれかに保存できます。
PostgreSQLには、標準のPostgreSQLログ機能を介して詳細なセッションおよび/またはオブジェクト監査ログを提供するPostgreSQL拡張機能であるpgAuditがあります。これは基本的にPostgreSQLのlog_statement機能の拡張バージョンであり、標準の監査ログに従って、監査のためにキャプチャされたデータを簡単に検索および検索する機能を備えています。
MongoDB Enterprise（有料）およびPercona Server for MongoDB（無料）には、mongodおよびmongosインスタンスの監査機能が含まれています。監査を有効にすると、サーバーは、syslog、コンソール、またはファイル（JSONまたはBSON形式）にログインできる監査メッセージを生成します。ほとんどの場合、パフォーマンスへの影響がJSONよりも小さいBSON形式でファイルにログインすることをお勧めします。このファイルには、認証、承認の失敗など、さまざまなユーザーイベントに関する情報が含まれています。詳細については、監査ドキュメントを確認してください。
次のインストール手順は、本番環境で使用するためにあらゆる種類のサーバーをセットアップする際の一般的な方法です。
$ yum -y install audit # apt install auditd python
$ mv /etc/audit/rules.d/audit.rules /etc/audit/rules.d/audit.rules.ori
$ cd /etc/audit/rules.d/
$ wget https://gist.githubusercontent.com/ashraf-s9s/fb1b674e15a5a5b41504faf76a08b4ae/raw/2764bf0e9bf25418bb86e33c13fb80356999d220/audit.rules
$ chmod 640 audit.rules
$ systemctl daemon-reload
$ systemctl start auditd
$ systemctl enable auditd
$ service auditd restartsystemdでルールをロードする場合、監査は実際にはうまく機能しないため、最後の行のサービスauditdの再起動が必須であることに注意してください。ただし、auditdサービスを監視するにはsystemdが引き続き必要です。起動時に、/ etc / audit/audit.rulesのルールがauditctlによって読み取られます。監査デーモン自体には、管理者がカスタマイズしたい構成オプションがいくつかあります。それらはauditd.confファイルにあります。
次の行は、構成された監査ログから取得した出力です。
$ ausearch -m EXECVE | grep -i 'password' | head -1
type=EXECVE msg=audit(1615377099.934:11838148): argc=7 a0="mysql" a1="-NAB" a2="--user=appdb1" a3="--password=S3cr3tPassw0rdKP" a4="-h127.0.0.1" a5="-P3306" a6=2D6553484F5720474C4F42414C205641524941424C4553205748455245205641524941424C455F4E414D4520494E20282776657273696F6E272C202776657273696F6E5F636F6D6D656E74272C2027646174616469722729上記からわかるように、auditdによってキャプチャされたausearchユーティリティを使用して、MySQLのクリアテキストパスワード（ "--password =S3cr3tPassw0rdKP"）を簡単に見つけることができます。この種の検出と監査は、データベースインフラストラクチャを保護するために不可欠です。このインフラストラクチャでは、安全な環境ではクリアテキストのパスワードを使用できません。
監査ログまたは証跡は、機密データを保存するための非常に重要なシステムであるデータベースシステムは言うまでもなく、インフラストラクチャとシステムを管理するときにDevOpsエンジニアが一般的に見落としている重要な側面です。個人データの漏洩や侵害は、ビジネスに非常に大きな損害を与える可能性があり、現在の情報技術の時代にそれが起こることを誰も望んでいません。