トランスポート層セキュリティとデジタル証明書
この記事では、プロトコルのトランスポート層セキュリティ (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 スタックによって暗号化解除される必要があります。
重要
SSL (Secure Sockets Layer) は、SQL Server 2016 (13.x) 以降では廃止されています。 代わりに TLS (TLS 1.2 をお勧めします) を使用してください。 詳細については、KB3135244 - Microsoft SQL Server での TLS 1.2 のサポートに関する記事を参照してください。 SQL Server 2022 では、TLS 1.3 のサポートが導入されています。 詳細については、TLS 1.3 サポートに関する記事を参照してください。 クライアント コンピューターとサーバー コンピューターの間に一致するプロトコルが存在しない場合は、「既存の接続がリモート ホストによって強制的に閉じられた」で説明されているエラーが発生する可能性があります。
デジタル証明書の概要
デジタル証明書は、ユーザーまたはコンピューターの ID を検証するためにオンライン パスワードのように動作する電子ファイルです。 これらは、クライアント側の通信に使用される暗号化チャネルを作成するために使用されます。 証明書は、証明機関 (CA) によって発行されるデジタル ステートメントであり、CA は、証明書の所有者の身元を保証し、当事者が暗号化を使用して安全に通信できるようにします。
デジタル証明書によって次のサービスが提供されます。
- 暗号化: 交換されるデータを盗難や改ざんから保護するのに役立ちます。
- 認証: 所有者 (ユーザー、Web サイト、さらにはルーターなどのネットワーク デバイス) が、主張しているとおりの人物またはものであることを検証します。 通常、認証は一方向であり、ソースはターゲットの ID を検証しますが、相互 TLS 認証もできます。
証明書には公開キーが含まれており、対応する秘密キーを保有するユーザー、コンピューター、またはサービスの ID にその公開キーを結合します。 公開キーと秘密キーはクライアントとサーバーで使用され、データを送信する前に暗号化します。 Windows のユーザー、コンピューター、サービスの場合、CA での信頼は、信頼できるルート証明書ストアにルート証明書が定義されており、証明書に有効な証明パスが含まれていると確立されます。 証明書は、取り消されていない (CA の証明書失効リストまたは CRL にない)、または有効期限が切れていない場合、有効と見なされます。
次の表に、主な 3 種類のデジタル証明書について説明します。
| Type | 説明 | 長所 | 短所 |
|---|---|---|---|
| 自己署名証明書 | 証明書は、それを作成したアプリケーションによって署名されるか、New-SelfSignedCertificate を使用して作成されます。 | コスト (無料) | - 証明書がクライアント コンピューターとモバイル デバイスによって自動的に信頼されることはありません。 証明書は、すべてのクライアント コンピューターとデバイスの信頼されたルート証明書ストアに手動で追加する必要がありますが、信頼されたルート証明書ストアへの変更がすべてのモバイル デバイスで許可されているわけではありません。 - すべてのサービスが自己署名証明書で動作するわけではありません。 - 証明書ライフサイクル管理のためのインフラストラクチャを確立することは困難です。 たとえば、自己署名証明書を取り消すことはできません。 |
| 内部 CA によって発行された証明書 | 証明書は、組織内の公開キー基盤 (PKI) によって発行されます。 例として Active Directory 証明書サービス (AD CS) があります。 詳しくは、「Active Directory 証明書サービスの概要」をご覧ください。 | - 組織が独自の証明書を発行できます。 - 商用 CA からの証明書よりも低コストです。 |
- PKI の展開と保守の複雑さが増します。 - 証明書がクライアント コンピューターとモバイル デバイスによって自動的に信頼されることはありません。 証明書は、すべてのクライアント コンピューターとデバイスの信頼されたルート証明書ストアに手動で追加する必要がありますが、信頼されたルート証明書ストアへの変更がすべてのモバイル デバイスで許可されているわけではありません。 |
| 商用 CA によって発行された証明書 | 証明書は、信頼された商用 CA から購入します。 | すべてのクライアント、デバイス、サーバーが証明書を自動的に信頼するため、証明書の展開が簡略化されます。 | コスト。 必要な証明書の数を最小限に抑えるために、事前に計画する必要があります。 |
証明書の所有者が主張しているとおりの人物であることを証明するには、証明書で他のクライアント、デバイス、またはサーバーに対して証明書の所有者を正確に識別する必要があります。 これを行う 3 つの基本的な方法を次の表に示します。
| メソッド | 説明 | 長所 | 短所 |
|---|---|---|---|
| 証明書のサブジェクトの一致 | 証明書の [サブジェクト] フィールドにホストの共通名 (CN) が含まれています。 たとえば、www.contoso.com に対して発行された証明書を Web サイト https://www.contoso.com に対して使用できます。 |
- すべてのクライアント、デバイス、サービスと互換性があります。 - コンパートメント化。 ホストの証明書を取り消しても、他のホストには影響しません。 |
- 必要な証明書の数。 指定したホストに対してのみ証明書を使用できます。 たとえば、サービスが同じサーバーにインストールされている場合でも、証明書 www.contoso.com を ftp.contoso.com に使用することはできません。- 複雑さ。 Web サーバーでは、各証明書に独自の IP アドレス バインドが必要です。 |
| 証明書のサブジェクトの別名 (SAN) の一致 | [サブジェクト] フィールドに加えて、証明書の [サブジェクトの別名] フィールドには、複数のホスト名の一覧が含まれています。 次に例を示します。www.contoso.comftp.contoso.comftp.eu.fabirkam.net |
- 利便性。 複数の異なるドメイン内の複数のホストに対して同じ証明書を使用できます。 - ほとんどのクライアント、デバイス、サービスで SAN 証明書がサポートされています。 - 監査とセキュリティ。 SAN 証明書を使用できるホストが正確にわかっています。 |
- より多くの計画が必要です。 証明書を作成するときは、ホストの一覧を指定する必要があります。 - コンパートメント化の欠如。 証明書内のすべてのホストに影響を与えずに、指定したホストの一部の証明書を選択的に取り消すことはできません。 |
| ワイルドカード証明書の一致 | 証明書の [サブジェクト] フィールドには、ワイルドカード文字 (*) と 1 つのドメインまたはサブドメインとして共通名が含まれています。 たとえば、*.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) 証明書では使用できません。 - 慎重な監査と制御が必要です。 ワイルドカード証明書が侵害された場合、指定したドメイン内のすべてのホストに影響します。 |