Of the many notable items that have occurred in the past two years, one is that many SAP customers are now running SAP HANA. I recall being at conferences in 2013 through 2014 and only able to find a few attendees that were actually using a SAP HANA based solution. That has all changed in 2017. I now find that a large portion of the SAP ecosphere is running something based on SAP HANA. With its popularity and usage on the rise, it is inevitable that SAP HANA security will soon be a top priority for most organizations and auditors. Solutions such as Suite on SAP HANA (SoH) and S4/HANA are becoming more commonplace within organizations. The dream of running ERP and Analytic on the same platform is starting to take shape and this is prompting more organization to grant access directly to the SAP HANA Database.
SAP’s ERP solutions are the lifeblood for many organizations and accordingly they must be secured at all layers. Based on my experience, most organizations have addressed access to the SAP Application Server layer. They might have lingering issues with segregation of duties (SoD), user account maintenance and other items; but one would assume that they have attempted to address it is at some point. However, I do find that many organizations have failed to implement any level of security within their SAP HANA database. They might have secured their SAP Application layer but none of that will matter the second someone perpetrates mass fraud by changing data directly within the SAP application server’s tables. With a few SQL INSERT, UPDATE and DELETE statements, someone could be sending themselves a few $9,000 checks every week.
Regarding SAP HANA security, I often find that organizations share the SYSTEM account and other services accounts used by the SAP Application server with multiple administrators. For example, the entire BASIS team might have the SAP application server’s database user account and password; this account can change data directly in the SAP system tables. I also find that most organizations grant too many privileges to users simply because they do not understand the SAP HANA security layer. Ignorance should never be an excuse for not implementing a proper SAP HANA security model.
In short, many organizations have numerous gaps as it relates to SAP HANA security. This is further complicated when they attempt to grant direct access to the SAP HANA database. As you can see in the figure below, most modern analytic applications will connect directly to the SAP HANA database via ODBC, JDBC or HTTP. Even some Fiori applications will require direct database access as well.
This is just the tip of the iceberg in my opinion. Securing a SAP HANA system goes well beyond user accounts and privileges. We must also have a strategy that addresses data encryption, communication encryption, password policies, auditing and monitoring. Cybersecurity is a major issues these days and you have to address all aspect of the SAP HANA security model to have any chance of defending your organization’s data and systems that run on SAP HANA. With this in mind, I will list out the top five reasons all organization need to address their SAP HANA security model before it’s too late.
- Fraud can cause an organization to lose money and their reputation. When a SAP HANA system operates an SAP ERP application server, someone only need INSERT, UPDATE or DELETE access to the SAP ERP tables to commit mass fraud.
- When your SAP ERP system is offline, it is hard to conduct business. Many organizations use their SAP ERP system to its full extent. When this system is offline, most processes within the organization come to a complete stop. So yes, securing your SAP HANA system is also about system availability. An untrained administrator with a high level of privileges can be just as dangerous as a hacker trying to bring down your system. It requires a sound SAP HANA security model, SoD and training to prevent these types of mistakes.
- Hackers… they like to hack into your systems. Hackers can gain access to your systems and data for a variety of reasons. Typically, such reasons are never well intended. It’s not like they hack into your system and perform routine maintenance for you. Most likely, they hack into your system to steal information, commit fraud, extortion, denial of service and other malicious acts. Therefore, you have to make it very difficult for them to penetrate your SAP HANA database security.
- Compliance means that resistance to implementing SAP HANA security is futile. Most organizations have obligations to external regulatory agencies and they must adhere to their security standards. SAP HANA is one of many systems that are subject to numerous regulations. Therefore, we need to have a security model and security strategy for all SAP HANA systems.
- Access to data must be governed. Almost all SAP HANA solutions involve the storage of master data and transaction data. Such data often needs to be secured from external access but it also needs to be segregated within the organization. Without a proper security model in place, most organizations have no means of securely distributing data hosted in SAP HANA.
To help organizations understand the key aspects of the SAP HANA security model, I recent authored a book titled SAP HANA Security Guide and it is available from SAP-Press and Rheinwerk Publishing. Below is the cover of this book.
The book address the following key areas of security and a few other topics:
- User Provisioning
- Repository Roles
- Object Privileges
- System Privileges
- Package Privileges
- Analytic Privileges
- Auditing and Monitoring
- Security recommendations
You can purchase a hard copy and e-Copy of the book today at:
Purchasing form SAP Press is your best way to get the book soon after it is released on 5/24/2017.
A hard-copy can also be purchased from Amazon: