Amazon Web Services ブログ

Amazon CloudFront で SAP S/4HANA に mTLS 認証を実装する

はじめに

シンガポールは朝7時。ある財務コントローラーが SAP で月次決算を締めようと急いでいますが、その前にシステム認証が3大陸にまたがって彼女の本人確認を行う必要があります。フランクフルトの彼女のチームは応答の遅さに苦しみ、ニューヨークのセキュリティチームは、本番 SAP システムへの検証されていない接続試行をたった今フラグしたところです。SAP を大陸をまたいで運用するグローバル企業にとって、これは例外ではなく日常的に起こることです。

機密性の高い財務取引、人事記録、サプライチェーンデータが、常にパブリックインターネットを流れています。多くの場合、ビジネスと不正アクセスの間に立ちはだかるのは、ユーザー名とパスワード程度でしかありません。

根本原因はアーキテクチャにあります。SAP S/4HANA が単一の AWS リージョンにホストされている場合、そのリージョンから遠いユーザーは TLS ハンドシェイク時に高いレイテンシーを強いられます。同時に、静的な SAP Fiori アセット（JavaScript、CSS、フォント）は、ネットワークエッジでキャッシュされることなく、オリジンサーバーから繰り返し取得されます。トラフィックが Amazon VPC（Virtual Private Cloud）に到達する前に、誰が接続しているのかを暗号的に保証する仕組みがありません。

Amazon CloudFront は、mTLS（相互 Transport Layer Security）の証明書チェックを各ユーザーに最も近いエッジロケーションへ移すことで、これら両方の課題に対応します。CloudFront はクライアント証明書を検証し、静的な SAP コンテンツをキャッシュし、証明書メタデータを HTTP ヘッダーとして SAP バックエンドへ転送して、X.509 ベースのシングルサインオン（SSO）を実現します。

本記事では、CloudFront、Elastic Load Balancing の Application Load Balancer（ALB）、SAP Internet Communication Manager（ICM）を用いてこのアーキテクチャを実装する方法を学びます。トラストストアのセットアップ、CloudFront と ALB の設定、SAP プロファイルパラメータの手順を順を追って説明します。読み終える頃には、エッジでユーザーを認証し、その ID を SAP へ安全に伝搬する、動作するソリューションが手元にあることになります。

社内テストでは、オリジンが N. バージニア（us-east-1）リージョンにある場合、シンガポールに所在するユーザーの初回ログイン時間をこのアーキテクチャによって約40〜50%短縮できました。この改善は、CloudFront エッジロケーションでのエッジキャッシュによって SAP Fiori のページ読み込み時間が高速化されたことによるものです。結果はネットワーク経路、ユーザーの所在地、ワークロードによって異なります。本記事後半の検証手順を用いて、ご自身の環境で測定してください。

私たちが継続的に耳にするお客様の課題

私たちのお客様は、ワークショップ、EBC（Executive Briefing Center）、その他の定期的な機会を通じて、以下の課題を継続的に持ち込まれます。

  • 「他国にいる SAP Fiori ユーザーから、ランチパッドが遅いと言われている。」SAP が単一リージョンで稼働している場合、静的な Fiori アセット（JavaScript、CSS、フォント）は、ネットワークエッジでキャッシュされることなくオリジンから繰り返し取得されます。その結果、遠隔地のユーザーはページごとに長く待たされます。
  • 「盗まれたパスワードさえあればインターネット経由で SAP ログインに到達できる、とセキュリティが指摘した。」多くのお客様では、パブリックインターネットと財務・人事・サプライチェーンのデータの間に立ちはだかるのは、ユーザー名とパスワード程度でしかありません。トラフィックが VPC に到達する前に、誰が接続しているのかを暗号的に証明する仕組みがありません。
  • 「当社はグローバル企業だが、SAP システムは1つのリージョンにある。」そのリージョンから遠いユーザーは、ログインのたびに TLS ハンドシェイクで高いレイテンシーを強いられ、月次決算のような時間に追われる業務でその影響が累積します。
  • 「SAP の前段に mTLS 付きの ALB をすでに配置している。なぜそれでは不十分なのか。」リージョン内の mTLS 検証はリージョン内のセキュリティを強化しますが、グローバルなハンドシェイクのレイテンシー、静的アセットのエッジキャッシュ、エッジレベルの DDoS 保護は解決しません。

なぜこれが重要なのか

これらの課題を解決することは、単なる技術的な演習ではなく、ビジネス成果を変えるものです。エッジでクライアント証明書を検証することで、不正な接続が VPC に到達する前に拒否するゼロトラストの姿勢を強制できます。これにより、すべてのリモートユーザー向けに VPN インフラを展開・維持することなく、攻撃対象領域を縮小できます。静的な SAP コンテンツをキャッシュし、各ユーザーに最も近い Point of Presence で TLS ハンドシェイクを終端することで、私たちのテストではログイン時間を約40〜50%短縮しました。これは、期限どおりに決算を締める財務コントローラーと、遅いランチパッドで待たされ続ける財務コントローラーとの違いを生みます。そして、ID がパスワードではなく X.509 証明書として運ばれるため、従業員をパスワードレスでフィッシング耐性のあるシングルサインオンへと移行させられます。本記事の残りでは、各コンポーネントの詳細な AWS ドキュメントへのリンクを添えて、これらの課題をどのように段階的に解決したかを説明します。

SAP における mTLS のための CloudFront の利点

ALB はリージョン内で強力な mTLS 機能を提供しますが、ALB の前段に CloudFront を追加することで、SAP ワークロードにいくつかの利点が得られます。

CloudFront は最も近いエッジロケーションでクライアント証明書を検証するため、トラフィックが VPC に入る前に不正な接続を拒否できます。TLS ハンドシェイクは 600 を超える CloudFront の Point of Presence（PoP）のうち最も近い場所で行われるため、ユーザーは地理的な所在地に関わらず低いレイテンシーを体験できます。

SAP WebGUI や SAP Fiori アプリケーションは、JavaScript、CSS、フォントファイルなど大量の静的アセットを配信します。CloudFront はこれらのアセットをエッジでキャッシュするため、オリジンへのリクエスト数が減り、ページの読み込み時間が改善されます。さらに、AWS Shield と AWS WAF の統合による組み込みの保護も得られ、本番 SAP システムに多層防御を追加できます。

CloudFront はクライアント証明書を検証すると、証明書の詳細を抽出します。そして、それらを HTTP ヘッダー（CloudFront-Viewer-Cert-\*）としてリクエストに追加します。SAP ICM インスタンスは CloudFront-Viewer-Cert-Pem ヘッダーを読み取り、X.509 証明書ベースの認証を実行します。これにより、クライアントブラウザへの直接的な TLS 接続が不要になります。

アーキテクチャの概要

次の図は、エンドツーエンドのリクエストフローを示しています。Amazon CloudFront はすべてのクライアント接続のエントリーポイントとして機能します。ALB はオリジンとして動作し、SAP ICM は認証のために転送された証明書メタデータを受け取ります。このアーキテクチャは4つのコンポーネントを使用します。X.509 証明書を持つクライアントブラウザ、mTLS verify モードの CloudFront、HTTPS パススルーモードの ALB、ポート 44300 の SAP ICM です。

Figure 1. Amazon CloudFront and SAP Deployment in one Customer managed VPC

図1. 1つのお客様管理 VPC 内での Amazon CloudFront と SAP の展開

リクエストフロー

  1. ブラウザに X.509 クライアント証明書をインストールします。AWS Private Certificate Authority（AWS Private CA） がブラウザ用のこの証明書を作成します。あるいは、他の信頼された認証局を使用することもできます。
  2. ブラウザが CloudFront ディストリビューション（例: democf.awsforsap.com）に接続します。CloudFront はクライアント証明書を要求し、Amazon S3 トラストストアに保存された CA 証明書と照合します。
  3. 検証に成功すると、CloudFront は証明書メタデータを抽出し、CloudFront-Viewer-Cert-\* ヘッダーをリクエストに追加します。これには、CloudFront-Viewer-Cert-Pem に含まれる PEM エンコードされた完全な証明書が含まれます。
  4. CloudFront はリクエストを HTTPS 経由で ALB オリジンへ転送します。ALB は mTLS パススルーモードで動作し、トラフィックを SAP ターゲットグループへ転送します。
  5. SAP ICM はリクエストを受け取り、CloudFront-Viewer-Cert-Pem ヘッダー（icm/HTTPS/client_certificate_header_name で設定）を読み取り、クライアント証明書を抽出し、証明書のコモンネーム（CN）を CERTRULE トランザクションを通じて SAP ユーザーにマッピングします。

このソリューションは、RISE with SAP on AWS の VPC に対しても展開できます。次の図は、CloudFront と ALB がお客様管理の VPC で稼働し、RISE with SAP の VPC と統合される同じパターンを示しています。

Figure 2. Amazon CloudFront and SAP Deployment in separate Customer managed VPC which is integrated to RISE with SAP VPC

図2. RISE with SAP VPC と統合された別のお客様管理 VPC 内での Amazon CloudFront と SAP の展開

CloudFront mTLS ビューアー認証

CloudFront は、ビューアー接続に対する相互 TLS 認証を verify モードでサポートします。このモードでは、CloudFront はすべてのクライアントに対し、TLS ハンドシェイク中に有効な X.509 証明書の提示を要求します。CloudFront は、Amazon S3 トラストストアに保存された CA 証明書バンドルと証明書を照合します。

証明書の検証が AWS リージョン内で行われる ALB mTLS とは異なり、CloudFront mTLS の検証は、あなたに最も近いエッジロケーションで行われます。CloudFront は、オリジンのリソースを消費する前に、エッジで不正な接続を拒否します。また、ハンドシェイクが最も近い PoP（Point of Presence）で行われるため、CloudFront は TLS ハンドシェイクのレイテンシーも最小化します。

CloudFront ビューアー証明書ヘッダー

mTLS verify モードを有効にすると、CloudFront は次のヘッダーを自動的に生成し、オリジンリクエストポリシーを通じてオリジンへ転送します。

ヘッダー 説明
CloudFront-Viewer-Cert-Pem リーフクライアント証明書の URL エンコードされた PEM 形式
CloudFront-Viewer-Cert-Subject サブジェクト DN の RFC2253 文字列（例: CN=ferrymul,O=awsforsap,C=SG）
CloudFront-Viewer-Cert-Issuer 発行者 DN の RFC2253 文字列
CloudFront-Viewer-Cert-Serial-Number 証明書の16進数シリアル番号
CloudFront-Viewer-Cert-Sha256 クライアント証明書の SHA256 ハッシュ
CloudFront-Viewer-Cert-Validity ISO8601 形式の NotBefore および NotAfter の日付
CloudFront-Viewer-Cert-Present 証明書が存在する場合は 1、存在しない場合は 0

CloudFront-Viewer-Cert-Pem ヘッダーは、SAP 統合における鍵となるヘッダーです。これには、SAP ICM が X.509 認証に使用するクライアント証明書の全体が含まれます。

実装手順

実装は4つのフェーズで構成されます。まず、認証局とトラストストアを作成します。次に、CloudFront と ALB を設定します。最後に、転送されたクライアント証明書を受け入れるよう SAP を設定します。以下のセクションで各フェーズを順に説明します。

ステップ1: 認証局とトラストストアの作成

最初のステップでは、PKI（Public Key Infrastructure）の基盤を確立します。ブラウザ認証用のクライアント証明書を作成する自己署名 CA を作成します。CloudFront がエッジで受信クライアント証明書をチェックするために使用する Amazon S3 トラストストアに、CA 証明書をアップロードします。これは mTLS チェーン全体の暗号的な信頼の根（root of trust）であるため、CA の秘密鍵は適切に保護してください。

クイックな概念実証には OpenSSL で自己署名 CA をブートストラップできますし、本番環境ではマネージドで監査可能なソリューションとして AWS Private CA を使用できます。最小限の OpenSSL フローでは、CA を作成し、CloudFront が照合する S3 トラストストアへアップロードし、ブラウザへインポートするための PKCS#12 バンドルとしてパッケージ化されたクライアント証明書を作成します。

# 自己署名 CA を作成（有効期間10年）

openssl genrsa -out ca.key 2048

openssl req -new -x509 -days 3650 -key ca.key -out ca.pem -subj "/C=SG/O=awsforsap/CN=awsforsap mTLS CA"


\# CloudFront が照合する S3 トラストストアに CA 証明書をアップロード

aws s3 cp ca.pem s3://<your-bucket>-trust-store/ca.pem

\# クライアント証明書（CN = SAP ユーザー名）を発行し、ブラウザ用に .p12 をエクスポート

openssl pkcs12 -export -out client.p12 -inkey client.key -in client.pem -certfile ca.pem

マネージドで本番運用に耐える方法と、証明書ライフサイクル全体のガイダンスについては、AWS Private CA ユーザーガイドおよび CloudFront での相互 TLS 認証を参照してください。

AWS Private CA は、CA ごとの月額料金に加えて、発行した証明書ごとに課金されます。自己署名 CA より AWS Private CA を選ぶ前に、AWS Private CA の料金を確認してください。

ステップ2: Amazon CloudFront の設定

トラストストアが整ったら、次のステップは、エッジでクライアント証明書をチェックする CloudFront ディストリビューションを作成することです。ここでレイテンシーとセキュリティの利点が実現します。CloudFront の 600 を超えるエッジロケーションで mTLS を終端することで、認証の判断を可能な限りユーザーの近くへ移し、ラウンドトリップ時間を短縮し、不正な接続が VPC に到達する前に拒否します。

CloudFront を設定するには、次の手順を実行します。

以下の手順は流れの要約です。詳細なコンソールのウォークスルーとすべての設定については、ディストリビューションの作成、ディストリビューションでの相互 TLS の有効化、オリジンリクエストポリシー、および CloudFront で ACM 証明書を使用するための要件を参照してください。

  1. ディストリビューションを作成します。ALB の DNS 名をオリジンとして指定し、HTTPS のみのオリジンプロトコルと TLSv1.2 を使用します。CloudFront コンソールでディストリビューションに移動し、「ディストリビューションを作成」を選択して、ALB の DNS 名をオリジンドメインとして入力します。
  2. オリジンの読み取りタイムアウトを 60 秒に設定します。SAP WebGUI はコールドスタート時に応答まで 30 秒以上かかることがあり、デフォルトの 30 秒のタイムアウトでは 504 エラーが発生します。
  3. verify モードで mTLS ビューアー認証を有効化します。「設定 > ビューアー証明書」で「相互 TLS 認証」を選び、「Verify モード」を選択します。トラストストアを、CA 証明書を含む S3 オブジェクトへ向けます。
  4. カスタムのオリジンリクエストポリシーを作成し、7つの CloudFront-Viewer-Cert-\* ヘッダーをすべて転送します。CloudFront コンソールで「ポリシー > オリジンリクエスト」に移動し、新しいポリシーを作成して、すべての CloudFront-Viewer-Cert ヘッダーを追加します。すべての Cookie とクエリ文字列を転送します。
  5. キャッシュ動作を設定します。動的な SAP コンテンツ（デフォルトの動作）はキャッシュをオフにし、静的アセット（\*.js、\*.css、\*.png、\*.jpg、\*.ico、\*.tiff）はキャッシュを最適化します。
  6. カスタムドメイン（例: \*.awsforsap.com）用に AWS Certificate Manager（ACM） 証明書を関連付け、必要に応じて AWS WAF ウェブアクセスコントロールリスト（ウェブ ACL）をアタッチします。

ステップ3: Application Load Balancer の設定

ALB は、CloudFront と SAP インスタンスの間の橋渡し役を担います。このアーキテクチャでは、ALB は mTLS パススルーモードで動作します。つまり、ALB 自身はクライアント証明書をチェックしません。代わりに、CloudFront がすでに検証した証明書ヘッダーをそのまま通過させます。これにより二重チェックのオーバーヘッドを回避し、SAP が証明書メタデータを直接受け取れるようになります。

ALB を設定するには、次の手順を実行します。

ALB と mTLS パススルー設定の完全なリファレンスについては、Application Load Balancer での TLS による相互認証を参照してください。

  1. インターネット向けの ALB を作成します。少なくとも2つのアベイラビリティーゾーン（AZ）に配置し、少なくとも2つのパブリックサブネットを選択し、両方のサブネットにインターネットゲートウェイへのルートがあることを確認します。
  2. ポート 443 の HTTPS リスナーを作成します。HTTPS:443 を選び、TLS 1.3 のセキュリティポリシー（例: ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09）を選択し、mTLS をパススルーモードに設定します。
  3. ターゲットグループを作成します。HTTPS プロトコル、ポート 44300（SAP ICM HTTPS ポート）を使用します。ヘルスチェックパスを /sap/public/ping、ヘルスチェックプロトコルを HTTPS に設定します。
  4. SAP インスタンスをターゲットとして登録し、クロスゾーン負荷分散を有効化します。

ステップ4: SAP S/4HANA の設定

最終フェーズでは、AWS インフラを SAP システムに接続します。CloudFront から ALB を経由して転送される証明書ヘッダーを信頼するよう、SAP ICM を設定します。これでエンドツーエンドの mTLS チェーンが完成します。SAP は HTTP ヘッダーでクライアント証明書を受け取り、直接的な TLS クライアント接続を必要とせずに、それを X.509 ベースの SSO に使用します。

CloudFront からの HTTP ヘッダー転送を通じて X.509 証明書認証を受け入れるために、SAP トランザクション RZ10 で次のプロファイルパラメータを設定します。

これらのパラメータと、関連する SICF、STRUST、CERTRULE の手順は、参照先の SAP Note と AWS の SAP 向け mTLS Security Extension ガイドに記載されています。

パラメータ 値 SAP Note
icm/HTTPS/accept_forwarded_cert_via_http TRUE 2805092
icm/HTTPS/client_certificate_header_name CloudFront-Viewer-Cert-Pem 3639967
icm/trusted_reverse_proxy SUBJECT=”<your-ALB-cert-subject>”, ISSUER=”<your-ALB-cert-issuer>” 2805092

さらに、次の SAP 設定を実施します。

  1. CERTRULE トランザクション: クライアント証明書の CN（例: CN=ferrymul）を対応する SAP ユーザーアカウントにマッピングするルールを作成します。
  2. SICF トランザクション: /sap/bc/gui/sap/its/webgui ICF サービスノードで、ログオン手続きとして SSL クライアント証明書を有効化します。
  3. STRUST トランザクション: SAP があなたの CA が発行した証明書を信頼するよう、ルート CA 証明書を SSL Server Standard PSE にインポートします。

ソリューションの検証

4つの設定フェーズをすべて完了したら、エンドツーエンドの mTLS 認証フローが正しく動作することを検証します。次の手順を使用して、証明書検証、ヘッダー伝搬、SAP 認証が成功していることを確認します。

テスト1: CloudFront mTLS ハンドシェイクの検証

クライアント証明書を使って curl で CloudFront mTLS ハンドシェイクをテストします。

curl -v --cert client.pem --key client.key https://democf.awsforsap.com/sap/public/ping

mTLS ハンドシェイクが成功すると、HTTP 200 レスポンスが返ります。証明書が無効または欠落している場合、CloudFront は HTTP 403 を返します。

テスト2: 証明書ヘッダー伝搬の検証

CloudFront のアクセスログを有効にし、オリジンリクエストヘッダーを確認します。レスポンスに期待される証明書サブジェクト（例: CN=ferrymul,O=awsforsap,C=SG）が含まれていることを検証します。

テスト3: SAP 認証の検証

クライアント証明書（.p12 ファイルからインポート）をインストールしたブラウザを起動します。https://democf.awsforsap.com/sap/bc/gui/sap/its/webgui にアクセスします。設定が正しければ、SAP は CERTRULE トランザクションでマッピングされた X.509 証明書の CN を用いて自動的にログインさせます。ユーザー名やパスワードの入力を求められることなく、SAP WebGUI セッションが表示されるはずです。

認証が失敗する場合は、SAP ICM トレース（トランザクション SMICM で「移動」→「トレースファイル」を選択）で証明書ヘッダーの解析エラーを確認してください。

主な違い: SAP における CloudFront mTLS と ALB mTLS の比較

以前のブログ記事「Elevate User Experience and Security of Application Load Balancer for SAP workloads on AWS」を参照すると、mTLS verify モードを実装するには2つの選択肢があります。以下は、この2つのアーキテクチャタイプの主な違いです。

観点 ALB mTLS（verify モード） CloudFront mTLS（verify モード）
mTLS 終端ポイント リージョナル（VPC 内の ALB） エッジ（最も近い CloudFront PoP）
証明書ヘッダー名 X-Amzn-Mtls-Clientcert CloudFront-Viewer-Cert-Pem
静的コンテンツのキャッシュ 利用不可 \*.js、\*.css、画像のエッジキャッシュ
DDoS 保護 AWS Shield Standard エッジでの AWS Shield + AWS WAF
グローバルなレイテンシー リージョナル（単一リージョン） 600 を超えるエッジロケーションによる低レイテンシー
トラストストアの場所 ALB トラストストア（S3 バックエンド） CloudFront トラストストア（S3 バックエンド）

要件やシナリオに基づいて、どちらの選択肢を実装するかを選べます。SAP をグローバルに運用しており、高いパフォーマンスとセキュリティを必要とするリモートワーカーがいる場合は、mTLS verify モードでエッジキャッシュとセキュリティ緩和策を実行できる CloudFront の機能の利用を検討するとよいでしょう。

運用上の考慮事項

いくつかの運用上の詳細が、このアーキテクチャを本番環境で健全に保ちます。SAP WebGUI はコールドスタート時に応答まで 30 秒以上かかることがあるため、504 Gateway Timeout エラーを避けるには、CloudFront のオリジン読み取りタイムアウトを少なくとも 60 秒に設定します。カスタムのオリジンリクエストポリシーを使用する場合、CloudFront はビューアーの Host ヘッダーを ALB へ転送するため、ALB と SAP バックエンドの両方がそのホスト名を受け入れることを確認してください。証明書ライフサイクルを事前に計画します。クライアント証明書は有効期限前に更新し（年1回が良い頻度です）、CA をローテーションするたびに S3 トラストストアを更新します。設定変更後は、すべてのエッジロケーションが新しい設定を取得できるよう、/\* に対する CloudFront の無効化（invalidation）を作成します。最後に、すべての ALB サブネットにインターネットゲートウェイへのルートがあることを確認してください。いずれかのアベイラビリティーゾーンでルートが欠落していると、断続的なタイムアウトが発生します。

コストについても計画してください。CloudFront はデータ転送（アウト）とリクエストに対して課金し、ALB は時間あたりの料金に加えて Load Balancer Capacity Units に対して課金します。Amazon CloudFront の料金および Elastic Load Balancing の料金のページを使って支出を見積もってください。

リソースのクリーンアップ

テスト後の継続的な課金を避けるため、作成したリソースを逆の順序で削除します。

  1. CloudFront ディストリビューションを削除します。CloudFront コンソールでまずディストリビューションを無効化し、ステータスが「Deployed」に変わるのを待ってから削除します。
  2. ALB とターゲットグループを削除します。Amazon EC2 コンソールで「ロードバランサー」に移動し、対象の ALB を選択して「削除」を選びます。次に、関連するターゲットグループを削除します。
  3. S3 トラストストアを削除します。S3 バケットから CA 証明書を削除し、この目的のためだけに作成したバケットであれば、バケット自体も削除します。
  4. クライアント証明書を失効させます。AWS Private CA を使用した場合は、発行したクライアント証明書を失効させます。自己署名証明書を使用した場合は、.pem、.key、.p12、.csr ファイルを削除します。
  5. SAP プロファイルパラメータを元に戻します。トランザクション RZ10 で icm/HTTPS パラメータを削除またはリセットします。SAP ICM サービスを再起動します。
  6. このディストリビューションのためだけに作成した場合は、ACM 証明書を削除します。
  7. このディストリビューションのためだけに作成した場合は、AWS WAF ウェブ ACL を削除します。

まとめと次のステップ

シンガポールのあの財務コントローラーに話を戻すと、このアーキテクチャによって、彼女の月次ログインはより速くなり、接続は VPC に到達する前に暗号的に検証され、そして彼女は一度もパスワードを入力しません。本記事では、このパターンを推し進めるお客様の課題と、それらを段階的にどう解決したかを見てきました。認証レイテンシーを下げるためにエッジで mTLS を終端し、静的な SAP コンテンツをキャッシュし、組み込みの DDoS 保護を追加しながら、証明書ベースの ID を SAP バックエンドへ伝搬しました。要点を振り返ると、CloudFront mTLS verify モードはエッジでクライアント証明書をチェックし、不正な接続が VPC に到達する前に拒否します。CloudFront-Viewer-Cert-Pem ヘッダーにより、SAP ICM は直接的な TLS クライアント接続なしで X.509 認証を実行できます。静的な SAP アセットのエッジキャッシュは、グローバルに分散したユーザーのページ読み込み時間を改善します。何より、既存の ALB mTLS パターンと並行して、このソリューションを段階的に採用できます。

このパターンをさらに発展させるには、SAP Fiori ランチパッドアプリケーション向けに CloudFront mTLS を実装してみたり、SAP Gateway OData エンドポイントなど他の SAP サービスに適用してみたりしてください。また、CloudFront Connection Functions と KeyValueStore の統合を検討し、エッジで証明書失効チェックを実装することもできます。

AWS Well-Architected Framework（SAP Lens）のセキュリティのベストプラクティスに従い、証明書とトラストストアを定期的に更新することをお勧めします。

謝辞

貢献してくれた次のチームメンバーに感謝します: Derek Ewell、Adam Hill、Bhuvan Wadhwa。

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