Amazon Web Services ブログ

AWS WAF（Web Application Firewall）によるSAP Fioriのセキュリティ向上

はじめに

SAP S/4HANAを導入するお客様の多くがHTML5をベースしたSAPアプリケーションのUser InterfaceコンポーネントであるSAP Fioriのセキュリティ対策について課題を抱えています。その出発点として、Webアプリケーションの最も重大なセキュリティリスクに関する幅広いコンセンサスを示すThe OWASP Top 10（Open Web Application Security Project）を参照することにします。SAP Fioriのセキュリティリスクを最小化する緩和策として採用することができます。

SAPはセキュリティリスクを軽減するためのセキュアプログラミングガイドを提供していますが、エンドユーザーがビジネスプロセスを実行する時にリソースが常に利用できるようにするためには、WebリクエストがSAP Fioriシステムに到達する前に緩和策が行われていることが望ましいです。今回は、SAP Fioriに到達する前のWebリクエストをフィルタリングするWebアプリケーションファイアウォールであるAWS WAFを紹介します。

WAFでは、カスタマイズ可能なWebセキュリティルールの定義およびAWS Managed Rulesの活用により、SAP FioriへのWebリクエストを許可またはブロックすることができます。AWS WAFのAWS Managed Rulesは、独自のルールを記述することなく、一般的なアプリケーションの脆弱性やその他の望まないトラフィックに対する保護を提供するマネージドサービスです。セキュリティ要件がAWS Managed Rulesを超える場合は、AWS Marketplaceで提供されているマネージドルールを検討することができます。これらのマネージドルールは脅威や脆弱性に関する豊富で最新の知識を持つセキュリティ専門家が作成したものです。詳細はこちらで確認できます。

本ブログでは、AWSをご利用中のSAPのお客様向けに、SAP FioriでAWS WAFとAWS Managed Rulesを導入するためのHow-Toガイドを説明します。これは、関連するブログシリーズ【SAP Fioriのパフォーマンス向上】Amazon CloudFrontとAWS Global Acceleratorの活用とSAP Fioriを多要素認証（MFA)でよりセキュアにの延長線上にあるものです。また、WAFの詳細については、Use AWS WAF to Mitigate OWASP’s Top 10 Web Application VulnerabilitiesとAWS Best Practices for DDoS Resiliencyでご覧いただけます。

ソリューションの概要

SAP Fiori with WAF Architecture

上の図は、Webブラウザーを使っているエンドユーザーとSAP Fioriの間のトラフィックフローを示しています。この簡略化されたアーキテクチャは、AWS WAFとSAP Fioriの導入プロセスを説明するために使用します。本番用に実装するためには、2つのAWS Availability Zoneにまたがる高可用性の設定や、独自のオンプレミスデータセンターへの接続など、要件に応じてこのアーキテクチャをさらに拡張する必要があります。

Application Load Balancer（ALB）は、定義されたWebセキュリティルールに基づいてセキュリティリスクを軽減するために検査できるように、AWS WAFを経由してトラフィックをルーティングします。トラフィックが許可されると、ALBに戻され、バックエンドのSAP Web DispatcherやSAP Fioriに転送されます。

SAP Fioriをグローバルに展開する場合、ここで説明したようにAmazon CloudFrontとAWS WAFを統合することができます。この統合をしますと、エンドユーザーがSAP Fioriシステムを使用可能な時間への影響を軽減するために、CloudFrontのエッジ拠点にAWS WAFの保護を委ねることが可能です。AWS WAFには設定済みのルールやチュートリアルが用意されており、AWS Lambdaを使ってセキュリティを自動化することが可能です。

前提条件

WAFをALBと連携させるので、ALBのターゲットグループを通じて、SAP Web DispatcherまたはSAP Fioriのいずれかを指すように設定する必要があります。詳しい設定方法はこのStep-by-Stepドキュメントを参照してください。

ソリューション実装

  1. AWS CloudFormationを使用し、AWS Security Automation Guideに従ってAWS WAFとAWS Managed Rulesをデプロイします。AWS Security Automation Guide
  2. Specify stack details 画面で、以下のようにパラメータ値を指定して、Next を選択します。CloudFormation Stack Parameters 1CloudFormation Stack Parameters 2
  3. Configure stack options画面でNextを選択し、すべてのパラメーター値を再確認したら、Create Stackを選択します。CloudFormation Acknowledgement
  4. CloudFormationの実行が成功したら、https://console.aws.amazon.com/wafv2/homev2/web-acls にアクセスし、Web ACLsのデプロイが成功したことを確認します。AWS WAF WebACLs
  5. 確認できたら、AWS WAFをAWS Application Load Balancer (ALB)と関連紐づけします。この関連紐づけによって、すべてのトラフックがSAP Fioriに到達する前に、WAFを経由することになります。AWS WAF WebACLs Resource Assignment

ソリューションテスト

このセクションでは、いくつかのサンプル攻撃シナリオを試し、SAP Fioriを保護するためのAWS WAF動作を確認します。この手動テストアプローチの目的は、関連するAWSリソースに対してWAFが有効であることを確認することです。。以下に示したアプローチは、推奨される侵入テストのアプローチではありません。精巧なテストツール不要で複数のシナリオをテストできるように、このブログに限った廉価な方法として適用するものです。

テストの前作業

  1. テスト実施するために、curl, Apache ab tool 及びChromeブラウザ等のツールを使用します。
  2. AWSコンソールを開き、「AWS WAF」、「Web ACLs」の順に移動し、「AWSWAFSecurityAutomations」を選択します。その後、「Custom response bodies」タブに移動し、「Create custom response body」を選択します。                                                                                                         Create Custom Response Body
  3. 以下のように、テキストボックスに適切なカスタムレスポンス内容を入力します。その後、WAF_Responseとして保存します。Custom Response Body
  4. 同じ Web ACL の rules タブから AWSWAFSecurityAutomationsIPReputationListsRule を選択します。この画面で、後でテストするために１つのIPv4 IPアドレスをメモし、編集を選択してください。
    IP Reputation List
  5. 編集画面で、以下のようにこのルールの設定を変更します。例えば：X-Forwarded-Forヘッダーを使ってリクエストの生成元を特定します。Setting X-Forwarded-For header
  6. 同じページのActionセッションでカスタマイズレスポンスのWAF_Responseを選択して、Save ruleを選択します。Setting Response Code
  7. 上記のステップ4~6と同様な方法で、以下のルールのActionセッションを変更します。
    • AWSWAFSecurityAutomationsHttpFloodRateBasedRule
    • AWSWAFSecurityAutomationsSqlInjectionRule
    • AWSWAFSecurityAutomationsXssRule
  8. ルールを保存した後に、以下のように変更した設定が反映されたことを確認できます。Assigning Custom Response

テスト実行

シナリオ１: IP許可/拒否リスト

多くの組織が、スパマー、Malware配布者、ボットネットなど、既知の攻撃者が使うIPアドレスのレピュテーションリストを管理しています。このルールは、これらのレピュテーションリストを活用して、悪意のあるIPアドレスからのリクエストをブロックするのに役立ちます。このシナリオをテストするために、AWS ALB経由でSAP Fioriサーバーにリクエストを行うためにcurlコマンドを使用します。以下で使用するURLはSAP Fioriのログインページですが、これをSAP Fioriアプリケーションの任意のURLに変更することもできます。このリクエストの一部として、AWSWAFSecurityAutomationsIPReputationListsRuleに記載されているIPアドレスのうちの1つをX-Forwarded-Forヘッダー値で指定します。

以下はコマンドラインから実行するリクエストの例です。

curl-v https:///sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html \ -H X-Forwarded-For:124.157.0.1

例のレスポンス：

IP Deny Response

リクエストがブロックされ、WAFから送られてきたカスタムレスポンスを確認できます。

シナリオ2：SQLインジェクション

SQLインジェクションは、ウェブサイトへのアクセスできるように、攻撃者がユーザーIDやパスワードなどの機密情報を取得するために使われる方法です。AWSWAFSecurityAutomationsSqlInjectionRuleは、悪質なSQLコードを含む可能性があるWebリクエストをブロックします。このシナリオをテストするには、Chromeブラウザーでフォーム送信のあるSAP Fioriのページを開きます。例えば SAP Fiori のログインページです。次に、Chrome Developer Tool (ネットワーク)を開きます。

Capturing HTTP Trace

フォームを送信すると、Developerツールで、右クリックでcurl形式のリクエストとレスポンスをコピーできます。

Copying to CURL command

コマンドから実行するリクエストの例：

curl-v https:///sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html \ -H 'authority: <ALB-Host-of-SAP-Fiori>' \
-H 'cache-control: max-age=0' \
-H 'sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90"' \
-H 'sec-ch-ua-mobile: ?0' \
-H 'origin: https://<ALB-Host-of-SAP-Fiori> (https://<ALB-Host-of-SAP-Fiori>/)' \
-H 'upgrade-insecure-requests: 1' \
-H 'dnt: 1' \
-H 'content-type: application/x-www-form-urlencoded' \
-H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36' \
-H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9' \
-H 'sec-fetch-site: same-origin' \
-H 'sec-fetch-mode: navigate' \
-H 'sec-fetch-user: ?1' \
-H 'sec-fetch-dest: document' \
-H 'referer: https://<ALB-Host-of-SAP-Fiori>/sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html' \
-H 'accept-language: en-US,en;q=0.9,bn;q=0.8,hi;q=0.7' \
-H 'cookie: sap-usercontext=sap-client=100; sap-login-<………>' \
--data-raw 'sap-system-login-oninputprocessing=onLogin&sap-urlscheme=&sap-system-login=onLogin&sap-system-login-basic_auth=&sap-client=100&sap-accessibility=&sap-login-XSRF=<………>&sap-system-login-cookie_disabled=&sap-hash=&sap-user=SELECT * FROM USERS --&sap-password=<………>r&sap-language=EN'

このリクエストは、WAF Web ACL のマネージドルールの AWSWAFSecurityAutomationsSqlInjectionRule でブロックされました。前のシナリオと同じカスタムWAF_responseが確認できました。

シナリオ3：XSS攻撃

Cross-Site Scripting（XSS）攻撃は、インジェクションの一種で、信頼できるWebサイトに悪意のあるスクリプトが注入されるものです。この悪意のあるスクリプトは、ブラウザが保持されたそのウェブサイトで使用されているクッキー、セッション・トークン、またはその他の機密情報にアクセスできます。AWSWAFSecurityAutomationsXssRule は、受信リクエストの一般的に探索される要素を検査し、XSS 攻撃を特定し、ブロックします。このシナリオをテストするために、下記のように、JavaScript snippetを埋めるWebリクエストのパラメータを使用することにします。

コマンドから実行するリクエストの例：

curl-v https://<ALB-Host-of-SAP-Fiori>/sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html?query=<script>alert("Bad script")</script>'

このリクエストは、WAF Web ACL のマネージドルールの AWSWAFSecurityAutomationsXssRuleでブロックされました。前のシナリオと同じカスタムWAF_responseが確認できました。

シナリオ4：HTTP Flooding

HTTP Floodingは、非常に短時間で送信される大量のリクエストにより、Webサイトに著しい速度低下を引き起こす、もう1つの攻撃シナリオです。最悪の場合、この攻撃により、ウェブサイトが正当なエンドユーザーからのリクエストに対応できなくなる可能性があります。AWSWAFSecurityAutomationsHttpFloodRateBasedRuleは、クライアントからのWebリクエストが設定可能な閾値を超えるとトリガーされるrate-baseのルールです。このシナリオをテストするために、短時間でWebリクエストを生成できるApache HTTPサーバのベンチマークツール(abコマンド)を使用します。abコマンドを使用して、同じクライアントからサーバーに100の有効なリクエストを送信し、3分毎に再び100のリクエストのセットを繰り返すことを試みます。最初の数回のリクエストでは、ステータスコード200（許可されたリクエスト）のHTTPレスポンスが表示されますが、その後のリクエストでは、ステータスコード2xxクラス以外のHTTPレスポンス、例えば「Forbidden」（ブロックされたリクエスト）の403が表示されることが確認できます。

これは、マネージドルールのAWSWASSecurityAutomationsHttpFloodRateBasedRuleに、5分ごとに評価される最大100リクエスト（rate limit）が含まれているためです。

以下は、許可されたリクエストバッチとブロックされたリクエストバッチの両方からのabコマンドライン出力です。

Allowed requests  Blocked requests, with Non-2xx response
Allowed Requests in AB tool Blocked Requests in AB tool

Sampled Request

ブロックまたは許可された結果はすべて、AWS WAFコンソールのWeb ACLの下にあるSampled Requestsセクションに取り込まれます。ここでは、観測された各トラフィックとルールをさらに監視して深く掘りするために、サンプルされたWebリクエストを表示することができます。

Web ACLs Sampled Requests

WAFの参考コスト計算

SAP FioriにWAFを導入する際のコスト計算の参考として、以下のシナリオを考えてみましょう。

  • 典型的なSAP Fioriアプリケーションでは、Fioriアプリケーションの複雑さにもよりますが、ユーザの1つのトランザクションで約50～150のWebリクエストが発生します。
  • AWS Managed Rules (8 Web ACL、各1ルール)を導入し、他のManaged Rule Groupは導入していない前提とします。
  • 100人のユーザーが1日に約20のドキュメントを作成すると仮定すると、1ヶ月に最大6,000,000のWebリクエストが発生します（= 100 * 20 * 150 * 20）。SAP EarlyWatch Alertsや監査レポートを通じてSAPシステムからの情報があれば、この数字はより正確にわかる可能性があります。
  • AWS Calculatorによると、シンガポールリージョンの場合、参考コストは以下のようになります。
    • 8 Web ACLs/月 x 5.00 USD = 40.00 USD (WAF Web ACLs コスト)
    • Web ACLごとに0ルールグループ × 0ルールグループ＝ 0.00 ルールグループのルール総数
    • 1.00 課金ルール/月 x 1.00 USD = 1.00 USD (WAFルールコスト)
    • 月6リクエスト× 1000000 × 0.0000006 USD = 3.60 USD (WAF Requests cost))
    • 40.00USD + 1.00USD + 1.80USD = 42.80 USDとなります。
    • AWS WAFコスト(月額): 44.60 USD

WAF Security Automationsソリューションのサブセットまたはすべての機能を使用する場合、Amazon Kinesis Data Firehose、Amazon S3、Amazon Lambda、Amazon API Gatewayなど、他のサービスのコストも考慮する必要があります。詳細な価格体系については、こちらを参照してください。

まとめ

SAP FioriにAWS WAFを導入するための詳細な手順について説明しました。SAP Fioriアプリケーションのセキュリティリスクを最小化するために、AWS WAFの使用をお勧めします。AWS WAFは、サイバー攻撃に対してSAP Fioriリソースの過剰な使用を防止し、システムの可用性とパフォーマンスを向上させることができます。AWS WAFのAWS Managed Rulesの活用により、ルールの記述と保守にかかる手作業が軽減されるため、セキュリティ緩和策が加速できます。もし、お客様がAWS Managed Rules for AWS WAF以上のセキュリティ要件を必要とする場合、AWSパートナーが提供する代替ソリューションをAWS Marketplaceからサブスクリプションすることができます。

AWS WAFは、SAP Fioriの保護に加えて、SAP Process Orchestration、SAP Enterprise Portal、SAP API Management、SAP Business Technology Platformなどの他SAPサービスを保護に拡張することがもきます。

SAP on AWSおよびAWS WAFの詳細については、AWSの製品ドキュメントを参照してください。

翻訳はSpecialist SA トゥアンが担当しました。原文はこちらです。