この記事では、プロトコルトランスポート層セキュリティ (TLS) とデジタル証明書の詳細について説明します。
トランスポート層セキュリティ (TLS)
TLS プロトコルと SSL プロトコルは、アプリケーション プロトコル 層と TCP/IP 層の間に配置され、そこでアプリケーション データをセキュリティで保護し、トランスポート層に送信できます。 TLS/SSL プロトコルでは、 暗号スイート のアルゴリズムを使用してキーを作成し、情報を暗号化します。 クライアントとサーバーは、接続確立の初期接続 (ログイン前) フェーズで暗号化に使用されるプロトコル バージョンと暗号スイートをネゴシエートします。 TLS ハンドシェイクでは、サポートされている最も上位の TLS バージョンが常に優先されます。 さまざまなバージョンの Windows オペレーティング システムでサポートされている TLS プロトコルのバージョンを確認するには、 TLS/SSL (Schannel SSP) のプロトコルに関する記事を参照してください。 SSL および以前のバージョンの TLS に対して、いくつかの既知の脆弱性が報告されています。 セキュリティで保護された通信のために TLS 1.2 にアップグレードすることをお勧めします。
SQL Server で TLS を使用して、SQL Server のインスタンスとクライアント アプリケーション間でネットワーク送信されるデータを暗号化できます。 暗号化は TLS で証明書を使用して実装されます。
TLS 暗号化を有効にすると、SQL Server のインスタンスとアプリケーション間でネットワーク送信されるデータのセキュリティが強化されます。 ただし、SQL Server とクライアント アプリケーション間のすべてのトラフィックが TLS を使用して暗号化されている場合は、次の追加処理が必要です。
- 接続時に追加のネットワーク ラウンドトリップが必要です。
- アプリケーションから SQL Server のインスタンスに送信されるパケットは、クライアント TLS スタックによって暗号化され、サーバー TLS スタックによって暗号化解除される必要があります。
- SQL Server のインスタンスからアプリケーションに送信されるパケットは、サーバー TLS スタックによって暗号化され、クライアント TLS スタックによって暗号化解除される必要があります。
Von Bedeutung
SQL Server 2016 (13.x) 以降、Secure Sockets Layer (SSL) は廃止されました。 代わりに TLS を使用します (TLS 1.2 をお勧めします)。 詳細については、 Microsoft SQL Server の TLS 1.2 サポートを参照してください。 SQL Server 2022 では、TLS 1.3 のサポートが導入されています。 詳細については、TLS 1.3 サポートに関する記事を参照してください。 クライアント コンピューターとサーバー コンピューターの間に一致するプロトコルが存在しない場合は、「 既存の接続がリモート ホストによって強制的に閉じられた」で説明されているエラーが発生する可能性があります。
デジタル証明書の概要
デジタル証明書は、オンライン パスワードのように動作し、ユーザーまたはコンピューターの ID を確認する電子ファイルです。 これらは、クライアント通信に使用される暗号化されたチャネルを作成するために使用されます。 証明書は、証明機関 (CA) によって発行されるデジタル ステートメントであり、証明書所有者の ID を保証し、暗号化を使用して関係者が安全に通信できるようにします。
デジタル証明書は、次のサービスを提供します。
- 暗号化: 盗難や改ざんから交換されたデータを保護するのに役立ちます。
- 認証: 所有者 (ユーザー、Web サイト、さらにはルーターなどのネットワーク デバイス) が本当に誰であるか、何であると主張しているかが確認されます。 通常、認証は一方向であり、ソースがターゲットの身元を確認しますが、相互 TLS 認証も可能です。
証明書には公開キーが含まれ、その公開キーを対応する秘密キーを保持するユーザー、コンピューター、サービスの ID に結び付けます。 公開キーと秘密キーは、データを送信する前に暗号化するために、クライアントとサーバーで使用されます。 Windows のユーザー、コンピューター、サービスでは、信頼されたルート証明書ストアにルート証明書が定義されていて、証明書に有効な証明のパスが含まれている場合に、CA に対する信頼が確立されます。 証明書が失効していない (CA の証明書失効リストまたは CRL にない) か、有効期限が切れている場合、証明書は有効と見なされます。
次の表では、3 種類の主なデジタル証明書について説明します。
| タイプ | 説明 | 利点 | 欠点 |
|---|---|---|---|
| 自己署名証明書 | 証明書は、証明書を作成したアプリケーションによって署名されるか、 New-SelfSignedCertificate を使用して作成されます。 | コスト (無料) | - 証明書は、クライアント コンピューターとモバイル デバイスによって自動的に信頼されません。 証明書は、すべてのクライアント コンピューターとデバイス上の信頼されたルート証明書ストアに手動で追加する必要がありますが、一部のモバイル デバイスでは信頼されたルート証明書ストアを変更できません。 - すべてのサービスが自己署名証明書で動作するわけではありません。 - 証明書のライフサイクル管理のためのインフラストラクチャを確立することは困難です。 たとえば、自己署名証明書を取り消すことはできません。 |
| 内部 CA によって発行された証明書 | 証明書は、組織の公開キー基盤 (PKI) によって発行されます。 例として、Active Directory 証明書サービス (AD CS) などがあります。 詳細については、「Active Directory 証明書サービスの概要」を参照してください。 | - 組織が独自の証明書を発行できるようにします。 - 商用 CA からの証明書よりも安価です。 |
- PKI の展開と保守の複雑さが増しました。 - 証明書は、クライアント コンピューターとモバイル デバイスによって自動的に信頼されません。 証明書は、すべてのクライアント コンピューターとデバイス上の信頼されたルート証明書ストアに手動で追加する必要がありますが、一部のモバイル デバイスでは信頼されたルート証明書ストアを変更できません。 |
| 商用 CA によって発行された証明書 | 信頼された商用 CA から証明書を購入します。 | すべてのクライアント、デバイス、およびサーバーが証明書を自動的に信頼するため、証明書の展開が簡略化されます。 | コスト。 必要な証明書の数を最小限にするために事前に計画する必要があります。 |
証明書の所有者の身元が正しいことを証明するには、証明書は他のクライアント、デバイス、サーバーに対する証明書の所有者を正確に識別する必要があります。 これを行う 3 つの基本的な方法を次の表に示します。
| メソッド | 説明 | 利点 | 欠点 |
|---|---|---|---|
| 証明書のサブジェクト一致 | 証明書の Subject フィールドには、ホストの共通名 (CN) が含まれています。 たとえば、 www.contoso.com に発行された証明書は、Web サイトの https://www.contoso.comに使用できます。 |
- すべてのクライアント、デバイス、およびサービスと互換性があります。 -棲み分け。 ホストの証明書を取り消しても、他のホストには影響しません。 |
- 必要な証明書の数。 証明書は、指定したホストに対してのみ使用できます。 たとえば、サービスが同じサーバーにインストールされている場合でも、www.contoso.comにftp.contoso.com証明書を使用することはできません。-複雑さ。 Web サーバーでは、各証明書に独自の IP アドレスのバインドが必要です。 |
| 証明書のサブジェクトの別名 (SAN) 一致 |
Subject フィールドに加えて、証明書の Subject Alternative Name フィールドに複数のホスト名が一覧表示されます。 例えば次が挙げられます。www.contoso.comftp.contoso.comftp.eu.fabrikam.net |
- 便利。 複数の個別のドメイン内にある複数のホストに対して同じ証明書を使用できます。 - ほとんどのクライアント、デバイス、およびサービスは SAN 証明書をサポートしています。 - 監査とセキュリティ。 SAN 証明書を使用できるホストを正確に把握できます。 |
- より多くの計画が必要です。 証明書の作成時に、ホストの一覧を提供する必要があります。 - コンパートメント化の欠如。 証明書内のすべてのホストに影響を与えずに、一部の指定されたホストの証明書を選択的に取り消すことはできません。 |
| ワイルドカード証明書一致 | 証明書の Subject フィールドには、ワイルドカード文字 (*) の後に単一のドメインまたはサブドメインが続く共通名が含まれています。 たとえば、*.contoso.com または *.eu.contoso.com です。
*.contoso.comワイルドカード証明書は、次の目的で使用できます。www.contoso.comftp.contoso.commail.contoso.com |
柔軟性。 証明書を要求するときにホストの一覧を指定する必要はありません。また、今後必要になる可能性のある任意の数のホストで証明書を使用できます。 | - 他の最上位ドメイン (TLD) ではワイルドカード証明書を使用できません。 たとえば、*.contoso.com ホストに*.contoso.netワイルドカード証明書を使用することはできません。- ワイルドカード証明書は、ワイルドカードのレベルのホスト名にのみ使用できます。 たとえば、 *.contoso.comにwww.eu.contoso.com証明書を使用することはできません。 または、*.eu.contoso.comにwww.uk.eu.contoso.com証明書を使用することはできません。- 古いクライアント、デバイス、アプリケーション、またはサービスは、ワイルドカード証明書をサポートしていない可能性があります。 - ワイルドカードは、拡張検証 (EV) 証明書では使用できません。 - 慎重な監査と制御が必要です。 ワイルドカード証明書が侵害されると、指定したドメイン内のすべてのホストに影響します。 |