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