SAP HANA Security:
SUMMARY
Protecting a company’s or
organization’s critical data from unauthorized access and ensuring compliance
with the growing number of rules and regulations is becoming increasingly
important for SAP customers. SAP HANA® offers capabilities and benefits for
customers in many important applications and scenarios and will therefore play
an increasingly important part in many customers critical IT and application
infrastructures.
The purpose of this document
is to give IT security experts a starting point and overview of what they need
to understand about SAP HANA in order to comply with security-relevant
regulations and policies and to protect their SAP HANA implementation and the
data within from unauthorized access.
The document provides
information on
The impact of the different SAP HANA scenarios on how security needs to be
addressed
The framework and functions provided by SAP HANA that can be used to implement
security and compliance requirements in line with the specific security, legal,
and regulatory requirements
How SAP HANA can be integrated into existing security infrastructures and
processes
Additional resources for
more detailed information on SAP security topics
OVERVIEW AND SCENARIOS
3.1 Overview
SAP HANA is SAP’s in-memory
database technology that leverages hardware and software innovations to enable
very fast processing of large amounts of data (for more details on SAP HANA see
“Further Reading”). SAP HANA can act as a standard SQL-based relational
database. In this role it can serve as either the data provider for classical
transactional applications (OLTP) and/or as the data source for analytical
requests (OLAP). Database functionality is accessed through an SQL interface.
In addition, SAP HANA comes
with a built-in application server, the “SAP HANA Extended Application Services
(SAP HANA XS)”. This server can be accessed through HTTP and can serve data via
OData calls or rich HTML user interfaces.
In order to leverage the
full potential of SAP HANA, data-intensive operations are executed directly in
the database. Therefore SAP HANA provides a development/modeling environment
that allows you to create new data structures and programs, analytical views
and queries, stored procedures, and applications. The development environment
is integrated into the SAP HANA studio, which also serves as the client tool
for database administration. Design-time artifacts (like custom applications,
roles, application content) are managed in the SAP HANA built-in repository,
which provides the lifecycle management for these artifacts. Repository design
time objects can be transported from development to quality assurance (QA) and
production systems.
SAP HANA is delivered to
customers as an appliance. This means that customers receive a completely
installed and preconfigured SAP HANA system on certified hardware from an SAP
hardware partner, including the underlying pre-installed and pre-configured
operating system. Depending on the customer’s requirements (for example size of
the database), an SAP HANA system may consist of one host or a cluster of
several hosts.
3.2 Availability
The SAP HANA database holds
the bulk of its data in memory for maximum performance, but it still uses
persistent storage to provide a fallback in case of failure. After a power
failure, the database can be restarted like any disk-based database and returns
to its last consistent state.
In addition, SAP HANA
provides functionality for backup and recovery as well as high availability and
disaster tolerance. These topics are described in separate documents (see
“Further reading”).
3.3 Scenarios
SAP HANA is used in
different scenarios – for reporting and analytics in data marts, as a database
in SAP NetWeaver Business Warehouse (SAP NetWeaver BW) and SAP Business Suite
installations, and for providing database and application services to
innovative new applications. This section will briefly introduce the different
scenarios, their security impact, how they differ from traditional security
approaches and what customers need to consider from a security perspective when
planning their SAP HANA projects. When planning the security of an SAP HANA
implementation, it is important to understand the different scenarios and their
impact. The scenarios below can also be combined within the same installation
(with some restrictions).
3.3.1 3-tier
application
SAP HANA can be used as a
relational database in classical 3-tier architectures. SAP HANA provides
standard interfaces such as JDBC and ODBC and supports standard SQL (with SAP
HANA-specific extensions). For example, you can use SAP HANA as the database
(“persistence”) in an SAP NetWeaver Business Warehouse or SAP Business Suite
installation.
In such installations, a
classical three-tier architecture is used: client – application server –
database (see figure below).
Figure 1: SAP HANA in a
3-tier architecture
In this architecture,
security management features such as authentication, authorization, encryption,
and audit logging are located and enforced mostly in the application server
layer, while the database is used as the data store only.
Applications connect to the
database through a technical user account, 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 for 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. Specific SAP
HANA security features are mainly needed to control access of administrators to
the database.
3.3.2 Data mart
(analytics only)
SAP HANA was first used in
scenarios that focus on analytical use cases. In these scenarios, data is
replicated from a source system such as SAP Business Suite into SAP HANA, and
then reporting is carried out on the data in SAP HANA (read-only views,
dashboards, and so on).
Figure 2: SAP HANA as a data mart
Different architectures can
be used for this, for example SAP BusinessObjects business intelligence (BI)
solutions accessing SAP HANA, or other BI clients accessing SAP HANA directly.
Note that in the latter
case, end-user clients connect directly to the SAP HANA server.
Therefore, security policies for user access also need to be enforced at the
database level. The security features provided by SAP HANA are described in the
section “Security functions”.
3.3.3 Technical
infrastructure for new applications
SAP HANA Extended
Application Services (SAP HANA XS) embed 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.
Figure
Figure 3: SAP HANA as
technical infrastructure for new applications
SAP HANA XS is tightly
integrated with the SAP HANA database and relies on the same security model.
This means that the majority of security features (for example authorization)
described in the section “Security functions” apply directly to SAP HANA XS
based applications with some differences (for example supported authentication
methods) or extensions. These extensions are also described in the section
“Security functions”. Additionally, SAP HANA XS contains support for protection
against typical vulnerabilities of web-based applications (for example XSRF).
Details are described in the SAP HANA Developer Guide (see “Further reading”).
4 SECURITY FUNCTIONS
SAP HANA provides security
functions that enable customers to implement different security policies and
meet compliance requirements. This section provides an overview of SAP HANA’s
security functions. Depending on the scenario in which SAP HANA is used (see
section “Overview and scenarios”), only some of these functions might actually
be needed; others might be provided in other architecture layers.
For detailed information
please refer to the SAP HANA Security Guide at http://help.sap.com/hana_platform
Figure 4: SAP HANA
security functions
4.1 Authentication and
single sign-on
Access to SAP HANA data
and applications requires authentication. Several authentication options are
available.
4.2 User and
role management
To be able
to log on to SAP HANA, a user must exist in the identity store of the SAP HANA
database. Depending on the scenario, the user accessing the SAP HANA database
can either be a technical user, an administrative user, or an individual end
user.
The actions
a user can perform depend on the roles and privileges that were assigned to the
user. Roles are used to bundle and structure privileges, allowing you to create
sets of privileges for dedicated user groups.
Roles can be
created in the repository during design time. This makes it possible to export
and import roles using repository functions, which can serve as a basis for
transports between systems (for example from development to test system). It
also enables applications based on SAP HANA to easily ship default or template
roles.
For user
administration and role management, administrators can use either the SAP HANA
studio (GUI) or SQL commands. An adapter for SAP NetWeaver Identity Management
is available to allow integration into existing infrastructures.
The user and
role management of SAP HANA XS is fully integrated with the core database user
and role management.
4.3
Authorization framework
SAP HANA
provides a rich set of authorization mechanisms based on standard SQL
privileges and SAP HANA-specific extensions to fulfill the needs of current and
future business applications.
All access
to data and execution of actions in the database require authorization:
Privileges control what users can do.
Privileges can be assigned to both roles and users. However, it is
recommended to bundle privileges into roles. There is a privilege concept for
both design time (development systems) and runtime (production systems).
4.4 Data
encryption on disk
Although SAP
HANA holds the bulk of its data in memory for maximum performance, it still
uses persistent storage to provide a fallback in case of failure.
SAP HANA can
encrypt this persistent storage (that is, the data volumes on disk), which
ensures that even if someone can access the data volumes on disk using
operating system commands, they will not be able to see the actual content.
4.5 Audit logging
Audit
logging tracks actions performed in the database: who did what – or tried to do
what – and when.
SAP HANA
provides audit logging for critical security events, such as changes to roles
and user privileges, and access to sensitive data. Both write and read access
of database objects (such as tables, views) can be logged, as well as the
execution of procedures.
Audit
logging can be configured in the SAP HANA studio or using SQL statements. Audit
policies define which actions in the database are logged (such as audit target
and audited users). These policies can be configured to the customer’s needs.
The audit
trail is written to Linux syslog to enable easy integration into existing
monitoring and auditing infrastructures. Syslog can be configured to write the
audit trail to remote servers, thus enabling segregation of duties between
database administration and audit log analysis.
4.6 Security
administration
Security
administration is integrated into the SAP HANA Studio, for example it is
possible to
Manage authentication policies
Manage users and roles and assign privileges
Configure
audit logging
Most security administration tasks can also be carried out using
SQL commands. SAP HANA has also been integrated into DBA Cockpit (part of SAP
NetWeaver).
5
INFRASTRUCTURE INTEGRATION
SAP HANA
supports standard interfaces to enable integration with customer security
network and datacenter infrastructures.
Identity
management (user and role provisioning)
o SQL-based interface for user and role
creation
o Out-of-the-box
connector for SAP NetWeaver Identity Management is available
Compliance
infrastructure
o Out-of the
box connector for SAP Access Control is available
Standards-based single sign-on infrastructures based on
Kerberos (for example Microsoft Active Directory) or SAML
Logging/monitoring infrastructures
o Database
audit trail written to Linux syslog
Further details can be found in the SAP HANA Security Guide (see
chapter “Further reading”)
5.1
Operating system
SAP HANA
comes with a pre-installed and pre-configured SUSE Linux Enterprise (SLES) 11,
which already includes preconfigured security settings such as minimal network
services running.
In order to
conform with internal and external IT policies, customers are allowed to make
certain changes or additions to the standard SAP HANA appliance installation.
The details are described in SAP notes.
5.2 Security
patches
SAP HANA
security patch information is published as part of the general SAP security
patch strategy (SAP Security Notes). SAP HANA security patches are delivered as
SAP HANA revisions and can be applied using the Software Update Manager for SAP
HANA.
Operating
system security patches are provided and published by SUSE.
5.3 Network
The network
communication channels (purpose, ports) used by SAP HANA are documented in
detail in the SAP HANA Master Guide. The SAP HANA Security Guide includes
recommendations on the use of firewalls, for example to separate internal and
external communication as well as the options for encryption using SSL. A
reference of the SAP HANA network protocol is also available.
All these
documents are available on the SAP Help Portal at
http://help.sap.com/hana_platform
5.4
Compliance
Compliance
plays an important role in many customer environments. SAP HANA provides
functions that support customers in achieving compliance.
Compliance
in most cases is not a product feature, but depends on many factors such as
Relevant rules and regulations (IT policies, industry,
country, and so on)
Existing
technology/infrastructure, processes, audit approach
To achieve
compliance, usually both process and functional requirements need to be
fulfilled:
Best practices in security operations
Need-to-know principle, separation of duties on all levels
Control of privileged access
Ability to audit
Deletion
of data
SAP HANA
takes an end-to-end approach to enable application compliance, the basis for
which is provided by the built-in database security features and the security
options of the whole software and hardware stack.
This is
extended by SAP HANA’s integration into existing security infrastructures
through standard/documented interfaces and the option to use third-party tools
that are required for data center operations.
Last but not
least SAP HANA provides end-to-end documentation for the whole software
lifecycle, including an extended security guide and recommendations on secure
setup and operation.
Based on the security provided by SAP HANA customers can implement
their specific security and compliance policies.
What is SAP HANA?
SAP HANA is a modern
in-memory platform that is deployable as an on-premise appliance, or in the
cloud. As an appliance, SAP HANA combines software components from SAP
optimized on proven hardware provided by SAP’s hardware partners. In the cloud
SAP HANA is offered as a comprehensive infrastructure combined with managed
services. SAP HANA can also be deployed through the following cloud offerings:
SAP HANA One, SAP HANA Cloud and SAP HANA Enterprise Cloud.
The SAP HANA platform is a
flexible data source agnostic in-memory data platform that allows customers to
analyze large volumes of data in real-time. It is also a development platform,
providing an infrastructure and tools for building high-performance applications
based on SAP HANA Extended Application Services (SAP HANA XS). It is the
foundation of various SAP HANA editions, like the SAP HANA Platform Edition,
providing core database technology, and the SAP HANA Enterprise Edition,
bundling additional components for data provisioning. The SAP HANA Platform
Edition integrates a number of SAP components, including the SAP HANA database,
SAP HANA studio, and SAP HANA clients.
Software
Components
The SAP
HANA Platform Edition is the foundation of various other SAP HANA editions,
like the SAP HANA Enterprise Edition. These editions bundle additional
components that customers might require, for example, for data replication. The
SAP HANA Platform Edition is composed of the following components:
ü
SAP
HANA database
ü
SAP HANA client
ü
SAP HANA client for Microsoft Excel
ü
SAP HANA studio
ü
SAPUI5 Tools IDE PLUGIN
ü
SAP Host Agent
ü
Diagnostics
Agent
ü
SAP HANA
information composer
ü
SAP
HANA AFL
ü
SAP
HANA LCApps
ü
SAP HANA lifecycle manager
ü
SAP HANA RDL
ü
SAP HANA smart data access
ü
SAP HANA INA Toolkit HTML
ü
SAP HANA unified installer
ü
LM structure inst SAP HANA
ü
SAP HANA Direct Extractor Connection (DXC)
The
SAP HANA Platform Edition is bundled together with other products into editions
as license bundles for special purposes.
SAP HANA – An Architectural Overview
SAP uses
the term “SAP HANA” to designate the SAP In-Memory Appliance which is aimed at
data analytics. It is a combination of hardware and software, and it is
delivered as an optimized appliance in cooperation with SAP’s hardware partners
for SAP HANA. SAP also uses the term to indicate the SAP in-memory database,
which is a hybrid in-memory database that combines row-based, column-based, and
object-based database technology. The following diagram provides a high-level
overview of the SAP HANA architecture.
SAP HANA Database
The SAP
HANA database consists of two database engines:
• The column-based store, storing relational data in
columns, optimized for holding data mart tables with large amounts of data,
which are aggregated and used in analytical operations.
• The
row-based store, storing relational data in rows. This row store is optimized
for write operations and has a lower compression rate, and its query
performance is much lower compared to the column-based store.
The
engine that is used to store data can be selected on a per-table basis at the
time of creation of a table (and changed subsequently). Tables in the row-store
are loaded into memory at startup time, whereas tables in the column-store can
be either loaded at startup or on demand, during normal operation of the SAP
HANA database.
Both
engines share a common persistency layer, which provides data persistency
across both engines. Changes to in-memory database pages (equivalent to Oracle
blocks) are made persistent through savepoints written to the data volumes on
persistent storage (usually hard drives). Every transaction committed in the
SAP HANA database is persisted by the logger of the persistency layer in a log
entry written to the log volumes on persistent storage
The SAP HANA database supports SQL
(JDBC/ODBC), MDX (ODBO), and BICS (SQL DBC). BICS is a SAP HANA-specific SQL
Script language that is an extension to SQL that can be used to push down
data-intensive application logic into the SAP HANA database (similar to Oracle
stored procedures).
Analysis: SAP HANA High
Availability (HA) Features
The HA analysis of SAP HANA can be done across the following three
elements.
1. Scalability support
2. Disaster Recovery (DR) support
3. Backup & Recovery support
The following sections will look into each of these in greater
detail.
Storage Replication
SAP relies on specific certified hardware partners to offer a
storage-level replication solution, which delivers a copy of the persisted
volumes or file-system to a remote, networked storage system. For synchronous
replication, the SAP HANA transaction only completes when the locally persisted
transaction log has been replicated remotely. SAP suggests synchronous storage
replication can be used
only where the primary-DR site distance is 100 kilometers or less.
In any case, this solution requires a reliable, high bandwidth and low latency
connection between the primary site and the secondary site.
Following are two examples of how this configuration looks.
No comments:
Post a Comment