Red Hat Summit11.4. プロキシーサービスのセキュリティー保護
プロキシーノードには、少なくとも 2 つのインターフェイス (物理または仮想) が必要です。1 つはパブリック、および 1 つはプライベート。パブリックインターフェイスを保護するには、ファイアウォールまたはサービスのバインディングを使用できます。パブリック向けサービスは、エンドポイントのクライアント要求を処理し、認証を行い、適切なアクションを実行する HTTP Web サーバーです。プライベートインターフェイスにはリスニングサービスは必要ありませんが、代わりにプライベートストレージネットワーク上のストレージノードへの発信接続を確立するために使用されます。
11.4.1. HTTP リッスンポート
director は、root 以外のユーザー (UID 0 以外) で実行するように Web サービスを設定します。1024 より大きいポート番号を使用すると、Web コンテナーのいずれの部分も root として実行されなくなります。通常、HTTP REST API を使用する (そして自動認証を実行する) クライアントは、認証応答から必要な完全な REST API URL を取得します。OpenStack REST API により、クライアントはある URL に対して認証を行い、実際のサービス用に完全に異なる URL を使用するためにリダイレクトできます。たとえば、クライアントは https://identity.cloud.example.org:55443/v1/auth に対して認証を行い、認証キーおよび 、https://swift.cloud.example.org:44443/v1/AUTH_8980 のストレージ URL (プロキシーノードまたはロードバランサーの URL) を持つ応答を取得できます。
11.4.2. ロードバランサー
Apache を使用するオプションが実行できない場合や、パフォーマンス上の理由で TLS 作業をオフロードする場合は、専用のネットワークデバイスのロードバランサーを使用する場合があります。これは、複数のプロキシーノードを使用する場合に冗長性および負荷分散を提供する一般的な方法です。
TLS のオフロードを選択する場合は、ロードバランサーとプロキシーノード間のネットワークリンクがプライベート (V)LAN セグメント上にありるようにします。これにより、ネットワーク上の他のノード (セキュリティー侵害されている可能性がある) による非暗号化トラフィックの盗聴 (スニフィング) を防ぐことができます。このような侵害が発生した場合、攻撃者はエンドポイントクライアントまたはクラウド管理者の認証情報にアクセスし、クラウドデータにアクセスできるようになります。
使用する認証サービスは、エンドポイントクライアントへの応答で異なる URL を設定する方法を決定し、個別のプロキシーノードではなくロードバランサーを使用できるようにします。
