編集

SAP on Azure の受信および送信インターネット接続

Azure Virtual Machines
Azure Virtual Network
Azure Application Gateway
Azure Load Balancer

この記事では、SAP on Azure インフラストラクチャの受信および送信インターネット接続のセキュリティを強化するための実証済みプラクティスについて説明します。

アーキテクチャ

SAP on Azure のインターネット接続通信のソリューションを示した図。

この記事のアーキテクチャの Visio ファイルをダウンロードします。

このソリューションは、一般的な運用環境を示しています。 要件に合わせて、構成のサイズとスコープを小さくすることができます。 この縮小は、SAP ランドスケープに適用できます。仮想マシン (VM) を減らしたり、高可用性をなくしたり、個別の VM ではなく埋め込み SAP Web Dispatcher を使用したりできます。 また、この記事で後述するように、ネットワーク設計の代替手段にも適用できます。

ビジネス ポリシーに基づくお客様の要件によって、アーキテクチャ、特にネットワーク設計への適応が必要になります。 可能な場合は、代替手段を含めました。 多くのソリューションが実行可能です。 ご自身のビジネスに適したアプローチを選択します。 Azure リソースをセキュリティで保護しながら、パフォーマンスの高いソリューションを維持できるようにする必要があります。

ディザスター リカバリー (DR) については、このアーキテクチャでは説明しません。 ネットワーク設計では、プライマリ運用リージョンで有効なものと同じ原則と設計が適用されます。 ご自身のネットワーク設計では、DR によって保護されているアプリケーションに応じて、別の Azure リージョンで DR を有効にすることを検討してください。 詳細については、「SAP ワークロードのディザスター リカバリーの概要とインフラストラクチャ のガイドライン」アーティクルを参照してください

ワークフロー

  • オンプレミス ネットワークは、Azure ExpressRoute 経由で中央ハブに接続します。 ハブ仮想ネットワークには、ゲートウェイ サブネット、Azure Firewall サブネット、共有サービス サブネット、Azure Application Gateway サブネットが含まれます。
  • ハブは、仮想ネットワーク ピアリングを使用して SAP 運用サブスクリプションに接続します。 このサブスクリプションには、次の 2 つのスポーク仮想ネットワークが含まれます。
    • SAP 境界仮想ネットワークには、SAP 境界アプリケーション サブネットが含まれます。
    • SAP 運用仮想ネットワークには、アプリケーション サブネットとデータベース サブネットが含まれます。
  • ハブ サブスクリプションと SAP 運用サブスクリプションは、パブリック IP アドレスを介してインターネットに接続します。

コンポーネント

サブスクリプション このアーキテクチャでは、Azure ランディング ゾーン アプローチを実装します。 ワークロードごとに 1 つの Azure サブスクリプションが使用されます。 1 つ以上のサブスクリプションが、ネットワーク ハブと中央の共有サービス (ファイアウォールや Active Directory および DNS など) を含む中央 IT サービスに使用されます。 SAP 運用ワークロードには、別のサブスクリプションが使用されます。 Azure 向けのクラウド導入フレームワークの決定ガイドを使用して、シナリオに最適なサブスクリプション戦略を決定します。

仮想ネットワーク。Azure Virtual Network では、Azure のリソースを相互に接続させ、セキュリティを強化しています。 このアーキテクチャでは、仮想ネットワークは、ハブスポーク トポロジのハブにデプロイされた ExpressRoute または仮想プライベート ネットワーク (VPN) ゲートウェイ経由でオンプレミス環境に接続されます。 SAP 運用ランドスケープでは、独自のスポーク仮想ネットワークが使用されます。 2 つの異なるスポーク仮想ネットワークで異なるタスクが実行され、サブネットによってネットワーク分離が行われます。

ワークロードごとにサブネットに分離することで、ネットワーク セキュリティ グループ (NSG) を使用して、デプロイされているアプリケーション VM または Azure サービスのセキュリティ規則を設定することがさらに容易になります。

ゾーン冗長ゲートウェイ。 ゲートウェイは個々のネットワークを接続し、オンプレミス ネットワークを Azure 仮想ネットワークに拡張します。 パブリック インターネットを使用しないプライベート接続を作成するには、ExpressRoute を使用することをお勧めします。 サイト間接続を使用することもできます。 ゾーンの障害を回避するために、ゾーン間で ExpressRoute または VPN ゲートウェイをデプロイできます。 ゾーン デプロイとゾーン冗長デプロイの違いについては、ゾーン冗長仮想ネットワーク ゲートウェイに関する記事をご覧ください。 ゲートウェイのゾーン デプロイには、Standard SKU の IP アドレスを使用する必要があります。

NSG。 仮想ネットワークとの間のネットワーク トラフィックを制限するには、NSG を作成して、特定のサブネットに割り当てます。 ワークロード固有の NSG を使用して、個々のサブネットにセキュリティをもたらします。

アプリケーション セキュリティ グループ。 ワークロードに基づき、アプリケーションを中心にして、NSG で詳細なネットワーク セキュリティ ポリシーを定義するには、明示的な IP アドレスではなくアプリケーションのセキュリティ グループを使用します。 アプリケーション セキュリティ グループを使用することで、SAP SID などの目的別に VM をグループ化できます。 アプリケーション セキュリティ グループでは、ネットワークの信頼できるセグメントからトラフィックをフィルタリングすることにより、アプリケーションのセキュリティの確保に役立ちます。

プライベート エンドポイント。 多くの Azure サービスは、設計上インターネット経由でアクセス可能なパブリック サービスとして動作します。 プライベート ネットワーク範囲を介してプライベート アクセスを許可するため、一部のサービスでプライベート エンドポイントを使用できます。 プライベート エンドポイントは、仮想ネットワーク内のネットワーク インターフェイスです。 これらにより、サービスがプライベート ネットワーク空間に効果的に取り込まれます。

Azure Application Gateway。Application Gateway は、Web トラフィック ロード バランサーです。 Web アプリケーション ファイアウォール機能を備えており、セキュリティを強化して Web アプリケーションをインターネットに公開するのに理想的なサービスです。 Application Gateway は、構成に応じて、パブリック (インターネット)、プライベート クライアント、またはその両方にサービスを提供できます。

このアーキテクチャでは、Application Gateway は、パブリック IP アドレスを使用して、HTTPS 経由で SAP ランドスケープへの受信接続を許可します。 バックエンド プールは 2 つ以上の SAP Web Dispatcher VM であり、ラウンドロビンにアクセスされ、高可用性をもたらします。 アプリケーション ゲートウェイはリバース プロキシおよび Web トラフィック ロード バランサーですが、SAP Web Dispatcher に置き換わりません。 SAP Web Dispatcher では、アプリケーションが SAP システムと統合され、Application Gateway 自体では提供しない機能が含まれています。 クライアント認証は、SAP システムに到達したときに、SAP アプリケーション レイヤーによってネイティブまたはシングル サインオンで実行されます。 Azure DDoS 保護を有効にする場合は、Application Gateway Web Application Firewall の割引が表示されるので、DDoS ネットワーク保護 SKU の使用を検討してください。

最適なパフォーマンスを得られるように、Application Gateway、SAP Web Dispatcher、SAP NetWeaver の HTTP/2 サポートを有効にします。

Azure Load Balancer。 Azure Standard Load Balancer では、SAP システムの高可用性設計にネットワーク要素を提供します。 クラスター化システムの場合、Standard Load Balancer により、ASCS/SCS インスタンスや、VM 上で実行されているデータベースなど、クラスター サービスの仮想 IP アドレスが提供されます。 また、Standard Load Balancer を使用して、Azure ネットワーク カード上のセカンダリ IP がオプションでない場合に、非クラスター化システムの仮想 SAP ホスト名に IP アドレスを与えることもできます。 送信インターネット アクセスに対処するために Application Gateway の代わりに Standard Load Balancer を使用する方法については、この記事の後半で説明します。

ネットワーク設計

このアーキテクチャでは、2 つの個別の仮想ネットワークが使用され、どちらも中央ハブ仮想ネットワークにピアリングされたスポーク仮想ネットワークになります。 スポーク間ピアリングはありません。 スター トポロジが使用され、ここでは通信はハブを通過します。 ネットワークの分離は、侵害からアプリケーションを保護するのに役立ちます。

アプリケーション固有の境界ネットワーク (DMZ とも呼ばれます) には、SAProuter、SAP Cloud Connector、SAP Analytics Cloud Agent などのインターネット接続アプリケーションがあります。 このアーキテクチャ図では、境界ネットワークには「SAP 境界 - スポーク仮想ネットワーク」という名前が付けられています。 SAP システムへの依存関係のため、SAP チームが通常、これらのサービスのデプロイ、構成、管理を行います。 そのため、これらの SAP 境界サービスは、中央ハブ サブスクリプションおよびネットワークには、あまり多く配置されていません。 多くの場合、組織的な課題は、ワークロード固有のアプリケーションまたはサービスのこのような中央ハブに配置することに起因します。

個別の SAP 境界仮想ネットワークを使用する利点のいくつかを次に示します。

  • 侵害が検出された場合に、侵害されたサービスをすばやく即座に分離。 SAP 境界からハブへの仮想ネットワーク ピアリングを削除すると、SAP 境界ワークロードと SAP アプリケーション仮想ネットワーク アプリケーションがインターネットからすぐに分離されます。 アクセスを許可する NSG 規則を変更または削除しても、新しい接続にのみ影響し、既存の接続は切断されません。
  • SAP 境界ネットワークと SAP アプリケーション ネットワーク内外の通信パートナーに対する厳密なロックダウンを行う、仮想ネットワークとサブネットに対するより厳しい制御。 SAP 境界アプリケーションのさまざまな認可バックエンド、特権アクセス、またはサインイン資格情報を使用して、SAP 境界アプリケーションでの許可されているユーザーとアクセス方法に対する制御を強化できます。

欠点は、複雑さが増加することと、インターネットへの SAP トラフィックの仮想ネットワーク ピアリング コストが余分にかかることです (通信は仮想ネットワーク ピアリングを 2 回通過する必要があるため)。 スポークハブスポーク ピアリング トラフィックへの待機時間の影響は、配置されているファイアウォールによって異なり、測定する必要があります。

簡略化されたアーキテクチャ

この記事の推奨事項に取り組みながら欠点を抑えるために、単一のスポーク仮想ネットワークを境界アプリケーションと SAP アプリケーションの両方に使用することができます。 次のアーキテクチャには、1 つの SAP 運用仮想ネットワークのすべてのサブネットが含まれています。 侵害された場合に SAP 境界への仮想ネットワーク ピアリングを終了することで即座に分離できるという利点は、利用できなくなります。 このシナリオでは、NSG への変更は新しい接続にのみ影響します。

SAP on Azure のインターネットに接続した通信の簡略化されたアーキテクチャを示した図。

この記事のアーキテクチャの Visio ファイルをダウンロードします。

サイズとスコープが小さいデプロイの場合、簡略化されたアーキテクチャの方が適している可能性があり、複雑なアーキテクチャの原則にも準拠します。 この記事では、特に記載がない限り、より複雑なアーキテクチャを参照します。

簡略化されたアーキテクチャでは、SAP 境界サブネット内の NAT ゲートウェイを使用します。 このゲートウェイでは、SAP Cloud Connector と SAP Analytics Cloud エージェントに送信接続を提供し、デプロイされた VM に OS 更新プログラムを提供します。 SAProuter では受信接続と送信接続の両方が必要になるため、SAProuter 通信パスは NAT ゲートウェイを使用する代わりにファイアウォールを通過します。 シンプルなアーキテクチャでは、ハブ仮想ネットワークの代替アプローチとして、 SAP 境界仮想ネットワークに独自の指定されたサブネットを持つ Application Gateway も配置されます。

NAT ゲートウェイは、送信接続に静的パブリック IP アドレスを提供するサービスです。 NAT ゲートウェイはサブネットに割り当てられます。 すべての送信通信で、インターネット アクセスに NAT ゲートウェイの IP アドレスが使用されます。 受信接続では NAT ゲートウェイは使用されません。 SAP Cloud Connector などのアプリケーションや、インターネット上のリポジトリにアクセスする VM OS 更新サービスでは、すべての送信トラフィックを中央ファイアウォール経由でルーティングするのではなく、NAT ゲートウェイを使用できます。 多くの場合、すべての仮想ネットワークからインターネットへのトラフィックを強制的に中央のファイアウォールに経由させるユーザー定義の規則が、すべてのサブネットに実装されます。

要件によっては、送信接続でのみ、中央ファイアウォールの代替として NAT ゲートウェイを使用できる場合があります。 このようにすることで、NSG で許可されたパブリック エンドポイントとの通信中に、中央ファイアウォールへの負荷を軽減できます。 また、NAT ゲートウェイの設定された IP リストで宛先ファイアウォール規則を構成できるため、送信 IP の制御も得られます。 たとえば、パブリック サービス、OS パッチ リポジトリ、またはサード パーティ製インターフェイスで使用される Azure パブリック エンドポイントへの到達が挙げられます。

高可用性構成の場合、NAT ゲートウェイは特定のゾーンにのみデプロイされ、現在はゾーン間で冗長になっていないことに注意してください。 単一の NAT ゲートウェイでは、仮想マシンにゾーン冗長 (クロスゾーン) デプロイを使用する SAP デプロイには適していません。

SAP ランドスケープ全体でのネットワーク コンポーネントの使用

アーキテクチャ ドキュメントには、通常、1 つの SAP システムまたはランドスケープのみが示されています。 これにより、わかりやすくなります。 その結果、多くの場合、画像を大きくしても、複数のシステム トラップおよび層を含んだより大きな SAP ランドスケープに、アーキテクチャがどの程度適合するかは対応しません。

ファイアウォール、NAT ゲートウェイ、プロキシ サーバー (デプロイされている場合) などの中央ネットワーク サービスは、すべての層 (運用、運用前、開発、サンドボックス) の SAP ランドスケープ全体で最適に使用されます。 要件、組織の規模、ビジネス ポリシーに応じて、層ごとに個別に実装するか、1 つの運用環境と 1 つのサンドボックス/テスト環境にするかを検討することをお勧めします。

通常 SAP システムを提供するサービスは、次の説明に従って分離することをお勧めします。

  • ロード バランサーは、個々のサービス専用にする必要があります。 会社のポリシーでは、リソースの命名とグループ化が決定されます。 ASCS/SCS および ERS 用のロード バランサーと、データベース用のロード バランサーを、SAP SID ごとに分離することをお勧めします。 あるいは、1 つの SAP システムの (A)SCS、ERS と DB クラスターの両方に 1 つのロード バランサーを使用するのも適切な設計です。 このように構成すれば、多くのフロントエンドおよびバックエンド プールと負荷分散規則がすべて 1 つのロード バランサー上に置かれ、トラブルシューティングが複雑にならないようにすることができます。 また、SAP SID ごとに 1 つのロード バランサーを使用すると、リソース グループ内の配置を他のインフラストラクチャ コンポーネントの配置と確実に一致させられます。
  • Application Gateway では、ロード バランサーと同様に、複数のバックエンド、フロントエンド、HTTP 設定、規則を使用できます。 環境内のすべての SAP システムでパブリック アクセスが必要なわけではないため、ここでは、複数の用途に 1 つのアプリケーション ゲートウェイを使用するという決定が一般的です。 このコンテキストでの複数の用途には、同じ SAP S/4HANA システムに対する異なる Web ディスパッチャー ポートや、異なる SAP 環境が含まれます。 接続されたシステムの複雑さと数が過剰にならない限り、層 (運用、非運用、サンドボックス) ごとに少なくとも 1 つのアプリケーション ゲートウェイを使用することをお勧めします。
  • SAP サービス (SAProuter、Cloud Connector、Analytics Cloud Agent など) は、アプリケーションの要件に基づいて一元的にデプロイされるか、分割してデプロイされます。 多くの場合、運用と非運用を分離することが望まれます。

サブネットのサイズ設定と設計

SAP ランドスケープのサブネットを設計するときは、必ずサイズ設定と設計の原則に従ってください。

  • 複数の Azure サービスとしてのプラットフォーム (PaaS) サービスには、それぞれ独自の指定されたサブネットが必要です。
  • Application Gateway では、スケーリングのために /24 サブネットが推奨されます。 Application Gateway のスケールを制限する場合は、最小 /26 以上の小さなサブネットを使用できます。 同じサブネットで両方のバージョンの Application Gateway (1 と 2) を使用することはできません。
  • NFS/SMB 共有またはデータベース ストレージに Azure NetApp Files を使用する場合は、指定されたサブネットが必要です。 /24 サブネットが既定値です。 要件を使用して、適切なサイズ設定を決定します。
  • SAP 仮想ホスト名を使用する場合は、SAP サブネットに SAP 境界を含む、より多くのアドレス空間が必要です。
  • 通常は中央 IT チームによって管理される Azure Bastion や Azure Firewall などの中央サービスには、十分なサイズの専用サブネットが必要です。

SAP データベースとアプリケーションに専用サブネットを使用することで、より厳密になるように NSG を設定でき、これにより、両方のアプリケーションの種類を独自の規則セットで保護できます。 この場合、SAP アプリケーションへのデータベース アクセスをより簡単に制限でき、詳細に制御するためにアプリケーション セキュリティ グループに頼る必要はありません。 また、SAP アプリケーションとデータベース サブネットを分離すると、NSG でセキュリティ規則を管理しやすくなります。

SAP サービス

SAProuter

SAProuter を使用して、SAP サポートやパートナーなどのサード パーティがお客様の SAP システムにアクセスできるようにすることができます。 SAProuter は、Azure 内の 1 つの VM で実行されます。 SAProuter を使用するためのルート アクセス許可は、saprouttab というフラット ファイルに格納されています。 saprouttab エントリを使用すると、任意の TCP/IP ポートから SAProuter の背後にあるネットワーク宛先 (通常は SAP システム VM) に接続できます。 SAP サポートによるリモート アクセスは、SAProuter に依存します。 メイン アーキテクチャでは、前述の設計が使用され、指定された SAP 境界仮想ネットワーク内で SAProuter VM が実行されます。 SAProuter は続いて、仮想ネットワーク ピアリングを通じて、独自のスポーク仮想ネットワークとサブネットで実行される SAP サーバーと通信します。

SAProuter は、SAP またはパートナーへのトンネルです。 このアーキテクチャでは、SAP/パートナーへの暗号化されたアプリケーション トンネル (ネットワーク レイヤ 7) を確立するために、SNC を使用した SAProuter の使用について説明します。 現時点では、IPSEC ベースのトンネルの使用は、このアーキテクチャではカバーされていません。

次の機能は、インターネット上の通信パスの保護に役立ちます。

  • Azure Firewall またはサードパーティ製の NVA によって、Azure ネットワークへのパブリック IP エントリ ポイントが提供されます。 ファイアウォール規則により、認可された IP アドレスのみに通信が制限されます。 SAP サポートへの接続については、SAP ノート 48243 - ファイアウォール環境への SAProuter ソフトウェアの統合に、SAP ルーターの IP アドレスが文書化されています。
  • ファイアウォール規則と同様に、ネットワーク セキュリティ規則では、SAProuter のポート (通常は 3299 と指定された宛先) での通信が許可されています。
  • SAProuter に接続できるユーザーとアクセスできる SAP システムを指定して、saprouttab ファイルで SAProuter の許可/拒否規則を保持します。
  • さらなる NSG 規則が、SAP システムを含む SAP 運用サブネット内のそれぞれのサブネットに配備されています。

Azure Firewall を使用して SAProuter を構成する手順については、Azure Firewall を使用した SAProuter の構成に関するページを参照してください。

SAProuter のセキュリティに関する考慮事項

SAProuter は SAP システムと同じアプリケーション サブネットでは動作しないため、OS のサインイン メカニズムが異なる場合があります。 ポリシーに応じて、SAProuter 用に個別のサインオン ドメインを使用することも、完全にホスト専用のユーザー資格情報を使用することもできます。 セキュリティ違反が発生した場合、資格情報ベースが異なるため、内部 SAP システムへのカスケード アクセスはできません。 前述のように、このような場合ネットワークを分離にすることで、侵害された SAProuter からアプリケーション サブネットへのその後のアクセスを切断できます。 この分離は、SAP 境界仮想ネットワーク ピアリングを切断することで実現できます。

SAProuter の高可用性に関する考慮事項

SAProuter はファイル ベースのルート アクセス許可テーブルを含んだ単純な実行可能ファイルであるため、簡単に開始できます。 このアプリケーションには高可用性は組み込まれていません。 VM またはアプリケーションの障害が発生した場合は、別の VM でサービスを開始する必要があります。 SAProuter サービスに仮想ホスト名を使用することが理想的です。 仮想ホスト名は IP にバインドされ、この IP は VM の NIC でのセカンダリ IP 構成として割り当てられるか、VM に接続された内部ロード バランサーに割り当てられます。 この構成では、SAProuter サービスを別の VM に移動する必要がある場合に、サービス仮想ホスト名の IP 構成を削除できます。 続いて別の VM に仮想ホスト名を追加します。ルート テーブルやファイアウォール構成を変更する必要はありません。 これらはすべて、仮想 IP アドレスを使用するように構成されています。 詳細については、Azure で Linux を使用した SAP 仮想ホスト名の使用に関するページを参照してください。

カスケード SAProuter

カスケード SAProuter を実装するために、SAP サポート接続用に最大 2 つの SAProuter を定義できます。 SAP 境界アプリケーション サブネットで実行される最初の SAProuter では、中央のファイアウォールと SAP またはパートナーの SAProuter からのアクセスを提供します。 唯一の許可された宛先は他の SAProuter であり、特定のワークロードで実行されます。 カスケード SAProuter では、アーキテクチャに応じて、層ごと、リージョンごと、または SID ごとの分離を使用できます。 2 番目の SAProuter は、最初の SAProuter からの内部接続のみを受け入れ、個々の SAP システムと VM へのアクセスを提供します。 この設計により、必要に応じて、アクセスと管理を別々のチームに分離できます。 カスケード SAProuters の例については、Azure Firewall を使用した SAProuter の構成に関するページを参照してください。

SAP Fiori と WebGui

SAP Fiori やその他の SAP アプリケーション用の HTTPS フロントエンドは、多くの場合、社内ネットワークの外部から使用されます。 インターネット上で使用できるようにする必要がある場合は、SAP アプリケーションを保護するための高セキュリティ ソリューションが必要です。 Web アプリケーション ファイアウォールを使用した Application Gateway は、この目的に最適なサービスです。

Application Gateway に関連付けられているパブリック IP のパブリック ホスト名にアクセスするユーザーの場合、HTTPS セッションは Application Gateway で終了します。 2 つ以上の SAP Web Dispatcher VM のバックエンド プールでは、Application Gateway からラウンドロビン セッションを取得します。 Web Dispatcher へのこの内部トラフィック アプリケーション ゲートウェイは、要件に応じて HTTP にすることも HTTPS にすることもできます。 Web アプリケーション ファイアウォールは、OWASP コア規則セットを使用して、インターネット経由で行われる攻撃から SAP Web Dispatcher を保護するのに役立ちます。 多くの場合、シングル サインオン (SSO) を介して Microsoft Entra ID に関連付けられている SAP NetWeaver により、ユーザー認証が実行されます。 Application Gateway を使用して Fiori の SSO を構成するために必要な手順については、パブリック URL と内部 URL に対する SAML と Microsoft Entra ID を使用したシングル サインオン構成に関するページを参照してください。

どのような状況でも SAP Web Dispatcher をセキュリティで保護する必要があることに注意してください。 内部でのみ開いている場合でも、パブリック IP 経由で Application Gateway に対して開いたり、他のネットワーク手段でアクセスしたりできます。 詳細については、SAP Web Dispatcher のセキュリティ情報に関するページを参照してください。

Azure Firewall と Application Gateway

Application Gateway によって提供されるすべての Web トラフィックは HTTPS ベースであり、指定された TLS 証明書で暗号化されます。 パブリック IP 経由で、Azure Firewall を企業ネットワークへのエントリ ポイントとして使用し、内部 IP アドレス経由で、ファイアウォールから Application Gateway に SAP Fiori トラフィックをルーティングできます。 詳しくは、「Azure Firewall の後の Application Gateway」を参照してください。 TCP/IP レイヤー 7 暗号化は既に TLS 経由で実施されているため、このシナリオでファイアウォールを使用する利点は限られており、パケット検査を実行することはできません。 Fiori では、受信トラフィックと送信トラフィックの両方に対して同じ外部 IP アドレスを介して通信しますが、これは通常、SAP Fiori デプロイでは必要ありません。

Application Gateway とレイヤー 4 ファイアウォールの同時デプロイには、いくつかの利点があります。

  • 企業全体のセキュリティ ポリシー管理と統合できるようになります。
  • セキュリティ規則に違反するネットワーク トラフィックは既に破棄されているため、検査は必要ありません。

この組み合わせたデプロイは、優れたアーキテクチャです。 受信インターネット トラフィックを処理する方法は、企業アーキテクチャ全体に依存します。 また、ネットワーク アーキテクチャ全体が、オンプレミス クライアントなどの内部 IP アドレス空間からのアクセス方法にどの程度適合しているかを検討する必要もあります。 この考慮事項については、次のセクションで説明します。

内部 IP アドレスの Application Gateway (省略可能)

このアーキテクチャでは、インターネットに接続するアプリケーションに重点を置いています。 内部のプライベート IP アドレスを介して、SAP Fiori、SAP NetWeaver システムの Web UI、または別の SAP HTTPS インターフェイスにアクセスするクライアントが利用できるさまざまなオプションがあります。 あるシナリオでは、パブリック IP を介して Fiori へのすべてのアクセスをパブリック アクセスとして扱います。 別のオプションでは、プライベート ネットワーク経由で SAP Web Dispatcher への直接ネットワーク アクセスを使用して、Application Gateway を完全に迂回します。 3 つ目のオプションでは、Application Gateway でプライベートとパブリックの両方の IP アドレスを使用して、インターネットとプライベート ネットワークの両方にアクセスできるようにします。

SAP ランドスケープへのプライベート専用ネットワーク アクセスには、Application Gateway でのプライベート IP アドレスで同様の構成を使用できます。 この場合のパブリック IP アドレスは管理目的でのみ使用され、リスナーは関連付けられません。

Application Gateway を使用する代わりに、ロード バランサーを内部で使用することもできます。 Web Dispatcher VM がラウンドロビン バックエンドとして構成された標準の内部ロード バランサーを使用できます。 このシナリオでは、標準ロード バランサーは SAP 運用アプリケーション サブネット内の Web Dispatcher VM と共に配置され、Web Dispatcher VM 間のアクティブ/アクティブ負荷分散を提供します。

インターネットに接続するデプロイの場合、パブリック IP を使用したロード バランサーではなく、Web Application Firewall を使用した Application Gateway をお勧めします。

SAP Business Technology Platform (BTP)

SAP BTP は、一般的にインターネット経由でパブリック エンドポイントを介してアクセスされる、SAP アプリケーション、SaaS、または PaaS の大規模なセットです。 SAP Cloud Connector は多くの場合、Azure で実行されている SAP S/4HANA システムなど、プライベート ネットワークで実行されているアプリケーションに通信を提供するために使用されます。 SAP Cloud Connector は、VM 内のアプリケーションとして実行されます。 SAP BTP を使用して TLS で暗号化された HTTPS トンネルを確立するには、送信インターネット アクセスが必要です。 仮想ネットワーク内のプライベート IP 範囲と SAP BTP アプリケーションとの間のリバース呼び出しプロキシとして機能します。 このリバース呼び出しをサポートしているため、仮想ネットワークからの接続は送信になるので、受信接続に対して開いたファイアウォール ポートや他のアクセス方法は必要ありません。

既定では、VM は Azure 上ではネイティブに送信インターネット アクセスを行います。 仮想マシンに関連付けられている専用パブリック IP アドレスがない場合、送信トラフィックに使用されるパブリック IP アドレスは、特定の Azure リージョン内のパブリック IP のプールからランダムに選択されます。 これを制御することはできません。 制御された識別可能なサービスと IP アドレスを使用して送信接続を確立するには、次のいずれかの方法を使用できます。

  • サブネットまたはロード バランサーとそのパブリック IP アドレスに関連付けられている NAT ゲートウェイ。
  • 操作する HTTP プロキシ サーバー。
  • ネットワーク トラフィックをファイアウォールなどのネットワーク アプライアンスに強制的に送信するユーザー定義ルート。

このアーキテクチャ図には、インターネットへのトラフィックをハブ仮想ネットワークに中央のファイアウォールを通じてルーティングする、最も一般的なシナリオが示されています。 SAP BTP アカウントに接続するには、SAP Cloud Connector でさらに設定を構成する必要があります。

SAP Cloud Connector の高可用性

高可用性は SAP Cloud Connector に組み込まれています。 Cloud Connector は 2 つの VM にインストールされます。 メイン インスタンスがアクティブで、シャドウ インスタンスがそれに接続されています。 これらは構成を共有し、ネイティブに同期状態に保持されます。 メイン インスタンスが使用できない場合、セカンダリ VM が主なロールを引き継ぎ、SAP BTP への TLS トンネルを再確立しようとします。 高可用性 Cloud Connector 環境がアーキテクチャに示されています。 構成には、ロード バランサーやクラスター ソフトウェアなどの他の Azure テクノロジは必要ありません。 構成と操作の詳細については、SAP のドキュメントを参照してください。

SAP Analytics Cloud エージェント

一部のアプリケーション シナリオでは、SAP Analytics Cloud エージェントは VM にインストールされるアプリケーションです。 SAP BTP 接続には SAP Cloud Connector が使用されます。 このアーキテクチャでは、SAP Analytics Cloud エージェント VM は、SAP Cloud Connector VM と共に SAP 境界アプリケーション サブネットで実行されます。 SAP Analytics Cloud エージェント経由での Azure 仮想ネットワークなどのプライベート ネットワークから SAP BTP へのトラフィック フローについては、SAP のドキュメントを参照してください。

SAP では、SAP BTP の Private Link サービスを提供しています。 これにより、選択した SAP BTP サービスと、Azure サブスクリプションと仮想ネットワーク内の選択したサービスとの間のプライベート接続が有効になります。 Private Link サービスを使用する場合、通信はパブリック インターネット経由でルーティングされません。 これは、高セキュリティの Azure グローバル ネットワーク バックボーンにとどまります。 Azure サービスへの通信は、プライベート アドレス空間を介して行われます。 プライベート エンドポイントが特定の Azure サービスを IP アドレスにマップするので、Private Link サービスを使用するときに、改善されたデータ流出防止が組み込まれます。 アクセスは、マップされた Azure サービスに制限されます。

一部の SAP BTP 統合シナリオでは、Private Link サービス アプローチをお勧めします。 その他の場合は、SAP Cloud Connector の方が適しています。 どちらを使用するかを決める際に役立つ情報については、Cloud Connector と SAP Private Link の並列的実行に関するページを参照してください。

SAP RISE/ECS

SAP が SAP RISE/ECS 契約で SAP システムを運用している場合、SAP がマネージド サービス パートナーになります。 SAP 環境は SAP によってデプロイされます。 SAP のアーキテクチャでは、ここに示すアーキテクチャは、SAP/ECS を使用した RISE で実行されるシステムには適用されません。 この種の SAP ランドスケープを Azure サービスおよびネットワークに統合する方法の詳細については、Azure のドキュメントを参照してください。

その他の SAP 通信の要件

インターネットへの通信に関するその他の考慮事項は、Azure で動作する SAP ランドスケープに適用される場合があります。 このアーキテクチャのトラフィック フローでは、この送信トラフィックに中央の Azure ファイアウォールが使用されます。 スポーク仮想ネットワークのユーザー定義の規則により、インターネットへのトラフィック要求はファイアウォールにルーティングされます。 または、特定のサブネット、既定の Azure 送信通信、VM でのパブリック IP アドレス (非推奨)、またはアウトバウンド規則を含むパブリック ロード バランサーで NAT ゲートウェイを使用できます。

クラスタ環境のように標準的な内部ロード バランサーの後ろにある VM の場合、標準ロード バランサーがパブリック接続の動作を変更することに注意してください。 詳細は、SAP の高可用性シナリオにおける Azure Standard Load Balancer を使用した仮想マシンのパブリック エンドポイント接続アーティクルを参照してください。

オペレーティング システムの更新プログラム

オペレーティング システムの更新プログラムは多くの場合、パブリック エンドポイントの背後に置かれ、インターネット経由でアクセスされます。 エンタープライズ リポジトリと更新管理が存在せず、プライベート IP アドレス/VM 上にベンダーから OS 更新プログラムをミラーリングする場合、SAP ワークロードはベンダーの更新リポジトリにアクセスする必要があります。

Linux オペレーティング システムの場合、Azure から OS ライセンスを取得した場合は、次のリポジトリにアクセスできます。 ライセンスを直接購入して Azure (BYOS) に持ち込む場合は、OS リポジトリへの接続方法とそれぞれの IP アドレス範囲について OS ベンダーに問い合わせてください。

高可用性クラスターの管理

クラスター化された SAP ASCS/SCS やデータベースなどの高可用性システムでは、クラスター マネージャーと Azure フェンス エージェントを STONITH デバイスとして使用できます。 これらのシステムは、Azure Resource Manager に到達できるかどうかによります。 Resource Manager は、Azure リソースに関する状態クエリや、VM を停止して起動する操作に使用されます。 Resource Manager は management.azure.com 下で使用できるパブリック エンドポイントであるため、VM 送信通信がそこに到達できる必要があります。 このアーキテクチャは、SAP 仮想ネットワークからのトラフィックをルーティングするユーザー定義規則を持つ中央ファイアウォールに依存します。 別の方法については、前のセクションを参照してください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

その他の共同作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

コミュニティ

これらのコミュニティを使用して、質問に対する回答を取得し、デプロイの設定に関するヘルプを確認することを検討してください。

次のステップ