# セキュリティ
このセキュリティの柱では、データ、システム、資産を保護して、クラウドテクノロジーを活用してセキュリティを強化する能力について説明します。このレンズは、SAP のいくつかの中核的な原則とリソースをハイライトします。これらのプラクティスの多くは SAP に固有ではないため、エンタープライズの中核的な原則を考慮し、環境全体でのコントロールを確立することに重点を置くことをお勧めします。それらの [セキュリティの柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) には、幅広い設計原則とレコメンデーションが含まれます。この後の SAP ガイダンスと併せて読むことを強く推奨します。
デプロイ戦略が、AWS ベース、オンプレミス、またはハイブリッドのいずれでも 、SAP セキュリティノートおよびニュースで推奨されるガイドラインに従い、SAP ワークロード特有の最新のセキュリティレコメンデーションを把握するようにします。
# 5 – セキュリティスタンダードとそれがどのように SAP ワークロードに適用されるかを理解する
**SAP ワークロードの重要性と整合するセキュリティスタンダードとコントロールをどのように定義しますか?** スタンダードは、製品、組織、業界、または法域のベストプラクティスに従って、システムをセキュリティで保護するために必要なポリシーと手順を定義する公開されたドキュメントです。SAP ワークロードを評価するためのフレームワークを提供します。一部のスタンダードは、規制要件のコンプライアンスを満たすために必須であり、その他は任意ですが、ロールと責任を確立する役に立ちます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-5.html)
# ベストプラクティス 5.1 – セキュリティロールと責任を定義する
SAP ワークロードをセキュリティで保護するための要件を定義することで、対応が必要なリスクを特定でき、セキュリティ関連のロールと責任が適切に割り当てられていることを確認できます。この提案では、AWS、SAP、およびセキュリティ戦略を構築できるベースラインを形成するためのサービスプロバイダーについて説明します。
**提案 5.1.1 - AWS 責任共有モデルを理解する**
AWS はクラウドのセキュリティに責任があり、お客様は、クラウドでのセキュリティに責任があります。以下のリソースを確認して理解します。
+ AWS ドキュメント: [AWS 責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ AWS ドキュメント: [AWS Response to Abuse and Compromise (不正使用と侵害に対する AWS の対応)](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/abuse-and-compromise.html)
+ AWS ドキュメント: [AWS Acceptable Use Policy (AWS 適正利用規約)](https://aws.amazon.com/aup)
AWS 責任共有モデルのコンテキストでお客様とお客様のパートナーとの間での責任の分担を理解します。
**提案 5.1.2 - コンプライアンス証明書、レポート、証明を含む、SAP と AWS にまたがるセキュリティ基盤を理解する**
SAP と AWS がサポートするセキュリティスタンダードとコンプライアンス認定を理解します。自分の業界や国にどれが関連するかを判断します (例えば、PCI-DSS、GDPR、HIPAA)。これらのコントロールは、コンプライアンスと認定プログラムを強化し、セキュリティスタンダードに適合するために必要な取り組みを削減します。
詳細については、以下の SAP および AWS ドキュメントを参照してください。
+ AWS ドキュメント: [AWS コンプライアンス](https://aws.amazon.com/compliance)
+ AWS ドキュメント: [AWS コンプライアンスセンター](https://aws.amazon.com/financial-services/security-compliance/compliance-center/)
+ AWS ドキュメント: [コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)
+ AWS ドキュメント: [コンプライアンスプログラムによる AWS 対象範囲内のサービス](https://aws.amazon.com/compliance/services-in-scope/)
+ SAP ドキュメント: [Trust Center](https://www.sap.com/about/trust-center.html)
**提案 5.1.3 - SAP ワークロードをサポートするサービスプロバイダーのセキュリティ基盤を評価する**
サードパーティー組織に依存してすべてまたは一部の SAP ワークロードを管理している場合、必要なセキュリティコントロールに適合するサードパーティーの能力を評価します。これには、エンタープライズにより義務づけられるリーガルおよび規制要件が含まれます。
# ベストプラクティス 5.2 – SAP ワークロード内のデータを分類する
データの機密性はリスクを軽減するために必要なコントロールに影響する可能性があります。AWS では、業界または組織内のスタンダードフレームワークを参照して採用し、SAP ワークロードとその中に含まれるデータを分類することをお勧めします。
**提案 5.2.1 - データ分類と処理要件を決定する**
組織に既に整備されているデータ分類フレームワークを特定します。これらのフレームワークは、機密性、整合性、可用性を保護する必要があるデータなど、情報の重要度に基づいてデータを分類するのに役立ちます。スタンダード分類モデル、例えば [US 情報分類スキーム](https://docs.aws.amazon.com/whitepapers/latest/data-classification/u.s.-information-categorization-scheme.html) が存在し、業種、ビジネスまたは IT 要件に基づいてカスタマイズできます。
分類に適切なガイドラインに従って、データを処理する方法を理解します。これには、スタンダードまたは規制要件 (例えば、PCI-DSS または GDPR) および一般的なプライバシーの考慮事項 (例えば、個人識別情報 (PII) の処理) に関連した具体的なセキュリティコントロールが含まれます。以下のドキュメントは次の追加情報を提供します。
+ AWS ドキュメント: [データ分類: 安全なクラウド導入ホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification-overview.html)
+ AWS ドキュメント: [一般データ保護規則 (GDPR) センター](https://aws.amazon.com/compliance/gdpr-center/)
+ [情報システムと組織のための NIST セキュリティとプライバシーコントロール](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)
+ [ISO 27001 – 付録 A.8: アセット管理](https://www.iso.org/isoiec-27001-information-security.html)
+ Well-Architected Framework [セキュリティ]: [データ保護](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-data-protection.html)
**提案 5.2.2 - 特定の処理ルールで SAP のデータタイプを識別する**
SAP システムにサポートされているビジネスプロセスに基づいて、データの処理とストレージに要件がある可能性があります。場所と業界向けのガイダンスを使用してよく理解します。SAP の例には以下が含まれる可能性があります。
+ 保存されたカード所有者データを保護し、PCI コンプライアンスを確保するためにデジタル決済アドオンが必要かどうかを評価します。
+ 例えば、一部の国や法域では、特定の地理的場所に保存することが要求されるなど、HR データのデータレジデンシー要件を評価します。
+ 機密データが見えないようにしつつ、データの整合性を維持するために、非本番稼働環境システムでどのデータを暗号化する必要があるかを検討します。
**提案 5.2.3 - 定義されたフレームワークに従ってすべてのワークロードを分類する**
ビジネスの使用と重要なデータタイプの存在に従って、SAP システムを分類します。SAP ERP などのトランザクションシステムは、SAP BW などの分析的システムまたは Solution Manager などの管理システムより機密データを含む可能性が高いと考えられますが、機能およびセキュリティのエキスパートによる確認が必要です。
さらに、同じコントロールが非本番稼働環境ワークロードに適用されるかどうかを評価します。例えば、非本番稼働環境ワークロードには本番稼働データが含まれていて、同じセキュリティコントロールに従う必要はありますか?
# ベストプラクティス 5.3 – SAP ワークロードの特定のセキュリティコントロールの必要性を評価する
データ分類に基づいて、以前のベストプラクティスで確立されたスタンダードと要件に適合するために役立つコントロールを評価します。これには、ロケーション、AWS アカウント戦略と非本番稼働用 SAP ワークロードのスクランブル要件が含まれます。
**提案 5.3.1 - 地理的な場所要件を評価する**
SAP ワークロードは、1 つまたは多数の AWS リージョンとアベイラビリティーゾーン (AZ) でデプロイされる可能性があります。各 AWS リージョンは、1 つの地理的領域内にある、複数の、隔離され、物理的にも分かれている AZ で成り立っています。レイテンシーと回復性についてリージョンを評価することに加え、セキュリティとコンプライアンス要件に適合できるかどうかを検討する必要があります。特定の運用管轄地域がある隔離されたリージョンの例には以下が含まれます。
+ AWS GovCloud (US) - 機密データ、規制されたワークロードをホストし、最も厳格な米国政府のセキュリティとコンプライアンス要件に対応するように設計されています。
+ 中国でのアマゾン ウェブ サービス - AWS は地元のパートナーと連携して、中国のリーガル要件と規制要件に適合するようにしています
一部の業界と国には、IT システムで処理および格納されるすべての顧客コンテンツは特定の国の国境内にとどまらなければならないというデータレジデンシー要件があります。
+ AWSドキュメント: [Addressing Data Residency with AWS (AWS によるデータレジデンシーへの対応)](https://aws.amazon.com/blogs/security/addressing-data-residency-with-aws/)
場所に関する決定を下す前に、その AWS リージョンのサービスの可用性をレビューして、必要なサービスが使用できることを確認してください。
+ AWSドキュメント: [リージョン別のサービス](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)
**提案 5.3.2 - SAP ワークロードに対して必要な AWS アカウント戦略を決定する**
AWS で SAP ワークロードを運用するときの重要な考慮事項は、組織のセキュリティ管理に応じて採用する AWS アカウント戦略です。SAP を SAP 以外のワークロードから切り離し、生産を生産以外のものとは別のアカウントで行うことを考慮する必要があります。
AWS 組織と AWS Control Tower の使用も含め、組織の既存の AWS アカウント管理戦略を理解します。セキュリティ機能とログ機能を別々のアカウントに分離することを検討します。詳細については、以下を参照してください。
+ Well-Architected Framework [セキュリティ]: [AWS アカウントの管理と分離](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/aws-account-management-and-separation.html)
+ AWSドキュメント: [ベストプラクティスの AWS 環境を確立する](https://aws.amazon.com/organizations/getting-started/best-practices/)
+ AWSドキュメント: [Organizing Your AWS Environment Using Multiple Accounts (複数のアカウントを使用した AWS 環境の組織化)](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/advanced-organization.html)
採用するアカウント戦略は、AWS 内のネットワーク構成にも影響を与えます。SAP ワークロードに応じた適切な AWS アカウント戦略を決定する一環として、以下のことを考慮する必要があります。
+ 非生産システムと生産システム間の通信を可能にするための、 [VPC ピアリング](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) または [Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html) のセットアップの必要性などのクロスアカウントアクセスの要件。例えば、環境内の SAP トランスポートの移動。
+ SAP ワークロードから異なる AWS アカウントでデプロイされる共有サービス (ディレクトリ管理リソースなど) とネットワーク管理コンポーネントに対する依存性。
**提案 5.3.3 - データスクランブリングのコントロールをレビューする (該当する場合)**
SAP のお客様の多くは、回帰テストや性能テストも含め、テスト目的で製品データのコピーに依存しています。生産データのコピーを作成する場合は、生産データを意図しないアクセスや改変から保護するために追加しなければならないコントロールを決定してください。
以下のオプションを考慮してください。
+ SAP またはサードパーティープロバイダーから提供される従来のデータスクランブリングメカニズム
+ 生産データのコピー時にアクセスを制限するための追加のアカウントまたはネットワークコントロールの使用
+ 生産用と同じコントロールでの非生産アカウントの使用
# ベストプラクティス 5.4 – セキュリティコントロールの実装戦略を作成する
データ分類に基づくビジネス要件を評価した後、より幅広い組織のセキュリティコントロールと、入手可能なアプリケーションガイドおよびオープン標準のバランスを取る戦略を作成します。実装の労力を考慮に入れ、リスクを確認します。
**提案 5.4.1 - リスクを評価するためのマトリックスを特定する**
特定の業界や地域向けのさまざまなリスク管理フレームワークがあります。組織によって採用されたリスクフレームワークと、これを SAP ワークロードに関連するリスクの管理に適用する方法を理解します。
+ AWSドキュメント: [リスクマトリックスの例](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/governance.html)
+ AWSドキュメント: [Scaling a governance, risk, and compliance program for the cloud (ガバナンス、リスク、およびコンプライアンスプログラムのクラウド向けのスケーリング)](https://aws.amazon.com/blogs/security/scaling-a-governance-risk-and-compliance-program-for-the-cloud/)
+ [NIST リスクマネジメントフレームワーク](https://www.nist.gov/cyberframework/risk-management-framework)
**提案 5.4.2 - 組織によって義務づけられているセキュリティおよびコンプライアンス要件を評価する**
クラウドセンターオブエクセレンス、リーガルチーム、コンプライアンスチーム、およびマネージドサービスプロバイダーに相談して、セキュリティベースラインとコントロールの実施方法を理解します。これらのコントロールのすべてを SAP ワークロードに容易に適用できるかどうか、また、例えば、AWS サービスの許可リストと拒否リスト、インバウンドおよびアウトバウンドトラフィックフローとアクセス制限など、例外を必要とする分野を特定できるかどうかを評価します。
**提案 5.4.3 - 例外プロセスを特定し、合意する**
状況によっては、SAP 用のソフトウェア、ビジネス、またはサポート要件により、標準的なセキュリティパターンからの逸脱が必要になることがあります。例外について変更諮問委員会またはセキュリティ設計機関との合意と文書化が必要なプロセスを特定し、プロセスを定期的に再評価します。
AWSドキュメント: [Change Management in the Cloud (クラウドにおける変更管理)](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
# 6 – インフラストラクチャおよびソフトウェアコントロールを使用して、セキュリティの構成ミスを軽減する
**SAP アプリケーションと基盤となるデータベース、オペレーティングシステム、ストレージ、およびネットワークをどのように保護しますか?** SAP ソフトウェアと、オペレーティングシステムおよびデータベースのパッチ、パラメータ、クラウドサービス、およびインフラストラクチャなど、関連する基盤構成を強化することをお勧めします。強化は、組織によって決定された適切なレベルでの、生産と非生産の両方を含むあらゆる SAP 環境の安全性の確保に役立ちます。
コミットメント割引を適用する機会を見つけるために、 [AWS 責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/) SAP 環境のセキュリティに関するアクティビティをガイドします。例えば、EC2 インスタンスのファームウェアアップデートは、AWS が責任を持つ「クラウドのセキュリティ」アクティビティですが、同じ EC2 インスタンスでも、オペレーティングシステムとアプリケーションの管理は、お客様が責任を持つ「クラウドでのセキュリティ」アクティビティです。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-6.html)
詳細については、次の情報を参照してください。
+ AWSドキュメント: [AWS のセキュリティホワイトペーパー](http://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf)
+ SAP Note: [2191528 - Third-party report showing security vulnerabilities (セキュリティの脆弱性を示すサードパーティーレポート)](https://launchpad.support.sap.com/#/notes/2191528) [SAP ポータルへのアクセス権が必要]
+ SAP ドキュメント: [ABAP Platform Security Guide](https://help.sap.com/viewer/621bb4e3951b4a8ca633ca7ed1c0aba2/LATEST/en-US/4aaf6fd65e233893e10000000a42189c.html)
# ベストプラクティス 6.1 – セキュリティと監査が SAP ネットワーク設計に組み込まれていることを確認する
SAP ワークロードをホストするネットワークへのアクセスを保護することは、悪意あるアクティビティに対する防御の最前線です。ビジネス要件と特定の SAP ソリューションを評価して、有効にする必要があるポート、プロトコル、およびトラフィックパターンを決定します。組織のセキュリティスタンダードと、ネットワーク設計を単純化するために使用できるツールおよびパターンを検討します。定期的に、または変更が発生するたびに監査します。
**提案 6.1.1 – SAP のネットワークトラフィックフローを理解する**
まず、トラフィックフローを理解します。SAP ワークロードのネットワークトラフィックパターンは、インバウンドトラフィック、アウトバウンドトラフィック、および内部トラフィックに分類できます。ソースとデスティネーションが信頼できるネットワーク境界内にあるかどうかを特定して、ルールセットの定義を支援する必要があります。
ユーザーアクセスやインターフェイス接続など、既知のインバウンドトラフィックフローとアウトバウンドトラフィックフローに加えて、SAP サポートへの接続 (SAProuter 経由) や、ソース IP アドレスに基づいてアクセスを制限する SAP SaaS サービスなど、SAP 固有の要件を考慮します。
内部トラフィックについては、コンポーネントおよびシステム間のトラフィックの他、AWS と共有サービス間のトラフィックを考慮します。次のようなツール [VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) と [VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) は、Amazon VPC へのトラフィックフローと Amazon VPC からのトラフィックフローの理解に役立ちます。
詳細については、次の情報を参照してください。
+ SAP ドキュメント: [TCP/IP Ports for All SAP Products](https://help.sap.com/viewer/ports)
**提案 6.1.2 – トラフィックフローの許可と拒否のオプションを評価する**
まず、SAP システムが運用されている AWS アカウントにオンプレミスネットワーク内のユーザーとシステムをどのように接続するかを理解します。これについては、 [「ネットワークから Amazon VPC への接続オプション」で説明されています](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html) .
VPC へのネットワークトラフィックと VPC からのネットワークトラフィックのフローを制御するための 2 つの主な方法として、 [セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) と [ネットワークアクセスコントロールリスト](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) (ネットワーク ACL) の使用があります。セキュリティグループは、EC2 インスタンスレベルで仮想ファイアウォールの役目を果たし、インバウンドおよびアウトバウンドトラフィックを制御し、ステートフルです。ネットワーク ACL は、VPC のセキュリティのためのオプションのレイヤーであり、1 つ以上のサブネットとの間のトラフィックを制御するファイアウォールの役目を果たし、セキュリティグループとは違ってネットワーク ACL はステートレスです。
VPC の外側のネットワークコンポーネントの依存性も考慮してください。これには、Amazon CloudWatch エンドポイントなど、AWS によって提供される外部ネットワークコンポーネントが含まれることがあります。また、オペレーティングシステムのパッチ用のソフトウェアリポジトリなど、インターネットでホストされるサービスも含まれることがあります。
AWS の標準オプションに加えて、SAP 自体も追加のネットワークセキュリティオプションを提供しており、 [SAProuter](https://support.sap.com/content/dam/support/en_us/library/ssp/tools/connectivity-tools/saprouter/SAProuter.pdf) AWS ニュースブログ、 [SAP Web Dispatcher](https://help.sap.com/doc/7b5ec370728810148a4b1a83b0e91070/1610%20002/en-US/frameset.htm?488fe37933114e6fe10000000a421937.html) 、および SAP ゲートウェイ [ネットワークベースのアクセスコントロールリストの使用などがあります](https://help.sap.com/viewer/62b4de4187cb43668d15dac48fc00732/LATEST/en-US/d0a4956abd904c8d855ee9d368bc510b.html) .これらは AWS のサービスおよび構成と連携して、SAP システムへのネットワークアクセスを許可または制限します。
詳細については、次の情報を参照してください。
+ SAP on AWS ブログ: [VPC Subnet Zoning Patterns for SAP on AWS (SAP on AWSAWS の VPC サブネットゾーニングパターン)](https://aws.amazon.com/blogs/awsforsap/vpc-subnet-zoning-patterns-for-sap-on-aws/)
+ Well-Architected Framework [セキュリティ]: [インフラストラクチャ保護 – ネットワークの保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/protecting-networks.html)
+ Well-Architected Framework [マネジメントとガバナンスレンズ]: [ネットワーク接続](https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-lens/networkconnectivity.html)
+ SAP ドキュメント: [Network and Communication Security (ネットワークと通信セキュリティ)](https://help.sap.com/viewer/621bb4e3951b4a8ca633ca7ed1c0aba2/LATEST/en-US/492f0050d5ac612fe10000000a44176d.html)
**提案 6.1.3 – 設計ガイドラインと AWS ツーリングを使用して、ネットワークセキュリティを簡素化する**
SAP システムは、多くの場合、複雑な統合要件を持ち、クラウドはネットワークセキュリティ管理を簡素化するための追加の手段となります。以下のアプローチを検討してください。
+ 管理の簡素化が可能な場合、個々の IP アドレスまたは IP の範囲の参照は避けます。
+ すべての SAP ワークロードについて SAP システム番号の標準セットを使用して、必要なネットワークポートの範囲を減らします。
+ [VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) は、Amazon S3 や Amazon CloudWatch などの AWS サービスにアクセスするための VPC からのアウトバウンドインターネットアクセスの要件をなくします。可能な場合や、ビジネス要件によって必要とされない場合は、これらのサービスとの間の SAP トラフィックがパブリックインターネットを経由せず、すべてのトラフィックが AWS によって管理されているネットワークコンポーネントを経由するようにできます。
+ 以下を使用することによって、セキュリティグループを簡素化します。 [VPC プレフィックスリスト](https://docs.aws.amazon.com/vpc/latest/userguide/managed-prefix-lists.html) や [セキュリティグループのルール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html) 。これらは、IP アドレスの範囲ではなく、他のセキュリティグループを参照します。
+ セキュリティグループの作成、更新、および管理にオートメーションを使用して、構成のズレを避けます。
+ 以下の使用を検討します。 [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/) これは VPC と AWS アカウント全体でのセキュリティグループの集中管理のためです。
+ 以下の使用を検討します。 [SAProuter](https://support.sap.com/en/tools/connectivity-tools/saprouter.html) 、 [SAP Web Dispatcher](https://help.sap.com/doc/7b5ec370728810148a4b1a83b0e91070/1610 002/en-US/frameset.htm?488fe37933114e6fe10000000a421937.html) 、および Elastic Load Balancing。これらを組み合わせることで、バックエンドシステムへのエントリポイントを難読化できます。
+ 複数の [SAP Internet Communication Manager (ICM)](https://help.sap.com/doc/d2ecfdfcaedc4e2ba46a99a6be7d5797/1610 002/en-US/frameset.htm#:~:text=The%20ICM%20is%20a%20component%20of%20the%20SAP%20NetWeaver%20Application%20Server.&text=The%20Internet%20Communication%20Manager%20ensures,processes%20requests%20from%20the%20Internet.) エントリポイントを使用して、よりきめ細かなアクセスコントロールを提供することを検討します。
詳細については、次の情報を参照してください。
+ SAP ドキュメント: [ネットワークベースのアクセスコントロールリスト](https://help.sap.com/viewer/62b4de4187cb43668d15dac48fc00732/LATEST/en-US/d0a4956abd904c8d855ee9d368bc510b.html)
+ SAP ドキュメント: [TCP/IP Ports for All SAP Products](https://help.sap.com/viewer/ports)
# ベストプラクティス 6.2 – オペレーティングシステムを構築し、保護する
SAP ソフトウェアの基盤となるオペレーティングシステムを保護することで、悪意ある人物が SAP アプリケーション内のデータへの不正なアクセス権を得て、ソフトウェアの可用性に影響を与えたり、ミッションクリティカルな実装を不安定化させたりする可能性を軽減できます。SAP、オペレーティングシステムベンダー、データベースベンダー、または AWS からのレコメンデーションに従って、オペレーティングシステムの安全を確保してください。選択した SAP ソリューションとオペレーティングシステムによっては、サービスの有効化/無効化、特定のカーネルパラメータの設定、およびさまざまな組み合わせのセキュリティパッチの適用が必要になる場合があります。SAP の要件が組織の要件にどのように対応するかを考慮し、矛盾点があれば特定します。
**提案 6.2.1 – セキュアなオペレーティングシステムをプロビジョニングするためのアプローチを決定する**
Amazon マシンイメージ (AMI) は、EC2 インスタンスを起動するために必要な情報を提供します。AMI がオペレーティングシステムレベルでセキュアであることを確認する必要があります。そうでない場合、AMI が時間の経過とともに再利用され、更新されるたびに、セキュリティホールが任意の数のインスタンスに伝播する恐れがあります。
AMI は、オペレーティングシステムベンダーからの標準イメージか、お客様自身が構築したカスタムイメージのいずれかです。どちらの場合も、一貫したアプローチにより、オペレーティングシステムが起動時にセキュアであり、継続的に維持されることを確実にする必要があります。Infrastructure as Code (IaC) ツール、例えば、 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) などの使用は、イメージセキュリティの一貫性の達成に役立ちます。HANA ベースの SAP ソリューションの場合、 [AWS Launch Wizard](https://aws.amazon.com/launchwizard/) for SAP は、セキュリティコンポーネントのインストールを自動化するためにカスタマイズできるプレおよびポストインストールスクリプトなど、インストールプロセスを簡素化します。
詳細については、コンピューティングリソースの保護、特に脆弱性管理の実行と攻撃面の削減に関する「AWS Well-Architected Framework [セキュリティの柱]」ガイダンスを参照してください。
+ Well-Architected Framework [セキュリティ]: [コンピューティングの保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/protecting-compute.html)
**提案 6.2.2 – セキュアなオペレーティングシステムを維持するためのアプローチを決定する**
コンピューティングの保護に関する Well-Architected Framework [セキュリティの柱] の説明で述べたように、選択したオペレーティングシステムが EC2 Image Builder によってサポートされている場合は、SAP 固有の AMI の構築、テスト、デプロイと継続的なパッチ管理を簡素化できます。セキュリティパッチ適用の自動化によるオペレーティングシステムのセキュリティ体制の維持については、AWS Systems Manager Patch Manager も調べてください。
+ Well-Architected Framework [セキュリティ]: [コンピューティングの保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/protecting-compute.html)
+ AWSドキュメント: [EC2 Image Builder](https://aws.amazon.com/image-builder/)
+ AWSドキュメント: [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
**提案 6.2.3 – オペレーティングシステムに適用できる追加のセキュリティレコメンデーションをレビューする**
SAP ソフトウェアの基盤となるオペレーティングシステムの強化に必要な項目の完全なリストを作成します。例えば、Linux ベースのシステムでのファイルシステム許可は SAP ガイドラインに従って設定する必要がありますが、Windows ベースのシステムでは、Administrator グループのアクセスを制限するのがベストプラクティスです。
以下の SAP 固有のレコメンデーションは、お客様の環境に該当する可能性があります。
+ SAP ドキュメント: [SAP NetWeaver セキュリティガイド - オペレーティングシステムのセキュリティ](https://help.sap.com/viewer/621bb4e3951b4a8ca633ca7ed1c0aba2/LATEST/en-US/4a6e3d96f90472dde10000000a42189b.html)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/best-practice-6-2.html)
**提案 6.2.4 – オペレーティングシステムのセキュリティ体制を検証する**
オペレーティングシステムがセキュアにデプロイされ、パッチが適用されたら、オペレーティングシステムのセキュリティ体制を検証して、オペレーティングシステムが高いレベルのセキュリティを継続的に維持して、違反行為がないことを確認します。サードパーティーのホスト侵入保護、侵入検知、アンチウイルス、およびオペレーティングシステムファイアウォールソフトウェアを使用して、この検証を自動化することを検討します。
詳細については、次の情報を参照してください。
+ Well-Architected Framework [セキュリティ]: [セキュアなオペレーション](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/operating-your-workload-securely.html)
+ Well-Architected Framework [セキュリティ]: [検出](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
+ Well-Architected Framework [セキュリティ]: [コンピューティングの保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/protecting-compute.html)
# ベストプラクティス 6.3 – データベースとアプリケーションを保護する
悪意ある人物が読み取り専用レベルでもアクセス権を取得すると、重要なビジネスデータのセキュリティが侵害されるため、データベースおよびアプリケーションレイヤーでのセキュリティ警戒が不可欠です。どのような場合でも、データベースのアクセス保護とアプリケーションのセキュリティに関する標準的な SAP ベストプラクティスに従ってください。これらは、オンプレミスとクラウドベースの両方のインストールに適用され、SAP システムの基盤となるサポートされる各データベースについてのガイドラインです。
**提案 6.3.1 選択したデータベースについて、データベースセキュリティに関する SAP ガイダンスに従う**
該当するガイドラインについては、以下を参照してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/best-practice-6-3.html)
**提案 6.3.2 – アプリケーションのセキュリティに関する SAP ガイダンスに従う**
SAP NetWeaver ベースのソリューションについては、『SAP NetWeaver セキュリティガイド』に詳しいガイダンスがあります。
+ SAP ドキュメント: [ABAP Platform Security Guide](https://help.sap.com/viewer/621bb4e3951b4a8ca633ca7ed1c0aba2/LATEST/en-US/4aaf6fd65e233893e10000000a42189c.html)
# ベストプラクティス 6.4 – 適用可能なすべてのソフトウェアのアップグレードとパッチ適用のプランを確立する
SAP と基盤となるオペレーティングシステムおよびデータベースのベンダーは、一定のスケジュールで標準的なセキュリティアップデートをリリースし、脆弱性を修正するための緊急アップデートも提供します。各ベンダーからの最新のセキュリティ情報を確認してください。セキュリティホールの導入を回避するには、定期的に最新のセキュリティフィックスで SAP アプリケーションと基盤となるすべてのコンポーネントを最新の状態に保つことをお勧めします。また、重要なセキュリティパッチがリリースされたときに緊急フィックスを適用するためのプランを立てておくことをお勧めします。
**提案 6.4.1 - オペレーティングシステム、データベース、およびソフトウェアソリューションのベンダーからのアラートを購読する**
さまざまなベンダーポータルのセキュリティアップデートを購読することで、新しいセキュリティ問題や修正をリリースされたタイミングで知ることができます。これは、必要な変更を計画するのに役立ちます。
+ AWS ドキュメント: [AWS セキュリティ速報](https://aws.amazon.com/security/security-bulletins/?card-body.sort-by=item.additionalFields.bulletinDateSort&card-body.sort-order=desc)
+ SAP ドキュメント: [SAP EarlyWatch Alert](https://support.sap.com/en/offerings-programs/support-services/earlywatch-alert.html)
+ SAP ドキュメント: [SAP セキュリティ関連のノートとニュース](https://support.sap.com/en/my-support/knowledge-base/security-notes-news.html)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/best-practice-6-4.html)
**提案 6.4.2 – 推奨された変更と、ビジネスおよび実装の取り組みに対するリスクをレビューする**
SAP チームは、システムアップタイムに対するニーズと、SAP セキュリティの向上のために推奨されたシステム変更の重要性とのバランスを取ることを学ぶ必要があります。これを怠ると、サービスの中断、財政上の影響、生産性の喪失など、不必要なリスクが生じる恐れがあります。脆弱性を修正するためにベンダーから推奨された変更と実装ステップをレビューし、それらをすみやかに実装するプランを立てます。これは、このレンズで述べられている運用上の優秀性のベストプラクティス、特にセキュリティに関するランブックの作成に直接関係します。
+ SAP Lens [運用上の優秀性]: [提案 3.4.1 - SAP セキュリティオペレーションのための具体的なランブックを作成する](best-practice-3-4.md)
**提案 6.4.3 – 脆弱性に迅速に対応するプランを確立する**
新しい SAP セキュリティレコメンデーションとセキュリティ関連のパッチを可能な限り迅速に適用することが、AWS ベースの SAP ソリューションにとっても、別の場所にインストールされているソリューションにとっても非常に重要です。新しいサービスと機能の [SAP セキュリティノートおよびニュース](https://support.sap.com/en/my-support/knowledge-base/security-notes-news.html) を定期的にレビューして、記載されているパッチ、ノート、およびレコメンデーションにより、セキュリティ問題を迅速に修正します。場合によっては、SAP 管理者は根本的な脆弱性が解決されるまで、一時的な緩和措置または管理措置を講じなければならないこともあります。インシデント対応に関するセキュリティの柱のレコメンデーションにも従ってください。
+ Well-Architected Framework [セキュリティ]: [インシデント対応](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html)
+ SAP ドキュメント: [SAP セキュリティノートおよびニュース](https://support.sap.com/en/my-support/knowledge-base/security-notes-news.html)
# 7 – ID および許可による SAP ワークロードへのアクセスの制御
**SAP ワークロードへのアクセスをどのように制御しますか?** AWS、SAP、およびその他のサードパーティーによって提供されるメカニズムを使用して、エンドユーザーとインターフェイスシステムが正しく識別され、認証されるようにします。最小特権を確保するために、許可はどのように管理されますか? アクセスはどのように監査され、報告されますか? まず、ユーザーのカテゴリを識別してから、コントロールおよび ID 管理アプローチを通じて組織的に作業して、SAP ワークロードへのアクセスを制限します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-7.html)
# ベストプラクティス 7.1 – SAP のユーザーカテゴリとアクセスメカニズムを理解する
SAP システムにアクセスするユーザーのタイプによって、適用する必要があるセキュリティコントロールが決まります。各ユースケースを調べることで、戦略を開発できます。これには、ID、認証、ツーリング、およびそれらの要件をサポートするメカニズムの管理方法を含める必要があります。
**提案 7.1.1 データアクセス許可と許可されるアクションを理解する**
SAP システムには、多くの場合、機密性の高いビジネスデータが含まれます。ユーザータイプを定義して、データアクセス許可を理解します(例えば、管理データベースユーザーにはアプリケーションユーザーのきめ細かなコントロールがないため、より重要かもしれません)。 [セキュリティ] も参照してください。 [ベストプラクティス 5.2 – SAP ワークロード内のデータを分類する](best-practice-5-2.md).
SAP システムのアクセスに関して、以下の質問を考慮します。
+ 管理ユーザーまたはサービスユーザーが取るアクションは、一意に識別可能な個人まで追跡可能な必要がありますか?
+ アクセス権が付与されるのは、アプリケーションのどのレイヤーですか?
+ 許可によって機能のサブセットへのアクセスを制限できますか?
+ その他のコントロール、例えば、特定のサービスのみを公開することによって、機能のサブセットへのアクセスを制限できますか?
+ 取られたアクションを監査するための要件はありますか?
**提案 7.1.2 – ユーザーが SAP システムにアクセスするネットワークや場所を理解する**
ネットワークや場所は、セキュリティリスクプロファイルの一因となることが多く、信頼できるユーザーとみなされるかどうかを決めることがあります。一般に、これは無許可アクセスを防止するためのコントロールと組み合わされます (以下を参照 [ベストプラクティス 6.1 – セキュリティと監査が SAP ネットワーク設計に組み込まれていることを確認する](best-practice-6-1.md) ) を指定する必要があります。
超えは設計に影響を与えることがあります。例えば、信頼できないインターネットユーザーまたはデバイスが SAP ワークロードにアクセスするには、社内ネットワークからの信頼できるユーザーに比べて、追加の認証要素を必要とすることがあります。
# ベストプラクティス 7.2 – SAP ワークロードへの特権アクセスを管理する
可能な場合は、最小特権のアプローチを採用します。ユーザビリティと効率性を管理しつつ、最小限のユーザーセットに、特定のロールを遂行するために必要な最小アクセスのみを付与します。管理アカウント (例えば、 `adm`) は、SAP ワークロードの信頼性やデータのセキュリティに大きな影響を与えるアクセス権をデフォルトで持ちます。このリスクをどのように制限できるか検討してください。
**提案 7.2.1 – AWS 認証情報と認証を管理する**
AWS Identity and Access Management (IAM) により、AWS のサービスとリソースへのアクセスを安全に管理できます。IAM を使用すると、さまざまな SAP およびクラウド管理タスクについて AWS ユーザーとグループを作成し、管理できます。IAM 許可を使用して、AWS リソースへのユーザーアクセスを許可および拒否します。特に特権 (ルート) アクセスの制限と保護については、標準ガイダンスに従う必要があります。
+ AWS ドキュメント: [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
ユーザーに割り当てられていないが、SAP アプリケーションのオペレーションに必要なアクセスについては、最小特権の確保に特に注意を払います。
+ AWS ドキュメント: [IAM ロールを使用して Amazon EC2 インスタンスでのアプリケーション実行権限を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)
**提案 7.2.2 – SAP 管理認証情報と認証を管理する**
必要なときだけ、期間限定の昇格された許可を承認および付与するプロセスを実装します。誰にどのような理由でアクセスが付与されたかに対処する監査機能を使用します。
特権アカウントのユーザーネーム/パスワードの使用を制限します。可能な場合は、直接アクセスを無効にします。特権アクセス管理ソリューションやパスワードボールトなど、認証情報を安全に保存します。
ランブック、RunCommand、および Secrets Manager を使用する特定のタスクについて、オペレーティングシステムへの直接アクセスを制限するために、システムマネージャーをどのように使用できるか評価します。
+ AWS ドキュメント: [SSM Agent を介してルートレベルコマンドへのアクセスを制限する](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-restrict-root-level-commands.html)
+ AWS ドキュメント: [AWS Secrets Manager パラメータからの Parameter Store シークレットの参照](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html)
# ベストプラクティス 7.3 – 組織の ID 管理アプローチと SAP への適用を理解する
一般的な SAP ワークロードは複数のシステムで、したがって複数の ID で構成されます。これらのユーザーを管理するための集中アプローチにより、セキュリティリスクとオペレーションの複雑性を軽減できます。焦点は、集中的なユーザー管理、シングルサインオン、および多要素認証を考慮して、AWS サービスとサードパーティーツールをアプローチでどのように使用できるかです。
**提案 7.3.1 – 指名ユーザーの ID プロバイダーを決める**
ユーザーはアクティブディレクトリなどの ID ストアに関連付けられます。これは、ロール、許可、ID などのアイデンティティ情報を管理するための中央リポジトリとして機能します。ID の各セットについて、これを ID プロバイダーに関連付けることができるかどうか判断します。ID プロバイダーによって、ユーザー認証の負担を軽減できます。シングルサインオン (SSO) を容易にし、ユーザー ID のライフサイクル (新規加入者、移動者、退去者など) も管理します。
人間に関連付けられない名前付きユーザーの例外を考慮します。これには、バッチ、ジョブスケジューリング、統合、およびモニタリングユーザーなどが含まれます。
+ AWS ドキュメント: [AWS ディレクトリサービス \$1 Amazon Web Services (AWS)](https://aws.amazon.com/directoryservice/)
**提案 7.3.2 – 認証メカニズムを決める**
SAP ワークロードの各レイヤーでサポートされる認証メカニズム (SAML、Kerberos、X.509、SAP シングルサインオンチケットなど) を理解します。アプリケーションと統合するための要件を評価します。可能な場合は、シングルサインオンを使用して、複数のユーザー認証情報を管理する管理上およびセキュリティ上の影響を回避します。
+ SAP ドキュメント: [User Authentication and single sign-on (ユーザー認証とシングルサインオン)](https://help.sap.com/viewer/621bb4e3951b4a8ca633ca7ed1c0aba2/LATEST/en-US/4a112f1a2228101ee10000000a42189b.html)
+ AWS ドキュメント: [クラウドアプリケーション - AWS シングルサインオン](https://docs.aws.amazon.com/singlesignon/latest/userguide/saasapps.html)
+ SAP on AWS ブログ: [AWS SSO による SAP シングルサインオンの有効化 パート 1: SAP Netweaver ABAP と AWS SSO の統合](https://aws.amazon.com/blogs/awsforsap/enable-sap-single-sign-on-with-aws-sso-part1-integrate-sap-netweaver-abap-based-applications-sso-with-aws-sso/)
+ SAP on AWS ブログ: [AWS SSO による SAP シングルサインオンの有効化 パート 2: SAP Netweaver Java と AWS SSO の統合](https://aws.amazon.com/blogs/awsforsap/enable-sap-single-sign-on-with-aws-sso-part-2-integrate-sap-netweaver-java/)
+ SAP on AWS ブログ: [Enable Single Sign On for SAP Cloud Platform Foundry and SAP Cloud Platform Neo with AWS SSO (AWS SSO で SAP Cloud Platform Foundry と SAP Cloud Platform Neo のシングルサインオンを有効にする)](https://aws.amazon.com/blogs/awsforsap/enable-single-sign-on-for-sap-cloud-platform-foundry-and-sap-cloud-platform-neo-with-aws-sso/)
**提案 7.3.3 – 多要素認証を検討する**
多要素認証 (MFA) は、ログオン認証情報に加えて保護を強化するベストプラクティスです。これら複数の要素により、SAP アプリケーションのセキュリティが強化されます。ユースケースとしては、信頼できないデバイスから SAP へのアクセス、AWS 管理コンソールへのアクセス、バックアップの削除や EC2 インスタンスの終了などの特権アクティビティがあります。
+ SAP on AWS ブログ: [Securing SAP Fiori with MFA (MFA による SAP Fiori の保護)](https://aws.amazon.com/blogs/awsforsap/securing-sap-fiori-with-multi-factor-authentication/)
+ AWS ドキュメント: [IAM のサインインページでの MFA デバイスの使用 - AWS ID とアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_sign-in-mfa.html)
+ AWS ドキュメント: [MFA 削除の設定 - Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html)
+ AWS ドキュメント: [Amazon EC2: 特定の EC2 オペレーション (GetSessionToken) に対して MFA を要求する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_require-mfa.html)
**提案 7.3.4 – 証明書管理のアプローチを決める**
クライアントベースの証明書は認証に使用でき、認証情報が不要です。システム間通信のセッション管理と証明書ローテーションのための時間ベースの有効期限切れを含むアプローチを決めます。AWS は SAP によって信頼される認証局を提供します。証明書は、次を使用して発行、管理できます。 [AWS Certificate Manager (ACM)](https://aws.amazon.com/certificate-manager/) .
+ SAP Note: [2801396 - SAP Global Trust List (SAP グローバル信頼リスト)](https://launchpad.support.sap.com/#/notes/2801396) [SAP ポータルへのアクセス権が必要]
+ SAP Note: [3040959 - How to get a CA signed server certificate in ABAP (ABAP で CA 署名付きサーバー証明書を取得する方法)](https://launchpad.support.sap.com/#/notes/3040959) [SAP ポータルへのアクセス権が必要]
+ SAP Lens [運用上の優秀性]: [提案 3.4.1 - SAP セキュリティオペレーションのための具体的なランブックを作成する](best-practice-3-4.md)
+ SAP Lens [運用上の優秀性]: [提案 4.1.2 - 認証情報、証明書およびライセンスの有効期限のカレンダーを管理する](best-practice-4-1.md)
# ベストプラクティス 7.4 – ユーザーアクセスと認可の変更およびイベントについてロギングとレポートを実装する
SAP システムのユーザーアクセスと認可イベントをログに記録し、分析し、定期的に監査する必要があります。SAP アプリケーションおよびデータベースのセキュリティイベントをアーキテクチャの他のコンポーネントと統合し、照合します。これにより、重大なセキュリティ問題や違反が発生した場合に、エンドツーエンドな追跡が可能です。中央のセキュリティ情報およびイベント管理 (SIEM) システムでイベントの分析を自動化します。これにより、オペレーションチームは、予定外または疑わしいアクティビティが通常のシステムコントロールの外部で発生したかどうか理解できます。その後、必要に応じて修正することができます。
**提案 7.4.1 – AWS Identity and Access Management (IAM) イベントをログに記録する**
AWS IAM イベントの履歴ログの保持を検討します。これは AWS アカウント内のユーザーや認可の変更を検出または監査するのに使用できます。ログの保持期間とログに記録するイベントのタイプを、組織によって必要とされるセキュリティポリシーに基づいて決定します。
オペレーションチームが SAP システムのインフラストラクチャレベルで監査の質問に答えられるようにします。
+ 新しい AWS コンソール/CLI ユーザーは、いつ、誰によって作成されましたか?
+ AWS IAM ロールは、いつ、誰によって変更されましたか?
+ AWS ユーザーが最後に正常にサインインしたのはいつですか?
+ AWS アカウントへのサインインの試みに失敗した疑わしい回数はありますか?
詳細については、以下を参照してください。
+ AWS ドキュメント: [IAM ベストプラクティス: AWS アカウントのアクティビティを監視する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#keep-a-log)
+ AWS ドキュメント: [AWS CloudTrail による IAM および AWS STS の API コールのログ記録](https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html)
+ AWS Well-Architected Framework [セキュリティ]: [検出](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec-detection.html)
+ AWS セキュリティブログ: [Visualizing Amazon GuardDuty findings (Amazon GuardDuty の調査結果を視覚化する)](https://aws.amazon.com/blogs/security/visualizing-amazon-guardduty-findings/)
**提案 7.4.2 – オペレーティングシステムでのユーザーおよび認可の変更をログに記録する**
検出または監査に使用できるように、オペレーティングシステム (OS) のユーザーおよび認可イベントの履歴ログを保持することを検討します。ログの保持期間とログに記録するイベントのタイプを、組織によって必要とされるセキュリティポリシーに基づいて決定します。
オペレーションチームが SAP システムのオペレーティングシステムレベルで次のような監査の質問に答えられるようにします。
+ 新しいスーパーユーザー OS アカウントは、いつ、誰によって作成されましたか?
+ OS アカウントの許可は、いつ、誰によって変更されましたか?
+ OS ユーザーが最後に正常にサインインしたのはいつですか?
+ OS アカウントへのサインインの試みに失敗した疑わしい回数はありますか?
+ OS ユーザーが昇格された許可を最後に使用したのはいつですか?
オペレーティングシステムの監査の詳細については、以下を考慮してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/best-practice-7-4.html)
**提案 7.4.3 – SAP アプリケーションとデータベースのユーザーおよび認可イベントをログに記録する**
検出または監査に使用できるように、SAP のユーザーおよび認可イベントの履歴ログを保持することを検討します。アプリケーションスタック (ABAP 認可など) とデータベース (SAP HANA など) の両方を考慮します。ログの保持期間とログに記録するイベントのタイプを、組織によって必要とされるセキュリティポリシーに基づいて決定します。
オペレーションチームがイベントの SAP アプリケーションおよびデータベースレベルで次のような監査の質問に答えられるようにします。
+ 新しい SAP またはデータベースアカウントは、いつ、誰によって作成されましたか?
+ SAP またはデータベースアカウントの許可は、いつ、誰によって変更されましたか?
+ SAP またはデータベースユーザーが最後に正常にサインインしたのはいつですか?
+ アカウントへのサインインの試みに失敗した疑わしい回数はありますか?
+ アカウントが最後に使用した機密トランザクションコードまたはツールは何ですか?
詳細については、以下を参照してください。
+ SAP ドキュメント: [SAP Access Control and Governance \$1 User Access (SAP アクセスコントロールとガバナンス \$1 ユーザーアクセス)](https://www.sap.com/australia/products/access-control.html)
+ SAP ドキュメント: [SAP NetWeaver ABAP: The Security Audit Log (SAP NetWeaver ABAP: セキュリティ監査ログ)](https://help.sap.com/viewer/280f016edb8049e998237fcbd80558e7/LATEST/en-US/4d41bec4aa601c86e10000000a42189b.html)
+ SAP ドキュメント: [SAP NetWeaver JAVA: The Security Audit Log (SAP NetWeaver JAVA: セキュリティ監査ログ)](https://help.sap.com/viewer/56bf1265a92e4b4d9a72448c579887af/LATEST/en-US/c769bcb7f36611d3a6510000e835363f.html)
+ SAP ドキュメント: [SAP HANA: Auditing Activity in SAP HANA (SAP HANA: SAP HANA でのアクティビティの監査)](https://help.sap.com/viewer/b3ee5778bc2e4a089d3299b82ec762a7/LATEST/en-US/ddcb6ed2bb5710148183db80e4aca49b.html)
**提案 7.4.4 – 分析のために、ユーザーおよび認可イベントをセキュリティ情報およびイベント管理 (SIEM) システムで統合する**
ユーザーおよび認可イベントのすべてを SAP ワークロードコンポーネントから中央の SIEM ツールに送信して、照合と分析を可能にすることを検討します。SAP Enterprise Threat Detection、サードパーティーのアドオンなどのツールを使用するか、SAP 監査ログをアプリケーションおよびデータベースサーバーから取り込みおよび分析ツールに直接送信します。
ワークロードのベースライン動作を確立し、異常がないかモニタリングして、セキュリティインシデントの検出を高めます。
検討 [AWS Marketplace SIEM ソリューション](https://aws.amazon.com/marketplace/solutions/control-tower/siem/) ワークロードをリアルタイムでモニタリングし、セキュリティ問題を特定し、根本原因の分析と修正を加速することを検討します。
詳細については、以下のリソースを考慮してください。
+ AWS Marketplace: [SIEM ソリューション](https://aws.amazon.com/marketplace/solutions/control-tower/siem/)
+ AWS ドキュメント: [AWS Security Hub](https://aws.amazon.com/security-hub/?aws-security-hub-blogs.sort-by=item.additionalFields.createdDate&aws-security-hub-blogs.sort-order=desc)
+ SAP ドキュメント: [SAP Enterprise Threat Detection](https://help.sap.com/viewer/eb42e48f5e9c4c9ab58a7ad73ff3bc66/LATEST/en-US/e12aa17b106c4c6193b7d593328aad48.html)
+ Well-Architected Framework [セキュリティ]: [セキュリティインシデント対応](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec-incresp.html)
+ AWS ドキュメント: [AWS セキュリティインシデント対応 - テクニカルホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
# 8 – SAP の保管中のデータと送信中のデータを保護する
**SAP データをどのように保護しますか?** SAP システムは、多くの場合、ビジネス内のコア機能を実行し、機密性の高いエンタープライズデータを保存します。ベストプラクティスは、保管中と送信中のデータを少なくとも 1 つの暗号化メカニズムを使用して暗号化し、社内または社外のセキュリティ要件と規制に準拠することです。次にリストされているコントロールに加えて、 [AWS 責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/) AWS は複数の暗号化ソリューションを備えています。多くの AWS サービスは、最小限の労力とパフォーマンスへの影響で暗号化を実行できる機能を備えています。データベースおよび SAP アプリケーションレイヤーで使用可能な暗号化オプションがあるので、検討してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-8.html)
# ベストプラクティス 8.1 – 保管中のデータを暗号化する
保管中のデータとは、デジタル的に保存されたデータを指します。このデータが承認されたユーザーにのみ表示され、ストレージまたはデータベースへのアクセスがアプリケーションとは無関係に侵害されるときには保護状態を保つように、暗号化を使用します。
**提案 8.1.1 – 暗号化が適用されるレベルを定義する**
一般に、暗号化をデプロイするスタックが多いほど、データの安全性は高まります。このセキュリティ強化には、デプロイと管理の複雑さの増加が伴います。AWS は、サービス内で使用可能な保管中の暗号化オプションを使用することをお勧めします。必要なときには、[セキュリティ] で定義されているオペレーティングシステムまたはデータベースの追加の暗号化を検討してください。 [ベストプラクティス 5.3 - SAP ワークロードの特定のセキュリティコントロールの必要性を評価する](best-practice-5-3.md).
**提案 8.1.2 – SAP サービスおよびソリューション向けの AWS 暗号化オプションを理解する**
保管中のデータについて SAP が依存するコアの AWS サービスは、Amazon EC2 (AMI プラス EBS ボリューム)、Amazon FSx for Windows File Server、または共有ファイルシステム向けの Amazon EFS とバックアップまたはその他のオブジェクトストアユースケース向けの Amazon S3 です。
+ AWS ドキュメント: [EBS -backed AMI での暗号化の利用](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIEncryption.html)
+ AWS ドキュメント: [Amazon EBS Encryption](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ AWS ドキュメント: [Amazon EFS 暗号化](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) / [Amazon FSx 暗号化](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/encryption.html)
+ AWS ドキュメント: [Amazon S3 の暗号化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingEncryption.html)
これらのサービスの保存されたデータは、AWS または AWS KMS からの顧客管理キーを使用して、保管中に暗号化できます。
オペレーティングシステムの暗号化オプションには、BitLocker、DM-crypt、および SuSE Remote Disk があります。
以下のリンクを参考に、データベースの暗号化オプションに関する情報を見つけてください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/best-practice-8-1.html)
**提案 8.1.3 – 暗号化の方法とキー管理ストアを定義する**
一般に、キー管理はエンタープライズレベルで定義され、これにより、SAP ワークロードでの使用が許されるキー管理オプションが決まります。AWS KMS は、AWS サービスの暗号化キーの管理を簡素化するセキュアで回復性の高いサービスです。独自のハードウェアセキュリティモジュール (HSM) を管理する必要がある場合は、AWS CloudHSM を使用できます。
+ AWS ドキュメント: [AWS 暗号化ツールおよびサービスのオプション](https://docs.aws.amazon.com/crypto/latest/userguide/awscryp-choose-toplevel.html)
+ AWS ドキュメント: [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/)
+ AWS ドキュメント: [AWS CloudHSM](https://aws.amazon.com/cloudhsm/)
マスターキーを保護するメカニズムも検討してください。キーのアクセスの制限、ローテーションの管理、および復元力の確保をどのように行いますか?
HANA の保管中のデータの暗号化のルートキーは、ファイルシステム内のインスタンスセキュアストア (インスタンス SSFS) または SAP Data Custodian SaaS Solution でのみ安全に保存できることに注意してください。インスタンスストアを使用する場合、マスターキーは [AWS Secrets Manager](https://aws.amazon.com/systems-manager/) にローテーションポリシーとともに保存できます。
+ SAP Note: [2154997 - Migration of hdbuserstore entries to ABAP SSFS (hdbuserstore エントリの ABAP SSFS への移行)](https://launchpad.support.sap.com/#/notes/2154997) [SAP ポータルへのアクセス権が必要]
+ SAP Note: [2755815 - How to Ensure Recoverability of Hana's Data-At-Rest Encryption (HANA の保管中データの暗号化の回復性を確保する方法)](https://launchpad.support.sap.com/#/notes/2755815) [SAP ポータルへのアクセス権が必要]
# ベストプラクティス 8.2 – 送信中のデータを暗号化する
送信中のデータの暗号化を使用すると、データがあるポイントから別のポイントへ移動しているときの傍受、アクセス、または改ざんがより困難になります。セキュアなプロトコルとネットワークレベルの暗号化が設定されていて、潜在的な脅威を最小化し、要件に応じた保護レベルを提供していることを確認します。
Well-Architected Framework [セキュリティ]: [伝送中のデータの保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/protecting-data-in-transit.html)
**提案 8.2.1 – SAP およびデータベースプロトコルに基づくアプリケーショントラフィックを暗号化する**
SAP プロトコルを使用するアプリケーショントラフィックの場合 (SAPGUI Dialog、RFC、および CPIC) は、SAP SNC を使用してトランスポートレイヤーセキュリティを適用します。
+ SAP ドキュメント: [SAP システムにおける SNC で保護された通信パス](https://help.sap.com/viewer/621bb4e3951b4a8ca633ca7ed1c0aba2/LATEST/en-US/ad38ff4fa187622fe10000000a44176d.html)
データベーストラフィックについては、可能な場合、クライアントとデータベース間のセキュアな接続を使用します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/best-practice-8-2.html)
**提案 8.2.2 – インターネットプロトコルに基づく SAP アプリケーショントラフィックを暗号化する**
インターネットプロトコル (HTTP、P4 (RMI)、LDAP) に基づくアプリケーショントラフィックについては、SSL/TLS を使用して、トランスポートレイヤーセキュリティを適用します。
+ SAP ドキュメント: [トランスポートレイヤーセキュリティ](https://help.sap.com/viewer/621bb4e3951b4a8ca633ca7ed1c0aba2/LATEST/en-US/5f0f558b8a7841049139f0fb558ac62c.html)
**提案 8.2.3 – ファイル転送またはメッセージ転送プロトコルに基づくデータ交換を暗号化する**
ファイルベースの転送の場合、AWS は、SFTP または FTPS 経由でのセキュアなファイル交換のために、AWS Transfer Family を提供します。AWS Transfer Family は Amazon S3 と Amazon EFS 管のデータの転送をサポートします。
+ AWS ドキュメント: [AWS Transfer Family](https://aws.amazon.com/aws-transfer-family)
メッセージレベルのデータ整合性チェックを使用すると、データが送信中に改ざんされていないことを確認できます。SAP によってサポートされている 1 つ以上のメッセージレベルセキュリティスタンダードを使用して、メッセージ内のデータに署名し、その整合性を確認することを検討してください。
+ SAP ドキュメント: [SAP ABAP ウェブサービスメッセージレベルセキュリティ](https://help.sap.com/viewer/684cffda9cbc4187ad7dad790b03b983/1709 000/en-US/47ac469337a24845e10000000a421138.html?q=netweaver%20security%20guide%20message%20level%20security)
+ SAP ドキュメント: [SAP NetWeaver プロセス統合セキュリティガイド](https://help.sap.com/doc/saphelp_nwpi711/7.1.1/en-US/f7/c2953fc405330ee10000000a114084/frameset.htm)
+ SAP ドキュメント: [SAP クラウド統合メッセージレベルセキュリティ](https://help.sap.com/viewer/368c481cd6954bdfa5d0435479fd4eaf/Cloud/en-US/463a9085156d4672bc4ee9095277e453.html)
IDOC ベースのメッセージについては、SNC を使用して、ALE によって使用される RFC 接続を保護します。
+ SAP ドキュメント: [IDocs での機密データの取り扱い](https://help.sap.com/viewer/621bb4e3951b4a8ca633ca7ed1c0aba2/LATEST/en-US/7f2e71922f4a4d7081e1d2032b0934f7.html)
**提案 8.2.4 – 管理アクセスを暗号化する**
SAP の管理には、Windows と SSH ベースの両方のツールを使用するのが一般的です。Bastian Hosts などのセキュリティコントロールに加えて、このトラフィックの暗号化が可能かどうか検討します。
または、[AWS Systems Manager セッションマネージャー](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) は、暗号化に TLS を使用して AWS 管理コンソール経由でオペレーティングシステムにアクセスするセキュアなメカニズムを提供します。
+ AWS ドキュメント: [Amazon EC2 Windows ガイド - 送信中の暗号化](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/data-protection.html)
+ AWS ドキュメント: [Amazon EC2 Linux ガイド - 送信中の暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html)
+ AWS ドキュメント: [AWS Systems Manager でのデータ保護 – データ暗号化](https://docs.aws.amazon.com/systems-manager/latest/userguide/data-protection.html#data-encryption)
**提案 8.2.5 – 送信中の暗号化を可能にする AWS サービスの機能を評価する**
アプリケーションベースの暗号化に加えて、多くの AWS サービスは送信中の暗号化機能を備えています。各サービスについて、会社のスタンダード、実装の取り組み、および関連する利点を評価します。以下は、SAP ワークロードに関連する例です。
+ AWS ドキュメント: [Amazon S3 - 送信中の暗号化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingEncryption.html) - デフォルトで有効であり、Amazon S3 へのバックアップに推奨。
+ AWS ドキュメント: [Amazon EFS - 送信中の暗号化](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html) / [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/encryption-in-transit.html) - 共有ファイルシステムの場合に必要なことがあります。
+ AWS ドキュメント: [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/data-protection.html) - この機能はすべてのタイプのロードバランサーで使用できるわけではないため、暗号化要件と、エンドツーエンドな TLS パススルーが必要かどうかをレビューします。
+ AWS ドキュメント: [Amazon EC2 - 送信中の暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html) - より新しい世代のインスタンスタイプのみが、この機能を備えています。
**提案 8.2.6 – ネットワークレベルの暗号化を実装する**
SAP のお客様は、一般に、Direct Connect または Direct Connect と VPN の組み合わせのいずれかを使用して、AWS 上のリソースへの信頼できる接続性を提供しています。
AWS Direct Connect は、送信中のトラフィックを暗号化しません。暗号化が必要な場合は、例えば、VPN over Direct Connect を使用して、トランスポートレベルの暗号化を実装してください。
AWS は、ネットワークチャネルの暗号化に使用できるサイト間 VPN を提供します。AWS Marketplace から、または Bring-Your-Own-License で Open VPN などのサードパーティー VPN ソリューションをデプロイすることもできます。
+ AWS ドキュメント: [AWS マネージド VPN](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-managed-vpn.html)
+ AWS ドキュメント: [AWS Direct Connect \$1 VPN](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect-vpn.html)
+ AWS ドキュメント: [ソフトウェアサイト間 VPN](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/software-site-to-site-vpn.html)
# ベストプラクティス 8.3 - データ復旧メカニズムを確保して、脅威から保護する
悪意あるアクティビティから保護するために、組織のセキュリティフレームワーク内で定められているガイドラインに従ってください。それらの [日本語ガイド: AWS クラウド環境をランサムウェアから保護する](https://d1.awsstatic.com/WWPS/pdf/AWSPS_ransomware_ebook_Apr-2020.pdf) には、インシデント前およびインシデント対応の一環としての重要な項目の概要が説明されていて、ネットワークコントロール、パッチ適用、最小特権許可などが含まれています。SAP システムの場合、脅威は他のアプリケーションと同様ですが、影響はより大きくなる可能性があります。SAP がレコードのシステムの場合や、ミッションクリティカルなトランザクションのために必要とされる場合は、以下の提案を検討して、悪意ある攻撃からバックアップを保護してください。
+ SAP Note: [2663467 - Tips to avoid a Ransomware situation (ランサムウェア状況を回避するためのヒント)](https://launchpad.support.sap.com/#/notes/2663467) [SAP ポータルへのアクセス権が必要]
+ SAP Note: [2496239 - Ransomware / malware on Windows (Windows でのランサムウェア / マルウェア)](https://launchpad.support.sap.com/#/notes/2496239) [SAP ポータルへのアクセス権が必要]
**提案 8.3.1 – 追加のコントロールで個別アカウントのバックアップを保護する**
データのプライマリコピーから隔離されたアカウントでバックアップを直接、またはレプリケーションを使用して保護することにより、システム侵害がデータ復旧メカニズムにも影響を与えるリスクを最小化できます。
セカンダリアカウントは、ユースケースに応じたアクセス要件を持つ “データバンカー” として見ることができます。
Amazon S3 を使用するバックアップの場合、追加のコントロールとして、write-once-read-many (WORM) モデルを使用してオブジェクトを保存する S3 Object Lock、または [多要素認証削除を含めることができます。](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html) .
レプリケーションを使用する場合は、使用可能なさまざまなオプション、例えば、 [削除マーカーレプリケーション](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-marker-replication.html) (デフォルトでは、削除マーカーはレプリケートされません) や [S3 レプリケーション時間制御などを理解してください](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-time-control.html) .コストを最適化するには、プライマリとセカンダリの両方のバケットでハウスキーピングが実行されることを確認します。
**提案 8.3.2 – 復旧能力を検証する**
バックアップは、悪意あるアクティビティからデータを保護する最後の防衛線ですが、バックアップが不完全であったり、バックアップが有効でなかったりするために復旧できない場合は役に立ちません。バックアップにアクセスできない場合や復号化できない場合も、復旧は不可能です。暗号化キーと認証情報をどのように保護するか考慮してください。
代替アカウントでの再構築も含めて、悪意あるシナリオに応じた復旧テストを実行してください。
+ SAP Lens [運用上の優秀性]: [ベストプラクティス 4.3 - 事業継続性計画と障害復旧を定期的にテストする](best-practice-4-3.md)
# 9 – セキュリティイベントのロギング、テスト、および対応のためのセキュリティ戦略を実装する
**適切なロギング、テスト、および文書化された対応方法でサポートされている戦略的セキュリティプランはありますか?** 戦略的セキュリティプランを持つことは、あらゆるセキュリティ課題に対処するために行わなければならない事前タスクと事後タスクの形成に役立ちます。AWS 上の SAP ワークロードのセキュリティインシデントの識別と修復に役立つロギング、検出、および追加保護の手順は、Well-Architected Framework のセキュリティの柱で詳しく述べられているものと同じです。このセクションのガイダンスに加えて、「セキュリティの柱」にある検出とインシデント対応に関するベストプラクティスをレビューしてください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-9.html)
+ Well-Architected Framework [セキュリティ]: [検出](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
+ Well-Architected Framework [セキュリティ]: [インシデント対応](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html)
# ベストプラクティス 9.1 – SAP アプリケーションおよびデータベースのセキュリティログ分析に関する戦略を理解する
適切な詳細度のセキュリティログを保持しなければ、インシデント対応、フォレンジックなセキュリティ分析、および脅威のモデリングのために必要な貴重なデータが失われることがあります。SAP セキュリティスタッフは、お客様のビジネス上のセキュリティ要件に応じて、SAP システムに影響する潜在的なセキュリティインシデントを評価できなければなりません。AWS 上で実行する SAP ワークロードの場合、「Well-Architected Framework セキュリティの柱」で説明されている AWS サービスは、以下の提案と組み合わせて、有効な出発点となります。
+ Well-Architected Framework [セキュリティ]: [検出 – 構成](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/configure.html)
**提案 9.1.1 – セキュリティイベントの検出に必要なログを決める**
個々の SAP ソフトウェアおよびサポートされるデータベースについて、SAP NetWeaver Guide Finder や SAP NetWeaver セキュリティガイドを参照して、該当するログ (例えば、 [読み取りアクセスログ](https://help.sap.com/viewer/621bb4e3951b4a8ca633ca7ed1c0aba2/LATEST/en-US/631dfbf00a604784b69fc30570bfb69d.html) ) を指定する必要があります。さらに、SAP アドバイザリをレビューして、 [セキュリティロギング](https://help.sap.com/viewer/1a93b7a44ac146b5ad9b6fd95c1223cc/LATEST/en-US/182e167819f6405792686e94c177b9eb.html) と、開発アクティビティのベストプラクティスに関する関連トピックを確認してください。
+ SAP ドキュメント: [SAP NetWeaver Guide Finder](https://help.sap.com/viewer/nwguidefinder)
+ SAP ドキュメント: [ABAP Platform Security Guide](https://help.sap.com/viewer/621bb4e3951b4a8ca633ca7ed1c0aba2/LATEST/en-US/4aaf6fd65e233893e10000000a42189c.html)
+ SAP ドキュメント: [セキュリティロギング](https://help.sap.com/viewer/1a93b7a44ac146b5ad9b6fd95c1223cc/LATEST/en-US/182e167819f6405792686e94c177b9eb.html)
**提案 9.1.2 – ログの保存と分析のメカニズムを開発する**
セキュアな SAP インストールのためには、潜在的なセキュリティイベントに関する関連データが必要ですが、同じように重要なのは、そのデータを安全に保存することと、データを効率的かつ迅速に検索し、分析するために必要なツールを用意することです。AWS でのオプションとしては、 [CloudWatch エージェント](https://docs.aws.amazon.com/systems-manager/latest/userguide/monitoring-cloudwatch-agent.html) を使用して、セキュリティ関連のインスタンスログと SAP アプリケーションログを [Amazon CloudWatch ロググループに保存する方法があります。](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html) .そのようなログは、 [Amazon S3 にエクスポートして、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 包括的なログ分析を行ったり、 [サードパーティーのログ分析ソリューションと統合したりできます](https://aws.amazon.com/marketplace/solutions/control-tower/siem) .
AWS セキュリティログでの SAP の組み立て、結合、および分析については、以下を参照してください。
+ SAP Lens [セキュリティ]: [提案 7.4.4 – 分析のために、ユーザーおよび認可イベントをセキュリティ情報およびイベント管理 (SIEM) システムで統合する](best-practice-7-4.md)
+ SAP on AWS ブログ: [SAP HANA monitoring: A serverless approach using Amazon CloudWatch (SAP HANA モニタリング: Amazon CloudWatch を使用したサーバーレスアプローチ)](https://aws.amazon.com/blogs/awsforsap/sap-hana-monitoring-a-serverless-approach-using-amazon-cloudwatch/)
+ SAP on AWS ブログ: [SAP Monitoring: A serverless approach using Amazon CloudWatch (SAP モニタリング: Amazon CloudWatch を使用したサーバーレスアプローチ)](https://aws.amazon.com/blogs/awsforsap/sap-monitoring-a-serverless-approach-using-amazon-cloudwatch/)
# ベストプラクティス 9.2 – セキュリティバグがないか、定期的にテストする
「Well-Architected Framework セキュリティの柱」のインシデント対応のセクションで述べられているように、シミュレーション、ランブックの作成、およびゲームデーの実施は、AWS 上の SAP も含め、あらゆるワークロードについて推奨されます。このタイプの定期的なテストによって、新しい攻撃ベクトルや脆弱性を特定できるだけでなく、セキュリティインシデントが発生した際の迅速で効果的な対応のための SAP セキュリティリソースを準備できます。
Well-Architected Framework [セキュリティ]: [インシデント対応 - シミュレーション](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/simulate.html)
**提案 9.2.1 – 標準のセキュリティおよび侵入テストに加えて、SAP アプリケーションをターゲットとして含める**
試験的なセキュリティテストは、セキュアな環境を維持するための重要な部分です。AWS で標準的な侵入テストを実施することに加えて、悪意あるアクティビティの追加の潜在的ターゲットとして SAP ソリューションを加えてください。SAProuter、Web Dispatcher、Cloud Connector、SAP Fiori など、アーキテクチャで公開されることが多い SAP 固有のソフトウェアソリューションを念頭に置いてください。
+ AWS ドキュメント: [侵入テスト](https://aws.amazon.com/security/penetration-testing/)
# ベストプラクティス 9.3 – セキュリティイベントに対応するための文書化されたプランを持つ
SAP アプリケーションにかかわるセキュリティイベントに対応するための文書化されたプランがなければ、セキュリティチームの対応が遅く、包括的でないものになり、イベントの緩和においても、原因の理解においても、効果の薄いものになる可能性があります。SAP アプリケーションについて、セキュリティ対応パターンを徹底的に文書化します。
**提案 9.3.1 - 文書化されたインシデント管理プランを作成することで、セキュリティイベントに備える**
これは、「AWS Well-Architected Framework セキュリティの柱」のインシデント対応の準備に関するガイダンスに直接対応しています。このドキュメントを参照し、それに従って SAP アプリケーションを含めます。
+ Well-Architected Framework [セキュリティ]: [インシデント対応 - 準備](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/prepare.html)