Application Load Balancer を SAP Enterprise Portal に活用

はじめに

SAP Enterprise Portal (EP) などの SAP Java アプリケーションでは、HTTP(s) 要求のエントリポイントとして SAP Web ディスパッチャを使用します。SAP Web ディスパッチャは、インターネットまたはイントラネットからの要求を受信し、アプリケーションサーバー間で要求を分散します。インターネットベースの HTTP(s) リクエストの場合、SAP Web Dispatcher はインターネットにアクセスできる必要があるため、パブリックサブネットにインストールする必要があります。多くの SAP のお客様は、アタックサーフェスを減らすためにパブリックサブネットに EC2 インスタンスを設置することを避けています。

このブログでは、SAP EP アプリケーションに Elastic Load Balancing（ELB）を使用する方法について説明します。SAP EP アプリケーションは、HTTP リクエストの負荷分散に Application Load Balancer（ALB）を使用します。SAP Web dispatcher とは異なり、ALB はサーバーレスサービスであり、AWS によるマネージドサービスです。SAP EP に HTTP トラフィックを提供するインターネットに面した ALB を構成することができます。ALB では、既知の脆弱性に対処するための AWS Web Application Firewall（WAF）、コンテンツ高速化のための Amazon CloudFront、TLS/SSL 証明書を管理するための AWS Certificate Manager（ACM）と統合することができます。

Application Load Balancer とその特徴

ALB は可用性の高いサービスで、クライアントからの HTTP(s) リクエストを受け取り、ルールに基づいてターゲットグループに振り分けます。各ターゲットグループには、SAP EP の単一または複数のアプリケーションサーバーの IP アドレスまたは EC2 インスタンス ID と HTTP ポートの組み合わせが含まれます。HTTP(s) リクエストは ALB によってアプリケーションサーバーに転送されます。

ALB は以下の SAP EP の要件を満たすことができます。

可用性が高く、複数のアベイラビリティゾーン（AZ）にリクエストを分散できる、レイヤー 7 の HTTP（s）ロードバランシングサービス。
高セキュリティ、高信頼性、スケーラブルなマネージド AWS サービスであり、手動でのサーバーメンテナンスが不要（サーバーレス）。
HTTP(s) リクエストは、ホストおよび/またはポートベースのマッピングに基づいて、複数のアプリケーションサーバーに転送することができます。
TLS/SSL 暗号化オフロード。ALB は SSL 証明書と連携してロードバランサーとクライアント間のトラフィックを暗号化します。受信トラフィックは、SAP アプリケーションをホストする EC2 インスタンスに到達する前に、アクセス制御リスト（ACL）に対する厳格なチェックを通過しなければなりません。
Simple and Protected GSS-API Negotiation（SPNEGO）と Security Assertion Markup Language（SAML）によるシングルサインオン（SSO）をサポートし、Active Directory などのアイデンティティプロバイダと認証します。
HTTP リクエストフィルタリング。WAF は、このブログで紹介した SQL インジェクションのような Open Web Application Security Project (OWASP) の攻撃に対する追加のセキュリティ・レイヤーとして、ALB と共に使用することができます。WAF はまた、ACL とルールの形でトラフィック検査とフィルタリングルールのサポートを提供します。ドキュメントに従って、WAF でカスタムルールを定義することもできます。
SSL 証明書の管理。ACM は、このドキュメントで説明されているように、SSL/TLS 証明書を管理するために使用することができます。

アーキテクチャ

1) SAP EP のシングル ALB アーキテクチャ

複数の SAP アプリケーションサーバー間で負荷を分散するために、単一の ALB を使用することができます。ALB は、インターネットに面したものでも、イントラネットに面したものでもかまいません（内部 ALB とも呼ばれます）。ダイレクト・コネクトまたは仮想プライベート・ネットワーク（VPN）を介して顧客のネットワークから到着する HTTP（s）リクエストに対して、「内部」ALB はリクエストを転送し、アプリケーション・サーバーに負荷分散します。しかし、顧客がインターネットから SAP EP へのアクセスを許可したい場合、図 1 の右側の図のように、パブリックサブネット上のインターネットに面した ALB が必要になります。

図 1：左：SAP EP の単一内部 ALB アーキテクチャ、右：SAP EP の単一インターネット ALB アーキテクチャ

2) SAP EP の ALB サンドイッチ・アーキテクチャ

図 2：SAP EP の ALB サンドイッチ・アーキテクチャ

図 2 に示すように、インターネットに面した ALB をパブリックサブネットに、2つ目の内部 ALB をプライベートサブネットに配置することで、2 つの ALB を組み合わせることができます。このような配置は、SAP アプリケーションのサブネットがインターネットに露出しないため、爆発半径を小さくすることができ、AWS Well-Architected Framework と整合して耐障害性を確保しながら、アーキテクチャをよりセキュアにすることができます。

アーキテクチャの説明

パブリックサブネットがネットワークアカウントにあり、プライベートサブネットが AWS 本番アカウントにある 2 アカウント戦略が考えられます。同じアーキテクチャを 1 つのアカウントでデプロイすることもできます。
ネットワークアカウントはインターネットにアクセスできますが、AWS 本番アカウントはインターネットに直接アクセスできません。これにより、AWS 本番アカウントはよりセキュアになります。
2 つの ALB を考えました。Network アカウントの ALB は、SAP EP 用のインターネットに面した ALB です。これはインターネット（外部）ユーザーにサービスを提供し、それはイントラネット（内部）ユーザーにサービスを提供するイントラネットに面した（内部）ALB に接続されています。
図 2 では、可用性と回復力を向上させるために、複数の AZ と Amazon EC2 Auto Scaling グループに分散した VM シリーズのファイアウォールを使用しています。
このようなサンドイッチ・アーキテクチャは、インバウンド・トラフィックのファイアウォール検査の要件に対応するために使用されます。トラフィックはまず、VM シリーズ・ファイアウォールの Auto Scaling Group のフロントエンドとして使用される ALB を通過する。各ファイアウォールの宛先は、その背後にターゲットグループ（この場合は EC2 インスタンス）を含む ALB です。このアプローチにより、セキュリティ検査層とウェブフロントエンド層の両方が、互いに独立したコスト効率の良い方法でスケールイン/スケールアウトできるようになります。詳細はこちらのブログを参照してください。

インターネットに面した ALB の構成

インターネットに面した ALB は HTTP または HTTPS トラフィックをリッスンするように設定されます。セキュリティを向上させるために HTTP ポート 80 を HTTPS ポート 443 にルーティングします。
デフォルトのセキュリティポリシー ELBSecurityPolicy-2016-08 は、TLSv1.2 をサポートしているので、インターネットに面したロードバランサーと内部のロードバランサーの両方に推奨されるポリシーです。
HTTPS リスナーについては、ACM 証明書またはサードパーティ証明書を使用して、ALB 上に 1 つの SSL/TLS サーバー証明書をデプロイする。

フローは以下の通りである：

トラフィックはインターネットに面した ALB で受信されます。
ALB はトラフィックをファイアウォール・インスタンス・ベースのターゲット・グループに転送します。
ファイアウォールインスタンスでは、静的ネットワークアドレス変換（NAT）またはポート間 NAT ポリシーが内部 ALB にトラフィックをルーティングするために使用されます。
内部 ALB はファイアウォールからトラフィックを受信します。

内部 ALB の設定

ポート 80 は、ファイアウォールを経由してルーティングされた、インターネットに面した ALB からの着信要求をリッスンする HTTP ポートとして定義されています。
ポート 443 は、企業ネットワーク内で SAP EP に直接アクセスするユーザーをリッスンする HTTPS ポートとして定義されています。
デフォルトのセキュリティポリシー ELBSecurityPolicy-2016-08 は、TLSv1.2 をサポートしているため、インターネットに面したロードバランサーと内部のロードバランサーの両方に推奨されるポリシーです。
HTTPS リスナーについては、ACM 証明書またはサードパーティ証明書を使用して、ALB 上に 1 つの SSL/TLS サーバー証明書を展開します。

図 3 内部 ALB リスナー

内部 ALB のターゲットグループ

SAP EP アプリケーションサーバーのすべての IP アドレスがターゲットグループに追加されます。EC2 インスタンスを追加することもできる一方、EC2 インスタンス ID は障害による終了時に変更される可能性があり、新しいインスタンスがその代わりになる可能性があるため、「IP アドレス」をターゲットとして追加することが望ましい。

図4 内部ALBのSAP EPのターゲットグループ

SAP EP のターゲットグループの属性

Stickiness Type	Application cookie[app_cookie]
Stickiness Duration	17 hours
App cookie name	saplb_*

図 5：SAP EP のスティッキネス属性

SAP EP は、アプリケーションベースのスティッキネスを有効にする必要があります。これは、ステートフルなユーザー・セッションをサポートするために、後続のリクエストを関連するアプリケーション・サーバーに渡すために必要です。バックエンドの SAP EP が saplb_* クッキーを追加し、ALB がその値をコピーして AWSALBAPP-* クッキーと呼ばれる別のクッキーを作成することを確認する必要があります。スティッキネス期間は、ユーザのセッションが常に ALB によって特定のアプリケーションサーバにルーティングされることを保証するのに十分でなければなりません。これは要件に基づいて調整できます。営業時間または 1 日を推奨します。

リスナールール

リスナーは、設定したプロトコルとポートを使用して接続要求をチェックするプロセスです。ALB を作成するときにリスナーを定義し、いつでもロードバランサーにリスナーを追加できます。例えば、図 3 に示すように、内部 ALB に 2 つのリスナーを定義しました：

インターネットに面した ALB から到着するトラフィック用の HTTP 80
HTTPS 443 社内ネットワークから来るトラフィック用

リスナーのリスナールールは、ALB が登録されたターゲットにどのようにリクエストをルーティングするかを決定する。各ルールは、優先度、1 つ以上のアクション、および 1 つ以上の条件で構成されます。詳細については、このドキュメントを参照してください。

内部 ALB リスナールール

以下の表は、ALB でのルールと設定の例を示しています。

ルール番号	Internal ALB Listener –Port 443 (Rule for internet traffic/internet facing ALB forward)	Internal ALB Listener – Port 80 (Rule for intranet traffic)	Corresponding SAP Web Dispatcher Rule
5	If Source IP is 10.0.0.0/8 OR 192.168.138.0/23 PATH is /webdynpro/dispatcher/sap.com/tc~sec~ume~wd~umeadmin/ Then Forward to sap-ep-prod-alb-tg: 1(100%)	If PATH is /webdynpro/dispatcher/sap.com/tc~sec~ume~wd~umeadmin/ “Return Fixed Response- This Feature is Blocked over Internet”	#User Administrator if %{PATH} regimatch ^/webdynpro/dispatcher/sap.com/tc~sec~ume~wd~umeadmin(.) [and] If %{REMOTE_ADDR} !regimatch 10(.) [and] %{REMOTE_ADDR} !regimatch 192.168.138(.) [and] %{REMOTE_ADDR} !regimatch 192.168.139(.) RegForbiddenURL ^/webdynpro/dispatcher/sap.com/tc~sec~ume~wd~umeadmin(.*) – [break]
6	If PATH is /webdynpro/dispatcher/sap.com/tc~sec~ume~wd~umeadmin/ “Return Fixed Response- This Feature is Blocked over Internet”

上記の 2 つのリスナールール 5 と 6 は、ユーザー管理エンジン（UME）管理者がシステム管理者の内部からのみアクセスできることを保証します。

ルール 5 は、社内サブネット範囲 10.0.0.0/8 または 192.168.138.0/24 または 192.168.139.0/24 内の IP アドレスからの UME 管理者へのアクセスを許可することを示します。

ルール 6 は、UME Admin がその他の IP アドレスからのアクセスを許可されていないことを示します。

図 6：ALB 内部 HTTP リスナーポート 443 の設定

インターネットに面した ALB リスナーのルール

HTTP 要求がポート 443 でリッスンしているインターネット向け ALB に到達すると、インターネット向け ALB のターゲットグループとして定義されている内部 ALB にトラフィックを転送します。

リスナー・ルールに従って、インターネットから UME Admin へのリクエストがあると、図 7 と図 8 のようにブロックされます。

図 7: 内部 ALB HTTP リスナー・ポート 80 の設定

図 8：インターネットからユーザ管理 URL にアクセスしようとした結果

ALB の属性とセキュリティに関する考慮事項

ALB が無効なパケットをドロップし、有効でないヘッダーフィールドを持つ HTTP ヘッダーがロードバランサーによって削除されるように ALB が設定されていることを確認することを推奨します。
TLS 1.1 は TLS 1.1 と比較してセキュリティが強化されているため、ALB レベルでは TLS 1.2 が有効です
EC2 のオートスケーリングが計画されている場合は、削除保護を無効にする必要がある。
アイドルタイムアウトは、SAP アプリケーションの処理タイムアウトと同じかそれ以上でなければなりません。デフォルトでは、SAP EP のタイムアウトは 600 秒で、これをインターネットとイントラネットの両方の ALB に組み込む必要があります。

インターネット経由で SAP EP 経由で SAP ECC バックエンドコンテンツにアクセスするための ALB サポート

ALB が SAP EP への接続をサポートし、インターネット経由で SAP EP から SAP ECC バックエンドにリダイレクトできるようにしたいと考えています。オープンネットワーク上で SAP EP から SAP ECC バックエンドへのトラフィックの流れの詳細については、この SAP ブログをご覧ください。

一部のお客様には、インターネットトラフィックの完全修飾ドメイン名 (FQDN) とポートの組み合わせを 1 つだけ許可する厳しいポリシーがあります。このような場合、複数の SAP システム間で負荷を分散するには、コンテキストベースまたはパスベースのマッピングが必要です。たとえば、顧客がポート 443 を持つ外部 ALB を 1 つだけ許可していて、SAP EP と SAP Fiori への接続を許可する必要がある場合、リスナールールの条件には、SAP EP の場合は「/irj/portal」または「/nwa」、SAP Fiori の場合は「/fiori」によるマッピングが必要です。ALB が 1 つしかない場合、特に「/icon」、「/sap」などの共通コンテンツでは、パスの競合が発生する可能性があります。そのため、インターネットユーザーやイントラネットユーザー向けに設計するには、複数の SAP ソリューションに対して 2 つ以上の ALB を組み合わせることをお勧めします。

次のアーキテクチャは、コンテキストベースのマッピングに使用される 2 組の ALB を示しています。1 組は SAP EP 用、もう 1 組は SAP ECC がそれぞれのアプリケーションにアクセスするためのものです。

図 9: インターネット経由で SAP EP から SAP ECC コンテンツにアクセスするためのマルチ ALB アーキテクチャ

インターネット経由で SAP EP 経由で SAP ECC 機能を利用するという目標を達成するために、2 組の ALB を検討しました。ペア 1 には、前述の SAP EP で説明したアーキテクチャを備えたインターネット向けの ALB と内部 ALB が含まれています。ペア 2 には、SAP ECC システム用のインターネット向け ALB と内部 ALB のセットがもう 1 つ含まれています。

SAP ECC webdynpro URL にはインターネット経由で直接アクセスせず、SAP EP または同じドメインのシステムからのみアクセスできるようにする必要があります。

これは、図 10 に示すように、SAP ECC のインターネット向け ALB にリスナールールを実装することで実現されます。このルールでは、「HTTP ヘッダーリファラー」フィールドにより、ECC サービスには ess-ep.example.com ALB FQDN からのみアクセスでき、インターネット経由の ECC サービスへの直接アクセスは HTTP 応答 402 でブロックされます。

図 10: ECC ALB リスナールールの HTTP ヘッダーリファラー

SAP ERP の内部 ALB には、リスナーポート 443 を介して直接アクセスできるため、社内ネットワークから直接アクセスすることも、SAP EP から参照することもできます。

図 11: SAP EP の ESS iView

図 12: システムエイリアス設定

たとえば、インターネットユーザーは、SAP EP ALB ベースのポータル URL https://ess-ep.example.com/irj/portal にログインして、SAP ECC 上で稼働する従業員セルフサービス (ESS) webdynpro アプリケーションにアクセスできます。このアプリケーションは、図 11 に示すように https://ess-ecc.example.com/sap/bc/webdynpro/ZHRESS にある SAP ECC ALB を使用してセットアップされています。

SAP ECC の「システムエイリアス」は、SAP ECC ALB FQDN で定義されています。これにより、図 12 に示すように、https://<EP-ALB URL >/irj/portal-> システム管理-> システムランドスケープまで SAP EP からの直接 SSO が可能になります。SAP ECC のインターネットトランザクションサーバー (ITS) ホスト名とアプリケーションサーバーホスト名は、SAP ECC ALB FQDN で定義されています。

予想される HTTP リクエストフロー:

ユーザーはまず SAP EP ポータルの URL にアクセスし、/irj/portal を開きます。
リクエストは VM シリーズのファイアウォールを通過する前に、インターネットに直接接続されている SAP EP ALB に到達します。
その後、SAP EP の内部 ALB に転送され、最後に SAP EP アプリケーションサーバに転送されます。
SAP EP 内に入ると、ユーザーが ESS タブをクリックすると、リクエストは SAP ECC のインターネットに直接接続された ALB にリダイレクトされます。
その後、リクエストは VM シリーズのファイアウォールに送信され、SAP ECC 内部 ALB に到達してリスナールールを検証します。
一致条件に基づいて、トラフィックを SAP ECC ターゲットグループに送信して SAP ECC アプリケーションサーバーに到達します。

ユーザーがインターネット経由で SAP ECC webdynpro URL に直接アクセスしようとすると、アクセスは拒否されます。これは、図 10 に示すように、ルールに示されている「リファラー」である SAP EP ALB が ECC ALB にアクセスする唯一の方法だからです。

HTTP リファラーは外部 ALB 側にしか実装されていないため、イントラネットユーザーが内部 ALB に直接接続しても、URL に直接または間接的にアクセスしても問題はありません。

ALB パフォーマンス分析とトラブルシューティング

ALB のパフォーマンスをモニタリングするには、Amazon CloudWatch コンソール、メトリックスに移動して目的の ALB を選択するか、EC2 コンソール-> 負荷分散-> ターゲットグループに移動し、目的のターゲットグループを選択して [モニタリング] タブをクリックします。詳細については、次の AWS ドキュメントを参照してください。以下は ALB の CloudWatch メトリクスの図の例で、インドの営業時間のピーク時に 30 分間、リクエスト数が 1500 ～ 2000 リクエストだった場合の平均「目標応答時間」が約 150 ～ 200 ミリ秒であることを示しています。

図 13: Amazon クラウドウォッチ ALB パフォーマンスメトリックス

このナレッジベースを参照して、高レイテンシーまたはタイムアウトの問題による ALB パフォーマンスのトラブルシューティングを行うことができます。SAP EP に関連する問題を絞り込んだら、ICM ログまたはデフォルトトレースで手がかりがないか確認してください。このような問題を解決するには、SAP Note 2579836 を確認してください。

結論

このブログ記事では、SAP EP アプリケーション用の ALB のユースケース、アーキテクチャパターン、セットアップ手順について詳しく説明しました。お客様は、ALB の機能や利点を活用するために、SAP アプリケーションに ALB を使用しています。ALB は AWS のマネージドサービスであり、基盤となるオペレーションレイヤーや EC2 インスタンスのメンテナンスを必要としません。可用性が高くスケーラブルなサービスとして提供されるため、SAP 環境を簡素化できます。

SAP on AWS の詳細については、AWS 製品ドキュメントをご覧ください。

さらに専門的なガイダンスが必要な場合は、AWS アカウントチームに連絡して、地元の SAP スペシャリストソリューションアーキテクトまたは AWS プロフェッショナルサービス SAP 専門プラクティスに依頼してください。

SAP on AWS ディスカッションにご参加ください。

カスタマーアカウントチームと AWS サポートチャネルに加えて、Re: Post — AWS コミュニティ向けの再考された Q&A エクスペリエンスで私たちと交流することもできます。SAP on AWS ソリューションアーキテクチャチームは定期的に SAP on AWS のトピックを監視し、お客様やパートナーを支援するためのディスカッションや質問に回答しています。質問がサポートに関連していない場合は、re: Post でのディスカッションに参加して、コミュニティのナレッジベースに追加することを検討してください。

このブログは Sumit Dey が共同執筆し、翻訳は Partner SA 松本が担当しました。原文はこちらです。

Amazon Web Services ブログ