Oracle Cloud Infrastructureドキュメント

LBaaSセキュリティ

Compute Cloud@Customerでは、ロード・バランサをサービスとして構成および保護できます(LBaaS)。

ロード・バランサ(LB)は、クライアントのアプリケーションと顧客のVCNを接続します。LBでは、デフォルトでTLS1.2が使用されます。Compute Cloud@CustomerのパブリックIPアドレスまたはプライベートIPアドレスを使用するようにLBを構成できます。

Compute Cloud@Customer LBでは、セキュリティにTLSおよびSSLが使用されます。LBは、次の3種類の接続のいずれかを使用して作成できます。
  • SSL終了:ロード・バランサは、着信SSLトラフィックを扱い、暗号化されていないリクエストをバックエンド・サーバーに渡します。
  • エンドツーエンド(ポイントツーポイント)SSL:ロード・バランサは、受信トラフィック・クライアントからのSSL接続を終了し、バックエンド・サーバーへの別のSSL接続を開始します。
  • SSLトンネリング:ロード・バランサ・リスナーがTCPトラフィック用に構成されている場合、ロード・バランサは受信SSL接続をアプリケーション・サーバーにトンネリングします。
LBは、次の2つのタイプのプロトコルで構成できます。
  • HTTP: HTTPまたはHTTPSを使用するLBは、LB自体でTLS接続を終了します。
  • TCP: TCPを使用するLBは、バックエンド・サーバーでTLS接続を終了します。

LBは、これらのタイプのプロトコルのIPアドレスをリスニングします。

LBaaSサービスの管理の詳細は、サービスとしてのロード・バランサを参照してください。

SSL証明書

Compute Cloud@Customerでは、LBaaSにセキュアな証明書を使用する必要があります。LBとそのリソースに標準SSLを使用するには、証明書を指定する必要があります。使用可能な証明書がない場合は、SSL証明書をアップロードできます。
ノート

関連付けるリスナーまたはバックエンド・セットを作成する前に、使用する証明書をアップロードしておくことをお薦めします。

Compute Cloud@Customer LBaaSでは、SSL証明書は生成されません。すでに所有している既存の証明書のみをインポートできます。証明書は、VerisignやGoDaddyなどのベンダーが発行したものにすることができます。また、OpenSSLやLet's Encryptなどのオープン・ソース・ツールを使用して生成する自己署名証明書を使用することもできます。自己署名証明書を生成する方法の手順は、対応するツールのドキュメントを参照してください。

バックエンドSSLの自己署名証明書を送信する場合は、対応するCA証明書フィールドに同じ証明書を送信する必要があります。

Compute Cloud@Customerは、x.509タイプの証明書をPEM形式でのみ受け入れます。次に、PEMエンコード証明書の例を示します:

-----BEGIN CERTIFICATE-----
<Base64_encoded_certificate>
-----END CERTIFICATE-----

証明書の詳細は、SSL証明書の管理を参照してください。

セキュリティ・リスト

Compute Cloud@Customerでは、VCNネットワーク・セキュリティ・グループ(NSG)またはセキュリティ・リストを使用して、ロード・バランサへのネットワーク・アクセスを制御します。この方法では、Compute Cloud@Customerに従来のLBファイアウォールと同様の機能が提供されます。ロード・バランサ・ルールを構成するには、LSGまたはLBのサブネット・セキュリティ・リストを構成します。

リスナーを作成する場合は、VCNセキュリティ・リストも更新して、そのLBリスナーへのトラフィックを許可する必要があります。

次のことができるように、セキュリティ・リストのイングレス・ルールを編集する必要があります:

  • ソースCIDR (LBを使用してネットワークをカバーするブロックを入力します)。0.0.0.0/0を指定できます。)

  • プロトコルTCP

  • 宛先ポート範囲80 (リスナー・ポート)

他のリスナーを作成した場合は、各リスナー・ポートのイングレス・ルールを追加して、トラフィックがリスナーに到達できるようにする必要があります。たとえば、ポート443でリスナーを作成した場合は、ポート443のトラフィックを許可する必要があります。

NSGおよびセキュリティ・リストの詳細は、セキュリティ・リストを使用したトラフィックの制御およびネットワーク・セキュリティ・グループを使用したトラフィックの制御を参照してください。

バックエンド・サーバーのセキュリティ

Compute Cloud@Customer上のパブリックLBの場合、パブリックLBのトラフィックのみを受け入れるように、バックエンド・サーバーのVCN NSGまたはセキュリティ・リストを構成する必要があります。バックエンド・サーバー・サブネットで使用されるセキュリティ・リストを更新して、LBサブネットからのイングレス・トラフィックを許可できます。

たとえば、LBがサブネット10.0.4.0/24にあり、Webサーバーのトラフィックのバランシングを行う場合は、TCPプロトコル、すべてのソース・ポートおよび宛先ポート80を使用して、ソースIPアドレス10.0.4.0/24からのトラフィックを許可するステートフル・イングレス・ルールを追加する必要があります。この新しいルールでは、LBサブネットからのイングレス・トラフィックが許可されます。

VCNサブネット・セキュリティ・リスト(NSGが使用されている場合はNSG)をNSGに関連付けることができ、LB、リスナーおよびバックエンドの作成後に更新する必要があります。通常、ロード・バランサはバックエンド・サーバーとは異なるサブネットに作成されます。たとえば、パブリック・サブネットで作成されたパブリックLBは、トラフィックをプライベート・サブネット内のバックエンド・サーバーに転送します。

ただし(推奨されませんが)、LBはバックエンド・サーバーと同じサブネットに作成できます。いずれの場合も、LBおよびバックエンド・サーバーを含むすべてのサブネットのセキュリティ・リストを更新する必要があります。

LBサブネットの場合、セキュリティ・リスト(NSG)を更新して、ロード・バランサから各バックエンド・サーバーのサブネットへのエグレス・トラフィックを許可する必要があります。たとえば、バックエンド・サーバーがSubnet1 (10.0.1.0/24)およびSubnet2 (10.0.0.0/24)にある場合、LBサブネットのセキュリティ・リストの更新は次のようになります:
  • Subnet1上のバックエンド・サーバーへのエグレス・トラフィックを許可します

  • Subnet2上のバックエンド・サーバーへのエグレス・トラフィックを許可します

バックエンド・サブネットへのエグレス・トラフィックを許可する更新に加えて、リスナーがトラフィックを受け入れることができるように更新する必要があります。たとえば、パブリックLBがポート80上の任意の場所からのトラフィックをLBに到達することを許可する場合は、LBをホストするサブネットに次のイングレス・ルールを追加する必要があります。
  • ソース・タイプ: CIDR
  • ソースCIDR: 0.0.0.0/0
  • IPプロトコル: TCP
  • 宛先ポート範囲: 80 (リスナー・ポート)

LBがサブネット10.0.4.0/24にある場合、ロード・バランサ・サブネットからのイングレス・トラフィックを許可するには、バックエンド・サーバー・サブネットで使用されるセキュリティ・リストに対するステートフル・ルールの更新が必要です:

  • ソース・タイプ: CIDR
  • ソースCIDR: 10.0.4.0/24
  • IPプロトコル: TCP
  • 宛先ポート範囲: 80 (リスナー・ポート)

この新しいステートフル・イングレス・ルールにより、TCPトラフィックがバックエンド・サーバーに到達できるようになります。ステートフルな性質は、応答を許可します。

最後に、すべてのエグレス・ルールを削除します。バックエンド・サーバーにはエグレス・ルールを設定できません。

ルート表に関する考慮事項

Compute Cloud@Customerでは、VCNルート表はリクエストをLBの様々なバックエンド・セットにルーティングする必要があります。仮想ホスト名をリスナーに割り当てるか、この目的でルート・ルールを作成できます。

これらのLBのトピックの詳細については、次を参照してください。

ルート表の一般的な構成の詳細は、「ルート表の使用」を参照してください。