Security Introduction

Basic concepts of SAP HANA Security features.

Topics to be covered:
Describe the security perspective in different implementation
scenarios
Outline the security functions in SAP HANA
Explain the different authentication methods
Explain the SSL connection encryption
Explain the data volume encryption
Explain the audit logging infrastructure
Security perspective in different implementation
scenarios:
SAP HANA as a data mart for reporting and analytics

SAP HANA in a classic 3-tier architecture as the primary database, for

example, in SAP Net Weaver Business Warehouse (SAP Net Weaver
BW) or SAP Business Suite installations

SAP HANA as a platform for providing database and application

services to native SAP HANA-based applications
Data Mart Scenario:
SAP HANA in a Classic 3-tier Adrchitecture:
SAP HANA as a Platform:
Security Functions of SAP HANA:
Security Administration features in Studio:
1. User and role management
2. Management of privileges
3. Management of audit policies
4. Configuration of password policy
Authentication in SAP Hana:
Definition:
The identity of every database user accessing the database is verified
through a process called authentication.

Authentication mechanisms:
1. SQL access: User name and password, Kerberos, Security Assertion
Markup Language (SAML bearer token)
2. HTTP access (SAP HANA XS): User name and password, SAP logon
tickets, SAML, and X.509 certificates
Authentication via Kerberos:
SAP HANA supports the Kerberos protocol for single sign-on.
The ODBC database client and the JDBC database client support
Kerberos.
To implement this, you need to install the MIT Kerberos client
software on the host of the SAP HANA database.
The users stored in the Microsoft Active Directory can be mapped to
database users in the SAP HANA database.
One Kerberos ID can only be assigned to one database user.
SAML:
The SAP HANA database supports the login of users to the SAP HANA
database using the Security Assertion Markup Language (SAML).
The primary function of SAML is to provide Internet Single Sign-On (SSO)
for organizations. SAML is used to securely connect Internet applications
that exist both inside and outside the organization's firewall.
Requires a trusted 3rd party (identity provider) that can issue SAML
assertions for clients (e.g. browser).
Whenever the application server needs to connect to the SAP HANA
database on behalf of a user, it requests an SAML assertion from the client.
The SAML assertion is issued by the identity provider after the client was
successfully authenticated there, and is then sent to the SAP HANA
database.
How to configure SAML in Studio and in XS
Administration:
SAP Logon Ticket and SAP Assertion Ticket
Users can be authenticated in SAP HANA by logon or assertion tickets
issued to them when they log on to an SAP system configured to
create tickets.
If you want to integrate an SAP HANA system into a landscape that
issues SAP logon or assertion tickets for user authentication, you must
configure SAP HANA to accept logon/assertion tickets.
SAP HANA validates incoming logon/assertion tickets against
certificates signed by a trusted Certification Authority (CA) stored in a
dedicated trust store. This trust store must contain all root
certificate(s) used to validate logon/assertion tickets.
Reference: SAP Note 1927949.
Authorizations Assigned by Privileges and
Roles:
 Encryption Overview
Secure Communication -Encryption of data communication in the
network:
Network traffic can be encrypted using SSL (v.3), both between the SAP
HANA database and clients, as well as between hosts in a distributed
SAP HANA system.
Encryption of the data persistence layer:
1. SAP HANA database can encrypt data at rest (data volumes)
2. Encryption works at the page level and uses the AES256 encryption
algorithm
 For the configuration of secure communication using SSL and the encryption
of the persistence layer a cryptographic service provider is available on the
server.
SAP HANA supports the following cryptographic libraries:
CommonCryptoLib (default):
CommonCryptoLib (libsapcrypto.so) is installed by default as part of SAP
HANA server installation at $DIR EXECUTABLE.
OpenSSL:
The OpenSSL library is installed by default as part of the operating system
installation.
<<< /usr/sap/<SID>/SYS/exe/hdb/libsapcrypto.so>>><<SAP Note 2093286.>>
Server-side configuration for SSL:
SSL is installed (e.g. openssl)
For connecting with Studio using SSL you need a certificate on the
server side too, Certificate hierarchy and certificate for the SAP HANA
database server are available.
The corresponding root certificate has been deployed on all clients
that are to use an SSL-encrypted connection to the server.
Configuration can be customized for SQLDBC/JDBC-based clients
using parameters in the indexserver.ini file -> section Communication
 Data Volume Encryption
Data volume encryption ensures that anyone who can access the data
volumes on disk using operating system commands cannot see the
actual data .. If data volumes are encrypted, all pages that reside in
the data area on disk are encrypted using the AES-256-CBC algorithm.
Pages are transparently decrypted as part of the load process into
memory. When pages reside in memory, they are therefore not
encrypted and there is no performance overhead for in-memory page
accesses. When changes to data are persisted to disk, the relevant
pages are automatically encrypted as part of the write operation.
 The SAP HANA database can be configured to encrypt all data at rest
(data volumes)
The master key for encryption is stored in the Secure Store File
System (SSFS). It is generated when a new database is created.
Encryption algorithm: AES256 bits.
Encryption works on page level.
When pages reside in memory they are not encrypted.
Currently not supported: Encryption of individual tables, log
volumes(Database redo log files), DB traces or backups.
 Data volume encryption on disk can be configured using SAP HANA studio or SQL
commands.
The root key for data volume encryption is automatically created during
installation. If you have received SAP HANA as an appliance, we recommend to
change this key after handover from the hardware vendor.
Prerequisites for changing the SSFS master key:
1. Credentials of the operating system user ( <sid>adm user) that was created
when the system was installed .
2. In a distributed SAP HANA system, every host must be able to access the key file
location .
An administrator can change the SSFS master key using the command line tool
rsecssfx using the credentials of the operating system user <sid> adm. Therefore
the SAP HANA system has to be stopped.
 Auditing Overview
Motivation:
Many regulatory requirements require audit logging.
Audit logging provides traceability for security-relevant events_ It records the try to break security_ It also helps protect companies
against unsubstantial charges.
Internal threats:
80-90% of all attacks/security breaches come from inside the intranet
- Unauthorized access to data (employees looking at salary tables, external consultants gaining access to sensitive internal
information)
- Unauthorized data changes (employees covering their own mistakes)
Most security breaches come from company-internal power users
By assigning themselves additional privileges or roles, or log on as different users
Power users must be audited
Power users must not be able to delete their own audit trails
External threats
Hackers
Audit Logging - Infrastructure
 When an audit policy is triggered, an audit entry is created in the audit
trail. The audit trail is written to Linux syslog or to an internal system
table.
Linux syslog:
The logging system of the Linux operating system (syslog) is a secure storage
location for the audit trail because not even the database administrator can
access or change it.
Database table:
Using an SAP HANA database table as the target for the audit trail makes it
possible to query and analyze auditing information quickly. It also provides
a secure and tamper-proof storage location. Internal column store table in
the _SYS_AUDIT schema of the SAP HANA database.
Audit entries are only accessible through the public system view
AUDIT_LOG. Only SELECT operations can be performed on this view by
users with system privilege AUDIT ADMIN or AUDIT OPERATOR.
To avoid the audit table growing too large, it is possible to delete old audit
entries.
Prerequisite: AUDIT ADMIN and INIFILE ADMIN system privilege
Permission to create, alter, activate, deactivate and drop any audit definition.
Show audit policies: select * from "PUBLIC"."AUDIT_POLICIES
Audit level:
EMERGENCY
ALERT
CRITICAL
WARNING
INFO
Viewing the audit trail in a database table:
In the Systems view of SAP HANA studio, expand the catalog and display the system view AUDIT_ LOG
Alternatively, display the system view using SQL command:
SELECT * FROM "PUBLIC"."AUDIT_LOG
Only SELECT operations can be performed on this view(AUDIT_LOG) by users with the system privilege AUDIT OPERATOR or AUDIT
ADMIN.
 User Administration Tools
SAP HANA studio
Creating users
Deleting, deactivating and reactivating users
Modelling and activating analytic privileges
Creating roles
Assigning roles and privileges to users
Check authentication of users
Command line interface (hdbsql or other SQL Tool)
Perform all administration tasks using SQL commands
for example run the following statement:
CREATE USER <user_name> PASSWORD <password>
CREATE ROLE <role_name>;
SAP Netweaver Identity Management
Creating and deleting user accounts
Assigning roles
Setting passwords of users
>>The SAP NetWeaver Identity Management 7.2 SP3 contains a connector to
the SAP HANA database (IDM connector).
>>Web IDE: http://<host>:<port>/sap/hana/xs/ide , or,
>> http://<host><port>/sap/hana/admin/cockpit
SAP HANA Lifecycle Manager
Perform post-installation steps including changing user passwords
User Types:
Database users that correspond to real people:
Database users that correspond to real people are dropped when the person
leaves the organization.
Technical database users:
They are 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. Eg. SYS , _SYS_REPO .

User Tasks:
Business end users reading reports using client tools, for example,
Microsoft Excel.
Modelers creating models and reports using the SAP HANA studio .
Database administrators operating and maintaining the database and
users using the SAP HANA studio.
 CREATE ROLE <Role_Name>
GRANT <Role_Name> TO <User>
REVOKE <Role_Name> FROM <user>

Database Users: When you install the SAP HANA database, a

database user, called SYSTEM, is created by default. The database
user SYSTEM has irrevocable system privileges, such as the ability to
create other database users, access system tables, and so on.
Operating System User: <SID>ADM (to start or stop database
processes or to execute a recovery.)
 Privileges in SAP HANA
System Privileges:
Authorize execution of administrative actions for the entire SAP HANA database
System Privileges are assigned to users and roles.

Object Privileges:
Authorize access to data and operations on database objects
Used to restrict access to and modification of database objects, such as tables.
Depending on the object type (for example, table, view), actions (for example,
CREATE ANY, ALTER, DROP) can be authorized per object.
For object privileges in the SAP HANA database, the SQL standard behavior is
applied.
Object privileges are assigned to users and roles.
Analytic Privileges:
Authorize read access to analytic, attribute and calculation views at runtime and
provide row-level access control based on the dimensions of the relevant view.
Only applied at the processing time of the user query.
Analytic Privileges need to be defined and activated before they can be granted
to users and roles.
Package Privileges:
Authorize access in the repository (modelling environment) at design time
Used to restrict the access to and the use of packages in the repository of the SAP
HANA database.
Packages contain design-time versions of various objects, such as Analytic,
Attribute, and Calculation Views, as well as Analytic Privileges, and functions. To be
able to work with packages, the respective Package Privileges must be granted.