Amazon Web Services ブログ

SAP on AWSにおけるVPCサブネットのゾーニングパターン

この記事は、Amazon Web Services(AWS)のソリューション アーキテクト、Harpreet SinghとDerek Ewellによるものです。

企業のファイアウォール内に存在する必要があるSAPランドスケープの設計は比較的簡単ですが、内部からも外部からも接続する必要があるSAPアプリケーションの場合はそうではありません。これらのシナリオでは、必要なコンポーネントとその配置場所について悩むことがよくあります。

この一連のブログ記事では、SAPアプリケーションにおけるAmazon Virtual Private Cloud(Amazon VPC) サブネットのゾーニングパターンを紹介し、例を用いてその使用方法を説明します。セキュリティグループ、ルートテーブルおよびネットワークアクセスコントロールリスト(ACL)の構成と合わせて、よくあるお客様シナリオに基づいた詳細な図で補足しながら、接続経路ごとにいくつかのアーキテクチャ設計パターンを説明します。

アプリケーションを配置するサブネットを正しく見極めるには、アプリケーションへの接続方法を理解することが必要です。SAPアプリケーションに接続する方法をいくつか見てみましょう。

  • 内部専用接続: これらのアプリケーションは内部的にのみ接続します。SAPサポートチームを除き、外部からの接続は許可されていません。この場合、ユーザーまたはアプリケーションは、専用線または仮想プライベートネットワーク(VPN)を介して接続された企業ネットワーク内に存在する必要があります。SAP Enterprise Resource Planning(ERP)、SAP S/4HANA、SAP Business Warehouse(BW)およびSAP BW/4HANAはほとんどの組織で内部専用接続が必要なアプリケーションです。
  • 内部および管理された外部接続: これらのアプリケーションは内部的に接続しますが、既知の外部の関係者に限定した接続も提供します。例えば、内部プロセスからSAP PI(Process Integration)やSAP PO(Process Process Orchestration)を使用することができますし、既知の外部の関係者もホワイトリストに登録されたIPアドレスからソフトウェアのインターフェースに接続することができます。さらに、SAP SuccessFactors、SAP Cloud Platform、SAP AribaなどのSaaS(Software as a Service)ソリューションとの統合は、AWS上で実行されるSAPソリューションに機能を追加する場合にも望まれます。
  • 内部および管理されていない外部接続: SAP hybrisや社外に公開するSAP Enterprise Portalなどのアプリケーションがこのカテゴリーに分類されます。これらのアプリケーションには一般に外部接続が可能ですが、管理、構成および他の内部アプリケーションとの統合のためのコンポーネントなど、内部接続用のコンポーネントがあります。
  • 外部専用接続: ほとんどのコンポーネントが外部から接続可能であっても、アプリケーションにはバックアップ、接続制御、インターフェースなどの基本的な管理タスクのために内部から接続できる必要があるため、稀なシナリオです。このシナリオは滅多にないため、この一連のブログ記事では説明しません。

このブログ記事では、最初のカテゴリーのアプリケーション(内部でのみ接続可能なアプリケーション)で取り得るアーキテクチャパターンについて説明します。今後の記事で、残りの2つのシナリオについて説明します。3つすべてのシナリオにおいて、パッチ、更新プログラムの適用およびその他の関連するシナリオに対処するために、ネットワークアドレス変換(NAT)デバイス(IPv4の場合)、Egress-Onlyインターネットゲートウェイ(IPv6の場合)を使用して、AWSリソースからインターネットに接続すると仮定します。さらに、この接続は、インバウンド(インターネットからAWSクラウドへの)接続要求を制限または排除する方法で管理します。

内部専用接続におけるアーキテクチャ設計パターン

このカテゴリーのSAPアプリケーションについて、データベースとアプリケーションサーバーを同じプライベートサブネットまたは分離したプライベートサブネットに配置する2つの設計パターンを見ていきます。

単一のプライベートサブネットにあるデータベースとアプリケーションサーバー

この構成には3つのサブネットがあります。

  • パブリックサブネット: SAProuterとNATゲートウェイまたはNATインスタンスをこのサブネットに配置します。SAPから指定されたパブリックIPアドレスのみがSAProuterに接続できます。詳細は、SAPノート28976 – リモート接続データシートを参照してください。(SAPノートの閲覧にはSAPサポートポータルへの接続が必要です)。
  • 管理用のプライベートサブネット: Microsoft System Center Configuration Manager(SCCM)などの管理ツール、管理者または踏み台ホストをこのサブネットに配置します。このサブネット内のアプリケーションは、エンドユーザーが直接接続するのではなく、エンドユーザーをサポートするために必要です。このサブネット内のアプリケーションは、パブリックサブネットに配置されたNATゲートウェイまたはNATインスタンスを介してインターネットに接続できます。
  • アプリケーションとデータベース用のプライベートサブネット: データベースとアプリケーションをこのサブネットに配置します。SAPアプリケーションは、SAP GUI経由またはSAP Webディスパッチャを介したHTTP/S経由でエンドユーザーから接続できます。エンドユーザーはデータベースに直接接続することはできません。

異なるプライベートサブネットにあるデータベースとアプリケーションサーバー

この構成には4つのサブネットがあります。パブリックサブネットと管理用のプライベートサブネットは以前のシナリオと同じ機能を持ちますが、3つ目のサブネット(データベースとアプリケーション用のプライベートサブネット)が2つに分割されています。データベース用のプライベートサブネットには、ユーザー環境からアクセスできません。

これらの2つのアプローチの間に大きな違いはないことが分かります。ただし、2つ目の方法では、データベース用のサブネットを別のルートテーブルとネットワークACLで保護することで、データベースをより安全に保護します。これにより、データベース層への接続をより効果的に制御、管理できます。

私たちの知識を活用

実装例を検討することで、詳細に落とし込んでみましょう。

シナリオ例

お客様は、SAP S/4HANA、SAP FioriおよびSAP BW on HANA(ABAPとJava)を導入する必要があります。これらのアプリケーションは、企業ネットワークからのみ接続可能である必要があります。SAML(Security Assertion Markup Language)によるシングルサインオン(SSO)のために、Active Directory(AD)またはActive Directory フェデレーション サービス(ADFS)との統合も必要です。SAP BWはレガシーアプリケーションとのファイルベースの統合も行い、この目的でSSHファイル転送プロトコル(SFTP)サーバーと通信します。SAP社はサポートのためにこれらのシステムに接続できる必要があります。SAP Solution ManagerのデータベースにはSAP ASEを採用し、SAPアプリケーションの集中監視および変更管理に使用します。すべてのアプリケーションは、SUSE Linux Enterprise Server(SLES)上で稼働していると仮定します。

AWS上のソリューション

この例では、ソリューション要素あたり1つのEC2インスタンスしか想定していません。ワークロードが水平方向にスケールする場合、または高可用性が必要な場合は、機能的に類似した複数のEC2インスタンスを同じセキュリティグループに含めることができます。この場合、セキュリティグループにルールを追加する必要があります。企業ネットワークとVPC間の接続には、IPsecベースのVPNを使用します。Red Hat Enterprise Linux(RHEL)またはMicrosoft Windows Serverを使用している場合は、セキュリティグループ、ルートテーブル、およびネットワークACLに設定変更が必要な場合があります。詳細については、オペレーティングシステムの製品マニュアル、またはAmazon Elastic Compute Cloud(EC2)のセキュリティグループのルールのリファレンスなど、その他の情報源を参照してください。プライマリーのADまたはADFSサーバー、レガシーSFTPサーバーなどの特定のシステムはオンプレミスに残ります。

ソリューションのアーキテクチャ図は以下です。

このアーキテクチャ図の設定例は以下を想定しています。

以下の表は、セキュリティグループの構成例です。セキュリティグループで定義されるルールの概要を示しています。正確なポート番号または範囲については、SAP製品のマニュアルを参照してください。

ネットワークトラフィックのフローは、以下のようなルートテーブルによって管理されています。

*AWS Data Providerは、Amazon CloudWatch、Amazon S3およびAmazon EC2のAWS APIに接続できる必要があります。詳細は、「AWS Data Provider for SAP Installation and Operations Guide」を参照してください。

インスタンスに追加の層のセキュリティが必要な場合、以下の表に示すようなネットワークACLを使用できます。ネットワークACLは高速かつ効率的で、前述の表に示すセキュリティグループに加えて、別の制御層を提供します。セキュリティの推奨事項については、「AWS Security Best Practices」を参照してください。

ある特定の時に(OSパッチ適用など)、EC2インスタンスから追加のインターネット接続が必要な場合があります。ルートテーブル、ネットワークACLおよびセキュリティグループは、この接続を一時的に許可するように調整できます。

ここまでの概要と今後の予定

このブログ記事では、内部専用接続が必要なアプリケーションにおけるサブネットのゾーニングパターンを例に説明してきました。他のサブネットのゾーニングパターンについては、このシリーズの次の記事を参照してください。

AWS上でSAPアプリケーション用のVPCを設定した皆様の経験についてもお聞きしたいと思います。この記事に関するご質問やご提案がありましたら、お気軽にお問い合わせください。

翻訳はPartner SA 河原が担当しました。原文はこちらです。