Azure PaaS を使用して SAP レガシ ミドルウェアを安全に公開する
内部システムと外部パートナーが SAP バックエンドとやり取りできるようにすることが一般的な要件です。 既存の SAP ランドスケープは、多くの場合、統合と変換のニーズに対して、従来のミドルウェア SAP Process Orchestration(PO) または Process Integration(PI) に依存しています。 わかりやすくするために、この記事では SAP Process Orchestration という用語を使用して、両方のオファリングに言及します。
この記事では、インターネット接続実装に重点を置いて Azure の構成オプションについて説明します。
Note
SAP では、SAP PO と PI の後継として Business Technology Platform (BTP) で実行されている SAP Integration Suite (特に SAP Cloud Integration) について言及しています。 BTP プラットフォームとサービスの両方を Azure で利用できます。 詳細については、SAP Discovery Center をご覧ください。 レガシ コンポーネントのメンテナンス サポートのタイムラインの詳細については、SAP OSS ノート 1648480 を参照してください。
概要
SAP ミドルウェアに基づく既存の実装は、多くの場合、SAP Web Dispatcher と呼ばれる SAP 独自のディスパッチ テクノロジに依存していました。 このテクノロジは、OSI モデルのレイヤー 7 で動作します。 これはリバース プロキシとして機能し、SAP Enterprise Resource Planning (ERP)、SAP Gateway、SAP Process Orchestration などのダウンストリーム SAP アプリケーション ワークロードの負荷分散ニーズに対応します。
ディスパッチ アプローチには、Apache などの従来のリバース プロキシから、Azure Load Balancer などのサービスとしてのプラットフォーム (PaaS) オプション、および厳密な SAP Web Dispatcher までが含まれます。 この記事で説明する全体的な概念は、説明されているオプションに適用されます。 SAP 以外のロード バランサーの使用に関するガイダンスについては、SAP の Wiki を参照してください。
Note
この記事で説明するすべてのセットアップでは、共有サービスがハブにデプロイされるハブアンドスポーク ネットワーク トポロジを前提としています。 SAP の重要度に基づいて、さらに分離が必要になる場合があります。 詳細については、SAP の境界ネットワークに関する設計ガイドを参照してください。
主要な Azure サービス
Azure Application Gateway は、パブリック インターネットベースおよび内部プライベート HTTP ルーティングと、Azure サブスクリプション間の暗号化トンネリングを扱います。 たとえば、セキュリティや自動スケーリングなどです。
Azure Application Gateway は Web アプリケーションの公開に重点を置いているため、Web アプリケーション ファイアウォール (WAF) を提供します。 Azure Application Gateway を介して SAP と通信する他の仮想ネットワーク内のワークロードは、テナント間でもプライベート リンクを介して接続できます。
Azure Firewall は、OSI モデルのレイヤー 4 から 7 のトラフィック タイプに対して、パブリック インターネット ベースおよび内部プライベート ルーティングを処理します。 これにより、フィルタリングと脅威インテリジェンスが Microsoft Security から直接提供されます。
Azure API Management は、特に API について、パブリック インターネット ベース ルーティングおよび/または内部プライベート ルーティングを処理します。 要求の調整、使用量クォータと制限、ポリシーなどのガバナンス機能、クライアントごとにサービスを詳細に分析する API キーが提供されます。
Azure VPN Gateway と Azure ExpressRoute は、オンプレミス ネットワークへのエントリ ポイントとして機能します。 図では、VPN と XR と略されています。
設定の考慮事項
統合アーキテクチャのニーズは、組織が使用するインターフェイスによって異なります。 中間ドキュメント (IDoc) フレームワーク、ビジネス アプリケーション プログラミング インターフェイス (BAPI)、トランザクション リモート関数呼び出し (tRFC)、プレーン RFC などの SAP 独自のテクノロジには、特定のランタイム環境が必要です。 これらは、通常 HTTP ベースの通信に依存する最新の API とは異なり、OSI モデルのレイヤー 4 から 7 で動作します (OSI モデルのレイヤー 7)。 そのため、インターフェイスを同じように扱うことはできません。
この記事では、Applicability Statement 2 (AS2) などの統合シナリオを含む、最新の API と HTTP に焦点を当てています。 ファイル転送プロトコル (FTP) は、HTTP 以外の統合のニーズを処理する例として機能します。 Microsoft 負荷分散ソリューションの詳細については、負荷分散のオプションを参照してください。
Note
SAP は、独自インターフェイス専用のコネクタを発行します。 たとえば、Java と .NET に関する SAP のドキュメントを確認してください。 これらは Microsoft ゲートウェイでもサポートされています。 IDocs は HTTP 経由でも投稿できることに注意してください。
セキュリティの問題では、トランスポート層セキュリティ (TLS) で HTTP ベースのトラフィックを処理するために、下位レベルのプロトコル用のファイアウォールと、WAF の使用が必要になります。 有効にするには、TLS セッションを WAF レベルで終了する必要があります。 ゼロトラストのアプローチに対応するため、後でもう一度暗号化し直して、エンドツーエンドの暗号化を提供することをお勧めします。
AS2 などの統合プロトコルでは、標準の WAF 規則を使用することでアラートが発生する可能性があります。 Application Gateway WAF トリアージ ブックを使用して、ルールがトリガーされる理由を特定してより正確に把握し、効果的かつ安全に修復できるようにすることをお勧めします。 標準規則は、Open Web Application Security Project (OWASP) によって提供されます。 SAP Fiori の公開に重点を置いたこのトピックの詳細なビデオ セッションについては、SAP on Azure Webcast をご覧ください。
相互認証とも呼ばれる 相互 TLS (mTLS) を使用することで、セキュリティをさらに強化できます。 これは、通常の TLS とは異なり、クライアント ID も検証します。
Note
仮想マシン (VM) プールにはロード バランサーが必要です。 読みやすさのため、この記事の図にはロード バランサーは表示されません。
Note
SAP Web Dispatcher が提供する SAP 固有の分散機能が必要ない場合は、それらを Azure Load Balancer に置き換えることができます。 この置換により、サービスとしてのインフラストラクチャ (IaaS) のセットアップではなく、マネージド PaaS オファリングの利点が得られます。
シナリオ: 受信 HTTP 接続を重視した場合
SAP Web Dispatcher は WAF を提供していません。 そのため、より安全なセットアップには Azure Application Gateway をお勧めします。 SAP Web Dispatcher と Process Orchestration が、サイズ設定ガイダンスと同時要求制限を使用して、SAP バックエンドを要求のオーバーロードから保護することを引き続き担当します。 SAP ワークロードで使用できる調整機能はありません。
SAP Web Dispatcher のアクセス制御リストを使用すると、意図しないアクセスを回避できます。
SAP プロセス オーケストレーション通信のシナリオの 1 つが受信フローです。 トラフィックは、オンプレミス、外部アプリやユーザー、または内部システムから発信される可能性があります。 次の例では、HTTPS に焦点を当てています。
シナリオ: 送信 HTTP/FTP 接続を重視した場合
逆通信方向の場合、SAP Process Orchestration では、仮想ネットワーク ルーティングを使用し、インターネット ブレイクアウトを介してオンプレミスのワークロードまたはインターネット ベースのターゲットに到達できます。 Azure Application Gateway は、このようなシナリオでリバース プロキシとして機能します。 非 HTTP 通信の場合、Azure Firewall を追加することを検討してください。 詳細については、この記事の後半の「シナリオ: ファイルベース」と「ゲートウェイのセットアップの比較」を参照してください。
次の送信シナリオは、考えられる 2 つの方法を示しています。 1 つは、Azure Application Gateway を介して HTTPS を使用し、Web サービス (SOAP アダプターなど) を呼び出します。 もう 1 つは、Azure Firewall を介して FTP over SSH (SFTP) を使用し、ビジネス パートナーの SFTP サーバーにファイルを転送します。
シナリオ: API Management を重視した場合
受信接続と送信接続のシナリオと比べ、内部モード (プライベート IP のみ、仮想ネットワーク統合) で Azure API Management を導入することにより、次のような組み込み機能が追加されます。
- 調整:
- API ガバナンス。
- 最新の認証フローなどの追加のセキュリティ オプション。
- Microsoft Entra ID の統合。
- SAP API を企業全体の中央 API ソリューションに追加可能。
WAF が必要ない場合は、パブリック IP アドレスを使用して Azure API Management を外部モードでデプロイできます。 このデプロイにより、調整機能と API ガバナンス機能を維持しながら、セットアップが簡略化されます。 基本保護は、すべての Azure PaaS オファリングに対して実装されます。
シナリオ: グローバルな展開
Azure Application Gateway はリージョン限定サービスです。 前のシナリオと比較すると、Azure Front Door では、Web アプリケーション ファイアウォールを含むリージョン間のグローバル ルーティングが保証されています。 相違点の詳細については、この比較を参照してください。
次の図は、見やすさの観点から、SAP Web Dispatcher、SAP Process Orchestration、バックエンドを単一のイメージにまとめています。
シナリオ: ファイルベース
FTP などの非 HTTP プロトコルは、これまでのシナリオに示すように、Azure API Management、Application Gateway、Azure Front Door では対処できません。 代わりに、マネージド Azure Firewall インスタンスまたは同等のネットワーク仮想アプライアンス (NVA) が、受信要求をセキュリティで保護する役割を引き受けています。
ファイルは、SAP による処理の前に格納する必要があります。 SFTP を使用することをお勧めします。 Azure Blob Storage では、SFTP がネイティブにサポートされます。
必要に応じて、代替の SFTP オプションを Azure Marketplace で使用できます。
次の図は、外部とオンプレミスの統合ターゲットを使用した、このシナリオのバリエーションを示しています。 セキュリティで保護されたさまざまな種類の FTP による通信パスが示されています。
Blob Storage の代替としてのネットワーク ファイル システム (NFS) ファイル共有の詳細については、「Azure Files での NFS ファイル共有」を参照してください。
シナリオ: SAP RISE 固有
SAP RISE デプロイは、前に説明したシナリオと技術的に同じですが、ターゲット SAP ワークロードが SAP 自体によって管理される点が異なります。 説明されている概念は、ここに当てはまります。
次の図は、例として 2 つのセットアップを示しています。 詳細については、SAP RISE リファレンス ガイドを参照してください。
重要
SAP に問い合わせて、シナリオの通信ポートが NSG で許可され開かれていることを確認してください。
HTTP 受信
最初のセットアップでは、お客様が、SAP Process Orchestration や完全な受信パスを含む統合レイヤーを管理します。 最終的な SAP ターゲットのみが RISE サブスクリプションで実行されます。 RISE ホステッド ワークロードへの通信は、仮想ネットワーク ピアリング (通常はハブ経由) を介して構成されます。 可能性のある統合としては、外部パーティによって SAP ERP Web サービス /sap/bc/idoc_xml に投稿される IDoc が考えられます。
次の 2 番目の例は、SAP RISE が API Management レイヤーを除く統合チェーン全体を実行するセットアップを示しています。
ファイル送信
このシナリオでは、SAP が管理する Process Orchestration インスタンスが、Azure 上にあるお客様が管理するファイル共有またはオンプレミスのワークロード設定にファイルを書き込みます。 ブレイクアウトを処理するのはお客様です。
ゲートウェイのセットアップの比較
Note
パフォーマンスとコストのメトリックは、運用グレード レベルを前提としています。 詳細については、Azure の料金計算ツールに関するページをご覧ください。 Azure Firewall のパフォーマンス、Application Gateway の高トラフィックのサポート、Azure API Management インスタンスのキャパシティに関する記事も参照してください。
使用する統合プロトコルによっては、複数のコンポーネントが必要になる場合があります。 Azure Application Gateway と Azure Firewall をチェーン化して組み合わせることによる利点の詳細については、仮想ネットワーク用の Azure Firewall と Application Gateway に関する説明を参照してください。
統合の経験則
この記事で説明する統合シナリオのうち、どれが要件に最も適しているかを判断するには、ケース バイ ケースで評価します。 次の機能を有効にすることを検討してください。
API Management を使用した要求の調整
SAP Web Dispatcher での同時要求の制限
クライアントと受信者を確認するための相互 TLS
WAF と TLS 終了後の再暗号化
非 HTTP 統合の Azure Firewall
VM ベースの SAP 統合ワークロードの高可用性とディザスター リカバリー
OAuth2 などの最新の認証メカニズム (該当する場合)
関連するすべての資格情報、証明書、キーに対する Azure Key Vault などのマネージド キー ストア
Azure Integration Services を使用した SAP プロセス オーケストレーションの代替手段
Azure Integration Services ポートフォリオを使用すると、SAP Process Orchestration がカバーする統合シナリオにネイティブに対処できます。 クラウドネイティブの手段を使用して SAP IFlow パターンを設計する方法については、こちらのブログ シリーズをご覧ください。 コネクタ ガイドには、AS2 と EDIFACT の詳細が含まれています。
詳細については、目的の SAP インターフェイスの Azure Logic Apps コネクタを参照してください。
次のステップ
Application Gateway と API Management で API を保護する
内部仮想ネットワーク内の API Management を Application Gateway と統合する
SAP 関連の WAF アラートをより深く理解するために、Application Gateway WAF トリアージ ブックをデプロイする
SAP 用の Application Gateway WAF について