(Jana Subramanian is APJ Principal Cybersecurity Advisor for Cloud Security and Fellow of Information Privacy (FIP) awarded by International Association of Privacy Professional (IAPP). Jana supports strategic customer engagements on cybersecurity, data privacy, multi-cloud security architecture, contractual assurance, audit, and compliance domains.)

Introduction

Transitioning to RISE with SAP cloud services, SAP customers have a choice of opting for either single tenanted or multi-tenanted landscape. The choice of tenancy model largely depends on the evaluation of risk, type of industry, classification of data, security, sectorial and data privacy regulations. Other considerations include performance, reliability, shared security governance, migration, cost, and connectivity. While customer data is always isolated and segregated between tenants, the level of isolation is a paramount consideration in choosing a Tenancy Model.

In this blog, we will cover tenancy models available under RISE with SAP cloud services and explore nuanced differences and some of the consideration for choosing each of the tenancy models.

Principle of Single Tenant Landscape

In the single tenancy model, a single dedicated instance of an application is deployed for each customer. This means that each customer gets a dedicated instance of web, application, and database tiers. This further enhanced with network level isolation. None of the Tiers are shared between other Tenants. This provides strong data isolation, and this architecture model is highly recommended for regulated industries where strict data isolation is required. It should be noted that when “Hyperscaler” is used as IaaS provider, the physical hardware is always shared and the concept of single tenanted always refers to application landscape created for Tenants.

Figure 1: Single Tenant Model

Principle of Multi-Tenant Landscape

This is an architecture model where single software or application architecture can serve multiple distinct user groups. This brings a great deal of standardization in functionalities at a lower cost due to economies of scale supporting larger customer base on a shared platform. Approaches can include, deploying one or more parts of an application as dedicated for each customer, and the rest is shared between all customers. For example, creating a shared architecture for web and application tier and a dedicated database tier for each customer.

Many approaches can be adopted for storing customer data. In a typical deployment, there are commonly three approaches:

1. Same Database, Same Schema with Column Discriminator for each customer ID

• A same database is used for storing all tenants’ data using the same schema for all tables.
• For each Tenant, special column ID is added to associate each record corresponding to the Tenant ID. This deployment provides highest cost saving, excellent resource usage but offers minimum customizations.
• In general, this approach is not recommended for large enterprises or regulated customers as data isolation is weak.
• Any implementations that are tenant specific, including tenant specific backups are not possible to implement.

Figure 2: Same Database, Same Schema – Column Discriminator

       2. Shared Database, Separate Table/Schema for each customer ID

• This approach is better than column discriminator since multiple tenants of an application to isolate their data in one or more tenant-specific tables/schema.
• This is achieved by creating a different table or schema in the database for each tenant. A tenant table discriminator specifies how to discriminate the tenant’s tables from the other tenants’ tables.
• The tenants’ tables can be in the same schema, using a prefix or suffix naming pattern to distinguish them; or they can be in separate schema, using a schema tenant table discriminator.
• This is a highly recommended model for multi-tenancy as it offers balance between cost efficiency and tenant data separation.
• The deployment approach provides an ability to store all tenants in a single database yet provide creation of different schema for its tables for each of the Tenant.
• This provides each tenant its own set of tables/schema within the same database.

Figure 3: Same Database, Seperate Table

      3. Shared Database, Separate Tenant Database for each customer

• Shared Database, Tenant Database for each customer ID
• This method allows for data Isolation to be achieved by creating a different database container, also known as a tenant database, for each customer/tenant.
• SAP HANA supports multiple isolated databases in a single HANA system.
• All database objects, such as schemas, tables, views, and procedures, are local to the tenant database.
• This method allows to achieve a high degree of isolation and security
• Additional benefits include customization and tenant specific backup and restore capabilities.

Figure 4: Same Database, Separate Tenant DB

Tenancy Model with SAP S/4HANA Cloud, Private Edition

The SAP S/4HANA Cloud, Private Edition is a single tenant landscape with the following key characteristics:

• Each customer gets a separate account (AWS), subscription (Azure) or Project in GCP.
• A separate network level separation is achieved via logically isolated Virtual Private Network (VNET)/VPC. This is to address specific system/data isolation requirements. Within each Virtual Network, there will be multiple subnets (using private CIDR block IP addresses) created to segregate the environments
• Each subnet is configured with Security Group with specific set of rules to control the network traffic.
• A separate S/4HANA application and Database Instance landscape for customer assigned Private IP Address space
• The production and non-production environment consisting of application instance, SAP HANA instance, Web Dispatcher, Cloud Connectors are deployed separately for each customer.
• Security policies that are defined at the higher-level hierarchy are pushed to each subscription/ project/ account. Data replication traffic from primary to DR site will always go via private connectivity (peering)
• Customer can have access to SAP S/4HANA applications hosted in VPC/VNET via a private dedicated connectivity.
• Backup services are integrated with native and 3^rd party services.

Figure 5: SAP S/4HANA Cloud, Private Edition Tenancy Model

• Customers can use IPSEC based Site-to-Site (S2S) VPN over Internet to connect to their dedicated virtual network in the cloud.
• A dedicated private connection with redundancy is recommended for accessing productive workload as it ensures quality of service and higher availability service levels.
• Hyperscaler provided solutions such as AWS Direct Connect, Azure ExpressRoute and GCP Cloud Interconnect can be used to establish such network connection. Information around edge locations and networking partners can be found in respective Hyperscaler documentation.
• A Web Application Firewall (WAF) is used to secure the internet inbound access. Such an access is not turned on by default and customer would require highlighting this requirement as part of onboarding preparation.

Figure 6: SAP S/4HANA Cloud, Private Edition – Network Landscape (AWS)

Tenancy Model with SAP S/4HANA Cloud (Public SaaS)

• SAP S/4HANA Cloud achieves multitenancy by sharing the SAP HANA system between multiple tenants. SAP HANA supports multiple isolated databases in a single SAP HANA system. This is known as tenant databases.
• SAP S/4HANA Cloud is leveraging the SAP HANA tenant databases in such a way that each tenant gets its own tenant database
• Each tenant has own dedicated ABAP application servers running on separate SAP HANA tenant databases. Tenant databases are independent databases within one SAP HANA database system, and they contain all tenant-specific application data and configuration. The isolation ensures that it impossible for one tenant to access another tenant’s data.
• Each tenant is completely isolated from the others by having its own ABAP application servers and tenant database. Each tenant is self-contained and fully isolated so that each tenant has, for example, its own database catalog, persistence, and backups.
• All tenant databases share the same installation of the database system software and the same system administration, and to a greater extent the same computing resource. All SAP HANA servers such as compile server and the pre-processor server, run alongside the central system database, and serve all tenant databases of an SAP HANA system. Each database is self-contained and fully isolated runs its own database catalog, persistence, and backups.
• All database objects, such as schemas, tables, views, and procedures, are local to the tenant database.

Figure 7: SAP S/4HANA Cloud (Public SaaS) Tenancy Model

Tenancy Model of SAP Business Technology Platform

• SAP Business Technology Platform operates on Platform as a Service (PaaS) model on a multi-tenant landscape. While various components and organizations leveraging SAP BTP share same physical resources, these resources are strictly isolated per tenant/organization. The data owned by a tenant/org is segregated from other tenants/organization. SAP runs SaaS applications such as SAP Analytics Cloud (SAC) and other industry cloud application leveraging this platform and a SaaS tenant can consume these business applications running on the platform
• SAP partners or customer can subscribe to SAP BTP under various licensing models to build, develop applications and deliver SaaS applications. The SAP BTP offers data management, analytics, artificial intelligence, application development, automation, and integration in one, unified environment.
• A global account represents a functional scope of the platform that a customer is entitled to be based on the license. SAP invoices are issued at the global account level.
• A sub-account is associated with a region where applications, data and services are hosted in a supported environment. The sub-account represents tenant at run-time.
• A simplified model is represented in the diagram below:

Figure 8: SAP Business Technology Platform Account Model

A detailed multi-tenant architecture concept in SAP Business Technology Platform is beyond the scope of this blog. However, you can refer to a blog titled “Multitenancy Architecture on SAP Cloud Platform, Cloud Foundry environment” to get insight into a architecture behind SAP Business Technology Platform. You can also read an introductory blog on Approuter and XSUAA. The conceptual explanation of Tenant identification and propagation is explained in the below diagram.

Figure 9: Tenant Identification and Propagation

Conclusion

SAP provides many SaaS based cloud applications that are powered by SAP HANA, allowing multi-tenant architecture offering multiple isolated tenant databases in one SAP HANA. The multi-tenant model brings down total cost of ownership, ease of management, data isolation, tenant specific customization. For highly regulated customers such as FSI, health care and defense prefer single tenant landscape for greater data isolation to meet their compliance obligation and for dedicated private network connectivity. SAP cloud architecture approach to variety of tenancy models provide customers with choice and agility while maintaining performance, scalability, cost reduction, security, and regulatory compliance.

(Disclaimer: The perspectives or opinions expressed in this blog are for information purposes only and should not be construed as a legal advice.  The content in this blog does not constitute any representation, or any commitment or legal obligation on the part of SAP)