SAP_HANA_One_Security_Guide_en330491373020393.pdf

7/27/2019 SAP_HANA_One_Security_Guide_en330491373020393.pdf

http://slidepdf.com/reader/full/saphanaonesecurityguideen330491373020393pdf 1/56

PUBLIC

SAP HANA Software SPS 05Document Version: 1.0 - 2013-05-15

SAP HANA One Security Guide



Table of Contents

1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 SAP HANA One Network Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Communication Channel Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

2.1.1 Securing Data Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.2 Communication Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.3 SAP HANA One Deployment Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.4 Security Group and Firewall Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 SAP HANA One User Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 User Administration Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 User Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 Standard Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 SAP HANA Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1 SAP HANA One Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.1 SAP HANA One Standard Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.2 SAP HANA One Management Console. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2 SAP HANA Authentication for Database Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2.1 Password Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2.2 Password Blacklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

4.2.3 Resetting the SYSTEM User Password. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.4 Single Sign-On Using Kerberos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.5 Single Sign-On Using SAML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 SAP HANA Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.1 Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.1 Analytic Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.1.2 Creation and Management of Analytic Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2.1 Standard Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.3 Authorization in the Repository of the SAP HANA Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

5.3.1 User Authorization for the Repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.3.2 _SYS_REPO Authorization in the Repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3.3 Granting and Revoking Privileges on Activated Repository Objects. . . . . . . . . . . . . . . . . . . . .37

5.4 SAP HANA One Samplers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

6 Secure Communication in SAP HANA One Landscape. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

6.1 Configuring HTTPS Between SAP HANA Database and SAP HANA Studio. . . . . . . . . . . . . . . . . . . . . . 39

6.1.1 Setup on Server-Side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

6.1.2 Setup on Client-Side (SQLDBC-Based Connections). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2P U B L I C© 2013 SAP AG or an SAP affiliate company. All rights reserved.


Table of Contents



6.1.3 Setup on Client-Side (JDBC-Based Connections). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2

6.1.4 Setup of SAP HANA Studio Connections (JDBC-Based-Connections). . . . . . . . . . . . . . . . . . 43

6.2 Configuring HTTPS (SSL) for Client Application Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7 SAP HANA One Data Storage Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.1 Data Volume Encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.1.1 Implications of Persistence Encryption for Backup and Recovery. . . . . . . . . . . . . . . . . . . . . .49

7.1.2 Periodic Administration Tasks for Persistence Encryption. . . . . . . . . . . . . . . . . . . . . . . . . . .49

8 Auditing Activity in SAP HANA Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8.1 Audit Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8.2 Audit Trail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

8.3 Auditing Configuration and Audit Policy Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55


Table of Contents

P U B L I C© 2013 SAP AG or an SAP affiliate company. All rights reserved. 3



1 Introduction

This document provides an overview of the overall security concepts used and recommended in subscribing,

developing on, and managing SAP HANA One instances for productive and commercial uses.

SAP HANA One is a public cloud solution that, by default, uses Amazon Web Service (AWS) as the public cloud

provider.

Target Audiences

● Technology consultants

● Security consultants

● System administrators

This document provides security information that is relevant for all software lifecycle phases.

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:

● SAP HANA One Network 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.

● SAP HANA One User Management

This section provides an overview of the following:

○ Concepts related to user management in SAP HANA

○ Tools for user and role administration

○ Types of users in SAP HANA

○ Standard users delivered with SAP HANA

● SAP HANA One Authentication

This section provides an overview of the authentication mechanisms supported by SAP HANA One, including

SAP HANA One Management Console and integration into single sign-on environments.

● SAP HANA One 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.

● Secure Communication in SAP HANA One Landscape

This section provides instructions on configuring secure communication among SAP HANA One components.

● SAP HANA One 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.

● Auditing Activity in SAP HANA One



Introduction



This section provides an overview of the auditing feature of the SAP HANA database.


Introduction




2 SAP HANA One Network Security

This topic provides you with the information about the different network channels of your SAP HANA system inthe public cloud, the required access for different scenarios, as well as configuration options provided by SAP

HANA.

It is recommended security practice to have a well-defined network topology to control and restrict network

access to the SAP HANA system to only the communication channels required for your respective scenario and to

apply appropriate additional security measures, such as encryption, where necessary. This can be achieved by

using different means such as separate network zones, network firewalls, or through configuration options, such

as encryption, provided by SAP HANA. The detailed setup is dependent on the specific customer environment, the

SAP HANA scenarios, and the security requirements or policies of the customer. Based on the information in this

chapter, customers can decide how SAP HANA can be securely integrated in their respective network

environment.

The system landscape gives an overview of the different network segments that, depending on the individual

configuration, are available. The detailed setup is dependent on the specific application scenario and customer

network infrastructure.

SAP HANA One should be operated in a protected environment. Only dedicated authorized network traffic should

be allowed from other network zones (for example, user access from client network zone):

● Client access (that is, all access to external standard database functionality, for example, SQL) only requires

access to the client access port.

● Client HTTP access (for example, browser) in scenarios that use the HTTP access feature of SAP HANA

Extended Application Services (SAP HANA XS), for example, SAP HANA UI Toolkit for Info Access.

● For some administrative functions (for example, starting and stopping the SAP HANA instance), access to the

administrative ports is additionally required.

● Database internal communication is only used for communication within the database.

Caution

The internal communication must be strictly separated from the external or client communication paths.

Access from hosts that are not part of the SAP HANA instance should be blocked.

If your setup does not allow having the internal communication in a dedicated subnet, we recommend

protecting the internal communication using encryption.

2.1 Communication Channel Security

The network communication channels in a SAP HANA landscape can be separated into different groups:

● SAP HANA database client access

These are the network channels which are used for client access to the database or SAP HANA-based

applications. There are two scenarios:

○ SAP HANA database clients to access the SQL interface of the SAP HANA database. The client in this

case can be application servers that use SAP HANA as a database, direct end-user clients such as



SAP HANA One Network Security



Microsoft Excel®

that access the database directly via the provided database clients or access with the

SAP HANA studio, such as for modeling.

○ Access to functionality provided by SAP HANA Extended Application Services (SAP HANA XS) via HTTP.

Examples for this are applications based on SAP HANA Extended Application Services which areaccessed using a web browser or mobile devices.

● Administrative access

There are additional network channels which are used for specific remote administrative tasks such as

starting or stopping the SAP HANA instances. Some administrative functions require access to the database

SQL interface or the HTTP interface.

● SAP HANA database internal communication

Those network channels are only used internally in the SAP HANA database to communicate between the

different components of the SAP HANA database or for communication between the different hosts in a

distributed SAP HANA instance.

Network Zones

SAP recommends the application of network firewall technology to create different network zones for the

different components and restrictively apply filtering of the traffic between those zones implementing a

“minimum required communication” approach. It is strongly recommended that you apply the measures in this

document to protect the access to the SAP HANA database internal communication channels to mitigate the risk

of unauthorized access to those services.

Tip

Block all access to other ports in the firewall that are not used by the SAP HANA database in your scenario.

CautionThe internal communication must be strictly separated from the external or client communication paths.

Access from hosts that are not part of the SAP HANA instance should be blocked. If your setup does not allow

having the internal communication in a dedicated subnet, we recommend protecting the internal

communication using encryption.

Communication Encryption

As shown in the table below, SAP HANA supports encrypted communication for the client-to-server

communication. We recommend using encrypted channels in all cases where network attacks such as

eavesdropping are not protected by other network security measures, for example, access from end-user

networks. As an alternative, VPN tunnels can be used for the transfer of encrypted information.

The table below shows the most relevant communication channels used by SAP HANA, the protocol used for the

connection and the type of data transferred.

Table 1: Communication Paths

Communication Path Protocol Used Type of Data Transferred Data Requiring Special

Protection

Client Access (for example, replication, application server, end-user client, modeling, SAP HANA studio)

SAP HANA database to

data providersODBC/JDBC over TCP

(SSL supported)

All application data All application data






Communication Path Protocol Used Type of Data Transferred Data Requiring Special

Protection


admin clientODBC/JDBC over TCP

(SSL supported)

User data, configuration

data, trace files

For modeling: Data

models

User data, configuration

data, trace files

For modeling: Data

models


end-user clientsODBC/JDBC over TCP

(SSL supported)

All application data All application data

SAP HANA Extended

Application Services (SAP

HANA XS)

HTTP All application data All application data

Administrative Access

SAP Start Service HTTP/HTTPS Configuration data, trace

files

Configuration data, trace

files

Operating system access SSH Operating system

commands, and so on.

Operating system

commands, and so on.

Database Internal Communication

SAP HANA database

internal communication

and communication

between SAP HANAdatabase instances in

distributed installations

TCP (SSL supported) All application data

Configuration data

All application data

Configuration data

2.1.1 Securing Data Communication

SAP HANA supports encrypted communication for client-to-server and internal communication.

We recommend using encrypted channels in all cases where network attacks such as eavesdropping are not

protected by other network security measures (for example, access from end-user networks).

2.1.2 Communication Ports

The table below lists the ports that are used by SAP HANA. We recommend controlling the network traffic

between the different network segments by using a firewall or a packet filter.

Tip

Block all access to other ports in the firewall that are not used by the SAP HANA database. With SAP HANA

One, an AWS security group is used to implement a bvirtual firewall around the SAP HANA One instance.






Note

In certain scenarios, additional communication channels, for example, for remote operating system access

may be required.

The notation of the ports is as follows: n <instance> xy, where <n> is either 3 or 5 (see table below),

<instance> is a two-digit number representing the SAP HANA instance number, and <xy> represents a

consecutive number. In SAP HANA One, the instance number is 00.

Recommendation

We strongly recommend not changing the instance number or SID of HANA One.

Communication Ports for Inbound Communication

Port Number Used for

Client Access

3<instance>15 Standard SQL communication for client access. This is

the only port required for client access.

80<instance>/43<instance> SAP HANA XS (HTTP/HTTPS).

Only enabled in scenarios that use SAP HANA XS.

Administrative Access

5<instance>13

5<instance>14

(SSL)

System administration (for example, startup and

shutdown)

For more information about the SAP Start Service, see

the SAP Library on SAP Help Portal at http://

help.sap.com under SAP NetWeaver SAP

NetWeaver 7.3 Functional View SAP NetWeaver by

Functional Areas Application Server Application

Server Infrastructure Architecture of the SAPNetWeaver Application Server SAP Start Service .

Database Internal Communication

3<instance>00 Used for database internal communication only. These

ports should only be accessible from other hosts of the

SAP HANA appliance.3<instance>01

3<instance>02

3<instance>03

3<instance>05

3<instance>07




http://help.sap.com/

http://help.sap.com/



2.1.3 SAP HANA One Deployment Options

SAP HANA One at Amazon Web Service (AWS) Marketplace provides two deployment options: EC2-classic andEC2-VPC (Virtual Private Cloud).

If you deploy your SAP HANA One instance using the 1-click deployment option, your instance is deployed into the

AWS cloud in the EC2-classic configuration and access to the instance is controlled by the use of a security group,

which acts as a virtual firewall. Specific ports and IP address ranges can be restricted in the security group to

secure the HANA One instance.

You can also use the AWS EC2 Management Console to deploy your SAP HANA One instance in the EC2-classic

configuration.

Figure 1: EC2-Classic Deployment

By using the AWS EC2 Management Console, you can also deploy your SAP HANA One instance in an existing

virtual private cloud (VPC). This VPC-deployment is included here for reference; however, it is beyond the scope

of this security guide.

The following figures show simple examples of EC2-VPC deployment options using access through the Internet or

through a customer's own data center.






Figure 2: EC2-VPC Deployment Access Via Internet Gateway in a Private Subnet

Figure 3: EC2-VPC Deployment Access Via Corporate Network

For additional information on setting up and operating an AWS VPC environment, go to http://aws.amazon.com/

vpc/ .

2.1.4 Security Group and Firewall Settings

Firewall settings are defined in AWS security groups. For security reasons, only the following ports are open by

default:

● Port 22 for SSH

● Port 80 for http

● Port 443 for https




http://aws.amazon.com/vpc/

http://aws.amazon.com/vpc/



Additional ports required by SAP HANA One are opened when configuring the server using SAP HANA One

Management Console. We recommend you to restrict the security group policies to only allow the IP address of

the systems to which you want to communicate with SAP HANA instance. For more information about security

groups, refer to Amazon EC2 Security Groups section in the Amazon Elastic Compute Cloud User Guide.

Recommendation

We recommend you restrict the security group policies to only allow the IP address of the systems to which you

want to communicate with the SAP HANA instance.

The ports opened by SAP HANA One are:

● Port 30015 for JDBC

● Port 50013 and 50014 for SAP Control

● Port 8000 for XS Engine

Additional ports may be opened to support new functionality out of the box. However, any ports are opened will be

notified at the launch time and will be documented in the HANA One Guide.

Related Links

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html




http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html



3 SAP HANA One User Management

Every user who wants to work with the SAP HANA database must have a database user. The identity of a database

user accessing the database is verified through a process called authentication. The SAP HANA database

supports internal authentication based on a username-password combination and authentication using external

user repositories.

Note

A user who connects to the database using an external authentication provider must have a database user

known to the database.

Once their identity has been verified, database users can perform database operations on database objects.

Whether or not a user is authorized to perform operations on objects in the database is determined by theirprivileges. The database user must have privileges to perform the operation and to access the object (for

example, a table) to which the operation applies. Privileges can be granted to database users either directly, or

indirectly through roles that they have been granted.

All the privileges granted directly or indirectly to a user are combined. This means 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 roles. As soon as all requested privileges have been found, the system aborts the check and grants access.

Although privileges can be granted directly to users, roles are the standard mechanism of granting privileges as

they allow you to implement both fine-grained and coarse-grained reusable hierarchies of user access that can be

modeled on business roles. Several standard roles are delivered with the SAP HANA database (for example,

MODELING, MONITORING). You can use these as templates for creating your own roles.

The relationship between the entities involved in user management can therefore be summarized as follows:

● A principal is either a role or a user.

● A known user can log on to the database. A user can be the owner of database objects.

● A role is a collection of privileges and can be granted to either a user or another role (nesting).

● A privilege is used to grant authorization to carry out operations on database objects, such as schemas,

tables, and views.

This relationship is depicted in the following figure:


SAP HANA One User Management




3.1 User Administration Tools

You can create and manage SAP HANA database users with several different tools. The following table lists the

available tools and the administration tasks that you can perform with each.

Tool User Administration Tasks Possible

SAP HANA studio You can use the SAP HANA studio for the following tasks related to user

and role administration:

● Creating database users

● Deleting, deactivating, and reactivating database users

● Modeling and activating analytic privileges

● Creating roles and role hierarchies

Note






Tool User Administration Tasks Possible

You can create roles in runtime on the basis of SQL statements or

as design-time objects in the repository of the SAP HANAdatabase. However, it is recommended that you create roles in the

repository as they offer more flexibility (for example, they can be

transported between systems).

● Assigning roles and privileges to users

● Verifying which privileges individual users have

Command line interface (hdbsql or

other SQL tool)

You can perform all user administration tasks from the command line

using SQL requests. This is useful when using scripts for automated

processing.

3.2 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 the following user types:

● Database users that correspond to real people

The database administrator creates a database user for every person who needs to work in the SAP HANA

database. Database users that correspond to real people are dropped when the person leaves the

organization. This means that database objects that they own are also automatically dropped, and privileges

that they granted are automatically revoked.

● 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, _SYS_STATISTICS, and

_SYS_REPO. It is not possible to log on to the database with these users.

Other technical database users are application specific. For example, an application server may log on to the

SAP HANA database using a dedicated technical database user.

Technically, these user types are the same – authentication and authorization are the same for both. The onlydifference between them is conceptual.

3.3 Standard Users

Certain users are required for installing, upgrading, and operating the SAP HANA database. The following table

lists the standard users that are available.






User Description Password Specification

SYSTEM The SYSTEM database user is the

initial user that is created during the

installation of the SAP HANA

database. SYSTEM is a powerful

database user – it has irrevocable

system privileges, such as the

ability to create other database

users, access system tables, and so

on.

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.

You specify the initial password

during SAP HANA One

configuration when you subscribe.

<sid>adm where sid is the ID of the

database system

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 access to all localresources related to SAP systems.

This user is not a database user but

a user at the operating system level.

You specify the initial password

during SAP HANA One

configuration after you subscribe.

SYS The SYS is a technical database

user. It is the owner of system

objects such as system tables and

monitoring views.

Not applicable

This is a technical database user. It

is not possible to log on with this

user.

_SYS_STATISTICS _SYS_STATISTICS is a technical

database user used by the statisticsserver of the SAP HANA database.

The statistics server is the main

component of the monitoring

infrastructure 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



user.

_SYS_REPO _SYS_REPO is a technical database

user used by the SAP HANA

Not applicable






User Description Password Specification

repository. The repository consists

of packages that contain design

time versions of various 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.


is not possible to log on with thisuser.

_SYS_AFL _SYS_AFL is a technical user that

owns all objects for Application

Function Libraries.

Not applicable



user.






4 SAP HANA Authentication

4.1 SAP HANA One Authentication

When you subscribe to SAP HANA One, you need to configure access, which includes defining several passwords

during launch. In SAP HANA one, access is authenticated using AWS access keys and key pairs.

The following methods of authentication are used to authenticate user requests to set or reset hdbadm and

SYSTEM user passwords:

● Access Keys: Used in the SAP HANA One Management Console. Access keys ensure that REST or Query

protocol requests to any AWS service API are secure. AWS creates access keys when your account is created.

NoteWithout AWS access keys, you cannot log in to SAP HANA One Management Console to configure your

SAP HANA One for the first time.

● Key Pairs: Used in SSH mode.

Related Links

Amazon AWS Access Credentials

4.1.1 SAP HANA One Standard Users

In SAP HANA One, you can create and manage passwords for the SYSTEM user and the hdbadm operating

system user.

To manage SAP HANA One SID database, SAP HANA requires the hdbadm user. This user is automatically

created without any password. SAP strongly recommends specifying a very strong password for the hdbadm

operating system user.

Operating System Access

Only the root user with key pairs is granted operating system access to SAP HANA One. Any other operating

system users cannot log in. We strongly recommend keeping this configuration.

After gaining access to the operating system as the root user, you can use “su” to change the user to hdbadm or

any other users you may need for your application.

4.1.2 SAP HANA One Management Console

SAP HANA One includes a web-based management console to run all system administration activities. You can

use this tool to set passwords and configure SAP HANA One for the first time.



SAP HANA Authentication

https://portal.aws.amazon.com/gp/aws/securityCredentials#access_credential



From SAP HANA One Management Console, you can easily set and reset both the SYSTEM user password and

the hdbadm operating system user password. For power users, it still provides HANA Studio and command level

options.

You also need to set a secured password for SAP HANA One Management Console. You do this when you log in to

SAP HANA One for the first time, either at the operating system level or the database level.

4.1.2.1 Resetting Passwords

In SAP HANA One, you can use the SAP HANA One Management Console to define and reset the following user

passwords:

●

SYSTEM● <sid> adm

● SAP HANA One Management Console

1. In the SAP HANA One Management Console, select the Administration tab.

2. Under Reset passwords, enter both the Access Key ID and the Secret Access Key ID that you used to

configure SAP HANA One.

3. After your access keys are validated, select the user for which you want to reset the password.

4. Enter and confirm the new password.

4.1.2.1.1 Resetting Forgotten Password for SAP HANA OneManagement Console

If you forget your password for SAP HANA One Management Console, you can reset your password by using

access keys.

1. Enter the Elastic IP or DNS name of your SAP HANA One instance and choose Reset password.

2. Enter both your Access Key and your Secret Access Key.

3. After the access keys are validated, enter a new password and choose Set new password.

4.2 SAP HANA Authentication for Database Users

The identity of every database user accessing the database is verified through a process called authentication.

The SAP HANA database supports internal authentication based on a username-password combination and

authentication using external user repositories.

● Internal authentication

Users are created in SAP HANA database only. Their identity is verified by means of a username-password

combination.






Note

For some administrative operations (such as start-up, shutdown, and database recovery), the credentials

of the SAP operating system user (<sapsid>adm) are also required.

● Authentication using external user repositories based on the following mechanisms:

○ Kerberos (third-party authentication provider) for integration into single sign-on environments

○ Security Assertion Markup Language (SAML) bearer token

Note

A user who connects to the database using an external authentication provider must also have a database

user known to the database.

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. Kerberos, SAML, and client certificates can be used for this purpose.

4.2.1 Password Policy

Passwords for internal authentication of database users are subject to certain security rules. These are

configured using the parameters in the password policy section of the system properties file indexserver.ini.

You can view and change the parameters of system properties files in the Administration editor of the SAP HANA

studio.

The following monitoring views are also available in which you can view the parameters and their current values:

● M_INIFILE_CONTENTS

● M_PASSWORD_POLICY

Related Links

http://help.sap.com/hana/html/monitor_views.html

4.2.1.1 Password Policy Parameters

The table below contains the password policy parameters and their default values, and explains the function of

each parameter.

Parameter Default Value Description

minimal_password_length 8 Defines the minimum password length. The accepted

value range is 6 to 64 characters. The allowed




http://help.sap.com/hana/html/monitor_views.html




character classes are described directly below in the

following table row.

password_layout A1a Defines the character types that must be used in the

creation of a password.

● Uppercase letter: A-Z

● Lowercase letter: a-z

● Numbers: 0-9

● Special characters: Underscore (_), hyphen (-),

and so on. Any character that is not an uppercase

letter, a lowercase letter, or a number is

considered to be a special character.

According to the example provided in theDefault

Value column, passwords would be required to

contain at least one uppercase letter, at least one

number, and at least one lowercase letter, with

special characters being optional. However, you

can use any specific letters and numbers and

special characters to define the password_layout

parameter, and the characters can be in any order.

For example, the default value example could also

have been represented by a1A, hQ5, or 9fG. If you

want to enforce the use of at least one of each

character type including special characters, you

could use A1a_ or 2Bg?.

Tip

When a password is enclosed in double quotes (")

during user creation, any Unicode characters may

be used.

Caution

The use of passwords enclosed in double quotes (")

may cause logon issues, depending on the clientused. The SAP HANA studio, for example, supports

passwords enclosed in double quotes ("), while the

hdbsql command line tool does not.

force_first_password_cha

nge

true Defines whether users have to change their initial

passwords at first logon.

Logging on with the initial password is still possible but

only the ALTER USER <current_user> PASSWORD

<password> command can be executed. All other







statements give the error message user is forced

to change password.

Administrators can force a user to change the

password at any time with the following SQL

command:

ALTER USER <user_name> FORCEPASSWORD CHANGE

maximum_invalid_connec

t_attempts

6 Defines how many invalid logon attempts are allowed

before the user account is locked.

Administrators can reset the number of invalid logon

attempts with the following SQL command:

ALTER USER <user_name> RESET CONNECTATTEMPTS

With the first successful logon after an invalid logon

attempt, an entry is made into the

INVALID_CONNECT_ATTEMPTS view showing:

● The number of invalid logon attempts since the last

successful logon

● The time of the last successful logon

Administrators and users can delete the information ofinvalid logon attempts with the following SQL

command:

ALTER USER <user_name> DROP CONNECTATTEMPTS

password_lock_time 1440 Defines the duration in minutes that a user account is

locked after a defined number of failed logon attempts.

The default value is set to 1,440 minutes (= 24 hours).

Administrators can reset the number of invalid logon

attempts and unlock the user account with the

following SQL command:

ALTER USER <user_name> RESET CONNECTATTEMPTS

last_used_passwords 5 Defines the number of last used passwords that the

user is not allowed to use when changing the current

password.

maximum_password_lifeti

me

182 Defines the duration in days that a password is valid.







After the expiry of this validity period, users have to

change their password at the next logon.

Administrators can exclude users from this password

lifetime check with the following SQL command:

ALTER USER <user_name> DISABLEPASSWORD LIFETIME

Note

It is recommended to perform this step for technical

users only, not for standard database users.

password_expire_warning

_time

14 Defines a number of days before password expiration.

Starting at the given period before the expiration date,

users receive notification when logging on that their

password will soon expire.

maximum_unused_initial_

password_lifetime

28 Defines the duration in days that an initial password for

a user account is valid.

If an initial password has not been used for the first

time within the given period of time, the password

becomes invalid and the password must be reset.

maximum_unused_produ

ctive_password_lifetime

365 Defines the duration in days that a user-defined

password is valid.

If a user-defined password has not been reused within

the given period of time, the password becomes invalid

and the password must be reset.

minimum_password_lifeti

me

1 Defines the minimum duration in days that a newly

entered user-defined password remains valid before

the user can change it again.

If the value of this parameter is set to 0, no check isperformed.

4.2.2 Password Blacklist

A password blacklist is a list of words or blacklist terms that are not allowed as passwords or parts of passwords.

SAP HANA performs a password check when you create or alter a user's password but not when the password is

used during logon.

Note






It is possible that a password exists that does not adhere to the current blacklist rules because it was defined

before the current state of the blacklist was reached.

The password blacklist allows you to specify the following:

● If the blacklist term check is case sensitive

● If the blacklist term check applies to either whole or partial passwords

The password blacklist in SAP HANA has been implemented with the following table:

CREATE TABLE _SYS_SECURITY._SYS_PASSWORD_BLACKLIST(BLACKLIST_TERM NVARCHAR(256) NOT NULL,CHECK_PARTIAL_PASSWORD VARCHAR(6) NOT NULL,CHECK_CASE_SENSITIVE VARCHAR(6) NOT NULL,PRIMARY KEY (CHECK_PARTIAL_PASSWORD, CHECK_CASE_SENSITIVE, BLACKLIST_TERM) )

This table is empty when you create a new instance. The _SYS_SECURITY schema and the

_SYS_PASSWORD_BLACKLIST table are owned by the SYSTEM user. The SYSTEM user is allowed to select,insert, update, and delete rows in this table and may grant the corresponding privileges to those users who may

need them.

Caution

For security reasons even the privilege to select should be handled very carefully to prevent users from being

able to view those items not allowed as password or parts of passwords.

The BLACKLIST_TERM column is populated with the blacklist terms. According to the value in the

CHECK_CASE_SENSITIVE column, you can determine whether the blacklist term is case sensitive.

The columns CHECK_PARTIAL_PASSWORD and CHECK_CASE_SENSITIVE are populated with the values <TRUE> or <FALSE> .

Example

Consider the following definition of a blacklisted term:

INSERT INTO _SYS_SECURITY._SYS_PASSWORD_BLACKLIST VALUES ('sap', 'TRUE', 'FALSE')

In this example, the passwords "SAP", "my_sap_pwd", and "sap_password" would not be allowed, regardless of

how the password layout and minimal password length are defined in the corresponding parameters.

4.2.3 Resetting the SYSTEM User Password

If the SYSTEM user's password is lost, you can use the SAP operating system user to reset the password.

To recover an SAP HANA instance where the SYSTEM user's password is lost, you need to have <sid>adm access

to the instance on which the master index server of the SAP HANA database is running.

1. Open a command line interface, and log on to the server on which the instance of the SAP HANA master index

server is running.

2. Shut down the instance.






3. Start the name server by executing the following commands:

○ /usr/sap/<SID>/HDB<instance>/hdbenv.sh

○ /usr/sap/<SID>/HDB<instance>/exe/hdbnameserver

4. Start an index server in console mode by executing the following commands:

○ /usr/sap/<SID>/HDB<instance>/hdbenv.sh

○ /usr/sap/<SID>/HDB<instance>/exe/hdbindexserver -console

You see the output of a starting index server. When the service has started, you have a console to the SAP

HANA instance where you are logged on as the SYSTEM user.

5. You can reset the SYSTEM user's password and store the new password in a secure location with the

following SQL command:

ALTER USER SYSTEM password <new password>

The password for the SYSTEM user is reset. As you are logged on as the SYSTEM user in this console, you do nothave to change this new password the next time you log on with this user, regardless of what your password policy

setting is.

4.2.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.

Kerberos is a network authentication protocol that provides authentication for client-server applications acrossan insecure network connection using secret-key cryptography.

SQLDBC (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.

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 authentication.

3. Map SAP HANA database users to their external identities stored in the Kerberos key distribution center

(KDC).






4.2.5 Single Sign-On Using SAML

Security Assertion Markup Language (SAML) is an XML-based open standard data format for exchangingauthentication and authorization data between an identity provider and a service provider. SAP HANA uses SAML

as an authentication mechanism only and not for authorization.

It is possible to log on to SAP HANA using SAML bearer assertions using the standard ODBC/JDBC database

clients. It is the database clients' responsibility to retrieve the SAML assertion used for the logon process.

Supported SAML Features

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 and MD5 for hash algorithms

● RSA-SHA1 as signature algorithm

● X509Certificate elements

Note

The XML signature must contain the X.509 certificate of the identity provider within the <X509Certificate>

element.

The following SAML assertion features are supported:

● Assertion Subject with NameID

● Qualified NameID with SPProvidedID and SPNameQualifier

● Validity conditions (NotBefore, NotOnOrAfter)

● Audience restrictions

Evaluated Assertion Properties

The following properties of a SAML assertion are evaluated:

Property Required Entry

saml:Assertion/@Version 2.0

saml:Subject/saml:NameID Must exist

saml:Subject/saml:NameID/@Format urn:oasis:names:tc:SAML:1.1:nameid-

format:unspecified

saml:Subject/saml:NameID/@SPProvidedID Must either match an explicit mapping in the SAP

HANA database or a wildcard mapping must have been

set for the user






Property Required Entry

saml:Subject/saml:SubjectConfirmation If it exists, {{"urn:oasis:names:tc:SAML:

2.0:cm:bearer"}}

saml:Conditions

● @NotBefore

● @NotOnOrAfter

● AudienceRestriction

Condition @NotOnOrAfter must be set.

4.2.5.1 User Mapping

An identity provider must be configured as a logon option for each database user. The following types of user

mapping are supported:

● SAP HANA-based user mappings:

The mapping to an SAP HANA 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>

● 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:

<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid- format:unspecified"SPProvidedID="BILLG">zgc2VLavgYy4hsohfYPM21</NameID>

Note

If an SAP HANA-based user mapping exists for a given identity provider and a conflicting SPProvidedID is sent

from the identity provider, an error is returned.






5 SAP HANA Authorization

When a user accesses the SAP HANA database using a client interface (such as ODBC, JDBC, MDX), his or herability to perform database operations on database objects is determined by the privileges that he or she has

been granted.

The authorization concept of the SAP HANA database operates at different levels.

SQL Authorization

● System privileges

System-wide SQL privileges exist to control general system activities and are mainly for administrative

purposes, such as creating schemas, creating and changing users, performing data backups, managing

licenses, and so on.

● Object privileges

For each SQL statement type (for example, SELECT, UPDATE, or CALL), a corresponding object privilegeexists. If a user wants to execute a particular statement on a database object (for example, table, view, or

stored procedure), 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.

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 only be accessed 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.

Row-Level Authorization

In addition to SQL authorization at activity and object level, analytic privileges are used to provide row-levelauthorization on certain kinds of database objects, such as analytic views. Analytic privileges can only be used for

read operations and not for write operations. Using analytic privileges, it is possible to allow a user to see specific

data in a view. An analytic privilege enables the grantee to see certain view rows that are identified by one or more

column values. For example, an analytic privilege could enable the grantee to see only those entries in the SALES

view for the years with the values 2006 to 2008.

Authorization in the SAP HANA Repository

In addition to privileges described above, package privileges provide a further means of allowing access to

different design-time objects that are bundled in packages in the repository of the SAP HANA database.

Authorization in SAP HANA Extended Application Services (SAP HANA XS)



SAP HANA Authorization



Developers of SAP HANA XS applications can create application privileges to authorize user and client access to

their application, for example, to start the application or to perform administrative actions on the application.

Authorization Check

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 aborts the

check and grants access.

5.1 Privileges

The table below describes the types of privileges used by SAP HANA.

Privilege Type Description

System privilege System privileges are SQL privileges that control

general system activities. They are mainly for

administrative purposes, such as creating schemas,

creating and changing users and roles, performing data

backups, managing licenses, and so on.

Object privilege Object privileges are SQL privileges that 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 example,

SELECT, CREATE ANY, ALTER, DROP, and so on).

Currently, SELECT, DROP, and DEBUG are the only

privileges that can be granted on attribute views,

analytic views, and calculation views.

Analytic privilege Analytic privileges are used to allow read access to

data in SAP HANA information models (that is analytic

views, attribute views, and calculation views)

depending on certain values or combinations of values.

Analytic privileges are evaluated during query

processing.

Package privilege Package privileges are used to allow access to and the

ability to work in packages in the repository of the SAP

HANA database.

Packages contain design time versions of various

objects, such as analytic views, attribute views,

calculation views, and analytic privileges.






Privilege Type Description

Application privilege Developers of SAP HANA XS applications can create

application privileges to authorize user and client

access to their application.

Application privileges are granted and revoked through

the procedures GRANT_APPLICATION_PRIVILEGE and

REVOKE_APPLICATION_PRIVILEGE procedure in the

_SYS_REPO schema.

It is not possible to grant application privileges to users

or roles in the SAP HANA studio. It is recommended

that you grant application privileges to roles created in

the repository.

Related Links

SAP HANA SQL Reference

SAP HANA Developer Guide

5.1.1 Analytic Privileges

SQL privileges implement coarse-grained authorization at object level only. Users either have access to an object,

such as a table, view or procedure, or they do not. 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 of which data individual users can see within the same view.

Note

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.

Analytic privileges are intended to control access to SAP HANA information models, that is:

● Attribute views

● Analytic views

● Calculation views

Therefore, all column views modeled and activated in the SAP HANA modeler automatically enforce an

authorization check based on analytic privileges. Column views created using SQL must be explicitly registered

for such a check (by passing the parameter REGISTERVIEWFORAPCHECK).

Note

Analytic privileges do not apply to database tables or views modeled on row-store tables. Access to database

tables and row views is controlled entirely by SQL object privileges.

You create and manage analytic privileges in the SAP HANA modeler.

Note




http://help.sap.com/hana/SAP_HANA_Developer_Guide_en.pdf

http://help.sap.com/hana/html/SAP_HANA_SQL_Reference_en.html





Some advanced features of analytic privileges, namely dynamic value filters, can only be implemented using

SQL. The management of such analytic privileges created in SQL also varies to those created in the SAP HANA

modeler.

5.1.2 Creation and Management of Analytic Privileges

Analytic privileges can be created, dropped, and changed in the SAP HANA modeler and using SQL statements.

The SAP HANA modeler should be used in all cases except if you are creating analytic privileges that use

dynamic procedure-based value filters.

To create analytic privileges, the system privilege CREATE STRUCTURED PRIVILEGE is required. To drop analytic

privileges, the system privilege STRUCTUREDPRIVILEGE ADMIN is required.

In the SAP HANA modeler, repository objects are technically created by the technical user _SYS_REPO, which by

default has the system privileges for both creating and dropping analytic privileges. To be able to create, activate,

drop, and redeploy analytic privileges in the SAP HANA modeler therefore, a database user requires the package

privileges REPO.EDIT_NATIVE_OBJECTS and REPO.ACTIVATE_NATIVE_OBJECTS for the relevant package.

Implications of Creating Analytic Privileges Using SQL

The SAP HANA modeler is the recommended method for creating and managing analytic privileges. However, it is

necessary to use SQL to implement those features of analytic privileges not available in the modeler, that is,dynamic, procedure-based value filters as attribute restrictions.

In the SAP HANA modeler, analytic privileges are created as design-time repository objects owned by the

technical user _SYS_REPO. They must be activated to become runtime objects available in the database. Analytic

privileges created using SQL statements are activated immediately. However, they are also owned by the

database user who executes the SQL statements. This is the main disadvantage of using SQL to create analytic

privileges. If the database user who created the analytic privilege is deleted, all objects owned by the user will also

be deleted. Therefore, if you are using SQL to create analytic privileges, we recommend that you create a

dedicated database user (that is, a technical user) for this purpose to avoid the potential loss of complex modeled

privileges.

An additional disadvantage of creating analytic privileges using SQL is that these analytic privileges are not in theSAP HANA repository and they cannot be transported between different systems.

Granting and Revoking Analytic Privileges

Analytic privileges are granted and revoked as part of user provisioning.

If the analytic privilege was created and activated using the SAP HANA modeler, the analytic privilege is owned by

the _SYS_REPO user. Therefore, to be able to grant and revoke the analytic privilege, a user needs the privilege

EXECUTE on the procedures GRANT_ACTIVATED_ANALYTICAL_PRIVILEGE and

REVOKE_ACTIVATED_ANALYTICAL_PRIVILEGE respectively.






If the analytic privilege was created using SQL, only the owner (that is, the creator) of the analytic privilege can

grant and revoke it.

5.2 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 in the Administration editor of the

SAP HANA studio

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 hierarchies of user access

that can be modeled on business roles. Several standard roles are delivered with the SAP HANA database (for

example, MODELING, MONITORING). You can use these as templates for creating your own roles.

Roles in the SAP HANA database can exist as runtime objects only, or as design-time objects that become

runtime objects on activation.

Role Structure

A role can contain any number of the following privileges:

● System privileges for administrative tasks (for example, AUDIT ADMIN, BACKUP ADMIN, CATALOG READ)

● Object privileges on database objects (for example, SELECT, INSERT, UPDATE)

● Package privileges on repository packages (for example, REPO.READ, REPO.EDIT_NATIVE_OBJECTS,

REPO.ACTIVATE_NATIVE_OBJECTS)

● Analytic privileges on SAP HANA information models

● Application privileges for enabling access to SAP HANA XS applications

Note

Application privileges cannot be granted to roles in the SAP HANA studio.

A role can also extend other roles.

Role Modeling

You can model roles in the following ways:

● As runtime objects on the basis of SQL statements






● As design-time objects in the repository of the SAP HANA database

It is recommended that you model roles as design-time objects for the following reasons.

Firstly, 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 productive system. This avoids unnecessary

duplication of effort.

Secondly, 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 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.

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. Although there is no mechanism of preventing a user from doing this, 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.

5.2.1 Standard Roles

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 hierarchies of user access

that can be modeled on business roles. Several standard roles are delivered with the SAP HANA database. You

can use these as templates for creating your own roles.

Note

The roles listed below are runtime objects. They are not roles created in the repository.

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 create

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

activated views, regardless of any other analytic privileges that apply. Although






Role Description

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 begranted to users, particularly in productive 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

statistics 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.

CONTENT_ADMIN This role contains the same privileges as the MODELING role but with additionalauthorization to grant these privileges 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 creating roles for content administrators.

SUPPORT This role is meant to be used for support cases.

This role contains privileges for read-only access to all metadata, the current

system status in system and monitoring views, and the data of the statistics server.

Additionally, it contains the privileges to access the base information of the system

and monitoring views. Without the support role, this base information can be

selected only by the SYSTEM user. Only the monitoring views can be selected by

everyone.

To restrict this role to support usage, the following restrictions apply:

● It cannot be granted to the SYSTEM user.

● It cannot be granted to more than one user at a time.

● It cannot be granted to another role.

● No role can be granted to it.

● Only system privileges can be granted to this role.

Note

If you need to grant other privileges to the user who will be in the support

role, it is recommended to grant these privileges to the user and not to theSUPPORT role.

● With every update of the SAP HANA database software, the privileges in this

role are reset.






5.3 Authorization in the Repository of the SAP HANADatabase

The following sections explains how the authorization concept is applied in the repository of the SAP HANA

database. The following aspects are covered:

● The privileges required by database users to work in the repository

● The implications of _SYS_REPO ownership of repository objects

● How privileges are granted and revoked on the activated runtime versions of repository objects

Related Links

SAP HANA Developer Guide

5.3.1 User Authorization for the Repository

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, and roles. All

repository methods that provide read or write access to content are secured with authorization checks. To allow

database users to work with packages in the repository, they must have the required package and system

privileges.

In addition, to be able to access the repository in the SAP HANA studio or another client, users need the EXECUTE

privilege on the database procedure SYS.REPOSITORY_REST.

The required privileges can be granted to users directly or indirectly through roles in the SAP HANA studio as part

of user provisioning.

Package Privileges

The SAP HANA database 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 automatically also authorized for all

corresponding sub-packages.

In the SAP HANA database 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

imported package should only be manually edited in exceptional cases.

The database users of developers should be granted the following privileges for native packages:

● REPO.READ

This privilege authorizes read access to packages and design-time objects, including both native and

imported objects.

● REPO.EDIT_NATIVE_OBJECTS

This privilege authorizes all kinds of inactive changes to design-time objects in native packages.







● REPO.ACTIVATE_NATIVE_OBJECTS

This privilege authorizes the user to activate or reactivate design-time objects in native packages.

● REPO.MAINTAIN_NATIVE_PACKAGES

This privilege authorizes the user to update or delete native packages, or create sub-packages of nativepackages.

Developers should only be granted the following privileges for imported packages in exceptional cases:

● REPO.EDIT_IMPORTED_OBJECTS

This privilege authorizes all kinds of inactive changes to design-time objects in imported packages.

● REPO.ACTIVATE_IMPORTED_OBJECTS

This privilege authorizes the user to activate or reactivate design-time objects in imported packages.

● REPO.MAINTAIN_IMPORTED_PACKAGES

This privilege authorizes the user to update or delete imported packages, or create sub-packages of imported

packages.

System Privileges

Developers require the following system privileges to be able to work in the repository:

● REPO.EXPORT

This privilege authorizes the user to export, for example, delivery units.

● REPO.IMPORT

This privilege authorizes the user to import transport archives.

● REPO.MAINTAIN_DELIVERY_UNITS

This privilege authorizes the user to maintain delivery units (DU, DU vendor and system vendor must be the

same).

● REPO.WORK_IN_FOREIGN_WORKSPACE

This privilege authorizes the user to work in a foreign inactive workspace.

5.3.2 _SYS_REPO Authorization in the Repository

The repository of the SAP HANA database stores both runtime objects, such as calculation scenarios, and design-

time objects, such as models used in analytic scenarios (attribute views, analytic views, calculation views, and

analytic privileges). Design-time objects must be activated to become runtime objects so that they can be used by

regular 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

Objects in the repository are however modeled on data objects, such as tables. _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.






5.3.3 Granting and Revoking Privileges on ActivatedRepository Objects

Only the _SYS_REPO user has any privileges on objects in the repository. Therefore, only this user can grant

privileges on them. Since no user can log on as _SYS_REPO, another means of granting privileges is used.

This is provided by stored procedures in the _SYS_REPO schema. These procedures can be used to grant and

revoke privileges on activated objects or schemas, analytic privileges, and roles. Stored procedures are beneficial

because a user is not required to have a privilege in order to grant it.

The following procedures exist:

Activated Object Type Procedure for Grant and Revoke

Modeled objects, such as calculation views ● GRANT_PRIVILEGE_ON_ACTIVATED_CONTENT

● REVOKE_PRIVILEGE_ON_ACTIVATED_CONTENT

Schema containing modeled objects ● GRANT_SCHEMA_PRIVILEGE_ON_ACTIVATED_C

ONTENT

● REVOKE_SCHEMA_PRIVILEGE_ON_ACTIVATED_

CONTENT

Analytic privilege ● GRANT_ACTIVATED_ANALYTICAL_PRIVILEGE

● REVOKE_ACTIVATED_ANALYTICAL_PRIVILEGE

Application privilege ● GRANT_APPLICATION_PRIVILEGE

● REVOKE_APPLICATION_PRIVILEGE

Role ● GRANT_ACTIVATED_ ROLE

● REVOKE_ACTIVATED_ ROLE

Note

Public synonyms of these procedures exist. Therefore, these procedures can be used without specifying

schema _SYS_REPO.

Having the EXECUTE privilege on any of the procedures enables a user to grant or revoke privileges. Using stored

procedures and a technical user for privilege management also changes the behavior in terms of how privileges

are revoked.

With regular SQL, privileges that were granted by a user are revoked when this user is dropped or loses the

privilege that was granted. Also, only the granter can revoke privileges with SQL. Both details are not true with this

approach. Any user with EXECUTE privilege on the revoke privilege procedure can revoke any privilege that was

granted, regardless of the granter. Also, if a user that has granted privileges is dropped, none of the privileges that

the user granted is revoked as part of dropping the user.

When using the SAP HANA studio for privilege management, this behavior is hidden. If privileges on activated

objects or schemas are granted or revoked, the procedures are used automatically.

Caution






Bear in mind that users who can change and activate objects as well as grant privileges on activated objects

have access to all SAP HANA content.

5.4 SAP HANA One Samplers

SAP HANA One includes samplers with public data. The goal of including sample data is to enhance and engage

SAP HANA One customers by demonstrating the capability 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, business and technical description of

the sampler, and instructions about how to uninstall the sampler, if you choose to do so.

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, savingsor 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.






6 Secure Communication in SAP HANA OneLandscape

SAP strongly recommends configuring secure communication among SAP HANA components including SAP

HANA Studio connection (JDBC based) with SAP HANA Server at cloud, client application access to SAP HANA

server at cloud.

SAP HANA supports the following cryptographic libraries for Linux based installation (clients).

● Open SSL (Client)

● SAP Cryptographic Library

Note

If you client application is outside of the SAP HANA One server, you are strongly recommended to configureHTTPS (SSL) for client accessing SAP HANA One.

6.1 Configuring HTTPS Between SAP HANA Database andSAP HANA Studio

6.1.1 Setup on Server-Side

To protect your data during network transmission, only secure connections should be used. We recommend using

the tools provided with OpenSSL to create the certificates required for SSL configuration.

Prerequisites

● The server possesses a public and private key pair and public-key certificate.

The SSL protocol uses public-key technology to provide its protection. Therefore, the server must possess a

public and private key pair and a corresponding public-key certificate. It must possess one key pair and

certificate to identify itself as the server component and another key pair. The key pair and certificate are

stored in the server's own personal security environments (PSE), the SSL server PSE, and the SSL client PSE,

respectively.

Note

In case, your server keys are compromised, replace the certificate.

● You have installed a cryptographic provider such as OpenSSL or the SAP Cryptographic Library.

Caution


Secure Communication in SAP HANA One Landscape




The distribution of the SAP Cryptographic Library is subject to and controlled by German export

regulations and is not available to all customers. In addition, usage of the SAP Cryptographic Library or

OpenSSL library may be subject to local regulations of your own country that may further restrict the

import, use, and export or reexport of cryptographic software. If you have any further questions about thisissue, contact your local SAP office.

Features

By supporting SSL, SAP HANA One can provide the following:

● Server-side authentication

With server-side authentication, the server identifies itself to the client when the connection is established.

This reduces the risk of using fake servers to gain information from clients.● Data encryption

In addition to authenticating the communication partners, the data being transferred between the client and

server is encrypted which provides for integrity and privacy protection. An eavesdropper cannot access or

manipulate the data.

Client-side authentication and mutual authentication are not currently supported.

The following parameters can be used to configure the server connectivity. They are located in the

indexserver.ini file, in the communication section.

Note

Configuration of cryptographic library providers is optional.

The parameters in the following table can be configured for the setup of secure connections.

Table 2: Configuration Parameters on Server-Side

Property Name Property Value Default Description

sslCryptoProvider {sapcrypto | openssl} 1. sapcrypto (if installed)

2. openssl

Cryptographic library

provider to use for SSL

connectivity.

sslKeyStore <file> $HOME/.ssl/key.pem Path to keystore file.

sslTrustStore <file> $HOME/.ssl/trust.pem Path to trust store file.

sslValidateCertificate <bool value> false If set to true, validate the

certificate of the

communication partner.

sslCreateSelfSignedCertifi

cate

<bool value> false If set to true, create a self-

signed certificate if the

keystore cannot be found.






No Configuration Provided

If no configuration for secure connections has been provided, the system determines which cryptographic libraryprovider should be used as follows:

1. Checks whether the environment variable <SECUDIR> is set.

a. If the environment variable <SECUDIR> is set, it tries to load the sapcrypto library using the regular paths

for library lookup. The recommended location of the sapcrypto library is /usr/sap/<SID>/SYS/

global/security/lib.

b. If sapcrypto cannot be loaded, it proceeds with the next cryptographic library provider.

c. If sapcryptowas loaded, it uses the path names given in sslKeyStore and sslTrustStore to check for a

*.pse store.

d. If a PSE store could be found, the system verifies its integrity.

e. If no PSE store could be found or the PSE store’s integrity could not be verified, SSL initialization fails and

SSL is not available.

2. Checks whether OpenSSL is available.

a. If OpenSSL is available, it checks for key certificates at the path given in sslKeyStore and trusted

certificates at the path given in sslTrustStore.

b. If any certificates were found, it checks for the integrity of the certificates.

c. If any of the above fails, SSL initialization fails and SSL is not available.

Configuration Provided

● If the value of the sslCryptoProvider parameter is set, the system tries to initialize the given cryptographic

library provider. Any other installed cryptographic library providers are ignored.

● If the value of the sslCryptoProvider parameter is set but no paths are given for the sslKeyStore and

sslTrustStore parameters, the system uses the default paths for initialization as if no configuration were

provided.

● If the value of the sslKeyStore parameter or the sslTrustStore parameter is set, the system does not check

the default paths. In this case, the sslCryptoProvider parameter must be set.

● If the values of both the sslKeyStore parameter and the sslTrustStore parameter are set, a value for the

sslCryptoProvider parameter also has to be set; otherwise SSL initialization fails and SSL is not available.

6.1.2 Setup on Client-Side (SQLDBC-Based Connections)

Set the parameter values according to the operating system installed on the clients. For SQLDBC-based

connectivity (for example ODBC), the parameters and their names are the same as for the server. Additionally,

the encrypt parameter is available to initiate an SSL-secured connection.






Table 3: Configuration Parameters on Client-Side for SQLDBC-Based Connections


encrypt <bool value> False Enables or disables SSL

encryption.

sslCryptoProvider {sapcrypto | openssl |

mscrypto}1. sapcrypto (if installed)

2. openssl/mscrypto

Cryptographic library

provider to use for SSL

connectivity.

sslKeyStore <file> $HOME/.ssl/key.pem Path to keystore file.

Leave empty when using

mscrypto.

sslTrustStore <file> $HOME/.ssl/trust.pem Path to trust store file.

Leave empty when using

mscrypto.

sslValidateCertificate <bool value> true If set to true, validate the

certificate of the


sslHostNameInCertificate <string value> <empty> Use the given host name

for validation.

Tip

Use this host name

when validating the

communicationpartner’s certificate.

Wildcards are not

allowed. If the given

host name is “*” then

host name validation is

disabled.

sslCreateSelfSignedCertifi

cate

<bool value> false If set to true, create a self-

signed certificate if the

keystore cannot be found.

6.1.3 Setup on Client-Side (JDBC-Based Connections)

For JDBC connections, the parameter names are the same as those for SQLDBC-based connections except for

the missing prefix SSL. Additionally, some additional parameters to further characterize the (Java-based)

keystore and its password are used. If you use JDBC connections, deploy the certificates to the Java keystore.

For JDBC connections, the automatic creation of a self-signed certificate is currently not supported. Therefore,

the createSelfSignedCertificate parameter is not available.






Table 4: Configuration Parameters on Client-Side for JDBC-Based Connections


encrypt <bool value> false Enables or disables SSL

encryption.

validateCertificate <bool value> true If set to true, validate the

certificate of the


hostNameInCertificate <string value> <empty> Use the given host name

for validation.

Tip

Use this host name

when validating thecommunication

partner’s certificate.

Wildcards are not

allowed. If the given

host name is “*” then

host name validation is

disabled.

keyStore <file | store name> <VM default>

keyStoreType <JKS | PKCS12> <VM default>

keyStorePassword <password> <VM default> Password used to access

the keystore.

trustStore <file | store name> <VM default>

trustStoreType <JKS> <VM default>

trustStorePassword <password> <VM default> Password used to access

the trust store.

If you do not specify any values for the *Store* parameters, the system uses the default values.

6.1.4 Setup of SAP HANA Studio Connections (JDBC-Based-Connections)

As a prerequisite for SSL-secured connections to and from SAP HANA studio, the root certificate that was used to

sign the server certificate must be available in the Java trust store. SAP HANA studio allows you to use either the

system-wide trust store or the default user trust store for certificate validation. For more information about how

to import certificates into trust stores, see the Java documentation.






6.2 Configuring HTTPS (SSL) for Client Application Access

To improve the security of your SAP HANA landscape, you can configure the SAP Web Dispatcher to use HTTPS

(SSL) for incoming requests from UI front ends and applications, for example, SAP HANA applications. The

requests are then forwarded to SAP HANA.

The SAP Web dispatcher lies between the Internet and your SAP system. It is the entry point for HTTP(s) requests

into your system. If you want to set up a secure SSL connection (Secure Socket Layer) between client

applications and the SAP Web Dispatcher, the following components are prerequisites:

● SAP Cryptographic library SAPCRYPTOLIB (libsapcrypto.so)

● SAP Cryptographic tool SAPGENPSE

● The SAP root certificate SAPNetCA.cer issued by the SAPNet certificate authority

To configure the SAP Web Dispatcher to use SSL for inbound application requests, perform the following steps:

1. Log on to the SAP HANA server at operating system level with the <SID> adm user.

2. Open the instance profile of your SAP Web Dispatcher.

The SAP Web Dispatcher profile can be found in the following location:

/usr/sap/ <SAPSID> /HDB <instance_nr> / <hostname> /wdisp

3. Add the following parameters to the profile:

wdisp/shm_attach_mode = 6wdisp/ssl_encrypt = 0wdisp/add_client_protocol_header = truessl/ssl_lib = /usr/sap/ <SAPSID> /SYS/global/security/libsapcrypto.sossl/server_pse = /usr/sap/ <SAPSID> /HDB <instance_nr> / <hostname> /sec/SAPSSL.pseicm/HTTPS/verify_client = 0

4. Check and, if necessary, modify the HTTPS port as follows:

icm/server_port_1 = PROT=HTTPS,PORT=443,EXTBIND=1

5. Copy the SAP Cryptographic Library (libsapcrypto.so) to the SAP HANA One server.

To enable secure HTTP communication between Web browsers and the SAP Web Dispatcher using SSL

(HTTPS), you must copy the SAP Cryptographic Library (libsapcrypto.so) to the SAP HANA One server.

The SAP Cryptographic Library libsapcrypto.somust be located in the directory /usr/sap/

<SAPSID>/SYS/global/security/lib/.

6. Install the root certificate SAPNetCA.cer.

Place the root certificate SAPNetCA.cer that you have downloaded from SAP Service Marketplace into the

following directory: /usr/sap/ <SAPSID> /HDB <instance_nr> / <hostname> /sec .

Note

If the /usr/sap/ <SAPSID> /HDB <instance_nr> / <hostname> /sec directory does not exist; you must

create it first.

7. Set the SECUDIR environment variable to point to your instance directory.

In a bash shell, execute the following command: export SECUDIR="/usr/sap/ <SAPSID> /

HDB <instance_nr> / <hostname> /sec"

Alternatively, you can add the export command to the .bashrc profile of your <SAPSID> adm user.






Note

The command you use to set the environment variable (and the .rc file you add it to) depends on the shell

you are using. For the c shell, you can use setenv and .cshrc. However, SECUDIR should already havebeen set automatically during the installation process, for example, in the hdbenv.csh or hdbenv.sh file.

8. Make the sapgenpse file available and executable.

a) Place a copy of the sapgenpse file in the following location: /usr/sap/ <SAPSID> /SYS/global/

security/lib.

b) Set permissions for the file sapgenpse, for example: chmod 777 sapgenpse.

9. Create an SSL key pair and a certificate request:

a) Change to the following directory.

cd /usr/sap/ <SAPSID> /SYS/global/security/lib

b) Add the security directly to your library path.export LD_LIBRARY_PATH=/usr/sap/ <SAPSID> /SYS/global/security/

c) Run the SAP Cryptographic tool SAPGENPSE

./sapgenpse get_pse -p SAPSSL.pse -x <PIN> -r SAPSSL.req "CN= <webdisp> ,

OU= <org_unit> , O= <company> , C= <country> "

For <org_unit> , enter your SID. For CN, enter the host name of the NC host ( <webdisp> , where the

SAP Web dispatcher is installed) in the user LAN, as this is the host that decrypts the SSL. If you do not

use the -x parameter, sapgenpse interactively asks for a personal identification number (PIN). The PIN

request provides extra security since nobody can read the password from the screen or find it in the

command history.

The export command creates two files, one in the sec/ directory and one in the current directory. The file

SAPSSL.req is an ASCII file whose content must be sent to a CA (certification authority). According to

the rules of the CA, the CA will sign the request and return a file with the signed certificate. SAP offers CA

services at http://service.sap.com/Trust , where you can have test certificates signed instantly. There is

also a navigation point called “SSL Test Server Certificates” https://websmp106.sap-ag.de/SSLTest .

10. Import the signed certificate.

Copy and paste the signed certificate into a file on the server hosting the SAP Web Dispatcher and execute

the commands indicated below:

a) Paste the text of the signed certificate into SAPSSL.cer, which is located in the directory /usr/sap/

<SAPSID> /HDB <instance_nr> / <hostname> /sec/.

b) Copy sapgenpse to the directory /usr/sap/ <SAPSID> /HDB <instance_nr> / <hostname> /sec/.

c) Place the certificate SAPNetCA.der that you have downloaded from SAP Service Marketplace into thefollowing directory /usr/sap/ <SAPSID> /HDB <instance_nr> / <hostname> /sec.

d) Import the certificate using the following command.

./sapgenpse import_own_cert -c SAPSSL.cer -p SAPSSL.pse -x <PIN> -r SAPNetCA.cer

Make sure that the date and time settings on the server hosting the SAP Web Dispatcher are correct and

synchronized with the certificate authority (CA) that issued the certificate you import, otherwise the

certificate might be interpreted as invalid.

11. Create a credentials file for the PSE.

The SAP Web Dispatcher requires a password to access the PSE file. Instead of supplying the password in the

profile, you must create a credential file, whose owner has access to the PSE. To create the credentials file,

run the following command:




https://websmp106.sap-ag.de/SSLTest

http://service.sap.com/Trust

https://websmp106.sap-ag.de/SSLTest

http://service.sap.com/Trust



./sapgenpse seclogin -p SAPSSL.pse -x <PIN> -O <SAPSID> adm

If successful, the command creates the file cred_v2 in the directory /usr/sap/ <SAPSID> /

HDB <instance_nr> / <hostname> /sec. Since this file contains the password for the SAP Web dispatcher,

restrict access to the owner by executing the following command in the sec/ directory:

chmod 600 cred_v2

The contents of the sec/ directory on the SAP Web Dispatcher host should now look similar to the following

example output:

blade1:sw1adm> ls -la /usr/sap/<SAPSID>/HDB<instance_nr>/<hostname>/sec/

drwxr-xr-x s1wadm sapsys 4096 2007-06-21 11:32 .

drwxr-xr-x s1wadm sapsys 4096 2007-06-10 11:12 ..

-rw------- s1wadm sapsys 164 2007-06-21 11:32 cred_v2

-rw------- s1wadm sapsys 542 2007-06-21 11:13 dev_sapstart

-rw------- s1wadm sapsys 1655 2007-06-21 10:45 SAPSSL.pse

12. Restart the SAP Web Dispatcher.

sapcontrol -nr <instanceNr> -function SendSignal <pid> <signal>

For example, to restart the SAP Web Dispatcher with the process ID 28155, run the following command:

sapcontrol -nr 00 -function SendSignal 28155 2

You can check the functioning of the SAP Web Dispatcher by starting the SAP Web Dispatcher administration

console under https:// <host_name> /sap/admin. You will require the name and the master passworddefined for the webadm user during installation of the SAP Web Dispatcher. You can also check the logs in the

following directory:

usr/sap/ <SAPSID> adm/HDB <instance_nr> /work

13. Bind the default SSL port to use.

Since only users with superuser authorization rights can bind ports with a number less that (<) 1024 (well-

known ports) on a UNIX system, and the ICM process or the SAP Web Dispatcher should not have these rights

(and ICM cannot have them for technical reasons), the port must be bound by an external program and the

listen socket then transferred to the calling process. You can use the icmbnd command.

Note

The installation process creates the file icmbnd.new, which you must rename to icmbnd. In addition, since

superuser privileges are required to bind ports with a number lower than 1024, you must change the owner

and permissions of the icmbnd command, for example, from <SID> adm to user root.

a) Change the owner of the icmbnd command:

$> chown root:sapsys icmbnd

b) Change the permissions for the icmbnd command:

$> chmod 4750 icmbnd






c) Check the new permissions for theicmbnd command:

$> ls -alrwsr-x 1 root sapsys 1048044 Feb 13 16:19 icmbnd

d) Bind the default SSL port to use.

icmbnd -S <server port> -l <listen port> -p <protocol>

Related Links

SAP Help Portal: SAP Web Dispatcher




http://help.sap.com/saphelp_nw73ehp1/helpdata/en/48/8fe37933114e6fe10000000a421937/frameset.htm



7 SAP HANA One Data Storage Security

The file permissions of the operating system are strictly configured. Therefore, we recommend that you do not

change them after the subscription and configuration of the SAP HANA One.

SAP HANA supports HANA Data volume encryption starting with SAP HANA 1.0 SPS5 (SAP HANA One Rev 48

and onward). The SAP HANA database persistence layer ensures that changes made in the row store or column

store are durable and that the database can be restored to the most recent committed state after a restart. For

this reason, data is stored in persistent disk volumes that are organized in pages.

7.1 Data Volume Encryption

The SAP HANA database persistence layer ensures that changes made in the row store or column store are

durable and that the database can be restored to the most recent committed state after a restart. For this reason,

data is stored in persistent disk volumes that are organized in pages.

Privacy of data on disk can be ensured globally by enabling SAP HANA data volume encryption. If this is the case,

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. 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 persistence encryption page keys. Page keys are valid for acertain range of savepoints and can be changed by executing SQL statements. After switching on persistence

encryption, an initial page key is automatically generated. Page keys are never readable in plaintext, but are

encrypted themselves using a dedicated persistence encryption root key.

During start-up, administrator interaction is not required. The root key is stored using the SAP NetWeaver Secure

Store File System (SSFS) functionality and is automatically retrieved from there. SAP HANA uses SAP NetWeaver

SSFS to protect the root encryption keys that are used to protect all encryption keys used in the SAP HANA

system from unauthorized access.

Note

For more information about SAP NetWeaver SSFS, seeSystem Security for SAP NetWeaver AS ABAP Only .

Persistence encryption does not include:

● Encryption of database redo log files.

Note

If the protection of database redo log files is required, we recommend using operating system facilities,

such as encryption, at the file system level.

● Backups of the database.

Note



SAP HANA One Data Storage Security

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/4c/5bc0fdf85640f1e10000000a42189c/frameset.htm

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/4c/5bc0fdf85640f1e10000000a42189c/frameset.htm



If encryption of backups is required, we recommend using third-party solutions that integrate with the

Backint for SAP HANA functionality for backups.

● Database traces.

Note

For security reasons, we recommend not running the system with extended tracing for more than short-

term analysis, since tracing might expose sensitive data, which would be encrypted by persistence, but not

in the trace. Therefore, you should not keep such trace files on disk beyond the respective analysis task.

7.1.1 Implications of Persistence Encryption for Backup and

Recovery

This topic includes backup and recovery recommendations for data volume encryption.

An SAP HANA database with an encrypted data area can be backed up just like an unencrypted system. The

backup contents are always unencrypted, regardless of the encryption state of the data area of the productive

system.

For recovery, the target system should already have the persistence encryption feature enabled. All data restored

during the data and log recovery phases are then automatically encrypted.

7.1.2 Periodic Administration Tasks for PersistenceEncryption

Certain tasks should be performed periodically regarding data encryption.

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 monitoring of the page keys used for data

encryption and their age.

An administrator can also trigger a re-encryption of the entire data area using the current page key.


SAP HANA One Data Storage Security




8 Auditing Activity in SAP HANA Systems

The auditing feature of the SAP HANA database allows you to monitor and record selected actions performed inyour system. In other words, it provides you with visibility on who did what (or tried to do what) and when.

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

● Changes to auditing 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.

● Changes to system configuration files

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.

A further scenario that cannot be meaningfully audited is the activation of roles in the repository of the SAP HANA

database. This is important to bear in mind if you are using roles created in the repository to grant privileges tousers.

8.1 Audit Policies

Auditing is implemented through the creation and activation of audit polices. 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. For

example, actions in a particular policy are audited only when they are performed by a particular user on a

particular object. When an action occurs, the audit policy is triggered and an audit event is written to the audit

trail.



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 totrack 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 actions

You can include all auditable actions in a single policy, but only in conjunction with a specific user. This is

useful if you want to audit the actions of a particularly privileged user.

● Data manipulation actions

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

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 more information about auditable actions, see the SAP HANA SQL Reference.

Audit Policy Parameters

In addition to the actions to be audited, an audit policy specifies additional 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

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, invalidate views)

are audited.

● Target object(s)

Actions that involve data manipulation require at least one target object. The following target object types are

possible:






○ 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. In addition, procedure is valid only for this action. This means that the action

EXECUTE cannot be combined with any other actions.

Note

An object must exist before it can be named as the target object of an audit policy. However, if the target

object of an audit policy is deleted, the audit policy remains valid. This means that if the object is recreated,

that is the same object type with the same name is created, the audit policy will work for this object again.

● Audited user(s)

It is possible to specify that the actions in the policy be audited only when performed by a particular user. In

the case of a policy that contains all auditable actions, a user must be specified.

Note

Users must exist before they can be named in an audit policy.

● 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.

Related Links

SAP HANA SQL Reference

8.2 Audit Trail

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 the audit trail.

The logging system of the Linux operating system (syslog) is the only supported audit trail target. 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 storage 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 provides 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 sufficient space available.

Note

For test purposes in non-productive systems, you can use a CSV text file as the audit trail. However, you must

not use this for a productive system as it has severe restrictions. Firstly, it is not sufficiently secure. By default,

this file is written to the same directory as trace files, so database users with the system privilege DATA

ADMIN, CATALOG READ, TRACE ADMIN, or INIFILE ADMIN can access it. 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).

For each occurrence of an audited action, one or more audit entries are created.

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.

Audit entries written to the audit trail have the following fields with the following meaning:

Field Description Sample Value

Event Timestamp Time (UTC) of event occurrence 2012-09-19 15:44:53

Service Name Name of the service where the

action occurred

Indexserver

Hostname Name of the host where the action

occurred

myhanablade23.customer.corp

SID System ID HAN

Instance Number Instance number 23

Port Number Port number 32303

Client IP Address IP address of the client application 127.0.0.2

Client Name Name of the client machine lu241511

Client Process ID PID of the client process 19504

Clint Port Number Port of the client process 47273

Policy Name Audit policy that was triggered AUDIT_GRANT

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






Field Description Sample Value

Target Schema Name of the schema where the

action occurred, for example, a

privilege 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

action 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

Role Name Name of the role that was granted

or revoked

MONITORING

Target Principal Name of the target user of the

action, for example, grantee in a

GRANT statement

HAXXOR

Action Status Execution status of the statement SUCCESSFUL

Component Currently not applicable

Section Currently not applicable

Parameter Currently not applicable

Old Value Currently not applicable

New Value Currently not applicable

Comment Currently not applicable

Executed Statement Statement that was executed GRANT SELECT ON SCHEMA

PRIVATE TO HAXXOR

Session ID ID of the session in which the

statement was executed

400006

In both the syslog and CSV file audit trails, the above fields are separated by ';'.

An audit entry therefore looks like this:

<Event Timestamp>;<Service Name>;<Hostname>;<SID>;<Instance Number>;<PortNumber>;<Client IP Address>;<Client Name>;<Client Process ID>;<Client PortNumber>;<Audit Level>;<Audit Action>;<Active User>;<Target Schema>;<TargetObject>;<Privilege Name>;<Grantable>;<Role Name>;<Target Principal>;<ActionStatus>;<Component>;<Section>;<Parameter>;<Old Value>;<NewValue>;<Comment>;<Executed Statement>;<Session Id>;






8.3 Auditing Configuration and Audit Policy Management

To be able to audit database activity, the auditing feature must first be activated for the system. 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.






www.sap.com/contactsap

© 2013 SAP AG 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 AG.

The information contained herein may be changed without prior

notice.

Some software products marketed by SAP AG and its distributors

contain proprietary software components of other software

vendors. National product specifications may vary.

These materials are provided by SAP AG and its affiliated

companies ("SAP Group") for informational purposes only without

http://www.sap.com/contactsap

Documents

SAP_HANA_One_Security_Guide_en330491373020393.pdf