次の方法で共有


暗号化階層

適用対象: SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceMicrosoft Fabric SQL Database

SQL Server では、暗号化とキーの階層的なキー管理インフラストラクチャを使用してデータを暗号化します。 各層では、証明書、非対称キー、および対称キーの組み合わせを使用して、その層の下位にある層を暗号化します。 拡張キー管理 (EKM) モジュールで、非対称キーと対称キーを SQL Server の外部に格納できます。

次の図は、暗号化階層のそれぞれの層がその下位にある層を暗号化することを示しており、最も一般的な暗号化構成を示しています。 階層の先頭へのアクセスは、通常、パスワードで保護されます。

スタック内の暗号化の組み合わせの図。

次の概念に注意してください。

  • 最適なパフォーマンスを得るには、証明書や非対称キーではなく、対称キーを使用してデータを暗号化します。

  • データベース マスター キー (DMK) は、サービス マスター キー (SMK) によって保護されます。 サービス マスター キーは、SQL Server セットアップで作成され、Windows データ保護 API (DPAPI) を使用して暗号化されます。

  • 追加の層を重ねる他の暗号化階層も使用できます。

  • 拡張キー管理 (EKM) モジュールは、SQL Server の外部で対称または非対称キーを保持します。

  • Transparent Data Encryption (TDE) では、データベース暗号化キーと呼ばれる対称キーを使用する必要があります。このキーは、 master データベースの DMK によって保護された証明書、または EKM に格納されている非対称キーによって保護されます。

  • サービス マスター キーとすべてのデータベース マスター キーは対称キーです。

次の図は、同じ情報を別の方法で示しています。

ホイール内の暗号化の組み合わせの図。

この図は、さらに次の概念を示しています。

  • この図では、矢印は一般的な暗号化階層を示しています。

  • EKM 内の対称キーと非対称キーによって、SQL Server に格納されている対称キーと非対称キーへのアクセスを保護できます。 EKM に結ばれた点線は、SQL Server に格納されている対称キーと非対称キーの代わりに EKM 内のキーを使用できることを示しています。

バックグラウンド

Azure SQL と SQL Server では、非対称暗号化に RSA アルゴリズムが使用されます。 RSA アルゴリズムは、セマンティック セキュリティを欠き、選択されたプレーンテキスト攻撃や暗号テキスト攻撃に対してセキュリティで保護されていないため、その "純粋な" 形式では使用できません。これは、決定論的な性質のためです。 同じメッセージを 2 回暗号化すると、同じ暗号テキストが生成されます。

セキュリティを実現するには、メッセージにパディングが必要です。 現在、データは PKCS #1 v1.5 パディング スキームを使用して RSA で暗号化されています。 PKCS#1 v1.5 パディングの特定の弱点は、バイトがランダムに埋め込まれ、特定の値が強制されないため、あまり冗長でないことです。 ランダム バイトのシーケンスは、小さな確率で "適切に埋め込まれる" ことができます。 攻撃者はブルート フォースによってプレーンテキストを回復するために、約 100 万個の中止されたハンドシェイクを必要とします。

新しいバージョンの PKCS#1 v1.5 では、最適非対称暗号化パディング (OAEP) と呼ばれる新しいパディングの種類が記述されています。これはハッシュ関数を使用して内部冗長性を大幅に追加するため、ランダムな文字列がパディング形式と一致することはあり得ないものです。 OAEP では、RSA 暗号化とパディング チェックの間にハッシュが導入されています。 OAEP からのハッシュによって、攻撃者が何を見ているかを理解する能力が大幅に変更されます。

SQL Server 2025 (17.x) プレビュー以降、RSA ベースの暗号化に対する OAEP-256 のサポートが導入されました。 OAEP パディング モードへの切り替えは、データベース互換性レベルによって行われます。 この機能は、データベース互換性の 170 レベル以上のデータベースで使用できます。

暗号化メカニズム

SQL Server には、次の暗号化メカニズムが用意されています。

  • Transact-SQL 関数

  • 非対称キー

  • 対称キー

  • 証明書

  • 透過的なデータ暗号化

Transact-SQL 関数

個々のアイテムは、Transact-SQL 関数を使用して挿入または更新されると暗号化できます。 詳細については、 ENCRYPTBYPASSPHRASE および DECRYPTBYPASSPHRASE を参照してください。

証明書

通常は証明書と呼ばれる公開キー証明書は、公開キーの値を、対応する秘密キーを保持する個人、デバイス、またはサービスの ID にバインドするデジタル署名されたステートメントです。 証明書は、CA (証明機関) によって発行および書名されます。 CA から証明書を受け取るエンティティは、その証明書のサブジェクトです。 通常、証明書には次の情報が含まれています。

  • サブジェクトの公開キー。

  • サブジェクトの ID 情報 (名前や電子メール アドレスなど)。

  • 有効期間。 これは、証明書が有効であると見なされる期間です。

    証明書は、証明書で指定された期間中のみ有効です。すべての証明書には、 有効期間の開始日有効期間の終了日 の日付が含まれています。 これらの日付によって、有効期間の境界が設定されます。 証明書の有効期間が終了すると、現在期限が切れている証明書のサブジェクトを使用して新しい証明書を要求する必要があります。

  • 発行者の ID 情報。

  • 発行者のデジタル署名。

    この署名により、公開キーとサブジェクトの ID 情報のバインドが有効であることが証明されます (デジタル署名情報の処理により、その情報だけでなく、送信者が保持している一部の機密情報が署名と呼ばれるタグに変換されます)。

証明書の主な利点は、個々のサブジェクトのパスワードの設定をホストで保守する必要性がなくなる点です。 代わりに、ホストは証明書発行者の信頼を確立するだけで、無制限の数の証明書に署名する可能性があります。

セキュリティで保護された Web サーバーなどのホストが、信頼されているルート機関として発行者を指定すると、このときホストは、発行された証明書のバインドを確立するために発行者が使用したポリシーを暗黙的に信頼することになります。 つまりホストは、証明書のサブジェクトの ID が発行者側で確認されているものと見なします。 ホストが発行者を信頼されているルート機関として指定する際は、発行者の公開キーが含まれている発行者の自己署名付きの証明書を、ホスト コンピューターの信頼されているルート証明機関の証明書ストアに配置します。 中間または下位の証明機関が信頼されるのは、信頼されているルート証明機関からの有効な証明書パスを持っている場合のみです。

発行者は、証明書の有効期限が切れる前に、証明書を取り消すことができます。 証明書を取り消すと、証明書で評価されている公開キーと ID のバインドが取り消されます。 各発行者は、プログラムが特定の証明書の有効性を確認するときに使用できる証明書失効リストを保持します。

SQL Server で作成された自己署名証明書は、X.509 基準に従っており、X.509 v1 フィールドをサポートしています。

非対称キー

非対称キーは、秘密キーとそれに対応する公開キーで構成されています。 各キーは、他方のキーで暗号化されたデータを暗号化解除できます。 非対称の暗号化と暗号化解除は、比較的リソースを集中して消費しますが、対称の暗号化よりも高レベルのセキュリティを提供します。 非対称キーは、データベース内のストレージに対する対称キーの暗号化に使用できます。

対称キー

対称キーは、暗号化と暗号化解除の両方で使用される 1 つのキーです。 対称キーを使用した暗号化および暗号化解除は、高速であり、データベース内の機密データでの定型的な使用に適しています。 対称キーのキー マテリアルを保護するために、SQL Server は非対称 RSA 暗号化を使用する暗号化された形式でキー マテリアルを格納します。 これまで、この暗号化では PKCS#1 v1.5 パディング モードが利用されました。データベース互換性レベル 170 以降では、暗号化では OAEP-256 パディング モードが使用されます。

透過的なデータ暗号化

透過的なデータ暗号化 (TDE) は、対称キーを使用した暗号化の特殊なケースです。 TDE では、データベース暗号化キーという対称キーを使用してデータベース全体を暗号化します。 データベース暗号化キーは、DMK または EKM モジュールに格納されている非対称キーによって保護されている他のキーまたは証明書によって保護されます。 詳細については、「Transparent Data Encryption (TDE)」を参照してください。

Fabric SQL データベース

Microsoft Fabric の SQL データベースでは、Always Encrypted、EKM、TDE は現在サポートされていません。 Microsoft Fabric の SQL データベースでは、データベース ユーザーの Microsoft Entra ID のみがサポートされている認証方法です。 詳細については、「Microsoft Fabric での SQL データベースでの 認証Features の比較を参照してください。