PUBLIC
SAP HANA Platform SPS 11
Document Version: 1.0 – 2016-09-13
SAP HANA One Security Guide
For Amazon Web Services
Content
1 Introduction................................................................5
2 Overview of SAP HANA One Security Concept......................................7
3 SAP HANA Network and Communication Security...................................9
3.1 Communication Channel Security.................................................9
3.2 Network Security.............................................................11
3.3 SAP HANA One Deployment Options.............................................. 13
3.4 Security Groups.............................................................15
3.5 Data Security in the SAP HANA One Application Layer ..................................16
3.6 Secure Communication in the SAP HANA One Web Layer................................17
3.7 Securing Data Communication...................................................17
Secure Communication Between SAP HANA and JDBC/ODBC Clients....................18
Secure Communication Between SAP HANA and HTTP Clients.........................28
4 SAP HANA User Management................................................. 30
4.1 User Types................................................................ 30
4.2 Standard Users............................................................. 32
4.3 User Administration Tools......................................................36
4.4 Deactivate the SYSTEM User....................................................38
5 Authentication in SAP HANA One.............................................. 40
5.1 Authentication in SAP HANA One Portal............................................40
5.2 Authenticating Access to SAP HANA One...........................................40
5.3 Password Management of SAP HANA One Standard Users...............................41
Change Passwords in the SAP HANA One Management Console........................42
Reset Lost Password for the SAP HANA One Portal Management Console.................43
5.4 SAP HANA Authentication and Single Sign-On....................................... 43
SAP HANA Logon Checks....................................................46
Password Policy..........................................................46
Password Blacklist.........................................................53
Single Sign-On Using Kerberos................................................53
Single Sign-On Using SAML 2.0............................................... 54
Single Sign-On Using SAP Logon and Assertion Tickets...............................57
6 SAP HANA Authorization.....................................................59
6.1 Privileges..................................................................59
6.2 System Privileges............................................................60
2
P U B L I C
SAP HANA One Security Guide
Content
System Privileges (Reference)................................................ 61
6.3 Object Privileges.............................................................65
Object Privileges (Reference).................................................66
6.4 Analytic Privileges........................................................... 69
Creating and Managing Analytic Privileges........................................70
6.5 Package Privileges........................................................... 71
Package Privilege Options................................................... 72
6.6 Application Privileges.........................................................73
6.7 Roles.....................................................................75
Catalog Roles and Repository Roles Compared.................................... 77
Roles as Repository Objects..................................................78
Repository Roles in the Lifecycle of SAP HANA-Based Applications......................80
Standard Database Roles....................................................82
Repository Roles Granted to Standard Database Users...............................85
6.8 Authorization in the Repository of the SAP HANA Database..............................86
Developer Authorization.................................................... 86
_SYS_REPO Authorization in the Repository...................................... 88
Granting and Revoking Privileges on Activated Repository Objects.......................89
6.9 SAP HANA One Samplers...................................................... 91
7 Data Storage Security in SAP HANA............................................ 92
7.1 Server-Side Data Encryption....................................................93
Encryption Key Management.................................................97
7.2 Data Volume Encryption......................................................100
7.3 Secure Internal Credential Store.................................................101
7.4 Protection of Data in SAP HANA Studio Workspaces..................................103
8 Auditing Activity in SAP HANA Systems.........................................104
8.1 Audit Policies..............................................................104
Actions Audited by Default Audit Policy.........................................107
8.2 Audit Trails................................................................109
Audit Trail Layout for Trail Target CSV and SYSLOG.................................111
Audit Trail Layout for Trail Target Database Table..................................113
8.3 Auditing Configuration and Audit Policy Management..................................114
System Properties for Configuring Auditing...................................... 114
8.4 Best Practices for Creating Audit Policies...........................................115
9 Certificate Management in SAP HANA.......................................... 117
9.1 Client Certificates...........................................................119
9.2 Certificate Collections ........................................................119
9.3 SQL Statements and Authorization for In-Database Certificate Management................. 121
10 Security Risks of Trace and Dump Files......................................... 124
SAP HANA One Security Guide
Content
P U B L I C 3
11 SAP HANA Content.........................................................125
11.1 Components Delivered as SAP HANA Content ...................................... 126
Administration...........................................................126
Application Lifecycle Management.............................................137
Runtime Libraries........................................................ 140
Configuration............................................................141
Supportability and Development..............................................142
User Interface...........................................................145
Role Templates..........................................................148
Documentation..........................................................149
12 Security for SAP HANA One Add-On Manager.....................................151
4 P U B L I C
SAP HANA One Security Guide
Content
1 Introduction
SAP HANA One is a public cloud solution that, among others, uses Amazon Web Service (AWS) as a public
cloud provider.
SAP HANA One Portal is a combination of an SAP HANA One instance and a Web-based management console
for managing and performing administrative tasks on a set of SAP HANA instances. SAP HANA One Portal is
used for managing other SAP HANA instances and itself has SAP HANA running on it.
The SAP HANA One Security Guide provides an overview of the overall security concepts used and
recommended when subscribing to, developing on, and managing SAP HANA One instances for production
and commercial uses.
Target Audiences
Technology consultants
Security consultants
System administrators
About this Document
This guide provides an overview of the security-relevant information that applies to SAP HANA One. It
comprises the following main sections:
Network and Communication Security
This section provides an overview of the communication paths used by SAP HANA One and the security
mechanisms that apply. It also includes descriptions of the various SAP HANA One deployment options.
User and Role Management
This section provides an overview of the following:
Concepts related to user management in the SAP HANA database
Tools for user and role administration
Types of users in SAP HANA
Standard users delivered with SAP HANA
Authentication and Single-Sign On
This section explains how user access to the SAP HANA One instance is authenticated based on cloud
access keys. Password management of standard SAP HANA One users in the management console of
SAP HANA One is covered.
This section also provides an overview of the authentication mechanisms supported by SAP HANA as well
as integration into single sign-on environments.
Authorization
This section provides an overview of the authorization concept of SAP HANA (privileges and roles),
including authorization in the SAP HANA repository. This section also provides security information
relevant to the samplers delivered with SAP HANA One.
SAP HANA One Security Guide
Introduction
P U B L I C 5
Data Storage Security
This section provides an overview of applicable critical data that is used by the SAP HANA database and
the security mechanisms that apply.
This section also provides an overview of the data volume encryption feature available in the SAP HANA
database.
Auditing Activity in SAP HANA Systems
This section provides an overview of the auditing feature of the SAP HANA database.
Certificate Management in SAP HANA
This section provides information about the handling of X.509 client certificates for various purposes in
SAP HANA.
Security for SAP HANA One Add-On Manager
This section explains the mechanisms in place to secure the download and installation of content
packages provided by SAP using the SAP HANA One Add-On Manager.
6 P U B LI C
SAP HANA One Security Guide
Introduction
2 Overview of SAP HANA One Security
Concept
SAP HANA One comprises two components: SAP HANA One Portal and SAP HANA One Console.
The SAP HANA One Portal is a Web-based console that is used to perform common administration tasks on an
SAP HANA One instance. It can be used to manage or unmange SAP HANA One instances, as well as provision
new SAP HANA One instances.
The SAP HANA One Console is also a Web-based console used to manage individual SAP HANA instances.
SAP HANA One instances are intended for production use and therefore need to be protected from improper
use.
Maximum protection against attacks is ensured through a focus on the following aspects:
Strong encryption is used to protect the transfer of sensitive information such as passwords and keys are
passed across the network from any potential breech.
Passwords and keys are stored in the instance for various use cases. Unauthorized access to this
information is not possible.
All actions executed in an instance require authorization.
Secure Communication
Communication between the management console of SAP HANA One Portal and the SAP HANA instance is
secured using Secure Sockets Layer (SSL) and Transport Layer Security (TLS). The following variants are
possible:
SAP HANA One Portal management console and SAP HANA instance reside on the same AWS instance
SAP HANA One Portal management console and SAP HANA instance reside on different AWS instances
Supported SSL/TLS
SAP HANA One version 3.0 and higher supports SSL 3.0. As of SAP HANA One version 4.3, only TLS 1.0 and
higher is supported.
SAP HANA One Security Guide
Overview of SAP HANA One Security Concept
P U B L I C 7
Request Flows
Web traffic from a browser enters SAP HANA One Portal through two paths: one based on servlet methods
and the other using the Apache CGI (Common Gateway Interface). These correspond to the two types of
request flow possible within the SAP HANA One Portal instance:
Privileged flows
Privileged components are those running as root or hanaoneroot user. The hanaoneroot is a privileged
user that belongs to the root group but does not have access as root. All servlet Web flows run as
hanaoneroot. All daemons run as root.
Non-privileged flows
Apache CGI flows are strictly non-privileged. Any security-critical work in the core must executed as the
root user. It cannot be called directly from this non-privileged flow. Instead, the CGI call must use SSH to
access as the root user with SSH keys and then execute any commands.
When SAP HANA One Portal and SAP HANA are installed on different AWS instances, SAP HANA One
Portal forwards the requests over TLS to SAP HANA running on a different instance.
8
P U B L I C
SAP HANA One Security Guide
Overview of SAP HANA One Security Concept
3 SAP HANA Network and Communication
Security
Several mechanisms are possible for securing network communication in the SAP HANA landscape.
The components of an SAP HANA landscape communicate through different network communication
channels. It is recommended security practice to have a well-defined network topology to control and limit
network access to SAP HANA to only those communication channels needed for your scenario, and to apply
appropriate additional security measures, such as encryption, where necessary. This can be achieved through
different means, such as separate network zones and network firewalls, and through the configuration options
provided by SAP HANA (for example, encryption). The exact setup depends on your environment, your
implementation scenario, and your security requirements and policies.
3.1 Communication Channel Security
The network communication channels used by SAP HANA can be categorized into those used for database
clients connecting to SAP HANA and those used for internal database communication. SAP recommends
using encrypted communication channels where possible.
SAP HANA supports encrypted communication for network communication channels. We recommend using
encrypted channels in all cases where your network isn't protected by other security measures against attacks
such as eavesdropping, for example, when your network is accessed from public networks. Alternatively, use
virtual private network (VPN) tunnels to transfer encrypted information.
The following is an overview of the network communication channels used by SAP HANA.
Overview of Connections
To support the different SAP HANA scenarios and set-ups, SAP HANA has different types of network
communication channels:
Channels used for external access to SAP HANA functionality by end-user clients, administration clients,
application servers, and for data provisioning through SQL or HTTP
Channels used for SAP HANA internal communication within the database
Channel used for internal communication between SAP HANA One Portal and SAP HANA One instance(s)
The connections between SAP HANA and external components and applications come under these
categories:
Connections for administrative purposes
Connections for data provisioning
Connections from database clients that access the SQL/MDX interface of the SAP HANA database
SAP HANA One Security Guide
SAP HANA Network and Communication Security
P U B L I C 9
Connections from HTTP/S clients
Outbound connections
The following tables provide more information about these connections:
Table 1: Database Client Access
Client
Protocol and Additional Information TCP Port
End-user clients that access the
SAP HANA database directly
Example: Microsoft Excel
You must enable SQL/MDX access for all database
clients.
External and internal host names are mapped for
database client access. You can change the default
mapping. For more information, see the SAP HANA
One Administration Guide.
The protocol used for database client access is
ODBC or JDBC.
3xx15
3xx17
SAP HANA studio
This connection is used for ad
ministrative purposes (for exam
ple, to access user data, configu
ration data or trace files) or for
modeling purposes (to access
data models).
Table 2: HTTP/S Client Access
Client
Additional Information TCP Port
Examples: a Web browser or a
mobile device
Access for applications based on SAP HANA Ex
tended Application Services (SAP HANA XS). For
more information, see the
SAP HANA Developer
Guide.
80xx (HTTP)
443 (HTTPS)
SAP HANA One Add-On Manager
UI toolkit for SAP HANA Info Ac
cess
Table 3: Administrative Tasks
Client
Additional Information TCP Port
SAP HANA studio The connection to the instance agent acts as an ad
ministrative channel for low-level access to the
SAP HANA instance to enable features such as
starting or stopping the SAP HANA database.
The protocol used for this connection is ODBC or
JDBC.
5xx13
5xx14 (SSL)
Other administrative tasks, mainly database administration, use the SQL/MDX channel of the database.
10
P U B L I C
SAP HANA One Security Guide
SAP HANA Network and Communication Security
Table 4: Database Internal Communication
Client TCP Port
Local host 3xx00
3xx01
3xx02
3xx03
3xx05
3xx07
Note
The instance number of an SAP HANA One instance is 00. We strongly recommend that you do not change
the instance number or SID of your SAP HANA One instance.
Table 5: SAP HANA One Portal Internal Communication
Client
Additional Information TCP
Local host or SAP HANA One Portal This connection is used for communi
cation between SAP HANA One Portal
and the HANA One instance irrespec
tive of whether they are installed on the
same AWS instance or not.
60555 (SSL)
Related Information
Securing Data Communication [page 17]
SAP HANA One Administration Guide
3.2 Network Security
To integrate SAP HANA securely into your network environment, several general recommendations apply.
Caution
It is strongly recommended that you apply the measures described in this section to protect access to the
SAP HANA database's internal communication channels and to mitigate the risk of unauthorized access to
these services.
SAP HANA One Security Guide
SAP HANA Network and Communication Security
P U B L I C 11
Network Zones
We recommend that you operate the different components of SAP HANA One in separate network zones.
To prevent unauthorized access to SAP HANA One and the SAP HANA database through the network, use
network firewall technology to create network zones for the different components and to restrictively filter
the traffic between these zones implementing a "minimum required communication" approach.
We recommend that you operate SAP HANA One in a protected environment. Allow only dedicated
authorized network traffic from other network zones (for example, user access from the client network
zone) to follow these rules:
Clients accessing external standard database functionality, for example by SQL, have only access to
the database client access port.
Clients (for example, browser applications) accessing SAP HANA through the HTTP access feature of
SAP HANA Extended Application Services (SAP HANA XS), for example SAP HANA UI Toolkit for Info
Access, have only access to the SAP HANA XS ports.
Some administrative functions (for example, starting and stopping the SAP HANA instance) have
access to the administrative ports.
SAP HANA XS exposes some administrative applications (for example, administration of Security
Assertion Markup Language (SAML) for user authentication). We recommend using URL filtering (for
example, reverse proxy) to control the exposure of different applications to different network zones.
In SAP HANA One, database internal communication channels are only used for communication within the
database.
Access to the network ports for database internal communication from other network hosts is blocked by
default. We recommend that you do not change this setting. The internal communication ports are bound to
localhost.
Note
The same communication channels are used for communication between the different processes on a
single host, and the internal IP addresses/ports are by default bound to the localhost interface. Prior to
SPS 06, these ports were by default bound to all network interfaces.
We recommend that you block all access to other ports in the firewall that are not used by the SAP HANA
database. With SAP HANA One Portal, an AWS security group is used to implement a virtual firewall around
the SAP HANA One instances.
Related Information
SAP HANA One Administration Guide
12
P U B L I C
SAP HANA One Security Guide
SAP HANA Network and Communication Security
3.3 SAP HANA One Deployment Options
SAP HANA One on Amazon Web Service (AWS) Marketplace provides two deployment options: EC2-classic
and EC2-VPC (Virtual Private Cloud).
With the EC2-classic configuration, the SAP HANA One instance is directly accessible through the public
interfaces of the instance (elastic or non-elastic). The instance can be directly routed from the Internet unless
ports are closed for that traffic.
You can use the AWS EC2 Management Console to deploy your SAP HANA One instance in the EC2-classic
configuration.
Figure 1: EC2-Classic Deployment
SAP HANA One also supports the more secure EC2-VPC configuration. This allows you to deploy your SAP
HANA One instance in an existing VPC.
In a VPC, the traffic always ends at a virtual network layer. It then gets routed to the correct instance and
configured port. The instances are all on port 10. Networks cannot therefore be routed from outside. It also
allows ports to be opened only as local network. In this way, it is possible to ensure that private traffic never
leaves the local network and is not vulnerable to sniffing. SAP HANA One does not interfere with the
configuration of the VPC and therefore does not compromise its security. All communication used by the SAP
HANA One components among themselves either use local loopback or are protected using SSL at the
transport layer.
The following figures show simple examples of EC2-VPC deployment options using access through the
Internet or your own data center.
Figure 2: EC2-VPC Deployment Access Via Internet Gateway in a Private Subnet
SAP HANA One Security Guide
SAP HANA Network and Communication Security
P U B L I C 13
Figure 3: EC2-VPC Deployment Access Via Corporate Network
For more information about setting up and operating an AWS VPC environment, see the Amazon VPC
documentation.
Related Information
Amazon VPC
14
P U B L I C
SAP HANA One Security Guide
SAP HANA Network and Communication Security
3.4 Security Groups
Firewall settings are defined in Amazon Web Service (AWS) security groups, which control traffic to SAP
HANA One.
AWS manages network security based on a collection of settings called security group. This limits the ports on
which incoming traffic can reach the instance and the protocol allowed. The SAP HANA One instance only
opens the ports that are required and only on the protocol needed. This limits the surface area of any possible
attack.
When you launch SAP HANA One, only the following ports are open by default:
Port 22 for SSH
Port 80 for HTTP
Port 443 for HTTPS
Port 60555 for custom TCP
Additional ports required by SAP HANA One are opened when you configure the server using the management
console of SAP HANA One. For more information about security groups, see the Amazon EC2 Security Groups
section in the Amazon Elastic Compute Cloud User Guide.
Recommendation
Restrict the security group policies so that only the IP address of the clients that you want to communicate
with the SAP HANA One instance are allowed.
The following additional ports are opened when you configure the SAP HANA One instance from the
management console of SAP HANA One:
Table 6:
Deployment Scenario
AWS Instance Required Ports
SAP HANA One Portal and SAP HANA
on the same AWS instance
SAP HANA One Portal with SAP HANA
2 (SSH)
80 (HTTP)
443 (HTTPS)
30015
50013
8000
SAP HANA One Portal and SAP HANA
on the different AWS instances
SAP HANA One Portal instance
22 (SSH)
80 (HTTP)
443 (HTTPS)
60555
SAP HANA One instance
30015
50013
8000
60555
SAP HANA One Security Guide
SAP HANA Network and Communication Security
P U B L I C 15
The required ports are used in SAP HANA One Portal as follows:
Table 7:
Port Purpose
30015 JDBC database client access
50013, 50014 SAP Control administrative access
8000 HTTP client access based on SAP HANA Extended Application Services (SAP
HANA XS)
60555 SAP HANA One Portal to SAP HANA communication
Related Information
Amazon Elastic Compute Cloud User Guide
3.5 Data Security in the SAP HANA One Application Layer
SAP HANA One stores security-relevant data (such access keys and certificates) securely and also ensures
that data entered in broswer is transmitted securely.
Secure Store of Security-Relevant Data
SAP HANA One Web flows contain security-relevant data that must be persisted, for example, cloud access
keys and secret keys, PKI private keys, and certificates. SAP HANA One Portal uses openSSH RSA keys for its
public-key infrastructure (PKI) and stores them in the Java KeyStore. Other sensitive data, such as other keys,
are encrypted with the RSA public key and stored in the instance. Only the secure store can decrypt the
sensitive data as needed. The private key never leaves the secure store and cannot be exposed. Every
instance, while initializing, generates the PKI key pair if it does not exist. The key pair is unique to the instance.
In general, it can also be used for basic encryption needs.
Secure Data Transfer
SAP HANA One supports two encryption techniques to protect against the leaking of sensitive data entered in
the browser and sent to the application layer.
When the size of the data elements is smaller than 128 bytes, the RSA PKI is good way to encrypt it. If the data
is larger, a block-encoded sequenced API scans the data and encrypts it. This operation is potentially slow and
CPU consumption is high.
16
P U B L I C
SAP HANA One Security Guide
SAP HANA Network and Communication Security
Therefore, an alternative is supported where an AES (Advanced Encryption Standard) key is generated by the
client and sent to the server. Then, the client can use AES encryption for any large data needs. AES encryption
is faster and has lower CPU usage.
3.6 Secure Communication in the SAP HANA One Web
Layer
Any traffic entering the SAP HANA One instance through the front-end Web layer is always encrypted using
the Secure Sockets Layer (SSL) protocol. This ensures that TCP/IP-based sniffing cannot divulge sensitive
information in the Web flow. New SSL certificates are generated for every SAP HANA One instance for
individual protection.
3.7 Securing Data Communication
SAP HANA supports encrypted communication for client-server and internal communication.
Certificate Collections (PSEs)
A certificate collection (also referred to as a personal security environment or PSE) is a secure location where
the public information (public-key certificates) and private information (private keys) of the SAP HANA server
are stored. A certificate collection may also contain the public information (public-key certificates) of trusted
communication partners or root certificates from trusted Certification Authorities. By default, certificate
collections for client-server communication over JDBC/ODBC are stored within the database. However for
compatibility with previous releases, certificate collections (PSEs) can also be stored in the file system. We
recommend creating the certificate collections in the database directly.
Certificates used for external communication (for example, JDBC client access, HTTP access) are typically
signed by an externally available Certification Authority (CA) because the CA certificates need to be integrated
in the relevant clients.
If your client application is accessing SAP HANA One from outside the SAP HANA One server, we recommend
that you configure HTTPS (SSL) for client access to SAP HANA One. For more information, see Configuring
HTTPS (SSL) for Client Application Access in the SAP HANA One Administration Guide.
We also recommend that you configure secure communication between the SAP HANA server and clients,
including the SAP HANA studio (JDBC-based connection). For more information, see SSL Configuration for
ODBC/JDBC Client Access.
SAP HANA One Security Guide
SAP HANA Network and Communication Security
P U B L I C 17
Related Information
Secure Communication Between SAP HANA and JDBC/ODBC Clients [page 18]
SAP HANA One Administration Guide
3.7.1 Secure Communication Between SAP HANA and JDBC/
ODBC Clients
You can use the Transport Layer Security (TLS)/Secure Sockets Layer (SSL) protocol to secure
communication between the SAP HANA database and clients that access the SQL interface of the database.
Implementing SSL for client-to-server communication provides the following:
Server-side authentication
The server identifies itself to the client when the connection is established. This reduces the risk of man-in-
the-middle attacks and fake servers gaining information from clients.
Data encryption
In addition to server authentication, the data being transferred between the client and server is encrypted,
which provides integrity and privacy protection. An eavesdropper cannot access or manipulate the data.
Client-side authentication and mutual authentication are not supported.
SSL must be configured on both the server and the client.
Remember
Secure communication between the SAP HANA server and HTTP clients (HTTPS) must be configured
separately. For more information, see Configure HTTPS (SSL) for Client Application Access in the SAP
HANA One Administration Guide.
Note
The required configuration is possible using only the SAP HANA studio, not the SAP HANA One
Management Console.
Enforced TLS/SSL for Client Connections
If you want to force all clients communicating with the SAP HANA database via the SQL interface to use a
secured connection, you can set the parameter sslEnforce in the communication section of the
global.ini configuration file to true. The database subsequently refuses SQL connection attempts that
don't use SSL.
Caution
Do not enforce TLS/SSL for client connections unless the monitoring and alerting functions in the system
are being implemented by the embedded statistics service, not the statistics server.
18
P U B L I C
SAP HANA One Security Guide
SAP HANA Network and Communication Security
Related Information
SAP HANA One Administration Guide
3.7.1.1 SSL Configuration on the SAP HANA Server
To use the Transport Layer Secure (TLS)/Secure Sockets Layer (SSL) protocol to secure communication
between the SAP HANA database and clients that access the SQL interface of the database, TLS/SSL must be
configured on both the server and the client.
Before You Start
Before you can configure TLS/SSL on the SAP HANA server, the following general prerequisites must be met:
You have installed a cryptographic service provider on the server.
The SAP HANA One server supports OpenSSL. It is installed by default.
The SAP HANA server possesses a public and private key pair, and a public-key certificate.
The TLS/SSL protocol uses public key technology to provide its protection. The server must possess a
public and private key pair and a corresponding public-key certificate. It uses these to identify itself as the
server component to a requesting client.
In distributed SAP HANA systems, every host must have its own key pair and public key certificate.
You can use the tools provided with OpenSSL to create server certificates.
Note
Regardless of the tool you use, do not password protect the keystore file that contains the server's
private key. For example, when using the SAP Web Dispatcher administration tool to create a personal
security environment (PSE) for the server, do not specify a PIN.
Caution
If your server's keys are compromised, you must replace the key and the certificate.
Configuring TLS/SSL
The properties for configuring TLS/SSL on the server for external communication are available in the
communication section of the global.ini configuration file, which you can edit in the Administration editor
of the SAP HANA studio for example.
SAP HANA One Security Guide
SAP HANA Network and Communication Security
P U B L I C 19
In general, it's not necessary to configure any of the properties explicitly. The default configuration can be
used. However, you do need to create a certificate collection. You do this as follows:
1. Create a certificate collection in the database.
2. Add the server's public key certificate(s) and private key(s).
3. Add the public key certificates of trusted communication partners.
4. Assign the purpose SSL to the PSE.
Note
It is possible to use a certificate collection located on the file system and configured in the global.ini file.
However, we recommend using a certificate collection that exists in the database.
For more information about the properties for TLS/SSL configuration, see Server-Side TLS/SSL Configuration
Properties for External Communication. For more information about creating and configuring certificate
collections in the SAP HANA database, see Certificate Management in SAP HANA.
Related Information
Server-Side TLS/SSL Configuration Properties for External Communication (JDBC/ODBC) [page 20]
Certificate Management in SAP HANA [page 117]
3.7.1.2 Server-Side TLS/SSL Configuration Properties for
External Communication (JDBC/ODBC)
The parameters for configuring TLS/SSL for external communication on the SAP HANA server are available in
the communication section of the global.ini configuration file.
The following table lists the configuration properties that can be used to configure TLS/SSL on the server. In
general, it's not necessary to configure any of the parameters explicitly. The default configuration can be used.
Table 8:
Parameter
Value Default Description
sslMinProtoco
lVersion
{SSL30,TLS10} TLS10 The minimum available
TLS/SSL protocol version
sslMaxProtoco
lVersion
{TLS10,TLS11,TLS12,MAX} MAX The maximum available
TLS/SSL protocol version
sslValidateCe
rtificate
<Boolean value>
false If set to true, the certificate
of the communication part
ner is validated.
sslCreateSelf
SignedCertifi
cate
<Boolean value>
false If set to true, a self-signed
certificate is created if the
keystore cannot be found.
20 P U B L I C
SAP HANA One Security Guide
SAP HANA Network and Communication Security
Additionally, the parameter sslCipherSuites can be used to specify the encryption algorithms available for
TLS/SSL connections. Its value depends on the cryptographic service provider used. The default values are
HIGH:MEDIUM:!aNULL (CommonCryptoLib) and ALL:!ADH:!LOW:!EXP:!NULL:@STRENGTH (OpenSSL).
For more information, see the documentation of the cryptographic library.
Parameters for Configuring Trust and Key Stores in the File System
The following parameters are used to configure trust and key stores located in the file system. In general, it's
not necessary to configure a cryptographic provider nor any of the parameters explicitly. The default
configuration can be used.
Remember that the trust store configured on the file system is also valid for single sign-on mechanisms that
rely on trust stores (such as SAP logon and assertion tickets or SAML).
Recommendation
Create certificate collections in the database instead of using trust and key stores in the file system. That
way you can create different certificate collections for different purposes.
Note
If certificate collections with a purpose (user authentication or secure client-server communication) exist in
the database, the parameters below are ignored.
Table 9:
Parameter
Value Default Description
sslCryptoProvider
{commoncrypto | sapcrypto
| openssl}
1. commoncrypto
2. openssl
Cryptographic provider used
for TLS/SSL connection
Note
If you specify a value for
this parameter, you must
also explicitly specify
paths in both the
sslKeyStore and
sslTrustStore pa
rameters to avoid config
uration issues.
SAP HANA One Security Guide
SAP HANA Network and Communication Security
P U B L I C 21
Parameter Value Default Description
sslKeyStore file
$SECUDIR/
sapsrv.pse (Com
monCryptoLib)
$HOME/.ssl/
key.pem (OpenSSL)
Path to the keystore file that
contains the server’s private
key
You must specify an abso
lute path to the keystore file
if using OpenSSL.
Note
If you specify a value for
this parameter, you must
also explicitly specify a
cryptographic provider in
the
sslCryptoProvider
parameter to avoid con
figuration issues.
sslTrustStore file
$SECUDIR/
sapsrv.pse (Com
monCryptoLib)
$HOME/.ssl/
trust.pem
(OpenSSL)
Path to trust store file that
contains the server’s public
certificate
You must specify an abso
lute path to the keystore file
if using OpenSSL.
Note
If you specify a value for
this parameter, you must
also explicitly specify a
cryptographic provider in
the
sslCryptoProvider
parameter.
3.7.1.3 TLS/SSL Configuration on the Client
You can use the Transport Layer Security (TLS)/Secure Sockets Layer (SSL) protocol to secure
communication between the SAP HANA database and clients that access the SQL interface of the database.
TLS/SSL must be configured on both the server and the client.
The client-side configuration required to secure client-to-server communication depends on whether the client
communicates with the server via an ODBC-based or a JDBC-based connection.
For ODBC-based connections, the configuration properties and their names are the same as the server
parameters. In addition, the encrypt property is available to initiate an TLS/SSL-secured connection. You set
the properties according to the client operating system.
22
P U B L I C
SAP HANA One Security Guide
SAP HANA Network and Communication Security
Note
The required configuration is possible using only the SAP HANA studio, not the SAP HANA One
Management Console.
For clients connecting via the JDBC interface, TLS/SSL is configured at the Java virtual machine (JVM) level
using system properties. There are several ways of configuring these properties. For more information, see the
Java Platform documentation.
For connections from the SAP HANA studio, which uses the JDBC interface, you configure the TLS/SSL
properties directly in the system's properties in the SAP HANA studio (for example, while adding it in the
studio). For more information, see Configure TLS/SSL for SAP HANA Studio Connections.
Note
The connection parameters for ODBC-based connections can also be used to configure TLS/SSL for
connections from ABAP applications to SAP HANA using the SAP Database Shared Library (DBSL). To pass
the connection parameters to the DBSL, use the following profile parameter:
dbs/hdb/connect_property = param1, param2, ...., paramN
The connection parameters are used for both the primary ABAP connection and secondary connections.
Related Information
Configure SSL for SAP HANA Studio Connections [page 27]
3.7.1.4 Client-Side TLS/SSL Configuration Properties
(ODBC)
For ODBC-based connections, the configuration properties and their names are the same as the server
parameters with the addition of the encrypt property, which initiates a TLS/SSL-secured connection.
The following table lists the configuration parameters that are used to configure SSL for ODBC client access:
Table 10:
Parameters
Value Default Description
encrypt
<bool value> False Enables or disables TLS/SSL encryp
tion
SAP HANA One Security Guide
SAP HANA Network and Communication Security
P U B L I C 23
Parameters Value Default Description
sslCryptoProvider
{commoncrypto| sap
crypto | openssl}
1. commoncrypto or
sapcrypto (if instal
led)
2. openssl
Cryptographic library provider used for
SSL communication
Note
If you specify a value for this param
eter, you must also explicitly specify
paths in both the sslKeyStore
and sslTrustStore parameters
to avoid configuration issues.
sslKeyStore
<file>
$SECUDIR/
sapsrv.pse (Com
monCryptoLib/SAP
Cryptographic Library) or
$HOME/.ssl/
key.pem (OpenSSL)
Path to the keystore file that contains
the server’s private key
Note
If you specify a value for this param
eter, you must also explicitly specify
a cryptographic provider in the
sslCryptoProvider parameter
to avoid configuration issues.
sslTrustStore
<file> $HOME/.ssl/trust.pem Path to trust store file that contains the
server’s public certificate(s) (OpenSSL
only)
Typically, the trust store contains the
root certificate or the certificate of the
certification authority that signed the
server’s certificate(s).
Note
If you specify a value for this param
eter, you must also explicitly specify
a cryptographic provider in the
sslCryptoProvider parameter
to avoid configuration issues.
Note
If you are using the cryptographic li
brary mscrypto, leave this parame
ter empty.
sslValidateCertif
icate
<bool value> true If set to true, the server’s certificate is
validated
24 P U BL I C
SAP HANA One Security Guide
SAP HANA Network and Communication Security
Parameters Value Default Description
sslHostNameInCert
ificate
<string value> <empty> Host name used to verify server’s iden
tity
The host name specified here is used to
verify the identity of the server instead
of the host name with which the con
nection was established.
For example, in a single-host system, if
a connection is established from a cli
ent on the same host as the server, a
mismatch would arise between the
host named in the certificate (actual
host name) and the host used to estab
lish the connection (localhost).
Note
If you specify * as the host name,
this parameter has no effect. Other
wildcards are not permitted.
3.7.1.5 Client-Side TLS/SSL Configuration Properties
(JDBC)
For clients connecting via the JDBC interface, TLS/SSL is configured using connection properties.
The following table lists the connection properties that can be used to configure TLS/SSL for JDBC client
access.
Table 11:
Property
Value Default Description
encrypt
<bool value> false Enables or disables TLS/SSL encryp
tion
validateCertifica
te
<bool value> true If set to true, the server’s certificate is
validated.
SAP HANA One Security Guide
SAP HANA Network and Communication Security
P U B L I C 25
Property Value Default Description
hostNameInCertifi
cate
<string value> <empty> Host name used to verify server’s iden
tity
The host name specified here is used to
verify the identity of the server instead
of the host name with which the con
nection was established.
For example, in a single-host system, if
a connection is established from a cli
ent on the same host as the server, a
mismatch would arise between the
host named in the certificate (actual
host name) and the host used to estab
lish the connection (localhost).
Note
If you specify * as the host name,
this parameter has no effect. Other
wildcards are not permitted.
keyStore
<file | store name> <VM default> Location of the Java keystore
keyStoreType
<JKS | PKCS12> <VM default> Java keystore file format
keyStorePassword
<password> <VM default> Password to access the private key
from the keystore file
Note
This property is not used for SAP
HANA studio connections.
trustStore
<file | store name> <VM default> Path to trust store file that contains the
server’s public certificate(s)
Typically, the trust store contains the
root certificate or the certificate of the
certification authority that signed the
server’s certificate(s).
trustStoreType
<JKS> <VM default> File format of trust store file
trustStorePasswor
d
<password> <VM default> Password used to access the trust
store file
26 P U B L I C
SAP HANA One Security Guide
SAP HANA Network and Communication Security
3.7.1.6 Configure SSL for SAP HANA Studio Connections
It is recommended to secure communication between the SAP HANA studio and the SAP HANA database
using the Transport Security Layer (TLS)/Secure Sockets Layer (SSL) protocol.
Prerequisites
You have configured the SAP HANA database for secure external communication. For more information,
see SSL Configuration on the SAP HANA Server.
You have added the SAP HANA system in the SAP HANA studio.
Context
The SAP HANA studio communicates with the SAP HANA database via the JDBC client interface. The client-
side configuration of the SAP HANA studio uses Java TLS/SSL properties.
Procedure
1. Using the keytool command line tool, import the trust store file that contains the server root certificate
into either the Java keystore or your personal user keystore.
By default, the SAP HANA studio client validates the server certificate(s) against the root certificate
stored in the Java keystore of the running VM (virtual machine). This keystore is part of the Java
installation and is located in the Java home directory under ${JAVA_HOME}/lib/security/cacerts
(Linux) or %JAVA_HOME%/lib/security/cacerts (Windows).
However, it is not recommended that you store the root certificate in this keystore, but in your personal
user keystore instead. The user key store is located in the home directory of the current operating system
user. The file name is .keystore.
2. Enable and configure TLS/SSL secure communication between the SAP HANA studio and the server:
In the SAP HANA studio, open the system's properties and choose Connect Using SSL.
This corresponds to setting the Java SSL property encrypt to true.
3. Configure how the identity of the server is to be validated during connection:
a. In the system's properties dialog, choose the Additional Properties tab.
b. If you want the server certificate(s) to be validated using the default trust store, choose Validate SSL
Certificate.
This corresponds to setting the Java SSL property validateCertificate to true.
When an TLS/SSL connection is established, the host name in the certificate being connected to and
the host name in the server certificate must match. This may not always be the case. For example, in a
single-host system, if a connection is established from the SAP HANA studio on the same host as the
SAP HANA One Security Guide
SAP HANA Network and Communication Security
P U B L I C 27
SAP HANA server, a mismatch would arise between the host named in the certificate (fully qualified
host name) and the host used to establish the connection (localhost)*.
You can override the host name specified in the server certificate by entering a host name with a
defined certificate. This corresponds to setting the Java SSL property hostNameInCertificate.
c. If you want the server certificate to be validated using the user's key store and not the default Java
keystore, choose Use user key store as trust store.
This corresponds to changing the value of the Java SSL property trustStore.
Note
If you do not have a working public key infrastructure (PKI), you can also suppress server certificate
validation entirely by selecting neither of these options (Validate SSL Certificate or Use user key store as
trust store). However, this is not recommended.
Results
In the Systems view, a lock icon appears next to the system name ( ), indicating that SSL communication is
active.
Related Information
SSL Configuration on the SAP HANA Server [page 19]
3.7.2 Secure Communication Between SAP HANA and HTTP
Clients
You can use the Transport Layer Security (TLS)/Secure Sockets Layer (SSL) protocol to secure
communication between SAP HANA and HTTP clients.
The SAP HANA XS server allows Web-based applications to access SAP HANA via HTTP. The internal Web
Dispatcher of the SAP HANA system manages these incoming HTTP requests.
Therefore, to secure communication between the SAP HANA system and HTTP clients, you must configure
the internal SAP Web Dispatcher to use TLS/SSL for inbound application requests. You can do this using the
SAP HANA Web Dispatcher Administration tool.
For more information, see Configure HTTPS (SSL) for Client Application Access in the SAP HANA One
Administration Guide.
28
P U B L I C
SAP HANA One Security Guide
SAP HANA Network and Communication Security
Related Information
SAP HANA One Administration Guide
3.7.2.1 HTTP Access Log
To monitor all HTTP(s) requests processed in an SAP HANA system, you can set up the internal Web
Dispatcher to write a standardized HTTP log for each request.
To configure the Web Dispatcher to log all HTTP(s) requests, you add the property icm/http/logging_0 to
the [profile] section of the webdispatcher.ini configuration file, specifying the following value:
PREFIX=/, LOGFILE=$(DIR_INSTANCE)/trace/access_log-%y-%m-%d, MAXSIZEKB=10000,
SWITCHTF=day, LOGFORMAT=SAP
This will generate access log files in the following directory: /usr/sap/<sid>/HDB<instance>/<host>/
trace/access_log-<timestamp>.
Example
Sample log file entry: [26/Nov/2014:13:42:04 +0200] 10.18.209.126 BOB - "GET /sap/xse/
test/InsertComment.xsjs HTTP/1.1" 200 5 245
The last three numbers are the HTTP response code, the response time in milliseconds, and the size in bytes.
For more information about logging and alternative log formats, see the Internet Communication Manager
(ICM) documentation on SAP Help Portal.
You can configure the webdispatcher.ini configuration file and view log files in the SAP HANA studio.
Related Information
icm/HTTP/logging_<xx>
Logging in the ICM and SAP Web Dispatcher
SAP HANA One Administration Guide
SAP HANA One Security Guide
SAP HANA Network and Communication Security
P U B L I C 29
4 SAP HANA User Management
SAP HANA database users may be technical users or correspond to real end users. Several tools are available
for user management.
Every user who wants to work directly with the SAP HANA database must have a database user with the
necessary privileges. Depending on the scenario, the user accessing SAP HANA may either be a technical
system user or an individual end user.
After successful logon, the user's authorization to perform the requested operations on the requested objects
is verified. This is determined by the privileges that the user has been granted. Privileges can be granted to
database users either directly, or indirectly through roles. Several tools are available for provisioning and
managing users.
For more information about the authorization model of the SAP HANA database, see SAP HANA Authorization.
Related Information
SAP HANA Authentication and Single Sign-On [page 43]
SAP HANA Authorization [page 59]
4.1 User Types
It is often necessary to specify different security policies for different types of database user. In the SAP HANA
database, we differentiate between database users that correspond to real people and technical database
users.
Technically, database users that correspond to real people and technical database users are the same. The
only difference between them is conceptual.
Database Users that Correspond to Real People
For every person who needs to work with SAP HANA, the user administrator creates a database user.
Database users that correspond to real people are dropped when the person leaves the organization. This
means that any database objects that they own are also automatically dropped, and any privileges that they
granted are automatically revoked.
Database users are created with either the CREATE USER or CREATE RESTRICTED USER statement.
30
P U B L I C
SAP HANA One Security Guide
SAP HANA User Management
Standard users are created with the CREATE USER statement. By default they can create objects in their own
schema and read data in system views. Read access to system views is granted by the PUBLIC role, which is
granted to every standard user.
Restricted users, created with the CREATE RESTRICTED USER statement, initially have no privileges.
Restricted users are intended for provisioning users who access SAP HANA through client applications and
who are not intended to have full SQL access via an SQL console. If the privileges required to use the
application are encapsulated within an application-specific role, then it is necessary to grant the user only this
role. In this way, it can be ensured that users have only those privileges that are essential to their work.
Compared to standard database users, restricted users are initially limited in the following ways:
They cannot create objects in the database as they are not authorized to create objects in their own
database schema.
They cannot view any data in the database as they are not granted (and cannot be granted) the standard
PUBLIC role.
They are only able to connect to the database using HTTP.
For restricted users to connect via ODBC or JDBC, access for client connections must be enabled by
executing the SQL statement ALTER USER <user_name> ENABLE CLIENT CONNECT or enabling the
corresponding option in the Restricted User editor of the SAP HANA studio.
For full access to ODBC or JDBC functionality, users also require the standard role
RESTRICTED_USER_ODBC_ACCESS or RESTRICTED_USER_JDBC_ACCESS.
Note
Disabling ODBC/JDBC access for a user, either a restricted user or a standard user, does not affect the
user's authorizations or prevent the user from executing SQL commands via channels other than
JDBC/ODBC. If the user has been granted SQL privileges (for example, system privileges and object
privileges), he or she is still authorized to perform the corresponding database operations using, for
example, a HTTP client.
Creating a database user as a restricted user is an irreversible action.
Technical Database Users
Technical database users do not correspond to real people. They are therefore not dropped if a person leaves
the organization. This means that they should be used for administrative tasks such as creating objects and
granting privileges for a particular application.
Some technical users are available as standard, for example, the users SYS and _SYS_REPO.
Other technical database users are created for application-specific purposes. For example, an application
server may log on to the SAP HANA database using a dedicated technical database user.
Technical users are standard users created with the CREATE USER statement.
Related Information
Standard Database Roles [page 82]
SAP HANA One Security Guide
SAP HANA User Management
P U B L I C 31
4.2 Standard Users
A number of standard users are required for installing, upgrading, and operating SAP HANA.
The following table lists the standard users that are available.
Note
If you have installed the new runtime environment for application development, SAP HANA Extended
Application Services (XS) Advanced Model, several additional standard users are available.
Table 12:
User
Description Password Specification
SYSTEM
The SYSTEM database user is created during
the installation of the SAP HANA system. It is
the most powerful database user with irrevoca
ble system privileges, such as the ability to cre
ate other database users, access system ta
bles, and so on.
In addition, to ensure that the administration
tool SAP HANA cockpit can be used immedi
ately after database creation, SYSTEM is auto
matically granted several roles the first time the
cockpit is opened with this user. For more infor
mation, see Repository Roles Granted to Stand
ard Database Users.
The SYSTEM user does not automatically have
access to objects created in the SAP HANA re
pository.
Caution
Do not use the SYSTEM user for day-to-day
activities. Instead, use this user to create
dedicated database users for administrative
tasks and to assign privileges to these users.
It is recommended that you then deactivate
the SYSTEM user.
The initial password of the SYSTEM user is
specified by your hardware partner or certified
administrator during installation. After hand
over, it is important that you change this pass
word. A user administrator (that is, a user with
the system privilege USER ADMIN) can do this
in the SAP HANA studio. It is also possible as
part of a system rename with SAP HANA lifecy
cle manager.
You specify the initial password in the SAP
HANA One Management Console during the ini
tial configuration of SAP HANA One.
32 P U B L I C
SAP HANA One Security Guide
SAP HANA User Management
User Description Password Specification
<sid>adm where
<sid> is the ID of the
SAP HANA system
Note
In SAP HANA One,
this is the user
hdbadm.
The
<sid>adm user is an operating system
user and is also referred to as the operating
system administrator.
This operating system user has unlimited ac
cess to all local resources related to SAP sys
tems.
This user is not a database user but a user at
the operating system level.
Note
Only the root user with key pairs is granted
operating system access to SAP HANA One.
No other operating system user can log in.
We strongly recommend that you keep this
configuration.
After gaining access to the operating system
as the root user, you can use the su com
mand to change the user to hdbadm or any
other user you may need for your applica
tion.
The initial password is specified during installa
tion by your hardware partner or certified ad
ministrator. After handover, it is important that
you change this password. A system adminis
trator can do this at the operating system level.
It is also possible as part of a system rename
with SAP HANA lifecycle manager.
You specify the initial password in the SAP
HANA One Management Console during the ini
tial configuration of SAP HANA One.
Recommendation
Specify a very strong password for the
hdbadm operating system user.
SYS
SYS is a technical database user. It is the owner
of database objects such as system tables and
monitoring views.
Not applicable
This is a technical database user. It is not possi
ble to log on with this user.
SAP HANA One Security Guide
SAP HANA User Management
P U B L I C 33
User Description Password Specification
XSSQLCC_AUTO_USER
_<generated_ID>
In the runtime configuration of an SAP HANA
XS application (SAP HANA XS, classic model),
a technical user is automatically generated for
an SQL connection configuration (SQLCC) if no
user is specified.
The user is created on activation of the SQLCC
and is automatically granted the role specified
in the configuration. If the SQLCC is deacti
vated, the user cannot be used in runtime.
With the standard SAP HANA XS application
SAP HANA XS Admin Tools, available with the
deployment of delivery unit HANA_XS_BASE,
two such users are created:
The technical user used by User Self-
Service Administration
tool to execute
tasks associated with user self-service re
quests, for example, sending e-mails in re
sponse to user requests.
This user is associated with the SQLCC ar
tifact
sap.hana.xs.selfService.userself
Service.xssqlcc and is assigned the
role
sap.hana.xs.selfService.user.rol
es::USSExecutor
.
For more information about this role, see
HANA_XS_BASE in the reference section of
the SAP HANA Security Guide.
This user cannot be used to log on to SAP
HANA.
The technical user used by the SAP Web
Dispatcher HTTP Tracing
tool to connect to
the database for the purpose of executing
HTTP tracing of SAP HANA XS applica
tions.
This user is associated with the SQLCC ar
tifact
sap.hana.xs.admin.webdispatcher.
server.common.httpTracing.xssqlc
c and is assigned the role
sap.hana.xs.admin.roles::WebDisp
atcherHTTPTracingAdministrator.
This user cannot be used to log on to SAP
HANA.
Password-based logon is disabled by default for
an automatically generated SQLCC user. There
fore, a password is not required.
34 P U B L IC
SAP HANA One Security Guide
SAP HANA User Management
User Description Password Specification
Note
Since the above users don't have human
readable names, check the assigned roles to
see which user is which.
For more information about SQLCCs and the
above applications, see the SAP HANA XS Ad
ministration Tools section of the SAP HANA One
Administration Guide.
_SYS_AFL
_SYS_AFL is a technical user that owns all ob
jects for Application Function Libraries.
Not applicable
This is a technical database user. It is not possi
ble to log on with this user.
_SYS_EPM
_SYS_EPM is a technical database used by the
SAP Performance Management (SAP EPM) ap
plication
Not applicable
This is a technical database user. It is not possi
ble to log on with this user.
_SYS_REPO
_SYS_REPO is a technical database user used
by the SAP HANA repository (SAP HANA XS,
classic model). The repository consists of pack
ages that contain design time versions of vari
ous objects, such as attribute views, analytic
views, calculation views, procedures, analytic
privileges, and roles. _SYS_REPO is the owner
of all objects in the repository, as well as their
activated runtime versions.
Not applicable
This is a technical database user. It is not possi
ble to log on with this user.
_SYS_STATISTICS
_SYS_STATISTICS is a technical database user
used by the internal monitoring mechanism of
the SAP HANA database. It collects information
about status, performance, and resource usage
from all components of the database and issues
alerts if necessary.
Not applicable
This is a technical database user. It is not possi
ble to log on with this user.
Note
_SYS_STATISTICS still logs on internally if
you have not migrated to the new implemen
tation of the statistics server available as of
SPS 07.
_SYS_TASK
_SYS_TASK is a technical database user in SAP
HANA Enterprise Information Management.
This user owns all task framework objects.
For more information, see SAP HANA Enter
prise Information Management on SAP Help
Portal.
Not applicable
This is a technical database user. It is not possi
ble to log on with this user.
_SYS_XB
_SYS_XB is a technical user for internal use
only.
Not applicable
This is a technical database user. It is not possi
ble to log on with this user.
SAP HANA One Security Guide
SAP HANA User Management
P U B L I C 35
Related Information
Deactivate the SYSTEM User [page 38]
Repository Roles Granted to Standard Database Users [page 85]
HANA_XS_BASE [page 134]
SAP HANA One Administration Guide
SAP HANA Enterprise Information Management
4.3 User Administration Tools
Depending on your organization and its user provisioning strategy, people with different job functions may be
involved in the process of user administration. Different tools are used for different tasks.
The recommended process for provisioning users in SAP HANA is as follows:
1. Define and create roles.
2. Create users.
3. Grant roles to users.
Further administration tasks include:
Deleting users when they leave the organization
Reactivating users after too many failed logon attempts
Deactivating users if a security violation has been detected
Resetting user passwords
The following table provides an overview of who does which of these tasks and the SAP HANA tools available:
Table 13:
Job Function
Task Environment Tool
Role designer or creator Create roles and role hierar
chies that reflect the access
requirements, job function,
and responsibilities of sys
tem users
Design time
Note
It is also possible to cre
ate roles in runtime on
the basis of SQL state
ments. However, it is rec
ommended that you cre
ate roles in the repository
as they offer more flexibil
ity (for example, they can
be transported between
systems). For more infor
mation, see
Catalog Roles
and Repository Roles
Compared
.
Developer Workbench of
the SAP HANA studio
Editor tool of the SAP
HANA Web-based De
velopment Workbench
36 P U B L I C
SAP HANA One Security Guide
SAP HANA User Management
Job Function Task Environment Tool
Application developer Create roles for new applica
tions developed on SAP
HANA Extended Services
(SAP HANA XS)
Design time
User or system administra
tor
Create SAP HANA database
users
Runtime
User editor of the SAP
HANA studio
Security tool of the SAP
HANA Web-based De
velopment Workbench
SAP HANA HDBSQL
HDBSQL is useful when
using scripts for auto
mated processing.
For more information
about HDBSQL, see the
SAP HANA One Admin
istration Guide.
Grant roles to database
users
Delete, deactivate, and reac
tivate database users
Reset user passwords
User or system administra
tor
Grant roles to database
users
Runtime Assign Roles app of the SAP
HANA cockpit
For more detailed information about roles in SAP HANA, see Roles.
SAP HANA lifecycle Management Tool hdblcm(gui)
You can use the SAP HANA lifecycle management tools to perform post-installation steps including changing
the passwords of database user SYSTEM and operating system administrator <sid>adm as part of system
rename. For more information, see Changing System Identifiers in the SAP HANA One Administration Guide.
Related Information
Roles [page 75]
Catalog Roles and Repository Roles Compared [page 77]
SAP HANA One Administration Guide
SAP HANA One Security Guide
SAP HANA User Management
P U B L I C 37
4.4 Deactivate the SYSTEM User
As the most powerful database user, SYSTEM is not intended for use in production systems. Use it to create
lesser privileged users for particular purposes and then deactivate it.
Prerequisites
You have the system privilege USER ADMIN.
Context
SYSTEM is the database superuser. It has irrevocable system privileges, such as the ability to create other
database users, access system tables, and so on. In addition, to ensure that the administration tool SAP HANA
cockpit can be used immediately after database creation, SYSTEM is automatically granted several roles the
first time the cockpit is opened with this user. For more information, see Roles Granted to Database User
SYSTEM. Note however that SYSTEM does not automatically have access to objects created in the SAP HANA
repository.
It is highly recommended that you do not use SYSTEM for day-to-day activities in production systems.
Instead, use it to create database users with the minimum privilege set required for their duties (for example,
user administration, system administration). Then deactivate SYSTEM.
Procedure
Execute the following statement, for example, in the SQL console of the SAP HANA studio:
ALTER USER SYSTEM DEACTIVATE USER NOW
Results
The SYSTEM user is deactivated and can no longer connect to the SAP HANA database.
You can verify that this is the case in the USERS system view. For user SYSTEM, check the values in the
columns USER_DEACTIVATED, DEACTIVATION_TIME, and LAST_SUCCESSFUL_CONNECT.
Note
You can still use the SYSTEM user as an emergency user even if it has been deactivated. Any user with the
system privilege USER ADMIN can reactivate SYSTEM with the statement ALTER USER SYSTEM
38
P U B L I C
SAP HANA One Security Guide
SAP HANA User Management
ACTIVATE USER NOW. To ensure that an administrator does not do this surreptitiously, it is recommended
that you create an audit policy monitoring ALTER USER statements.
SAP HANA One Security Guide
SAP HANA User Management
P U B L I C 39
5 Authentication in SAP HANA One
SAP HANA One is a combination of an SAP HANA One instance and a Web-based management console. The
SAP HANA One Portal management console is used for administrating other SAP HANA instances and itself
has SAP HANA running on it. One person (Portal administrator) can manage multiple SAP HANA instances.
5.1 Authentication in SAP HANA One Portal
5.2 Authenticating Access to SAP HANA One
Several types of authentication are involved in accessing SAP HANA One.
User Authentication
Only the user who is the rightful owner of an SAP HANA One instance and has sufficient authorization can
access and manage the instance.
The authorization to access an SAP HANA One instance is based on user authentication with the access key
and secret access key from AWS (or similar tokens from the cloud). These keys are authenticated to ensure
the following:
They are valid
They belong to the account of the user who is the rightful owner of the instance
The SAP HANA One Portal Management Console is the tool used to manage the instance.
It is expected that an SAP HANA One Portal instance is managed by one person at a time (Portal
administrator). However, an SAP HANA One Portal instance that is currently being managed by another
instance can be forcefully managed.
The management console of SAP HANA One Portal only has one password, which can only be set by the user
with valid access keys. This password is stored securely as a hash in the SAP HANA One Portal instance. Only
the root user can read the password hash. This is done to prevent exposure of the real password in SAP HANA
One flows. There is no code to send the password outside the flow that reads it. The only operation allowed is
to compare the hash with another after it is set.
Instance Authentication
The user authentication flow described above takes part in the application layer. In AWS, a self-discovery API
describes the instance ID at runtime. As user-entered keys are required to access the instance, the application
40
P U B L I C
SAP HANA One Security Guide
Authentication in SAP HANA One
layer invokes management calls against this instance with these keys. If the call succeeds, then the user has
the authorization to manage the instance and can therefore manage SAP HANA One too.
Session Authentication
Browser – SAP HANA One Portal Scenario
After successful user authentication in the management console of SAP HANA One Portal, session
cookies are used to maintain a session with predefined expiry. Session cookies are encrypted. The session
is a sliding window for session lease. Thus, as the client makes valid calls with session cookies, the session
gets extended with new session cookies being set from the server. If the session cookies expire and the
session is stale, the client cannot make any more requests. The client returns to the logon page for re-
authentication.
SAP HANA One Portal – SAP HANA One Scenario
With the SAP HANA One Portal architecture, most request related to the SAP HANA instance are
forwarded from the SAP HANA One Portal instance to the relevant SAP HANA instance for execution. If
the SAP HANA One Portal and SAP HANA instances are installed on the same AWS instance, requests
related to the SAP HANA instance are executed on the same instance. However, the best feature of both
conventional and public-key cryptography technique (hybrid cryptosystem) is used for communication
between SAP HANA One Portal and the SAP HANA instance.
SAP HANA One Portal initiates a hand-shaking call with the QServer component of the SAP HANA
instance by sending a session-specific symmetric AES key and other required information. SAP HANA One
Portal sends the AES secret key to the QServer encrypted using the QServer public key so that it can’t be
intercepted in transit. The QServer validates the information and issues an encrypted session token. The
AES secret key is the mutual agreement between SAP HANA One Portal and the Qserver and is used for
request-response payload encryption/decryption needs.
5.3 Password Management of SAP HANA One Standard
Users
SAP HANA One Portal includes a Web-based console that allows you to perform SAP HANA One
administration activities, including password management of the SAP HANA One standard users.
You use the management console of the SAP HANA One instance to set the initial passwords for the SYSTEM
database user and the hdbadm operating system user. You can also change these passwords if necessary.
Note
Password management of database users is done in the SAP HANA studio or on the command line.
You also need to set a secure password for the management console of SAP HANA One Portal itself. You do
this when you launch your SAP HANA One Portal instance for the first time.
Caution
If you forget this password, you cannot use the management console of SAP HANA One Portal.
SAP HANA One Security Guide
Authentication in SAP HANA One
P U B L I C 41
Authentication of Password Change Requests
In SAP HANA One Portal, user requests to set or reset the passwords of the users hdbadm and SYSTEM are
authenticated using the following AWS access credentials:
Access keys
Access keys are used in the management console of SAP HANA One Portal. They ensure that REST or
Query protocol requests to any AWS service API are secure. AWS creates access keys when your account
is created.
Note
Without your AWS access keys, you cannot log in to the management console of SAP HANA One Portal
to configure your SAP HANA One Portal and SAP HANA One instances for the first time.
Key pairs
Key pairs are used to connect in SSH mode.
Related Information
Amazon AWS Access Credentials
5.3.1 Change Passwords in the SAP HANA One Management
Console
You use the SAP HANA One Portal Management Console to set and change the passwords of the SYSTEM
database user, the hdbadm operating system user, and the password for the SAP HANA One Portal
Management Console.
Procedure
1. Log on to the management console of SAP HANA One Portal.
2. Click the public IP address of the SAP HANA instance card that you want.
The Management Console of the SAP HANA One instance opens in a new tab
3. In the management console of the SAP HANA One instance, choose the Administration tab.
4. Under Reset passwords, enter both the access key ID and the secret access key ID that you used to
configure SAP HANA One.
5. After your access keys are authenticated, select the user for which you want to change the password.
6. Enter and confirm the new password.
42
P U B L I C
SAP HANA One Security Guide
Authentication in SAP HANA One
Note
The management console of SAP HANA One Portal supports only alphanumeric characters to set the
SYSTEM database user password. However, after your have configured the instance and the SAP
HANA server is up and running, you can use the SAP HANA studio to change the SYSTEM user's
password with all character types supported by SAP HANA. For more information about supported
character types, see the password_layout parameter of the password policy.
Related Information
Password Policy [page 46]
5.3.2 Reset Lost Password for the SAP HANA One Portal
Management Console
If you forget the password for the management console of SAP HANA One Portal, you cannot use it. However,
you can reset the password using your AWS access keys, that is your access key and secure access key
combination (key pair).
Procedure
1. Enter the Elastic IP or DNS name of your SAP HANA One Portal instance and choose the link to reset your
password.
2. Enter both your access key and your secret access key.
3. After the access keys are authenticated, enter a new password and choose Set new password.
5.4 SAP HANA Authentication and Single Sign-On
The identity of database users accessing SAP HANA is verified through a process called authentication. SAP
HANA supports several authentication mechanisms, several of which can be used for the integration of SAP
HANA into single sign-on environments (SSO). The mechanisms used to authenticate individual users is
specified as part of the user definition.
The following sections provide an overview of the authentication mechanisms supported by SAP HANA.
Note
For JDBC and ODBC client connection, user passwords are always transmitted in encrypted hashed form
during the user authentication process, never in plain text. For HTTP connections, HTTPS must be
SAP HANA One Security Guide
Authentication in SAP HANA One
P U B L I C 43
configured. In SSO environments, we recommend using encrypted communication channels for all client
connections.
Basic Authentication
Users accessing the SAP HANA database authenticate themselves by entering their database user name and
password.
Kerberos
A Kerberos authentication provider can be used to authenticate users accessing SAP HANA in the following
ways:
Directly from ODBC and JDBC database clients within a network (for example, the SAP HANA studio)
Indirectly from front-end applications such as SAP BusinessObjects applications using Kerberos
delegation
Via HTTP access by means of SAP HANA Extended Services (SAP HANA XS)
In this case, Kerberos authentication is enabled with Simple and Protected GSSAPI Negotiation
Mechanism (SPNEGO).
Note
A user who connects to the database using an external authentication provider must also have a database
user known to the database. SAP HANA maps the external identity to the identity of an internal database
user.
Security Assertion Markup Language (SAML)
A SAML bearer assertion can be used to authenticate users accessing SAP HANA directly from ODBC/JDBC
database clients. SAP HANA can act as service provider to authenticate users accessing via HTTP by means of
SAP HANA XS.
Note
A user who connects to the database using an external authentication provider must also have a database
user known to the database. SAP HANA maps the external identity to the identity of an internal database
user.
44
P U B L I C
SAP HANA One Security Guide
Authentication in SAP HANA One
X.509 Client Certificates
For HTTP access to SAP HANA by means of SAP HANA XS, users can be authenticated by client certificates
signed by a trusted Certification Authority (CA), which can be stored in the SAP HANA XS trust store.
Note
To implement X.509 client certificates, the user specified in the certificate must already exist in SAP HANA;
there is no support for user mapping.
Single-Sign On
Single sign-on provides for an environment in which users can access SAP HANA from multiple clients based
on an initial authentication on the client. The following mechanisms can be used for this purpose:
Kerberos
SAML
X.509 client certificates
Only for HTTP access to SAP HANA by means of SAP HANA XS
Note
X.509 client certificates are supported only for HTTP access to SAP HANA by means of SAP HANA XS.
SAP HANA XS Application Configuration
You use the Web-based administration tools for SAP HANA XS to configure security-related aspects of SAP
HANA XS applications, including authentication (for example, enforced authentication mechanism, trust store
configuration and management, and SAML configuration).
Related Information
Password Blacklist [page 53]
Password Policy [page 46]
Single Sign-On Using Kerberos [page 53]
Single Sign-On Using SAML 2.0 [page 54]
Single Sign-On Using SAP Logon and Assertion Tickets [page 57]
SAP HANA SQL and System Views Reference
SAP HANA One Administration Guide
SAP HANA One Security Guide
Authentication in SAP HANA One
P U B L I C 45
5.4.1 SAP HANA Logon Checks
Before a user can connect to an SAP HANA One instance running on Amazon Web Services, the system
performs several checks as part of the logon process.
1. The system authenticates the user using the configured mechanism.
For example, if user name/password authentication is being enforced, the provided user name and
password are verified.
2. The system verifies that the user's account is within its validity period.
In the system view USERS, the columns VALID_FROM and VALID_UNTIL must contain effective values for
the user in question.
The validity period is an optional parameter that a user administrator can set during user provisioning.
3. The system verifies that the user's account is active.
In the system view USERS, the column IS_DEACTIVATED must contain the value FALSE for the user in
question.
User accounts may be deactivated explicitly by a user administrator or by the system, for example, due to
too many invalid logon attempts.
If all of the above checks are successful, the user is logged on to SAP HANA.
5.4.2 Password Policy
Passwords for the user name/password authentication of database users are subject to certain rules, or
password policy. You can change the default password policy in line with your organization’s security
requirements. You cannot deactivate the password policy.
You configure your password policy in the Security editor of the SAP HANA studio.
The actual parameters are contained in the password_policy section of the indexserver.ini system
properties file. Although it is recommended to configure the password policy using the Security editor of the
SAP HANA studio, you can also do so by editing the indexserver.ini directly.
Caution
Direct changes to the indexserver.ini file cannot be audited.
The system view M_PASSWORD_POLICY contains the parameters and their current values.
Related Information
Auditing Activity in SAP HANA Systems [page 104]
SAP HANA One Administration Guide
46
P U B L I C
SAP HANA One Security Guide
Authentication in SAP HANA One
5.4.2.1 Password Policy Configuration Options
Passwords for the user name/password authentication of database users are subject to certain rules, or
password policy.
You can change the default password policy in the Security editor of the SAP HANA studio (recommended) or
directly in the password_policy section of the indexserver.ini system properties file.
minimal_password_length [page 47]
password_layout [page 47]
force_first_password_change [page 48]
last_used_passwords [page 49]
maximum_invalid_connect_attempts [page 49]
password_lock_time [page 50]
minimum_password_lifetime [page 51]
maximum_password_lifetime [page 51]
maximum_unused_initial_password_lifetime [page 51]
maximum_unused_productive_ password_lifetime [page 52]
password_expire_warning_time [page 52]
password_lock_for_system_user [page 52]
detailed_error_on_connect [page 53]
minimal_password_length
The minimum number of characters that the password must contain
Table 14:
Default Value
8
Additional Information You must enter a value between 6 and 64.
SAP HANA Studio Minimum password length
password_layout
The character types that the password must contain; at least one character of each selected character type is
required
Table 15:
Default Value
Aa1
SAP HANA One Security Guide
Authentication in SAP HANA One
P U B L I C 47
Additional Information
The following character types are possible:
Lowercase letter (a-z)
Uppercase letter (A-Z)
Numerical digits (0-9)
Special characters (underscore (_), hyphen (-), and so on)
Any character that is not an uppercase letter, a lowercase letter, or a numerical
digit is considered a special character.
The default configuration requires passwords to contain at least one uppercase letter,
at least one number, and at least one lowercase letter, with special characters being
optional.
Note
Passwords containing special characters other than underscore must be enclosed
in double quotes ("). The SAP HANA studio does this automatically. When a pass
word is enclosed in double quotes ("), any Unicode characters may be used.
Caution
The use of passwords enclosed in double quotes (") may cause logon issues de
pending on the client used. The SAP HANA studio, for example, supports pass
words enclosed in double quotes ("), while the SAP HANA HDBSQL command line
tool does not.
Note
If configuring this option in the indexserver.ini file using the
password_layout parameter, you can use any specific letters, numbers and
special characters, and the characters can be in any order. For example, the default
value example could also be represented by
a1A, hQ5, or 9fG. If you want to en
force the use of at least one of each character type including special characters, you
specify A1a_ or 2Bg?.
SAP HANA Studio
Required Character Types
force_first_password_change
Defines whether users have to change their initial passwords immediately the first time they log on
Table 16:
Default Value
True
48 P U B L I C
SAP HANA One Security Guide
Authentication in SAP HANA One
Additional Information
If this parameter is set to true, users can still log on with the initial password but ev
ery action they try to perform will return the error message that they must change their
password.
If this parameter is set to false, users are not forced to change their initial password
immediately the first time they log on. However, if a user does not change the pass
word before the number of days specified in the parameter
maximum_unused_initial_password_lifetime, then the password still ex
pires and must be reset by a user administrator.
A user administrator (that is, a user with the system privilege USER ADMIN) can force
a user to change his or her password at any time with the following SQL statement:
ALTER USER <user_name> FORCE PASSWORD CHANGE
A user administrator can override this password policy setting for individual users (for
example, technical users) with the following SQL statement:
CREATE USER <user_name> PASSWORD <password> [NO
FORCE_FIRST_PASSWORD_CHANGE]
ALTER USER <user_name> PASSWORD <password> [NO
FORCE_FIRST_PASSWORD_CHANGE]
SAP HANA Studio
User must change password on first logon
last_used_passwords
The number of last used passwords that the user is not allowed to reuse when changing his or her current
password
Table 17:
Default Value
5
Additional Information
If you enter the value 0, the user can reuse his or her old password.
SAP HANA Studio Number of Previous Passwords Excluded
maximum_invalid_connect_attempts
The maximum number of failed logon attempts that are possible; the user is locked as soon as this number is
reached
Table 18:
Default Value
6
SAP HANA One Security Guide
Authentication in SAP HANA One
P U B L I C 49
Additional Information
You must enter a value of at least 1.
A user administrator can reset the number of invalid logon attempts with the following
SQL statement:
ALTER USER <user_name> RESET CONNECT ATTEMPTS
The first time a user logs on successfully after an invalid logon attempt, an entry is
made in the INVALID_CONNECT_ATTEMPTS system view containing the following in
formation:
The number of invalid logon attempts since the last successful logon
The time of the last successful logon
A user administrator can delete information about invalid logon attempts with the fol
lowing SQL statement: ALTER USER <user_name> DROP CONNECT
ATTEMPTS
Recommendation
Create an audit policy to log activity in the INVALID_CONNECT_ATTEMPTS system
view. For example, create an audit policy that logs data query and manipulation
statements executed on this view.
Note
Although this parameter is not valid for the SYSTEM user, the SYSTEM user will still
be locked if the parameter password_lock_for_system_user is set to
true. If password_lock_for_system_user is set to false, the SYSTEM
user will not be locked regardless of the number of failed logon attempts.
SAP HANA Studio
Number of Allowed Failed Logon Attempts
password_lock_time
The number of minutes for which a user is locked after the maximum number of failed logon attempts
Table 19:
Default Value
1440
Additional Information
If you enter the value 0, the user is unlocked immediately. This disables the functional
ity of parameter maximum_invalid_connect_attempts.
A user administrator can reset the number of invalid logon attempts and reactivate the
user account with the following SQL statement:
ALTER USER <user_name>
RESET CONNECT ATTEMPTS. It is also possible to reactivate the user in the user
editor of the SAP HANA studio.
To lock a user indefinitely, enter the value -1. In the Security editor of the SAP HANA
studio, this corresponds to selecting the
Lock indefinitely checkbox. The user remains
locked until reactivated by a user administrator as described above.
SAP HANA Studio
Lock Time/Lock For
50 P U B L I C
SAP HANA One Security Guide
Authentication in SAP HANA One
minimum_password_lifetime
The minimum number of days that must elapse before a user can change his or her password
Table 20:
Default Value
1
Additional Information
If you enter the value 0, the password has no minimum lifetime.
SAP HANA Studio Minimum Password Lifetime
maximum_password_lifetime
The number of days after which a user's password expires
Table 21:
Default Value
182
Additional Information
You must enter a value of at least 1.
A user administrator can exclude users from this password check with the following
SQL statement:
ALTER USER <user_name> DISABLE PASSWORD
LIFETIME. However, this is recommended only for technical users only, not database
users that correspond to real people.
A user administrator can re-enable the password lifetime check for a user with the fol
lowing SQL statement: ALTER USER <user_name> ENABLE PASSWORD
LIFETIME.
SAP HANA Studio
Maximum Password Lifetime
maximum_unused_initial_password_lifetime
The number of days for which the initial password or any password set by a user administrator for a user is
valid.
Table 22:
Default Value
7
Additional Information
You must enter a value of at least 1.
If a user has not logged on using the initial password within the given period of time, the
password becomes invalid and you must reset it.
SAP HANA Studio Lifetime of Initial Password
SAP HANA One Security Guide
Authentication in SAP HANA One
P U B L I C 51
maximum_unused_productive_ password_lifetime
The number of days after which a password expires if the user has not logged on
Table 23:
Default Value
365
Additional Information
You must enter a value of at least 1.
If a user has not logged on using their user-defined password within the given period of
time, the password becomes invalid and you must reset it.
SAP HANA Studio Maximum Duration of User Inactivity
password_expire_warning_time
The number of days before a password is due to expire that the user receives notification
Table 24:
Default Value
14
Additional Information Notification is transmitted via the database client (ODBC or JDBC) and it is up to the
client application to provide this information to the user.
If you enter the value 0, the user does not receive notification that his or her password
is due to expire.
The system also monitors when user passwords are due to expire and issues a medium
priority alert (check 62). This may be useful for technical database users since pass
word expiration results in the user being locked, which may affect application availabil
ity. It is recommended that you disable the password lifetime check of technical users
so that their password never expires.
SAP HANA Studio
Notification of Password Expiration
password_lock_for_system_user
Indicates whether or not the user SYSTEM is locked for the specified lock time (password_lock_time) after
the maximum number of failed logon attempts (maximum_invalid_connect_attempts)
Table 25:
Default Value
true
SAP HANA Studio Exempt SYSTEM user from locking
52 P U BL I C
SAP HANA One Security Guide
Authentication in SAP HANA One
detailed_error_on_connect
Indicates the detail level of error information returned when a logon attempt fails
Table 26:
Default Value
false
Additional Information
If set to false, only the information authentication failed is returned.
If set to true, the specific reason for failed logon is returned:
Invalid user password
User is locked
Connect try is outside validity period
User is deactivated
SAP HANA Studio
Not configurable
Related Information
SAP HANA One Security Guide (For AWS)
5.4.3 Password Blacklist
A password blacklist is a list of words that are not allowed as passwords or parts of passwords.
The password blacklist in SAP HANA is implemented with the table _SYS_PASSWORD_BLACKLIST in the
schema _SYS_SECURITY. This table is empty when you create a new instance.
You can enter words in the password blacklist as part of password policy configuration in the Security editor of
the SAP HANA studio.
Related Information
SAP HANA One Administration Guide
5.4.4 Single Sign-On Using Kerberos
For integration into Kerberos-based SSO scenarios, SAP HANA supports Kerberos version 5 based on Active
Directory (Microsoft Windows Server) or Kerberos authentication servers. For HTTP access using SAP HANA
SAP HANA One Security Guide
Authentication in SAP HANA One
P U B L I C 53
Extended Services (SAP HANA XS), Kerberos authentication is enabled with Simple and Protected GSSAPI
Negotiation Mechanism (SPNEGO).
Kerberos is a network authentication protocol that provides authentication for client-server applications
across an insecure network connection using secret-key cryptography.
ODBC and JDBC database clients support the Kerberos protocol, for example, the SAP HANA studio. Access
from front-end applications (for example, SAP BusinessObjects XI applications) can also be implemented
using Kerberos delegation. Support for constrained delegation and protocol transition is limited to scenarios in
which the middle-tier application connects to SAP HANA as the database layer via JDBC.
Kerberos is supported for HTTP access using SAP HANA XS with Simple and Protected GSSAPI Negotiation
Mechanism (SPNEGO). It is up to the HTTP client whether it uses Kerberos directly or SPNEGO.
Recommendation
To avoid replay attacks, we recommend that you set up secure communication between the individual
components of the SAP HANA database and client connections using the secure sockets layer (SSL)
protocol when implementing Kerberos authentication, in particular when using Kerberos with insecure
encryption algorithms such as RC4.
Configuration
To allow users to log on to the SAP HANA database from a client using Kerberos authentication, the following
configuration steps are necessary:
1. Install MIT Kerberos client libraries on the host(s) of the SAP HANA system.
2. Configure the SAP HANA system for Kerberos and/or SPNEGO authentication.
3. Map SAP HANA database users to their external identities stored in the Kerberos key distribution center
(KDC).
In distributed SAP HANA systems that use Kerberos delegation (SSO2DB), application disruptions resulting
from expired authentication are avoided though the use of session cookies. This mechanism is active by
default but can be disabled in the indexserver.ini configuration file with the [authentication]
session_cookie_for_kerberos property.
Related Information
SAP HANA One Administration Guide
5.4.5 Single Sign-On Using SAML 2.0
SAP HANA supports the Security Assertion Markup Language (SAML) for user authentication in single-sign on
environments. SAML is used for authentication purposes only and not for authorization.
SAML provides the mechanism by which the identity of users accessing the SAP HANA database from client
applications is authenticated by XML-based assertions issued by a trusted identity provider. The internal
54
P U B L I C
SAP HANA One Security Guide
Authentication in SAP HANA One
database user to which the external identity is mapped is used for authorization checks during the database
session.
SAML can be implemented to authenticate users accessing the SAP HANA database from the following client
applications:
Database clients that access the SQL interface of the SAP HANA database directly
This covers standard ODBC and JDBC database clients.
In this scenario, a SAML bearer assertion is used to authenticate the user directly. It is the client
application’s responsibility to retrieve the SAML bearer assertion used for logon.
Note
The SAP HANA studio does not support SAML.
Clients that connect to SAP HANA through the SAP HANA XS server via HTTP
In this scenario, SAP HANA acts as the service provider that authenticates users on the basis of their
SAML bearer assertion.
Recommendation
To avoid replay attacks, we recommend that you set up secure communication between the individual
components of the SAP HANA database and client connections using the secure sockets layer (SSL)
protocol when implementing SAML authentication.
SAML Assertion Specification
SAP HANA supports plain SAML 2.0 assertions as well as unsolicited SAML responses that include an
unencrypted SAML assertion. SAML assertions and responses must be signed using XML signatures.
The following features of XML signatures are supported:
SHA1, SHA256, and MD5 for hash algorithms
RSA-SHA1 and RSA-SHA256 as signature algorithms
The following SAML assertion features are supported:
Assertion Subject with NameID
Qualified NameID with SPProvidedID and SPNameQualifier
Validity conditions (NotBefore, NotOnOrAfter)
Audience restrictions
The following properties of a SAML assertion are evaluated to log on the requesting user to SAP HANA:
Table 27:
Property
Note
saml:Assertion/@Version
Required entry: 2.0
saml:Subject/saml:NameID
Must be specified
SAP HANA One Security Guide
Authentication in SAP HANA One
P U B L I C 55
Property Note
saml:Subject/saml:NameID/@Format
Optional entry
If present, entry can be urn:oasis:names:tc:SAML:
1.1:nameid-format:unspecified or
"urn:oasis:names:tc:SAML:1.1:nameid-
format:emailAddress"
saml:Subject/saml:NameID/@SPProvidedID
Must either match an explicit user mapping in the SAP
HANA database, or a wildcard mapping must have been set
for the user
saml:Subject/saml:SubjectConfirmation
Optional
If present, entry must be
{{"urn:oasis:names:tc:SAML:
2.0:cm:bearer"}}
saml:Conditions
@NotBefore
@NotOnOrAfter
AudienceRestriction
Condition
@NotOnOrAfter must be set.
Configuration for ODBC/JDBC Client Access
To enable logon using SAML bearer assertions, you must configure identity providers and then map them to
the required database users. Two types of user mapping are supported:
SAP HANA-based user mappings
The mapping to a database user is explicitly configured within SAP HANA for each identity provider. The
corresponding assertion subject looks like this:
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-
format:unspecified">zgc2VLavgYy4hsohfYPM21</NameID>
Mapping to a database user's e-mail address is also possible. The corresponding assertion subject looks
like this:
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
Identity provider-based user mappings
The identity provider maps its users to SAP HANA database users and provides this information using the
SPProvidedID attribute. The corresponding assertion subject looks like this:
<NameIDFormat="urn:oasis:names:tc:SAML:1.1:nameid- format:unspecified"
SPProvidedID="BILLG">zgc2VLavgYy4hsohfYPM21</NameID>
You can configure SAML identity providers and map them to database users in the SAP HANA studio.
In addition, you must configure the trust store used to validate incoming SAML assertions against certificates
signed by a trusted Certification Authority (CA). We recommend creating a certificate collection with the
purpose SAML that contains the required certificates directly in the database. It is also possible to use a trust
store located on the file system. This is the same trust store configured for communication between the SAP
HANA database and clients that access the SQL interface of the database. For more information, see Server-
Side SSL Configuration Properties for External Communication (JDBC/ODBC).
56
P U B L I C
SAP HANA One Security Guide
Authentication in SAP HANA One
Configuration for HTTP Client Access
While you can configure SAML providers for ODBC/JDBC-based SAML authentication using the SAP HANA
studio or SQL statements, you should always use the SAP HANA XS Administration Tool to configure SAML
providers that will be used for HTTP access via the XS server.
You also use the SAP HANA XS Administration Tool to configure an SAP HANA system to act as an SAML
service provider. For more information, see Maintaining SAML Providers in the SAP HANA One Administration
Guide.
Related Information
Server-Side TLS/SSL Configuration Properties for External Communication (JDBC/ODBC) [page 20]
SAP HANA One Administration Guide
5.4.6 Single Sign-On Using SAP Logon and Assertion Tickets
Users can be authenticated in SAP HANA by logon or assertion tickets issued to them when they log on to an
SAP system configured to create tickets (for example, the SAP Web Application Server or Portal).
If you want to integrate an SAP HANA system into a landscape that uses logon or assertion tickets for user
authentication, you must configure SAP HANA to accept logon/assertion tickets.
Trust Store Configuration
SAP HANA validates incoming logon/assertion tickets against certificates signed by a trusted Certification
Authority (CA) stored in a dedicated trust store. This trust store must contain all root certificate(s) used to
validate logon/assertion tickets. We recommend creating a certificate collection with the purpose SAP LOGON
with the required certificates directly in the database.
It is also possible to use a trust store located in the file system. The default location of the trust store in the file
system depends on the cryptographic library configured for SSL:
$SECUDIR/saplogon.pse (CommonCryptoLib)
Note
The saplogon.pse trust store is available automatically.
$HOME/.ssl/saplogon.pem (OpenSSL)
You can also configure the path to the trust store by setting the parameter [authentication]
saplogontickettruststore
in the indexserver.ini configuration file.
SAP HANA One Security Guide
Authentication in SAP HANA One
P U B L I C 57
Note
You must restart SAP HANA after you change this parameter.
User Configuration
The user named in an incoming logon ticket must exist as a database user. The database user also must be
configured for authentication using logon/assertion tickets. This can be done in the user editor of the SAP
HANA studio.
For more information about using logon tickets, see the SAP NetWeaver Library on SAP Help Portal.
Related Information
SAP HANA One Administration Guide
Using Logon Tickets
58
P U B L I C
SAP HANA One Security Guide
Authentication in SAP HANA One
6 SAP HANA Authorization
When a user accesses the SAP HANA database using a client interface (for example, ODBC, JDBC, or HTTP),
his or her ability to perform database operations on database objects is determined by the privileges that he or
she has been granted.
All the privileges granted directly or indirectly (through roles) to a user are combined. This means that
whenever a user tries to access an object, the system performs an authorization check on the user, the user's
roles, and directly granted privileges. It is not possible to explicitly deny privileges. This means that the system
does not need to check all the user's privileges. As soon as all requested privileges have been found, the
system skips further checks and grants access.
Several privilege types are used in SAP HANA.
6.1 Privileges
Several privilege types are used in SAP HANA.
Table 28:
Privilege Type
Applicable To Target User Description
System privilege System, database Administrators, devel
opers
System privileges control general system activi
ties. They are mainly used for administrative
purposes, such as creating schemas, creating
and changing users and roles, performing data
backups, managing licenses, and so on.
System privileges are also used to authorize ba
sic repository operations.
Object privilege
Database objects
(schemas, tables,
views, procedures and
so on)
End users, technical
users
Object privileges are used to allow access to
and modification of database objects, such as
tables and views. Depending on the object type,
different actions can be authorized (for exam
ple, SELECT, CREATE ANY, ALTER, DROP, and
so on).
Schema privileges are object privileges that are
used to allow access to and modification of
schemas and the objects that they contain.
Source privileges are object privileges that are
used to restrict access to and modification of
remote data sources, which are connected
through SAP HANA smart data access.
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 59
Privilege Type Applicable To Target User Description
Analytic privilege Analytic views End users Analytic privileges are used to allow read ac
cess to data in SAP HANA information models
(that is, analytic views, attribute views, and cal
culation views) depending on certain values or
combinations of values. Analytic privileges are
evaluated during query processing.
Package privilege
Packages in the repo
sitory of the SAP
HANA database
Application and con
tent developers
Package privileges are used to allow access to
and the ability to work in packages in the repo
sitory of the SAP HANA database.
Packages contain design time versions of vari
ous objects, such as analytic views, attribute
views, calculation views, and analytic privileges.
Application privilege
SAP HANA XS applica
tions
Application end users,
technical users (for
SQL connection con
figurations)
Developers of SAP HANA XS applications can
create application privileges to authorize user
and client access to their application. They ap
ply in addition to other privileges, for example,
object privileges on tables.
Application privileges can be granted directly to
users or roles in runtime in the SAP HANA stu
dio. However, it is recommended that you grant
application privileges to roles created in the re
pository in design time.
Note
In the SAP HANA studio, an additional privilege type can be granted. Privileges on users are SQL privileges
that users can grant on their user. ATTACH DEBUGGER is the only privilege that can be granted on a user. It
is a system privilege.
For example, User A can grant User B the privilege ATTACH DEBUGGER to allow User B debug SQLScript
code in User A's session. User A is only user who can grant this privilege. Note that User B also needs the
object privilege DEBUG on the relevant SQLScript procedure.
For more information, see Debug an External Session in the SAP HANA Developer Guide on SAP Help Portal.
6.2 System Privileges
System privileges control general system activities.
System privileges are mainly used to authorize users to perform administrative actions, including:
Creating and deleting schemas
Managing users and roles
Performing data backups
Monitoring and tracing
60
P U B L I C
SAP HANA One Security Guide
SAP HANA Authorization
Managing licenses
System privileges are also used to authorize basic repository operations, for example:
Importing and exporting content
Maintaining delivery units (DU)
For more information about the individual system privileges available, see System Privileges (Reference).
Related Information
System Privileges (Reference) [page 61]
6.2.1 System Privileges (Reference)
System privileges control general system activities.
The following tables describe the system privileges supported in the SAP HANA database. For more detailed
information about these privileges, see the documentation for the SQL access control statement GRANT in the
SAP HANA SQL and Systems Views Reference.
Table 29: General System Privileges
System Privilege
Description
ATTACH DEBUGGER Authorizes the debugging of a procedure call called by a different user
In addition, the DEBUG privilege for the corresponding procedure is needed.
AUDIT ADMIN Controls the execution of the auditing-related commands CREATE AUDIT POL
ICY, DROP AUDIT POLICY, and ALTER AUDIT POLICY, as well as changes to au
diting configuration
It also authorizes access to AUDIT_LOG system view.
AUDIT OPERATOR
Authorizes the execution of the command ALTER SYSTEM CLEAR AUDIT LOG
It also authorizes access to the AUDIT_LOG system view.
CERTFICATE ADMIN Controls the execution of the following certificate store-related commands: CRE
ATE CERTIFICATE, DROP CERTIFICATE
It also allows access to the CERTIFICATES system view.
SSL ADMIN Controls the execution of the following commands: SET <pse_store_name>
PURPOSE SSL.
It also allows access to the PSES system view.
BACKUP ADMIN Authorizes backup and recovery commands for defining and initiating backup
and recovery procedures.
It also authorizes changes to system configuration options with respect to
backup and recovery.
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 61
System Privilege Description
BACKUP OPERATOR Authorizes the backup command to initiate a backup process
CATALOG READ Authorizes unfiltered read-only access to all system views
Normally, the content of these views is filtered based on the privileges of the ac
cessing user.
CREATE REMOTE SOURCE Authorizes the creation of remote data sources using the CREATE REMOTE
SOURCE command
CREATE R SCRIPT Authorizes the creation of a procedure using the language R
CREATE SCENARIO Authorizes the creation of calculation scenarios and cubes (calculation data
base)
CREATE SCHEMA Authorizes the creation of database schemas using the CREATE SCHEMA com
mand
By default each user owns one schema. With this privilege the user can create
additional schemas.
CREATE STRUCTURED PRIVILEGE
Authorizes the creation of structured privileges (analytic privileges)
Only the owner of an analytic privilege can further grant or revoke that privilege
to other users or roles.
CREDENTIAL ADMIN Authorizes the execution of the commands CREATE CREDENTIAL, ALTER CRE
DENTIAL, and DROP CREDENTIAL
DATA ADMIN Authorizes the reading of all data in the system views.
This privilege also enables the execution of any Data Definition Language (DDL)
commands in the SAP HANA database.
Users with this privilege cannot select or change data stored in tables for which
they do not have access privileges. However, they can drop tables or modify ta
ble definitions.
EXPORT
Authorizes export activity in the database using the EXPORT command
Note that in addition to this privilege, the user requires the SELECT privilege on
the source tables to be exported.
IMPORT Authorizes import activity in the database using the IMPORT commands
Note that in addition to this privilege the user requires the INSERT privilege on
the target tables to be imported.
INIFILE ADMIN Authorizes the changing of system configuring files
LICENSE ADMIN Authorizes the execution of the SET SYSTEM LICENSE command to install a new
license
LOG ADMIN Authorizes the execution of the ALTER SYSTEM LOGGING [ON|OFF] commands
to enable or disable the log flush mechanism
MONITOR ADMIN Authorizes the execution of the ALTER SYSTEM commands for EVENTs.
OPTIMIZER ADMIN Authorizes the execution of the ALTER SYSTEM commands related to SQL PLAN
CACHE, as well as ALTER SYSTEM UPDATE STATISTICS commands, which in
fluence the behavior of the query optimizer
62 P U B L I C
SAP HANA One Security Guide
SAP HANA Authorization
System Privilege Description
RESOURCE ADMIN Authorizes commands concerning system resources, for example ALTER SYS
TEM RECLAIM DATAVOLUME and ALTER SYSTEM RESET MONITORING VIEW
This privilege also authorizes many of the commands available in the Manage
ment Console.
ROLE ADMIN
Authorizes the creation and deletion of roles using the CREATE ROLE and DROP
ROLE commands
This privilege also authorizes the granting and revocation of roles using the
GRANT and REVOKE commands.
Activated repository roles, that is roles whose creator is the technical user
_SYS_REPO, can neither be granted to other roles or users nor dropped directly.
Not even users having ROLE ADMIN privilege are able to do so. Stored proce
dures are used instead. For more information, see Granting and Revoking Privi
leges on Activated Repository Objects.
SAVEPOINT ADMIN
Authorizes the execution of a savepoint operation using the ALTER SYSTEM SA
VEPOINT command
SCENARIO ADMIN Authorizes all calculation scenario-related activities (including creation)
SERVICE ADMIN Authorizes the execution of the ALTER SYSTEM [START|CANCEL|RECONFIG
URE] commands
This privilege is for administering system services of the database.
SESSION ADMIN Authorizes the execution of the ALTER SYSTEM commands concerning sessions
to stop or disconnect a user session or to change session variables
STRUCTUREDPRIVILEGE ADMIN Authorizes the creation, reactivation, and dropping of structured privileges
TABLE ADMIN Authorizes the execution of the commands LOAD, UNLOAD, and MERGE DELTA
in relation to tables and table placement
TRACE ADMIN Authorizes the execution of the ALTER SYSTEM [CLEAR|REMOVE] TRACES
commands for operations on database trace files, as well as the changing of
trace system settings
TRUST ADMIN Authorizes commands to update the trust store
USER ADMIN Authorizes the creation and modification of users using the CREATE USER, AL
TER USER, and DROP USER commands
VERSION ADMIN Authorizes the execution of the ALTER SYSTEM RECLAIM VERSION SPACE
command of the multiversion concurrency control (MVCC) mechanism
WORKLOAD ADMIN Authorizes execution of the workload class and mapping commands: CREATE
WORKLOAD CLASS, ALTER WORKLOAD CLASS, DROP WORKLOAD CLASS,
CREATE WORKLOAD MAPPING, ALTER WORKLOAD MAPPING, and DROP
WORKLOAD MAPPING
Table 30: Repository System Privileges
System Privilege
Description
REPO.EXPORT Authorizes the export of delivery units for example
REPO.IMPORT Authorizes the import of transport archives
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 63
System Privilege Description
REPO.MAINTAIN_DELIVERY_UNITS Authorizes the maintenance of delivery units (DU, DU vendor and system vendor
must be the same
REPO.WORK_IN_FOREIGN_WORK
SPACE
Authorizes work in a foreign inactive workspace
REPO.CONFIGURE Authorize work with SAP HANA Change Recording, which is part of SAP HANA
Application Lifecycle Management
REPO.MODIFY_CHANGE
REPO.MODIFY_OWN_CONTRIBUTION
REPO.MODIFY_FOREIGN_CONTRIBU
TION
Note
Additional system privileges may exist and be required in conjunction with SAP HANA options and
capabilities such as SAP HANA Enterprise Information Management. For more information, see SAP HANA
Options and Capabilities on SAP Help Portal.
Caution
SAP HANA server software and tools can be used for several SAP HANA platform and options scenarios as
well as the respective capabilities used in these scenarios. The availability of these is based on the available
SAP HANA licenses and the SAP HANA landscape, including the type and version of the back-end systems
the SAP HANA administration and development tools are connected to. There are several types of licenses
available for SAP HANA. Depending on your SAP HANA installation license type, some of the features and
tools described in the SAP HANA platform documentation may only be available in the SAP HANA options
and capabilities, which may be released independently of an SAP HANA Platform Support Package Stack
(SPS). Although various features included in SAP HANA options and capabilities are cited in the SAP HANA
platform documentation, each SAP HANA edition governs the options and capabilities available. Based on
this, customers do not necessarily have the right to use features included in SAP HANA options and
capabilities. For customers to whom these license restrictions apply, the use of features included in SAP
HANA options and capabilities in a production system requires purchasing the corresponding software
license(s) from SAP. The documentation for the SAP HANA optional components is available in SAP Help
Portal at http://help.sap.com/hana_options. If you have additional questions about what your particular
license provides, or wish to discuss licensing features available in SAP HANA options, please contact your
SAP account team representative.
Related Information
Developer Authorization [page 86]
SAP HANA Options and Capabilities
64
P U B L I C
SAP HANA One Security Guide
SAP HANA Authorization
6.3 Object Privileges
Object privileges are SQL privileges that are used to allow access to and modification of database objects.
For each SQL statement type (for example, SELECT, UPDATE, or CALL), a corresponding object privilege
exists. If a user wants to execute a particular statement on a simple database object (for example, a table), he
or she must have the corresponding object privilege for either the actual object itself, or the schema in which
the object is located. This is because the schema is an object type that contains other objects. A user who has
object privileges for a schema automatically has the same privileges for all objects currently in the schema and
any objects created there in the future.
Object privileges are not only grantable for database catalog objects such as tables, views and procedures.
Object privileges can also be granted for non-catalog objects such as development objects in the repository of
the SAP HANA database.
Initially, the owner of an object and the owner of the schema in which the object is located are the only users
who can access the object and grant object privileges on it to other users.
An object can therefore be accessed only by the following users:
The owner of the object
The owner of the schema in which the object is located
Users to whom the owner of the object has granted privileges
Users to whom the owner of the parent schema has granted privileges
Caution
The database owner concept stipulates that when a database user is deleted, all objects created by that
user and privileges granted to others by that user are also deleted. If the owner of a schema is deleted, all
objects in the schema are also deleted even if they are owned by a different user. All privileges on these
objects are also deleted.
Authorization Check on Objects with Dependencies
The authorization check for objects defined on other objects (that is, stored procedures and views) is more
complex. In order to be able to access an object with dependencies, both of the following conditions must be
met:
The user trying to access the object must have the relevant object privilege on the object as described
above.
The user who created the object must have the required privilege on all underlying objects and be
authorized to grant this privilege to others.
If this second condition is not met, only the owner of the object can access it. He cannot grant privileges on it
to any other user. This cannot be circumvented by granting privileges on the parent schema instead. Even if a
user has privileges on the schema, he will still not be able to access the object.
Note
This applies to procedures created in DEFINER mode only. This means that the authorization check is run
against the privileges of the user who created the object, not the user accessing the object. For procedures
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 65
created in INVOKER mode, the authorization check is run against the privileges of the accessing user. In this
case, the user must have privileges not only on the object itself but on all objects that it uses.
Tip
The SAP HANA studio provides a graphical feature, the authorization dependency viewer, to help
troubleshoot authorization errors for object types that typically have complex dependency structures:
stored procedures and calculation views.
For more information about resolving authorization errors with the authorization dependency viewer, see
Resolve Errors Using the Authorization Dependency Viewer in the SAP HANA One Administration Guide.
For more information about the object privileges available in SAP HANA and for which objects they are
relevant, see Object Privileges (Reference).
Related Information
Object Privileges (Reference) [page 66]
SAP HANA One Administration Guide
6.3.1 Object Privileges (Reference)
Object privileges are used to allow access to and modification of database objects, such as tables and views.
The following table describes the object privileges supported in the SAP HANA database. For more detailed
information about these privileges, see the documentation for the SQL access control statement GRANT in the
SAP HANA SQL and Systems Views Reference.
Table 31:
Object Privilege
Applicable To Description
ALL PRIVILEGES
Table
View
Collection of all data definition language (DDL) and data ma
nipulation language (DML) privileges that the grantor cur
rently possesses and is allowed to grant further
The privileges granted are specific to the particular object
being acted upon.
ALTER
Schema
Table
Function/Procedure
Authorizes the ALTER command for the object
CREATE ANY Schema Authorizes the creation of all kinds of objects, in particular,
tables, views, sequences, synonyms, SQLScript functions,
database procedures, and scenarios in a schema
CREATE VIRTUAL TABLE Remote source Authorizes the creation of proxy tables pointing to remote
tables from the source entry
66 P U B L I C
SAP HANA One Security Guide
SAP HANA Authorization
Object Privilege Applicable To Description
CREATE TEMPORARY TA
BLE
Schema
Authorizes the creation of a temporary local table, which
can be used as input for procedures, even if the user does
not have the CREATE ANY privilege for the schema
DEBUG
Schema
View
Function/Procedure
Authorizes debug functionality on a procedure or calcula
tion view or on the procedures and calculation views of a
schema
DELETE
Schema
Table
View
Function/Procedure
Authorizes the DELETE and TRUNCATE commands for the
object
DROP
Schema
Table
View
Sequence
Function/Procedure
Remote source
Authorizes the DROP commands for the object
EXECUTE
Schema
Function/Procedure
Authorizes the execution of an SQLScript function or a data
base procedure using the CALLS or CALL command respec
tively
INDEX
Schema
Table
Authorizes the creation, modification, or dropping of in
dexes for the object
INSERT
Schema
Table
View
Authorizes the INSERT command for the object
The INSERT and UPDATE privilege are both required on the
object to allow the REPLACE and UPSERT commands to be
used.
REFERENCES
Schema
Table
Personal security envi
ronment
Authorizes the usage of all tables in this schema or this table
in a foreign key definition, or the usage of a personal secur
ity environment (PSE) for a certain purpose
SELECT
Schema
Table
View
Sequence
Authorizes the SELECT command for this object or the us
age of a sequence
SELECT CDS METADATA Schema Authorizes access to CDS metadata from the catalog
SELECT METADATA Schema Authorizes access to the complete metadata of all objects in
a schema (including procedure and view definitions), thus
showing the existence of objects that may be located in
other schemas
TRIGGER
Schema
Table
Authorizes the CREATE TRIGGER and DROP TRIGGER com
mands for the specified table or the tables in the specified
schema
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 67
Object Privilege Applicable To Description
UPDATE
Schema
Table
View
Authorizes the UPDATE, LOAD, and UNLOAD commands
for the object
The INSERT and UPDATE privilege are both required on the
object to allow the REPLACE and UPSERT commands to be
used. The UPDATE privilege is also required to perform
delta merges of column store tables using the MERGE
DELTA command.
Note
Additional object privileges may exist and be required in conjunction with SAP HANA options and
capabilities such as SAP HANA Enterprise Information Management. For more information, see SAP HANA
Options and Capabilities on SAP Help Portal.
Caution
SAP HANA server software and tools can be used for several SAP HANA platform and options scenarios as
well as the respective capabilities used in these scenarios. The availability of these is based on the available
SAP HANA licenses and the SAP HANA landscape, including the type and version of the back-end systems
the SAP HANA administration and development tools are connected to. There are several types of licenses
available for SAP HANA. Depending on your SAP HANA installation license type, some of the features and
tools described in the SAP HANA platform documentation may only be available in the SAP HANA options
and capabilities, which may be released independently of an SAP HANA Platform Support Package Stack
(SPS). Although various features included in SAP HANA options and capabilities are cited in the SAP HANA
platform documentation, each SAP HANA edition governs the options and capabilities available. Based on
this, customers do not necessarily have the right to use features included in SAP HANA options and
capabilities. For customers to whom these license restrictions apply, the use of features included in SAP
HANA options and capabilities in a production system requires purchasing the corresponding software
license(s) from SAP. The documentation for the SAP HANA optional components is available in SAP Help
Portal at http://help.sap.com/hana_options. If you have additional questions about what your particular
license provides, or wish to discuss licensing features available in SAP HANA options, please contact your
SAP account team representative.
Related Information
SAP HANA Options and Capabilities
68
P U B L I C
SAP HANA One Security Guide
SAP HANA Authorization
6.4 Analytic Privileges
Analytic privileges grant different users access to different portions of data in the same view based on their
business role. Within the definition of an analytic privilege, the conditions that control which data users see is
either contained in an XML document or defined using SQL.
Standard object privileges (SELECT, ALTER, DROP, and so on) implement coarse-grained authorization at
object level only. Users either have access to an object, such as a table, view or procedure, or they don't. While
this is often sufficient, there are cases when access to data in an object depends on certain values or
combinations of values. Analytic privileges are used in the SAP HANA database to provide such fine-grained
control at row level of which data individual users can see within the same view.
Example
Sales data for all regions are contained within one analytic view. However, regional sales managers should
only see the data for their region. In this case, an analytic privilege could be modeled so that they can all
query the view, but only the data that each user is authorized to see is returned.
XML- Versus SQL-Based Analytic Privileges
Before you implement row-level authorization using analytic privileges, you need to decide which type of
analytic privilege is suitable for your scenario. In general, SQL-based analytic privileges allow you to more
easily formulate complex filter conditions that might be cumbersome to model using XML-based analytic
privileges.
The following are the main differences between XML-based and SQL-based analytic privileges:
Table 32:
Feature
SQL-Based Analytic Privi
leges
XML-Based Analytic Privi
leges
Control of read-only access to SAP HANA information mod
els:
Attribute views
Analytic views
Calculation views
Yes
Yes
Control of read-only access to SQL views Yes No
Control of read-only access to database tables No No
Design-time modeling in the Editor tool of the SAP HANA
Web Workbench
Yes Yes
Design-time modeling in the SAP HANA Modeler perspective
of the SAP HANA studio
Yes Yes
Transportable Yes Yes
Complex filtering Yes No
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 69
Enabling an Authorization Check Based on Analytic Privileges
All column views modeled and activated in the SAP HANA modeler and the SAP HANA Web-based
Development Workbench automatically enforce an authorization check based on analytic privileges. XML-
based analytic privileges are selected by default, but you can switch to SQL-based analytic privileges.
Column views created using SQL must be explicitly registered for such a check by passing the relevant
parameter:
REGISTERVIEWFORAPCHECK for a check based on XML-based analytic privileges
STRUCTURED PRIVILEGE CHECK for a check based on SQL-based analytic privileges
SQL views must always be explicitly registered for an authorization check based analytic privileges by passing
the STRUCTURED PRIVILEGE CHECK parameter.
Note
It is not possible to enforce an authorization check on the same view using both XML-based and SQL-based
analytic privileges. However, it is possible to build views with different authorization checks on each other.
6.4.1 Creating and Managing Analytic Privileges
Analytic privileges can be created and managed both as runtime and design-time objects. We recommend
managing them as repository objects in the SAP HANA modeler or the SAP HANA Web-based Workbench. You
grant analytic privileges to users or roles using the SAP HANA studio or the SAP HANA Web Workbench.
Creating and Deleting Analytic Privileges
To create analytic privileges, a user must have the system privilege CREATE STRUCTURED PRIVILEGE or
STRUCTUREDPRIVILEGE ADMIN. To delete analytic privileges, a user must have the system privilege
STRUCTUREDPRIVILEGE ADMIN.
In the SAP HANA modeler and SAP HANA Web-based Development Workbench, repository objects are
technically created by the technical user _SYS_REPO, which by default has the system privileges for both
creating and deleting analytic privileges. To create, activate, delete, and redeploy analytic privileges therefore,
a user requires the package privileges REPO.EDIT_NATIVE_OBJECTS and
REPO.ACTIVATE_NATIVE_OBJECTS for the relevant package.
Granting and Revoking Analytic Privileges
Once they have been activated, you grant and revoke analytic privileges to users and roles in the same way as
other privilege types in the SAP HANA studio or SAP HANA Web-based Workbench. However, as analytic
privileges are repository objects owned by the _SYS_REPO user, the actual granting and revoking actions
happen through the execution of stored procedures. Therefore, to grant and revoke an analytic privilege, a
70
P U B L I C
SAP HANA One Security Guide
SAP HANA Authorization
user needs the privilege EXECUTE on the procedures GRANT_ACTIVATED_ANALYTICAL_PRIVILEGE and
REVOKE_ACTIVATED_ANALYTICAL_PRIVILEGE respectively.
Recommendation
Use roles to grant privileges to users instead of granted privileges directly. For more information, see Roles.
Users with system privileges CREATE STRUCTURED PRIVILEGE or STRUCTUREDPRIVILEGE ADMIN or
privileges on the above procedures can see granted analytic privileges in the system view
STRUCTURED_PRIVILEGES.
Related Information
Granting and Revoking Privileges on Activated Repository Objects [page 89]
Roles [page 75]
6.5 Package Privileges
Package privileges authorize actions on individual packages in the SAP HANA repository.
Privileges granted on a repository package are implicitly assigned to the design-time objects in the package, as
well as to all sub-packages. Users are only allowed to maintain objects in a repository package if they have the
necessary privileges for the package in which they want to perform an operation, for example to read or write
to an object in that package. To be able perform operations in all packages, a user must have privileges on the
root package .REPO_PACKAGE_ROOT.
If the user authorization check establishes that a user does not have the necessary privileges to perform the
requested operation in a specific package, the authorization check is repeated on the parent package and
recursively up the package hierarchy to the root level of the repository. If the user does not have the necessary
privileges for any of the packages in the hierarchy chain, the authorization check fails and the user is not
permitted to perform the requested operation.
In the context of repository package authorizations, there is a distinction between native packages and
imported packages.
Native package
A package that is created in the current system and expected to be edited in the current system. Changes
to packages or to objects the packages contain must be performed in the original development system
where they were created and transported into subsequent systems. The content of native packages are
regularly edited by developers.
Imported package
A package that is created in a remote system and imported into the current system. Imported packages
should not usually be modified, except when replaced by new imports during an update. Otherwise,
imported packages or their contents should only be modified in exceptional cases, for example, to carry
out emergency repairs.
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 71
Note
The SAP HANA administrator can grant the following package privileges to an SAP HANA user: edit,
activate, and maintain.
Related Information
Package Privilege Options [page 72]
6.5.1 Package Privilege Options
Package privileges authorize actions on individual packages in the SAP HANA repository. In the context of
repository package authorizations, there is a distinction between native packages and imported packages.
Note
To be able perform operations in all packages in the SAP HANA repository, a user must have privileges on
the root package .REPO_PACKAGE_ROOT.
Privileges for Native Repository Packages
A native repository package is created in the current SAP HANA system and expected to be edited in the
current system. To perform application-development tasks on native packages in the SAP HANA repository,
developers typically need the privileges listed in the following table:
Table 33:
Package Privilege Description
REPO.READ Read access to the selected package and design-time ob
jects (both native and imported)
REPO.EDIT_NATIVE_OBJECTS Authorization to modify design-time objects in packages
originating in the system the user is working in
REPO.ACTIVATE_NATIVE_OBJECTS Authorization to activate/reactivate design-time objects in
packages originating in the system the user is working in
REPO.MAINTAIN_NATIVE_PACKAGES Authorization to update or delete native packages, or create
sub-packages of packages originating in the system in
which the user is working
72 P U B L I C
SAP HANA One Security Guide
SAP HANA Authorization
Privileges for Imported Repository Packages
An imported repository package is created in a remote SAP HANA system and imported into the current
system. To perform application-development tasks on imported packages in the SAP HANA repository,
developers need the privileges listed in the following table:
Note
It is not recommended to work on imported packages. Imported packages should only be modified in
exceptional cases, for example, to carry out emergency repairs.
Table 34:
Package Privilege Description
REPO.READ Read access to the selected package and design-time ob
jects (both native and imported)
REPO.EDIT_IMPORTED_OBJECTS Authorization to modify design-time objects in packages
originating in a system other than the one in which the user
is currently working
REPO.ACTIVATE_IMPORTED_OBJECTS Authorization to activate (or reactivate) design-time objects
in packages originating in a system other than the one in
which the user is currently working
REPO.MAINTAIN_IMPORTED_PACKAGES Authorization to update or delete packages, or create sub-
packages of packages, which originated in a system other
than the one in which the user is currently working
Related Information
Package Privileges [page 71]
6.6 Application Privileges
In SAP HANA Extended Application Services (SAP HANA XS), application privileges define the authorization
level required for access to an SAP HANA XS application, for example, to start the application or view
particular functions and screens.
Application privileges can be assigned to an individual user or to a group of users, for example, in a user role.
The user role can also be used to assign system, object, package, and analytic privileges, as illustrated in the
following graphic. You can use application privileges to provide different levels of access to the same
application, for example, to provide advanced maintenance functions for administrators and view-only
capabilities to normal users.
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 73
Figure 4: Application Privileges for Users and User Roles
If you want to define application-specific privileges, you need to understand and maintain the relevant sections
in the following design-time artifacts:
Application-privileges file (.xsprivileges)
Application-access file (.xsaccess)
Role-definition file (<RoleName>.hdbrole)
Application privileges can be assigned to users individually or by means of a user role, for example, with the
application privilege” keyword in a role-definition file (<RoleName>.hdbrole) as illustrated in the following
code. You store the roles as design-time artifacts within the application package structure they are intended
for, for example, acme.com.hana.xs.app1.roles.
role acme.com.hana.xs.app1.roles::Display
{
application privilege: acme.com.hana.xs.appl::Display;
application privilege: acme.com.hana.xs.appl::View;
catalog schema "ACME_XS_APP1": SELECT;
package acme.com.hana.xs.app1: REPO.READ;
package ".REPO_PACKAGE_ROOT" : REPO.READ;
catalog sql object "_SYS_REPO"."PRODUCTS": SELECT;
catalog sql object "_SYS_REPO"."PRODUCT_INSTANCES": SELECT;
catalog sql object "_SYS_REPO"."DELIVERY_UNITS": SELECT;
catalog sql object "_SYS_REPO"."PACKAGE_CATALOG": SELECT;
catalog sql object "ACME_XS_APPL"."acme.com.hana.xs.appl.db::SYSTEM_STATE":
SELECT, INSERT, UPDATE, DELETE;
}
The application privileges referenced in the role definition (for example, Display and View) are actually
defined in an application-specific .xsprivileges file, as illustrated in the following example, which also
contains entries for additional privileges that are not explained here.
Note
The .xsprivileges file must reside in the package of the application to which the privileges apply.
The package where the .xsprivileges resides defines the scope of the application privileges; the privileges
specified in the.xsprivileges file can only be used in the package where the .xsprivileges resides (or
any sub-packages). This is checked during activation of the .xsaccess file and at runtime in the by the XS
JavaScript API $.session.(has|assert)AppPrivilege().
{
"privileges" : [
74
P U B L I C
SAP HANA One Security Guide
SAP HANA Authorization
{ "name" : "View", "description" : "View Product Details" },
{ "name" : "Configure", "description" : "Configure Product Details" },
{ "name" : "Display", "description" : "View Transport Details" },
{ "name" : "Administrator", "description" : "Configure/Run Everything" },
{ "name" : "ExecuteTransport", "description" : "Run Transports"},
{ "name" : "Transport", "description" : "Transports"}
]
}
The privileges are authorized for use with an application by inserting the authorization keyword into the
corresponding .xsaccess file, as illustrated in the following example. Like the .xsprivileges file,
the .xsaccess file must reside either in the root package of the application to which the privilege
authorizations apply or the specific subpackage which requires the specified authorizations.
Note
If a privilege is inserted into the .xsaccess file as an authorization requirement, a user must have this
privilege to access the application package where the
.xsaccess file resides. If there is more than one
privilege, the user must have at least one of these privileges to access the content of the package.
{
"prevent_xsrf": true,
"exposed": true,
"authentication": {
"method": "Form"
},
"authorization": [
"acme.com.hana.xs.appl::Display",
"acme.com.hana.xs.appl::Transport"
]
}
6.7 Roles
A role is a collection of privileges that can be granted to either a user or another role in runtime.
A role typically contains the privileges required for a particular function or task, for example:
Business end users reading reports using client tools such as Microsoft Excel
Modelers creating models and reports in the modeler of the SAP HANA studio
Database administrators operating and maintaining the database and users
Privileges can be granted directly to users of the SAP HANA database. However, roles are the standard
mechanism of granting privileges as they allow you to implement complex, reusable authorization concepts
that can be modeled on business roles.
Roles in the SAP HANA database can exist as runtime objects only (catalog roles), or in the repository of the
SAP HANA database as design-time objects that become runtime objects on activation (repository roles).
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 75
Role Structure
A role can contain any number of the following privileges:
System privileges for the following:
Administration tasks (for example, AUDIT ADMIN, BACKUP ADMIN, CATALOG READ,
REPO.CONFIGURE)
Developer tasks related to object change management (for example, REPO.MODIFY_CHANGE,
REPO.MODIFY_OWN_CONTRIBUTION, REPO.MODIFY_FOREIGN_CONTRIBUTION)
Object privileges (for example, SELECT, INSERT, UPDATE) on database objects (for example, schemas,
tables, views, procedures, and sequences)
Analytic privileges on SAP HANA information models
Package privileges on repository packages (for example, REPO.READ, REPO.EDIT_NATIVE_OBJECTS,
REPO.ACTIVATE_NATIVE_OBJECTS)
Application privileges for enabling access to SAP HANA-based applications
A role can also contain other roles.
Managing Roles
You can create and manage roles, as well as grant them to users, using the SAP HANA studio and the SAP
HANA Web-based Development Workbench. The SAP HANA cockpit also provides an app for granting roles to
users (Assign Roles app).
For best performance of role operations, in particular, granting and revoking, keep the following basic rules in
mind:
Create roles with the smallest possible set of privileges for the smallest possible group of users who can
share a role (principle of least privilege)
Avoid granting object privileges at the schema level to a role if only a few objects in the schema are
relevant for intended users.
Avoid creating and maintaining all roles as a single user. Use several role administrator users instead.
76
P U B L I C
SAP HANA One Security Guide
SAP HANA Authorization
6.7.1 Catalog Roles and Repository Roles Compared
It is possible to create roles as pure runtime objects that follow classic SQL principles or as design-time
objects in the repository of the SAP HANA database. In general, repository roles are recommended as they
offer more flexibility. For example, they can be transported between systems.
The following table summarizes the differences between catalog roles and repository roles:
Table 35:
Feature
Catalog Roles Repository Roles
Transportability Roles cannot be transported between
systems. They can only be created in
runtime by users with the system privi
lege ROLE ADMIN.
Roles can be transported between sys
tems using several transport options:
SAP HANA Application Lifecycle
Manager
The change and transport system
(CTS+) of the SAP NetWeaver
ABAP application server
SAP HANA Transport Container
(HTC)
Version management
No version management is possible. The repository provides the basis for
versioning. As repository objects, roles
are stored in specific repository tables
inside the database. This eliminates the
need for an external version control
system.
Relationship to creating database user
Roles are owned by the database user
who creates them. To create a role, a
database user requires all the privi
leges being granted to the role. If any of
these privileges are revoked from the
creating user, they are automatically
revoked from the role. Similarly, if the
creating user is dropped, all roles that
he or she created are also dropped.
The technical user _SYS_REPO is the
owner of roles, not the database user
who creates them. Therefore, roles are
not directly associated with the creat
ing user. To create a role, a database
user needs only the privileges required
to work in the repository.
Grant and revoke process
Roles created in runtime are granted
directly by the database user using the
SQL GRANT and REVOKE statements.
Roles can only be revoked by the gran
tor. If the granting user is dropped (not
necessarily the role creator), all roles
that he or she granted are revoked.
Roles are granted and revoked using
built-in procedures. Any administrator
with the EXECUTE privilege on these
can grant and revoke roles. Role crea
tion is decoupled from the grant and re
voke process.
In general, it is recommended that you model roles as design-time objects for the following reasons:
Unlike roles created in runtime, roles created as design-time objects can be transported between systems.
This is important for application development as it means that developers can model roles as part of their
application's security concept and then ship these roles or role templates with the application. Being able
to transport roles is also advantageous for modelers implementing complex access control on analytic
content. They can model roles in a test system and then transport them into a production system. This
avoids unnecessary duplication of effort.
Roles created as design-time objects are not directly associated with a database user. They are created by
the technical user _SYS_REPO and granted through the execution of stored procedures. Any user with
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 77
access to these procedures can grant and revoke a role. Roles created in runtime are granted directly by
the database user and can only be revoked by the same user. Additionally, if the database user is deleted,
all roles that he or she granted are revoked. As database users correspond to real people, this could
impact the implementation of your authorization concept, for example, if an employee leaves the
organization or is on vacation.
Catalog roles make sense in scenarios where user and role provisioning is carried out solely using a higher-
level application that connects to SAP HANA through a technical user such as SAP Identity Management.
Related Information
Granting and Revoking Privileges on Activated Repository Objects [page 89]
Developer Authorization [page 86]
6.7.2 Roles as Repository Objects
Roles can be created in the repository of the SAP HANA database as design-time objects that become runtime
objects on activation. Being a repository object has several implications for a role.
Roles created in the repository differ from roles created directly as runtime objects using SQL in some
important ways:
What authorization does a user need to grant privileges to a role? [page 78]
What about the WITH ADMIN OPTION and WITH GRANT OPTION parameters? [page 79]
How are repository roles granted and revoked? [page 79]
How are repository roles dropped? [page 80]
Can changes to repository roles be audited? [page 80]
What authorization does a user need to grant privileges to a role?
According to the authorization concept of the SAP HANA database, a user can only grant a privilege to a user
directly or indirectly in a role if the following prerequisites are met:
The user has the privilege him- or herself
The user is authorized to grant the privilege to others (WITH ADMIN OPTION or WITH GRANT OPTION)
A user is also authorized to grant object privileges on objects that he or she owns.
The technical user _SYS_REPO is the owner of all objects in the repository, as well as the runtime objects that
are created on activation. This means that when you create a role as a repository object, you can grant the
following privileges:
Privileges that have been granted to the technical user _SYS_REPO and that _SYS_REPO can grant further
This is automatically the case for system privileges, package privileges, analytic privileges, and application
privileges. Therefore, all system privileges, package privileges, analytic privileges, and application
privileges can always be granted in design-time roles.
78
P U B L I C
SAP HANA One Security Guide
SAP HANA Authorization
Privileges on objects that _SYS_REPO owns
_SYS_REPO owns all activated objects. Object privileges on non-activated runtime objects must be
explicitly granted to _SYS_REPO. It is recommended that you use a technical user to do this to ensure that
privileges are not dropped when the granting user is dropped (for example, because the person leaves the
company.
The following table summarizes the situation described above:
Table 36:
Privilege
Action Necessary to Grant in Repository Role
System privilege None
Package privilege None
Analytic privilege None
Application privilege None
SQL object on activated object (for example, attribute view,
analytic view)
None
SQL object privilege on runtime object (for example, repli
cated table)
Grant privilege to user _SYS_REPO with WITH GRANT OP
TION
Note
Technically speaking, only the user _SYS_REPO needs the privileges being granted in a role, not the
database user who creates the role. However, users creating roles in the SAP HANA Web-based
Development Workbench must at least be able to select the privileges they want to grant to the role. For
this, they need either the system privilege CATALOG READ or the actual privilege to be granted.
What about the WITH ADMIN OPTION and WITH GRANT OPTION
parameters?
When you create a role using SQL (that is, as a runtime object), you can grant privileges with the additional
parameters WITH ADMIN OPTION or WITH GRANT OPTION. This allows a user who is granted the role to grant
the privileges contained within the role to other users and roles. However, if you are implementing your
authorization concept with privileges encapsulated within roles created in design time, then you do not want
users to grant privileges using SQL statements. For this reason, it is not possible to pass the parameters WITH
ADMIN OPTION or WITH GRANT OPTION with privileges when you model roles as repository objects.
Similarly, when you grant an activated role to a user, it is not possible to allow the user to grant the role further
(WITH ADMIN OPTION is not available).
How are repository roles granted and revoked?
It is not possible to grant and revoke activated design-time roles using the GRANT and REVOKE SQL
statements. Instead, roles are granted and revoked through the execution of the procedures
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 79
GRANT_ACTIVATED_ROLE and REVOKE_ACTIVATED_ROLE. Therefore, to be able to grant or revoke a role, a
user must have the object privilege EXECUTE on these procedures.
How are repository roles dropped?
It is not possible to drop the runtime version of a role created in the repository using the SQL statement DROP
ROLE. To drop a repository role, you must delete it in the repository and activate the change. The activation
process deletes the runtime version of the role.
Can changes to repository roles be audited?
The auditing feature of the SAP HANA database allows you to monitor and record selected actions performed
in your database system. One action that is typically audited is changes to user authorization. If you are using
roles created in the repository to grant privileges to users, then you audit the creation of runtime roles through
activation with the audit action ACTIVATE REPOSITORY CONTENT.
6.7.3 Repository Roles in the Lifecycle of SAP HANA-Based
Applications
Roles are an integral part of SAP HANA-based applications and their lifecycle. Developers create application-
specific objects, including roles, in the repository of the development system. Content administrators
transport applications as delivery units to the production system, where they are activated. User
administrators grant activated roles to end users.
In application development scenarios, roles are developed like other application-specific artifacts and
managed as part of overall application lifecycle management. Roles developed as part of the application
encapsulate the privileges required by different user groups to use the application.
The following is a high-level overview of how applications, including application-specific roles, are developed
and deployed:
1. Developers build the application by creating the required objects, including roles, in the repository of the
development system.
All development objects, including roles, are stored in packages. Packages that belong to the same
application are grouped together into a delivery unit (DU). DUs are the mechanism by which design-time
objects in the repository are transported between two systems. They ensure that application-specific
objects are transported consistently together within a system landscape.
2. Developers activate their development objects in the development system initially for testing purposes
and finally to make them ready for transport.
The activation process makes the design-time objects available in runtime. In many cases, the runtime
objects created are catalog objects, such as schemas, tables, views, and roles.
3. The content administrator transports the application DU from the development system to the production
system. This activates the DU and creates runtime objects in the production system.
80
P U B L I C
SAP HANA One Security Guide
SAP HANA Authorization
Content can be exported and imported using:
SAP HANA Application Lifecycle Manager
The change and transport system (CTS+) of the SAP NetWeaver ABAP application server
HANA Transport Container (HTC)
The transport option used depends on the scenario. For example, CTS+ can be used to transport SAP
HANA content in ABAP system landscapes where a CTS transport landscape is already in place.
Once roles are available as runtime objects in the production system, the user administrator can grant them to
end users.
Caution
The design-time version of a role in the repository and its activated runtime version should always contain
the same privileges. In particular, additional privileges should not be granted to the activated runtime
version of a role created in the repository. If a repository role is changed in runtime, the next time the role is
activated in the repository, any changes made to the role in runtime will be reverted. It is therefore
important that the activated runtime version of a role is not changed in runtime. Although it is not possible
to change the activated runtime version of a repository role in the SAP HANA studio, there is no mechanism
of preventing a user from doing this at the SQL level.
The following figure illustrates the process described above:
Figure 5: Lifecycle of Repository Roles
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 81
Related Information
Change and Transport System (Including CTS Plug-In)
How to transport ABAP for SAP HANA applications with HTC
6.7.4 Standard Database Roles
Several catalog and repository roles are available by default in the SAP HANA database.
Catalog roles
Repository roles
Catalog Roles
Several catalog roles are delivered with the SAP HANA database. You should not use these roles directly, but
instead use them as templates for creating your own roles.
The table below lists the catalog roles delivered with the SAP HANA database.
Note
These roles do not exist in the repository.
Table 37:
Role
Description
CONTENT_ADMIN
This role contains all the privileges required for using the information modeler in
the SAP HANA studio, as well the additional authorization to grant these privi
leges to other users. It also contains system privileges for working with imported
objects in the SAP HANA repository. You can use this role as a template for cre
ating roles for content administrators.
Caution
The CONTENT_ADMIN role is very privileged and should not be granted to
users, particularly in production systems. The CONTENT_ADMIN role should
only be used as a template.
82 P U B L I C
SAP HANA One Security Guide
SAP HANA Authorization
Role Description
MODELING
This role contains all the privileges required for using the information modeler in
the SAP HANA studio.
It therefore provides a modeler with the database authorization required to cre
ate all kinds of views and analytic privileges.
Caution
The MODELING role contains the standard analytic privilege _SYS_BI_CP_ALL.
This analytic privilege potentially allows a user to access all the data in all acti
vated views, regardless of any other analytic privileges that apply. Although
the user must also have the SELECT object privilege on the views to actually
be able to access data, the _SYS_BI_CP_ALL analytic privilege should not be
granted to users, particularly in production systems. For this reason, the
MODELING role should only be used as a template.
MONITORING
This role contains privileges for full read-only access to all metadata, the current
system status in system and monitoring views, and the data collected by the sta
tistics server.
PUBLIC
This role contains privileges for filtered read-only access to the system views.
Only objects for which the users have access rights are visible. By default, this
role is granted to every user, except restricted users.
RESTRICTED_USER_JDBC_ACCESS
This role contains the privileges required by restricted database users to connect
to SAP HANA through the JDBC client interface.
This role is intended to be used in conjunction with application-specific roles. It is
recommended that the privileges required to use an application are encapsu
lated within an application-specific role, which is then granted to restricted data
base users. By including the RESTRICTED_USER_JDBC_ACCESS role in the appli
cation-specific role, it can be ensured that application users have only those priv
ileges that are essential to their work.
RESTRICTED_USER_ODBC_ACCESS
This role contains the privileges required by restricted database users to connect
to SAP HANA through the ODBC client interface.
This role is intended to be used in conjunction with application-specific roles. It is
recommended that the privileges required to use an application are encapsu
lated within an application-specific role, which is then granted to restricted data
base users. By including the RESTRICTED_USER_ODBC_ACCESS role in the appli
cation-specific role, it can be ensured that application users have only those priv
ileges that are essential to their work.
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 83
Role Description
SAP_INTERNAL_HANA_SUPPORT
This role contains system privileges (for example, CATALOG READ) and object
privileges (for example, SELECT on SYS schema) that allow access to certain
low-level internal system views needed by SAP HANA development support in
support situations. All access is read only. This role does not allow access to any
customer data.
The definition of the low-level internal system views to which this role allows ac
cess is not part of the stable end-user interface and might change from revision
to revision. To avoid administrators and end users accidentally accessing these
internal system views in applications or scripts, this role is therefore subject to
several usage restrictions (listed below) and should be granted only to SAP
HANA development support users for the their support activities.
In detail, this role contains privileges for read-only access to all metadata, the
current system status, and the data of the statistics server. Additionally, it con
tains the privileges for accessing low-level internal system views. Without the
SAP_INTERNAL_HANA_SUPPORT role, this information can be selected only by
the SYSTEM user.
To avoid accidental use of this role in day-to-day activities, the following restric
tions apply to the SAP_INTERNAL_HANA_SUPPORT role:
It cannot be granted to the SYSTEM user.
It can only be granted to a limited number of users at the same time.
The maximum number of users to which the role can be granted can be con
figured with the parameter internal_support_user_limit in the
authorization section of the indexserver.ini configuration file. The de
fault value is 1.
It cannot be granted to another role.
It cannot be granted another role.
It cannot be granted further object privileges.
It can be granted only further system privileges.
With every upgrade of the SAP HANA database, it is reset to its default privi
leges.
To ensure that system administrators are aware that the
SAP_INTERNAL_HANA_SUPPORT role is currently granted to one or more users in
a system, an information alert is issued every hour by default. This behavior can
configured with check 63.
Repository Roles
SAP HANA is delivered with a set of preinstalled software components implemented as SAP HANA Web
applications, libraries, and configuration data. The privileges required to use these components are contained
within roles delivered with the component itself. For more information about the repository roles delivered as
standard, see SAP HANA Content.
84
P U B L I C
SAP HANA One Security Guide
SAP HANA Authorization
Note
No user has these roles initially except the standard user _SYS_REPO. Some may also be granted
automatically to the standard user SYSTEM. For more information, see Repository Roles Granted to
Standard Database Users.
Related Information
SAP HANA Content [page 125]
Repository Roles Granted to Standard Database Users [page 85]
6.7.5 Repository Roles Granted to Standard Database Users
The privileges required to use software components delivered as SAP HANA content are contained within
roles delivered with the component itself. The standard user _SYS_REPO automatically has all of these roles.
Some may also be granted automatically to the standard user SYSTEM.
_SYS_REPO
Like all repository roles, roles delivered with SAP HANA content are owned by the user _SYS_REPO. Therefore,
_SYS_REPO has all standard repository roles.
SYSTEM
The SAP HANA cockpit is an SAP Fiori Launchpad site that provides SAP HANA administrators with a single
point-of-access to a range of Web-based administration applications, which are delivered as SAP HANA
content. To ensure that SAP HANA cockpit can be used "out of the box" after database creation, the database
user SYSTEM is automatically granted several roles the first time the cockpit is opened with this user. As the
SYSTEM user, a user administrator can then create dedicated database users for administrative tasks and
grant them these roles.
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 85
The following roles are granted:
Table 38:
Role Description
sap.hana.admin.roles::Administrator
Allows users to open the SAP HANA cockpit with read-only
access to monitoring data, as well as to perform database
administration tasks supported by the cockpit (configure
alerts, stop/start services, reset memory statistics, cancel
sessions)
This role also allows users to see tiles in the SAP HANA
Platform Lifecycle Management tile catalog.
sap.hana.xs.ide.roles::TraceViewer
Allows users to open the Trace tool of the SAP HANA Web-
based Development Workbench
sap.hana.ide.roles::SecurityAdmin
Allows users to open the Security tool of the SAP HANA
Web-based Development Workbench
6.8 Authorization in the Repository of the SAP HANA
Database
The authorization concept of SAP HANA applies in the repository of the SAP HANA database.
Developers of SAP HANA-based applications create application-specific objects such as views, procedures,
tables, roles, CDS entities, and web content exposed via SAP HANA Extended Services (SAP HANA XS). SAP
HANA comes with a built-in repository for the management and persistence of the design-time
representations of these objects. The repository provides the basis for concepts like namespaces (through
packages), versioning, transport in system landscapes, and software component delivery from SAP or
independent software vendors to customers.
To ensure that the application development process is secure, it is important that developers have access to
only those repository objects that they actually need to work with.
The technical user _SYS_REPO is the owner of all objects in the repository, as well as their activated runtime
versions. _SYS_REPO must be explicitly authorized for objects that are not created in the repository but on
which repository objects are modeled.
As the owner of all objects in the repository, _SYS_REPO is the only user who can grant privileges on them.
Since no user can log on as _SYS_REPO, stored procedures are used to grant privileges on repository objects
instead.
6.8.1 Developer Authorization
To ensure that the application development process is secure, it is important that developers have access to
only those repository objects that they actually need to work with.
The repository of the SAP HANA database consists of packages that contain design-time versions of various
objects, such as attribute views, analytic views, calculation views, procedures, analytic privileges, roles, and so
86
P U B L I C
SAP HANA One Security Guide
SAP HANA Authorization
on. All repository methods that provide read or write access to content are secured with authorization checks.
To allow developers to work with packages in the repository, they must have the required package, system,
and object privileges.
The following table explains the privileges that developers require to work in the repository:
Table 39:
Privilege Type
Privileges Required
Package privileges The SAP HANA repository is structured hierarchically with packages assigned to
other packages as sub-packages. If you grant privileges to a user for a package,
the user is also automatically authorized for all corresponding sub-packages.
In the SAP HANA repository, a distinction is made between native and imported
packages. Native packages are packages that were created in the current system
and should therefore be edited in the current system. Imported packages from
another system should not be edited, except by newly imported updates. An im
ported package should only be manually edited in exceptional cases.
Developers should be granted the following privileges for native packages:
REPO.READ
REPO.EDIT_NATIVE_OBJECTS
REPO.ACTIVATE_NATIVE_OBJECTS
REPO.MAINTAIN_NATIVE_PACKAGES
Developers should only be granted the following privileges for imported pack
ages in exceptional cases:
REPO.EDIT_IMPORTED_OBJECTS
REPO.ACTIVATE_IMPORTED_OBJECTS
REPO.MAINTAIN_IMPORTED_PACKAGES
System privileges
Developers require the following system privileges to be able to work in the repo
sitory:
REPO.EXPORT
REPO.IMPORT
REPO.MAINTAIN_DELIVERY_UNITS
REPO.WORK_IN_FOREIGN_WORKSPACE
REPO.MODIFY_CHANGE, REPO.MODIFY_OWN_CONTRIBUTION, and
REPO.MODIFY_FOREIGN_CONTRIBUTION
These 3 privileges authorize the user to work with SAP HANA Change
Recording, which is part of SAP HANA Application Lifecycle Management.
Object privileges
To be able to access the repository in the SAP HANA studio or another client, de
velopers need the EXECUTE privilege on the database procedure SYS.REPOSI
TORY_REST.
Authorization for SAP HANA Web-based Developer Workbench
If developers are using the SAP HANA Web-based Development Workbench, the privileges required for
building and testing development artifacts as well tool access are bundled into the following roles:
sap.hana.xs.ide.roles::EditorDeveloper
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 87
sap.hana.xs.debugger::Debugger
For more information, see SAP HANA Web-Based Development Workbench in the SAP HANA Developer Guide
(For Web Workbench) on SAP Help Portal.
Authorization for SAP HANA Application Lifecycle Management
SAP HANA Application Lifecycle Management is a Web-based tool that runs in SAP HANA Extended
Application Services (SAP HANA XS). Application developers use this tool to create products, delivery units,
packages, and basic application components, while administrators use it to set up the transport of delivery
units, start and monitor transports, and upload or download delivery unit archives.
These tasks require different combinations of various privileges. Dedicated roles are available and can be
granted to users based on their function (for example, sap.hana.xs.lm.roles::Administrator). For
more information, see SAP HANA Application Lifecycle Management on SAP Help Portal.
Related Information
Package Privileges [page 71]
System Privileges (Reference) [page 61]
SAP HANA Application Lifecycle Management
6.8.2 _SYS_REPO Authorization in the Repository
The technical user _SYS_REPO is the owner of all objects in the repository, as well as their activated runtime
versions. _SYS_REPO must be explicitly authorized for objects that are not created in the repository but on
which repository objects are modeled.
The repository of the SAP HANA database consists of packages that contain design-time versions of various
objects, such as attribute views, analytic views, calculation views, procedures, analytic privileges, roles, and so
on. Design-time objects must be activated to become runtime objects so that they can be used by end users of
SAP HANA and the SAP HANA database.
Inside the repository, only the technical user _SYS_REPO is used. Therefore, this user is the owner of the
objects created in the repository and initially is the only user with privileges on these objects. This includes the
following objects:
All tables in the repository schema (_SYS_REPO)
All activated objects such as procedures, views, analytic privileges, and roles
Note
This does not apply in the case of objects that have been activated using the data preview on intermediate
nodes in calculation models. These objects are activated and owned by the user who does the data preview.
88
P U B L I C
SAP HANA One Security Guide
SAP HANA Authorization
Objects in the repository can be modeled on data objects that are not part of design time, such as tables that
are used in replication scenarios. _SYS_REPO does not automatically have authorization to access these
objects. _SYS_REPO must therefore be granted the SELECT privilege (with grant option) on all data objects
behind all objects modeled in the repository. If this privilege is missing, the activated objects will be invalidated.
6.8.3 Granting and Revoking Privileges on Activated
Repository Objects
Only the _SYS_REPO user has privileges on objects in the repository. Therefore, only this user can grant
privileges on them. Since no user can log on as _SYS_REPO, stored procedures are used to grant privileges
instead.
Using stored procedures and a technical user for privilege management is beneficial for the following reasons
compared to the standard SQL mechanism using the GRANT and REVOKE statements:
To be able to grant a privilege, a user must have the privilege and be authorized to grant it further. This is
not the case when procedures are used. Any user who has the EXECUTE privilege on the relevant grant
procedure can grant privileges.
If a user grants a privilege using the GRANT statement, the privilege is automatically revoked when the
grantor is dropped or loses the granted privileges.
Only the grantor can revoke the privilege. With the stored procedures approach, any user with the
EXECUTE privilege on the relevant revoke procedure can revoke a granted privilege, regardless of the
grantor. If the grantor is dropped, none of the privileges that he or she granted are revoked.
When the SAP HANA studio is used for privilege management, it automatically chooses the suitable method
for granting and revoking privileges and roles. So if privileges on activated objects are being granted or
revoked, the procedures are used.
Caution
Users who can change and activate objects as well as grant privileges on activated objects have access to
all SAP HANA content.
Related Information
Stored Procedures Used to Grant/Revoke Privileges on Activated Repository Objects [page 90]
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 89
6.8.3.1 Stored Procedures Used to Grant/Revoke
Privileges on Activated Repository Objects
Stored procedures, which exist in the _SYS_REPO schema, are used to grant and revoke privileges on
activated modeled objects, analytic privileges, application privileges, and roles.
Note
Public synonyms of these procedures exist. Therefore, these procedures can be called without specifying
the schema _SYS_REPO.
Table 40:
Activated Object Type
Procedure Call for Grant and Revoke
Modeled objects, such as calculation
views
CALL GRANT_PRIVILEGE_ON_ACTIVATED_CONTENT
('<object_privilege>','<object>''<user>'/'<role>')
CALL REVOKE_PRIVILEGE_ON_ACTIVATED_CONTENT
('<object_privilege>','<object>','<user>'/'<role>')
Schema containing modeled objects
CALL GRANT_SCHEMA_PRIVILEGE_ON_ACTIVATED_CONTENT
('<analytic_privilege>','<user>'/'<role>')
CALL REVOKE_SCHEMA_PRIVILEGE_ON_ACTIVATED_CONTENT
('<analytic_privilege>','<user>'/'<role>')
Analytic privilege
CALL GRANT_ACTIVATED_ANALYTICAL_PRIVILEGE
('<analytic_privilege>','<user>'/'<role>')
CALL REVOKE_ACTIVATED_ANALYTICAL_PRIVILEGE
('<analytic_privilege>','<user>'/'<role>')
Application privilege
CALL GRANT_APPLICATION_PRIVILEGE
('<application_privilege>','<user>'/'<role>')
CALL REVOKE_APPLICATION_PRIVILEGE
('<application_privilege>','<user>'/'<role>')
Role
CALL GRANT_ACTIVATED_ROLE ('<role>','<user>'/'<role>')
CALL REVOKE_ACTIVATED_ROLE
('<role>','<user>'/'<role>')
Note
Object names that are not simple identifiers must be enclosed between double quotes, for example:
CALL GRANT_APPLICATION_PRIVILEGE ('"com.acme.myApp::Execute"','User')
This does not apply to the procedures GRANT_ACTIVATED_ROLE and REVOKE_ACTIVATED_ROLE. The
role being granted or revoked must not be enclosed in double quotes, for example:
CALL GRANT_ACTIVATED_ROLE ('acme.com.data::MyUserRole','User')
For all procedures, the user or role to whom/from whom a privilege or role is being granted/revoked must
not be enclosed between double quotes.
90
P U B L I C
SAP HANA One Security Guide
SAP HANA Authorization
6.9 SAP HANA One Samplers
Samplers with public data are available as packages for installation in the SAP HANA One Add-On Manager.
The goal of making sample data available is to demonstrate the capabilities of SAP HANA in an easy-to-use
way in SAP HANA One.
The sample data is provided as of a static date and is for demonstration purposes only and may not be
accurate. Each sampler includes a how-to guide describing the source of the data, a business and technical
description of the sampler, and instructions about how to uninstall the sampler.
When using the provided samplers, we strongly recommend complying to the concept presented in this
security guide.
Disclaimer
The sample data is provided "as-is" and without warranty of any kind, express, implied or otherwise, including
without limitation, any warranty of fitness for a particular purpose.
In no event shall SAP be liable to you or anyone else for any direct, special, incidental, indirect or consequential
damages of any kind, or any damages whatsoever, including without limitation, loss of profit, loss of use,
savings or revenue, or the claims of third parties, whether or not SAP has been advised of the possibility of
such loss, however caused and on any theory of liability, arising out of or in connection with the possession,
use or performance of this data.
SAP HANA One Security Guide
SAP HANA Authorization
P U B L I C 91
7 Data Storage Security in SAP HANA
Several mechanisms can be used to protect security-relevant data used by the SAP HANA database.
The file permissions of the operating system are strictly configured. Therefore, we recommend that you do not
change them after subscription to and configuration of SAP HANA One.
The following aspects of server-side and client-side data storage are also security relevant.
Server-Side Data Security
Data at rest encryption
To protect data saved to disk from unauthorized access at operating system level, the SAP HANA
database supports data encryption in the persistence layer. This is referred to as data volume encryption.
Passwords
All operating system user and database user passwords are stored securely on the SAP HANA database
server. In addition, credentials required by SAP HANA applications for outbound connections are stored
securely in an internal credential store, which in turn is secured using the internal data encryption service.
Data in applications developed using SAP HANA Extended Application Services (SAP HANA XS)
Application developers can use the SAP HANA XS $.security.Store API to define secure stores that
store application data in name-value form. These secure stores use the internal data encryption service.
Instance secure store in the file system (SSFS)
SAP HANA uses the instance SSFS to store all internal SAP HANA encryption keys, that is the root keys
used for data volume encryption and the internal data encryption service.
Note
To prevent data encrypted in the SAP HANA database from becoming inaccessible, the content of the
instance SSFS and key information in the database must remain consistent. The database detects if
this is not case, for example if the instance SSFS becomes corrupted, and issues an alert (check 57).
System public key infrastructure (PKI) SSFS
SAP HANA uses the system PKI SSFS to protect the X.509 certificate infrastructure that is used to secure
internal SSL/TLS-based communication.
Client-Side Data Security
Secure user store
The SAP HANA user store (hdbuserstore) can be used to store user logon information to allow client
applications to connect to SAP HANA without having to enter a user's password explicitly.
SAP HANA studio
The Eclipse secure storage can be used to store user passwords in the SAP HANA studio.
92
P U B L I C
SAP HANA One Security Guide
Data Storage Security in SAP HANA
Data copied to local workspaces requires additional protection.
Related Information
Secure Storage in the File System (AS ABAP)
7.1 Server-Side Data Encryption
SAP HANA features two data encryption services: data encryption in the persistence layer and an internal
encryption service available to applications requiring data encryption. SAP HANA uses the secure store in the
file system (SSFS) to protect the root keys for these encryption services.
Data Volume Encryption
Table 41:
What Does It Do?
What Encryption Keys Are Involved?
If enabled, this internal encryption service protects all data
saved to disk from unauthorized access at operating system
level.
For more information, see Data Volume Encryption.
Pages in the data area are encrypted using
page encryption
keys. Page encryption keys are encrypted with the data vol
ume encryption root key
.
The root key is generated randomly during installation. The
page keys are created when data volume encryption is ena
bled.
SAP HANA One Security Guide
Data Storage Security in SAP HANA
P U B L I C 93
Internal Data Encryption Service
Table 42:
What Does It Do?
What Encryption Keys Are Involved?
This internal encryption service is used in the following con
texts:
Secure internal credential store
This service stores credentials required by SAP HANA
for outbound connections. It is used when data is re
trieved from remote data sources using SAP HANA
smart data access. It is also used during HTTP destina
tion calls from SAP HANA XS applications.
For more information, see Secure Internal Credential
Store.
Secure stores defined using the SAP HANA XS
$.security.Store API
Application developers can create XS secure stores to
store certain application data in name-value form. For
more information, see Using the Server-Side JavaScript
APIs in the SAP HANA Developer Guide (For SAP HANA
Studio) and the Class:Store in the SAP HANA XS Java
Script API Reference on SAP Help Portal.
Private key store
This service stores the private keys of the SAP HANA
server required for secure client-server communica
tion, if the relevant personal security environment
(PSE) is stored in the database.
For more information, see SSL Configuration on the
SAP HANA Server and Certificate Management in SAP
HANA.
Every consumer of the service has its own system-internal
application encryption key. Application encryption keys are
encrypted with the
data encryption service root key.
The root key is generated randomly during installation. The
application key for the internal credential store is generated
randomly during the first startup. Application keys for XS
secure stores are created with the XS secure store. The ap
plication key for the private key store is created when the
first private key is set for an in-database PSE.
94 P U B L I C
SAP HANA One Security Guide
Data Storage Security in SAP HANA
Instance Secure Store in the File System (SSFS)
Table 43:
What Does It Do?
What Encryption Keys Are Involved?
This secure store stores internal root keys in the file system. The master key of the instance SSFS encrypts the data vol
ume encryption root key and the data encryption service
root key.
Recommendation
The initial default master key that protects the instance
SSFS is changed during installation or update. If you re
ceived your system pre-installed from a hardware or
hosting partner, we recommend that you change it im
mediately after handover to ensure that it is not known
outside of your organization.
System PKI (Public Key Infrastructure) SSFS
Table 44:
What Does It Do?
What Encryption Keys Are Involved?
This secure store stores internal root keys in the file system. The master key of the system PKI SSFS protects the X.509
certificate infrastructure that is used to secure internal
SSL/TLS-based communication.
Recommendation
The initial default master key that protects the system
PKI SSFS is changed during installation or upgrade. If
you received your system pre-installed from a hardware
or hosting partner, we recommend that you change it im
mediately after handover to ensure that it is not known
outside of your organization.
The following figure illustrates the encryption keys protected by the instance SSFS.
Note
The system PKI SSFS is not depicted.
SAP HANA One Security Guide
Data Storage Security in SAP HANA
P U B L I C 95
Figure 6: Encryption Keys Protected by the Instance SSFS
Related Information
Data Volume Encryption [page 100]
Secure Internal Credential Store [page 101]
SSL Configuration on the SAP HANA Server [page 19]
Certificate Management in SAP HANA [page 117]
Secure Storage in the File System (AS ABAP)
96
P U B L I C
SAP HANA One Security Guide
Data Storage Security in SAP HANA
7.1.1 Encryption Key Management
SAP HANA generates new and unique root keys on installation. However, if you received SAP HANA pre-
installed from a hardware vendor, you might want to change them to ensure they are not known outside your
organization. We recommend that you do this immediately after handover from your hardware partner.
The following root keys exist and can be changed:
Instance SSFS master key
System PKI SSFS master key
Data volume encryption root key
Data encryption service root key
Reinstalling your system will change the data volume encryption and data encryption service root keys. The
initial default master keys of both the instance SSFS and the system PKI SSFS will also be changed. You can
use command line tools to change keys individually.
Caution
It is important that you plan root key changes carefully. To change root keys, you will have to shut down the
database. Not only that, but if you change root keys at the wrong time, key information in the instance SSFS
and the database could become corrupt or inconsistent. This will render the database unusable or make
encrypted data inaccessible. Rectifying the problem could result in data loss. We recommend that you
contact SAP Support if errors related to inconsistent instance SSFS or encryption failure occur.
The following sections explain how and when you can safely change root keys. More detailed instructions are
available in the SAP HANA One Administration Guide.
SSFS Master Keys
Table 45:
How to Change
When to Change
Using the command line tool rsecssfx
The commands are: generatekey and changekey
Remember
You'll need operating system access (<sid>adm user) to
execute
rsecssfx commands.
For more information, see Change the SSFS Master Keys in
the SAP HANA One Administration Guide.
The initial default master keys are changed during installa
tion or update. If you received your system pre-installed
from a hardware or hosting partner, we recommend that
you change them immediately after handover to ensure that
they are not known outside of your organization.
You can change the master keys at any time.
SAP HANA One Security Guide
Data Storage Security in SAP HANA
P U B L I C 97
Data Volume Encryption Root Key
Table 46:
How to Change
When to Change
Using the command line tool hdbnsutil
The command is: generateRootKeys
type=PERSISTENCE
Remember
You'll need operating system access (<sid>adm user) to
execute
hdbnsutil commands.
Caution
After you change the root key with the command
generateRootKeys type=DPAPI, you must im
mediately reset the consistency information in the SSFS
using the SAP HANA tool
hdbcons.
For more information, see Enable Data Volume Encryption in
an Existing SAP HANA System in the SAP HANA One Admin
istration Guide.
You only need to change the data volume encryption root
key if you received SAP HANA pre-installed from a hardware
or hosting partner and you want to ensure it is not known
outside your organization.
If you want to change this key, ideally you do it after receipt
of your system but technically, you can change it any time
as long as data volume encryption is not enabled.
If encryption was enabled and has since been disabled, it is
important that the decryption process that happens after
disablement has fully completed before you generate a new
root key. Changing the root key while data is still encrypted
will render the SAP HANA database unusable. You can verify
the encryption status in the Security editor of the SAP
HANA studio or the Data Volume Encryption app of the SAP
HANA cockpit. All services must have the status
Unencrypted.
Caution
If system replication is configured, do not change the
data volume encryption root key on any system involved
(either as a primary or secondary system).
98
P U B L I C
SAP HANA One Security Guide
Data Storage Security in SAP HANA
Data Encryption Service Root Key
Table 47:
How to Change
When to Change
Using the command line tool hdbnsutil
The command is: generateRootKeys type=DPAPI
Remember
You'll need operating system access (<sid>adm user) to
execute
hdbnsutil commands.
Caution
After you change the root key with the command
generateRootKeys type=DPAPI, you must im
mediately do the following two things:
Reset the consistency information in the SSFS using
the SAP HANA tool hdbcons.
Change all application keys so that they are en
crypted with the new root key.
For more information, see Change the Data Encryption Serv
ice Root Key in the SAP HANA One Administration Guide.
You only need to change the data encryption service root
key if you received SAP HANA pre-installed from a hardware
or hosting partner and you want to ensure it is not known
outside your organization.
If you want to change this key, ideally you do it after receipt
of your system but at the latest before any data is encrypted
using the service. This means before you create any of the
following things:
A remote data source
A HTTP destination
An XS secure store
A certificate collection with a private key
You can use the following system views to see whether any
data has already been encrypted:
CREDENTIALS (PUBLIC)
If the credential store is empty, then this view will also
be empty.
P_DPAPI_KEY_ (SYS)
If there are no XS secure stores, then this view will have
no records with the caller XsEngine. If there are no
certificate collections with private keys, there will be no
records with the caller PSEStore. Only the user SYS
TEM can access this view.
Note
You can change the root keys for data volume encryption and the data encryption service together using
the hdbnsutil command generateRootKeys type=ALL. If you use this command, you must observe
the prerequisites and postrequisites stated above.
Related Information
SAP HANA One Administration Guide
SAP HANA One Security Guide
Data Storage Security in SAP HANA
P U B L I C 99
7.2 Data Volume Encryption
To protect data saved to disk from unauthorized access at operating system level, the SAP HANA database
supports data encryption in the persistence layer.
The SAP HANA database holds the bulk of its data in memory for maximum performance, but it still uses
persistent disk storage to provide a fallback in case of failure. Data is automatically saved from memory to disk
at regular savepoints. The data belonging to a savepoint represents a consistent state of the data on disk and
remains so until the next savepoint operation has completed. After a power failure, the database can be
restarted like any disk-based database and returns to its last consistent state.
Data volume encryption ensures that anyone who can access the data volumes on disk using operating system
commands cannot see the actual data. If data volumes are encrypted, all pages that reside in the data area on
disk are encrypted using the AES-256-CBC algorithm. Pages are transparently decrypted as part of the load
process into memory. When pages reside in memory they are therefore not encrypted and there is no
performance overhead for in-memory page accesses. When changes to data are persisted to disk, the relevant
pages are automatically encrypted as part of the write operation.
Pages are encrypted and decrypted using 256-bit page encryption keys. Page keys are valid for a certain range
of savepoints and can be changed by executing SQL statements. After data volume encryption has been
enabled, an initial page key is automatically generated. Page keys are never readable in plain text, but are
encrypted themselves using a dedicated persistence encryption root key.
During start-up, administrator interaction is not required. The data volume encryption root key is stored using
the secure storage in the file system (SSFS) functionality and is automatically retrieved from there. SAP HANA
uses the SSFS to protect the root encryption keys that are used to protect all encryption keys used in the SAP
HANA system from unauthorized access. Root keys are encrypted using the SSFS master key.
Enabling data volume encryption does not increase data size.
Data Not Encrypted
The data volume encryption feature does not encrypt the following data:
Database redo log files
If database redo log files need to be protected, we recommend using operating system facilities, such as
encryption at the file system level.
Database backups
The contents of database backups are not encrypted.
Note
To ensure that all data restored during the data and log recovery phases is encrypted, encryption must
be enabled before the recovery is started.
If encryption of backups is required, we recommend using third-party solutions that integrate with the
Backint for SAP HANA functionality for backups.
100
P U B L I C
SAP HANA One Security Guide
Data Storage Security in SAP HANA
Note
Unlike data backups, data in storage snapshots is encrypted. This is because a storage snapshot
captures the content of the data area exactly as it is at a particular point in time.
Database traces
For security reasons, we recommend that you do not run the system with extended tracing for more than
short-term analysis since tracing might expose security-relevant data that would be encrypted in the
persistence layer, but not in the trace. Therefore, you should not keep such trace files on disk beyond the
respective analysis task.
Periodic Administration Tasks
Depending on your security policy, we recommend periodically changing the page keys in order to limit the
potential impact of a key being compromised. A new page key will be active for new data as of the next
savepoint operation. The SAP HANA database provides system views that allow you to monitor encryption
status (M_PERSISTENCE_ENCRYPTION_STATUS), as well as the page keys used for data encryption and their
age (M_PERSISTENCE_ENCRYPTION_KEYS). An administrator can also trigger a re-encryption of the entire
data area using a newly-generated page key.
Administration tasks related to data volume encryption can be done in the Security editor of the SAP HANA
studio, the Data Volume Encryption app of the SAP HANA cockpit, or using the SQL system management
statement ALTER SYSTEM PERSISTENCE ENCRYPTION.
Related Information
Secure Storage in the File System (AS ABAP)
SAP HANA One Administration Guide
7.3 Secure Internal Credential Store
A database-internal credential store is available that allows you to securely store in the SAP HANA database
the credentials required by SAP HANA applications for outbound connections. For example, in an SAP HANA
smart data access scenario, in order to retrieve data, credentials are required to access a remote source.
Credentials can be created and updated by users and privileged administrators using the SQL interface.
However, access to credentials in unencrypted form is only available to native SAP HANA applications via an
internal API.
Users can create and modify their own credentials. A user with the system privilege CREDENTIAL ADMIN can
manage credentials for other users. Credentials are also created implicitly during the creation of remote data
sources (SAP HANA smart data access scenario) and HTTP destinations for SAP HANA XS applications.
SAP HANA One Security Guide
Data Storage Security in SAP HANA
P U B L I C 101
Credentials are created using the SQL statement CREATE CREDENTIAL as follows.
CREATE CREDENTIAL FOR USER <user_name> COMPONENT '<application>' PURPOSE
'<credential_purpose>' TYPE '<credential_type>' USING '<credential>'
A credential consists of the following elements:
Table 48:
Element
Description
User The database user for which the credential is stored
If no user name is specified, the supplied credential serves as a general entry that can be
used by the application if no explicit mapping for a database user is possible. For example,
in an SAP HANA smart data access scenario, the connection to a data source may always
be established using the same technical user.
Component
The application for which the credential is stored
The value of the 'component' element is defined by the application, for example, in an SAP
HANA smart data access scenario, the component is 'SAPHANAFEDERATION'.
Purpose The purpose for which the application is storing this credential
The value of the 'purpose' element is defined by the application, for example, in an SAP
HANA smart data access scenario, the purpose is the name of the remote data source.
Type The type of credential being stored, for example PASSWORD or X509
The supported values for the this element are specific to the application.
Using The actual credential, for example user name and password for a credential of type PASS
WORD
Note
You can only set credentials using SQL. It not possible to view them. The unencrypted
value of the credential is only available to the application via an internal interface.
Example
CREATE CREDENTIAL FOR USER TESTUSER COMPONENT 'SAPHANAFEDERATION' PURPOSE 'ASE'
TYPE 'PASSWORD' USING 'user="remotedbuser";password="abc123"'
Credentials can be changed and dropped using the ALTER CREDENTIAL and DROP CREDENTIAL statements
respectively.
The system view CREDENTIALS contains information about stored credentials.
Note
Credentials stored using the credential store remain encrypted even in backups. To allow for the
reconstruction of credential data in the case of database recovery, the encryption key used is also part of
the backup. To avoid unauthorized access to the encrypted credentials, backups should be stored in a safe
and secure place.
102
P U B L I C
SAP HANA One Security Guide
Data Storage Security in SAP HANA
Note
The credential store uses the data encryption service of the SAP HANA database. The root encryption key
for this data encryption service is stored in the secure store in the file (SSFS) system along with the root
encryption key used for data volume encryption (if activated). During a recovery, the root encryption key for
the data encryption service is restored to the target system's SSFS without interfering with the root
encryption key for data volume encryption of the target system.
Related Information
Server-Side Data Encryption [page 93]
Encryption Key Management [page 97]
SAP HANA SQL and System Views Reference
SAP HANA Developer Guide (For SAP HANA Studio)
7.4 Protection of Data in SAP HANA Studio Workspaces
When users are working in the SAP HANA studio, data is copied to workspaces on their local disk for editing.
This data requires additional protection.
In the SAP HANA studio, data is copied to the following workspaces on the local disks of users:
Eclipse workspace
When the SAP HANA studio is installed, a local workspace is created by default in the user's home
directory in the hdbstudio sub-directory. This workspace contains for example, the connection details of
SAP HANA systems that the user adds in the SAP HANA studio, as well as other configuration data.
It is possible to change the location of this directory using the standard Eclipse Switch Workplace feature.
SAP HANA repository workspaces
In the SAP HANA Development perspective of the SAP HANA studio, content and application developers
create repository workspaces in a local directory. This allows them to work on local copies of design-time
objects from an SAP HANA repository.
To ensure that only the user can access the data in workspaces, workspaces must be created in the user's
home directory. In addition, it is recommended that users encrypt the data on their hard drives using an
encryption tool.
Users must delete their workspaces when they uninstall the SAP HANA studio.
SAP HANA One Security Guide
Data Storage Security in SAP HANA
P U B L I C 103
8 Auditing Activity in SAP HANA Systems
Auditing provides you with visibility on who did what in the SAP HANA database (or tried to do what) and
when.
Auditing allows you to monitor and record selected actions performed in the SAP HANA database. Although
auditing does not directly increase your system's security, if wisely designed, it can help you achieve greater
security in the following ways:
Uncover security holes if too many privileges were granted to some user
Show attempts to breach security
Protect the system owner against accusations of security violations and data misuse
Allow the system owner to meet security standards
The following actions are typically audited:
Changes to user authorization
Creation or deletion of database objects
Authentication of users
Changes to system configuration
Access to or changing of sensitive information
Constraints
Only actions that take place inside the database engine can be audited. If the database engine is not online
when an action occurs, it cannot be detected and therefore cannot be audited.
This is important to bear in mind in the following cases:
Upgrade of a SAP HANA database instance
Upgrade is triggered when the instance is offline. When it becomes available online again, it is not possible
to determine which user triggered the upgrade and when.
Direct changes to system configuration files using operating system commands
Only changes that are made using SQL are visible to the database engine. It is also possible to change
configuration files when the system is offline.
8.1 Audit Policies
An audit policy defines the actions to be audited, as well as the conditions under which the action must be
performed to be relevant for auditing. When an action occurs, the policy is triggered and an audit event is
written to the audit trail. Audit policies are database specific.
104
P U B L I C
SAP HANA One Security Guide
Auditing Activity in SAP HANA Systems
Audited Actions
An action corresponds to the execution of an action in the database by SQL statement. For example, you want
to track user provisioning in your system, so you create an audit policy that audits the execution of the SQL
statements CREATE USER and DROP USER.
Although most actions correspond to the execution of a single SQL statement, some actions can cover the
execution of multiple SQL statements. For example, the action GRANT ANY will audit the granting of multiple
entities on the basis of the SQL statements GRANT PRIVILEGE, GRANT ROLE, GRANT STRUCTURED
PRIVILEGE, and GRANT APPLICATION PRIVILEGE.
An audit policy can specify any number of actions to be audited, but not all actions can be combined together
in the same policy. Actions can be grouped in the following main ways:
All auditable actions
You can include all actions performed by a specific user in a single policy. This covers not only all other
actions that can be audited individually but also actions that cannot otherwise be audited. Such a policy is
referred to as a firefighter policy and is useful if you want to audit the actions of a particularly privileged
user.
Caution
The actions that are audited are limited to those that take place inside the database engine while it is
running. Therefore, system restart and system recovery will not be audited.
Data manipulation actions (DML)
You can include any actions that involve data manipulation together in a single policy, for example actions
that audit SELECT, INSERT, UPDATE, DELETE, and EXECUTE statements on database objects. A policy
that includes these actions requires at least one target object that allows the actions in question. This type
of policy is useful if you want to audit a particularly critical or sensitive database object.
Data definition actions (DDL)
Other action types, for example actions that involve data definition, can only be combined together in a
single policy if they are compatible. For example, the action GRANT PRIVILEGE can be combined with
REVOKE PRIVILEGE but not with CREATE USER. The action CREATE USER can be combined with DROP
USER.
For a full list of all actions that can be audited, see the documentation for SQL access control statement
CREATE AUDIT POLICY in the SAP HANA SQL and Systems View Reference.
Audit Policy Parameters
In addition to the actions to be audited, an audit policy specifies parameters that further narrow the number of
events actually audited.
Audited action status
For each audit policy, it must be specified when the actions in the policy are to be audited:
On successful execution
On unsuccessful execution
On both successful and unsuccessful execution
SAP HANA One Security Guide
Auditing Activity in SAP HANA Systems
P U B L I C 105
Note
An unsuccessful attempt to execute an action means that the user was not authorized to execute the
action. If another error occurs (for example, misspellings in user or object names and syntax errors),
the action is generally not audited. In the case of actions that involve data manipulation (that is,
INSERT, SELECT, UPDATE, DELETE, and EXECUTE statements), additional errors (for example,
invalidated views) are audited.
Target object(s)
Actions that involve data manipulation require at least one target object. The following target object types
are possible:
Schemas (and all objects contained within)
Tables
Views
Procedures
Target objects are specified at the level of audit policy, so if an audit policy contains several data
manipulation actions, the target object must be valid for all actions in the policy. In the case of the action
EXECUTE, the only valid target object is procedure. The reverse is also true: the only valid action for
procedures is EXECUTE. This means that the action EXECUTE cannot be combined with any other actions.
An object does not have to exist before it can be named as the target object of an audit policy. However, if
the object does not exist, it cannot be audited by the audit policy. When an object with the specified name
is subsequently created, the audit policy will apply for the object, assuming it is of a type that can be
audited and the audited action applies to that object type. For example, if the audited action is EXECUTE,
the subsequently created object must be a procedure.
Audited user(s)
It is possible to specify that the actions in the policy be audited only when performed by a particular user
or users. Alternatively, you can specify that the actions in the policy be audited when performed by all
users except a particular user or users. In the case of a policy that contains all auditable actions, a user
must be specified.
Users do not have to exist before they can be named in an audit policy. However, if a specified user does
not exist, it cannot be audited by the audit policy. When the user is subsequently created, the audit policy
will apply for the user.
Audit level
Each audit policy must be assigned one of the following levels:
EMERGENCY
ALERT
CRITICAL
WARNING
INFO
When the audit policy is triggered, an audit entry of the corresponding level is written to the audit trail. This
allows tools checking audited actions to find the most important information, for example.
Policy-Specific Audit Trail Target(s)
You can optionally configure one or more policy-specific audit trail targets. If you do not configure a policy-
specific audit trail target, audit entries generated by the policy are written to the audit trail target for the audit
level of the policy if configured, or the audit trail target configured for the system.
106
P U B L I C
SAP HANA One Security Guide
Auditing Activity in SAP HANA Systems
If an action is audited by multiple audit polices and these audit policies have different audit trail targets, the
audit entry is written to all trail targets.
For more detailed information about audit trails, see Audit Trails.
Related Information
Audit Trails [page 109]
System Properties for Configuring Auditing [page 114]
8.1.1 Actions Audited by Default Audit Policy
If auditing is active, certain actions are always audited and are therefore not available for inclusion in user-
defined audit polices. These action are audited by the internal audit policy MandatoryAuditPolicy.
The actions listed below are always audited and result in audit entries with the audit level CRITICAL. Audit
entries are written to the audit trail configured for this audit level. If no audit trail is configured for this audit
level, entries are written to the audit trail configured for the system.
Table 49:
Action
Description
CREATE AUDIT POLICY
ALTER AUDIT POLICY
DROP AUDIT POLICY
Creation, modification, or deletion of audit policies
ALTER SYSTEM CLEAR AUDIT LOG UNTIL
<timestamp>
Deletion of audit entries from the audit trail
This only applies to the audit trail written to an internal data
base table. It is not possible to delete audit entries from the
syslog audit trail target.
SAP HANA One Security Guide
Auditing Activity in SAP HANA Systems
P U B L I C 107
Action Description
ALTER SYSTEM ALTER CONFIGURATION
('global.ini','SYSTEM') set
('auditing
configuration','global_auditing_state
') = <value> with reconfigure;
ALTER SYSTEM ALTER CONFIGURATION
('global.ini','SYSTEM') set
('auditing
configuration','default_audit_trail_t
ype' ) = '
<audit_trail_type>' with
reconfigure;
ALTER SYSTEM ALTER CONFIGURATION
('global.ini','SYSTEM') set
('auditing
configuration','default_audit_trail_p
ath') = '
<path>' with reconfigure;
Changes to auditing configuration, that is:
Enabling or disabling auditing
Changing the audit trail target
Changing the location of the audit trail target if it is a
CSV text file
108 P U B L I C
SAP HANA One Security Guide
Auditing Activity in SAP HANA Systems
8.2 Audit Trails
When an audit policy is triggered, that is, when an action in the policy occurs under the conditions defined in
the policy, an audit entry is created in one or more audit trails.
Audit Trail Types
The following audit trail targets are supported for production systems:
Table 50:
Audit Trail Target
Description
Logging system of the Linux operating
system (syslog)
The syslog is a secure storage location for the audit trail because not even the
database administrator can access or change it. There are also numerous stor
age possibilities for the syslog, including storing it on other systems. In addition,
the syslog is the default log daemon in UNIX systems. The syslog therefore pro
vides a high degree of flexibility and security, as well as integration into a larger
system landscape. For more information about how to configure syslog, refer to
the documentation of your operating system.
Caution
If the syslog daemon cannot write the audit trail to its destination, you will not
be informed. To avoid a situation in which audited actions are occurring but
audit entries are not being written to the audit trail, ensure that the syslog is
properly configured and that the audit trail target is accessible and has suffi
cient space available.
Internal database table
Using an SAP HANA database table as the target for the audit trail makes it pos
sible to query and analyze auditing information quickly. It also provides a secure
and tamper-proof storage location. Audit entries are only accessible through the
public system view AUDIT_LOG. Only SELECT operations can be performed on
this view by users with the system privilege AUDIT OPERATOR or AUDIT ADMIN.
To avoid the audit table growing indefinitely, it is possible to delete old audit en
tries by truncating the table. The system monitors the size of the table with re
spect to the overall memory allocation limit of the system and issues an alert
when it reaches defined values (by default 5%, 7%, 9%, and 11% of the allocation
limit). This behavior can be configured with check 64 ("Total memory usage of
table-based audit log"). Only users with the system privilege AUDIT OPERATOR
can truncate the audit table.
Additionally, the option exists to store the audit trail in a CSV text file. This should only be used for test
purposes in non-production systems. A separate CSV file is created for every service that executes SQL.
Caution
You must not use a CSV text file for a production system as it has severe restrictions. Firstly, it is not
sufficiently secure. By default, the file is written to the same directory as trace files (/usr/sap/<sid>/
<instance>/<host>/trace). This means that database users with the system privilege DATA ADMIN,
SAP HANA One Security Guide
Auditing Activity in SAP HANA Systems
P U B L I C 109
CATALOG READ, TRACE ADMIN, or INIFILE ADMIN can access it. In the Administration editor of the SAP
HANA studio, it is listed on the Diagnosis Files tab, and at operating system level, any user in the SAPSYS
group can access it. Secondly, audit trails are created for each server in a distributed database system. This
makes it more difficult to trace audit events that were executed across multiple servers (distributed
execution).
Multiple Audit Trails
When you enable auditing, you must specify an audit trail target for the system. In addition, you can configure
separate audit trail targets based on the severity of the action being audited, that is the audit level.
Audit entries from audit policies with the audit level EMERGENCY, CRITICAL, or ALERT are written to the audit
trail target(s) specified for the audit level in question. If no audit trail target is configured for an audit level,
entries are written to the audit trail target configured for the system.
Audit policy-specific targets are also possible. In this case, audit entries from a particular policy are written to
the specified audit trail target(s). If no audit trail target is configured for an audit policy, entries are written to
the audit trail target for the audit level if configured, or the audit trail target configured for the system. Several
audit trail targets are configurable for each individual policy.
Audit Entry Layout
For each occurrence of an audited action, one or more audit entries are created and written to the configured
audit trail(s).
The layout of audit entries varies depending on the audit trail type.
Example
If an action that involves data manipulation was executed implicitly by a procedure, the call to this
procedure is audited together with the audited action. If the action does not involve data manipulation, then
an implicitly executed procedure is not audited. For example, if there is an active audit policy that audits the
action of creating users, the execution of CREATE USER statements within procedures will be audited but
not the procedures themselves.
110
P U B L I C
SAP HANA One Security Guide
Auditing Activity in SAP HANA Systems
8.2.1 Audit Trail Layout for Trail Target CSV and SYSLOG
For each occurrence of an audited action, one or more audit entries are created and written to the audit trail.
The layout of audit entries varies depending on the audit trail type.
The following table describes the layout of the audit trail when either the syslog or a CSV text file is the trail
target:
Table 51:
Field
Description Example
Event Timestamp Local system time of event occur
rence
2012-09-19 15:44:53
Service Name Name of the service where the ac
tion occurred
Indexserver
Hostname Name of the host where the action
occurred
myhanablade23.customer.corp
SID System ID
HDB
Instance Number Instance number
00
Port Number Port number
30003
Client IP Address IP address of the client application 127.0.0.2
Client Name Name of the client machine lu241511
Client Process ID Process ID of the client process 19504
Client Port Number Port of the client process 47273
Policy Name Audit policy that was triggered AUDIT_GRANT, MandatoryAuditPolicy
Audit Level Severity of audited action CRITICAL
Audit Action Action that was audited and thus
triggered the policy
GRANT PRIVILEGE
Active User User who performed the action MYADMIN
Target Schema Name of the schema where the ac
tion occurred, for example, a privi
lege was granted on a schema, or a
statement was executed on object
in a schema
PRIVATE
Target Object Name of the object on which an ac
tion was performed, for example, a
privilege was granted
HAXXOR
Privilege Name Name of the privilege that was
granted or revoked
SELECT
Grantable Indication of whether the privilege
or role was granted with or without
GRANT/ADMIN OPTION
NON GRANTABLE
SAP HANA One Security Guide
Auditing Activity in SAP HANA Systems
P U B L I C 111
Field Description Example
Role Name Name of the role that was granted
or revoked
MONITORING
Target Principal Name of the target user of the ac
tion, for example, grantee in a
GRANT statement
HAXXOR
Action Status Execution status of the statement SUCCESSFUL
Component Name of the configuration file in
which a parameter value was
changed
indexserver.ini
Section Name of the configuration file sec
tion in which a parameter value was
changed
auditing_configuration
Parameter Name of the configuration parame
ter whose value was changed
global_auditing status
Old Value Previous value of the parameter CSVTEXTFILE
New Value New parameter value CSTABLE
Comment Additional information about failed
user connection attempts
user is locked
Currently in case of failed logon attempts, the
reason for failure appears in this field.
Executed Statement Statement that was executed GRANT SELECT ON SCHEMA PRIVATE TO
HAXXOR
Session ID ID of the session in which the state
ment was executed
400006
Application user name Application user name A099999
Caution
Treat this information with caution. It
comes from the application and SAP HANA
has no way of verifying its authenticity.
Example
2013-11-30 13:04:54;indexserver;myhanablade23.customer.corp;HAN;
01;30103;10.29.14.177;lu306309;6776;58060;Alter User Policy;INFO;ALTER
USER;SYSTEM;;;;;;ADAMS;SUCCESSFUL;;;;;;alter user ADAMS VAXXXXXXXXXXXXX;434597;
112
P U B L I C
SAP HANA One Security Guide
Auditing Activity in SAP HANA Systems
8.2.2 Audit Trail Layout for Trail Target Database Table
For each occurrence of an audited action, one or more audit entries are created and written to the audit trail.
The layout of audit entries varies depending on the audit trail type.
The follwoing table below describes the layout of the audit trail when the column store database table is the
trail target:
Table 52:
Column
Data Type Description
TIMESTAMP TIMESTAMP Time of event occurrence (in system local time)
HOST VARCHAR(64) Name of the host where the action occurred
PORT INTEGER Port number
SERVICE_NAME VARCHAR(32) Name of the service where the action occurred
CONNECTION_ID INTEGER ID of the session in which the statement was executed
CLIENT_HOST VARCHAR(64) Name of the client machine
CLIENT_IP VARCHAR(16) IP address of the client application
CLIENT_PID BIGINT Process ID of the client process
CLIENT_PORT INTEGER Port of the client process
USER_NAME NVARCHAR(256) User who performed the action
APPLICATION_USER_NAME NVARCHAR(256) Application user who performed the action
Caution
Treat this information with caution. It comes from the ap
plication and SAP HANA has no way of verifying its au
thenticity.
AUDIT_POLICY_NAME
NVARCHAR(256) Audit policy that was triggered
EVENT_STATUS VARCHAR(32) Execution status of the statement
EVENT_LEVEL VARCHAR(16) Severity of audited action
EVENT_ACTION VARCHAR(32) Action that was audited and thus triggered the policy
SCHEMA_NAME NVARCHAR(256) NULL Name of the schema where the action occurred, for exam
ple, a privilege was granted on a schema, or a statement
was executed on object in a schema
OBJECT_NAME NVARCHAR(256) NULL Name of the object on which an action was performed, for
example, a privilege was granted
PRIVILEGE_NAME NVARCHAR(256) NULL Name of the privilege that was granted or revoked
ROLE_NAME NVARCHAR(256) NULL Name of the role that was granted or revoked
GRANTEE NVARCHAR(256), NULL Name of the target user of the action, for example, grantee
in a GRANT statement
GRANTABLE VARCHAR(16), NULL Indication of whether the privilege or role was granted with
or without GRANT/ADMIN OPTION
SAP HANA One Security Guide
Auditing Activity in SAP HANA Systems
P U B L I C 113
Column Data Type Description
FILE_NAME VARCHAR(256), NULL Configuration file name, for example global.ini
SECTION VARCHAR(128), NULL Configuration section name, for example auditing configura
tion
KEY VARCHAR(128), NULL Configuration parameter, for example
global_auditing_state
PREV_VALUE VARCHAR(5000), NULL Previous value of the parameter, for example CSVTEXTFILE
VALUE VARCHAR(5000), NULL New parameter value, for example CSTABLE
STATEMENT_STRING NCLOB, NULL Statement that was executed
COMMENT VARCHAR(5000) NULL Additional information about the audited event
Note
Currently in case of failed logon attempts, the reason for
failure appears in this field.
8.3 Auditing Configuration and Audit Policy Management
To audit database activity, auditing must first be enabled in the system, and if necessary audit trails
configured. It is then possible to create and activate the required audit policies. Audit policies can also be
deactivated and reactivated later, or deleted altogether.
You configure auditing and manage auditing policies in the Security editor of the SAP HANA studio. The SAP
HANA cockpit also provides read-only access to this information. The underlying system properties are in the
auditing configuration section of the global.ini system properties file.
Related Information
SAP HANA SQL and System Views Reference
SAP HANA One Administration Guide
8.3.1 System Properties for Configuring Auditing
The system properties for configuring auditing are in the auditing configuration section of the
global.ini system properties file.
The following system properties are used to configure auditing. It is recommended that you not edit these
properties directly, but use the Security editor of the SAP HANA studio instead.
114
P U B L I C
SAP HANA One Security Guide
Auditing Activity in SAP HANA Systems
Table 53:
System Property Value Default Value Description
global_auditing_sta
te
<Boolean value>
false Activation status of auditing
in the system
default_audit_trail
_type
{SYSLOGPROTOCOL |
CSTABLE | CSVTEXTFILE}
SYSLOGPROTOCOL if
global_auditing_state is true
Default audit trail target of
the database
default_audit_trail
_path
<file>
/usr/sap/<sid>/
<instance>/<host>/
trace if
default_audit_trail
_type
is CSVTEXTFILE
The file path of audit trail tar
get CSVTEXTFILE
emergency_audit_tra
il_type
{SYSLOGPROTOCOL |
CSTABLE | CSVTEXTFILE}
-- Audit trail target to which au
dit entries from audit policies
with the audit level EMER
GENCY are written
alert_audit_trail_t
ype
{SYSLOGPROTOCOL |
CSTABLE | CSVTEXTFILE}
-- Audit trail target to which au
dit entries from audit policies
with the audit level ALERT
are written
critical_audit_trai
l_type
{SYSLOGPROTOCOL |
CSTABLE | CSVTEXTFILE}
-- Audit trail target to which au
dit entries from audit policies
with the audit level CRITICAL
are written
Example
Configure Multiple Audit trails per Audit Level
ALTER SYSTEM ALTER CONFIGURATION ('global.ini','SYSTEM') set ('auditing
configuration', 'emergency_audit_trail_type' ) = 'CSTABLE,SYSLOGPROTOCOL' with
reconfigure;
ALTER SYSTEM ALTER CONFIGURATION ('global.ini','SYSTEM') set ('auditing
configuration', 'alert_audit_trail_type' ) = 'CSTABLE,SYSLOGPROTOCOL' with
reconfigure;
ALTER SYSTEM ALTER CONFIGURATION ('global.ini','SYSTEM') set ('auditing
configuration', 'critical_audit_trail_type' ) = 'CSTABLE,SYSLOGPROTOCOL' with
reconfigure;
8.4 Best Practices for Creating Audit Policies
To reduce the performance impact of auditing, some basic guidelines for creating audit policies apply.
Create as few audit policies as possible. It's usually better to have one complex policy than several simple
ones.
SAP HANA One Security Guide
Auditing Activity in SAP HANA Systems
P U B L I C 115
Note
Some audit actions can't be combined in the same policy.
Use audit actions that combine other actions where possible.
Example
Audit the GRANT ANY action instead of the GRANT PRIVILEGE and the GRANT STRUCTURED
PRIVILEGE actions.
Create audit policies for DML actions only if required. Auditing DML actions impacts performance more
than auditing DDL actions.
Don't create audit policies for actions that are automatically audited, for example CREATE AUDIT
POLICY. For a list of actions that are always audited, see Actions Audited by Default Audit Policy in the SAP
HANA One Security Guide.
Don't create audit policies for database-internal tables that are involved in administration actions. Create
policies for the administration actions themselves.
Example
C_P_USER_PASSWORD and P_USER_PASSWORD are internal database tables that cannot be accessed by
any user, not even SYSTEM. Changes in these tables are carried out by internal mechanisms, and not
by DML operations. Don't included these tables in an audit policy. Instead create an audit policy for
changes to users (ALTER USER action) instead.
Related Information
Actions Audited by Default Audit Policy [page 107]
SAP HANA One Security Guide
116
P U B L I C
SAP HANA One Security Guide
Auditing Activity in SAP HANA Systems
9 Certificate Management in SAP HANA
SAP HANA uses X.509 client certificates as the basis for securing internal and external communication
channels, as well as for several user authentication mechanisms. Certificates can be stored and managed in
files in the file system and in some cases directly in the SAP HANA database.
Certificate Management in the Database
All certificate-based user authentication mechanisms in SAP HANA, as well as secure communication between
SAP HANA and clients that access the SQL interface of the database rely on X.509 client certificates for
authentication and verifying digital signatures. For ease of management, it's possible to store these
certificates and configure their usage directly in the SAP HANA database.
The following figure shows a typical certificate management workflow. A full separation of duties is possible
through user authorization. For more information, see
SQL Statements and Authorization for In-Database
Certificate Management.
Figure 7: Certificate Management Workflow
SAP HANA One Security Guide
Certificate Management in SAP HANA
P U B L I C 117
You can manage certificates in the SAP HANA cockpit.
Note
Roles are required to access the certificate management apps of the SAP HANA cockpit. The privileges for
certificate management indicated above are partially included in these roles.
Certificate Management in the File System
Although we recommend using in-database storage, it is possible to store and manage the certificates
required for certificate-based user authentication and secure client-server communication in trust and key
stores located in the file system.
The certificates required to secure all internal communication channels and HTTP client access using SAP
Web Dispatcher are contained in files located in the file system. In-database storage of certificates for these
communication channels is not supported. Do not delete these files from the file system.
For more information about how to configure the usage of trust and key stores in the file system, see Server-
Side SSL Configuration Properties for External Communication in the SAP HANA One Security Guide.
Overview of Certificate Handling
Table 54:
Certificates can be stored for…
...in the database ...in the file system
Secure client-server communication over JDBC/ODBC Yes Yes
Server client-server communication over HTTP No Yes
Secure internal communication No Yes
User authentication (SAML assertions, SAP logon and as
sertion tickets, X.509 certificates)
Yes Yes
Related Information
SSL Configuration on the SAP HANA Server [page 19]
SQL Statements and Authorization for In-Database Certificate Management [page 121]
Server-Side TLS/SSL Configuration Properties for External Communication (JDBC/ODBC) [page 20]
SAP HANA One Administration Guide
118
P U B L I C
SAP HANA One Security Guide
Certificate Management in SAP HANA
9.1 Client Certificates
X.509 client certificates required for certificate-based authentication and secure communication between
SAP HANA and clients that access the SQL interface of the database can be stored and managed directly in
the SAP HANA database.
Certificates stored in the SAP HANA database can be used for:
Trust validation
Certificates used for trust validation are the public-key certificates of trusted communication partners or
root certificates from trusted Certification Authorities. These certificates contain the public part of a
user's or component's public and private key pair.
Server authentication
Certificates used for server authentication are the public-key certificates of the SAP HANA server used to
identify the server to connecting clients. In addition to the public-key information of the server, these
certificates contain the server's private keys, as well as the intermediate certificates that complete the
trust chain from the server certificate to the root certificate that the communication partner (client)
trusts.
Note
Private keys are stored securely using the internal data encryption service of the SAP HANA database.
For more information, see Server-Side Data Encryption in the SAP HANA One Security Guide.
Once they have been imported into the database, certificates can be assigned to certificate collections.
Certificate collections are also created and managed directly in the database, where they serve a unique
purpose (either secure client-server communication or a certificate-based authentication mechanism).
Note
Although we recommend creating and managing both certificates and certificate collections in the
database, files containing certificates may also be stored in the file system.
Related Information
Certificate Collections [page 119]
Server-Side Data Encryption [page 93]
9.2 Certificate Collections
A certificate collection (also referred to as a personal security environment or PSE) is a secure location where
the public information (public-key certificates) and private information (private keys) of the SAP HANA server
are stored. A certificate collection may also contain the public information (public-key certificates) of trusted
communication partners or root certificates from trusted Certification Authorities.
SAP HANA One Security Guide
Certificate Management in SAP HANA
P U B L I C 119
Certificate collections can be created and managed as database objects directly in the SAP HANA database.
Note
Although we recommend creating and managing both certificates and certificate collections in the
database, files containing certificates may also be stored in the file system.
Certificate collections uniquely serve one of the following purposes in the database in which they exist:
User authentication based on:
SAML assertions
X.509 certificates
Logon and assertion tickets
Client-server communication over JDBC/ODBC secured using the Secure Sockets Layer (SSL) protocol
Only one certificate collection may serve one of these purposes at any given time.
The client certificates required for each purpose are assigned to the corresponding certificate collection from
the in-database certificate store. A certificate can be assigned to more than one certificate collection.
Certificates used for server authentication, that is certificates that include the private key of the server, need
only be assigned to the certificate collection used for secure client-server communication.
Ownership of Certificate Collections
A certificate collection is a database object created in runtime. It is therefore owned by the database user who
creates it. If a certificate collection is in use, in other words it has been assigned one of the above purposes, it
is not possible to change it (for example, add or remove certificates) or to delete it. However, if the owner of
the certificate collection is deleted, the certificate collection will be deleted even if it currently in use.
Caution
The deletion of a certificate collection that is assigned a purpose could render the database unusable. For
example, if SSL is being enforced for all client connections and the certificate collection used for SSL is
deleted, no new client connections to the database can be opened.
Related Information
SAP HANA Authentication and Single Sign-On [page 43]
Secure Communication Between SAP HANA and JDBC/ODBC Clients [page 18]
120
P U B L I C
SAP HANA One Security Guide
Certificate Management in SAP HANA
9.3 SQL Statements and Authorization for In-Database
Certificate Management
All administration tasks related to in-database certificate management can be performed using SQL.
The following table lists the SQL statements for creating and managing certificates and certificate collections
in the SAP HANA database, including the required authorization for each task.
Note
Certificate collections are referred to as personal security environments (PSEs) in back-end terminology.
Table 55:
To...
Execute the Statement... With the Authorization...
See certificates in the in-database cer
tificate store
SELECT * FROM CERTIFICATES
Note
You can also view certificates using
the Certificate Store app of the SAP
HANA cockpit.
System privilege CERTIFICATE ADMIN
or TRUST ADMIN
If you have object privilege ALTER on a
certificate collection, you'll also be able
to see the certificates used in this col
lection.
See which certificates are used in a cer
tificate collection
SELECT * FROM
PSE_CERTIFICATES
Note
You can also see this information in
the Certificate Store app of the SAP
HANA cockpit.
Object privilege ALTER, DROP, or REF
ERENCES on the certificate collection
Add a certificate to the in-database cer
tificate store
CREATE CERTIFICATE FROM
<certificate_content>
[ COMMENT <comment> ]
System privilege CERTIFICATE ADMIN
Delete a certificate from the in-data
base certificate
Note
If the certificate has already been
added to a certificate collection, it
can't be deleted.
DROP CERTIFICATE
<certificate_id>
System privilege CERTIFICATE ADMIN
SAP HANA One Security Guide
Certificate Management in SAP HANA
P U B L I C 121
To... Execute the Statement... With the Authorization...
View certificate collections in the data
base, including the certificates they
contain
SELECT * FROM
PSE_CERTIFICATES
Note
You can also view certificate collec
tions using the Certificate Collection
app of the SAP HANA cockpit.
System privilege CATALOG READ and
either TRUST ADMIN, USER ADMIN, or
SSL ADMIN
Note
If you own a certificate collection or
you have the object privilege ALTER,
DROP, or REFERENCES on a certifi
cate collection, you'll be able to see
it without the above privileges.
Create a certificate collection
CREATE PSE <PSE_name>
System privilege TRUST ADMIN
Add a public-key certificate to a certifi
cate collection
ALTER PSE <PSE_name> ADD
CERTIFICATE
<certificate_id>
Nothing if you're the owner of the
certificate collection
Object privilege ALTER on the cer
tificate collection if you're not the
owner
Remove a public-key certificate from a
certificate collection
Note
If the purpose of the certificate col
lection already been set, then sys
tem privilege USER ADMIN or SSL
ADMIN is additionally required de
pending on whether the purpose is
user authentication or secure com
munication.
ALTER PSE <PSE_name> DROP
CERTIFICATE
<certificate_id>
Add a private key to a certificate collec
tion
ALTER PSE <PSE_name> SET
OWN CERTIFICATE
<certificate_content>
Nothing if you're the owner of the
certificate collection
Object privilege ALTER on the cer
tificate collection if you're not the
owner
Set the purpose of a certificate collec
tion
Note
If the purpose of the PSE is SSL,
then it must already have a private
key added.
SET PSE <PSE_name> PURPOSE
<PSE_purpose>
The following PSE purposes are possi
ble:
SAML
SAP LOGON
X509
SSL
System privilege USER ADMIN or
SSL ADMIN if you're the owner of
the certificate collection
USER ADMIN is needed if the pur
pose of the certificate collection is
user authentication (SAML, X.509,
or logon tickets), and SSL ADMIN
is required if the purpose is secure
client-server communication
(SSL)
Object privilege REFERENCES on
the certificate collection and sys
tem privilege USER ADMIN or SSL
ADMIN if you're not the owner of
the certificate collection
122 P U B L I C
SAP HANA One Security Guide
Certificate Management in SAP HANA
To... Execute the Statement... With the Authorization...
Unset the purpose of a certificate col
lection
UNSET PSE <PSE_name>
PURPOSE <PSE_purpose>
System privilege SSL ADMIN if the
purpose is secure client-server
communication (SSL)
System privilege USER ADMIN for
all other purposes
Delete a certificate collection
Note
If the certificate collection has al
ready been assigned a purpose, it
can't be deleted.
DROP PSE <PSE_name>
Nothing, if you're the owner of the
certificate collection
Object privilege DROP on the cer
tificate collection, if you're not the
owner
For more information, see SAP HANA SQL and System Views Reference on SAP Help Portal.
SAP HANA One Security Guide
Certificate Management in SAP HANA
P U B L I C 123
10 Security Risks of Trace and Dump Files
In exceptional situations, the data output in trace and dump files may expose certain security-relevant data.
Trace files are used to troubleshoot problems in the SAP HANA database. Dump files containing useful
information for error analysis may also be created. Under normal circumstances, security-relevant data is not
written to the files. However, if the default configuration is changed, for example when a trace is activated with
a high trace level in a support situation, query strings including WHERE clause restrictions are written to trace
files, for example, the database trace file of the index server. Query result sets and information about users
may be output.
Note
Passwords are never output.
The following files may contain security-relevant data:
Trace files generated through the activation of the following trace types:
SQL trace
Database trace, including user-specific and end-to-end traces
Expensive statement trace
Performance trace
Dump files
Core dump files (for example, crash dump files)
The system generates these files automatically.
Runtime dump files
The generation of these files can be triggered using the command line tool hdbcons.
Related Information
SAP HANA One Administration Guide
124
P U B L I C
SAP HANA One Security Guide
Security Risks of Trace and Dump Files
11 SAP HANA Content
SAP HANA is delivered with a set of preinstalled software components implemented as SAP HANA Web
applications, libraries, and configuration data. These components are developed on SAP HANA Extended
Services (SAP HANA XS), classic model, and together with other configuration components are referred to as
SAP HANA content.
Software components delivered as SAP HANA content are an integral part of the SAP HANA platform. They
provide essential features for Web-based configuration, administration and monitoring, application lifecycle
management, and supportability.
Installation and Update
SAP HANA content is contained in delivery units (DUs). DUs containing automated content are deployed after
the core SAP HANA database engine is started up during platform installation or upgrade and every time a
new logical SAP HANA database is created. During an upgrade of an SAP HANA platform instance, the
software components are updated to the version residing on the installation medium. DUs containing non-
automated content need to be manually imported into the SAP HANA repository by a system administrator.
DUs containing non-automated content are also automatically updated during an upgrade of an SAP HANA
platform instance. For more information importing DUs, see Deploy a Delivery Unit Archive (*.tgz) in the SAP
HANA Master Guide.
Content Security
Several software components available as SAP HANA content are Web applications and are therefore
intended to be accessed by users through a Web browser. Only authenticated SAP HANA database users who
have been explicitly authorized to use these software components by a user administrator can access them
from their Web browser. The privileges required to use a software component are contained within roles
delivered with the component itself. No user has these roles initially.
Users are authenticated and authorization checks are performed by the standard authentication and
authorization mechanisms implemented by SAP HANA XS.
It is therefore guaranteed that no functionality is provided to or exposed to any user after a plain installation or
upgrade.
More Information
For a list of all software components installed as SAP HANA content, including a detailed description of their
purpose and functional scope, see the section Components Delivered as SAP HANA Content. The roles
SAP HANA One Security Guide
SAP HANA Content
P U B L I C 125
required to use each component are also listed with information about which functionality is made available by
which role.
Related Information
Components Delivered as SAP HANA Content [page 126]
11.1 Components Delivered as SAP HANA Content
The following sections provide the technical details, key features, and roles of all software components
delivered with the SAP HANA platform as content.
For more information about what SAP HANA content is, see SAP HANA Content.
Related Information
SAP HANA Content [page 125]
11.1.1 Administration
SAP HANA content related to system and database administration
HANA_ADMIN [page 127]
HANA_BACKUP [page 128]
HANA_HDBLCM [page 129]
HANA_SEC_BASE [page 130]
HANA_SEC_CP [page 132]
HANA_SYS_ADMIN [page 133]
HANA_XS_BASE [page 134]
126
P U B L I C
SAP HANA One Security Guide
SAP HANA Content
11.1.1.1 HANA_ADMIN
This component provides Web applications required for the effective administration and monitoring of the SAP
HANA platform in both production and non-production environments.
Technical Details
Table 56:
Delivery unit
HANA_ADMIN
Prerequisites HANA_UI_INTEGRATION_SVC, SAPUI5_1
Content type Automated content
Content details SAP HANA XS applications
Target users SAP HANA database administrators
Web application URL
http(s)://<host>:<port>/sap/hana/admin/cockpit
Key Features
The SAP HANA Database Administration component includes the following applications:
SAP HANA cockpit, an SAP Fiori Launchpad site providing administrators with a single point-of-access to
applications for the administration of SAP HANA.
Applications for the following basic database administration tasks:
Monitoring and managing database services
Monitoring alerts
Configuring alert checkers (for example, alerting schedule and thresholds, e-mail notifications)
Monitoring historical performance data of the database across a range of key performance indicators
related in particular to memory, disk, and CPU usage
Analyze the comparative memory utilization of column tables
Monitoring current most critical statements
Monitoring system replication status
Roles
The following roles are available with the SAP HANA Database Administration component. Users must be
granted one or more of these roles before they can use the component and its functions.
SAP HANA One Security Guide
SAP HANA Content
P U B L I C 127
Table 57:
Role Description
sap.hana.admin.roles::Monitoring
Allows users to open the SAP HANA cockpit with read-only
access to monitoring data
This role also allows users to see tiles in the SAP HANA
Platform Lifecycle Management and Smart Data Access
Administration tile catalogs.
sap.hana.admin.roles::Administrator
Allows users to open the SAP HANA cockpit with read-only
access to monitoring data, as well as to perform database
administration tasks supported by the cockpit (configure
alerts, stop/start services, reset memory statistics, cancel
sessions)
This role also allows users to see tiles in the SAP HANA
Platform Lifecycle Management tile catalog.
sap.hana.admin.cockpit.sysrep.roles::SysRepAd
min
Allows users read-only access to monitor system replication
status
11.1.1.2 HANA_BACKUP
This component provides a Web application for backing up the SAP HANA database, monitoring the progress
of a running backup and the status of existing backups.
Technical Details
Table 58:
Delivery unit
HANA_BACKUP
Prerequisites HANA_UI_INTEGRATION_SVC, SAPUI5_1
Content type Automated content
Content details SAP HANA XS application
Target users SAP HANA database administrators
Web application URL
http(s)://<host>:<port>/sap/hana/backup
Features
The SAP HANA Backup component provides a Web application that enables users to create a full data backup
and delta backups (differential and incremental), and to monitor the progress of a running backup or the
status of the last backup if currently none is running.
128
P U B L I C
SAP HANA One Security Guide
SAP HANA Content
Roles
The following roles are available with the SAP HANA Backup component. Users must be granted one or more
of these roles before they can use the component and its functions.
Table 59:
Role
Description
sap.hana.backup.roles::Operator
Provides access to the SAP HANA Backup application and
to create a backup
sap.hana.backup.roles::Administrator
Includes the above role and in addition provides write ac
cess to the backup catalog
11.1.1.3 HANA_HDBLCM
This component provides access to the SAP HANA platform lifecycle management Web user interface from
the SAP HANA cockpit.
Technical Details
Table 60:
Delivery unit
HANA_HDBLCM
Prerequisites
HANA_ADMIN
Content type Automated content
Content details SAP HANA cockpit plug-in
Target users SAP HANA database administrators
Web application URL
http(s)://<host>:<port>/lmsl/HDBLCM/<sid>/index.html
Key Features
SAP HANA platform lifecycle management can be used to update the SAP HANA system, to install or update
additional platform components, to add or remove hosts from the system, and to configure settings.
SAP HANA One Security Guide
SAP HANA Content
P U B L I C 129
Roles
Users must be granted one of these roles before they can use the component and its functions:
Table 61:
Role
Description
sap.hana.admin.roles::Monitoring
Allows users to see the SAP HANA platform lifecycle man
agement tiles in the SAP HANA cockpit
sap.hana.admin.roles::Administrator
To open and use the SAP HANA platform lifecycle management Web user interface, the user needs to
authenticate with the <sid>adm operating system user.
11.1.1.4 HANA_SEC_BASE
This component provides the database views, client API, and roles to be consumed by applications that
provide security administration features.
Technical Details
Table 62:
Delivery unit
HANA_SEC_BASE
Prerequisites
SAPUI5_1
Content type Automated content
Content details Data service of database engine, role definitions, client side API
Target users System administrators responsible for security-related configuration, user man
agement and/or management of public key infrastructure (PKI)
Web application URL None
Key Features
The SAP HANA Security Base component provides a remote API for the following functions:
Assign roles to users
Search for users by name and email
List users, roles, granted privileges, effective privileges, granted roles, and user attributes
List certificates in certificate store
List certificate collections and the contained certificates
List audit policies and global auditing settings
List encryption information (cryptographic library, data encryption status, network encryption settings)
130
P U B L I C
SAP HANA One Security Guide
SAP HANA Content
Trigger the encryption and decryption of data volumes
Roles
The following roles are available with the SAP HANA Security Base component. Users must be granted one or
more of these roles before they can use the component and its functions.
Table 63:
Role
Description
sap.hana.security.base.roles::HANACertificate
Admin
Provides read-only access to certificates and certificate col
lections if they have system privileges CERTIFICATE ADMIN
and TRUST ADMIN are granted. If not, only certificates in
own certificate collections are displayed. If users have sys
tem privilege TRUST ADMIN, they can create new certificate
collections. If they have CERTIFICATE ADMIN, they can add
new certificates.
sap.hana.security.base.roles::HANACertificate
View
Provides read-only access to view certificates and certifi
cate collections with OData services
sap.hana.security.base.roles::XSUserAdmin
Provides read-only access to users, roles, granted privi
leges, granted roles and effective privileges of current user,
and allows granting of roles to users
sap.hana.security.base.roles::XSUserView
Provides read-only access to users, roles, granted privi
leges, granted roles and effective privileges of current user,
and granted roles
sap.hana.security.base.roles::HANASecurityDas
hboardView
Provides read-only access to following security-related con
figuration information:
Auditing, including audit policies and audit trail targets
Data volume encryption
SSFS key changes
Network communication
sap.hana.security.base.roles::HANADataVolumeE
ncryptionAdmin
Allows users to trigger the encryption and decryption of
data volumes
SAP HANA One Security Guide
SAP HANA Content
P U B L I C 131
11.1.1.5 HANA_SEC_CP
This component provides Web applications for monitoring critical security settings, managing users, and
managing the in-database storage of X.509 client certificates.
Technical Details
Table 64:
Delivery unit
HANA_SEC_CP
Prerequisites
HANA_SEC_BASE
Content type Automated content
Content details SAP HANA XS applications
Target users SAP HANA user and security administrators
Web application URL
http(s)://<host>:<port>/sap/hana/admin/cockpit
Key Features
The SAP HANA Security Cockpit component includes the following applications for performing the following
tasks:
Monitoring the status of critical security settings (auditing, data storage, and network communication)
Encrypting and decrypting data volumes
Assigning roles to users
Managing certificates and certificate collections stored directly in the database
Roles
The following roles are available with the SAP HANA Security Cockpit component. Users must be granted one
or more of these roles before they can use the component and its functions.
Table 65:
Role
Description
sap.hana.security.cockpit.roles::DisplayAssig
nedRoles
Allows users to see which roles are granted to users
sap.hana.security.cockpit.roles::EditAssigned
Roles
Allows users to grant roles to users
sap.hana.security.cockpit.roles::DisplayCerti
ficateStore
Allows users read-only access to certificates and certificate
collections stored in the database
132 P U B L I C
SAP HANA One Security Guide
SAP HANA Content
Role Description
sap.hana.security.cockpit.roles::MaintainCert
ificates
Allows users to import trusted certificates into the certifi
cate store
sap.hana.security.cockpit.roles::MaintainCert
ificateCollections
Allows users to create collections, as well as add trusted
certificates and server certificates to collections
sap.hana.security.cockpit.roles::EditCertific
ateStore
Allows user to set the purpose of a collection in conjunction
with either system privilege USER ADMIN or SSL admin and
object privilege REFERENCES on the collection
sap.hana.security.cockpit.roles::DisplaySecur
ityDashboard
Allows users to see information about critical security set
tings (auditing, data storage, and network communication)
sap.hana.security.cockpit.roles::MaintainData
VolumeEncryption
Allows users to enable and disable data volume encryption
11.1.1.6 HANA_SYS_ADMIN
This component provides Web applications for the administration and monitoring of tenant databases in SAP
HANA systems that support multitenant database containers. This component is installed only on the system
database of a multiple-container system.
Technical Details
Table 66:
Delivery unit
HANA_SYS_ADMIN
Prerequisites
HANA_ADMIN
Content type Automated content
Content details SAP HANA XS applications
Target users SAP HANA system administrators
Web application URL
http(s)://<host>:<port>/sap/hana/admin/cockpit
Key Features
The SAP HANA System Administration component includes applications for performing the following tasks:
Monitoring and managing (stop, start, create, delete) tenant databases
Monitoring alerts and alert configurations in a tenant database
Monitoring historical performance data of a tenant database across a range of key performance indicators
related in particular to memory, disk, and CPU usage
SAP HANA One Security Guide
SAP HANA Content
P U B L I C 133
Roles
The following roles are available with the SAP HANA System Administration component. Users must be
granted one or more of these roles before they can use the component and its functions.
Table 67:
Role
Description
sap.hana.admin.cockpit.sysdb.roles::SysDBAdmi
n
Allows users in the system database to monitor and manage
tenant databases in a multiple-container system
11.1.1.7 HANA_XS_BASE
This component provides a Web application for configuring and managing SAP HANA XS applications and
system-level settings such as SMTP and security-related details (SAML, trust store, and so on).
Technical Details
Table 68:
Delivery unit
HANA_XS_BASE
Prerequisites None
Content type Automated content
Content details SAP HANA XS applications (including data model, tables, roles, and user interfa
ces)
Target users SAP HANA XS application administrators
Web application URL
http(s)://<host>:<port>/sap/hana/xs/admin
Key Features
The SAP HANA XS Administration Tool enables users to configure and manage SAP HANA XS applications
and system-level settings. It provides the following features:
SAP HANA XS application configuration
Supports the configuration of application security (public/private) and user authentication methods
(basic, form-based, logon tickets, X509, and SAML). It also supports the management of SQL connection
configurations, HTTP destinations, and job schedules.
SAML configuration
Enables the configuration and management of SAML service providers (URLs, metadata) and identity
providers (IDP metadata, certificates, destinations)
Trust management
Enables trust store configuration and management, and certificate management
134
P U B L I C
SAP HANA One Security Guide
SAP HANA Content
SMTP configurations
Enables the configuration and management of e-mail server settings for outbound e-mail connections. It
also supports the management of authentication type with credentials, transport security settings, and
socket proxy settings.
User self-service administration
Enables the administration of user self-service requests (acceptance/rejection of user requests). It also
support the activation of users, the granting of roles and the management of access lists such as blacklist/
whitelist email id/domain/IP range adding constraints to the user self-service process
Online Translation Tool
Enables the user to provide manual translation for text strings used in the application's user interface,
error messages, and documentation. Also the user can export and import XLIFF-formatted files into the
tool. The tool is integrated with SAP Translation Hub for recommendations of the translated texts.
Note
Access to external translation services is not granted in the SAP HANA license. To use external
translation services such as the SAP Translation Hub, an additional license is required.
SAP Web Dispatcher HTTP Tracing application
HTTP tracing for individual SAP HANA XS applications can be enabled in the SAP HANA Web Dispatcher.
The SAP HANA XS Administration Tools include the SAP Web Dispatcher HTTP Tracing application, which
you can use to enable and disable HTTP tracing in the SAP Web Dispatcher for SAP HANA XS applications.
Roles
The following roles are available with this component. Users must be granted one or more of these roles
before they can use the component and its functions.
Table 69:
Role
Description
sap.hana.xs.debugger::Debugger
Use of the debugging features of the SAP HANA Web-based
Development Workbench
sap.hana.xs.admin.roles::HTTPDestAdministrato
r
Full access to HTTP destination configurations (display and
edit)
sap.hana.xs.admin.roles::HTTPDestViewer
Read-only access to HTTP destination configurations, which
are used to specify connection details for outbound connec
tions, for example using the server-side JavaScript Connec
tivity API that is included with SAP HANA XS
sap.hana.xs.admin.roles::JobAdministrator
Full access to the configuration settings for SAP HANA XS
job schedules (defined in .xsjob files); user can specify
start/stop times, the user account to run the job, and the lo
cale
SAP HANA One Security Guide
SAP HANA Content
P U B L I C 135
Role Description
sap.hana.xs.admin.roles::JobSchedulerAdminist
rator
Full access to the configuration settings for SAP HANA XS
job schedules (defined in .xsjob files); user can specify
start/stop times, the user account to run the job, and the lo
cale
User can also enable or disable scheduling of jobs.
sap.hana.xs.admin.roles::JobViewer
Read-only access to the configuration settings for SAP
HANA XS job schedules (defined in .xsjob files).
sap.hana.xs.formLogin.profile::ProfileOwner
Management of user profile settings such as date/time for
mat and locale
It also allows the changing of user password.
sap.hana.xs.admin.roles::RuntimeConfAdministr
ator
Full access to the configuration settings for SAP HANA XS
application security and the related user-authentication pro
viders
sap.hana.xs.admin.roles::RuntimeConfViewer
Read-only access to the configuration settings for SAP
HANA XS application security and the related user-authenti
cation providers, for example, SAML or X509
sap.hana.xs.admin.roles::SAMLAdministrator
Full access to SAML configurations, including both the serv
ice provider and the identity providers
User can add new entries and make changes to existing
service or identity providers, as well as parse the resulting
metadata
sap.hana.xs.admin.roles::SAMLViewer
Read-only access to SAML configurations that are used to
provide details of SAML service providers and identity pro
viders
sap.hana.xs.admin.roles::SMTPDestAdministrato
r
Read-only access to SMTP configurations that are used to
specify configuration settings for outbound mail connec
tions to external mail servers
sap.hana.xs.admin.roles::SMTPDestViewer
Full access to SMTP configurations (display and edit)
User can maintain mail server details, authentication type
with credentials, transport security settings and socket
proxy settings.
sap.hana.xs.admin.roles::SQLCCAdministrator
Full access to SQL connection configurations (SQLCC)
sap.hana.xs.admin.roles::SQLCCViewer
Read-only access to SQL connection configurations
(SQLCC), which are used to enable the execution of SQL
statements from inside your server-side JavaScript applica
tion with credentials that are different to the credentials of
the requesting user
sap.hana.xs.admin.roles::TrustStoreAdministra
tor
Full access to the SAP HANA XS application trust store that
manages the certificates required to start SAP HANA XS ap
plications
sap.hana.xs.admin.roles::TrustStoreViewer
Read-only access to the trust store that contains the
server’s root certificate or the certificate of the certification
authority that signed the server’s certificate
136 P U B L IC
SAP HANA One Security Guide
SAP HANA Content
Role Description
sap.hana.xs.admin.roles::USSAdministrator
Administration of user requests submitted by end users
through the User Self-Services application
It is also possible to manage access lists such as blacklist/
whitelist email id/domains/IP range adding constraints to
the user self-service process
sap.hana.xs.admin.roles::USSExecutor
Role assigned to technical user to enable user self-service
application in the system
sap.hana.xs.wdisp.admin::WebDispatcherAdmin
Full access to the SAP HANA Web Dispatcher Administra
tion tool used by administrators to maintain secure inbound
communication, for example, to enable SSL/TLS connec
tions between browser front-ends or an ABAP system and
an SAP HANA XS application
sap.hana.xs.wdisp.admin::WebDispatcherMonitor
Read-only access to the information displayed in the SAP
HANA Web Dispatcher Administration tool
Translator
Enables an SAP HANA user to maintain translation text
strings with the SAP HANA Online Translation Tool
WebDispatcherHTTPTracingViewer
Read-only access to the HTTP setting of SAP HANA XS ap
plications running on the selected SAP HANA instance. This
role extends the
JobViewer role to enable the user to view
details of the xsjob configuration (httptracing.xsjob)
that starts and stops the HTTP tracing tasks.
WebDispatcherHTTPTracingAdministrator
Full access required to maintain HTTP tracing in the SAP
Web Dispatcher for SAP HANA XS applications. This role ex
tends the
JobAdministrator role to enable the user to
maintain the XS job file (httptracing.xsjob) used to
configure and enable HTTP tracing for XS applications in the
SAP Web Dispatcher.
11.1.2 Application Lifecycle Management
SAP HANA content for application lifecycle management
HANA_XS_LM [page 138]
SAP HANA One Security Guide
SAP HANA Content
P U B L I C 137
11.1.2.1 HANA_XS_LM
This component provides a Web application for the application lifecycle management of components
developed for SAP HANA XS.
Technical Details
Table 70:
Delivery unit
HANA_XS_LM
Prerequisites SAPUI5_1
Content type Automated content
Content details SAP HANA XS application
Target users Application developers, content administrators
Web application URL
http(s)://<host>:<port>/sap/hana/xs/lm
Key Features
The SAP HANA Application Lifecycle Management application enables application developers to create
products, delivery units, packages, and basic application components. Administrators can use the application
to set up the transport of delivery units, start and monitor transports, and upload or download delivery unit
archives.
Roles
The following roles are available with the SAP HANA Application Lifecycle Management component. Users
must be granted one or more of these roles before they can use the component and its functions:
Table 71:
Role
Description
sap.hana.xs.lm.roles::Administrator
Full read/write access to all the features in the SAP HANA
application lifecycle management tool, including the access
privileges granted to all other user roles available in the SAP
HANA application lifecycle management, for example, Dis
play, Execute Transport, and Transport.
sap.hana.xs.lm.roles::Developer
Enables the user to work on a change to which he is as
signed and to approve own contributions to the change. This
role includes the privileges of the Display role.
138 P UB L I C
SAP HANA One Security Guide
SAP HANA Content
Role Description
sap.hana.xs.lm.roles::DevelopmentExpert
Enables the user to perform all actions involved in change
recording (for example, create, assign objects to, release,
delete, assign other users to a change, approve own or for
eign contributions). This role includes the privileges of the
Display and the Developer roles.
sap.hana.xs.lm.roles::Display
View-only access; some features and options are hidden. A
user with this role can view all information available but can
not make any changes or trigger any transport operations.
sap.hana.xs.lm.roles::Execute Transport
Users with this role can view all information as well as trig
ger predefined transport operations. However, users with
this role cannot register or maintain systems, create trans
port routes, or edit details of a product, a delivery unit, or a
package.
sap.hana.xs.lm.roles::Transport
For technical users only. This role cannot be assigned to
normal users; it is granted as part of the Execute Transport
role. The Transport role grants the privileges required for
export or import actions during a transport operation. The
credentials and privileges of a technical user with the Trans
port role cannot be used for interactive logons, for example,
to start SAP HANA application lifecycle management.
sap.hana.xs.lm.roles::SLP_display
For technical users used for HTTP-based deployment when
using CTS Transport. Users with this role can perform all
supported read requests for SL protocol services.
sap.hana.xs.lm.roles::SLP_CTS_deploy_admin
For technical users used for HTTP-based deployment when
using CTS Transport. Users with this role can perform all
supported requests for CTS Deploy SL protocol service.
sap.hana.xs.lm.roles::SLP_CTS_ping_admin
For technical users used for HTTP-based deployment when
using CTS Transport. Users with this role can perform all
supported requests for CTS Ping SL protocol service.
For tasks that require interaction with external tools, the following additional roles are required:
Table 72:
Role
Description
sap.hana.ide.roles::EditorDeveloper
Inspect, create, change, delete and activate SAP HANA re
pository objects
This role is required when you select the Packages tile in or
der to maintain SAP HANA repository packages in Web-
based Development Workbench.
sap.hana.xs.admin.roles::HTTPDestAdministrato
r
Full access to HTTP destination configurations (display and
edit)
This role is required when you register a system for a trans
port route.
SAP HANA One Security Guide
SAP HANA Content
P U B L I C 139
Role Description
sap.hana.xs.admin.roles::RuntimeConfAdministr
ator
Full access to the configuration settings for SAP HANA XS
application security and the related user-authentication pro
viders
This role is required when you register a system for a trans
port route.
The following roles are required for SAP HANA Application Lifecycle Management Process Engine:
Table 73:
Role
Description
sap.hana.xs.lm.pe.roles::PE_Display
The user can monitor processes and display services
sap.hana.xs.lm.pe.roles::PE_Execute
In addition to the previous role, the user can start, stop,
skip, and resume processes.
sap.hana.xs.lm.pe.roles::PE_Activate
In addition to the previous roles, the user can activate serv
ices from repository files.
sap.hana.xs.lm.roles::Administrator
This role includes all previous roles.
11.1.3 Runtime Libraries
SAP HANA content for runtime libraries
HANA_XS_DBUTILS [page 140]
11.1.3.1 HANA_XS_DBUTILS
This component provides content for the simplified consumption of SAP HANA database objects for XSJS.
Technical Details
Table 74:
Delivery unit
HANA_XS_DBUTILS
Prerequisites None
Content type Automated content
Content details XSJS libraries
Target users Developers using the libraries for more convenient access to SAP HANA data
base objects
Web application URL None
140 P U B L I C
SAP HANA One Security Guide
SAP HANA Content
Key Features
The SAP HANA XS DB UTILITY LIBS component comes as set of XS JavaScript libraries that wrap the
database interface of XS with JavaScript-native access methods and object representations:
Invocation of SQL procedures as if they were JavaScript functions
JavaScript CDS client and query builder
These libraries can be consumed only by applications deployed on XS. In other words, they cannot be
accessed directly via HTTP from outside the XS container.
Roles
This component does not come with any roles. As the component simply wraps the standard XS database
interface, the role definitions and authorizations of that interface directly apply.
11.1.4 Configuration
SAP HANA content for configuration
HANA_TA_CONFIG [page 141]
11.1.4.1 HANA_TA_CONFIG
This component provides predefined configurations and dictionaries used by the SAP HANA text analysis
engine and by text mining.
Technical Details
Table 75:
Delivery unit
HANA_TA_CONFIG
Prerequisites None
Content type Automated content
Content details Configuration files
Target users SAP HANA developers
Web application URL None
SAP HANA One Security Guide
SAP HANA Content
P U B L I C 141
Key Features
The Text Analysis Configuration component includes the following:
Predefined configuration files containing text analysis options to be used when creating a full text index
Predefined configuration files containing text mining options
Roles
This component does not come with any roles.
The Text Analysis Configuration component contains configuration files. It does not contain any executable
software. Any user with permission to execute the SQL statement CREATE FULLTEXT INDEX can use the text
analysis engine and text mining, which use the HANA_TA_CONFIG data.
11.1.5 Supportability and Development
SAP HANA content for supportability and development
HANA_IDE_CORE [page 142]
HANA_XS_IDE, HANA_XS_EDITOR [page 143]
HANA_DT_BASE [page 144]
11.1.5.1 HANA_IDE_CORE
This component provides a Web-based integrated development environment (IDE) that can be used to build
and test development artifacts in SAP HANA. The SAP HANA Web-based Development Workbench is a quick
and easy alternative to the SAP HANA studio for developing native SAP HANA applications.
Technical Details
Table 76:
Delivery unit
HANA_IDE_CORE
Prerequisites SAPUI5_1, SAP_WATT, HANA_XS_BASE
Content type Automated content
Content details SAP HANA applications
Target users SAP HANA developers and support staff
Web application URL http(s)://<host>:<port>/sap/hana/ide
142 P U B L I C
SAP HANA One Security Guide
SAP HANA Content
Key Features
The SAP HANA Web-based Development Workbench includes the following tools:
Editor (IDE)
Inspect, create, change, delete , and activate SAP HANA repository objects or development artifacts such
as database entities, XS JavaScript code, Web content (HTML, CSS, etc.), OData service definitions
Catalog
Create, edit, execute, and manage SQL catalog artifacts
Security
Manage users and roles, assign objects and manage security
Traces
View and download traces for SAP HANA XS applications and set trace levels
Roles
The following roles are available with the SAP HANA IDE component. Users must be granted one or more of
these roles before they can use the component and its functions.
Table 77:
Role
Description
sap.hana.xs.ide.roles::Developer
A combined user role which incorporates all the following
roles and provides access to all tools
sap.hana.xs.ide.roles::EditorDeveloper
Provides access to the IDE/Editor tool
sap.hana.xs.ide.roles::CatalogDeveloper
Provides access to the Catalog tool
sap.hana.xs.ide.roles::TraceViewer
Provides access to the Trace tool
sap.hana.xs.ide.roles::SecurityAdmin
Provides access to the Security tool
11.1.5.2 HANA_XS_IDE, HANA_XS_EDITOR
These components provide browser redirection to the SAP HANA Web-based Development Workbench.
Note
The components HANA_XS_IDE and HANA_XS_EDITOR are available for downward compatibility reasons.
They do not contain any functionality except redirection to the SAP HANA Web-based Development
Workbench.
SAP HANA One Security Guide
SAP HANA Content
P U B L I C 143
11.1.5.3 HANA_DT_BASE
This component provides the SAP HANA REST application programming interface (API).
The SAP HANA REST API allows development tools to access the SAP HANA repository and database catalog
via HTTP(S) in a standard-compliant way. It builds upon the Eclipse Orion server API protocol version 1 on SAP
HANA. For SAP- specific tools, the Orion server protocol has been extended with SAP HANA-specific features
such as activation, change tracking, and database catalog search
Technical Details
Table 78:
Delivery unit
HANA_DT_BASE
Prerequisites None
Content type Automated content
Content details SAP HANA REST API
Target users SAP HANA developers and support staff
Web application URL None
Key Features
The SAP HANA REST API includes the following features:
File and folder operations such as reading, writing, moving and deleting files and folders (packages)
It is possible to read and write file and folder metadata. Examples of SAP-specific metadata are the
version, the activation time, and the activating user. In addition to the Orion standard, mass operations are
available to get and set the metadata of many files with one request.
Activation of repository objects
Change tracking
Handling of user preference data (for example, the SAP HANA Web-based Development Workbench and
other development and support tools)
Existence checks and search suggestions for metadata
These functions can be used to implement searching in the repository and in the database catalog, with
auto-completion. The metadata suggestion request returns all resources that match a specified pattern
Roles
The following roles are available with the REST API component. Users must be granted one or more of these
roles before they can use the component and its provided services. Additionally, users need the appropriate
authorization on SAP HANA repository entities and catalog entities to be able to view or change repository or
database content.
144
P U B L I C
SAP HANA One Security Guide
SAP HANA Content
Table 79:
Role Description
sap.hana.xs.dt.base::restapi
Allows users to access the REST API
11.1.6 User Interface
SAP HANA content for user interface
HANA_UI_INTEGRATION_SVC, HANA_UI_INTEGRATION_CONTENT [page 145]
SAPUI5_1 [page 146]
SAP_WATT [page 147]
11.1.6.1 HANA_UI_INTEGRATION_SVC,
HANA_UI_INTEGRATION_CONTENT
These components provide SAP HANA UI Integration Services (UIS), which is a set of Eclipse-based tools and
client-side APIs that enable you to integrate standalone SAP HANA client applications into Web-based
application sites.
Technical Details
Table 80: HANA_UI_INTEGRATION_SVC
Delivery unit
HANA_UI_INTEGRATION_SVC
Prerequisites None
Content type Automated content
Content details Database tables, views, stored procedures, UIs, HTML,
JavaScript
Target users Developers (design time) and end users (runtime)
Web application URL None
Table 81: HANA_UI_INTEGRATION_CONTENT
Delivery unit
HANA_UI_INTEGRATION_CONTENT
Prerequisites
HANA_UI_INTEGRATION_SVC
Content type Automated content
Content details Application sites and catalogs (.xsappsite and .xswidget
files)
Target users XS developers
SAP HANA One Security Guide
SAP HANA Content
P U B L I C 145
Web application URL None
Key Features
For developers and designers: tools for creating content and designing application sites
For end users: personalization capabilities and role-based access to application sites and their content
Roles
The following roles are available with the SAP HANA UIS components. Users must be granted one or more of
these roles before they can use the component and its provided services.
Table 82:
Role
Description
sap.hana.uis.db::SITE_DESIGNER
Create and edit standard and Fiori Launchpad applications
sites and catalogs
Assign permissions to standard and Fiori Launchpad appli
cation sites and their content
sap.hana.uis.db::SITE_USER
Access standard and Fiori Launchpad application sites and
catalogs
11.1.6.2 SAPUI5_1
This component provides SAP UI5, which is the library used by XS-based Web applications and tools to
implement the specific user interfaces.
All Web applications delivered with SAP HANA such as the SAP HANA cockpit, SAP HANA Application
Lifecycle Management, and SAP HANA Web-based Development Workbench rely on this delivery unit.
Technical Details
Table 83:
Delivery unit
SAPUI5_1
Prerequisites None
Content type Automated content
Content details Web content such as HTML, CSS, JavaScript
146 P U BL I C
SAP HANA One Security Guide
SAP HANA Content
Target users Used by XS-based Web applications
Web application URL None
Roles
Since this component provides purely Web content consumed by arbitrary Web applications, it is not
protected by any specific mechanisms. Any browser can download the artifacts in this library.
11.1.6.3 SAP_WATT
This component provides the SAP WATT Web library, which is an additional Web library used by the SAP
HANA Web-based Development Workbench. It contains additional Web content such as HTML, CSS, and
JavaScript libraries to build Web development environments.
All Web applications delivered with SAP HANA such as the SAP HANA cockpit, SAP HANA Application
Lifecycle Management, and SAP HANA Web-based Development Workbench rely on this delivery unit.
Technical Details
Table 84:
Delivery unit
SAP_WATT
Prerequisites None
Content type Automated content
Content details Web content such as HTML, CSS, JavaScript
Target users Used by the SAP HANA Web-based Development Work
bench
Web application URL None
Roles
Since this component provides purely Web content consumed by arbitrary Web applications, it is not
protected by any specific mechanisms. Any browser can download the artifacts in this library.
SAP HANA One Security Guide
SAP HANA Content
P U B L I C 147
11.1.7 Role Templates
SAP HANA content for role templates
HANA_ROLES [page 148]
11.1.7.1 HANA_ROLES
This component provides a design-time role template, based on predefined roles and privileges, to simplify
user management. An administrator can copy or extend the role template to create a project-specific role. The
role could be extended to include package and schema privileges, and then granted to users.
Technical Details
Table 85:
Delivery unit
HANA_ROLES
Prerequisites HANA_DT_BASE, HANA_XS_BASE, HANA_UI_INTEGRATION_SVC
Content type Non-automated content
Content details Template roles
Target users User administrators
Web application URL None
Roles
No roles are required to use the content of this component. However, users must have the following privileges
before they can change and grant the role template delivered with this component.
Table 86:
Privilege
Description
Catalog SQL object "_SYS_REPO"."GRANT_ACTI
VATED_ROLE": EXECUTE;
Required to grant role to users
148 P U B L I C
SAP HANA One Security Guide
SAP HANA Content
Privilege Description
System privilege: CATALOG READ
Catalog sql object "SYS"."REPOSITORY_REST":EXE
CUTE
Package <project_specific/root>: REPO.READ
Package <project_specific/root>: REPO.MAIN
TAIN_NATIVE_PACKAGES
Package <project_specific/root>:
REPO.EDIT_NATIVE_OBJECTS
Package <project_specific/root>: REPO.ACTI
VATE_NATIVE_OBJECTS;
Required to grant project-specific package and schema
privileges to the role and to activate the role
11.1.8 Documentation
SAP HANA documentation delivered as SAP HANA content
HDC_* [page 149]
11.1.8.1 HDC_*
These components provide product documentation for several Web applications delivered with SAP
HANASAP HANA. Users can access the documentation via a tile on the application homepage and from the
Help menu if available.
Technical Details
Table 87:
Delivery unit
HDC_ADMIN
HDC_XS_BASE
HDC_IDE_CORE
HDC_SEC_CP
HDC_SYS_ADMIN
HDC_XS_LM
Prerequisites
None
Content type Automated content
Content details HTML files, image files
Target users Application users
Web application URL
http(s)://<host>:<port>/public/sap/docs/hana
SAP HANA One Security Guide
SAP HANA Content
P U B L I C 149
Features
Product documentation is available for the following Web applications delivered with SAP HANA:
SAP HANA database and system administration with SAP HANA Cockpit
Note
The HDC_SYS_ADMIN component is installed only on the system database of a multiple-container
system.
SAP HANA security administration with SAP HANA Cockpit
SAP HANA XS Admin Tools
SAP HANA Application Lifecycle Management
SAP HANA Web-based Development Workbench
Roles
These components do not come with any roles. Access to the content is controlled by the standard XS-
application security mechanism, the .xsaccess file.
150
P U B L I C
SAP HANA One Security Guide
SAP HANA Content
12 Security for SAP HANA One Add-On
Manager
The SAP HANA One Add-On Manager allows you to download additional content packages provided by SAP
and to install/uninstall them on a running instance of SAP HANA One.
You use the SAP HANA One Add-On Manager to do the following:
Update your SAP HANA One instance
Update your SAP HANA One license
Install and uninstall SAP HANA One samplers
Downloading and installing content packages using the Add-On Manager requires the SAP HANA One instance
to contact an external REST service called remote repository.
This operation needs to be secured to prevent the following:
Downloading of packages from an unauthorized location
Tampering with downloaded packages
The Add-On Manager uses the API security mechanisms described below, but the end-point URL of the
remote repository API is protected using the access key pair used to manage the instance. The API code only
uses this stored end-point URL to contact the remote repository. This mechanism protects against the
downloading of content from unauthorized locations.
The following sections describe the mechanism used to prevent package tampering.
Protected Add-Ons
Many packages are protected and require authorization.
Packages are stored in the remote repository and on its local disk in a protected format. This is achieved by
dividing the package into a main package and a part containing the critical data, which is not in the package
itself but maintained as part of the metadata.
This metadata is maintained in the database of the remote repository. The metadata is transferred to the
instance only when installation of the package has been initiated.
Remote Repository API Security
All package management takes place through REST-style calls. These calls are protected using the API key
and secret key included in the code. Thus only the authentic code can execute the calls successfully. A
signature is also generated to keep the integrity of the call content. Both the server and client check integrity
for request and response.
SAP HANA One Security Guide
Security for SAP HANA One Add-On Manager
P U B L I C 151
Protection Against Unauthorized Copying of Add-Ons
Packages that contain sensitive data do not contain all the required content during transfer. Sensitive data is
contained in the package metadata, which the instance subsequently requests. It is transferred using the
following process:
1. The remote repository registers the public key of the instance.
2. It generates an AES key.
3. It uses the AES key to encrypt the sensitive data in the package metadata.
4. It encrypts the AES key with the previously-registered public key of the instance.
5. The metadata with encrypted AES key, together with the sensitive data encrypted with AES key, is sent to
the instance.
Security of Add-On Execution
As described above, the instance first receives incomplete package data. Then, it receives the encrypted
metadata. It uses the secure store private key to decrypt the AES key and then uses this AES key to decrypt
the sensitive data.
This unencrypted sensitive data is sent to the acceptSensitiveData install step as a stdin byte stream. The
package needs to have a binary with this name in its script directory.
152
P U B L I C
SAP HANA One Security Guide
Security for SAP HANA One Add-On Manager
Important Disclaimer for Features in SAP
HANA Platform, Options and Capabilities
SAP HANA server software and tools can be used for several SAP HANA platform and options scenarios as
well as the respective capabilities used in these scenarios. The availability of these is based on the available
SAP HANA licenses and the SAP HANA landscape, including the type and version of the back-end systems the
SAP HANA administration and development tools are connected to. There are several types of licenses
available for SAP HANA. Depending on your SAP HANA installation license type, some of the features and
tools described in the SAP HANA platform documentation may only be available in the SAP HANA options and
capabilities, which may be released independently of an SAP HANA Platform Support Package Stack (SPS).
Although various features included in SAP HANA options and capabilities are cited in the SAP HANA platform
documentation, each SAP HANA edition governs the options and capabilities available. Based on this,
customers do not necessarily have the right to use features included in SAP HANA options and capabilities.
For customers to whom these license restrictions apply, the use of features included in SAP HANA options and
capabilities in a production system requires purchasing the corresponding software license(s) from SAP. The
documentation for the SAP HANA optional components is available in SAP Help Portal at http://
help.sap.com/hana_options. If you have additional questions about what your particular license provides, or
wish to discuss licensing features available in SAP HANA options, please contact your SAP account team
representative.
SAP HANA One Security Guide
Important Disclaimer for Features in SAP HANA Platform, Options and Capabilities
P U B L I C 153
Important Disclaimers and Legal Information
Coding Samples
Any software coding and/or code lines / strings ("Code") included in this documentation are only examples and are not intended to be used in a productive system
environment. The Code is only intended to better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and
completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, unless damages were caused by SAP
intentionally or by SAP's gross negligence.
Accessibility
The information contained in the SAP documentation represents SAP's current view of accessibility criteria as of the date of publication; it is in no way intended to be
a binding guideline on how to ensure accessibility of software products. SAP in particular disclaims any liability in relation to this document. This disclaimer, however,
does not apply in cases of willful misconduct or gross negligence of SAP. Furthermore, this document does not result in any direct or indirect contractual obligations
of SAP.
Gender-Neutral Language
As far as possible, SAP documentation is gender neutral. Depending on the context, the reader is addressed directly with "you", or a gender-neutral noun (such as
"sales person" or "working days") is used. If when referring to members of both sexes, however, the third-person singular cannot be avoided or a gender-neutral noun
does not exist, SAP reserves the right to use the masculine form of the noun and pronoun. This is to ensure that the documentation remains comprehensible.
Internet Hyperlinks
The SAP documentation may contain hyperlinks to the Internet. These hyperlinks are intended to serve as a hint about where to find related information. SAP does
not warrant the availability and correctness of this related information or the ability of this information to serve a particular purpose. SAP shall not be liable for any
damages caused by the use of related information unless damages have been caused by SAP's gross negligence or willful misconduct. All links are categorized for
transparency (see: http://help.sap.com/disclaimer).
154
P U B L I C
SAP HANA One Security Guide
Important Disclaimers and Legal Information
SAP HANA One Security Guide
Important Disclaimers and Legal Information
P U B L I C 155
go.sap.com/registration/
contact.html
© 2016 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any
form or for any purpose without the express permission of SAP SE
or an SAP affiliate company. The information contained herein may
be changed without prior notice.
Some software products marketed by SAP SE and its distributors
contain proprietary software components of other software
vendors. National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company
for informational purposes only, without representation or warranty
of any kind, and SAP or its affiliated companies shall not be liable for
errors or omissions with respect to the materials. The only
warranties for SAP or SAP affiliate company products and services
are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein
should be construed as constituting an additional warranty.
SAP and other SAP products and services mentioned herein as well
as their respective logos are trademarks or registered trademarks
of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the
trademarks of their respective companies.
Please see http://www.sap.com/corporate-en/legal/copyright/
index.epx for additional trademark information and notices.