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

最大限のデータ保護のための完全なMariaDB暗号化の保管中および転送中-パート1-

    このブログシリーズでは、完全に暗号化されたMariaDBサーバーを保存中および転送中の暗号化用に構成して、データが保護されないようにする方法について、完全なウォークスルーを提供します。物理的に、または他のホストとの転送および通信中に盗まれた。基本的な考え方は、次の図に簡略化されているように、「プレーン」デプロイメントを完全に暗号化されたMariaDBレプリケーションに変換することです。

    いくつかの暗号化コンポーネントを構成します:

    • 転送中の暗号化。これは、次のもので構成されます。
        クライアントサーバー暗号化 レプリケーションの暗号化
    • 保存時の暗号化。以下で構成されます:
        データファイルの暗号化 バイナリ/リレーログの暗号化。

    このブログ投稿は、転送中の暗号化のみを対象としていることに注意してください。このブログシリーズの第2部では、保存時の暗号化について説明します。

    このデプロイメントウォークスルーは、MariaDBレプリケーションサーバーがすでに実行されていることを前提としています。持っていない場合は、ClusterControlを使用して、5回未満のクリックで数分以内に新しいMariaDBレプリケーションをデプロイできます。すべてのサーバーは、CentOS7システム上のMariaDB10.4.11で実行されています。

    転送中の暗号化

    データは転送中と保存中の両方でリスクにさらされる可能性があり、両方の状態で保護する必要があります。転送中の暗号化は、データがネットワークを介してホスト間、サイトとクラウドプロバイダー間、サービス間、またはクライアントとサーバー間を移動するときに通信が傍受された場合にデータを保護します。

    MySQL / MariaDBの場合、クライアントがデータベースサーバーに接続するとき、またはスレーブノードがマスターノードからデータを複製するときに、データが移動します。 MariaDBは、TLS(Transport Layer Security)プロトコルを使用したクライアントとサーバー間の暗号化された接続をサポートします。 TLSはSSL(Secure Sockets Layer)と呼ばれることもありますが、MariaDBは暗号化が弱いため、実際には暗号化された接続にSSLプロトコルを使用しません。詳細については、MariaDBのドキュメントページをご覧ください。

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

    この設定では、自己署名証明書を使用します。つまり、Google、Comodo、その他の一般的な認証局プロバイダーなどの外部の関係者を使用して身元を確認することはありません。 SSL / TLSでは、ID検証は、サーバーとクライアントが証明書とキーを交換する前に通過する必要がある最初のステップです。

    MySQLは、キーと証明書の生成を自動的に処理するmysql_ssl_rsa_setupと呼ばれる非常に便利なツールを提供します。残念ながら、MariaDBサーバー用のそのようなツールはまだありません。したがって、MariaDBTLSのニーズに合わせてSSL関連のファイルを手動で準備して生成する必要があります。

    以下は、OpenSSLツールを使用して生成するファイルのリストです。

    • CAキー -PEM形式のRSA秘密鍵。秘密にしておく必要があります。
    • CA証明書 -PEM形式のX.509証明書。公開鍵と証明書のメタデータが含まれています。
    • サーバーCSR -証​​明書署名要求。フォームに入力するときの共通名(CN)は重要です。たとえば、CN =mariadb-server
    • サーバーキー -RSA秘密鍵。秘密にしておく必要があります。
    • サーバー証明書 -CAキーによって署名されたX.509証明書。公開鍵と証明書のメタデータが含まれています。
    • クライアントのCSR -証​​明書署名要求。サーバーのCSRとは異なる共通名(CN)を使用する必要があります(例:CN =client1
    • クライアントキー -RSA秘密鍵。秘密にしておく必要があります。
    • クライアント証明書 -CAキーによって署名されたX.509証明書。公開鍵と証明書のメタデータが含まれています。

    何よりもまず、転送中の暗号化用の証明書とキーを保存するディレクトリを作成します。

    $ mkdir -p /etc/mysql/transit/
    $ cd /etc/mysql/transit/

    このブログシリーズの次のパートでは、/ etc / mysql / restに保存中の暗号化用に別のディレクトリを作成するため、前述のようにディレクトリに名前を付ける理由を説明します。

    認証局

    独自の認証局(CA)のキーファイルを生成します:

    $ openssl genrsa 2048 > ca-key.pem
    Generating RSA private key, 2048 bit long modulus
    .......................+++
    ...............................................................................................................................................................................................................................................+++
    e is 65537 (0x10001)

    3650日が経過する前に生成されたca-key.pemに基づいて、独自の認証局(CA)の証明書を生成します。

    $ openssl req -new -x509 -nodes -days 3650 -key ca-key.pem -out ca.pem
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    -----
    Country Name (2 letter code) [XX]:SE
    State or Province Name (full name) []:Stockholm
    Locality Name (eg, city) [Default City]:Stockholm
    Organization Name (eg, company) [Default Company Ltd]:Severalnines
    Organizational Unit Name (eg, section) []:
    Common Name (eg, your name or your server's hostname) []:CA
    Email Address []:[email protected]

    これで、この作業ディレクトリの下にca-key.pemとca.pemが作成されます。

    サーバーのキーと証明書

    次に、MariaDBサーバーの秘密鍵を生成します。

    $ openssl genrsa 2048 > server-key.pem
    Generating RSA private key, 2048 bit long modulus
    .............................................................................................................+++
    ..................................................................................................................+++
    e is 65537 (0x10001)

    信頼できる証明書は、認証局によって署名された証明書である必要があります。ここでは、ネットワーク内のホストを信頼しているため、独自のCAを使用します。署名付き証明書を作成する前に、証明書署名要求(CSR)と呼ばれる要求証明書を生成する必要があります。

    MariaDBサーバーのCSRを作成します。証明書をserver-req.pemと呼びます。これは、MariaDBサーバーに使用する証明書ではありません。最終的な証明書は、(次の手順で示すように)独自のCA秘密鍵によって署名される証明書です:

    $ openssl req -new -key server-key.pem -out server-req.pem
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    -----
    Country Name (2 letter code) [XX]:SE
    State or Province Name (full name) []:Stockholm
    Locality Name (eg, city) [Default City]:Stockholm
    Organization Name (eg, company) [Default Company Ltd]:Severalnines
    Organizational Unit Name (eg, section) []:
    Common Name (eg, your name or your server's hostname) []:MariaDBServer
    Email Address []:[email protected]
    
    Please enter the following 'extra' attributes
    to be sent with your certificate request
    A challenge password []:
    An optional company name []:
    「MariaDBServer」を指定した共通名に注意してください。これは任意の名前にすることができますが、値はクライアント証明書と同じであってはなりません。一般に、アプリケーションがFQDNまたはホスト名(skip-name-resolve =OFF)を介してMariaDBサーバーに接続する場合は、MariaDBサーバーのFQDNを共通名として指定することをお勧めします。

    次に、最終的なX.509証明書(server-cert.pem)を生成し、CAの証明書(ca.pem)とCAの秘密鍵(ca)を使用してCSR(server-req.pem)に署名できます。 -key.pem):

    $ openssl x509 -req -in server-req.pem -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -days 3650 -sha256
    Signature ok
    subject=/C=SE/ST=Stockholm/L=Stockholm/O=Severalnines/CN=MariaDBServer/[email protected]
    Getting CA Private Key

    この時点で、これが現在の状態です:

    $ ls -1 /etc/mysql/transite
    ca-key.pem
    ca.pem
    server-cert.pem
    server-key.pem
    server-req.pem

    必要なのは、CA証明書(ca.pem)、サーバーの署名付き証明書(server-cert.pem)、およびMariaDBサーバーのサーバーの秘密鍵(server-key.pem)のみです。 CSR(server-req.pem)は不要になりました。

    クライアントのキーと証明書

    次に、MariaDBクライアントのキーファイルと証明書ファイルを生成する必要があります。 MariaDBサーバーは、これらの証明書ファイルを持つクライアントからのリモート接続のみを受け入れます。

    クライアント用に2048ビットのキーを生成することから始めます:

    $ openssl genrsa 2048 > client-key.pem
    Generating RSA private key, 2048 bit long modulus
    .............................................................................................................+++
    ..................................................................................................................+++
    e is 65537 (0x10001)

    client-req.pemというクライアントのCSRを作成します:

    $ openssl req -new -key client-key.pem -out client-req.pem
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    -----
    Country Name (2 letter code) [XX]:SE
    State or Province Name (full name) []:Stockholm
    Locality Name (eg, city) [Default City]:Stockholm
    Organization Name (eg, company) [Default Company Ltd]:Severalnines
    Organizational Unit Name (eg, section) []:
    Common Name (eg, your name or your server's hostname) []:Client1
    Email Address []:[email protected]
    
    Please enter the following 'extra' attributes
    to be sent with your certificate request
    A challenge password []:
    An optional company name []:
    「Client1」を指定する共通名に注意してください。クライアントを表す任意の名前を指定します。この値は、サーバーの共通名とは異なる必要があります。高度な使用法では、この共通名を使用して、この値に一致する証明書を持つ特定のユーザーを許可できます。例:

    MariaDB> GRANT SELECT ON schema1.* TO 'client1'@'192.168.0.93' IDENTIFIED BY 's' REQUIRE SUBJECT '/CN=Client2';

    次に、最終的なX.509証明書(client-cert.pem)を生成し、CAの証明書(ca.pem)とCAの秘密鍵(ca)を使用してCSR(client-req.pem)に署名できます。 -key.pem):

    $ openssl x509 -req -in client-req.pem -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out client-cert.pem -days 3650 -sha256
    Signature ok
    subject=/C=SE/ST=Stockholm/L=Stockholm/O=Severalnines/CN=Client1/[email protected]
    Getting CA Private Key
    転送中の暗号化設定に必要なすべての証明書が生成されます。両方の証明書がCAによって正しく署名されていることを確認します:

    $ openssl verify -CAfile ca.pem server-cert.pem client-cert.pem
    server-cert.pem: OK
    client-cert.pem: OK

    MariaDBのSSLの構成

    すべてのスレーブに新しいディレクトリを作成します:

    (slave1)$ mkdir -p /etc/mysql/transit/
    (slave2)$ mkdir -p /etc/mysql/transit/
    暗号化ファイルをすべてのスレーブにコピーします:

    $ scp -r /etc/mysql/transit/* [email protected]:/etc/mysql/transit/
    $ scp -r /etc/mysql/transit/* [email protected]:/etc/mysql/transit/

    certsディレクトリの所有者が「mysql」ユーザーになっていることを確認し、すべてのキーファイルの権限を変更して、グローバルに読み取れないようにします。

    $ cd /etc/mysql/transit
    $ chown -R mysql:mysql *
    $ chmod 600 client-key.pem server-key.pem ca-key.pem
    「transit」ディレクトリの下にあるファイルを一覧表示するときに表示される内容は次のとおりです。

    $ ls -al /etc/mysql/transit
    total 32
    drwxr-xr-x. 2 root  root 172 Dec 14 04:42 .
    drwxr-xr-x. 3 root  root 24 Dec 14 04:18 ..
    -rw-------. 1 mysql mysql 1675 Dec 14 04:19 ca-key.pem
    -rw-r--r--. 1 mysql mysql 1383 Dec 14 04:22 ca.pem
    -rw-r--r--. 1 mysql mysql 1383 Dec 14 04:42 client-cert.pem
    -rw-------. 1 mysql mysql 1675 Dec 14 04:42 client-key.pem
    -rw-r--r--. 1 mysql mysql 1399 Dec 14 04:42 client-req.pem
    -rw-r--r--. 1 mysql mysql 1391 Dec 14 04:34 server-cert.pem
    -rw-------. 1 mysql mysql 1679 Dec 14 04:28 server-key.pem
    -rw-r--r--. 1 mysql mysql 1415 Dec 14 04:31 server-req.pem

    次に、MariaDBのSSL接続を有効にします。すべてのMariaDBホスト(マスターとスレーブ)で、構成ファイルを編集し、[mysqld]セクションの下に次の行を追加します。

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

    一度に1ノードずつMariaDBサーバーを再起動します。スレーブから開始し、最後にマスターで再起動します。

    (slave1)$ systemctl restart mariadb
    (slave2)$ systemctl restart mariadb
    (master)$ systemctl restart mariadb

    再起動後、MariaDBは、接続文字列でSSL関連のパラメーターを指定すると、SSL関連のパラメーターなしで、または暗号化された接続を使用して接続することにより、プレーン接続を受け入れることができるようになりました。

    ClusterControlユーザーの場合、クリックするだけでクライアントサーバー暗号化を有効にできます。 ClusterControl->セキュリティ->SSL暗号化->有効化->証明書の作成->証明書の有効期限->SSLの有効化に移動するだけです:

    ClusterControlは、必要なキー、X.509証明書、CA証明書を生成します。クラスタ内のすべてのノードのクライアントサーバー接続にSSL暗号化を設定します。 MySQL / MariaDBレプリケーションの場合、SSLファイルは/ etc / ssl / replication / cluster_Xの下にあります。ここで、XはすべてのデータベースノードのクラスターIDです。すべてのノードで同じ証明書が使用され、既存の証明書が上書きされる可能性があります。このジョブの完了後、ノードを個別に再起動する必要があります。最初にレプリケーションスレーブを再起動し、SSL設定が機能することを確認することをお勧めします。

    すべてのノードを再起動するには、ClusterControl->ノード->ノードアクション->ノードの再起動に移動します。スレーブから始めて、一度に1つのノードを再起動してください。最後のノードは、強制停止フラグが有効になっているマスターノードである必要があります:

    ノードがクライアントサーバー暗号化を処理できるかどうかは、次の方法で確認できます。概要グリッドのデータベースノードのすぐ横にある緑色の鍵のアイコンを確認します。

    この時点で、クラスターはMySQLからのSSL接続を受け入れる準備ができています。ユーザー。

    暗号化された接続を介した接続

    MariaDBクライアントには、サーバー内で生成されたすべてのクライアント関連のSSLファイルが必要です。生成されたクライアント証明書、CA証明書、およびクライアントキーをクライアントホストにコピーします。

    $ cd /etc/mysql/transit
    $ scp client-cert.pem client-key.pem ca.pem [email protected]:~

    ** ClusterControlは、すべてのデータベースノードの/ etc / ssl / Replication /cluster_X/の下にクライアントSSLファイルを生成します。XはクラスターIDです。

    マスターでSSLを必要とするデータベースユーザーを作成します:

    MariaDB> CREATE SCHEMA sbtest;
    MariaDB> CREATE USER [email protected]'%' IDENTIFIED BY 'mysecr3t' REQUIRE SSL;
    MariaDB> GRANT ALL PRIVILEGES ON sbtest.* to [email protected]'%';

    クライアントホストから、SSL関連のパラメーターを使用してMariaDBサーバーに接続します。 「STATUS」ステートメントを使用して接続ステータスを確認できます:

    (client)$ mysql -usbtest -p -h192.168.0.91 -P3306 --ssl-cert client-cert.pem --ssl-key client-key.pem --ssl-ca ca.pem -e 'status'
    ...
    Current user: [email protected]
    SSL: Cipher in use is DHE-RSA-AES256-GCM-SHA384
    ...
    暗号化に暗号が使用されているSSL回線に注意してください。これは、クライアントが暗号化された接続を介してMariaDBサーバーに正常に接続されていることを意味します。

    この時点で、次の図の緑色の両方向矢印で示されているように、MariaDBサーバーへのクライアントサーバー接続を暗号化しました。

    次のパートでは、ノード間のレプリケーション接続を暗号化します。

    レプリケーション暗号化

    レプリケーション用に暗号化された接続を設定することは、クライアント/サーバー接続の場合と同様です。同じクライアント証明書、キー、およびCA証明書を使用して、レプリケーションユーザーが暗号化チャネルを介してマスターのサーバーにアクセスできるようにすることができます。これにより、スレーブIOスレッドがマスターからレプリケーションイベントをプルするときに、ノード間の暗号化が間接的に有効になります。

    一度に1つのスレーブでこれを構成しましょう。最初のスレーブ192.168.0.92の場合、MariaDB構成ファイル内の[client]セクションの下に次の行を追加します。

    [client]
    ssl-ca=/etc/mysql/transit/ca.pem
    ssl-cert=/etc/mysql/transit/client-cert.pem
    ssl-key=/etc/mysql/transit/client-key.pem
    スレーブでレプリケーションスレッドを停止します:

    (slave)MariaDB> STOP SLAVE;

    マスターで、既存のレプリケーションユーザーを変更して、SSLを使用して接続するように強制します。

    (master)MariaDB> ALTER USER [email protected] REQUIRE SSL;

    スレーブで、-sslフラグを指定したmysqlコマンドラインを介してマスター192.168.0.91への接続をテストします。

    (slave)MariaDB> mysql -urpl_user -p -h192.168.0.91 -P 3306 --ssl -e 'status'
    ...
    Current user: [email protected]
    SSL: Cipher in use is DHE-RSA-AES256-GCM-SHA384
    ...
    エラーなしでマスターホストに接続できることを確認してください。次に、スレーブで、SSLパラメーターを使用してCHANGEMASTERステートメントを次のように指定します。

    (slave)MariaDB> CHANGE MASTER TO MASTER_SSL = 1, MASTER_SSL_CA = '/etc/mysql/transit/ca.pem', MASTER_SSL_CERT = '/etc/mysql/transit/client-cert.pem', MASTER_SSL_KEY = '/etc/mysql/transit/client-key.pem';
    レプリケーションスレーブを開始します:

    (slave)MariaDB> START SLAVE;

    関連するSSLパラメータを使用して、レプリケーションが正常に実行されていることを確認します。

    MariaDB> SHOW SLAVE STATUS\G
    ...
                  Slave_IO_Running: Yes
                 Slave_SQL_Running: Yes
                Master_SSL_Allowed: Yes
                Master_SSL_CA_File: /etc/mysql/transit/ca.pem
                   Master_SSL_Cert: /etc/mysql/transit/client-cert.pem
                    Master_SSL_Key: /etc/mysql/transit/client-key.pem
    ...

    これで、スレーブはTLS暗号化を介してマスターから安全に複製しています。

    残りのスレーブ、192.168.0.93で上記のすべての手順を繰り返します。唯一の違いは、それぞれのホストに変更する必要があるマスターで実行されるユーザー変更ステートメントです。

    (master)MariaDB> ALTER USER [email protected] REQUIRE SSL;

    この時点で、次の図のマスターからスレーブへの緑色の線で示されているように、転送中の暗号化が完了しました。

    インターフェイスeth1のtcpdump出力を確認することで、暗号化接続を確認できます。スレーブ上。以下は、暗号化なしの標準レプリケーションの例です。

    (plain-slave)$ tcpdump -i eth1 -s 0 -l -w - 'src port 3306 or dst port 3306' | strings
    tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
    H"-'
    binlog.000008Ulw
    binlog.000008Ulw
    sbtest
    sbtest
    create table t1 (id INT AUTO_INCREMENT PRIMARY KEY, data VARCHAR(255))
    binlog.000008
    sbtest
    BEGIN3
    sbtest
    test data3
    Ok*Z
    binlog.000008*Z
    
    ^C11 packets captured
    11 packets received by filter
    0 packets dropped by kernel

    スレーブがマスターから読み取ったテキストをはっきりと見ることができます。暗号化された接続では、次のようなぎこちない文字が表示されます。

    (encrypted-slave)$ tcpdump -i eth1 -s 0 -l -w - 'src port 3306 or dst port 3306' | strings
    tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
    :|f^yb#
    O5~_
    @#PFh
    k)]O
    jtk3c
    @NjN9_a
    !\[email protected]
    NrF
    ?7&Y
    
    ^C6 packets captured
    6 packets received by filter
    0 packets dropped by kernel
    結論

    このブログシリーズの次のパートでは、MariaDB保存時暗号化を使用して完全に暗号化されたセットアップを完了する方法について説明します。しばらくお待ちください!


    1. ECONNREFUSEDを接続します-ノードjs、sql

    2. SQL ServerStandardEditionの高可用性の将来

    3. より良いデータベース設計のためのヒント

    4. ETLプロセスでのPythonとMySQLの使用