“Why consider SAP HANA security and controls?” is a question that has been raised many times but yet has gotten so little attention. Let’s take a deeper look into SAP HANA and talk about the security features, loopholes, benefits and so much more.
SAP HANA provides several security functions such as authentication, authorization, encryption, and audit logging that enable the implementation of security policies based on the scenarios in which SAP HANA can be used. SAP HANA can be used in providing application services using SAP HANA Extended Services (XS), for reporting and analytics in data marts, and as a database in SAP Business Warehouse (SAP BW) and SAP Business Suite applications. In this three-part blog series, I will first discuss some of the SAP HANA Security scenarios. In the second part we will discuss more about Security Functions and in the final blog we will discuss the loopholes, best practices, Security Controls and auditing features in SAP HANA.
When you think of SAP HANA security and controls, it is important to first understand the various scenarios in which security can be applied. Let’s take a look at some of them. The first scenario is SAP HANA as an Application Server is one of the scenarios where SAP HANA XS incorporates an application server embedded within SAP HANA, exposing applications developed in this server to end users. The various security functions for SAP HANA directly apply to these applications and appropriate controls have to be tested accordingly. All the web applications built on SAP HANA is built in the HANA XS server which requires suitable security functions to be applied. The SAP HANA security functions will be discussed in our next blog article.
The second scenario is SAP HANA as a Data Mart. In this scenario, data is replicated from the source system into SAP HANA and then reporting is carried out on the data stored in SAP HANA. Some people refer this as a side car solution. A good example is SAP BusinessObjects Business Intelligence tools that use the data stored in SAP HANA directly to provide end users suitable reports. This scenario requires end users to authenticate from the native SAP HANA clients and applications and does not require any authentication directly to the SAP HANA database to access the reports.
Let’s take a look at our final scenario, SAP HANA as a Three-Tier Architecture (Client, Application Server, and Database). In this scenario, SAP HANA is used as a database layer in the classic three-tier architecture of systems. The security functions in this scenario are maintained in the application server and the SAP HANA database is primarily used as a data store. SAP Business Suite software, a set of fully integrated applications such as SAP ERP, SAP CRM, SAP SCM, and SAP SRM are perfect examples of this scenario.
The key is to remember that SAP HANA can be used in different scenarios and each scenario requires a different security approach. The database provides several security functions with the flexibility of implementing different security policies. Security implementation depends heavily on the architecture of SAP HANA and the systems surrounding the database.
itelligence has built a unique solution around SAP HANA Security called “SecureHANA.it”. It is a package that delivers preconfigured SAP HANA Security, including SOX ready, Segregation of Duties compliant, design time HANA Roles, Risk and Control Matrix for SAP HANA and several spreadsheet templates for Security Assessment, Role Build and SOD violation within the HANA Database.
Learn More About SAP HANA Security
Learn more about SAP HANA Security and Controls! Download our in-depth customer case study presentation: Managing Security and Controls in SAP HANA – Tube Specialties Case Study.