Authorization and Access Control

Authorization and Access Control for SAP on Azure

Introduction: The Foundation of SAP Security in the Cloud

When you migrate SAP workloads to Microsoft Azure, the shift from an on-premises data center to a cloud-based infrastructure changes the security perimeter. In a traditional data center, security is often tied to physical access, network isolation, and internal firewalls. In Azure, identity becomes the new perimeter. Authorization and access control are no longer just about who can log into the SAP GUI; they are about who can modify the underlying virtual machines, who can access the database backups in storage accounts, and who can manage the network configurations that allow traffic to flow between your SAP application and database tiers.

Failure to implement a granular, well-structured access control model can lead to catastrophic consequences, ranging from accidental configuration deletion to unauthorized data exfiltration. Because SAP systems typically house an organization’s most critical financial, supply chain, and human resources data, the stakes are incredibly high. This lesson is designed to help you architect an authorization strategy that protects your SAP environment while maintaining the agility required by modern cloud operations. We will move beyond basic permissions and explore how to build a defense-in-depth strategy using Azure Role-Based Access Control (RBAC), Managed Identities, and Privileged Identity Management (PIM).

Understanding the Layers of Access Control

To manage access effectively, you must understand that your SAP environment on Azure consists of multiple layers. Each layer requires a different approach to authorization. If you treat the infrastructure layer the same way you treat the SAP application layer, you will either create security holes or make the environment impossible to manage.

1. The Azure Resource Manager (ARM) Layer

This is the top-level management layer where you control the lifecycle of your SAP resources. This includes virtual machines (VMs), virtual networks, storage accounts, and availability sets. Access here is governed by Azure RBAC. An administrator with "Owner" or "Contributor" access at the subscription level has the power to delete your entire SAP production environment. Therefore, controlling access here is your first line of defense.

2. The Infrastructure Layer (Operating System and Database)

Once a VM is deployed, you have the OS layer (Linux or Windows) and the database layer (HANA, SQL Server, Oracle). Access control here is handled through SSH keys, local user accounts, or integration with Active Directory/LDAP. Managing this separately from Azure RBAC is a common source of friction, but it is necessary for compliance and granular control over the SAP kernel and database files.

3. The SAP Application Layer

This is the layer where SAP users operate. Authorization here is managed via SAP profiles, roles, and authorization objects (Transaction PFCG). While this is "inside" the VM, it is the most critical layer for business logic. Your Azure strategy must account for how these identities are synchronized or mapped, especially when considering Single Sign-On (SSO) scenarios.

Callout: The Identity-Centric Security Model In the past, security was defined by the network (the "moat"). In the cloud, the network is fluid and perimeter-less. Identity is the only constant. By focusing on Azure Active Directory (now Microsoft Entra ID) as your central source of truth for both infrastructure and application access, you can enforce consistent policies regardless of where the user is located or which resource they are trying to access.

Implementing Azure Role-Based Access Control (RBAC)

Azure RBAC is the primary mechanism for controlling who can do what within your Azure subscription. It is built on three components: the security principal (user, group, or service principal), the role definition (what they can do), and the scope (where they can do it).

Best Practices for RBAC Design

When designing your SAP environment, avoid the temptation to assign broad roles like "Contributor" to your SAP Basis team. Instead, use a tiered approach:

• Least Privilege: Grant users only the permissions they need to perform their job. If a team member only needs to start and stop VMs, do not give them permission to delete the virtual network.
• Use Custom Roles: Azure provides built-in roles, but they are often too broad. You can create custom roles in JSON format to define specific actions.
• Scope at the Resource Group Level: Do not assign permissions at the subscription level if you can avoid it. Group your SAP resources (e.g., Prod-SAP-RG, Dev-SAP-RG) and assign permissions to those specific resource groups.

Example: Creating a Custom Role for SAP Basis

If you want to allow your Basis team to manage SAP VMs without allowing them to modify the network or storage, you can define a custom role:

{
  "Name": "SAP Basis VM Operator",
  "IsCustom": true,
  "Description": "Allows starting, stopping, and restarting SAP VMs.",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/deallocate/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscription-id}/resourceGroups/SAP-Production-RG"
  ]
}

Note: Always test your custom roles in a sandbox or development environment before applying them to production. An improperly defined "NotAction" can inadvertently block access to essential management tasks.

Managed Identities: The Secret to Secure Automation

One of the most common mistakes in SAP migrations is hardcoding credentials into scripts. Whether you are using PowerShell, Azure CLI, or Python to automate SAP backups or scaling, developers often store service principal secrets in plain text files or environment variables. This is a significant security risk.

Managed Identities solve this by providing an identity for your Azure resource in Microsoft Entra ID. The resource (e.g., an SAP Application Server VM) uses this identity to authenticate to other Azure services (like Key Vault or Storage Accounts) without needing a password.

How to Implement Managed Identities for SAP

1. Enable the Identity: On your SAP VM, go to the "Identity" tab in the Azure portal and switch the "System assigned" status to "On."
2. Assign Permissions: Go to the target resource (e.g., an Azure Storage account containing SAP backups) and use Azure RBAC to grant the VM's identity the required role (e.g., "Storage Blob Data Contributor").
3. Use the Identity in Code: Instead of using a client secret, your script will now use the Managed Identity to authenticate.

Example: Using Managed Identity in a PowerShell script to access an Azure Storage Account:

# Authenticate using the VM's Managed Identity
Connect-AzAccount -Identity

# Access the storage account without hardcoded keys
$storageContext = New-AzStorageContext -StorageAccountName "sapbackups" -UseConnectedAccount
Get-AzStorageBlob -Container "backups" -Context $storageContext

This approach removes the need to manage secret rotation and prevents credential leakage, which is a major win for security compliance in SAP landscapes.

Privileged Identity Management (PIM)

For highly sensitive operations, such as modifying the SAP HANA database instance or changing Azure network configurations, "always-on" access is a security liability. If an administrator's account is compromised, the attacker has immediate access to your most critical systems.

Azure AD Privileged Identity Management (PIM) allows you to implement "Just-In-Time" (JIT) access. Instead of having permanent administrative rights, users must request elevation.

Configuring PIM for SAP Administrators

• Eligibility: Identify the users who need high-level access and mark them as "eligible" for a specific role (e.g., Contributor).
• Activation: When the user needs to perform a task, they log into the PIM portal and "activate" their role.
• Approval/Justification: You can configure PIM to require multi-factor authentication (MFA) or approval from another administrator before the role is granted.
• Time-Bound: Access is automatically revoked after a set period (e.g., 4 hours), ensuring that administrative rights do not persist indefinitely.

Warning: Never use a shared "SAP-Admin" account. Each administrator must have their own individual identity. Shared accounts make it impossible to perform forensic audits if a configuration change causes a system outage.

Network-Level Authorization: Network Security Groups (NSGs)

While RBAC controls who can manage the Azure environment, Network Security Groups (NSGs) control who (or what) can communicate with your SAP systems. Think of NSGs as a distributed firewall that sits in front of your VMs.

Best Practices for NSG Rules

• Default Deny: Start with a rule that denies all inbound and outbound traffic. Then, add specific rules to allow only the traffic necessary for SAP operations.
• Application Security Groups (ASGs): Use ASGs to group your VMs by function (e.g., ASG-SAP-AppServer, ASG-SAP-DB). This allows you to write rules like "Allow traffic from ASG-SAP-AppServer to ASG-SAP-DB on port 3200" rather than managing rules for individual IP addresses.
• Restrict SSH/RDP: Never allow public internet access to your SAP VMs via SSH (port 22) or RDP (port 3389). Use Azure Bastion or a VPN/ExpressRoute connection.

Managing SAP-Specific Access (The PFCG Layer)

While we have focused heavily on the Azure infrastructure, we must address the SAP application layer. When migrating to Azure, you have the opportunity to integrate your SAP security with your cloud identity provider.

Single Sign-On (SSO) with Microsoft Entra ID

By integrating your SAP system with Entra ID via SAML 2.0 or OIDC, you can enforce MFA for SAP GUI or Fiori access. This prevents unauthorized access even if a user's SAP password is compromised.

1. Configure SAP: Use transaction SAML2 to set up the SAP system as a Service Provider.
2. Configure Entra ID: Create an Enterprise Application and configure the SAML tokens to map the user's Entra ID identity to the SAP username.
3. Enforce MFA: Use Conditional Access policies in Entra ID to require MFA when users attempt to access the SAP application.

Common Pitfalls to Avoid

• Over-Provisioning SAP Profiles: Avoid the "SAP_ALL" profile. It is the most common cause of security breaches in SAP. Use the SAP Profile Generator (PFCG) to build roles based on actual job functions.
• Neglecting the Database Layer: Many administrators focus on the application server but leave the HANA database open to the entire subnet. Ensure that the database port (usually 39xx) is only accessible from the application server's IP address.
• Ignoring Audit Logs: Azure provides detailed activity logs. If you are not sending these logs to a Log Analytics Workspace or a SIEM (like Microsoft Sentinel), you are effectively blind to unauthorized access attempts.

Step-by-Step: Securing an SAP Database Backup

To provide a concrete example of how these concepts come together, let’s look at the process for backing up an SAP HANA database to an Azure Blob Storage account.

1. Create a Storage Account: Provision the storage account with "Secure transfer required" enabled.
2. Access Control: Do not use the storage account access keys. Instead, assign an Azure RBAC role ("Storage Blob Data Contributor") to the SAP HANA VM's Managed Identity.
3. Network Isolation: Use a Private Endpoint to ensure the storage account is only reachable from within your virtual network.
4. Firewall: Configure the storage account firewall to deny all traffic except from the specific VNet containing the SAP HANA database.
5. Monitoring: Enable diagnostic settings on the storage account to log all read/write requests to a Log Analytics workspace.

By following these steps, you have created a secure pipeline for your most sensitive data. You have eliminated hardcoded keys, restricted network access, and provided an audit trail for all operations.

Troubleshooting Access Issues

Even with the best planning, users will eventually encounter "Access Denied" errors. When this happens, follow a systematic approach to identify the root cause:

1. Check Azure Activity Logs: Navigate to the resource that is throwing the error and view the "Activity Log." Look for failed operations—this will tell you exactly which identity attempted the action and which permission was missing.
2. Verify the Scope: Ensure the user has the role assigned at the correct level (Resource Group vs. Subscription).
3. Review Deny Assignments: Check if there are any "Deny" assignments (often inherited from a Blueprints or Policy) that are overriding the "Allow" permissions.
4. Confirm Identity Sync: If you are using federated identities, ensure the user is correctly mapped in Entra ID and the synchronization is not delayed.

Callout: The Role of Azure Policy Azure Policy is not just for compliance; it is a powerful access control tool. You can use policies to enforce "Deny" rules, such as "Prevent any VM from being created without a managed identity" or "Disallow public IP addresses on all SAP VMs." This acts as a guardrail that prevents users from accidentally creating insecure configurations.

Industry Recommendations and Compliance

When working with SAP, you must often comply with standards such as SOX, GDPR, or HIPAA. Authorization is a central pillar of these audits.

• Segregation of Duties (SoD): Ensure that the person who manages the infrastructure (Azure Admin) is not the same person who manages the SAP business roles (SAP Security Admin). This prevents a single individual from being able to bypass all controls.
• Regular Access Reviews: Use Entra ID Access Reviews to periodically check if users still need the administrative access they were granted. If a user changes roles or leaves the project, their access should be automatically revoked.
• Automated Remediation: If a user creates a resource that violates your security policy (e.g., a storage account without encryption), use Azure Policy to automatically remediate or delete the resource.

Summary of Key Takeaways

Migrating SAP to Azure requires a mindset shift from perimeter-based security to identity-based security. By implementing the strategies discussed in this lesson, you can significantly reduce your attack surface and ensure the integrity of your SAP workloads.

1. Identity is the Perimeter: Move away from network-based security and focus on managing identities through Microsoft Entra ID. Use RBAC to enforce the principle of least privilege.
2. Remove Hardcoded Credentials: Always use Managed Identities for automation scripts. This removes the risk of credential theft and simplifies secret management.
3. Implement Just-In-Time Access: Use Privileged Identity Management (PIM) to ensure that administrative access is temporary, audited, and granted only when necessary.
4. Secure the Network: Use Network Security Groups and Application Security Groups to limit traffic. Follow the "Default Deny" rule for all inbound and outbound communication.
5. Integrate SAP Security: Do not treat SAP application security as separate from your Azure identity. Use SSO to enforce MFA and centralize user management.
6. Audit and Monitor: Enable logging for all Azure resources and use a SIEM like Microsoft Sentinel to detect and respond to suspicious activities in real-time.
7. Enforce with Policy: Use Azure Policy as a guardrail to prevent insecure configurations from being deployed in the first place.

By adopting these practices, you create a robust, auditable, and secure environment that supports the critical business processes running on your SAP platform. Security in the cloud is an ongoing process of monitoring, refining, and adapting to new threats, and the authorization framework you build today will serve as the foundation for your organization’s future growth in Azure.