SAP on AWS におけるApplication Load Balancerのユーザーエクスペリエンスとセキュリティの向上

はじめに

数千のお客様がAWS上でSAPワークロードを実行しており、お客様はAWS上でクラウドネイティブなアプリケーション拡張を構築することで、ビジネスプロセス変革を加速することを求めています。お客様は200を超えるAWSサービスを活用して、ERPシステムのクリーンコアを維持し、アップグレードを合理化し、AWSネイティブ機能を使用して進化するビジネスニーズに合わせてペースよくイノベーションを行っています。
セキュリティはAWSの最優先事項です。このモダナイゼーションの旅において、お客様の重要な焦点は、最小権限を順守し、複雑なシステム境界を越えてアイデンティティを伝播することで、セキュリティ体制を強化することです。一つのユースケースは、ユーザーがAWS上でホストされているクラウドネイティブアプリケーション拡張からSAPリソースにアクセスする場合です。
より良いユーザーエクスペリエンスの重要な実現要因は、プリンシパル伝播です。これは、AWSのApplication Load Balancer（ALB）などの初期認証ポイントから、再認証を必要とせずにSAPなどのバックエンドシステムまで、検証されたアイデンティティを運ぶ能力です。これにより、SAPリソースがALBによって検証されたアイデンティティを信頼し、ユーザー認可を通じて最小権限アクセスを担保することができます。
このブログ投稿では、Application Load Balancer（ALB）、X.509証明書、およびMutual Transport Layer Security（mTLS）が、AWS上でホストされているクラウドネイティブ拡張からミッションクリティカルなSAP ERPシステムのSAPリソースにアクセスするSAPユーザーに対して、シングルサインオン（SSO）エクスペリエンスを可能にする方法に焦点を当てています。

プリンシパル伝播とは？

プリンシパル伝播により、ユーザーは一度サインインするだけで複数のシステムに安全にアクセスでき、複数回ログインする必要がなくなります。これにより、ユーザーが一度認証されると（例：ALBでのクライアント証明書による認証）、そのアイデンティティがSAPなどの下流システムによって一貫して認識され、信頼されることが保証されます。これにより、冗長なログインプロンプトの必要性がなくなり、ランドスケープ全体で安全なユーザーコンテキストが維持されます。システムユーザーではなく、ユーザーのアイデンティティの下でアクションが実行されることを保証し、トークンベースの認証に依存することでセキュリティを向上させ、アイデンティティをシステムに転送することでシングルサインオン（SSO）を可能にします。

プリンシパル伝播の主要なメリット

シングルサインオン（SSO）によるより良いユーザーエクスペリエンス： ユーザーは複数のシステムやアプリケーションにアクセスするために一度だけ認証すればよく、繰り返しのログインプロンプトの煩わしさを排除し、異なるプラットフォーム間での生産性を維持できます。
セキュリティの強化： 複数の認証情報を保存する必要性を排除し、認証タッチポイントを削減することで、プリンシパル伝播はセキュリティ体制を強化します。明確な監査証跡を維持し、統合されたシステム全体で一貫したセキュリティポリシーを強制する統一されたセキュリティコンテキストを作成し、潜在的な攻撃者が環境を侵害することを困難にします。
コンプライアンスとガバナンス： 組織は、包括的なユーザーアクティビティの追跡と説明責任を通じて、規制要件へのより良いコンプライアンスを維持できます。プリンシパル伝播により、ユーザーアクションがすべてのシステムで適切に帰属し、ログに記録されることが保証され、監査プロセスと規制報告が簡素化されます。
管理効率： ITチームは、単一の制御ポイントからユーザーアクセス、権限、認証情報を管理でき、ユーザーライフサイクル管理を簡素化し、日常的な管理タスクを合理化できます。
システム統合： プリンシパル伝播は、異なるシステムとプラットフォーム間の橋渡しとして機能し、システム境界を越えて一貫したユーザーコンテキストと認可を維持します。この統合は、アプリケーションが複数のプラットフォームとクラウドサービスにまたがる現代のハイブリッド環境において特に価値があります。
コスト削減： 組織は、ヘルプデスクチケットの削減、セキュリティ実装の簡素化、および集中管理によるより効率的なリソース利用から恩恵を受けます。

mTLS認証はプリンシパル伝播をどのようにサポートできるか？

Mutual Transport Layer Security（mTLS）認証は、クライアントとサーバー間で安全な双方向暗号化接続を確立します。サーバーのみが証明書を提供する標準的なTLSとは異なり、mTLSでは両方の当事者がデジタル証明書を提示する必要があります。このメカニズムにより、ユーザーはクライアントとサーバー間でより良いセキュリティ体制を持つシームレスな認証を体験できます。

図1. クライアントとサーバー間のmTLS認証フロー

mTLS認証シナリオでは、両方が信頼されることを保証するために、認証局（CA）を使用してクライアントとサーバー証明書をプロビジョニングする必要があります。認証プロセスは以下のように動作します：

クライアントがサーバーへの接続を要求します。
サーバーがその証明書を提示します。
クライアントがサーバーの証明書を検証します。
クライアントがサーバーの検証と認証のためにその証明書を提示します。
クライアントとサーバー間で安全な接続が確立されます。

Application Load BalancerでのmTLSクライアント認証

ALBはmTLS認証をサポートしています。パススルーモードと検証モードの2つのモードを提供します。
安全なデータフローを確保するために、ALB、SAP Web Dispatcher、S/4HANAシステムを含むインフラストラクチャ全体で使用されるすべてのSSL（Secure Socket Layer）またはTLS証明書は、これらの証明書の実装と保守を容易にするために、単一の信頼できるルート認証局から発行される必要があります。

mTLSパススルーモード

mTLSパススルーモードでは、ALBはクライアントの証明書チェーン全体をバックエンドターゲットに転送します。これはX-Amzn-Mtls-Clientcertという名前のHTTPヘッダーを介して行われます。リーフ証明書を含むチェーンは、+、=、/を安全な文字として使用してURLエンコードされたPEM形式で送信されます。mTLSパススルーモードを使用する際の考慮事項は以下の通りです。

クライアント証明書が存在しない場合、ALBはヘッダーを追加しません。バックエンドがこれを処理する必要があります。
バックエンドターゲットがクライアント認証とエラー処理を担当します。
HTTPSリスナーの場合、ALBはクライアント-ALB TLSを終端し、ターゲットにインストールされた証明書を使用して新しいALB-バックエンドTLSを開始します。
ALBのTLS終端により、ロードバランシングにALBの任意のルーティングアルゴリズムを使用できます。

mTLS検証モード

mTLS検証モードを有効にするには、CA証明書バンドルを含むトラストストアを作成します。これはAWS Certificate Manager（ACM）、AWS Private CA、または独自の証明書をインポートすることで実現できます。Amazon S3に保存され、トラストストアにリンクされた証明書失効リスト（CRL）を使用して、失効した証明書を管理します。
ALBはトラストストアに対するクライアント証明書の検証を処理し、不正なリクエストを効果的にブロックします。このアプローチにより、バックエンドターゲットからmTLS処理をオフロードし、システム全体の効率を向上させます。ALBはS3からCRLをインポートし、S3への繰り返しフェッチなしでチェックを実行し、レイテンシを最小限に抑えます。
クライアント認証を超えて、ALBはHTTPヘッダー（例：X-Amzn-Mtls-Clientcert-Leaf）を通じてクライアント証明書メタデータをHTTPヘッダー経由でバックエンドSAP Web Dispatcherに送信します。これにより、SAPサーバーが元の「ホストヘッダー」情報を保持する要件を満たすために、証明書の詳細に基づいてバックエンドターゲットで追加のロジック実装が可能になります。
これにより、SSL接続を終端するAWSロードバランサーなどの非SAPソースから発信された場合でも、サーバーがクライアント証明書メタデータを一貫して処理できるようになります。ALB – SAP Web Dispatcher – SAPサーバー間でエンドツーエンド暗号化を実装している場合は、icm/HTTPS/client_certificate_header_nameなどのSAP Web Dispatcherプロファイルパラメータを設定する必要があります。詳細については、このリンクを参照してください。

推奨事項

AWS上でのSAPワークロードデプロイメントには、mTLS検証モードの実装を推奨します。これにより、可能な限り早期（ALBレイヤー）で検証と認証をオフロードできるためです。mTLS検証モードは、RISE with SAP on AWSでもサポートされています。

mTLS検証モードのアーキテクチャパターン

図2. AWS上のSAPワークロードのmTLS検証認証データフロー

上記のアーキテクチャは、AWS Direct Connectを通じて閉鎖されたオンプレミスとAWS VPCでmTLS認証がどのように実装されるかを説明しています。mTLS認証は、インターネット接続を持つリモートユーザーに対しても実装できます。

アーキテクチャフロー

ユーザーは、クライアントデバイス（ラップトップおよび/またはモバイル）にX.509証明書をインストールします。
クライアントデバイスはALBへの接続を開始し、それぞれの証明書を共有して、両方が互いを検証できるようにします。ALBの検証はAmazon S3をトラストストアとして活用します。
検証が完了すると、ALBは検証と認証のためにSAP Web Dispatcherに接続を転送します。
SAP Web Dispatcherは、検証と認証のためにSAPインスタンス（S/4HANA、ABAPスタックなど）に接続を転送します。

実装手順

詳細な実装手順はこちらで確認できます。これらの設定手順は、安全なクライアント-サーバー認証の基盤を確立します：

Amazon S3を使用してトラストストアを設定します。
- プライベート認証局（CA）と中間証明書を保存するためにAmazon S3バケットを作成します。
- EC2コンソールを通じてトラストストアを設定し、S3バケットにリンクします。
- ネットワーク接続に対する追加のセキュリティ制御のために証明書失効リスト（CRL）を実装します。
Application Load Balancer（ALB）を設定します。
- AWS Certificate Managerを使用してALB用のSSLパブリック証明書を要求します。
- 要求されたSSLパブリック証明書に関連付けることでmTLSを有効にするHTTPSリスナーを作成します。
- ALBからのトラフィックのみを許可するインバウンドルールを設定して、SAP Web Dispatcher専用のセキュリティグループを作成します。
- SAP Web Dispatcher用のターゲットグループを作成し、ALBにマッピングします。
SAPインスタンス（SAP S/4HANAなど）をバックエンドとしてターゲットするようにSAP Web Dispatcherを設定します。
- sapgenpseコマンドを使用して、ルートおよび中間証明書をSAP WebDispatcherにインポートします。
- SAP Web Dispatcher用のSSLパブリック証明書を（同じプライベートCAから）生成し、sapgenpseコマンドを使用してインストールします。
- SAPパラメータicm/HTTPS/client_certificate_header_name = x-amzn-mtls-clientcertを実装します。SAPドキュメントを参照してください。
安全な接続を受け入れるようにSAP S/4HANAを設定します。
- SAP S/4HANAのSTRUSTトランザクションにルートおよび中間証明書をインポートします。
- SAP Web Dispatcherに割り当てられたSSL証明書の詳細でSAPパラメータicm/trusted_reverse_proxyを実装します。SAPドキュメントを参照してください。

料金

Application Load Balancerの料金に関する詳細情報はこのリンクで確認できます。mTLS認証に特に関連して、mTLS検証ユースケースシナリオに基づいてALBに関連付けられたトラストストアあたりの追加の時間料金があります。S/4 HANAアプリケーションが平均して1秒あたり1つの新しい接続を受信し、それぞれが2分間持続すると仮定できます。クライアントは平均して1秒あたり5つのリクエストを送信し、リクエストとレスポンスの処理バイト数の合計は1秒あたり300 KBです。ロードバランサーでクライアントリクエストをルーティングするために1つのルールを設定し、Mutual TLSシナリオ用に1つのトラストストアを関連付けています。米国東部（バージニア北部）リージョンの料金を使用して、月次Application Load Balancerコストを以下のように計算します：

新しい接続（1秒あたり）：各LCU(Load Balancer Capacity Unit)は1秒あたり25の新しい接続を提供します（1時間の平均）。アプリケーションが1秒あたり1つの新しい接続を受信するため、これは0.04 LCU（1秒あたり1接続 / 1秒あたり25接続）に相当します。
アクティブ接続（1分あたり）：各LCUは1分あたり3,000のアクティブ接続を提供します。アプリケーションは1秒あたり1つの新しい接続を受信し、それぞれが2分間持続します。これは1分あたり120のアクティブ接続、または0.04 LCU（1分あたり120アクティブ接続 / 1分あたり3,000アクティブ接続）に相当します。
処理バイト数（1時間あたりGB）：各LCUは1時間あたり1 GBの処理バイトを提供します。各クライアント接続が1秒あたり300 KBのデータを転送するため、これは1時間あたり1.08 GBまたは1.08 LCU（1.08 GB/1 GB）に相当します。
ルール評価（1秒あたり）：10の無料ルールのため、この次元は料金に影響しません。
これらの値を使用して、時間料金は4つの次元で消費される最大LCUを取ることで計算されます。この例では、処理バイト次元（1.08 LCU）が新しい接続（0.04 LCU）、アクティブ接続（0.04 LCU）、ルール評価（0 LCU）よりも大きく、1時間あたり$0.00864（1.08 LCU * LCUあたり$0.008）または月額$6.22（$0.00864 * 24時間 * 30日）の合計料金となります。
$0.0225（ALB時間）の時間料金と0.0056（トラストストア）の時間料金を追加すると、Application Load Balancerの総コストは：
1時間あたり$0.03674（$0.0281時間料金 + $0.00864 LCU料金）；または
月額$26.4528（$0.03114 * 24時間 * 30日）。

まとめ

Application Load BalancerのmTLSサポートは、SAPランドスケープでプリンシパル伝播を実装するための堅牢な基盤を提供します。この統合により、AWSのマネージドサービスを活用しながら、安全でスケーラブル、かつ保守可能なSSOソリューションが可能になります。
主要なポイント：

ALBのmTLSサポートがプリンシパル伝播の実装を簡素化します。
SAP Web Dispatcherとの統合により、認証情報の適切なマッピングが保証されます。
AWSマネージドサービスが運用オーバーヘッドを削減します。
証明書ベースの認証によるセキュリティの強化。

ALBを使用してmTLS認証を実装することで、組織は従業員により良いユーザーエクスペリエンスを提供しながら、SAPアプリケーションのセキュリティ体制を向上させることができます。このソリューションは、アプリケーションランドスケープ全体で安全で効率的な認証メカニズムを維持する必要があるAWS上でSAPワークロードを実行している企業に特に関連があります。AWS Well Architected Framework（SAP Lens）に含まれるセキュリティのベストプラクティスに常に従い、証明書とトラストストアを定期的に更新することを忘れないでください。

SAP投資からより多くの価値を得る方法についてのインスピレーションを得るために、AWS for SAPブログで詳細をお読みください。

SAP on AWSディスカッションに参加

お客様のアカウントチームとAWSサポートチャネルに加えて、最近re:Post – AWSコミュニティのための再構築されたQ&Aエクスペリエンスを開始しました。AWS for SAPソリューションアーキテクチャチームは、お客様とパートナーを支援するために回答できるディスカッションと質問について、AWS for SAPトピックを定期的に監視しています。質問がサポート関連でない場合は、re:Postでのディスカッションに参加し、コミュニティの知識ベースに貢献することを検討してください。

クレジット

貢献してくれた以下のチームメンバーに感謝します：Derek Ewell、Sreenath Middhi、Rajendra Narikimelli、Joachim Aumman、Arne Knoeller、Adam Hill。

本ブログの翻訳はAmazon Q Developer CLIによる機械翻訳を行い、パートナー SA 松本がレビューしました。原文はこちらです。

Amazon Web Services ブログ