SAP_HANA_Security_Guide_en[1].pdf

PUBLIC

SAP HANA Platform SPS 06 Document Version: 1.2 - 03-09-2013

SAP HANA Security Guide

Table of Contents 1

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2

Before You Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3

SAP HAN HANA A Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1

SAP HAN HANA A Implementation Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2

SAP HANA as a Data Mart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 SAP

3.3

SAP HAN HANA A in a Classic 3-tier Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4

SAP HANA as Technical Infrastructure for Native Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 SAP 12

4

SAP HANA Network and Communication Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1

Communication Channel Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Com 14

4.2

Network Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 17

4.3

Securing Data Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3..1 4.3

Configuring SSL for ODBC/JDBC Client Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3..2 4.3

Configuring SSL for SAP HANA Internal Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 25

4.3..3 4.3

Configuring HTTPS (SSL) for Client Application Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5

SAP SA P HANA User and Role Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.1

User Administration Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2

User Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.3

Standard Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Sta 32

6

SAP HANA Authentication and Single Sign-On. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.1

Logging on to SAP HANA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 36

6.2

Password Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Pas

6.3

Password Blacklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.4

Single Sig Sign n-On Using Kerberos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 43

6.5

Single Sig Sign n-On Using SAML 2.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7

SAP HANA Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.1

Object Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 47

7.2

Analytic Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Ana 48 7.2.1

7.3

Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Rol 49 7.3..1 7.3

7.4

2

Creation and Management of Analytic Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Standard Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Authorization in the Repository of the SAP HANA Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52 Aut 7.4..1 7.4

User Authorization for the Repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.4..2 7.4

_SYS_REPO Authorization in the Repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.4 .4..3

Granting an and d Revokin ing g Privile leg ges on Activated Repo possitory Obje jec cts. . . . . . . . . . . . . . . . . . . . .5 .54 4

PUBLIC © 2013 SAP AG or an SAP affiliate company. All rights reserved.

SAP HANA Security Guide Table of Contents

Table of Contents 1

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2

Before You Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3

SAP HAN HANA A Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1

SAP HAN HANA A Implementation Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2

SAP HANA as a Data Mart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 SAP

3.3

SAP HAN HANA A in a Classic 3-tier Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4

SAP HANA as Technical Infrastructure for Native Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 SAP 12

4

SAP HANA Network and Communication Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1

Communication Channel Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Com 14

4.2

Network Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 17

4.3

Securing Data Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3..1 4.3

Configuring SSL for ODBC/JDBC Client Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3..2 4.3

Configuring SSL for SAP HANA Internal Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 25

4.3..3 4.3

Configuring HTTPS (SSL) for Client Application Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5

SAP SA P HANA User and Role Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.1

User Administration Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2

User Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.3

Standard Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Sta 32

6

SAP HANA Authentication and Single Sign-On. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.1

Logging on to SAP HANA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 36

6.2

Password Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Pas

6.3

Password Blacklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.4

Single Sig Sign n-On Using Kerberos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 43

6.5

Single Sig Sign n-On Using SAML 2.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7

SAP HANA Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.1

Object Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 47

7.2

Analytic Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Ana 48 7.2.1

7.3

Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Rol 49 7.3..1 7.3

7.4

2

Creation and Management of Analytic Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Standard Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Authorization in the Repository of the SAP HANA Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52 Aut 7.4..1 7.4

User Authorization for the Repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.4..2 7.4

_SYS_REPO Authorization in the Repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.4 .4..3

Granting an and d Revokin ing g Privile leg ges on Activated Repo possitory Obje jec cts. . . . . . . . . . . . . . . . . . . . .5 .54 4



8

SAP HANA Data Storage Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 56

8.1

Data Volume Encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 8.1.1

8.2

Periodic Administration Tasks for Persistence Encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Secure Storage of Passwords in SAP HANA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 57 8.2.1

Secure Internal Credential Store. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 58

8.2.2

Secure User Store (hdbuserstore). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

9

Auditing Activity in SAP HANA Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

9.1

Audit Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

9.2

Audit Trail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

9.3

Auditing Configuration and Audit Policy Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 68

10

Security of Logs and Traces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

11

Security for Additional SAP HANA Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 70

11.1

SAP HANA Unified Installer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

11.2

SAP HANA Lifecycle Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

11.3

SAP HANA Extended Application Services (SAP HANA XS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

11.4

SAP HANA Info Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 71

11.5

SAP HANA UI Integration Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

11.6

Application Function Library (AFL). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

11.7

R Integration Integration.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

11.8

SAP HANA In Infformation Composer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

12

SAP HANA Data Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

12.1

SAP HANA Smart Data Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

12.2

SAP HANA Replication Technologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 77

13

Security Ref Refe erence In Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

13.1

Security Con Conffiguration Ch Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80



3

1

Introduction Caution

This guide does not replace the administration or operation guides that are available for productive operations.

Target Audiences ●

Technology consultants

●

Security consultants

●

System administrators

This document is not included as part of the installation guides, configuration guides, technical operation manuals, or upgrade guides. Such guides are only relevant for a certain phase of the software lifecycle, whereas security guides provide information that is relevant for all lifecycle phases.

Why is Security Necessary? As it becomes more and more important for organizations to protect their critical data from unauthorized access and to ensure compliance with a growing number of rules and regulations, the demands on security are also on the rise. As an in-memory computing platform that supports multiple implementation scenarios and use cases – from traditional relational database underneath SAP applications to platform for the development and deployment of innovative new applications – SAP HANA can play an important part in critical IT and application infrastructures. It is therefore essential that you integrate SAP HANA into your infrastructures securely and that you protect your data in SAP HANA.

About this Document This guide provides an overview of the security-relevant information that applies to SAP HANA. It comprises the following main sections: ●

Before You Start

This section contains references to the most important SAP Notes that apply to the security of the SAP HANA appliance software and further helpful resources. ●

SAP HANA Overview

This section provides an overview of SAP HANA and its main deployment scenarios. ●

SAP HANA Network and Communication Security

This section provides an overview of the communication paths used by SAP HANA and the security mechanisms that apply. It also includes recommendations for the network topology to restrict access at the network level.

4


SAP HANA Security Guide Introduction

●

SAP HANA User and Role 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 Authentication and Single-Sign On

This section provides an overview of the authentication mechanisms supported by SAP HANA, including integration into single sign-on environments. ●

SAP HANA Authorization

This section provides an overview of the authorization concept of SAP HANA (privileges and roles), including authorization in the SAP HANA repository. ●

SAP HANA 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 Systems

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

Security Logging and Tracing

This section provides an overview of the trace and log files that contain security-relevant information, for example, so you can reproduce activities if a security breach does occur. ●

SAP HANA Additional Components

This section provides security information that applies to the following components that are part of the SAP HANA landscape:

●

○

SAP Unified Installer

○

SAP Lifecycle Manager

○

SAP HANA Extended Application Services (SAP HANA XS)

○

SAP HANA Info Access

○

SAP HANA UI Integration Services

○

Application Function Library (AFL)

○

R Integration

○

SAP HANA Information Composer

Security for SAP HANA Data Provisioning Technologies

This section provides an overview of the authorization concept of SAP HANA smart access, as well as the security aspects of the various replication technologies supported by SAP HANA. ●

Security Reference Information

This section contains a security configuration checklist that provides general recommendations on security settings for SAP HANA.

SAP HANA Security Guide Introduction


5

2

Before You Start

SAP HANA Guides For more information about the SAP HANA landscape, including installation and administration, see the following resources on SAP Help Portal : ●

SAP HANA Master Guide

●

SAP H ANA Server Installation Guide

●

SAP HANA Master Update Guide

●

SAP HANA Update and Configuration Guide

●

SAP HANA Technical Operations Manual

Configuration You can find the configuration steps for implementing security for SAP HANA in the relevant installation and administration guides.

Important SAP Notes Important SAP Notes that apply to SAP HANA security are listed in the table below.

Note SAP supports that customers install additional tools on the SAP HANA appliance within defined boundaries. It is the responsibility of the customer to ensure that the network channels used by those tools are appropriately protected. For detailed information, see the SAP Notes listed below. In addition, you can find a list of security-relevant SAP Notes on SAP Service Marketplace .

1598623

SAP HANA appliance: Security

1514967

SAP HANA appliance: Central Note

1730928

Using external software in an SAP HANA appliance

1730929

Using external tools in an SAP HANA appliance

1730930

Using antivirus software in an SAP HANA appliance

6


SAP HANA Security Guide Before You Start

1730932

Using backup tools with Backint for SAP HANA

1730996

Nonrecommended external software and software versions

1730997

Nonrecommended versions of antivirus software

1730998

Nonrecommended versions of backup tools

1730999

Configuration changes in SAP HANA appliance

1731000

Nonrecommended configuration changes

Additional Information For more information about specific topics, see the quick links in the table below.

Security

https://sdn.sap.com/irj/sdn/security

Security Guides

https://service.sap.com/securityguide

Related SAP Notes

https://service.sap.com/notes https://service.sap.com/securitynotes

Released platforms

https://service.sap.com/pam

Network security

https://service.sap.com/securityguide

SAP Solution Manager

https://service.sap.com/solutionmanager

SAP NetWeaver

http://sdn.sap.com/irj/sdn/netweaver

In-Memory Computing

http://www.sdn.sap.com/irj/sdn/in-memory

SAP HANA Security Guide Before You Start


7

3

SAP HANA Overview

SAP HANA is SAP's in-memory computing platform designed for performing real-time analytics and developing and deploying real-time applications. For an on-premise deployment, SAP HANA comes preinstalled on certified hardware provided by an SAP hardware partner.

The SAP HANA Database At the core of SAP HANA is the high-performance, in-memory SAP HANA database. It can manage structured and unstructured data, and supports both transactional and analytical use cases. As a traditional relational database, the SAP HANA database can function either as the data provider for classic transactional applications (OLTP) and/or as a data source for analytical requests (OLAP). SAP HANA provides standard database interfaces such as JDBC and ODBC and supports standard SQL with SAP HANA-specific extensions. Several data provisioning mechanisms are possible for getting data from different sources into SAP HANA. For example, in a data mart or analytics scenario, data is replicated into SAP HANA from a source system (or systems) using one of the supported replication technologies (for example, SAP Landscape Transformation (LT) Replication Server). In the case of applications that use SAP HANA as their primary database (such as SAP Business Suite powered by SAP HANA), data is created directly in SAP HANA. For maximum performance, the SAP HANA database holds the bulk of its data in memory. However, it still uses persistent storage to support system restart and recovery with minimal delay and without loss of data in the event of failure. For example, after a power failure, the database can be restarted like any disk-based database and returns to its most recent consistent state. In addition, SAP HANA provides functions for backup and recovery, as well as high availability (disaster recovery and fault recovery).

SAP HANA XS and Development Infrastructure SAP HANA is more than a database management system. It also includes the SAP HANA Extended Application Services (SAP HANA XS), which is fully integrated into the SAP HANA database and provides application server functions. Accessible through HTTP, this server can deliver data via Open Data Protocol (OData) calls and rich HTML user interfaces. For creating new structures and programs, for example modeling database structures, analytical queries, reports and procedures, as well as developing applications, SAP HANA provides a development environment. This development environment is integrated into the SAP HANA studio, which also serves as the main administration tool for SAP HANA. Design-time artifacts, such as custom applications, roles, and application content, are managed in SAP HANA's built-in repository. Design-time objects can be transported from development systems to test and production systems.

8


SAP HANA Security Guide SAP HANA Overview

3.1

SAP HANA Implementation Scenarios

How you implement SAP HANA determines what you need to consider from a security perspective. SAP HANA can be implemented in the following main ways: ● ●

●

As a data mart for reporting and analytics As the primary database in a traditional 3-tier architecture, for example, in SAP NetWeaver Business Warehouse (SAP NetWeaver BW) or SAP Business Suite installations As the technical infrastructure that provides database and application services to native SAP HANA-based applications

3.2

SAP HANA as a Data Mart

In a data mart scenario, data is replicated from a source system such as SAP Business Suite into the SAP HANA database. Reporting is then carried out on the data in SAP HANA (for example, using read-only views, dashboards, and so on). Different architectures can be used in this scenario. For example, SAP HANA can be integrated into the SAP BusinessObjects Business Intelligence (BI) platform as a relational database. The source data can then be analyzed and reported on by SAP BusinessObjects Business Intelligence Suite products. Alternatively, SAP HANA can be accessed directly by BI clients such as Microsoft Excel. In this case, end-user clients connect directly to the database. These architectures are depicted in the following figure:

The implemented architecture determines the extent to which security-related aspects are handled in SAP HANA. However, user and role management in the database layer of SAP HANA is required, at least for technical users and administrators.



9

The following table outlines the relevance of SAP HANA security-related features in the context of this implementatin scenario.

User and Role Management

The extent to which SAP HANA user and role management is required in this scenario depends on your system architecture. If SAP HANA is integrated into a business intelligence solution (for example, SAP BusinessObjects Business Intelligence platform) only as the reporting database, end users and roles are managed in the relevant application server. User and role management in the database layer of SAP HANA is required only for technical database users and administrators. If end users connect to the SAP HANA database directly through a SQL client (for example, SAP BusinessObjects Explorer or Microsoft Excel®), users and roles are managed directly in the database.

Authentication and SSO

The extent to which authentication and SSO is handled in SAP HANA depends on your system architecture in the same way as described above. If SAP HANA is used only as the data store, end-user authentication is handled in the application server. The relevant technical database users are used to authenticate connections to the database. If end users connect to the SAP HANA database directly through a SQL client, the database user is authenticated. End-user clients support the external authentication mechanisms Kerberos and SAML for integration into SSO environments.

Authorization

SAP HANA authorization applies to users managed directly in the database.

Encryption of data communication in the network

Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are supported and recommended for network communication where possible.

Encryption of data persistence layer Data volume encryption ensures that anyone who can access the data volume on disk using operating system commands cannot see the actual data. Auditing

3.3

Actions performed in the SAP HANA database can be audited.

SAP HANA in a Classic 3-tier Architecture

SAP HANA can be used as a relational database in a classic 3-tier architecture (client, application server, and database).

10



This architecture is depicted in the following figure:

In this architecture, security-related features, such as authentication, authorization, encryption, and auditing, are located and enforced primarily in the application server layer. The database is used as a data store only. Applications connect to the database using a technical user, and direct access to the database is only possible for database administrators. End users do not have direct access to either the database itself or the database server on which it is running. As a consequence, security in the database layer is mainly focused on securing administrative access to the database. Typical examples of this architecture are the SAP Business Suite and SAP NetWeaver BW. When SAP HANA is used as a database in these scenarios, the same security approach applies, and specific SAP HANA security features are mainly needed to control access of administrators to the database. The following table outlines the relevance of SAP HANA security-related features in the context of this implementation scenario.

User and role management

End users and roles are managed in the application server layer. For example, SAP Business Suite applications use the user management and authentication mechanisms of the SAP NetWeaver platform, and in particular, SAP NetWeaver Application Server. User and role management in the database layer of SAP HANA is required only for technical database users and administrators.


End-user authentication is handled in the application server layer. The relevant technical database users are used to authenticate connections to the database.



11

Administrators with direct access to the database must be authenticated in the database. Administration clients that access the database via SQL (for example, the SAP HANA studio and the SAP HANA HDBSQL command line tool) support the external authentication mechanisms Kerberos and SAML for integration into SSO environments. Authorization

SAP HANA authorization applies only to technical and administrative database users managed in the database.


Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are supported and recommended for network communication where possible.



3.4 SAP HANA as Technical Infrastructure for Native Applications In addition to the SAP HANA database, SAP HANA includes SAP HANA Extended Application Services (SAP HANA XS). SAP HANA XS embeds a full-featured application server, web server, and development environment within SAP HANA itself. Applications can be deployed directly on SAP HANA XS, which exposes the applications to end users via a web interface. This architecture is depicted in the following figure:

12



Native SAP HANA applications rely on the security-related features of SAP HANA. In particular, users of native SAP HANA applications must have a user in the SAP HANA database. The following table outline the relevance of SAP HANA security-related features in the context of this implementation scenario.

User and role management

User and roles are managed fully in SAP HANA.


The database user is used to authenticate not only users connecting to the database via the SQL interface, but also to HTTP clients that connect to SAP HANA XS. Several mechanisms are supported for the integration of HTTP access via SAP HANA XS into SSO environments, including SAML, X.509 client certificates, and SAP logon tickets.

Authorization

User access to native SAP HANA applications and applications functions is determined by the privileges granted to the database user.


Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are supported and recommended for network communication where possible. The SAP Web Dispatcher is recommended to secure connections between HTTP client applications and SAP HANA.





13

4 SAP HANA Network and Communication Security The components of an SAP HANA landscape communicate via different network communication channels. It is recommended security practice to have a well-defined network topology to control and limit network access to SAP HANA to only those communication channels required for your scenario, and to apply appropriate additional security measures, such as encryption, where necessary. This can be achieved through different means, such as separate network zones and network firewalls, and through the configuration options provided by SAP HANA (for example, encryption). The exact setup depends on your environment, your implementation scenario, and your security requirements and policies. The detailed network set-up and recommendations are described in the SAP HANA Master Guide . This chapter contains only some additional security-relevant information.

SAP HANA Master Guide

4.1

Communication Channel Security

The network communication channels used by SAP HANA can be categorized into those used for database clients connecting to SAP HANA and those used for internal database communication. SAP recommends using encrypted communication channels where possible.

Overview of Connections To support the different SAP HANA scenarios and set-ups, SAP HANA has different types of network communication channels: ●

●

Channels used for external access to SAP HANA functionality by end-user clients, administration clients, application servers, and for data provisioning via SQL or HTTP Channels used for SAP HANA internal communication within the database or in a distributed scenario for communication between hosts

The connections between SAP HANA and external components and applications can be categorized as follows: ●

Connections used for administrative purposes

Note The SAP HANA studio is the main administration client. ●

Connections used for data provisioning

●

Connections from database clients that access the SQL interface of the SAP HANA database

●

Connections from HTTP(S) clients

●

Outgoing connections

14


SAP HANA Security Guide SAP HANA Network and Communication Security

You can see an example of what these connections look like in the diagram below. Network connections are depicted by dotted arrows. The direction of each arrow indicates which component is the initiator (start of arrow) and which component is the listener (end point of arrow). Administrative access to and from SAP HANA via the SAP HANA studio is depicted by the blue dotted arrows. Port numbers are shown with a pink background. The xx in the port numbers stands for the number of your SAP HANA instance. The diagram shows all the network channels used by the SAP HANA software. The SAP HANA appliance has additional network services such as SSH for administrative access. For the purposes of illustration, the diagram shows a single-host installation of SAP HANA. However, the connections shown apply equally to a distributed scenario.

In addition, the different components of SAP HANA, as well as the hosts in a distributed scenario, communicate with each other via the internal SAP HANA connections. These connections are also used in system replication scenarios for communication between a primary site and a secondary site to ensure high availability in the event of a data center failure.



15

In the following image of a distributed scenario, the internal communication between multiple hosts is depicted by blue dotted lines.

For more information about the connections described and illustrated above, including the protocols used and the relevant ports numbers, see the SAP HANA Master Guide .

Communication Encryption SAP HANA supports encrypted communication for network communication channels. 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. Alternatively, virtual private network (VPN) tunnels can be used for the transfer of encrypted information. For more information about the connections that can be secured using encryption, see Securing Data Communication.

Securing Data Communication [page 18]

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

16



SAP HANA Master Guide SAP HANA Administration Guide

4.2

Network Security

To integrate SAP HANA securely into your network environment, the following general recommendations apply. We recommend that you operate the different components of the SAP HANA appliance in separate network zones. In order to prevent unauthorized access to the SAP HANA appliance and the SAP HANA database through the network, we recommend the application of network firewall technology to create network zones for the different components and to restrictively filter the traffic between these zones implementing a "minimum required communication" approach.

Note It is strongly recommended that you apply the measures in this document to protect access to the SAP HANA database's internal communication channels and thus mitigate the risk of unauthorized access to these services. The relevant network zones depend your specific application scenario and your network infrastructure. For more information, see SAP HANA Master Guide . We recommend that you operate the SAP HANA appliance in a protected data center environment.Only dedicated authorized network traffic should be allowed from other network zones (for example, user access from the client network zone), as follows: ●

●

●

Clients accessing external standard database functionality, for example by SQL, only require access to the database client access port. Clients (for example, browser applications) accessing SAP HANA through the HTTP access feature of SAP HANA Extended Application Services (SAP HANA XS), for example SAP HANA UI Toolkit for Info Access require access to the SAP HANA XS ports. Some administrative functions (for example, starting and stopping the SAP HANA instance) require access to the administrative ports.

Database internal communication channels are only used for the following: ●

Communication within the database

●

Communication between hosts in distributed scenarios

●

Communication between a primary site and a secondary site in system replication scenarios

Note the following network security considerations for single-host, distributed, and high-availability scenarios: ●

In a single-host scenario, access to the network ports for database internal communication from other network hosts is blocked by default. We recommend that you do not change this setting. The internal communication ports are bound to localhost.

Note In single-host scenarios, the same communication channels are used for communication between the different processes on a single host, and the internal IP addresses/ports are by default bound to the localhost interface. Prior to SPS 06, these ports were by default bound to all network interfaces.



17

●

In a distributed scenario (that is, one instance of SAP HANA on multiple hosts), internal network communication takes place between the hosts at one site via ports 3xx01-3xx07. Certified SAP HANA hosts contain a separate network interface card that is configured as part of a private network using separate IP addresses and ports. We recommend operating all hosts in a dedicated subnetwork. To prevent unauthorized access to the database via the internal communication channels in distributed systems, we recommend that you prevent access to these network channels and ports from outside the system. There are a number of ways to isolate internal network ports from the client network: Using the SAP HANA configuration option to route communication between the hosts of a distributed environment onto the specified network and bind those internal network services exclusively to the network interface This feature cannot be used in the presence of a secondary site. For more information, see the SAP HANA Administration Guide .

○

○

Using operating system commands (for example, iptables), and/or network device configuration

○

Using network firewall functions to block access to internal ports in specific network zones

If your setup does not permit isolating internal network communication, you should consider using encryption to protect the internal communication. ●

In system replication scenarios, the internal communication channels used for communication between the hosts of a distributed environment must be protected from unauthorized access by blocking access to the respective network ports and network channels.

Note To prevent unauthorized access to the SAP HANA database, the internal communication channels between the primary site and the secondary site in a system replication scenario need to be protected. This may include filtering access to the relevant ports and channels by firewalls, implementing network separation, or applying additional protection at the network level (for example, VPN, IPSec). We recommend routing the connection between the two sites over a special site-to-site high-speed network, which typically already implements security measures such as separation from other network access and encryption or authentication between sites. The details of security measures and implementation of additional network security measures depend on your specific environment. For more information about network and security aspects, see the SAP HANA Master Guide and the SAP HANA Administration Guide . Additional network configurations may be required depending on the implemented replication technology.

SAP HANA Replication Technologies [page 77] SAP HANA Master Guide SAP HANA Administration Guide

4.3

Securing Data Communication

SAP HANA supports encrypted communication for client-server and internal communication. The communication between the following components can be secured using the secure sockets layer (SSL) protocol:

18



SAP HANA and data providers

SAP HANA Replication Technologies [page 77]

SAP HANA database and external clients via ODBC/ ODBC or JDBC connections

Configuring SSL for ODBC/JDBC Client Access [page

SAP HANA and clients via HTTP (SAP HANA XS)

Configuring HTTPS (SSL) for Client Application Access

19] [page 26]

Software Update Manager for SAP HANA and SAP HANA studio

SAP HANA Lifecycle Manager [page 70]

Software Update Manager for SAP HANA and SAP Service Marketplace

Note SAP HANA needs an SAP Service Marketplace user (S-user) to access SAP Service Marketplace. These credentials are sent only by encrypted communication channels using an HTTPS connection. Software Update Manager for SAP HANA and SAP Host Agent SAP HANA information composer and internet browser SAP HANA Information Composer [page 75] SAP HANA database internal communication, communication between hosts in distributed SAP HANA systems, and communication between hosts at the different sites in a system replication scenario

4.3.1

Configuring SSL for SAP HANA Internal Communication

[page 25]

Configuring SSL for ODBC/JDBC Client Access

You can use the Secure Sockets Layer (SSL) protocol to secure communication between the SAP HANA database and clients that access the SQL interface of the database. Implementing SSL for client-to-server communication provides the following: ●

●

Server-side authentication The server identifies itself to the client when the connection is established. This reduces the risk of using fake servers to gain information from clients. Data encryption In addition to server authentication, 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 supported. SSL must be configured on both the server and the client.



19

Note The connection parameters for ODBC-based connections can also be used to configure SSL for connections from ABAP applications to SAP HANA using the SAP Database Shared Library (DBSL). To pass the connection parameters to the DBSL, use the following profile parameter: dbs/hdb/connect_property = param1, param2, ...., paramN

The connection parameters are used for both the primary ABAP connection and secondary connections.

4.3.1.1 Server-Side SSL Configuration for ODBC/JDBC Client Access You can use the Secure Sockets Layer (SSL) protocol to secure communication between the SAP HANA database and clients that access the SQL interface of the database. SSL must be configured on both the server and the client. Before you can configure SSL on the SAP HANA server, the following prerequisites must be met: ●

The server possesses a public and private key pair and a public-key certificate The SSL protocol uses public-key technology to provide its protection. The server must possess a public and private key pair and a corresponding public-key certificate. It uses these to identify itself as the server component to a requesting client. The key pair and certificate are stored in the server's own personal security environment (PSE). We recommend using the tools provided with OpenSSL to create the certificates required for SSL configuration.

Caution If your server's keys are compromised, you must replace the key and the certificate. For more information about public-key technology, see SAP NetWeaver 7.4 on SAP Help Portal under NetWeaver Library: Function-Oriented View

Security

Digital Signatures and Encryption

SAP

Public-Key

Technology . ●

You have installed a cryptographic service provider on the server. The SAP HANA server supports the following cryptographic libraries: ○

○

OpenSSL The OpenSSL library is installed by default. SAP Cryptographic Library You must download the SAP Cryptographic Library from SAP Service Marketplace as the standard installer does not provide the required binaries.

Caution 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 re-export of cryptographic software. If you have any further questions about this issue, contact your local SAP office.

20



You configure SSL for the server in the communication section of the indexserver.ini configuration file. The following parameters are relevant:

sslCryptoProvider

{sapcrypto | openssl}

sapcrypto (if installed)

Cryptographic provider used for SSL connection

openssl sslKeyStore

$HOME/.ssl/key.pem

Path to the keystore file that contains the server’s private key

Note If you specify a value for this parameter, you should also explicitly specify a cryptographic provider in the sslCryptoProvider parameter to avoid configuration issues. sslTrustStore

$HOME/.ssl/trust.pem Path to trust store file that contains the server’s certificate

Note If you specify a value for this parameter, you should also explicitly specify a cryptographic provider in the sslCryptoProvider parameter. sslCreateSelfSignedCe rtificate

false

If set to true, a self-signed certificate is created if the keystore cannot be found.

It is not necessary to configure a cryptographic provider or any of the above parameters explicitly. The default configuration can be used. If this is the case, SSL is initialized on system start as follows: The system checks whether or not the environment variable is set. If the environment variable is set, the system tries to load the SAP Cryptographic Library using the default paths for library lookup. The recommended location of the SAP Cryptographic Library is /usr/sap//SYS/global/ security/lib. If the environment variable is not set or if the SAP Cryptographic Library cannot be loaded, the system proceeds with the next cryptographic provider – OpenSSL (step 7). If the SAP Cryptographic Library could be loaded, the system looks for a *.pse store in the locations specified in the sslKeyStore and sslTrustStore parameters. If a PSE store is found, the system verifies its integrity.



21

If a PSE store cannot be found or the PSE store’s integrity cannot be verified, SSL initialization fails, and SSL is not available. The system checks whether or not OpenSSL is available. If OpenSSL is available, the system looks for the server’s private key in the location specified in the sslKeyStore parameter and for the server certificate in the location specified in the sslTrustStore parameter. If certificates are found, the system verifies their integrity. If any of the above fails, SSL initialization fails and SSL is not available. If you do specify a cryptographic provider, that is you specify a value for the sslCryptoProvider parameter, any other installed cryptographic providers are ignored. To initialize SSL, the system then uses either the default paths or the user-configured paths specified in the sslKeyStore and sslTrustStore parameters. Note that if you enter specific values in these parameters, it is recommended that you specify a value in the sslCryptoProvider parameter to avoid configuration issues

4.3.1.2 Access

Client-Side SSL Configuration for ODBC/JDBC Client

You can use the Secure Sockets Layer (SSL) protocol to secure communication between the SAP HANA database and clients that access the SQL interface of the database. SSL must be configured on both the server and the client. The client-side configuration required to secure client-to-server communication depends on whether the client communicates with the server via an ODBC-based or a JDBC-based connection. For ODBC-based connections, the configuration properties and their names are the same as the server parameters. In addition, the encrypt property is available to initiate an SSL-secured connection. You set the properties according to the operating system installed on the clients. The following properties are relevant for ODBC client configuration:

encrypt

sslCryptoProvider

{sapcrypto | openssl | mscrypto}

False sapcrypto (if installed)

Enables or disables SSL encryption Cryptographic library provider used for SSL communication

openssl mscrypto sslTrustStore

$HOME/.ssl/trust.pem Path to trust store file that contains the server’s certificate(s) Typically, the trust store contains the root certificate or the certificate of the certification authority that signed the server’s certificate.

22



Note If you are using the cryptographic library mscrypto, leave this property empty. sslValidateCertificate

true

If set to true, the server’s certificate is validated

sslHostNameInCertific ate

Host name used to verify server’s identity The host name specified here is used to verify the identity of the server instead of the host name with which the connection was established. For example, in a single-host system, if a connection is established from a client on the same host as the server, a mismatch would arise between the host named in the certificate (actual host name) and the host used to establish the connection (localhost).

Note Wildcards are not permitted. If you specify the host name as "*", then this parameter has no effect.

For JDBC connections, the properties for configuring SSL are the same as those for ODBC-based connections above but without the prefix SSL. Some additional properties are used to characterize the Java-based keystore and its password.

Note When the client validates the server certificate against the CA certificate, it uses the Java keystore of the running VM (virtual machine) by default. This keystore is part of the Java installation and is located at $ {JAVA_HOME}/jre/lib/security/cacerts. It is not recommended that you store your CA certificate or public server certificates in this keystore, but in the personal keystore instead. In the SAP HANA studio, you can make this setting in a system's connection properties. The personal keystore is defined as $HOME/.keystore. A different system keystore can be defined using the javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword properties of the JVM. If you do not have a working public key



23

infrastructure (PKI), you can also suppress server certificate validation entirely. For more information, see the SAP HANA Administration Guide . The following properties are relevant for JDBC client configuration:

encrypt

false

Enables or disables SSL encryption

validateCertificate

true

If set to true, the server’s certificate is validated.

hostNameInCertificate

Host name used to verify server’s identity The host name specified here is used to verify the identity of the server instead of the host name with which the connection was established. For example, in a single-host system, if a connection is established from a client on the same host as the server, a mismatch would arise between the host named in the certificate (actual host name) and the host used to establish the connection (localhost).

Note Wildcards are not permitted. If you specify the host name as "*", then this property has no effect. keyStore

Location of the Java keystore

keyStoreType

Java keystore file format

keyStorePassword

Password to access the private key from the keystore file

trustStore

Path to trust store file that contains the server’s certificate(s) Typically, the trust store contains the root certificate or the certificate of the certification authority that signed the server’s certificate.

trustStoreType

24


File format of trust store file


trustStorePassword

Password used to access the trust store file where the server certificate(s) are stored

SAP HANA Administration Guide

4.3.2 Configuring SSL for SAP HANA Internal Communication The Secure Sockets Layer (SSL) protocol is used to secure internal network communication between the individual components of an SAP HANA system on a single host and also between multiple hosts if the system is distributed.

Context As a host can both initiate a connection with another host (client role) and be the target of a connection initiated by another host (server role), each host requires 2 personal security environments (PSEs) – a server PSE and a client PSE. This is necessary because every host is verified with its fully qualified domain name (FQDN). A host’s server PSE contains the private key and certificate (the server certificate) with which it can identify itself to other hosts. Its client PSE contains the certificate with which it can validate the identity of other hosts. Typically, this is the root certificate or the certificate of the certification authority that signed the server’s certificate. We recommend that you use a dedicated Certification Authority (CA) to sign all certificates used for internal communication. The process for configuring SSL for SAP HANA database internal communication is as follows:

Procedure Download the SAP Cryptographic Library from SAP Service Marketplace. This is necessary because the standard installer does not provide the required binaries. Create a CA for the SAP HANA installation using external tools, for example, the OpenSSL command line tool. We recommend storing your CA certificate in $DIR_INSTANCE/ca. This is typically the root certificate. On every host, create the required server certificates. The common name (CN) must be the FQDN of the host you get by reverse DNS lookup. The other fields describe your organization. Sign the certificates with the CA.



25

On every host, create a local keystore named SAPSSLS.pse in directory $SECUDIR and import the server key and certificate. On every host, create a local keystore named SAPSSLC.pse in directory $SECUDIR and import the CA certificate (or root certificate). Activate SSL. In the communication section of the file global.ini, create the parameter ssl with the value on.

4.3.3

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.

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

Procedure Log on to the SAP HANA server at operating system level with the adm user. Open the instance profile of your SAP Web Dispatcher. The SAP Web Dispatcher profile can be found in the following location: /usr/sap/ /HDB / /wdisp

Add the following parameters to the profile: wdisp/shm_attach_mode = 6 wdisp/ssl_encrypt = 0 wdisp/add_client_protocol_header = true ssl/ssl_lib = /usr/sap/ /SYS/global/security/libsapcrypto.so ssl/server_pse = /usr/sap/ /HDB / /sec/SAPSSL.pse icm/HTTPS/verify_client = 0

Check and, if necessary, modify the HTTPS port as follows: icm/server_port_1 = PROT=HTTPS,PORT=443,EXTBIND=1

Copy the SAP Cryptographic Library (libsapcrypto.so) to the SAP HANA blade.

26



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 blade. The SAP Cryptographic Library libsapcrypto.so must be located in the directory /usr/sap/ /SYS/global/security/lib/. 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/ /HDB / /sec .

Note /HDB / /sec directory does not exist; you must If the /usr/sap/ create it first.

Set the SECUDIR environment variable to point to your instance directory. / In a bash shell, execute the following command: export SECUDIR="/usr/sap/ HDB / /sec" Alternatively, you can add the export command to the .bashrc profile of your 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 have been set automatically during the installation process, for example, in the hdbenv.csh or hdbenv.sh file. Make the sapgenpse file available and executable. a) Place a copy of the sapgenpse file in the following location: /usr/sap/ /SYS/global/ security/lib. b) Set permissions for the file sapgenpse, for example: chmod 777 sapgenpse. Create an SSL key pair and a certificate request: a) Change to the following directory. cd /usr/sap/ /SYS/global/security/lib b) Add the directory containing the security libraries to your library path. export LD_LIBRARY_PATH=/usr/sap/ /SYS/global/security/lib c) Run the SAP Cryptographic tool SAPGENPSE ./sapgenpse get_pse -p SAPSSL.pse -x -r SAPSSL.req "CN= , OU= , O= , C= "

For , enter your SID. For CN, enter the host name of the NC host ( , 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. Import the signed certificate.



27

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 Paste the the text of of the sign signed ed certif certifica icate te into into SAPSSL.cer, which is located in the directory /usr/sap/ /HDB /HDB / /sec/. /sec/ b) Copy sapgenpse to the directory /usr/sap/ /HDB /HDB / /sec/. /sec/ c) Place Place th the e cer certif tifica icate te SAPNetCA.cer that you have downloaded from SAP Service Marketplace into the following directory /usr/sap/ /HDB /HDB / /sec. /sec d) Import the certif certificate icate using the followin following g command. command. ./sapgenpse import_own_cert -c SAPSSL.cer -p SAPSSL.pse -x -r SAPNetCA.cer -r

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. 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: ./sapgenpse seclogin -p SAPSSL.pse -x -O -O adm adm

If successful, the command creates the file cred_v2 in the directory /usr/sap/ / HDB / /sec. Since this file contains the password for the SAP Web dispatcher, /sec 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//HDB//sec/ /usr/sap//HDB//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

Restart the SAP Web Dispatcher. sapcontrol -nr -function SendSignal -function

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:// /sap/admin. You will require the name and the master password /sap/admin defined for the webadm user during installation of the SAP Web Dispatcher. You can also check the logs in the following directory: usr/sap/ adm/HDB adm/HDB /work /work

Bind the default SSL port to use.

28



Since only users with superuser authorization rights can bind ports with a number less that (<) 1024 (wellknown 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 adm to user root. adm a) Ch Chan ange ge th the e owne ownerr of th the e icmbnd command: $> chown root:sapsys icmbnd

b) Cha Change nge the perm permiss issions ions for the icmbnd command: $> chmod 4750 icmbnd

c) Che Check ck the the new new perm permiss issions ions for the icmbnd command: $> ls -al rwsr-x 1 root sapsys 1048044 Feb 13 16:19 icmbnd

d) Bin Bind d the the defau default lt SSL SSL port port to use. use. icmbnd -S -l -l -p -p

http://help.sap.com/saphelp_nw73ehp1/ http://help.sap.com/sa phelp_nw73ehp1/helpdata/en/48/ helpdata/en/48/8fe37933114e6fe100 8fe37933114e6fe10000000a421937/fram 00000a421937/frameset.htm eset.htm



29

5

SAP HANA User and Role Management

Every user who wants to work directly with the SAP HANA database must have a database user with the necessary privileges. After successful logon, the user's authorization to perform the requested operations on the requested objects is verified. This is determined by the privileges that the user has been granted. The user must have both the privilege to perform the operation and the privilege 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. A role is a set of privileges. Roles are the standard mechanism of granting privileges as they allow you to implement both fine-grained and coarse-grained reusable authorization concepts that can be modeled on business roles. Several standard roles are also delivered with the SAP HANA database (for example, MODELING, MONITORING). You can use these as templates for creating your own roles.

Roles [page 49]

A role is a collection of privileges that can be granted to either a user or another role in runtime.

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

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 You can create roles in runtime on the basis of SQL statements or as design-time objects in the repository of the SAP HANA database. 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 You can perform all user administration tasks from the command line using SQL requests. This is useful when using scripts for automated other SQL tool) processing.

30


SAP HANA Security Guide SAP HANA User and Role Management

SAP NetWeaver Identity Management

SAP NetWeaver Identity Management 7.2 Support Package Stack 3 and higher contains a connector to the SAP HANA database. With SAP NetWeaver Identity Management you can perform the following user administration tasks in the SAP HANA database: ●

Creating and deleting user accounts

●

Assigning roles

Note Only roles created in runtime are supported. ●

SAP HA HANA NA Li Life fecy cycle cle Ma Mana nage gerr

Setting passwords for users

You can You can us use e SAP SAP HA HANA NA Li Life fecy cycle cle Ma Mana nage gerr to to per perfo form rm pos postt-in inst stal allat lation ion steps including changing user passwords.

SAP HANA Administration Guide SAP HANA Developer Guide SAP NetWeaver Identity Management SAP HANA Update and Configuration Guide

5.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 Database users that correspond to real people are 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 database users do not correspond to real real people. They are therefore not dropped if a person leaves the organization. This means that they should be used for administrative tasks such as creating objects and granting privileges for a particular application. Some technical users are available as standard, for example, the users SYS and _SYS_REPO. Other technical database users are 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. The only difference between them is conceptual.



31

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

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.

The initial password is specified during installation by your hardware vendor. After handover, it is important that you change this password. A user administrator (that is, a user with the system privilege USER ADMIN) can do this in the SAP HANA studio. It is also possible as part of a system rename with SAP HANA lifecycle manager.

Caution Do not use the SYSTEM user for day-to-day activities. Instead, use this user to create dedicated database users for administrative tasks and to assign privileges to these users. It is recommended that you then deactivate the SYSTEM user (for example, using the SQL statement ALTER USER SYSTEM DEACTIVATE USER NOW ). You can still use the SYSTEM user as an emergency user even if it has been deactivated. Any user with the system privilege USER ADMIN can reactivate it. If you want to ensure that an administrator does not do this surreptitiously, it is recommended that you create an audit policy monitoring ALTER USER statements.

adm where sid is the ID of the database system

32

The adm user is an operating system user and is also referred to as the operating system administrator.


The initial password is specified during installation by your hardware vendor. After handover, it is important that you change this password. A system administrator can do this at the operating system


This operating system user has unlimited access to all local resources related to SAP systems.

level. It is also possible as part of a system rename with SAP HANA lifecycle manager.

This user is not a database user but a user at the operating system level. SYS

_SYS_STATISTICS

_SYS_REPO

_SYS_DATAPROV

_SYS_AFL


SYS is a technical database user. It is the owner of system objects such as system tables and monitoring views.

Not applicable

_SYS_STATISTICS is a technical database user used by the statistics server of the SAP HANA database. The statistics server is one of the main components 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

_SYS_REPO is a technical database user used by the SAP HANA 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.

Not applicable

_SYS_DATAPROV is a technical database user used by the unified data provisioning feature. This user is the owner of all views, tables, and procedures of that feature. Unified data provisioning provides a set of modeling, administration and monitoring capabilities for provisioning data into SAP HANA.

Not applicable

_SYS_AFL is a technical user that owns all objects for Application Function Libraries.

Not applicable

This is a technical database user. It is not possible to log on with this user.

This is a technical database user. Although _SYS_STATISTICS logs on internally, it not possible to log on directly with this user.




33


34



6 SAP HANA Authentication and Single SignOn The identity of every database user accessing the database is verified through a process called authentication. The SAP HANA database supports several authentication mechanisms. ●

User name/password authentication When accessing SAP HANA, users authenticate themselves by entering their database user name and password.

Note For some administrative operations (such as start-up, shutdown, and database recovery), the credentials of the SAP operating system user (adm) are also required. ●

Authentication using external user repositories ○

Kerberos A Kerberos authentication provider can be used to authenticate users accessing SAP HANA in the following ways: ○

○

Directly from SQLDBC (for example, ODBC) and JDBC database clients within a network (for example, the SAP HANA studio) Indirectly from front-end applications such as SAP BusinessObjects applications using Kerberos delegation

Note Kerberos is not supported for HTTP access to SAP HANA by means of SAP HANA Extended Services (SAP HANA XS). ○

Security Assertion Markup Language (SAML) ○

○

A SAML bearer assertion can be used to authenticate users accessing SAP HANA directly from ODBC/JDBC database clients. SAP HANA can act as service provider to authenticate users accessing via HTTP by means of SAP HANA XS.

Note A user who connects to the database using an external authentication provider must also have a database user known to the database. SAP HANA maps the external identity to the identity of an internal database user. ●

●

X.509 client certificates For HTTP access to SAP HANA by means of SAP HANA XS, users can be authenticated by client certificates signed by a trusted Certification Authority (CA), which can be stored in the SAP HANA XS trust store. SAP logon tickets For HTTP access to SAP HANA by means of SAP HANA XS, users can be authenticated by logon tickets issued to them when they log on to an SAP system that is configured to create logon tickets (for example, the SAP Web Application Server or Portal).

SAP HANA Security Guide SAP HANA Authentication and Single Sign-On


35

Note To implement X.509 client certificates or SAP logon tickets, note the following: You must have configured support for the Secure Sockets Layer (SSL) protocol in your system.

●

The user specified in the certificate or logon ticket must already exist in SAP HANA; there is no support for user mapping.

●

Single-Sign On Single sign-on provides for an environment in which users can access SAP HANA from multiple clients based on an initial authentication on the client. Kerberos, SAML, X.509 client certificates, and logon tickets can be used for this purpose.

Note X.509 client certificates and logon tickets are supported only for HTTP access to SAP HANA by means of SAP HANA XS. Enable support for logon tickets only if SSO is not possible by other means, for example, Kerberos or SAML.

SAP HANA XS Application Configuration SAP HANA XS includes a Web-based administration tool that enables you to configure several security-related aspects of SAP HANA XS applications, including authentication (for example, enforced authentication mechanism, trust store configuration and management, and SAML configuration).


6.1

Logging on to SAP HANA

Before a user can connect to the SAP HANA database , the system performs several checks as part of the logon process. The system authenticates the user using the configured mechanism. For example, if user name/password authentication is being enforced, the provided user name and password are verified. The system verifies that the user's account is within its validity period. In the system view USERS, the columns VALID_FROM and VALID_UNTIL must contain effective values for the user in question. The validity period is an optional parameter that a user administrator can set during user provisioning. The system verifies that the user's account is active.

36



In the system view USERS, the column IS_DEACTIVATED must contain the value FALSE for the user in question. User accounts may be deactivated explicitly by a user administrator or by the system, for example, due to too many invalid logon attempts. If all of the above checks are successful, the user is logged on to SAP HANA.

6.2

Password Policy

Passwords for the user name/password authentication of database users are subject to certain rules, or password policy. You can change the default password policy in line with your organization’s security requirements. You cannot deactivate the password policy. You configure your password policy in the Security editor of the SAP HANA studio.

Note The actual parameters are contained in the password_policy section of the indexserver.ini system properties file. Although it is recommended to configure the password policy using the Security editor of the SAP HANA studio, you can also do so by editing the indexserver.ini directly.

Caution Changes to the indexserver.ini file cannot be audited. The following table describes the options available for configuring your password policy:

Minimum password length

8

The minimum number of characters that the password must contain

(minimal_password_length)

You must enter a value between 6 and 64. Required Character Types

(password_layout)

In the Security editor of the SAP HANA studio, the following options are selected: ●

Lowercase case

●

Uppercase letter

●

Numerical digit

The character types that the password must contain At least one character of each selected character type is required. The following character types are possible:

The corresponding parameter value in the indexserver.ini file is Aa1.

●

Lowercase letter (a-z)

●

Uppercase letter (A-Z)

●

Numerical digits (0-9)

●


Special characters (underscore (_), hyphen (-), and so on)


37

Any character that is not an uppercase letter, a lowercase letter, or a numerical digit is considered a special character. The default configuration requires passwords to contain at least one uppercase letter, at least one number, and at least one lowercase letter, with special characters being optional.

Note 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 client used. The SAP HANA studio, for example, supports passwords enclosed in double quotes ("), while the SAP HANA HDBSQL command line tool does not.

Note If configuring this option in the indexserver.ini file using the password_layout parameter, you can use any specific letters, numbers and special characters, and the characters can be in any order. For example, the default value example could also be represented by a1A, hQ5, or 9fG. If you want to enforce the use of at least one of each character type including special characters, you specify A1a_ or 2Bg?.

38



User must change password on first logon

(force_first_password_change)

In the Security editor of the SAP Defines whether users have to HANA studio, this option is selected. change their initial passwords the first time they log on The corresponding parameter value in the indexserver.ini file is Users can still log on with the initial password but every action they try true. to perform will return the error message that they must change their password. A user administrator (that is, a user with the system privilege USER ADMIN) can force a user to change his or her password at any time with the following SQL statement: ALTER USER FORCE PASSWORD CHANGE

Number of Previous Passwords Excluded (last_used_passwords)

5

The number of last used passwords that the user is not allowed to reuse when changing his or her current password

Note If you enter the value 0, the user can reuse his or her old password. Number of Allowed Failed Logon Attempts

(maximum_invalid_connect_attemp ts)

6

The maximum number of failed logon attempts that are possible; the user is deactivated as soon as this number is reached You must enter a value of at least 1. You can reset the number of invalid logon attempts with the following SQL statement: ALTER USER RESET CONNECT ATTEMPTS

The first time a user logs on successfully after an invalid logon attempt, an entry is made in the INVALID_CONNECT_ATTEMPTS system view containing the following information:



39

●

●

The number of invalid logon attempts since the last successful logon The time of the last successful logon

You can delete information about invalid logon attempts with the following SQL statement: ALTER USER DROP CONNECT ATTEMPTS

Recommendation Create an audit policy to record activity in the INVALID_CONNECT_ATTEMPTS system view.

Note This parameter is not valid for the SYSTEM user. The SYSTEM user will not be deactivated regardless of the number of failed logon attempts. User Lock Time

1440

(password_lock_time)

The number of minutes for which a user is deactivated after the maximum number of failed logon attempts

Note If you enter the value 0, the user is reactivated immediately. This disables the functionality of parameter maximum_invalid_connect_atte mpts. You can reset the number of invalid logon attempts and reactivate the user account with the following SQL statement: ALTER USER RESET CONNECT ATTEMPTS

40



To deactivate a user indefinitely, enter the value -1. It is still possible to reactivate the user with the above statement. Minimum Password Lifetime

1

(minimum_password_lifetime)

The minimum number of days that must elapse before a user can change his or her password

Note If you enter the value 0, the password has no minimum lifetime. Maximum Password Lifetime

182

(maximum_password_lifetime)

The maximum number of days for which a password is valid before the user must change it You must enter a value of at least 1. You can exclude users from this password check with the following SQL statement: ALTER USER DISABLE PASSWORD LIFETIME. However,

this is recommended only for technical users only, not database users that correspond to real people. You can re-enable the password lifetime check for a user with the following SQL statement: ALTER USER ENABLE PASSWORD LIFETIME.

Lifetime of Initial Password

(maximum_unused_initial_passwor d_lifetime)

28

The number of days for which the initial password that you set for a user is valid You must enter a value of at least 1. If a user has not logged on using the initial password within the given period of time, the password becomes invalid and you must reset it.



41

Maximum Duration of User Inactivity 365

(maximum_unused_productive_pas sword_lifetime)

The number of days after which a password expires if the user has not logged on You must enter a value of at least 1. If a user has not logged on using their user-defined password within the given period of time, the password becomes invalid and you must reset it.

Notification of Password Expiration

14

(password_expire_warning_time)

The number of days before a password is due to expire that the user receives notification

Note If you enter the value 0, the user does not receive notification that his or her password is due to expire.

The system view M_PASSWORD_POLICY contains the parameters and their current values. Auditing Activity in SAP HANA Systems [page 63] SAP HANA Administration Guide SAP HANA SQL and System Views Reference

6.3

Password Blacklist

A password blacklist is a list of words that are not allowed as passwords or parts of passwords. The password blacklist in SAP HANA is implemented with the table _SYS_PASSWORD_BLACKLIST ( _SYS_SECURITY). This table is empty when you create a new instance. You can enter words in the password blacklist as part of password policy configuration in the Security editor of the SAP HANA studio.


42



6.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 across an insecure network connection using secret-key cryptography. ODBC and JDBC database clients support the Kerberos protocol, for example, the SAP HANA studio. Access from front-end applications (for example, SAP BusinessObjects XI applications) can also be implemented using Kerberos delegation.

Note Kerberos is not supported for HTTP access via SAP HANA XS.

Configuration To allow users to log on to the SAP HANA database from a client using Kerberos authentication, the following configuration steps are necessary: Install MIT Kerberos client libraries on the host(s) of the SAP HANA system. Configure the SAP HANA system for Kerberos authentication. Map SAP HANA database users to their external identities stored in the Kerberos key distribution center (KDC). For more information about how to set up SSO with SAP HANA using Kerberos and Microsoft Active Directory®, see SAP Note 1837331.


6.5

Single Sign-On Using SAML 2.0

SAP HANA supports the Security Assertion Markup Language (SAML) for user authentication in single-sign on environments. SAML is used for authentication purposes only and not for authorization. SAML provides the mechanism by which the identity of users accessing the SAP HANA database from client applications is authenticated by XML-based assertions issued by a trusted identity provider. The internal database user to which the external identity is mapped is used for authorization checks during the database session. SAML can be implemented to authenticate users accessing the SAP HANA database from the following client applications: ●

Database clients that access the SQL interface of the SAP HANA database directly



43

This covers standard ODBC and JDBC database clients such as the SAP HANA studio. In this scenario, a SAML bearer assertion is used to authenticate the user directly. It is the client’s responsibility to retrieve the SAML bearer assertion used for logon. Clients that connect to SAP HANA through the SAP HANA XS server via HTTP In this scenario, SAP HANA acts as the service provider that authenticates users on the basis of their SAML bearer assertion.

●

SAML Assertion Specification SAP HANA supports plain SAML 2.0 assertions as well as unsolicited SAML responses that include an unencrypted SAML assertion. SAML assertions and responses must be signed using XML signatures. The following features of XML signatures are supported: ●

SHA1 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 element. The following SAML assertion features are supported: ●

Assertion Subject with NameID

●

Qualified NameID with SPProvidedID and SPNameQualifier

●

Validity conditions (NotBefore, NotOnOrAfter)

●

Audience restrictions

The following properties of a SAML assertion are evaluated to log on the requesting user to SAP HANA:

saml:Assertion/@Version

Required entry: 2.0

saml:Subject/saml:NameID

Must be specified

saml:Subject/saml:NameID/@Format

Required entry: urn:oasis:names:tc:SAML:1.1:nameidformat:unspecified

saml:Subject/saml:NameID/@SPProvidedID

Must either match an explicit user mapping in the SAP HANA database, or a wildcard mapping must have been set for the user

saml:Subject/saml:SubjectConfirmation

If it exists, entry must be {{"urn:oasis:names:tc:SAML: 2.0:cm:bearer"}}

saml:Conditions

Condition @NotOnOrAfter must be set.

●

@NotBefore

●

@NotOnOrAfter

●

AudienceRestriction

44



Configuration ●

ODBC/JDBC database client access To enable logon using SAML bearer assertions, you must configure identity providers and then map them to the required database users. Two types of user mapping are supported: ○

SAP HANA-based user mappings The mapping to a database user is explicitly configured within SAP HANA for each identity provider. The corresponding assertion subject looks like this: zgc2VLavgYy4hsohfYPM21

○

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

You can configure SAML identity providers and map them to database users in the SAP HANA studio. ●

HTTP client access (SAP HANA XS) You use the SAP HANA XS Administration Tool to configure an SAP HANA system to act as an SAML service provider. For more information, see the SAP HANA Administration Guide .




45

7

SAP HANA Authorization

When a user accesses the SAP HANA database using a client interface (for example, ODBC, JDBC), his or her ability to perform database operations on database objects is determined by the privileges that he or she has been granted. The following table provides with an overview of the privilege types used in SAP HANA.

System privilege

System privileges are SQL privileges that control SAP HANA SQL and general system activities. They are mainly for System Views Reference 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).

●

Object Privileges

[page 47] ●

SAP HANA SQL and System Views Reference

Currently, SELECT, DROP, and DEBUG are the only privileges that can be granted on attribute views, analytic views, and calculation views. Schema privilege

Schema privileges are SQL object privileges that are used to allow access to and modification of schemas and the objects that they contain.

Source privilege

Source privileges are SQL object privileges that are used to restrict access to and modification of remote data sources, which are connected through SAP HANA smart data access.

Analytic privilege

Analytic privileges are used to allow read access to Analytic Privileges [page data in SAP HANA information models (that is analytic 48] 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 Authorization in the ability to work in packages in the repository of the SAP Repository of the SAP HANA database. HANA Database [page 52] Packages contain design time versions of various objects, such as analytic views, attribute views, calculation views, and analytic privileges.

Application privilege

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

46


SAP HANA Developer Guide

SAP HANA Security Guide SAP HANA Authorization

Application privileges are granted and revoked through the procedures GRANT_APPLICATION_PRIVILEGE and REVOKE_APPLICATION_PRIVILEGE procedure in the _SYS_REPO schema. Application privileges can be granted to users or roles in runtime in the SAP HANA studio. However, it is recommended that you grant application privileges to roles created in the repository.

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.


7.1

Object Privileges

Object privileges are SQL privileges that are used to allow access to and modification of database objects. For each SQL statement type (for example, SELECT, UPDATE, or CALL), a corresponding object privilege exists. If a user wants to execute a particular statement on a 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.

Note Schema privileges do not always grant authorization to objects in the schema. In case of views (both row and column views) and DEFINER procedures, this is only true if the owner of the view or procedure has obtained all privileges on the dependent objects WITH GRANT OPTION. An object can therefore be accessed only by the following users: ●

The owner of the object



47

●

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.

Tip The SAP HANA studio provides a graphical feature, the authorization dependency viewer, to help troubleshoot authorization errors for object types that typically have complex dependency structures: stored procedures and calculation views. For more information about resolving authorization errors with the authorization dependency viewer, see the SAP HANA Administration Guide .. For more information about the object privileges available in SAP HANA and for which objects they are relevant, see the SAP HANA SQL Reference .

SAP HANA SQL and System Views Reference SAP HANA Administration Guide

7.2

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.

Example Sales data for all regions are contained within one analytic view. However, regional sales managers should only see the data for their region. In this case, an analytic privilege could be modeled so that they can all query the view, but only the data that each user is authorized to see is returned. Analytic privileges are intended to control read-only 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).

48



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.

7.2.1

Creation and Management of Analytic Privileges

Analytic privileges can be created, dropped, and changed in the SAP HANA modeler. 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.

Granting and Revoking Analytic Privileges You grant and revoke analytic privileges in the same way as other privilege types. As repository objects, analytic privileges are owned by the _SYS_REPO user. To be able to grant and revoke an analytic privilege, a user needs the privilege EXECUTE on the procedures GRANT_ACTIVATED_ANALYTICAL_PRIVILEGE and REVOKE_ACTIVATED_ANALYTICAL_PRIVILEGE respectively.

SAP HANA Administration Guide SAP HANA Developer Guide

7.3

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 authorization concepts that



49

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)

●

Analytic privileges on SAP HANA information models Package privileges on repository packages (for example, REPO.READ, REPO.EDIT_NATIVE_OBJECTS, REPO.ACTIVATE_NATIVE_OBJECTS)

●

Application privileges for enabling access to SAP HANA XS applications

●

A role can also extend other roles.

Role Modeling You can model roles in the following ways: ●

As runtime objects

●

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

50



7.3.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 authorization concepts 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.

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 the user must also have the SELECT object privilege on the views to actually be able to access data, the _SYS_BI_CP_ALL analytic privilege should not be granted to users, particularly in production systems. For this reason, the MODELING role should only be used as a template. MONITORING

This role contains privileges for full read-only access to all metadata, the current system status in system and monitoring views, and the data collected by the 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 additional authorization 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.

SAP_INTERNAL_HANA_S UPPORT

This role contains system privileges (for example, CATALOG READ) and object privileges (for example, SELECT on SYS schema) that allow access to certain lowlevel internal system views needed by SAP HANA development support in support situations. All access is read only. This role does not allow access to any customer data. The definition of the low-level internal system views to which this role allows access is not part of the stable end-user interface and might change from revision to revision. To avoid administrators and end users accidentally accessing these internal system views in applications or scripts, this role is therefore subject to



51

several usage restrictions (listed below) and should be granted only to SAP HANA development support users for the their support activities. In detail, this role contains privileges for read-only access to all metadata, the current system status, and the data of the statistics server. Additionally, it contains the privileges for accessing low-level internal system views. Without the SAP_INTERNAL_HANA_SUPPORT role, this information can be selected only by the SYSTEM user. To avoid accidental use of this role in day-to-day activities, the following restrictions apply to the SAP_INTERNAL_HANA_SUPPORT role: ●

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.

●

It cannot be granted another role.

●

It cannot be granted further object privileges.

●

It can be granted only further system privileges.

●

With every upgrade of the SAP HANA database, it is reset to its default privileges.

7.4 Authorization in the Repository of the SAP HANA Database 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

SAP HANA Developer Guide

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

52



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 subpackages. 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. 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 native packages.

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



53

●

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

7.4.2

_SYS_REPO Authorization in the Repository

The repository of the SAP HANA database stores both runtime objects, such as calculation scenarios, and designtime 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.

7.4.3 Granting and Revoking Privileges on Activated Repository Objects Only the _SYS_REPO user has privileges on objects in the repository. Therefore, only this user can grant privileges on them. Since no user can log on as _SYS_REPO, another means of granting privileges is used, namely stored procedures. The following stored procedures, in the _SYS_REPO schema, are used to grant and revoke privileges on activated modeled objects, analytic privileges, application privileges, and roles.

Modeled objects, such as calculation views

Schema containing modeled objects

Analytic privilege

Application privilege

Role

54

●

GRANT_PRIVILEGE_ON_ACTIVATED_CONTENT

●

REVOKE_PRIVILEGE_ON_ACTIVATED_CONTENT

●

GRANT_SCHEMA_PRIVILEGE_ON_ACTIVATED_CONTENT

●

REVOKE_SCHEMA_PRIVILEGE_ON_ACTIVATED_CONTENT

●

GRANT_ACTIVATED_ANALYTICAL_PRIVILEGE

●

REVOKE_ACTIVATED_ANALYTICAL_PRIVILEGE

●

GRANT_APPLICATION_PRIVILEGE

●

REVOKE_APPLICATION_PRIVILEGE

●

GRANT_ACTIVATED_ ROLE



●

REVOKE_ACTIVATED_ ROLE

Note Public synonyms of these procedures exist. Therefore, these procedures can be used without specifying the schema _SYS_REPO. Using stored procedures and a technical user for privilege management is beneficial for several reasons compared to the standard SQL mechanism using the GRANT and REVOKE statements. Normally, to be able to grant a privilege, a user must have the privilege and be authorized to grant it further. This is not the case when procedures are used. Any user who has the EXECUTE privilege on the relevant grant procedure can grant privileges. Furthermore, if a user grants a privilege using the GRANT statement, the privilege is automatically revoked when the grantor is dropped or loses the granted privileges. In addition, only the grantor can revoke the privilege. With the stored procedures approach, any user with the EXECUTE privilege on the relevant revoke procedure can revoke a granted privilege, regardless of the grantor. If the grantor is dropped, none of the privileges that he or she granted are revoked. When the SAP HANA studio is used for privilege management, this behavior is hidden. If privileges on activated objects are granted or revoked, the procedures are used automatically. To grant and revoke privileges on activated objects directly using procedures, the relevant procedure must be executed as follows:

CALL GRANT_PRIVILEGE_ON_ACTIVATED_CONTENT ('','

SAP_HANA_Security_Guide_en[1].pdf

Recommend Documents