# 7 – Control access to your SAP workload through identity and permissions
**How do you control access to your SAP workload?** Use mechanisms provided by AWS, SAP, and other third parties to ensure that end users and interfacing systems are properly identified and authenticated. How are permissions controlled to ensure least privilege? How is access audited and reported on? Start by identifying your user categories and then systematically work through the controls and your identity management approach to limit access to your SAP workload.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/latest/sap-lens/design-principle-7.html)
# Best Practice 7.1 – Understand your SAP user categories and access mechanisms
The types of users accessing your SAP system will determine the security controls you need to apply. By examining each use case, you can develop a strategy. This should include how you manage identities, authentication, tooling and mechanisms to support those requirements.
**Suggestion 7.1.1 Understand data access permissions and permitted actions**
SAP systems often contain highly sensitive business data. As you define your user types, understand the data access permissions. (For example, an administrative database user does not have the fine-grained controls of an application user, and therefore may be more critical.) Also refer to [Security]: [Best Practice 5.2 - Classify the data within your SAP workloads](best-practice-5-2.md).
Consider the following questions in relation to your SAP system access:
+ Do the actions taken by an administrative or service user need to be traceable to a uniquely identifiable individual?
+ At which layer of the application will the access be granted?
+ Can you restrict access to a subset of functionality via permissions?
+ Can you restrict access to a subset of functionality via other controls, for example exposing only certain services?
+ Is there a requirement to audit the actions taken?
**Suggestion 7.1.2 – Understand the network and/or location from which users will access the SAP systems**
Network and/or location often contributes to the security risk profile and may determine whether the user is considered trusted or untrusted. Typically, this is coupled with the controls to prevent unauthorized access (refer to [Best Practice 6.1 - Ensure that security and auditing are built into the SAP network design](best-practice-6-1.md)).
This can influence your design. For example, an untrusted internet user or device may require additional factors of authentication to access your SAP workload, when compared with a trusted user from your corporate network.
# Best Practice 7.2 – Manage privileged access to your SAP workload
Adopt an approach of least privilege where possible. Only grant the minimum access required to perform a particular role to a minimum set of users, while managing usability and efficiency. There are administrative accounts (for example, `adm`), which by default, have access to significantly impact the reliability or data security of your SAP workload. Consider how you can limit this risk.
**Suggestion 7.2.1 – Manage AWS credentials and authentication**
AWS Identity and Access Management (IAM) enables you to manage access to AWS services and resources securely. Using IAM, you can create and manage AWS users and groups for different SAP and cloud administration tasks. Use IAM permissions to allow and deny users access to AWS resources. Standard guidance should be followed, in particular restricting and securing root access.
+ AWS Documentation: [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
For access that is not assigned to a user but is required for the operation of the SAP application, pay particular attention to ensuring least privilege.
+ AWS Documentation: [Using an IAM role to grant permissions to applications running on Amazon EC2 instances](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)
[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) helps identify security risks associated with resources that are shared with an external entity, validates policies against IAM policy grammar and best practice, and can generate an IAM policy from the analysis of AWS CloudTrail logs. Consider its use as a mechanism for continuously reducing permissions based on user and role access patterns.
**Suggestion 7.2.2 – Manage SAP Administrative credentials and authentication**
Implement a process for approving and granting elevated permissions only when required, for a limited time-period. Use auditing functionality that addresses who and why the access was granted.
Restrict the use of username/password for privileged accounts. Disable direct access where possible. Store credentials securely, for example, in a privileged access management solution or password vault.
Evaluate how Systems Manager could be used to restrict direct operating system access for specific tasks using runbooks, RunCommand, and AWS Secrets Manager.
+ AWS Documentation: [Restricting access to root-level commands through SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-restrict-root-level-commands.html)
+ AWS Documentation: [Referencing AWS Secrets Manager secrets from Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html)
# Best Practice 7.3 – Understand your organization’s identity management approach, and its application to SAP
Typical SAP workloads will consist of multiple systems and therefore multiple identities. A centralized approach for managing these users can reduce the security risk and operational complexity. Your focus should be on how to use AWS services and third-party tools in your approach to SAP security, considering such options as centralized user management, single sign-on, and multi-factor authentication.
**Suggestion 7.3.1 – Determine an Identity Provider for named users**
Users will be associated with an identity store, for example Active Directory. This acts as a central repository for managing identity information, such as roles, permissions, and identifiers. For each set of identities, determine if this can be associated with an Identity Provider. An identity provider enables you to off-load the authentication of users. It facilitates single sign-on (SSO) and also manages the user identity lifecycle (for example joiners, movers, leavers).
Consider exceptions for named users that are not associated with a human. This may include batch, job scheduling, integration, and monitoring users.
+ AWS Documentation: [AWS Directory Service \$1 Amazon Web Services (AWS)](https://aws.amazon.com/directoryservice/)
+ AWS Documentation: [AWS Identity Services](https://aws.amazon.com/identity/)
**Suggestion 7.3.2 – Determine the authentication mechanisms**
Understand the supported authentication mechanisms (for example, SAML, Kerberos, X.509, SAP Single Sign-On tickets) at each of the layers for your SAP workload. Evaluate the requirements to integrate with your application. Where possible use single sign-on to avoid the administrative and security impact of managing multiple user credentials.
+ SAP Documentation: [User Authentication and single sign-on](https://help.sap.com/viewer/621bb4e3951b4a8ca633ca7ed1c0aba2/LATEST/en-US/4a112f1a2228101ee10000000a42189b.html)
+ AWS Documentation: [Cloud applications - AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/saasapps.html)
+ SAP on AWS Blog: [Enable SAP Single Sign On with AWS IAM Identity Center Part 1: Integrate SAP NetWeaver ABAP with IAM Identity Center](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 Blog: [Enable SAP Single Sign On with AWS IAM Identity Center Part 2: Integrate SAP NetWeaver Java](https://aws.amazon.com/blogs/awsforsap/enable-sap-single-sign-on-with-aws-sso-part-2-integrate-sap-netweaver-java/)
+ SAP on AWS Blog: [Enable Single Sign On for SAP Cloud Platform Foundry and SAP Cloud Platform Neo with IAM Identity Center](https://aws.amazon.com/blogs/awsforsap/enable-single-sign-on-for-sap-cloud-platform-foundry-and-sap-cloud-platform-neo-with-aws-sso/)
**Suggestion 7.3.3 – Consider multi-factor authentication**
Multi-Factor Authentication (MFA) is a best practice that adds an extra layer of protection on top of your logon credentials. These multiple factors provide increased security for your SAP application. Use cases include: access to SAP from an untrusted device; access to the AWS Management Console; and privileged activities such as deletion of backups or termination of EC2 instances.
+ SAP on AWS Blog: [Securing SAP Fiori with MFA](https://aws.amazon.com/blogs/awsforsap/securing-sap-fiori-with-multi-factor-authentication/)
+ AWS Documentation: [Using MFA devices with your IAM sign-in page - AWS Identity and Access](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_sign-in-mfa.html)
+ AWS Documentation: [Configuring MFA delete -Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html)
+ AWS Documentation: [Amazon EC2: Requires MFA (GetSessionToken) for specific EC2 operations](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_require-mfa.html)
**Suggestion 7.3.4 – Determine the approach to certificate management**
Client-based certificates can be used for authentication without the need for credentials. Determine an approach which includes time-based expiration for session management and certificate rotation for system to system communication. AWS provides a Certificate Authority (CA) that is trusted by SAP. Certificates can be issued and managed using [AWS Certificate Manager (ACM)](https://aws.amazon.com/certificate-manager/).
+ SAP Note: [2801396 - SAP Global Trust List](https://launchpad.support.sap.com/#/notes/2801396) [Requires SAP Portal Access]
+ SAP Note: [3040959 - How to get a CA signed server certificate in ABAP](https://launchpad.support.sap.com/#/notes/3040959) [Requires SAP Portal Access]
+ SAP Lens [Operational Excellence]: [Suggestion 3.4.1 - Create specific runbooks for SAP security operations](best-practice-3-4.md)
+ SAP Lens [Operational Excellence]: [Suggestion 4.1.2 - Maintain a calendar for expiring of credentials, certificates and licenses](best-practice-4-1.md)
# Best Practice 7.4 – Implement logging and reporting for user access and authorization changes and events
User access and authorization events in your SAP systems should be logged, analyzed, and audited regularly. Consolidate and correlate security events from your SAP applications and database with other components of your architecture. This can allow for end-to-end tracing in the event of a critical security problem or breach. Automate analysis of events in a central Security Information and Event Management (SIEM) system. This can allow your operations team to understand if any unexpected or suspicious activity occurs outside of the bounds of normal system controls. They can then remediate as needed.
**Suggestion 7.4.1 – Log AWS Identity and Access Management (IAM) events**
Consider keeping a historical log of AWS IAM events. This can be used in detection or audit of user and authorization changes within AWS accounts. Determine your log retention period and types of events to log based on your organizations required security policies.
Enable your operations team to answer audit questions at the infrastructure level for your SAP system:
+ When and by whom was the new AWS console/CLI user created?
+ When and by whom was the AWS IAM role modified?
+ When did the AWS user last successfully sign in?
+ Is there a suspicious number of failed sign-in attempts to the AWS account?
For further information, consider the following:
+ AWS Documentation: [IAM Best Practices: Monitor activity in your AWS account](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#keep-a-log)
+ AWS Documentation: [Logging IAM and AWS STS API calls with AWS CloudTrail](https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html)
+ AWS Well-Architected Framework [Security]: [Detection](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec-detection.html)
+ AWS Security Blog: [Visualizing Amazon GuardDuty findings](https://aws.amazon.com/blogs/security/visualizing-amazon-guardduty-findings/)
+ AWS Security Blog:[Amazon GuardDuty Enhances Detection of EC2 Instance Credential Exfiltration](https://aws.amazon.com/blogs/aws/amazon-guardduty-enhances-detection-of-ec2-instance-credential-exfiltration/)
**Suggestion 7.4.2 – Log user and authorization changes in your operating system**
Consider keeping a historical log of operating system (OS) user and authorization events such that they can be used in detection or audit. Determine your log retention period and types of events to log based on your organizations required security policies.
Enable your operations team to answer audit questions at the operating system level for your SAP system such as:
+ When and by whom was the new superuser OS account created?
+ When and by whom was the OS account permissions modified?
+ When did the OS user last successfully sign in?
+ Is there a suspicious number of failed sign-in attempts for the OS account?
+ When did your OS user last use elevated permissions?
For further information on auditing at the operating system consider:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/latest/sap-lens/best-practice-7-4.html)
**Suggestion 7.4.3 – Log SAP application and database user and authorization events**
Consider keeping a historical log of SAP user and authorization events such that they can be used in detection or audit. Consider both the application stack (for example, ABAP authorizations) and your database (for example, SAP HANA). Determine your log retention period and types of events to log based on your organizations required security policies.
Enable your operations team to answer audit questions at the SAP application and database level for events such as:
+ When and by whom was the new SAP or database account created?
+ When and by whom was the SAP or database account permissions modified?
+ When did the SAP or database user last successfully sign in?
+ Is there a suspicious number of failed sign-in attempts for the account?
+ What sensitive transaction codes or tools did the account last use?
For further information consider the following:
+ SAP Documentation: [SAP Access Control and Governance \$1 User Access](https://www.sap.com/australia/products/access-control.html)
+ SAP Documentation: [SAP NetWeaver ABAP: The Security Audit Log](https://help.sap.com/viewer/280f016edb8049e998237fcbd80558e7/LATEST/en-US/4d41bec4aa601c86e10000000a42189b.html)
+ SAP Documentation: [SAP NetWeaver JAVA: The Security Audit Log](https://help.sap.com/viewer/56bf1265a92e4b4d9a72448c579887af/LATEST/en-US/c769bcb7f36611d3a6510000e835363f.html)
+ SAP Documentation: [SAP HANA: Auditing Activity in SAP HANA](https://help.sap.com/viewer/b3ee5778bc2e4a089d3299b82ec762a7/LATEST/en-US/ddcb6ed2bb5710148183db80e4aca49b.html)
**Suggestion 7.4.4 – Consolidate user and authorization events in a Security Information and Event Management (SIEM) system for analysis**
Consider sending all your user and authorization events from across your SAP workload components into a central SIEM tool to allow correlation and analysis. Use tools like SAP Enterprise Threat Detection, third-party add-ons or directly ship your SAP audit logs from your application and database servers to an ingestion and analysis tool.
Establish baseline behaviors for your workload and monitor for abnormalities to improve detection of security incidents.
Consider [AWS Marketplace SIEM solutions](https://aws.amazon.com/marketplace/solutions/control-tower/siem/) to monitor your workload in real-time, identify security issues, and expedite root-cause analysis and remediation.
For further information, consider the following resources:
+ AWS Marketplace: [SIEM Solutions](https://aws.amazon.com/marketplace/solutions/control-tower/siem/)
+ AWS Documentation: [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/?aws-security-hub-blogs.sort-by=item.additionalFields.createdDate&aws-security-hub-blogs.sort-order=desc)
+ SAP Documentation: [SAP Enterprise Threat Detection](https://help.sap.com/viewer/eb42e48f5e9c4c9ab58a7ad73ff3bc66/LATEST/en-US/e12aa17b106c4c6193b7d593328aad48.html)
+ Well-Architected Framework [Security]: [Security Incident Response](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec-incresp.html)
+ AWS Documentation: [AWS Security Incident Response - Technical Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)