LBaaSセキュリティ
Compute Cloud@Customerでは、Load Balancer as a Service (LBaaS)を構成および保護できます。
ロード・バランサ(LB)は、クライアントのアプリケーションと顧客のVCNを接続します。LBでは、デフォルトでTLS1.2が使用されます。Compute Cloud@CustomerのパブリックIPアドレスまたはプライベートIPアドレスを使用するようにLBを構成できます。
- SSL終了:ロード・バランサは、受信SSLトラフィックを処理し、暗号化されていないリクエストをバックエンド・サーバーに渡します。
- エンドツーエンド(ポイントツーポイント) SSL:ロード・バランサは、受信トラフィック・クライアントからのSSL接続を終了してから、バックエンド・サーバーへの別のSSL接続を開始します。
- SSLトンネリング:ロード・バランサ・リスナーがTCPトラフィック用に構成されている場合、ロード・バランサは、受信SSL接続をアプリケーション・サーバーにトンネルします。
- 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のサブネット・セキュリティ・リストを構成します。リスナーを作成する場合、そのLBリスナーへのトラフィックを許可するようにVCNセキュリティ・リストも更新する必要があります。
-
ソースCIDR (LBを使用してネットワークをカバーするブロックを入力します。0.0.0.0/0にできます。)
-
プロトコルTCP
- 宛先ポート範囲80 (リスナー・ポート)
他のリスナーを作成した場合は、各リスナー・ポートにイングレス・ルールを追加して、トラフィックがリスナーに到達できるようにする必要があります。たとえば、ポート443にリスナーを作成した場合、ポート443のトラフィックを許可する必要があります。
NSGおよびセキュリティ・リストの詳細は、セキュリティ・リストを使用したトラフィックの制御およびネットワーク・セキュリティ・グループを使用したトラフィックの制御を参照してください。
バックエンド・サーバーのセキュリティ
Compute Cloud@Customer上のパブリックLBの場合、バックエンド・サーバーのVCN NSGまたはセキュリティ・リストを構成して、パブリックLBのトラフィックのみを受け入れる必要があります。バックエンド・サーバー・サブネットで使用されるセキュリティ・リストを更新して、LBサブネットからのイングレス・トラフィックを許可できます。たとえば、LBがサブネット10.0.4.0/24にあり、Webサーバーのトラフィックのバランシングを行う場合、ソースIPアドレス10.0.4.0/24からのトラフィック、TCPプロトコル、すべてのソース・ポートからのトラフィック、および宛先ポート80へのトラフィックを許可するステートフル・イングレス・ルールを追加する必要があります。この新しいルールは、LBサブネットからのイングレス・トラフィックを許可します。
VCNサブネット・セキュリティ・リスト(またはNSG(使用する場合))はNSGに関連付けることができ、LB、リスナーおよびバックエンドの作成後に更新する必要があります。通常、ロード・バランサはバックエンド・サーバーとは異なるサブネットに作成されます。たとえば、パブリック・サブネットで作成されたパブリックLBは、プライベート・サブネット内のバックエンド・サーバーにトラフィックを転送します。
ただし(推奨されませんが)、LBはバックエンド・サーバーと同じサブネットに作成できます。どちらの場合も、LBおよびバックエンド・サーバーに関連するすべてのサブネットのセキュリティ・リストを更新する必要があります。
- Subnet1上のバックエンド・サーバーへのエグレス・トラフィックを許可します
-
Subnet2上のバックエンド・サーバーへのエグレス・トラフィックを許可します
- ソース・タイプ: 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の様々なバックエンド・セットにルーティングする必要があります。仮想ホスト名をリスナーに割り当てたり、この目的でルート・ルールを作成したりできます。
一般的なルート表の構成の詳細は、ルート表の使用を参照してください。