Pages

Wednesday, December 20, 2023

AWS Network FirewallによるSAPの保護: Part 2 – マネージドルール | Amazon Web Services - amazon.com

この投稿は、AWS と Fortinet の以下の担当者が共同で執筆しました:
Ferry Mulyadi, Principal Partner Solution Architect, AWS
Derek Ewell, Principal Partner Solution Architect, AWS
Julian Petersohn, Global SAP Engineer, Fortinet
Fabian Lee, Solution Architect, AWS

CyberCrime の編集長スティーブ・モーガンによると、「 サイバー犯罪は2025年までに年間10.5兆ドルのコストを世界にもたらす」-これは米国、中国に次いで世界第3位の経済規模に相当します。SAP システムにはミッションクリティカルなデータが格納されており、そのデータは機密性が高いことが多いため、悪質のある攻撃者にとって格好の標的となっています。S/4HANA へのモダナイゼーションを進めている SAP のお客様にとって、セキュリティリスクの状況は、SAP Fiori、Web ユーザーインターフェイス、モバイルデバイス、システムインターフェイス、SAP アプリケーションに接続されるクラウドサービスなど、新たな領域に移行しつつあります。このため、SAP のお客様は最終的に、ビジネスクリティカルなエンタープライズシステムに対して、セキュリティアップデート以外の追加のセキュリティ管理を実施する必要に迫られます。SAP のお客様を支援するために、我々は AWS Network Firewall がどのように SAP on AWS デプロイメントに対するセキュリティを向上させることができるかについてブログをシリーズで複数書きました。 最初のブログでは、送受信インターフェース、SAP サポート、リモートユーザー、モバイルアクセス、SAP BTP 統合などの SAP のユースケースに基づいて、SAP のお客様にデプロイ可能な様々なアーキテクチャパターンについて説明しました。このアーキテクチャパターンは、 AWS Security Reference Architecture (SRA)AWS Network Firewall を使った Inspection Deployment Models に基づいており、悪意のある攻撃者が SAP システムのパフォーマンスや可用性に影響を与えるのを防ぎ、SAP システムからのデータ盗難を防ぎます。Customer Obsessionを貫く私たちは、AWS Network Firewall のデプロイ速度を向上させるためにどのような支援ができるか、常にお客様やパートナー様の声に耳を傾けています。私たちが Network Firewall を開発するとき、タスクの 1 つは SAP ネットワークトラフィックをきめ細かく制御するファイアウォール ルールを定義することです。ゼロから始める場合、この作業は大変です。 AWS マネージドルール は、AWS が作成・管理するすぐに使えるルールであり、AWS のお客様が無料で利用できるため、これらのファイアウォール ルールの実装をすぐに始めることができます。また、カスタムルールとパートナーマネージドルールについても説明しますので、組織のセキュリティニーズに合わせてより専門的なルールを導入することができます。このブログでは、Fortinet を招待し、Amazon Network Firewall 用のマネージド IDS と IPS ルールについて共有します。

Network Firewall の AWS マネージドルール

AWS Network Firewall は、柔軟なファイアウォール ルールエンジンを提供し、きめ細かなネットワーク保護を実現します。Network Firewall の AWS マネージドルールは、あらかじめ定義されたすぐに使えるファイアウォール ルールです。新しい脆弱性や脅威が出現すると、AWS は自動的にマネージドルールグループを更新します。

AWS マネージドルールグループは、アプリケーションにセキュリティの別のレイヤーを追加することで、一般的な脅威からエンタープライズワークロードを保護するように設計されています。ただし、AWS マネージドルールグループは、お客様のセキュリティ責任を代替するものではありません。AWS のリソースが適切に保護されていることを確認するには、責任共有モデル を参照してください。

現在、AWS のマネージドルールグループには以下のものがあります:

  • Domain List Rule Groups : HTTP または HTTPS のドメイン名に基づいてトラフィックを識別し、ブロックします。
  • Threat Signature Rule Groups : Threat signature のいくつかのカテゴリに基づいてトラフィックを識別し、ブロックします。

マネージド ドメインリスト ルールグループ (Egress Filtering)

ドメインリストルールは、レピュテーションが低い、またはマルウェアやボットネットとの関連が知られている、または疑われているドメインへの HTTP または HTTPS トラフィックをブロックします。これらのルールグループを「A2. インターネットエグレスアクセスのアーキテクチャ設計パターン」(このブログシリーズのパート1)を使用してこれらのルールグループを展開すると、SAP 環境から発信される疑わしいエグレス トラフィックをブロックできます。

ルール名 説明
AbusedLegitBotNetCommandAndControlDomainsActionOrderRules 一般的には合法的だが、危険でボットネットをホストしている可能性があるドメインのクラスへのリクエストをブロックできるルール
MalwareDomainsActionOrder マルウェアをホストしていることが知られているドメインへのリクエストをブロックできるルール
AbusedLegitMalwareDomainsActionOrder 一般的には合法だが、危険でマルウェアをホストしている可能性があるドメインのクラスへのリクエストをブロックできるルール
BotNetCommandAndControlDomainsActionOrder ボットネットをホストしていることが知られているドメインへのリクエストをブロックできるルール

AWS Network Firewall は、HTTPS の TLS ネゴシエーション中に Server Name Indication (SNI) エクステンションによって、HTTP トラフィックのホストヘッダによってリクエストのドメイン名を決定します。DNS 解決レベルでドメインをフィルタリングするには、Amazon Route 53 Resolver DNS Firewall を Amazon Network Firewall ルールと組み合わせて活用することで、さらに保護することができます。: Amazon Route 53 Resolver DNS Firewall で Amazon VPC の DNS 解決を保護

SAP に適用可能な脅威シグネチャのルールグループ

AWS Network Firewall が管理する脅威シグネチャのルールグループは、様々なタイプのマルウェアやエクスプロイト、サービス拒否、ボットネット、Web 攻撃、クレデンシャルフィッシング、スキャンツール、メールやメッセージング攻撃から保護するために、いくつかのカテゴリの脅威シグネチャをサポートしています。また、侵入検知や公正使用ポリシーの適用、新たな脅威に対する防御のためのシグネチャもあります。現在、Network Firewall は Suricata 互換のステートフル マネージドルールグループのみをサポートしています。
下表のルールは、SAP の技術スタックに有害な既知のシグネチャを持つ悪意のあるリクエストをブロックします。以下のようなルールは SAP のユースケースとは関係ないため除外しています: マルウェアコインマイニング、VOIP、ゲーム、不適切、P2P。実装コストを最適化するために、該当するこれらのルールを事前に選択することができます。

カテゴリ ルール名
Botnet ThreatSignaturesBotnet – アクティブなボットネットやその他のコマンド&コントロール(C2)ホストの既知および確認された複数のソースから自動生成されたシグネチャ
Botnet Web ThreatSignaturesBotnetWeb – HTTP ボットネットを検出するシグネチャ
Compromised ThreatSignaturesIOC –  攻撃レスポンス – LMHost ファイルのダウンロード、特定のウェブバナーの存在、Metasploit Meterpreter kill コマンドの検出など、侵入を示すレスポンスを識別するためのシグネチャ
エクスプロイトキット – エクスプロイトキットやそのインフラストラクチャ、配信に関連する活動を検知するためのシグネチャ
DoS ThreatSignaturesDoS – サービス拒否(DoS)の試みを検出するシグネチャ
Emerging Threats ThreatSignaturesEmergingEvents – 現在のイベント – 活発で短期間のキャンペーンや、一時的なものと予想される注目度の高い項目に対応して開発されたルールを持つ署名
DoS ThreatSignaturesDoS – サービス拒否(DoS)の試みを検出するシグネチャ
Exploits ThreatSignaturesExploits – エクスプロイト – 特定のサービス・カテゴリでカバーされていない直接的なエクスプロイトから保護するシグネチャ。ActiveX、FTP、ICMP、NetBIOS、リモート・プロシージャ・コール(RPC)、ShellCode(リモート・シェルコード検出)、SNMP(Simple Network Management Protocol)、Telnet、TFTP(Trivial File Transport Protocol)、SQL(Structured Query Language)
Malware ThreatSignaturesMalware – マルウェアを検出するシグネチャ(TCP、UDP、SMTP、ICMP、SMB、IP)および WORM。マルウェア – 悪意のあるソフトウェアを検出します。このカテゴリのルールは、ネットワーク上で検出された悪意のあるソフトウェアに関連するアクティビティを検出します。ワーム – 脆弱性を悪用してインターネット全体またはネットワーク内に自動的に拡散しようとする悪意のあるアクティビティを検出します。
Malware Mobile ThreatSignaturesMalwareMobile – Google Android、Apple iOS などのモバイルおよびタブレット OS に関連するマルウェアを示すシグネチャ
Malware Web ThreatSignaturesMalwareWeb – HTTP と TLS プロトコルの悪意のあるコードを検出するシグネチャ
Phishing ThreatSignaturesPhishing – クレデンシャルフィッシング活動を検出するシグネチャ
Scanners ThreatSignaturesScanners – Nessus、Nikto、その他のポートスキャンツールなどのツールからの偵察やプロービングを検出するシグネチャ。ユーザーエージェント – 不審なユーザーエージェントや異常なユーザーエージェントを検出するシグネチャ
Web Attacks ThreatSignaturesWeb – ウェブクライアント – ウェブブラウザや CURL、WGET などのクライアント側アプリケーションなどのウェブクライアントに関する攻撃や脆弱性を検出するシグネチャ。ウェブサーバー – APACHE、TOMCAT、NGINX、Microsoft Internet Information Services(IIS)、その他のウェブサーバーソフトウェアなどのウェブサーバーインフラストラクチャに対する攻撃を検出するシグネチャ。Web Specific Apps – 特定のWeb アプリケーションの攻撃や脆弱性を検出するシグネチャ。

AWS マネージドルールによる AWS Network Firewall のテスト

AWS マネージドルールを実装した後、ルールの検証を行いたい場合があります。以下のようなことができます:

  • ThreatSignaturesWeb ” ルールを例にしてみましょう。
  • AWS Network Firewall によってトラフィックが検査される Fiori を提供する SAP サーバーがある場合、curlmetasploit などのツールを使って、ウェブサーバーのクエリセグメントにペイロードを注入してみることができます。このブログの例を参考にしてください。
  • CloudWatch Logs Log Group でアラートの Log Destination にマッチするものが表示され始めます。
  • 次に、シグネチャを識別子として使用することで、一致する AWS Network Firewall マネージドルールを検索することができます。以下に例を示します:
"alert": {
            "action": "blocked",
            "signature_id": 2811788,
            "rev": 7,
            "signature": "ipTIME firmware < 9.58 RCE",
            "category": "Web Application Attack",
            "severity": 1,
            "metadata": {
                 "created_at": [
                    "2015_07_03"
                ],
                "updated_at": [
                    "2020_10_01"
                ]
            }
        },
        "http": {
            "hostname": "54.179.180.129",
            "http_port": 80,
            "url": "/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh",
            "http_user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36",
            "http_method": "POST",
            "protocol": "HTTP/1.1",
            "length": 0
        },
        "files": [
            {
                "filename": "/bin/sh",
                "sid": [],
                "gaps": false,
                "state": "CLOSED",
                "stored": false,
                "size": 33,
                "tx_id": 0
            }
        ],
        "app_proto": "http"
    }

カスタム ファイアーウォール ルール

AWS Network Firewall は、2つのルールエンジンを使用してパケットを検査します。エンジンは、ファイアウォールポリシーで設定されたルールに従ってパケットを検査します。

  • ステートレス ルールエンジン – トラフィックの方向や、パケットが既存の承認された接続の一部であるかどうかなどの要素を考慮することなく、各パケットを個別に検査します。ネットワークファイアウォールのステートレスルールは、Amazon VPC のネットワークアクセスコントロールリスト( ACL )と動作や使い方が似ています。
  • ステートフル ルールエンジン – パケットをトラフィックフローのコンテキストで検査し、より複雑なルールを使用することができ、ネットワークトラフィックを記録し、トラフィックに関する Network Firewall アラートを記録することができます。ステートフルルールはトラフィックの方向を考慮します。ステートフルエンジンは、オープンソースの侵入防御システム(IPS)である Suricata と互換性のあるルールを使用します。詳細については、AWS Network Firewall のステートフル ルールグループを使用するを参照してください。

以下のブログを参考に、独自のファイアウォールルールを作成することができます:

SAP アプリケーションに関連するルールの例:

#These example Firewall Rules will alert SQL injection attempts to SAP MaxDB Sybase database as well as SAP Netweaver AS Java Use Case
#alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE SAP MaxDB error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"SQL error"; fast_pattern; content:"POS("; distance:0; pcre:"/SQL error.*POS\([0-9]+\)/m"; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020545; rev:2;)
#alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE SAP MaxDB error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"Warning"; content:"maxdb"; fast_pattern; distance:0; pcre:"/Warning.*maxdb/m"; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020546; rev:2;)
#alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE Sybase error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"Warning"; content:"sybase"; fast_pattern; distance:0; pcre:"/i?Warning.*sybase/m"; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020547; rev:3;)
#alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE Sybase error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"Sybase message"; fast_pattern:only; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020548; rev:2;)
#alert http $HTTP_SERVERS any -> $EXTERNAL_NET any (msg:"ET ATTACK_RESPONSE Sybase error in HTTP response, possible SQL injection point"; flow:from_server,established; file_data; content:"Sybase Server message"; fast_pattern:only; threshold:type both,track by_src,count 1,seconds 60; classtype:web-application-attack; sid:2020549; rev:2;)
alert http any any -> $HOME_NET any (msg: "ATTACK [PTsecurity] SAP NetWeaver AS Java UDDI 7.11-7.50 SQL Injection (CVE-2016-2386)"; flow: established, to_server; content: "POST"; http_method; content: "/UDDISecurityService/UDDISecurityImplBean"; http_uri; fast_pattern; content: "permissionId"; http_client_body; content: "|27|"; http_client_body; distance: 0; pcre: "/permissionId\s*>[^<]+?\x27/Pi"; reference: cve, 2016-2386; reference: url, github.com/vah13/SAP_exploit; classtype: attempted-recon; reference: url, github.com/ptresearch/AttackDetection; sid: 10002408; rev: 1; )

パートナー マネージド ルール

セキュリティのニーズがすぐに利用できる AWS マネージドルールを超えている場合、パートナーの提供するソリューションを活用することができます。このブログでは、AWS パートナーである Fortinet のマネージド IDS と IPS ルールを取り上げます。
Fortinet Managed IPS Rules for AWS Firewall は、AWS Network Firewall のための設定済みのルールセットを提供し、様々なネットワーク攻撃を検知、防止するように設計されています。これらのルールは、既知の脆弱性やエクスプロイト、Web アプリケーション攻撃だけでなく、従来のセキュリティ対策では検出が困難な未知のエクスプロイトであるゼロデイ攻撃からも保護するために使用できます。
Fortinet のマネージド IPS ルールは、FortiGuard Labs が提供する最新の脅威インテリジェンスデータに基づいて定期的にメンテナンスされ、最新の脅威からお客様の環境を確実に保護します。これは、機密データが保存されているため攻撃者の標的になりやすい SAP ランドスケープにとって特に重要です。
お客様の導入要件を満たすために、複数のグループセットが用意されています。これらのルールセットは以下の通りです:

Name Technical Name
クライアントの脆弱性 Fortinet-ips-client-enable-rulegroup1
Fortinet-ids-client-alert-rulegroup1
マルウェア検出 Fortinet-ips-malware-enable-rulegroup1
Fortinet-ids-malware-alert-rulegroup1
サーバおよびOSの脆弱性 Fortinet-ips-serveros-enable-rulegroup1
Fortinet-ips-serveros-enable-rulegroup2
Fortinet-ids-serveros-alert-rulegroup1
Fortinet-ids-serveros-alert-rulegroup2
Web クライアントの脆弱性 Fortinet-ips-webclient-enable-rulegroup1
Fortinet-ids-webclient-alert-rulegroup1
Webアプリケーションの脆弱性 Fortinet-ips-webapp-enable-rulegroup1
Fortinet-ids-webapp-alert-rulegroup1
Webサーバの脆弱性 Fortinet-ips-webserver-enable-rulegroup1
Fortinet-ids-webserver-alert-rulegroup1

 ルールの各セットは、侵入検知シグネチャと侵入防止シグネチャの2つのサブセットで構成されます:

  • 侵入防御シグネチャ(IPS)は DROP または ALERT アクションを実行できる
  • 侵入検知シグネチャ(IDS)は ALERT アクションしか実行できない。

全体として、AWS Firewall 用 の Fortinet Managed IPS Rules は、SAP ランドスケープに追加のセキュリティレイヤーを提供し、ビジネスクリティカルなデータとアプリケーションの保護に役立ちます。
Fortinet Managed Rules for AWS Firewall のセットアップと検証方法の詳細については、管理ガイドを参照してください。

SAP 専用の侵入防御シグネチャルール

Fortinet は、SAP 専用にカスタマイズされたマネージド AWS ネットワークファイアウォール ルールのほか、ファイアウォール、エンドポイントプロテクション、クラウドセキュリティサービスなど、さまざまなセキュリティソリューションを提供しています。これらのソリューションは高度な脅威の検知と防止機能を提供し、既知の脅威から新たな脅威まで、幅広い脅威から SAP システムを保護します。
Fortinet は、SAP アプリケーションに特化した攻撃や悪意のある動作を防止するために、60 種類以上(さらに増加中)のシグネチャを提供しています。これらのシグネチャは、Fortinet が提供するマネージド IPS ルールの一部です。

Figure 1.  Fortinet マネージド IPS ルールにおける SAP 固有のシグネチャの例

 複雑さを避けるため、これらの署名は提供されたルールグループに分散されます。SAP 導入の安全性を確保するには、以下のルールグループが非常に重要であります。

  • サーバおよびOSの脆弱性
  • Webアプリケーションの脆弱性
  • Webサーバの脆弱性
  • クライアントの脆弱性
  • マルウェア検出

どのルールグループがあなたのユースケースに関連するかを確認するには、管理ガイドのユースケースのセクションを参照してください。例えば AWS 上の SAP S/4 HANA デプロイメントの場合、以下のルールグループが該当します: サーバーと OS の脆弱性、Web サーバーの脆弱性、Web アプリケーションの脆弱性。

  • サーバおよびOSの脆弱性ルールグループは、オペレーティングシステムと SAP Web Dispatcher、RFC (Remote Function Call) Gateway などの SAP サービスに対する攻撃を防ぎます。
  • SAP が SAP Web ベースのフロントエンド Fiori に移行するにつれて、HTTP(s) リクエストは OWASP Top 10 (Open Web Application Security Project) に対して保護される必要があります。このような HTTP(s) リクエストを保護するために、AWS WAF や Forti Web のような Web Application Firewall を実装することを強く推奨します。このような Web Application Firewall は、SQL インジェクションやクロスサイトスクリプティングを特定するために、HTTP ヘッダー、HTTP ボディ、URI 文字列、ペイロードなど、OSI モデルのレイヤー 7 の情報を分析するように設計されています。前述の Web サーバの脆弱性および Web アプリケーションの脆弱性管理ルールグループは、このようなシナリオにおいて基本的な Web 保護を提供します。
  • AWS 上の SAP S/4HANA デプロイメントを保護するコンテキストでは、クライアントの脆弱性ルールグループは使用されません。このルールグループは、Chrome ブラウザや SAP GUI のようなクライアントソフトウェアに対する攻撃をブロックすることにのみ有効であり、サーバーコンポーネントに対する攻撃を防ぐことはできません。SAP  デプロイがクライアントとして機能する場合、たとえば、送信トラフィック( エグレス トラフィック)の保護とフィルタリングを行う場合は、クライアントの脆弱性および マルウェア検出ルールグループが関連します。

これらのルールセットは、FortiGuard Labs の脅威インテリジェンスから定期的に更新されるため、含まれるシグネチャの数は時間の経過とともに増加し、新しい攻撃をブロックするルールが含まれるようになります。

SAP 環境で AWS Network Firewall を使用する際の設計と使用上の考慮点

AWS 上の SAP デプロイメントに AWS Network Firewall を実装する前に、いくつかの要因を考慮することが不可欠であります。

  • ユースケースに応じて、AWS WAF、AWS Network Firewall、Amazon VPC セキュリティグループの組み合わせを使用することを検討してください。AWS Web Application Firewall (WAF) は、Application Load Balancer (ALB)、Amazon API Gateway、または Amazon CloudFront によってフロントされる HTTP ベースのトラフィックに対してレイヤー 7 の保護を提供します。
  • AWS Firewall Manager は、AWS 組織内の AWS リージョン、アカウント、リソースにまたがるファイアウォールルールの設定とデプロイを行うための中心的な場所として機能するセキュリティ管理サービスです。Firewall Manager は、新しいアカウントやリソースが作成された場合でも、すべてのファイアウォールルールが一貫して適用されるようにします。Firewall Manager は、AWS Network Firewall、Amazon Route 53 Resolver DNS Firewall、AWS WAF、AWS Shield Advanced、Amazon VPC セキュリティグループと統合されています。
  • 正当なトラフィックをブロックしないように、常にテストを実施してください。AWS マネージド ルール グループをカスタマ マネージド ルール グループにコピーし、含まれるルールのライフサイクルをカスタマイズまたは制御することができます。ベストプラクティスとして、本番環境に適用する前に、まずステージング環境に AWS およびパートナー マネージド ルールを実装してテストすることをお勧めします。これにより、これらの新しいルールを SAP 環境に追加した場合の影響を理解し、適切にカスタマイズすることができます。AWS Network Firewall は、”alert mode ” を介してルールとトラフィック間の相互作用の観測可能性を提供します。これにより、ルールを削除する代わりに、ルールの一致をアラートすることで、ルールをテストすることができます。AWS マネージド ルール グループについては、これを実装するためのステップバイステップの手順がここにあります。Fortinet マネージドルールには、IPS と IDS のバージョンがあります。IDS ルールは、ルールの一致に対してアラートを発するため、テストに使用できます。
  • ネットワークファイアウォール ルールと IPS シグネチャは、パフォーマンスに悪影響を及ぼす可能性があります。AWS ネットワークファイアウォール ルールの数は、検査のパフォーマンスに影響を与えます。これらのルールは、ネットワークトラフィックをリアルタイムで分析して動作するため、ネットワークトラフィックの処理が遅くなり、SAP アプリケーションのパフォーマンスに悪影響を及ぼす可能性があります。このため、SAP Application と Database コンポーネント間のネットワークトラフィックを検査することは推奨されません。
  • イングレス トラフィック インスペクションとエグレス トラフィック インスペクション。 ネットワークファイアウォールによるイングレス トラフィック フィルタリングは、外部からネットワークに侵入する脅威の検出と防止に重点を置いています。一方、エグレス トラフィッ ク フィルタリングは、データの盗難/流出やその他の悪意のある行為など、ネットワークから出ようとする脅威の検出と防止に関係します。SAP システムはクライアントとして機能することができ(例:アウトバウンド Web インターフェース)、関連する エグレストラフィック検査が適用されることに留意してください。

まとめ

AWS Network Firewall 用のすぐに使える AWS マネージドルールが、よく知られた攻撃から SAP 環境を保護するのに役立つことを説明しました。これは、カスタム ファイアウォール ルールを実装し、維持するためのオーバーヘッドを削減しながら、この保護を提供します。セキュリティのニーズが既存の AWS マネージドルールでカバーできない場合は、Fortinet などの AWS パートナーによるソリューションで補完することができます。
Fortinet は、AWS 上のSAP デプロイメントを保護するために特別に設計されたさまざまな Fortinet Managed IPS ルールなど、SAP デプロイメント専用のセキュリティサービスとサポートを提供しています。これらの IPS ルールは、ターゲットを絞った脅威の検出と防止機能を提供し、既知の脅威や新たな脅威から SAP システムを保護します。SAP セキュリティに対する Fortinet の取り組みは、重要なビジネスシステムを保護することの重要性を強調し、SAP 環境特有のニーズに合わせた専用のセキュリティソリューションの必要性を浮き彫りにしています。
要約すると、AWS Network Firewall は、不審なネットワークトラフィックを検査して遮断することで、AWS 上の SAP ワークロードの安全を確保し、柔軟なステートレスおよびステートフル ルールエンジンを提供することで、新たな脅威から SAP システムを保護することができます。AWS 上の安全でパフォーマンスの高い SAP デプロイメントにより、SAP ユーザーはミッションクリティカルなビジネスプロセスを完了することができます。
SAP on AWS と AWS Network Firewall の詳細については、AWS 製品のドキュメントをご覧ください。
Fortinet  の詳細については、Fortinet の SAP セキュリティソリューションと、Fortinet が重要な SAP エンタープライズ環境の保護にどのように役立つかをご覧ください。

Adblock test (Why?)


からの記事と詳細 ( AWS Network FirewallによるSAPの保護: Part 2 – マネージドルール | Amazon Web Services - amazon.com )
https://ift.tt/ZX6AKu0

No comments:

Post a Comment