Connectivity, Security and User Management for SAP HANA Cloud

Explanation

Once a SAP HANA Cloud instance exists, the next practical challenge consultants face is: who and what can connect to it, and how is that access secured and scoped? Unlike a traditional on-premise HANA system where DBA teams manage users directly through database tools with broad network access inside a corporate firewall, SAP HANA Cloud is designed for cloud-native, service-oriented access patterns where connectivity is explicit, credential-based, and scoped per application. The primary connectivity model in Cloud Foundry is through service instances and service keys. When a CAP or HDI-based application is deployed, it typically has an HDI container service instance bound to it. The bind operation generates credentials (host, port, user, password, certificate information) injected into the application's environment (VCAP_SERVICES). The application's runtime never needs a manually configured JDBC string with hardcoded credentials; the platform manages credential delivery. This reduces the risk of credentials being committed to source control, but it also means consultants must understand service instance and service key lifecycles, because rotating or deleting a service key can break a running application until it is rebound or restarted. For Kyma or external tools that are not native Cloud Foundry applications, service keys can be created explicitly to obtain a reusable set of credentials. This is common for BI tools, ETL utilities, or administrative scripts that need direct SQL access. Consultants should treat service keys as sensitive secrets: they typically contain a certificate and hostname sufficient to open a direct database connection, so they must be stored in secure credential stores, not in code repositories or shared spreadsheets. Security within the database itself is managed through HDI container users and database roles rather than broad SYSTEM-level access. Each HDI container has a technical user with privileges scoped to that container's schema. Application developers work with design-time roles defined in the HDI project (as .hdbrole or CAP-based role definitions) which are activated into the container and granted to users or other roles. This is a significant shift from classic HANA administration where roles were often created directly via SQL console; in HANA Cloud with HDI, roles-as-code is the recommended pattern because it version-controls authorization changes alongside the data model. Network-level security separates two connectivity directions. Inbound connectivity to HANA Cloud from BTP applications in the same subaccount is typically straightforward via service bindings. Outbound connectivity from HANA Cloud (or from BTP applications) to on-premise systems, or inbound connectivity from on-premise tools to HANA Cloud, requires the SAP Cloud Connector, which establishes a secure reverse-invoke tunnel without opening inbound firewall ports on the on-premise side. Consultants configuring hybrid scenarios, such as replicating data from an on-premise S/4HANA system into HANA Cloud via SLT or SDI, need to understand which direction Cloud Connector is protecting and configure the appropriate virtual-to-internal host mappings. Encryption in transit is enforced by default for HANA Cloud connections; TLS/SSL is mandatory and not optional in most landscapes, meaning JDBC/ODBC clients must be configured with the correct certificate trust store. A common early-project blocker is client tools failing to connect because the local trust store does not include the required certificate authority, especially with older client driver versions. For administrative or cross-container access, HANA Cockpit provides a web-based interface where authorized administrators can review users, roles, workload, and audit certain security-relevant events, but production organizations should still layer SAP BTP identity and access management (via the subaccount's trust configuration, typically federated to a corporate identity provider) on top of raw database credentials wherever human access to the cockpit is required, rather than sharing a single administrative password.

Code example

-- Example: reviewing HDI container users and roles from SQL console (illustrative, syntax approximate) -- 1. List schemas/containers visible to the current administrative userSELECT SCHEMA_NAME FROM SYS.SCHEMAS WHERE SCHEMA_NAME LIKE '%HDI_CONTAINER%'; -- 2. Example design-time role definition (in .hdbrole file, activated via HDI deployer)-- File: src/reader-role.hdbrolerole reader_role {    catalog schema "MY_CONTAINER_SCHEMA": SELECT} -- 3. Example CDS-based role restriction in a CAP service (Node.js/CDS project)-- srv/catalog-service.cdsservice CatalogService {  entity Products as projection on my.Products;}annotate CatalogService with @(requires: 'authenticated-user'); -- 4. Creating a service key for external tool access (Cloud Foundry CLI)-- cf create-service-key my-hana-instance my-service-key-- cf service-key my-hana-instance my-service-key-- (returns JSON with host, port, certificate, user credentials for JDBC/ODBC clients) -- 5. JDBC connection string pattern for a BI tool using the service key output-- jdbc:sap://<host>:443/?encrypt=true&validateCertificate=true&currentschema=MY_CONTAINER_SCHEMA

Real project scenario

A project team building a CAP-based procurement analytics application on SAP BTP needed a third-party BI tool to read aggregated purchasing data directly from the HANA Cloud instance backing the application, without going through the application's own OData API. The integration architect created a dedicated read-only HDI role scoped to a reporting view schema, generated a service key exposing only that role's credentials, and configured the BI tool with the service key's JDBC connection details and the required TLS certificate. Separately, the same landscape needed to replicate a subset of master data from an on-premise ECC system; because HANA Cloud cannot directly reach the on-premise network, the Cloud Connector was configured on the customer's side to expose the ECC's RFC destination virtually to the BTP subaccount, and an SLT replication job was pointed at that virtual destination. Distinguishing which credentials belonged to the application binding versus the BI tool's service key versus the Cloud Connector's virtual destination configuration was essential to avoid granting overly broad access in any single integration point.

Common mistakes

• Embedding service key credentials directly in application code or committing them to a git repository instead of storing them in a secure credential store or environment variable. • Granting the default HDI container technical user broad privileges beyond its own schema instead of creating narrowly scoped reader/writer roles for each consuming application. • Assuming a single shared administrative database user is acceptable for multiple developers or tools, which removes traceability and complicates later access reviews. • Forgetting that deleting or regenerating a service key invalidates existing connections using the old key, causing unexpected outages in connected BI or ETL tools. • Not configuring TLS certificate trust correctly in older JDBC/ODBC client tools, resulting in connection failures that are misdiagnosed as network or firewall issues. • Overlooking that Cloud Connector is required for on-premise connectivity and attempting to point on-premise systems directly at HANA Cloud's public endpoint, which does not reflect the supported hybrid architecture.

Best practices

• Define authorization using design-time artifacts (.hdbrole, CDS @requires and @restrict annotations) so access control changes are reviewed and version-controlled alongside data model changes. • Scope each external tool or integration to its own service key and HDI role rather than sharing one broad credential across multiple consumers. • Rotate service keys periodically and immediately after any suspected credential exposure, coordinating rotation with all dependent applications to avoid unplanned downtime. • Store all service keys and credentials in a secure secrets manager, never in source code, shared documents, or plaintext configuration files. • Validate TLS certificate trust configuration in every client tool during initial setup rather than after a production incident. • Use Cloud Connector with the principle of exposing only the specific on-premise systems and ports required for the integration, not broad network ranges.

Interview angle

Interviewers frequently probe whether a candidate understands the difference between application-level service bindings and manually created service keys, and why HDI roles-as-code is preferred over ad hoc SQL-console role creation in HANA Cloud. A strong answer explains that service bindings are scoped and lifecycle-managed automatically for platform-native applications, while service keys are used for external tools needing durable direct credentials, and that both should follow least-privilege role design defined in version-controlled .hdbrole or CDS annotations rather than broad grants. Candidates should also be able to explain, at a conceptual level, why Cloud Connector is needed for hybrid on-premise connectivity and that HANA Cloud does not have direct network visibility into a corporate on-premise landscape without it.