データ転送時および保存時にデータを暗号化して保護する

完了

Transparent Data Encryption (TDE) は、すべてのAzure SQL データベースで既定で有効になっており、サービスマネージド キーを使用して保存データ ファイル、ログ、バックアップを保護します。 このアプローチでは、構成オーバーヘッドを伴わない強力な暗号化が提供されますが、金融規制機関は、財務個人データを含むデータベースの暗号化キーを制御するよう Contoso Financial Services に要求します。

暗号化レイヤー	サービス管理型	顧客管理
キー コントロール	Microsoft	組織
キーのローテーション	自動	手動または自動
コンプライアンスサポート	Basic	先進的な（規制関連）
構成の複雑さ	なし	Moderate

Azure Key Vault でカスタマー マネージド キーを構成する

カスタマー マネージド キー (CMK) を使用すると、データベースを保護する暗号化キーを制御でき、キーの所有権とローテーション ポリシーの規制要件を満たします。 SQL サーバーは、マネージド ID を使用して、データの暗号化または暗号化解除が必要なたびにAzure Key Vaultからキーを取得します。

カスタマー マネージド キーを SQL Server にアタッチする前に、Key Vaultが 2 つの必須要件を満たしている必要があります。 最初に、誤ってキーを削除しないように、ソフトデリートを有効化する必要です。 次に、消去保護を有効にして、悪意のあるキーまたは永続的なキーの削除をブロックする必要があります。 これらのセーフガードがないと、キーへのアクセスを失うと、データベースに永続的にアクセスできなくなります。

Key Vaultにファイアウォールが構成されている場合は、信頼されたMicrosoft サービスを有効にしてファイアウォールをバイパスする必要があります。 この設定がないと、Azure SQLのマネージド ID は TDE キーを取得できず、TDE 保護機能の構成は失敗します。 SQL サーバーがプライベート エンドポイントを介してKey Vaultに接続する場合、この要件は適用されません。

Step	アクション
1. Key Vaultを作成または確認する	ソフト削除とパージ保護が有効になっていることを確認する
2. RSA キーを生成する	Key Vaultで 2048 ビットまたは 3072 ビットの非対称キーを作成する
3.マネージド ID を割り当てる	SQL Server でシステム割り当て ID またはユーザー割り当て ID を有効にする
4. キーのアクセス許可を付与する	Key Vault Crypto Service Encryption ユーザー ロールまたはアクセス ポリシーに get、wrapKey、unwrapKey のアクセス許可を割り当てる
5. TDE を構成する	カスタマー マネージド キー オプションを選択し、Key Vault キーを指定する

カスタマー マネージド キーを構成した後、TDE は引き続き AES-256 暗号化を使用しますが、データベース暗号化キー (DEK) を Key Vault キーでラップします。 SQL サーバーは、マネージド ID を使用してKey Vaultに対して認証を行い、キーを取得して、DEK を復号化します。 削除、アクセスが取り消された、またはKey Vaultに到達できないなどの理由でキーにアクセスできなくなった場合、データベースはアクセス不可の状態になります。 キー アクセスを復元すると、データベースは介入なしで自動的に回復できます。 Key Vaultアラートと診断ログを構成して、データベースの可用性に影響を与える前にキー アクセスエラーを検出します。

ブラスト半径と可用性に関するKey Vaultアーキテクチャを計画します。 環境 (開発、ステージング、運用) ごとに個別の Key Vault を使用し、ボールトの問題が 1 つのレベルにのみ影響するようにします。 Key Vault のソフト削除リテンション期間は 7 ~ 90 日間 （既定では 90 日間）で、削除されたボルト名をどのくらい早く再利用できるかに影響します。 geo 冗長 SQL デプロイについては、ディザスター リカバリー テストの一環として、Vault の可用性を計画します。

TLS を使用して転送中のデータをセキュリティで保護する

Azure SQLでは、すべての接続にトランスポート層セキュリティ (TLS) が必要です。クリア テキスト接続は受け入れられませんでした。 SQL サーバーの TLS バージョンの最小設定によって、クライアントが接続の確立に使用できるプロトコル のバージョンが決まります。

TLS の最小バージョンが 1.2 に設定されている場合、TLS 1.0 や 1.1 などの古いプロトコルを使用しているクライアントは接続できません。 通常、金融および医療の規制では、ダウングレード攻撃を防ぎ、最新の暗号化標準を確保するために TLS 1.2 以降が義務付けられています。 TLS 1.3 は、プロトコル レベルのセキュリティが最も高いAzure SQL Databaseにも使用できます。すべてのクライアントが TLS 1.3 をサポートする規制されたワークロードでは、それを最小バージョンとして適用できます。 この設定は、AZURE ポータルの SQL サーバーのネットワーク画面で構成します。

表形式データ ストリーム (TDS) プロトコルは、TLS 経由で SQL トラフィックを伝送します。 厳密な接続暗号化を使用した TDS 8.0 では、認証資格情報を含む接続ハンドシェイク全体を暗号化することで、最高のセキュリティが提供されます。 TDS 7.1 は下位互換性のためにサポートされる最小バージョンのままですが、新しいデプロイと規制対象のワークロードには厳格な暗号化をお勧めします。

Tip

SQL Server の初期デプロイ時に、後で更新するのではなく、最小 TLS バージョンを 1.2 に設定します。 この方法では、弱い TLS 構成のアプリケーションが接続できず、セキュリティの除外が必要になります。

列レベルの保護のために Always Encrypted を評価する

Always Encrypted は、Azure SQLに送信する前に、アプリケーション レイヤーのデータを暗号化することで、特定の列を保護します。 ディスク上のデータ ファイルを保護する TDE とは異なり、Always Encrypted は、クエリの実行中でも、暗号化された列のプレーンテキスト値がデータベース エンジンに表示されないようにします。

この暗号化モデルは、データベース管理者、クラウド プロバイダー スタッフ、または昇格された SQL 特権を持つすべてのユーザーが機密データにアクセスしてはならない内部関係者の脅威シナリオに対処します。 社会保障番号、クレジット カード番号、正常性識別子は、Always Encrypted の一般的なユース ケースです。 クライアント ドライバーは、INSERT ステートメントまたは UPDATE ステートメントを送信する前にデータを暗号化し、クエリ結果を復号化してからアプリケーションに返します。

Criteria	TDE のみ	常に暗号化されています
ディスクの盗難から保護	はい	はい
DBA アクセスに対する保護	いいえ	はい
Azure担当者から保護	いいえ	はい
アプリケーションの変更が必要	いいえ	はい
クエリの複雑さの課題	なし	高 (制限された操作)

トレードオフは、実装の複雑さです。 Always Encrypted では、列のメイン キーと列暗号化キーを管理するためのアプリケーションレイヤーの変更が必要であり、クエリ機能は制限されています。暗号化された列に対して範囲クエリ、パターン マッチング、並べ替えを実行することはできません。 脅威モデルにデータベースへのインサイダー アクセスが特に含まれている場合に適していますが、TDE に代わるものではありません。 通常は、すべてのデータに対して保存時の保護用の TDE と、特権ユーザーでもプレーンテキストで表示すべきではないデータを含む列の場合は Always Encrypted の両方を実装します。

カスタマー マネージド キー、ネットワーク分離、およびMicrosoft Entra ID認証を使用して TDE によるセキュリティ要件を満たしている場合、Always Encrypted の複雑さが増すと、十分な価値を提供できません。 運用環境のワークロードに対して Always Encrypted にコミットする前に、脅威モデル、規制要件、およびアプリケーション アーキテクチャを評価します。

保存時と転送中にデータを暗号化すると、各ユーザーが表示できるデータを決定するアクセス制御を適用する準備が整います。