MySQLとMariaDBのセキュリティを実現するための10のヒント

最近のデータのセキュリティは最優先事項です。 PCI-DSSやHIPAAなどの外部規制によって施行される場合もあれば、顧客のデータと評判を気にするための場合もあります。ネットワークアクセス、オペレーティングシステムのセキュリティ、付与、暗号化など、覚えておく必要のあるセキュリティの側面は多数あります。このブログ投稿では、MySQLまたはMariaDBのセットアップを保護する際の注意点に関する10のヒントを紹介します。

1。パスワードなしでユーザーを削除する

MySQLには、事前に作成されたユーザーのセットが付属していました。そのうちのいくつかは、パスワードなしでデータベースに接続でき、さらに悪いことに、匿名ユーザーも接続できます。これはMySQL5.7で変更されており、デフォルトでは、インストール時に選択したパスワードを使用するrootアカウントのみが付属しています。それでも、以前のバージョンからアップグレードされたMySQLインストールがあり、これらのインストールはレガシーユーザーを維持します。また、Centos7のMariaDB10.2には匿名ユーザーが付属しています：

MariaDB [(none)]> select user, host, password from mysql.user where user like '';
+------+-----------------------+----------+
| user | host                  | password |
+------+-----------------------+----------+
|      | localhost             |          |
|      | localhost.localdomain |          |
+------+-----------------------+----------+
2 rows in set (0.00 sec)

ご覧のとおり、これらはローカルホストからのアクセスにのみ制限されていますが、それでも、そのようなユーザーは必要ありません。特権は制限されていますが、データベースに関する詳細情報を表示する可能性のあるいくつかのコマンドを実行できます。たとえば、バージョンは、攻撃のさらなるベクトルを特定するのに役立つ場合があります。

[[email protected] ~]# mysql -uanonymous_user
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 19
Server version: 10.2.11-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW GRANTS\G
*************************** 1. row ***************************
Grants for @localhost: GRANT USAGE ON *.* TO ''@'localhost'
1 row in set (0.00 sec)
MariaDB [(none)]> \s
--------------
mysql  Ver 15.1 Distrib 10.2.11-MariaDB, for Linux (x86_64) using readline 5.1
Connection id:        19
Current database:
Current user:        [email protected]
SSL:            Not in use
Current pager:        stdout
Using outfile:        ''
Using delimiter:    ;
Server:            MariaDB
Server version:        10.2.11-MariaDB MariaDB Server
Protocol version:    10
Connection:        Localhost via UNIX socket
Server characterset:    latin1
Db     characterset:    latin1
Client characterset:    utf8
Conn.  characterset:    utf8
UNIX socket:        /var/lib/mysql/mysql.sock
Uptime:            12 min 14 sec
Threads: 7  Questions: 36  Slow queries: 0  Opens: 17  Flush tables: 1  Open tables: 11  Queries per second avg: 0.049
--------------

非常に単純なパスワードを使用しているユーザーは、パスワードを使用していないユーザーとほぼ同じくらい安全ではないことに注意してください。 「password」や「qwerty」などのパスワードはあまり役に立ちません。

2。タイトなリモートアクセス

まず、スーパーユーザーのリモートアクセス（最新のMySQL（5.7）またはMariaDB（10.2）をインストールするときにデフォルトで処理されます）は、ローカルアクセスのみを使用できます。それでも、さまざまな理由でスーパーユーザーが利用できるのはよくあることです。最も一般的なのは、おそらくデータベースが仕事を簡単にしたい人間によって管理されているため、データベースへのリモートアクセスを追加するためです。リモートアクセスを使用すると、MySQLの潜在的な（または検証済みの）セキュリティの脆弱性を悪用しやすくなるため、これは適切なアプローチではありません。最初にホストに接続する必要はありません。

別のステップ-すべてのユーザーが特定のホストからのみMySQLに接続できることを確認します。同じユーザー（example @ sqldat.com、example @ sqldat.com）に対していつでも複数のエントリを定義できます。これにより、ワイルドカード（[email protected]’％’）の必要性を減らすことができます。

3。テストデータベースを削除する

テストデータベースは、デフォルトで、すべてのユーザー、特に匿名ユーザーが利用できます。このようなユーザーは、テーブルを作成して書き込むことができます。これは、それ自体で問題になる可能性があります。書き込みを行うと、オーバーヘッドが追加され、データベースのパフォーマンスが低下します。現在、デフォルトのインストール後、Centos7上のMariaDB10.2のみがこの影響を受けます。OracleMySQL5.7およびPerconaServer5.7では「テスト」スキーマを使用できません。

[[email protected] ~]# mysql -uanonymous_user
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 13
Server version: 10.2.11-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW GRANTS\G
*************************** 1. row ***************************
Grants for @localhost: GRANT USAGE ON *.* TO ''@'localhost'
1 row in set (0.00 sec)
MariaDB [(none)]> USE test;
Database changed
MariaDB [test]> CREATE TABLE testtable (a INT);
Query OK, 0 rows affected (0.01 sec)
MariaDB [test]> INSERT INTO testtable VALUES (1), (2), (3);
Query OK, 3 rows affected (0.01 sec)
Records: 3  Duplicates: 0  Warnings: 0
MariaDB [test]> SELECT * FROM testtable;
+------+
| a    |
+------+
|    1 |
|    2 |
|    3 |
+------+
3 rows in set (0.00 sec)

もちろん、MySQL 5.7が、「テスト」スキーマが削除されていない以前のバージョンからアップグレードされている場合もあります。これに注意し、作成されているかどうかを確認する必要があります。

4。 MySQLへのアクセスをわかりにくくする

MySQLがポート3306で実行されることはよく知られており、そのスーパーユーザーは「ルート」と呼ばれます。物事を難しくするために、これを変更するのは非常に簡単です。ある程度、これは隠すことによるセキュリティの例ですが、少なくとも「root」ユーザーにアクセスするための自動化された試行を停止する可能性があります。ポートを変更するには、my.cnfを編集し、「port」変数を他の値に設定する必要があります。ユーザーに関しては、MySQLをインストールした後、新しいスーパーユーザー（GRANTALL…WITHGRANT OPTION）を作成してから、既存の「[email protected]」アカウントを削除する必要があります。

5。ネットワークセキュリティ

理想的には、MySQLはネットワークを介して利用できず、すべての接続はUnixソケットを介してローカルで処理されます。一部の設定では、これが可能です。その場合、my.cnfに「skip-networking」変数を追加できます。これにより、MySQLはTCP / IP通信を使用できなくなり、LinuxではUnixソケットのみが使用可能になります（Windowsホストでは名前付きパイプと共有メモリ）。

ただし、ほとんどの場合、このような厳格なセキュリティは実現可能ではありません。その場合、別の解決策を見つける必要があります。まず、ファイアウォールを使用して、特定のホストからMySQLサーバーへのトラフィックのみを許可できます。たとえば、アプリケーションホスト（プロキシを介してMySQLに到達することは問題ありませんが）、プロキシレイヤー、および場合によっては管理サーバーです。ネットワーク内の他のホストは、おそらくMySQLサーバーに直接アクセスする必要はありません。これにより、ネットワーク内の一部のホストが危険にさらされた場合に備えて、データベースへの攻撃の可能性が制限されます。

クエリの正規表現マッチングを可能にするプロキシを使用する場合は、それらを使用してSQLトラフィックを分析し、疑わしいクエリをブロックできます。ほとんどの場合、アプリケーションホストは「DELETE*FROMyour_table;」を実行しないでください。定期的に。一部のデータを削除する必要がある場合は、MySQLインスタンスでローカルに手動で実行できます。 ProxySQLのようなものを使用して、そのようなルールを作成できます：そのようなクエリをブロック、書き換え、リダイレクトします。 MaxScaleには、正規表現に基づいてクエリをブロックするオプションもあります。

6。プラグインの監査

誰がいつ何を実行したかに関するデータの収集に関心がある場合は、MySQLで使用できる監査プラグインがいくつかあります。 MySQL Enterpriseを使用する場合は、MySQLEnterpriseの拡張機能であるMySQLEnterpriseAuditを使用できます。 PerconaとMariaDBにも、独自のバージョンの監査プラグインがあります。最後に、MySQL用のMcAfeeプラグインは、さまざまなバージョンのMySQLでも使用できます。一般的に、これらのプラグインは多かれ少なかれ同じデータを収集します-接続および切断イベント、実行されたクエリ、アクセスされたテーブル。これらすべてには、どのユーザーがそのようなイベントに参加したか、どのホストからログインしたか、いつ発生したかなどに関する情報が含まれています。出力はXMLまたはJSONにすることができるため、一般的なログの内容を解析するよりも解析する方がはるかに簡単です（データはかなり似ていますが）。このような出力は、syslogに送信することもでき、さらに、処理と分析のためにある種のログサーバーに送信することもできます。

7。 LOAD DATALOCALINFILEを無効にする

サーバーとクライアントの両方にLOADDATALOCAL INFILEを実行する機能がある場合、クライアントはローカルファイルからリモートのMySQLサーバーにデータをロードできます。これは、クライアントがアクセスできるファイルを読み取るのに役立つ可能性があります。たとえば、アプリケーションサーバーでは、HTTPサーバーがアクセスできる任意のファイルにアクセスできます。これを回避するには、my.cnfでlocal-infile=0を設定する必要があります

8。ファイル権限

MySQLのセキュリティはオペレーティングシステムの設定にも依存することに注意する必要があります。 MySQLはデータをファイルの形式で保存します。 MySQLサーバーはログにたくさんの情報を書き込みます。この情報にデータが含まれている場合があります。たとえば、低速のクエリログ、一般的なログ、バイナリログなどです。この情報が安全であり、アクセスする必要のあるユーザーだけがアクセスできることを確認する必要があります。通常、これは、MySQLを実行している権限を持つルートとユーザーのみがすべてのMySQL関連ファイルにアクセスできることを意味します。ほとんどの場合、それは「mysql」と呼ばれる専用ユーザーです。 MySQL構成ファイルとMySQLによって生成されたすべてのログをチェックし、他のユーザーが読み取れないことを確認する必要があります。

9。転送中のデータのSSLと暗号化

人々が構成ファイルやログファイルにアクセスできないようにすることは1つのことです。もう1つの問題は、データがネットワークを介して安全に転送されることを確認することです。すべてのクライアントがローカルで、Unixソケットを使用してMySQLにアクセスするセットアップを除いて、ほとんどの場合、クエリの結果セットを形成するデータはサーバーを離れ、ネットワーク経由でクライアントに転送されます。データは、たとえば標準のMySQLレプリケーションを介して、またはGaleraクラスター内でMySQLサーバー間で転送することもできます。ネットワークトラフィックを盗聴することができ、それらの手段を通じて、データが公開されます。

これを防ぐために、SSLを使用してサーバー側とクライアント側の両方のトラフィックを暗号化することができます。クライアントとMySQLサーバーの間にSSL接続を作成できます。マスターとスレーブ間、またはGaleraクラスターのノード間にSSL接続を作成することもできます。これにより、転送されるすべてのデータが安全になり、ネットワークにアクセスした攻撃者が盗聴することがなくなります。

MySQLのドキュメントでは、SSL暗号化の設定方法について詳しく説明しています。面倒な場合は、ClusterControlを使用すると、数回クリックするだけでMySQLレプリケーションまたはGaleraクラスター用の安全な環境をデプロイできます。

10。保存データの暗号化

SSL暗号化を使用して転送中のデータを保護すると、問題は部分的にしか解決されません。保存データ（データベースに保存されているすべてのデータ）にも注意を払う必要があります。保存データの暗号化は、HIPAAやPCIDSSなどのセキュリティ規制の要件になる場合もあります。このような暗号化は、複数のレベルで実装できます。ファイルが保存されているディスク全体を暗号化できます。 MySQLまたはMariaDBの最新バージョンで利用可能な機能を使用して、MySQLデータベースのみを暗号化できます。暗号化はアプリケーションに実装することもできるため、データベースに保存する前にデータを暗号化します。すべてのオプションには長所と短所があります。ディスク暗号化は、ディスクが物理的に盗まれた場合にのみ役立ちますが、実行中のデータベースサーバーではファイルは暗号化されません。 MySQLデータベースの暗号化はこの問題を解決しますが、rootアカウントが侵害された場合にデータへのアクセスを防ぐことはできません。アプリケーションレベルの暗号化は最も柔軟で安全ですが、SQLの機能が失われます。WHERE句またはJOIN句で暗号化された列を使用するのはかなり困難です。

MySQLのすべてのフレーバーは、保存データの暗号化のようなものを提供します。 OracleのMySQLは、透過的データ暗号化を使用してInnoDBテーブルスペースを暗号化します。これは、商用のMySQLEnterprise製品で利用できます。 InnoDBテーブルスペースを暗号化するオプションを提供します。データを何らかの形式で保存する他のファイル（たとえば、バイナリログ、一般ログ、低速クエリログ）は暗号化されません。これにより、ツールチェーン（MySQL Enterprise Backupだけでなく、xtrabackup、mysqldump、mysqlbinlog）もこのような設定で正しく機能します。

MySQL 5.7.11以降、MySQLのコミュニティバージョンもInnoDBテーブルスペース暗号化をサポートするようになりました。エンタープライズ製品との主な違いは、キーの保存方法です。キーは、規制への準拠に必要な安全な保管庫に配置されていません。これは、Percona Server 5.7.11以降、InnoDBテーブルスペースを暗号化することも可能であることを意味します。最近公開されたPerconaServer5.7.20では、バイナリログの暗号化のサポートが追加されました。 keyring_vaultプラグインを介してHashicorpVaultサーバーと統合し、OracleのMySQL Enterpriseエディションで利用可能な機能と一致させる（さらには拡張-バイナリログ暗号化）ことも可能です。

MariaDBは、10.1.3でデータ暗号化のサポートを追加しました。これは、別個の拡張された実装です。これにより、InnoDBテーブルスペースだけでなく、InnoDBログファイルも暗号化することができます。その結果、データはより安全になりますが、一部のツールはそのような構成では機能しません。 Xtrabackupは暗号化されたREDOログでは機能しません-MariaDBは、MariaDB暗号化のサポートを追加するフォークMariaDBBackupを作成しました。 mysqlbinlogにも問題があります。

使用するMySQLフレーバーに関係なく、最新バージョンである限り、データベースサーバーを介して保存データの暗号化を実装し、データがさらに保護されるようにするオプションがあります。

MySQLまたはMariaDBを保護することは簡単ではありませんが、これらの10のヒントが途中で役立つことを願っています。

概要

今日の状況では、データセキュリティはすべてのデータベース管理者にとって最優先事項です。動機が規制要件への準拠であろうと、顧客とビジネスの評判の保護であろうと、MySQLおよびMariaDBデータベースを保護するためのこれらの10のヒントは、インフラストラクチャをさらに保護し、安心を与えるのに役立ちます。