データベースのセキュリティ-転送中および保存中のバックアップ暗号化

データの保護は、私たちが優先すべき最も重要なタスクの1つです。 GDPR、HIPAA、PCI DSS、PHIなどのセキュリティコンプライアンスを必要とする規制の出現により、データを安全に保存するか、ネットワーク経由で送信する必要があります。

ClusterControlでは、セキュリティの重要性を重視し、データベースアクセスと保存されたデータを保護するための多くの機能を提供しています。それらの1つは、保管時と転送中の両方でデータベースのバックアップを保護することです。転送中は、バックアップがインターネットまたはネットワークを介して送信元から宛先に転送されるときであり、保存中は、データが永続ストレージに保存されるときです。このブログでは、ClusterControlを使用して、保存中および転送中のバックアップデータを暗号化する方法を紹介します。

暗号化転送中

ClusterControlを介してバックアップを管理する場合、mysqldumpまたはPercona Xtrabackup / Mariabackupの使用は、ネットワーク経由で送信される場合、デフォルトで暗号化なしで管理されます。ただし、データ送信の暗号化にTLS / SSLを使用することは、MySQL / MariaDB / Percona Serverでサポートされており、コマンドの呼び出し時にSSLオプションを提供するPerconaXtrabackupもサポートされています。

ClusterControlは、クラスターをデプロイするときにデフォルトでSSLを有効にしますが、バックアップの作成中に即座に切り替えてデータをネットワーク経由で暗号化するためのコントロールはありません。クラスターを作成するときにClusterControlを使用する手動アプローチ、またはMySQLでTLS / SSLを手動でセットアップする昔ながらの方法を使用する手動アプローチについては、以前のブログを確認してください。

ClusterControlでは、クラスターをデプロイするときに、[セキュリティ]タブまたはこのアイコンを確認できます。

クリックするとボタンを使用すると、新しくプロビジョニングされた展開中にClusterControlによって現在使用または展開されている証明書を置き換えることができます。集まる。このブログ「更新：ClusterControl DBAになる-SSLキー管理と転送中のMySQLデータの暗号化」を確認してください。このブログでは、キーの処理方法を示しました。基本的に、ClusterControlの左側のナビゲーションを通過して、[キー管理]をクリックできます。

以下は、既存のキーを作成およびインポートできるキー管理の例です。

mysqldumpを論理バックアップとして使用してバックアップを作成する場合、データを暗号化するには、SSLオプションが適切に設定されていることを確認してください。

次は？

作成した証明書があるので、それに応じてSSLを有効にして設定する必要があります。これを確認するには、ClusterControlまたはmysqlコマンドプロンプトを介して確認できます。以下の画像を参照してください：

または、[パフォーマンス]タブで確認して、以下に示すように[DB変数]をクリックすることもできます。

[パフォーマンス]->[DB変数]で入力するのに時間がかかる場合があることに注意してください。したがって、手動で確認する場合は、次のようにmysqlコマンドプロンプトを使用できます。

ssl_cipherを定義すると、セキュリティをさらに強化できます。 SHOW GLOBAL STATUS LIKE‘Ssl_cipher_list’ \ Gを実行するか、ここを確認すると、暗号スイートのリストが表示されます。暗号スイートは、認証、暗号化、およびメッセージ認証コード（MAC）アルゴリズムの組み合わせです。これらは、TLS / SSL接続のセキュリティ設定のネゴシエーション中、およびデータの安全な転送のために使用されます。

ClusterControlはmysqldumpをそのホストにローカルで実行するため、MySQL構成ファイル（/etc/my.cnf、/etc/mysql/my.cnf、/usr/etc/my.cnf、〜に次のパラメーター（以下を参照）を追加します。 /.my.cnf）は、SQLダンプのアクションを暗号化します。以下を参照してください：

[mysqldump]
socket=/var/lib/mysql/mysql.sock
max_allowed_packet = 512M
host=127.0.0.1
ssl-cert=/var/lib/mysql/client-cert.pem
ssl-key=/var/lib/mysql/client-key.pem

tcpdumpを使用して監視を試みることができ、TLSを使用した暗号化されていないレイヤーと暗号化されたレイヤーを比較して以下を確認できます。

TLS / SSLを使用する場合：

TLS / SSLなし：

ClusterControlでPerconaXtraBackupまたはMariabackupを使用する場合、バックアップがネットワーク経由で送信される現時点では、TLS/SSLサポートはありません。これは、基本的に通信手段として別のノードへのポートを開くだけのsocatを使用します。

例

[21:24:46]: 192.168.10.20: Launching ( ulimit -n 256000 && LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - | socat - TCP4:192.168.10.200:9999 ) 2>&1.
[21:24:46]: 192.168.10.20: The xtrabackup version is 2.4.12 / 2004012.
[21:24:46]: 192.168.10.20:3306: Checking xtrabackup version.
[21:24:46]: 192.168.10.20: Streaming backup to 192.168.10.200
[21:24:46]: 192.168.10.200: Netcat started, error log is in '192.168.10.200:/tmp/netcat.log'.
[21:24:43]: 192.168.10.200: Starting socat -u tcp-listen:9999,reuseaddr stdout > /home/vagrant/backups/BACKUP-71/backup-full-2018-11-12_132443.xbstream.gz 2>/tmp/netcat.log.

トランスポート中にセキュアレイヤーが必要な場合は、コマンドの呼び出し中に--ssl*オプションを使用して手動でこれを行うことができます。詳細については、PerconaXtraBackupのマニュアルをここで確認してください。登録された認証局から証明書/キーを取得することをお勧めします。

または、ClusterControlを使用して、ネットワーク経由で送信する前にデータを暗号化できます。送信されるパケットは生のデータではなく、暗号化されたデータです。暗号化は保存状態に依存していますが、これについては次のセクションで説明します。

暗号化の保存時

ClusterControlでは、バックアップを作成するときに、データを暗号化するオプションがあります。以下を参照してください：

ClusterControlは、暗号化されると、「AdvanceEncryptionStandard」AES-256-CBCを使用します。以下のサンプルログを参照してください：

[22:12:49]: 192.168.10.30: Launching ( ulimit -n 256000 && LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - | openssl enc -aes-256-cbc -pass file:/var/tmp/cmon-002471-32758-24c456ca6b087837.tmp | socat - TCP4:192.168.10.200:9999 ) 2>&1.

たとえばAWSS3を使用してバックアップをクラウドに保存する場合、S3はサーバー側暗号化（SSE）の3つの異なるモードを提供します。これらは、SSE-S3、SSE-C、またはSSE-KMSです。 Amazonには、保存データの暗号化を処理する優れたSSE機能があります。ここから始めて、S3がAWSKMSをどのように使用するかに取り組んでいます。バックアップをボリュームまたはブロックベースのストレージに移動する場合、AWSにはAWSKMSを使用したEBS暗号化もあります。詳細については、こちらを確認してください。

Microsoft Azureには、保存データを処理する際の優れた機能もあります。「保存データのAzureStorageService暗号化」のページを確認してください。 Azureは、AWS KMSと同じように、AzureKeyVaultでキーを処理します。保存データのGoogle暗号化については、こちらで確認できます。

オンプレミスでデータバックアップを保存する場合、cryptまたはdmcryptと組み合わせてLUKS（Linux Unified Key Setup）を使用できます。これについてはこのブログでは説明しませんが、これは参考になる良い情報源です：MySQL Encryption at Rest – Part 1（LUKS）。ディスク暗号化の詳細については、このArchLinuxページの「ディスク暗号化」から始めるのが最適です。

最も重要なことは、データが保存中および転送中に暗号化されている間、バックアップが機能することを常に確認することです。テストされていないバックアップは、リカバリが必要なときに機能しない場合、バックアップではありません。暗号化されている間もバックアップを保存するには、問題なく復号化する必要があります。したがって、キーはプライベートに、可能な限り最も安全な方法で保存する必要があります。さらに、InnoDB暗号化やSST（Galeraの場合）などの暗号化をデータに追加すると、セキュリティが強化されますが、このブログではこれらについては説明しません。

結論

保管中および転送中のバックアップデータの暗号化は、PHI、HIPAA、PCI DSS、またはGDPRに準拠するための重要なコンポーネントであり、ネットワーク経由で送信されたりディスクに保存されたりする機密データを、有効なキーがないとユーザーやアプリケーションが読み取れないようにします。 PCI DSSやHIPAAなどの一部のコンプライアンス規制では、保存データをデータライフサイクル全体で暗号化する必要があります。

ここでは、ClusterControlがこれらのオプションをエンドユーザーに提供する方法を示します。ただし、コンプライアンスは大きな課題であり、さまざまな分野に影響を及ぼします。規制も頻繁に更新されており、それに応じてプロセス/ツールも更新する必要があります。コンプライアンスを促進するために、ClusterControlのさまざまな領域を継続的に改善しています。これについてのご意見と、改善方法についてお聞かせください。