With the emergence of technology trends such as the Internet of Things and machine learning, the growth rate of business data is continually accelerating. Finding ways to effectively manage and leverage data will continue to be a top priority for nearly all organizations. In-memory technology, with its ability to store and rapidly process a large amount of data in system memory rather than on the hard disk, offers a compelling solution to this challenge.
But what about security? How can you be sure that one of your most valuable — and most sensitive — assets is protected when it is stored and accessed in this way? Data security, whether on-disk or in-memory, remains of paramount importance for every business and its customers. As the leader of in-memory database platforms,1 SAP HANA is designed to ensure secure access to data while enforcing defined security policies (see the sidebar "Why SAP HANA?" for more on its key features). This article shows you how SAP HANA secures this access by sharing lessons centered around the seven most critical areas of security for SAP HANA (see Figure 1), including how user access to SAP HANA is secured; how access to SAP HANA by external applications, services, and servers is secured; and how you can customize SAP HANA security to your organization’s particular needs with additional built-in features as well as other SAP solutions.
Securing User Access
While hacker attacks tend to command the most headlines, the biggest security threat currently facing organizations comes from within, whether by intent or negligence.2 To help security administrators mitigate this risk, SAP HANA has built-in controls for managing user access and authentication with SAP HANA, handling access to the operating system and system database, and providing an authorization framework to protect SAP HANA database objects.
1. Secure User Access and Authentication
To ensure the security of data stored and processed in memory, only database users with an authenticated account in the SAP HANA identity store can connect to SAP HANA. The actions that a user can perform are determined by the roles and privileges assigned to that user’s database user account. There are three types of SAP HANA database user accounts: named user accounts, technical user accounts, and anonymous browsing accounts.
Named user accounts are required for authenticated users to directly access SAP HANA or an SAP HANA web application. For example, a user running a sales report or logging in to a web-based helpdesk application may log in using his or her individual user account, such as johndoe. This type of access is restricted based on roles and privileges assigned, at the user level, to the user’s individual account.
A technical user account does not correspond to an actual person — technical user accounts represent an application, and therefore represent all users of that application. For example, a single technical user account can be used by a decoupled application server to provide each user of an application, such as SAP Business Suite powered by SAP HANA, with data access.
An anonymous browsing account provides users of a web-based application with open access to data that an application considers public data. For example, a user might be able to search forum data without logging in to the system. If the user wants to access restricted data, the application may ask the user to log in or create an account (which would be a named user account). Behind the scenes, the access is actually provided through a specified technical user account that is configured to enable anonymous access via a SQL connection configuration (SQLCC).3
To authenticate users who are accessing SAP HANA, SAP HANA supports password-based authentication and many single sign-on options. Single sign-on protocols supported for ODBC/JDBC-based access to SAP HANA include Kerberos, SAML, and SAP logon and assertion tickets. For HTTP(S)-based access to SAP HANA, supported protocols are Kerberos via SPNEGO, SAML, X.509 digital certificates, and SAP logon and assertion tickets.
2. Secure Operating System and System Database Access
When installing SAP HANA, a special operating system user account — <sid>adm — is automatically created. This account provides SAP HANA system administrators with access to the operating system underlying SAP HANA, and can be used to start and stop the SAP HANA server and to access SAP HANA files, such as utilities and logs. The security aspects of the operating system and operating system user account are managed using the tools and security patches provided by the vendor of the particular operating system in use.
To segregate multiple sets of data and applications, SAP HANA optionally supports multiple SAP HANA databases, or tenant databases, within a single SAP HANA system. This feature is known as multi-tenant database containers. In a multi-tenant configuration, there is one system database that is used to manage the creation and policy restrictions for one or more tenant databases. Administrators of the system database will usually not have privileges for accessing data in or managing users of the tenant databases. High isolation options allow individual operating system users to be created for each tenant database.
3. Secure Access to Database Objects with an Authorization Framework
Each tenant database in an SAP HANA system houses its own set of database objects and its own identity store to manage access to those objects. Assigned privileges control what users can do in that database — for example, system privileges authorize administrative actions for the entire SAP HANA system, object privileges authorize operations on individual database objects, and analytic privileges authorize read access to specified analytic views of data. Privileges should be bundled into roles that can be granted to end users or other high-level business roles, so that assignment of privileges and security administration in general can be performed in the most efficient way possible, and so that security models can be easily transported across systems.
Database objects stored in the SAP HANA database catalog, such as tables and views, are secured in a manner that is similar to how any other SQL database secures its database catalog objects — privileges such as create, read, update, and delete can be assigned. In addition, SAP HANA supports row-level data security that can be dynamically determined based on customized business logic. For example, users can be restricted to seeing salary information only for direct reports, or sales managers can be restricted to seeing region-specific data. Row-level security is enforced by analytic privileges, which can reference lookup tables or even procedures in the case of more complex access rules.
Once an application is developed and deployed, the design-time objects generate active runtime objects (e.g., schemas, tables, and views) in the database catalog, where they are owned by the special system user _SYS_REPO, which ensures their independence and viability beyond the existence of the authoring user. By separating the design-time code from the activated runtime objects, SAP HANA enables an inherent segregation of duties, removing the need for developers to require direct access to sensitive runtime objects and data. It also enables the easy transport of code and corresponding activated objects across databases.
Securing Application Access
Data doesn’t do much good if applications and application servers outside of the database system can’t access it, but opening up external access to your data is a risk. SAP HANA is built to ensure reliable, authorized web-based access to data as well as access by decoupled application servers.
4. Secure Web-Based Access with XS and SAP HANA Tools
XS enables HTTP(S) access to SAP HANA in the form of web services or web applications that can access or deliver data through HTTP(S) interfaces. Any SAP HANA table or view can easily be exposed as an OData web service, enabling create, read, update, delete (CRUD) operations on your data using HTTP methods or verbs. Security for these services (and for web applications in general) is managed using SAP HANA application privileges on top of existing database-level access privileges.
The actions and access enabled by these privileges are defined by developers, and can be assigned to roles granted by security administrators via the SAP HANA web-based development workbench and the SAP HANA cockpit. It is important that security administrators and architects understand the access granted by these privileges, to ensure compliance and efficient administration, and to understand and mitigate possible security risks.
5. Secure Access from Decoupled Application Servers and Applications
Traditional external application servers work with SAP HANA as they do with any other SQL database using a three-tier architecture, where many of the security aspects are built into the application server and application logic, and administered through a custom-built administration application.
SAP NetWeaver Application Server (SAP NetWeaver AS) for ABAP and SAP NetWeaver AS for Java enable SAP Business Suite 4 SAP HANA (SAP S/4HANA) and SAP Business Warehouse (SAP BW) to run on SAP HANA. These application servers and applications offer special optimizations using SAP HANA. Processing logic is pushed down to SAP HANA, and the security and data models can be exposed for direct access and extensibility in SAP HANA by SAP HANA tools and complementary SAP or third-party SAP HANA-based extension applications. Non-SAP application servers, such as Apache TomEE, Node.js, and the Microsoft .NET Framework, can also be used with SAP HANA.
Decoupled application servers (and clients) generally connect to SAP HANA using a standard client interface such as MDX, JDBC, ODBC, or SQLDBC (an SAP proprietary interface). To enable database authorization, these servers typically connect to SAP HANA (or any other database) using the technical user account described earlier. Security features and logic are then managed at the application server layer.
Special security administration and synchronization capabilities are provided for some SAP HANA solutions delivered on decoupled application servers. SAP BW powered by SAP HANA includes the ability to securely consume and provide direct (client) access to underlying business objects stored in SAP HANA. In this case, SAP BW users, selected data (such as InfoProviders and InfoObjects), and authorizations are automatically generated in the SAP HANA database by SAP BW. This not only securely allows users and applications to directly access SAP BW data in SAP HANA, it also allows SAP BW to securely access data and models in SAP HANA that may have been created or integrated from other non-SAP BW systems.
Similar capabilities exist for SAP HANA Live, a set of pre-configured virtual data models delivered with SAP Business Suite powered by SAP HANA. These virtual data models can be securely accessed in SAP HANA, in real time, directly from SAP Business Suite business intelligence tools and custom applications. An authorization assistant synchronizes the SAP ERP authorizations with SAP HANA database users, safely exposing direct access of real-time business data from SAP HANA.
Customizing SAP HANA Security
To help customers tailor SAP HANA security to their unique needs and broader landscapes, SAP offers additional options for security administration and integration of the SAP HANA platform. These include features that are built directly into SAP HANA, as well as integration with additional SAP components and solutions.
6. Additional Built-In Security Features
Additional core SAP HANA security features include encryption, support for virus scanning software, audit logging, and self-service workflows.
Encryption can be enabled for all network communications — for example, between SAP HANA and clients and between different SAP HANA systems — as well as for data at rest (SAP HANA does persist data for restoration purposes, in case of power failures, for instance). Field-level data encryption and decryption can be performed by applications or web services using XS API calls. Similar APIs exist to allow the use of virus scanning software to scan and clean files stored in the database.
Audit logging enables the tracking of actions performed in SAP HANA, such as changes to user privileges, system configuration modifications, and access of sensitive data. Logging policies are highly customizable. Policies can be tailored to cover specific users, events, or objects, and can be configured to have different classification levels. The log output for each audit policy can be written to the Linux syslog, an SAP HANA database table, a CSV file, or some combination.
Self-service workflows can be enabled so that users can reset their own passwords and request access to an SAP HANA system or XS application. Assigned administrators can approve or deny the access requests.
7. Additional Security Products and Add-Ons
There are several additional SAP components and solutions that can help you customize the security administration or integration of your SAP HANA platform with features for management and synchronization of security models, landscape management, compliance, and threat detection.
SAP Identity Management (SAP ID Management) supports over 40 types of SAP and non-SAP connectors used to manage and synchronize security models across many disparate systems, including SAP HANA systems.4 You can use SAP ID Management to uniformly perform user administration tasks, such as maintaining user accounts and roles, or setting passwords in SAP HANA as well as other systems.
SAP Solution Manager helps organizations monitor, configure, and audit their SAP HANA systems along with other disparate systems and applications, all from a single solution.
SAP Enterprise Threat Detection leverages SAP HANA to detect and alert enterprises to intruders and information security threats in real time to help prevent security breaches in your SAP and non-SAP systems.5
SAP Access Control automates the process of detecting, remediating, and ultimately preventing access risk violations. It helps manage and enforce compliance of user provisioning and security access approval workflows. Integrating SAP Access Control with SAP HANA enforces and unifies segregation of duties, user provisioning, and access approval policies for your SAP HANA systems and IT landscapes.
Information security is a top priority for the enterprise. While traditional enterprise solutions have disparate security models built into the application server and database layers, SAP HANA is designed to facilitate inherent integration of these models and to share enterprise security elements across applications and architectural layers.
This approach allows direct, secure access to database objects in a range of scenarios while efficiently enforcing security policies authored in the database, in the application layer, or in both, enabling you to gain the benefits of in-memory technology with confidence.
For more information and some helpful SAP HANA-related links, visit http://scn.sap.com/community/hana-in-memory/blog/2015/09/11/helpful-sap-hana-related-security-links.
1 Forrester, “The Forrester Wave: In-Memory Database Platforms, Q3 2015” (August 2015; www.forrester.com/pimages/rws/reprints/document/120222/oid/1-V7OVKQ). [back]
2 Experian, “2015 Second Annual Data Breach Industry Forecast” (www.experian.com/assets/data-breach/white-papers/2015-industry-forecast-experian.pdf). [back]
3 SQLCCs are configured using the administration tool for SAP HANA extended application services (XS), a component included with SAP HANA that provides application server functions. [back]
4 For more on SAP ID Management, see the article “Simplify Administration and Extend User Management into the Cloud with SAP Identity Management 8.0” in the April-June 2015 issue of SAPinsider (SAPinsiderOnline.com). [back]
5 For more on SAP Enterprise Threat Detection, see the article “Safeguard Your Business-Critical Data with Real-Time Detection and Analysis” in the October-December 2014 issue of SAPinsider (SAPinsiderOnline.com). [back]