TLS / SSL について

TLS(Transport Layer Security、前身は SSL)は、ウェブサーバーとウェブ クライアント(ブラウザやアプリなど)の間で、暗号化されたリンクを確立するための標準的なセキュリティ テクノロジーです。暗号化されたリンクにより、サーバーとクライアントの間で送受信されるすべてのデータに対して機密性が確保されます。TLS を使用するには、クライアントは、暗号化されていない http プロトコルではなく、暗号化された https プロトコルを使用して、セキュリティで保護されたリクエストをサーバーに送信します。

Edge では、クラウドとオンプレミス デプロイの両方で、一方向 TLS と双方向 TLS がサポートされています(サポートされている TLS のバージョンについてはサポートされているソフトウェアとサポートされているバージョンをご覧ください)。一方向 TLS では、TLS クライアントが TLS サーバーの ID を確認できます。たとえば、Android スマートフォン(クライアント)で実行されているアプリは Edge API(サーバー)の ID を確認できます。

Apigee では、双方向(またはクライアント)TLSを使用した、より強力な認証形態もサポートされています。お客様は、通常、エンドツーエンドでセキュリティを強化して、クライアントのなりすましや中間者攻撃などのクライアント攻撃からデータを保護するために、双方向 TLS を実装します。双方向 TLS では、クライアントがサーバーの ID を確認した後、サーバーがクライアントの ID を確認します。

TLS の用語

TLS を構成する前に、以下の重要な用語とコンセプトについて十分に理解している必要があります。

用語

定義

TLS 証明書

TLS トランザクションでエンティティを識別するデジタルファイル。証明書(または「cert」)は、TLS 構成に応じて TLS サーバーや TLS クライアントを識別するために使用できます。

自己署名証明書

信頼できる CA によって署名されていない証明書。発行元とサブジェクトが同一であり、証明書に含まれている公開鍵と一致する秘密鍵で署名されています。

証明書チェーン

お客様が CA のルート秘密鍵で署名されている証明書を持っていないことはよくあります。代わりに、チェーンを形成する 1 つまたは複数の中間証明書とともに、自分の証明書を持っています。通常、そのチェーンの最後の中間証明書は、CA のルート秘密鍵で署名されます。

認証(CA)

証明書の発行や証明書の信頼性の検証に使用される、信頼できるエンティティ(Symantec や VeriSign など)。自己署名証明書と呼ばれるタイプの証明書では CA は要求されません。

公開鍵

TLS クライアントから TLS サーバーに送信されるデータを暗号化するために使用されます。公開鍵は証明書に含まれています。すべての TLS クライアントはサーバーの公開鍵のコピーを持っています。

秘密鍵

データを復号するために TLS サーバーで使用されます。秘密鍵は TLS サーバーのみが持ちます。秘密鍵は TLS クライアントと共有されません。

CSR

Certificate Signing Request(CSR)は、TLS サーバー上で秘密鍵に基づいて生成されるファイルです。CSR には公開鍵と、組織の名前、ロケーション、ドメイン名などの情報が含まれています。CA は CSR に署名して TLS 証明書を作成します。通常、お客様が期限切れの証明書を更新する場合に CSR を作成します。

注: Apigee ではお客様に代わって CSR を作成しません。お客様が CSR を作成する必要があります。詳しくは、秘密鍵を作成して CSR を生成する方法をご覧ください。

キーストア

TLS handshake でエンティティを識別するために使用される、TLS 証明書と秘密鍵が格納されます。

トラストストア

クライアントに提示されている TLS サーバーの証明書を検証するために使用される、TLS クライアント上の信頼済み証明書が格納されます。通常、これらの証明書は自己署名証明書、または信頼できる CA によって署名されていない証明書です。

PEM ファイル

証明書、証明書チェーン、秘密鍵を格納するための X.509 形式に準拠しているテキスト ファイル。証明書や秘密鍵が PEM ファイルとして定義されていない場合は、openssl などのユーティリティを使用して PEM ファイルに変換できます。

PKCS12/PFX ファイル

証明書、中間証明書、秘密鍵を 1 つの暗号化可能ファイルに格納するためのバイナリ ファイル形式。一般的に、PFX ファイルの拡張子は、.pfx や .p12 になります。PFX ファイルは、通常、Windows マシンで証明書や秘密鍵をインポートまたはエクスポートするために使用します。

Server Name Indication(SNI)

複数の HTTPS ターゲットが、同じ証明書を使用することなく、同じ IP アドレスとポートでサービスを受けることができます。

一方向 TLS/SSL

次の図は、TLS クライアントと TLS サーバーの間での一方向認証の TLS/SSL handshake を示しています。

一方向 TLS 構成の場合:

  • クライアントがサーバーへのセッション リクエストを発行します。
  • サーバーは、サーバーの公開鍵が含まれている証明書付きのレスポンスを返します。この証明書はサーバーのキーストアから取得されます。キーストアにはサーバーの秘密鍵も入っています。その秘密鍵がクライアントに送信されることはありません。
  • 署名付き証明書の場合、クライアントはその証明書を認証するように認証局(CA)にリクエストします。
  • クライアントとサーバーはキーを検証するために何度かメッセージをやり取りします。
  • クライアントがサーバーとの TLS データ転送を開始します。

次の図は、オプションのトラストストアをクライアント上で使用している TLS/SSL handshake を示しています。

TLS サーバーが自己署名証明書、または信頼できる CA によって署名されていない証明書を使用している場合は、クライアント上にトラストストアを作成します。クライアントは、自分が信頼しているサーバー証明書と公開鍵をトラストストアに入れます。クライアントは証明書を受信すると、受信した証明書をトラストストア内の証明書と照合して検証します。

一方向 TLS では、Edge はサーバーまたはクライアントのいずれかになることができます。

  • TLS サーバーとしての Edge

    Edge は、TLS エンドポイントをホストするサーバーであり、TLS エンドポイントは仮想ホストにデプロイされている API プロキシに相当します。その API プロキシにアクセスしようとするアプリがクライアントです。このシナリオでは、Edge には証明書と秘密鍵が入っているキーストアがあります。
  • TLS クライアントとしての Edge

    Edge はバックエンド サービスにアクセスするクライアントして機能します。この場合、バックエンド サービスは TLS エンドポイントをホストしているサーバーに相当します。したがって、バックエンド サーバーにはその証明書と秘密鍵が含まれたキーストアがあります。

双方向 TLS

次の図は、クライアントとサーバーの間での双方向 TLS 認証の TLS/SSL handshake を示しています。

双方向 TLS の場合:

  • クライアントとサーバーの両方にそれぞれのキーストアがあります。クライアントのキーストアにはそれ自体の証明書と秘密鍵が含まれ、サーバーのキーストアにはそれ自体の証明書と秘密鍵が含まれています。
  • TLS サーバーは認証を受けるために、それ自体の証明書を TLS クライアントに提示します。クライアントは、それ自体の証明書をサーバーに送信する前に、サーバーの ID を確認します。
  • TLS クライアントは、サーバーから認証を受けるために、それ自体の証明書を TLS サーバーに提示します。

次の図は、オプションのトラストストアを使用している TLS handshake を示しています。

このシナリオの場合:

  • TLS サーバーが自己署名証明書、または信頼できる CA によって署名されていない証明書を使用している場合は、クライアント上にトラストストアを作成します。クライアントのトラストストアにはサーバーの証明書のコピーが入っています。TLS handshake 中に、クライアントでは、それ自体のトラストストアにある証明書と、サーバーから送信された証明書を比較して、サーバーの ID を確認します。
  • TLS クライアントが自己署名証明書、または信頼できる CA によって署名されていない証明書を使用している場合は、サーバー上にトラストストアを作成します。サーバーのトラストストアにはクライアントの証明書のコピーが入っています。TLS handshake 中に、サーバーでは、それ自体のトラストストアにある証明書と、クライアントから送信された証明書を比較して、クライアントの ID を確認します。

クライアントとサーバーのいずれかだけがトラストストアを使用することも、両方が使用することもできます。

双方向 TLS では、Edge はサーバーまたはクライアントのいずれかになることができます。

  • サーバーとしての Edge

    Edge は、TLS エンドポイントをホストするサーバーであり、TLS エンドポイントは API プロキシに相当します。その API プロキシにアクセスしようとするアプリがクライアントです。このシナリオでは、Edge には証明書と秘密鍵が含まれたキーストアがあり、クライアントの証明書と CA チェーンが含まれているトラストストアが要求されます。
  • クライアントとしての Edge

    Edge はバックエンド サービスにアクセスするクライアントとして機能します。この場合、バックエンド サービスは TLS エンドポイントをホストしているサーバーに相当します。したがって、バックエンド サーバーにはその証明書と秘密鍵が含まれたキーストアがあります。

    Edge では、バックエンド サービスでそれ自体を検証するための証明書が入っているキーストアも定義されている必要があります。また、バックエンド サーバーが自己署名証明書、または信頼できる CA によって署名されていない証明書を使用している場合は、バックエンド サーバーからの証明書が入っているトラストストアを定義することもできます。

どのように構成することにしたとしても、Edge はその高い柔軟性により双方向 TLS をサポートできることを覚えておくことが重要です。

Server Name Indication(SNI)のサポート

Edge では、API プロキシから Edge へ(Edge は TLS サーバーとして機能する)、および Edge からターゲット エンドポイントへ(Cloud と Private Cloud の両方のインストールで Edge は TLS クライアントとして機能する)の Server Name Indication(SNI)の使用がサポートされています。

TLS/SSL の拡張機能である SNI を使用すると、複数の HTTPS ターゲットが、同じ証明書を使用することなく、同じ IP アドレスとポートでサービスを受けることができます。

オンプレミス インストールでの SNI を有効化については、Edge での SNI の使用をご覧ください。