How to Secure SAP Analytics Cloud Data Access

Understanding the SAP Analytics Cloud Security Model

Before implementing controls, you must understand how SAC structures data access. SAC operates on a layered security architecture that governs what data users can see, how they can interact with it, and which systems they can access.

The Three Layers of SAC Data Access

Every SAC data access request passes through three distinct security layers, each with its own controls and potential vulnerabilities:

• System-Level Authentication: Controls which users can connect to SAC and which identity providers (IdPs) they authenticate against—typically SAP Cloud Identity, SAML 2.0, or corporate Active Directory via SCIM.
• Role-Based Access Control (RBAC): Defines what users can do within SAC—create stories, view data, export reports, or administer the system. SAC provides pre-defined roles but also supports custom role creation.
• Data-Level Security: The most granular layer. Includes dataset-level restrictions, row-level security (RLS), and dynamic data masking. This layer is where most misconfigurations occur.

Each layer must be independently hardened. A common mistake is assuming that strong RBAC alone protects data. In reality, a user with the "Viewer" role but no data restrictions can still access every dataset that role has visibility into, including sensitive financial or HR data.

Row-Level Security: Implementation Guide

Row-level security (RLS) is the most powerful data access control available in SAP Analytics Cloud. It restricts which rows of data a user can see based on pre-defined rules tied to user attributes, roles, or membership in organizational structures.

When to Use RLS vs. Dataset-Level Restrictions

Choosing between RLS and dataset-level restrictions depends on the sensitivity and structure of your data:

Implementing RLS with SAP Cloud Identity

SAP Analytics Cloud uses identity attributes from SAP Cloud Identity or an external identity provider to enforce RLS rules. The implementation follows a structured process:

Securing Live Data Connections

One of the most overlooked attack surfaces in SAC is the live data connection to SAP S/4HANA, SAP BW, or HANA Cloud. When users interact with a live query, their SAC credentials are passed through to the source system. If these connections are not properly secured, a user with "Viewer" access in SAC could potentially run unrestricted queries against the backend system.

Configuring Live Data Security in S/4HANA

For live connections to SAP S/4HANA, the security posture depends on the connection type:

• Direct Live Connection (BICS): Uses a dedicated HANA user for all SAC queries. All SAC users run under this shared backend identity. This means any row-level security or authorization must be enforced at the SAC layer, not the backend. This is the most common configuration but also the most vulnerable to privilege escalation if an SAC RLS rule is misconfigured.
• SSO-Enabled Live Connection: Passes the individual SAC user's identity to the backend via SAML bearer assertion or Kerberos. This enables backend authorization checks (e.g., SAP S/4HANA PFCG roles) to apply per-user. This is the recommended approach for data privacy and compliance, but requires additional configuration in both SAC and the backend system.

Dynamic Data Masking for Sensitive Columns

Row-level security controls which rows a user can see, but it does not protect sensitive columns within visible rows. For example, an HR analyst might need to see employee data for their region but should not see salary information or national identification numbers. Dynamic data masking (DDM) solves this by obfuscating column values based on user roles or attributes.

Implementing DDM in SAC Models

SAP Analytics Cloud supports dynamic data masking at the model level. To implement it:

1. In the SAC modeler, identify columns containing sensitive data (e.g., "Salary", "SSN", "IBAN", "Credit_Limit").
2. Create a masking rule that specifies which user groups or roles see the original value and which see a masked version. Masking options include: full obfuscation (XXXXXX), partial mask (e.g., last 4 digits visible), or a fixed replacement value (e.g., "REDACTED").
3. Assign the masking rule to the model. All stories, views, and exports that use this model will automatically apply the masking rules based on the viewer's identity.
4. Test with users from each role group to verify that masking rules apply correctly—both in the SAC web interface and in exported data (PDF, CSV, Excel).

One critical nuance: dynamic masking in SAC applies to the analyst or viewer role, but modelers who build datasets see unmasked data. This creates a SoD exposure. A modeler with access to unmasked salary data and the ability to create stories visible to unauthorized users could inadvertently or maliciously expose sensitive data. This is a scenario that CyberSilo SAP Guardian specifically monitors—detecting when a user with data modeling privileges creates stories containing sensitive columns for broad distribution.

Monitoring and Auditing SAC Access Changes

Data access controls are only effective if you audit and monitor them continuously. SAP Analytics Cloud provides detailed audit logs, but they must be actively reviewed and correlated with your security monitoring solution.

Critical Audit Events to Monitor

Configure your SIEM or SAP security monitoring platform to alert on these specific SAC events:

• User role changes: Any modification to SAC roles, especially promotion to "Admin" or "Modeler".
• Dataset permission changes: When RLS rules or dataset-level restrictions are added, modified, or deleted.
• Live connection modifications: Changes to backend connection strings, authentication methods, or technical user credentials.
• Data export patterns: Large or unusual data exports from SAC—especially if they involve datasets containing sensitive columns.
• Non-compliance with SoD policies: Users who hold both "Modeler" and "Data Administrator" roles simultaneously.

For organizations using top 10 SIEM tools like Microsoft Sentinel, Splunk, or QRadar, SAC audit logs can be forwarded via the SAP Cloud Platform audit log service. However, most SIEM tools lack native understanding of SAP authorization semantics, meaning they generate noise without context-specific SAP security intelligence. A purpose-built solution like CyberSilo SAP Guardian provides pre-built correlation rules specific to SAC authorization changes, reducing false positives and accelerating incident response.

Best Practices for SAC Role Design

The most common source of SAC data access vulnerabilities is poorly designed roles. Organizations often start with the default SAP-provided roles and add permissions iteratively, creating roles that are overly permissive and impossible to audit.

Principle of Least Privilege in SAC

Every SAC role should be designed around the minimum permissions needed for a user to perform their job function. This means:

• Separate "Viewer" from "Analyst" and "Modeler": Most users only need the "Viewer" role. "Analyst" should be restricted to business users who need to create stories. "Modeler" must be tightly controlled and approved by the SAP security team.
• Use role hierarchies with care: SAC allows role hierarchies where child roles inherit permissions from parent roles. This can create unintended privilege escalation if a child role adds permissions that, when combined with parent permissions, create a super-set of access that violates SoD.
• Disable the "Export Data" privilege by default: Most users do not need to export raw data from SAC. Exporting data often bypasses RLS and masking controls, especially when exporting to CSV or Excel. Enable export only for specific use cases and monitor export activity in audit logs.
• Review shared stories and public teams: A user who creates a story and shares it with a public team can expose data beyond the intended audience. SAC does not automatically re-apply RLS rules when stories are shared—the viewer's own RLS scope applies. But if the story uses a live connection with a shared technical user, all viewers see the same data regardless of their SAC role.

Segregation of Duties in SAC

Segregation of duties (SoD) conflicts in SAC can have serious compliance implications under SOX and SOC 2. Common SAC SoD conflicts include:

• A user who can create datasets (Modeler) and view all data (Admin Viewer) can see and potentially exfiltrate data without oversight.
• A user who can manage SAC security (Security Admin) and create stories (Analyst) can bypass their own controls.
• A user who can create SAML identity providers (System Admin) and assign roles (User Admin) can provision accounts with any level of access.

Your SAP security monitoring solution should provide automated SoD conflict detection across all SAC roles and user assignments. CyberSilo SAP Guardian includes pre-built SoD rule matrices aligned with SAP best practices and common audit frameworks, allowing you to detect and remediate conflicts before they become audit findings.

Securing Data Imports and Exports

SAC supports importing data from flat files (CSV, Excel), cloud connectors, and direct feeds from SAP systems. Each import path introduces unique security considerations.

Import Security Controls

• Flat file imports: These bypass all backend authorizations. Any user with "Data Import" or "Modeler" privileges can upload data from a local file, potentially bypassing the security controls of your source systems. Restrict flat file import to a dedicated service account and audit all imports.
• Cloud connector imports: The SAP Cloud Connector acts as a secure tunnel between your on-premises SAP systems and SAC. Ensure the connector uses certificate-based authentication and that the connector user has the minimum required authorizations in the backend SAP system.
• Automated imports: Scheduled imports from BW or S/4HANA should run with a dedicated import user. Audit this user's authorizations regularly—an over-privileged import user can expose data that individual users should not see.

Export Security Controls

Data exports from SAC are a primary data leakage vector. Implement these controls:

• Disable export to CSV and PDF for users who do not have a documented business need.
• For users who require export, apply expiration policies that automatically revoke export permissions after the defined period.
• Log all export operations—including which dataset was exported, the export format, row count, and file size—and correlate with the user's role and recent access patterns.
• If your organization handles sensitive data (GDPR item, PCI DSS cardholder data), block exports containing unmasked sensitive columns entirely. CyberSilo SAP Guardian can be configured to block export operations that match defined sensitive data patterns and alert the security team in real time.

Integrating SAC Security with SAP BTP

SAP Analytics Cloud often operates within a broader SAP Business Technology Platform (BTP) landscape. BTP provides Identity Authentication, Integration Suite, and extension applications that interact with SAC. This integration creates additional security dependencies.

BTP Identity Authentication and SAC

When SAC is integrated with SAP Cloud Identity or BTP Identity Authentication, the security of SAC data access depends on the security of the identity system:

• If an identity administrator creates a generic service user in BTP with access to SAC, and that service user's credentials are compromised, an attacker gains the same level of access assigned to that user.
• If SAML attribute mapping for RLS is misconfigured in the IdP, users receive incorrect attribute values, potentially granting them access to unauthorized data rows.
• Password policies, MFA, and session timeout settings in the IdP directly affect SAC security. Ensure your IdP enforces MFA for all SAC access, especially for users with "Modeler" or "Admin" roles.

Monitor BTP subaccount permissions and service user assignments as part of your SAC security monitoring scope. An attacker who compromises a BTP subaccount could create new service users, modify SAC role assignments, or alter the IdP attribute mapping used for RLS. Tools like CyberSilo SAP Guardian are designed to detect these cross-component attacks by correlating BTP audit events with SAC access logs.

Compliance Mapping for SAC Access Controls

Each enterprise compliance framework requires specific controls around data access in cloud analytics platforms. The following mapping shows how SAC security controls satisfy key compliance requirements: