可用性グループは、高可用性/ディザスタリカバリソリューションに最適であり、他のDBAも私に同意すると確信しています。ただし、予期しない予期しない事態を回避するために、特定の予防措置と追加の手順を慎重に検討する必要がある場合があります。たとえば、セカンダリレプリカは、何らかの理由で現在のプライマリレプリカになります。私たちの目標は、それを起こさせないことです。
SQLによって提供される2つの暗号化オプションがあります：sqltdeと常に暗号化されます。この記事では、DBAが細部に特別な注意を払う必要がある1つのシナリオを紹介します。タイトルにあるように、AlwaysOn可用性グループのセットアップの一部であるデータベース内のデータ暗号化を処理する適切な方法をガイドします。
最初の考慮事項
ケースを構築するためのテクノロジーとして、透過的データ暗号化（TDE）を使用します。サポートされているすべてのバージョンのSQLServerに適用されます。この機能は、次のSQLServerエディションでのみ使用できることに注意してください。
- SQL Server 2019の評価、標準、開発者、エンタープライズ
- SQL Server 2017の評価、開発者、エンタープライズ
- SQL Server 2016の評価、開発者、エンタープライズ
- SQL Server 2014の評価、開発者、エンタープライズ
- SQL Server 2012の評価、開発者、エンタープライズ
- SQL Server 2008R2データセンター、評価、開発者、エンタープライズ
- SQL Server 2008の評価、開発者、エンタープライズ
SQL Server Standard EditionでTDE（透過データ暗号化）を使用する方法を見てみましょう。まず、データを暗号化するためのDMK（データベースマスターキー）を作成する必要があります。次に、データにアクセスしながらデータを復号化できるように、証明書とキーを作成します。証明書をバックアップし、最後に暗号化を有効にすることを忘れないでください。
注： TDE機能はSQLServerExpressEditionではサポートされていません。
この投稿では、可用性グループを構築する手順については説明しません。テスト目的ですでに構築されているものに依存しています。 LinuxにSQLServerAlwaysOn可用性グループを展開する方法の詳細を読むことができます。
環境はWindowsベースですが、異なるプラットフォーム（Linux上のSQLServerやAzureSQLマネージドインスタンスなど）を使用する場合、原則は非常に似ています。
一時データ暗号化とは
TDEを使用する主な理由は、SQLデータベースのデータとログファイルのセキュリティです。個人データが盗まれるのを防ぐために、それを守ることは良い考えです、そしてこの暗号化プロセスは非常に簡単です。ページがディスクに書き込まれる前に、ファイルはページレベルで暗号化されます。データにアクセスするたびに、データは復号化されます。 TDEの実装後、データベースを復元または接続するための特定の証明書とキーが必要になります。それが暗号化アルゴリズムです。
マイクロソフト SQLServer可用性グループの例
私のテスト可用性グループは、それぞれが独自のVMにある2つのレプリカで構成されています。基本的なプロパティは次のとおりです。
ご覧のとおり、特別なものはなく、同期コミットモードと手動フェイルオーバーモードを使用するレプリカがいくつかあります。
次のスクリーンショットは、「テスト」と呼ばれるデータベースを示しています。 SQL Server AlwaysOn可用性グループに追加され、同期状態になります。
SQLServerでTDEを有効にする方法
「テスト」データベースに対してSQLServerTDEを有効にする手順は次のとおりです。 注 ：現在のプライマリレプリカで次の手順を実行します。
ステップ1
マスターデータベースにマスターキーを作成します。
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
ステップ2
マスターキーで保護された証明書を作成します。
CREATE CERTIFICATE TestCertificate WITH SUBJECT = 'My test Certificate';ステップ3
データベース暗号化キー（DEK）を作成し、手順2で作成した証明書で保護します。
USE test;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TestCertificate;
ステップ4
暗号化を使用するように「テスト」データベースを設定します。
ALTER DATABASE test
SET ENCRYPTION ON;
TDEが有効になっているかどうかを確認する方法
完了したら、SQLServerの透過的データ暗号化が「テスト」データベースで有効になっていることを確認する必要があります。
データベースのプロパティ セクションで、オプションに移動します ページ。そこで、状態に注意してください ウィンドウの下部にある領域。 暗号化が有効 値はTrueである必要があります 。
次のTSQLコードを実行して確認することもできます。
SELECT name,is_encrypted
FROM sys.databases
WHERE name = 'test'
キー管理と認証の問題
注： tempdbも暗号化されていることがわかっても驚かないでください。これは、tempdbが、すべてのデータベースのデータを使用して、あらゆる種類の操作（並べ替え、ハッシュ結合など）が行われる場所であるためです。したがって、少なくとも1つのユーザーデータベースが暗号化されている場合、その特定のデータベースからの操作はtempdbに入り、そのデータをユーザーデータベースに返す必要があります。したがって、暗号化されていないデータを送り返すことは問題を表します。
データベースのセキュリティを強化するためのSQLServerでのバックアップ暗号化の詳細を読むことができます。
次のTSQLコードを使用して、証明書によって暗号化された「テスト」データベースのデータベースマスターキーが存在することを確認できます（手順3で実行）。
SELECT
DB_NAME(database_id) AS DB,
create_date,
key_algorithm,
key_length,
encryptor_thumbprint,
encryptor_type
FROM sys.dm_database_encryption_keys
WHERE DB_NAME(database_id) = 'test'
これまでのところ、少なくともプライマリレプリカについては良好です。しかし、 sys.databasesにクエリを実行するとどうなりますか セカンダリレプリカの「テスト」データベースの暗号化ステータスを確認するためのシステムビュー？
可用性グループは、データベースに関連するすべてのものを1つのレプリカから別のレプリカに複製します。ただし、セカンダリレプリカには、暗号化されていないことが明確に示されています。
それに関する手がかりがないか、セカンダリレプリカを確認しましょう：
データベースの状態は「同期していない/疑わしい」– まったく見栄えが良くありません。ただし、セカンダリレプリカのエラーログを確認すると、次のことがわかります。
2021-04-10 00:40:55.940 spid39s Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.940 spid39s Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950 spid39s Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.950 spid39s Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950 spid39s Always On Availability Groups data movement for database 'test' has been suspended for the following reason: "system" (Source ID 2; Source string: 'SUSPEND_FROM_REDO'). To resume data movement on the database, you will need to resume the database manually. For information about how to resume an availability database, see SQL Server Books Online.
2021-04-10 00:40:55.950 spid39s Error: 3313, Severity: 21, State: 2.
2021-04-10 00:40:55.950 spid39s During redoing of a logged operation in database 'test', an error occurred at log record ID (34:743:1). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.
主な問題は、「テスト」データベースのデータベース暗号化キーの暗号化に使用される証明書（ステップ3）がセカンダリレプリカに存在しないことです。
なぜですか？
可用性グループはシステムデータベースからのデータを複製しないためです。欠落しているサーバー証明書は、プライマリレプリカマスターデータベースにあります。
SQLServerでTDE証明書を確認および設定する方法
プライマリレプリカマスターデータベースにサーバー証明書のバックアップを生成しましょう。次に、セカンダリレプリカのマスターデータベースに復元しましょう。
次のTSQLコードを使用して、TDEが有効になっている「テスト」データベースを持つ現在のプライマリレプリカからバックアップを生成します。
USE master;
GO
BACKUP CERTIFICATE TestCertificate
TO FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (file='C:\temp\TestCertificate.pvk',
ENCRYPTION BY PASSWORD='<YourStrongPasswordHere>');
セカンダリレプリカで証明書を復元する前に、まずデータベースマスターキーがマスターデータベース内に存在するかどうかを確認してください。 そうでない場合は、手順1とまったく同じように作成します。
次のTSQLコードを使用して、セカンダリレプリカの証明書を復元します。 注 ：最初に.cerファイルと.pvkファイルをターゲットディレクトリにコピーしてください。
USE master;
GO
CREATE CERTIFICATE TestCertificate
FROM FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (
FILE = N'C:\temp\TestCertificate.pvk',
DECRYPTION BY PASSWORD = '<YourStrongPasswordHere>'
);
したがって、セカンダリレプリカで証明書を復元した後でも、「テスト」データベースの状態は同じままです。
「テスト」データベースのデータ移動は一時停止されているため、手動で再開して、今回は幸運かどうかを確認しましょう。
はい！操作は成功しました。 「テスト」データベースは、完全に同期されて正常であるだけでなく、TDEで暗号化されています。
さらに、レプリカの役割を交換するための手動フェイルオーバーの実行後も、すべてが完全に正常に機能し続けます。
結論
紹介されたソリューションは完全に正常に機能しました。ただし、すべての場合に理想的とは限りません。特に、「正しい」方法で計画を立てて実行するのが好きなDBAの場合はそうです。次のように「正しい」と思います：
- 可用性グループからデータベースを削除します
- データベースの読み取り/書き込みが行われるレプリカで透過的データ暗号化を有効にするためのすべての手順を実行します。
- プライマリレプリカからサーバー証明書をバックアップします。
- バックアップファイルをセカンダリレプリカの場所にコピーします。
- マスターデータベースに証明書を復元します。
- データベースを可用性グループに追加し直します。
- データベースの動作状態が正しく、意図された状態であることを確認してください（特定の設定によって異なります）。
ソリューションを提示した方法で、疑わしいとマークされたセカンダリレプリカのデータベースを取得したため、「正しい」を二重引用符で囲んでいます。これだけでも、おそらく多くの不要なフラグ/アラート/指差しが発生します。 Always On可用性グループのセットアップでTDEを計画および適切に実装するためのすべての考慮事項を考慮することで、簡単に回避できる不要なノイズです。
この投稿を締めくくるために、MicrosoftがWebサイトに投稿したTDEに使用される公式の暗号化階層を残しておきます。覚えておいていただきたいのは、各要素が（マスターデータベースまたはユーザーデータベースのいずれかで）作成される場所です。これにより、可用性グループに関する潜在的な問題や驚きを克服できます。
ご存じない場合は、SQL Completeを使用すると、機密データを保護するためのもう1つの便利なテクノロジであるAlwaysEncryptedを構成できます。
Always On可用性グループのシナリオでAlwaysEncryptedを処理することを計画している場合は、この記事で説明されているのと同じことを考慮する必要があることに注意してください。ただし、SQL Complete v6.7で導入された機能は、すぐに成功できるように設計されています。