MySQLデータベースサーバーをパブリックネットワークまたは公開ネットワークで実行することが避けられない場合があります。これは、サーバーが複数のサービスで構成され、データベースサーバーと同じサーバー内で実行されることが多い共有ホスティング環境での一般的な設定です。この種の設定をしている人は、サービス拒否、ハッキング、クラッキング、データ侵害などのサイバー攻撃に対して常に何らかの保護を行う必要があります。これらはすべて、データの損失につながる可能性があります。これらは、データベースサーバーで常に避けたいことです。
MySQLまたはMariaDBのセキュリティを向上させるためにできるヒントをいくつか紹介します。
ClamAVは、Linuxを含むさまざまなオペレーティングシステム向けの最も広く知られ、広く信頼されているウイルス対策ソリューションの1つです。無料でインストールが非常に簡単で、サーバー内の不要なものを探すためのかなり優れた検出メカニズムが付属しています。 cronジョブで定期的なスキャンをスケジュールします。例：
0 3 * * * /bin/freshclam ; /bin/clamscan / --recursive=yes -i > /tmp/clamav.log ; mail -s clamav_log_`hostname` [email protected] < /tmp/clamav.log上記は、ClamAVウイルスデータベースを更新し、すべてのディレクトリとファイルをスキャンして、実行のステータスに関する電子メールを送信し、毎日午前3時に報告します。
MySQLユーザーを作成するときは、すべてのホストがワイルドカードホスト（％）を使用してMySQLサーバーにアクセスすることを許可しないでください。次のステートメントに示すように、MySQLホストをスキャンして、ワイルドカードホストの値を探す必要があります。
mysql> SELECT user,host FROM mysql.user WHERE host = '%';
+---------+------+
| user | host |
+---------+------+
| myadmin | % |
| sbtest | % |
| user1 | % |
+---------+------+上記の出力から、[ホスト]列の下に「％」の値しかないすべてのユーザーを厳密化または削除します。 MySQLサーバーにリモートでアクセスする必要があるユーザーは、SSHトンネリング方式を使用するように強制できます。これは、MySQLユーザーのリモートホスト構成を必要としません。 MySQL WorkbenchやHeidiSQLなどのほとんどのMySQL管理クライアントは、SSHチューニングを介してMySQLサーバーに接続するように構成できるため、MySQLユーザーのリモート接続を完全に排除することができます。
また、SUPER特権をローカルホストのユーザーのみに制限するか、UNIXソケットファイルを介して接続します。 LOADDATAINFILEおよびSELECT...INTO OUTFILEステートメントを使用してサーバー上でファイルの読み取りと書き込みを許可するため、root以外のユーザーにFILE特権を割り当てる場合は、より注意が必要です。この特権が付与されているすべてのユーザーは、MySQLサーバーが読み取りまたは書き込みできる任意のファイルを読み取りまたは書き込みすることもできます。
デフォルトの設定、名前付け、構成から離れることで、攻撃ベクトルを数倍に減らすことができます。次のアクションは、DBAが簡単に変更できるが、MySQLに関連して一般的に見落とされがちなデフォルト構成の例です。
- MySQLのルートユーザー名を「root」以外の名前に変更します。
- パスワードの有効期限を設定し、すべてのユーザーのパスワードの有効期間を短縮します。
- MySQLがアプリケーションサーバーと同じ場所にある場合は、UNIXソケットファイルのみを介した接続を強制し、すべてのIPアドレスのポート3306でのリッスンを停止します。
これについては、このブログ投稿「MySQL/MariaDBサーバーを保護する方法」で実際に詳しく説明しています。
遅延スレーブは単なる典型的なスレーブですが、スレーブサーバーは、MySQL 5.6から利用可能な、少なくとも指定された時間だけマスターよりも遅れてトランザクションを意図的に実行します。基本的に、マスターから受信したイベントは、少なくとも Nまで実行されません。 マスターでの実行より数秒遅れています。その結果、スレーブは過去のある時点でマスターの状態を反映します。
遅延スレーブを使用してデータを回復できます。これは、遅延期間内に問題がすぐに見つかった場合に役立ちます。マスターから6時間の遅延でスレーブを構成したとします。この時間範囲内にデータベースが（誤って開発者によって、または意図的にハッカーによって）変更または削除された場合、現在のマスターを停止してからスレーブサーバーを起動することにより、発生する直前の瞬間に戻る可能性があります。次のコマンドで特定の時点まで：
# on delayed slave
mysql> STOP SLAVE;
mysql> START SLAVE UNTIL MASTER_LOG_FILE='xxxxx', MASTER_LOG_POS=yyyyyy;
ここで、「xxxxx」はバイナリログファイルであり、「yyyyy」は災害が発生する直前の位置です（mysqlbinlogツールを使用してこれらのイベントを調べます）。最後に、スレーブを新しいマスターに昇格させると、MySQLサービスが通常どおり動作可能になります。この方法は、バックアップをリロードせずに本番環境でMySQLデータベースを回復するためのおそらく最速の方法です。このブログに示されているように、Dockerコンテナの上に費用効果の高い遅延レプリケーションサーバーをセットアップする方法について、このブログに示されているように、さまざまな長さの遅延スレーブが多数あります。 スタンドアロンのMySQL/MariaDBサーバーで実行している場合でも、通常はバイナリロギングを有効にすることをお勧めします。バイナリログには、データベースの内容を変更するSQLステートメントに関する情報が含まれています。情報は、変更を説明する「イベント」の形式で保存されます。パフォーマンスへの影響はありますが、バイナリログを使用すると、データベースサーバーを復元したい正確なポイントまで再生することができます。これは、ポイントインタイムリカバリ（PITR）とも呼ばれます。レプリケーションにはバイナリロギングも必須です。
バイナリログを有効にすると、完全バックアップを作成するときに、バイナリログファイルと位置情報を含める必要があります。 mysqldumpの場合、値1または2の--master-dataフラグを使用すると、後でバイナリログを再生するときにデータベースをロールフォワードするための開始点として使用できる必要な情報が出力されます。
バイナリロギングを有効にすると、フラッシュバックと呼ばれる別のクールなリカバリ機能を使用できます。これについては、次のセクションで説明します。 フラッシュバック機能はMariaDBで使用でき、MySQLデータベースまたはテーブルの以前のスナップショットにデータを復元できます。フラッシュバックはmysqlbinlogを使用してロールバックステートメントを作成し、そのために完全なバイナリログ行イメージが必要です。したがって、この機能を使用するには、MySQL/MariaDBサーバーを次のように構成する必要があります。 次のアーキテクチャ図は、スレーブの1つでフラッシュバックがどのように構成されているかを示しています。 フラッシュバック操作を実行するには、最初に日付と時刻を決定する必要がありますデータ、またはバイナリログファイルと位置を「表示」する場合。次に、mysqlbinlogユーティリティで--flashbackフラグを使用して、データをそのポイントにロールバックするSQLステートメントを生成します。生成されたSQLファイルでは、DELETEイベントがINSERTに変換され、その逆も行われ、UPDATEイベントのWHERE部分とSET部分が交換されていることがわかります。
次のコマンドラインは、slave2（binlog_row_image =FULLで構成）で実行する必要があります。
次に、slave2をレプリケーションチェーンから切り離します。これは、slave2を切断し、サーバーを使用してデータをロールバックするためです。
最後に、生成されたSQLファイルをslave2のデータベースショップ用のMariaDBサーバーにインポートします。
上記を適用すると、表「製品」は2020-02-1701:30:00の状態になります。技術的には、生成されたSQLファイルはMariaDBサーバーとMySQLサーバーの両方に適用できます。 MySQLサーバーでフラッシュバック機能を使用できるように、MariaDBサーバーからmysqlbinlogバイナリを転送することもできます。ただし、MySQL GTIDの実装はMariaDBとは異なるため、SQLファイルを復元するにはMySQLGTIDを無効にする必要があります。
フラッシュバックを使用するいくつかの利点は、この操作を実行するためにMySQL/MariaDBサーバーを停止する必要がないことです。戻すデータの量が少ない場合、フラッシュバックプロセスは、完全バックアップからデータを回復するよりもはるかに高速です。 一般ログは、基本的に、MySQLサーバーのクライアントによって実行されているすべてのSQLステートメントをキャプチャします。ただし、パフォーマンスへの影響とスペースの消費のため、これはビジー状態の実稼働サーバーでは一般的な決定ではない可能性があります。パフォーマンスが重要な場合は、バイナリログの優先度が高くなります。次のコマンドを実行することにより、実行時に一般ログを有効にできます。[mysqld]
...
binlog_format = ROW
binlog_row_image = FULL
$ mysqlbinlog --flashback --start-datetime="2020-02-17 01:30:00" /var/lib/mysql/mysql-bin.000028 -v --database=shop --table=products > flashback_to_2020-02-17_013000.sqlmysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> RESET SLAVE ALL;$ mysql -u root -p shop < flashback_to_2020-02-17_013000.sqlmysql> SET global general_log_file='/tmp/mysql.log';
mysql> SET global log_output = 'file';
mysql> SET global general_log = ON;
mysql> SET global log_output = 'table';次に、mysql.general_logテーブルに対して標準のSELECTステートメントを使用してクエリを取得できます。このブログ投稿に示されているように、この構成で実行すると、パフォーマンスへの影響が少し増えると予想してください。
それ以外の場合は、クエリのサンプリングと監視を実行できる外部監視ツールを使用して、サーバーに着信するクエリをフィルタリングおよび監査できます。 ClusterControlを使用して、すべてのクエリを収集および要約できます。次のスクリーンショットに示すように、DELETE文字列を含むすべてのクエリをフィルタリングします。
同様の情報は、ProxySQLのトップクエリページでも利用できます（アプリケーションがProxySQL経由で接続）：
これは、データベースサーバーに発生した最近の変更を追跡するために使用できます。また、監査目的で使用することもできます。
MySQLサーバーとMariaDBサーバーには、通常、攻撃者が管理している機密データが含まれているため、常に十分に保護する必要があります。このブログ投稿「ClusterControlを使用してオープンソースデータベースを保護する方法」で紹介されているように、ClusterControlを使用してデータベースサーバーのセキュリティ面を管理することもできます。