# 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)