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 トランザクションでエンティティを識別するデジタルファイル。証明書は、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 を作成します。注: お客様用の CSR は Apigee によって自動的に作成されません。お客様がご自身で 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 エンドポイントをホストするサーバーであり、仮想ホストにデプロイされている API プロキシが TLS エンドポイントになります。その 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 エンドポイントをホストするサーバーであり、API プロキシが TLS エンドポイントになります。その API プロキシにアクセスしようとするアプリがクライアントです。このシナリオでは、Edge に証明書と秘密鍵が格納されたキーストアがあり、クライアントの証明書と CA チェーンを含むトラストストアも存在する必要があります。
クライアントとしての Edge

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

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

重要な点は、Edge では、その構成方法にかかわらず、双方向 TLS を柔軟にサポートできるということです。

Server Name Indication（SNI）のサポート

Edge では、API プロキシから Edge への Server Name Indication（SNI）と、Edge からターゲットエンドポイントへの SNI の使用がサポートされています。前者の場合、Edge は TLS サーバーとして機能します。後者の場合は、Cloud と Private Cloud のどちらのインストールにおいても、Edge は TLS クライアントとして機能します。

TLS / SSL の拡張機能である SNI を使用すると、複数の HTTPS ターゲットが、同じ証明書を使用せずに同じ IP アドレスとポートからサービスを提供できます。

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