sql >> データベース >  >> RDS >> Mysql

ガレラクラスターを保護する方法-8つのヒント

    分散データベースシステムとして、Galera Clusterは、集中型データベースと比較して追加のセキュリティ対策を必要とします。データは複数のサーバーまたはデータセンターに分散されている可能性があります。ノード間で重要なデータ通信が行われているため、適切なセキュリティ対策が講じられていないと、重大な危険にさらされる可能性があります。

    このブログ投稿では、GaleraClusterを保護するためのヒントをいくつか紹介します。このブログは、以前のブログ投稿「ClusterControlを使用してオープンソースデータベースを保護する方法」に基づいていることに注意してください。

    ファイアウォールおよびセキュリティグループ

    次のポートは、Galeraクラスターにとって非常に重要です。

    • 3306-MySQL
    • 4567-ガレラの通信と複製
    • 4568-ガレラIST
    • 4444-ガレラSST

    外部ネットワークからは、MySQLポート3306へのアクセスのみを開くことをお勧めします。他の3つのポートは、外部ネットワークから閉じることができ、Galeraノード間の内部アクセスのみを許可します。たとえばHAProxyなどのGaleraノードの前にあるリバースプロキシを実行している場合は、MySQLポートをパブリックアクセスからロックダウンできます。また、HAProxy監視スクリプトの監視ポートが開いていることを確認してください。 Galeraノードのデフォルトのポートは9200です。

    次の図は、3ノードのGaleraクラスターでのセットアップ例を示しています。HAProxyは、関連するポートを備えたパブリックネットワークに面しています。

    上の図に基づくと、データベースノードのiptablesコマンドは次のとおりです。

    $ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 3306 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 4444 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dports 4567:4568 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 9200 -j ACCEPT

    ロードバランサーを使用している場合：

    $ iptables -A INPUT -p tcp --dport 3307 -j ACCEPT

    ファイアウォールルールをすべて拒否して終了するようにしてください。これにより、例外ルールで定義されているトラフィックのみが許可されます。たとえば、ネットワークインターフェイス、宛先アドレス、送信元アドレス、接続状態などを追加することで、セキュリティポリシーに従うようにコマンドを厳密にし、拡張することができます。

    MySQLクライアントサーバー暗号化

    MySQLは、クライアントとサーバー間の暗号化をサポートしています。まず、証明書を生成する必要があります。構成が完了すると、ユーザーアカウントを強制して、MySQLサーバーに暗号化して接続するための特定のオプションを指定できます。

    手順では、次のことを行う必要があります。

    1. 認証局（ca-key.pem）のキーを作成します
    2. 自己署名CA証明書（ca-cert.pem）を生成します
    3. サーバー証明書のキーを作成する（server-key.pem）
    4. サーバーの証明書を生成し、ca-key.pem（server-cert.pem）で署名します
    5. クライアント証明書のキーを作成する（client-key.pem）
    6. クライアントの証明書を生成し、ca-key.pem（client-cert.pem）で署名します

    CA秘密鍵（ca-key.pem）には常に注意してください。これにアクセスできる人は誰でも、CA秘密鍵を使用して、CA検証が有効になっている場合に正当なものとして受け入れられる追加のクライアントまたはサーバー証明書を生成できます。肝心なのは、すべてのキーを慎重に保つ必要があるということです。

    次に、[mysqld]ディレクティブの下にSSL関連の変数を追加できます。例：

    ssl-ca=/etc/ssl/mysql/ca-cert.pem
ssl-cert=/etc/ssl/mysql/server-cert.pem
ssl-key=/etc/ssl/mysql/server-key.pem

    MySQLサーバーを再起動して、変更をロードします。次に、REQUIRE SSLステートメントを使用してユーザーを作成します（例：

    ）。 
    mysql> GRANT ALL PRIVILEGES ON db1.* TO 'dbuser'@'192.168.1.100' IDENTIFIED BY 'mySecr3t' REQUIRE SSL;

    REQUIRE SSLで作成されたユーザーは、正しいクライアントSSLファイル（client-cert.pem、client-key.pem、ca-cert.pem）に接続するように強制されます。

    ClusterControlを使用すると、「SSL暗号化の作成」機能を使用して、UIからクライアントサーバーSSL暗号化を簡単に有効にできます。

    ガレラ暗号化

    Galeraの暗号化を有効にすると、通信が同じソケットを介して行われるため、ISTも暗号化されます。一方、SSTは、次のセクションに示すように、個別に構成する必要があります。クラスタ内のすべてのノードでSSL暗号化を有効にする必要があり、SSL暗号化を有効にしているノードと有効にしていないノードを混在させることはできません。これを構成するのに最適なタイミングは、新しいクラスターをセットアップするときです。ただし、実行中の本番システムにこれを追加する必要がある場合は、残念ながらクラスターをリブートストラップする必要があり、ダウンタイムが発生します。

    クラスタ内のすべてのGaleraノードは、同じキー、証明書、およびCA（オプション）を使用する必要があります。 MySQLクライアントサーバー暗号化用に作成されたものと同じキーと証明書を使用することも、この目的のためだけに新しいセットを生成することもできます。 Galera内で暗号化をアクティブにするには、各GaleraノードのMySQL構成ファイル内のwsrep_provider_optionsの下にオプションと値を追加する必要があります。たとえば、Galeraノードの次の既存の行について考えてみます。

    wsrep_provider_options = "gcache.size=512M; gmcast.segment=0;"

    セミコロンで区切られた引用符内に関連する変数を追加します：

    wsrep_provider_options = "gcache.size=512M; gmcast.segment=0; socket.ssl_cert=/etc/mysql/cert.pem; socket.ssl_key=/etc/mysql/key.pem;"

    GaleraのSSL関連パラメーターの詳細については、こちらを参照してください。すべてのノードでこの変更を実行します。次に、クラスターを停止し（一度に1つのノード）、最後にシャットダウンしたノードからブートストラップします。 MySQLエラーログを調べることで、SSLが正しくロードされているかどうかを確認できます。

    2018-01-19T01:15:30.155211Z 0 [Note] WSREP: gcomm: connecting to group 'my_wsrep_cluster', peer '192.168.10.61:,192.168.10.62:,192.168.10.63:'
2018-01-19T01:15:30.159654Z 0 [Note] WSREP: SSL handshake successful, remote endpoint ssl://192.168.10.62:53024 local endpoint ssl://192.168.10.62:4567 cipher: AES128-SHA compression:

    ClusterControlを使用すると、「SSLガレラ暗号化の作成」機能を使用してガレラレプリケーション暗号化を簡単に有効にできます。

    SST暗号化

    SSTが暗号化なしで発生すると、SSTプロセスの進行中にデータ通信が公開されます。 SSTは、ドナーからジョイナーノードへの完全なデータ同期プロセスです。攻撃者が完全なデータ送信を「見る」ことができた場合、その攻撃者はデータベースの完全なスナップショットを取得します。

    暗号化を使用したSSTは、mysqldumpおよびxtrabackup-v2メソッドでのみサポートされます。 mysqldumpの場合、ユーザーにはすべてのノードで「REQUIRE SSL」が付与されている必要があり、構成は標準のMySQLクライアントサーバーSSL暗号化と同様です（前のセクションで説明）。クライアント/サーバー暗号化がアクティブ化されたら、SSLが適用された新しいSSTユーザーを作成します。

    mysql> GRANT ALL ON *.* TO 'sst_user'@'%' IDENTIFIED BY 'mypassword' REQUIRE SSL;

    rsyncの場合、GaleraCluster用のドロップインSSLで保護されたrsyncSSTスクリプトであるgalera-secure-rsyncを使用することをお勧めします。 wsrep_sst_rsyncとほぼ同じように動作します ただし、socatを使用してSSLとの実際の通信を保護します。必要なクライアント/サーバーキーと証明書ファイルを生成し、それらをすべてのノードにコピーし、MySQL構成ファイル内のSSTメソッドとして「secure_rsync」を指定してアクティブにします。

    wsrep_sst_method=secure_rsync

    xtrabackupの場合、次の構成オプションを[sst]ディレクティブの下のMySQL構成ファイル内で有効にする必要があります。

    [sst]
encrypt=4
ssl-ca=/path/to/ca-cert.pem
ssl-cert=/path/to/server-cert.pem
ssl-key=/path/to/server-key.pem

    データベースの再起動は必要ありません。このノードがGaleraによってドナーとして選択された場合、GaleraがSSTを開始すると、これらの構成オプションが自動的に選択されます。

    SELinux

    Security-Enhanced Linux（SELinux）は、カーネルに実装されているアクセス制御メカニズムです。 SELinuxがない場合、ユーザーのファイルアクセスを制御するために、ファイル権限やACLなどの従来のアクセス制御方法のみが使用されます。

    デフォルトでは、厳密な強制モードが有効になっていると、すべてが拒否され、管理者は、機能するためにシステムの要素に必要な一連の例外ポリシーを作成する必要があります。 SELinuxを完全に無効にすることは、最近の多くのRedHatベースのインストールでは一般的な不適切な方法になっています。

    ワークロード、使用パターン、およびプロセスに応じて、環境に合わせた独自のSELinuxポリシーモジュールを作成するのが最善の方法です。実際に行う必要があるのは、SELinuxを許可モード（強制なしでのみログに記録する）に設定し、SELinuxがログに記録するためにGaleraノードで発生する可能性のあるイベントをトリガーすることです。広範であるほど良い。次のようなイベントの例：

    • ドナーまたはジョイナーとしての開始ノード
    • ノードを再起動してISTをトリガーします
    • さまざまなSSTメソッドを使用する
    • mysqldumpまたはxtrabackupを使用してMySQLデータベースをバックアップおよび復元します
    • バイナリログを有効または無効にする

    1つの例は、GaleraノードがClusterControlによって監視され、クエリ監視機能が有効になっている場合、ClusterControlは低速クエリログ変数を有効/無効にして、低速実行クエリをキャプチャします。したがって、audit.logに次の拒否が表示されます。

    $ grep -e denied audit/audit.log | grep -i mysql
type=AVC msg=audit(1516835039.802:37680): avc:  denied  { open } for  pid=71222 comm="mysqld" path="/var/log/mysql/mysql-slow.log" dev="dm-0" ino=35479360 scontext=system_u:system_r:mysqld_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file

    考えられるすべての拒否を監査ログに記録させ、後で audit2allowを使用してポリシーモジュールを生成するために使用できるようにするという考え方です。 SELinuxにロードする前に。 Codershipは、これについてドキュメントページのSELinux構成で詳しく説明しています。

    SSTアカウントと権限

    SSTは、Galeraによって実行される最初の同期プロセスです。これにより、ジョイナーノードがクラスター内の残りのメンバーとともに最新になります。このプロセスは基本的に、ドナーノードからデータをエクスポートし、ジョイナーノードでデータを復元してから、ジョイナーがキューの残りのトランザクション（つまり、同期プロセス中に発生したトランザクション）に追いつくことができるようにします。 3つのSSTメソッドがサポートされています：

    • mysqldump
    • rsync
    • xtrabackup（またはxtrabackup-v2）

    mysqldump SSTを使用するには、次の権限が必要です。

    • SELECT、SHOW VIEW、TRIGGER、LOCK TABLES、RELOAD、FILE

    mysqldumpは、SSTメソッドとして本番環境で使用されることはおそらくないため、これ以上先に進むことはしません。それに加えて、それはドナーのブロック手順です。 Rsyncは通常、同期時間が速く、mysqldumpと比較してエラーが発生しにくいため、xtrabackupの後に推奨される2番目の選択肢です。 SST認証はrsyncでは無視されるため、rsyncが選択されたSST方式である場合は、SSTアカウント権限の構成をスキップできます。

    xtrabackupに沿って、Xtrabackupのドキュメントページに基づく標準のバックアップと復元の手順について、次の権限をお勧めします。

    • CREATE、CREATE TABLESPACE、EVENT、INSERT、LOCK TABLE、PROCESS、RELOAD、REPLICATION CLIENT、SELECT、SHOW VIEW、SUPER

    ただし、xtrabackupのSSTの使用については、次の特権のみが重要です。

    • プロセス、リロード、レプリケーションクライアント

    したがって、SSTのGRANTステートメントは次のように最小化できます。

    mysql> GRANT PROCESS,RELOAD,REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost' IDENTIFIED BY '[email protected]@sTr0nG%%P4ssW0rD';

    次に、MySQL構成ファイル内でそれに応じてwsrep_sst_authを構成します。

    wsrep_sst_auth = sstuser:[email protected]@sTr0nG%%P4ssW0rD

    localhostのSSTユーザーのみを許可し、強力なパスワードを使用してください。 rootユーザーをSSTアカウントとして使用することは避けてください。これは、この変数の下の構成ファイル内でrootパスワードを公開するためです。さらに、MySQLルートパスワードを変更またはリセットすると、将来的にSSTが破損する可能性があります。

    MySQLセキュリティ強化

    Galera Clusterは、MySQLおよびMariaDBフォークで実行されるInnoDBストレージエンジン用のマルチマスターレプリケーションプラグインです。したがって、標準のMySQL / MariaDB/InnoDBセキュリティ強化の推奨事項がGaleraClusterにも適用されます。

    このトピックは、数多くのブログ投稿で取り上げられています。このトピックについては、次のブログ投稿でも取り上げています。

    • MySQLとMariaDBのセキュリティを実現するための10のヒント
    • ClusterControlのヒントとコツ：MySQLインストールの保護
    • ClusterControlを使用してオープンソースデータベースを保護する方法

    上記のブログ投稿は、保存データと転送中のデータを暗号化する必要性、監査プラグイン、一般的なセキュリティガイドライン、ネットワークセキュリティのベストプラクティスなどをまとめたものです。

    ロードバランサーを使用する

    Galeraと一緒に使用できるデータベースロードバランサー（リバースプロキシ）がいくつかあります。それらのいくつかに名前を付けるには、HAProxy、ProxySQL、MariaDBMaxScaleなどがあります。ロードバランサーを設定して、Galeraノードへのアクセスを制御できます。これは、データベースインスタンス間でデータベースのワークロードを分散するだけでなく、アクセスを制限するための優れた方法です。たとえば、メンテナンスのためにノードをオフラインにしたい場合や、Galeraノードで開く接続の数を制限したい場合などです。ロードバランサーは接続をキューに入れることができる必要があるため、データベースサーバーに過負荷保護を提供します。

    MySQLとMariaDBを理解する強力なデータベースリバースプロキシであるProxySQLは、クエリファイアウォールなどの多くの便利なセキュリティ機能で拡張して、データベースサーバーからの問題のあるクエリをブロックできます。クエリルールエンジンを使用して、不正なクエリをより適切で安全なものに書き換えたり、Galeraノードに影響を与えることなく負荷を吸収できる別のサーバーにリダイレクトしたりすることもできます。 MariaDB MaxScaleは、データベースファイアウォールフィルターを使用して正規表現に基づいてクエリをブロックすることもできます。

    Galeraクラスターにロードバランサーを使用するもう1つの利点は、データベース層をパブリックネットワークに公開せずにデータサービスをホストできることです。プロキシサーバーは、プライベートネットワーク内のデータベースノードにアクセスするための要塞ホストとして使用できます。データベースクラスターを外界から隔離することで、重要な攻撃ベクトルの1つを削除しました。

    それでおしまい。常に安全で保護された状態を保ちます。


    1. 単一のSQL接続で複数のSQLコマンドを実行するにはどうすればよいですか？

    2. offset+limitを使用してmySQLクエリの結果の総数を検索します

    3. mysqlでのGROUPBY名の前の日付と時刻の順序付け

    4. MySQLのあるテーブルから別の新しいテーブルにデータをコピーするにはどうすればよいですか？