How Authorizations Have Evolved from SAP ERP to SAP S/4HANA
Authorizations are the core of security in SAP, but they have evolved with time from their initial iterations with SAP ERP. On launch in 1992, SAP R3 attempted to become a corporate backbone for enterprise data. To do this, SAP R3 used three interlinked layers: database, presentation, and application. The database layer contained the raw data arranged in a queryable format. The application layer was responsible for performing actions on the data stored in the database. The presentation layer tabulates and puts that data together into a human-readable form that allows users to leverage the data to make decisions. However, since it’s an enterprise-level system, it would require specific ways to ensure only authorized users had access to the needed data. R3 solved this by a client/server architecture commonly used during the period for login authorizations.
SAP ERP evolved over time to accommodate demands for separate access to business functions by the department. At the time, the name of a particular transaction referred to its department. To limit access to transactions from other departments, authorization objects were used to control the level of access on a per-department or per-grouping basis. As evolution continued into SAP NetWeaver 2004 (and later NetWeaver 7.0) and eventually integration with third-party Java installations, accessibility and authorization had to keep pace. This next step looked at simplifying the current security architecture to allow for seamless authorization for users. This simplification extended to other devices connected to the enterprise network, feeding data into the database.
SAP S/4HANA and Authorization
Being released in 2011, SAP S/4HANA built on the success of SAP ERP. By including a modular coding language in ABAP, SAP allowed businesses to adapt the software suite to their own needs and write custom modules. These custom modules, of course, have to conform with the security architecture of SAP S/4HANA for authorizations. SAP S/4HANA has moved its priority from integration to developing a harmonized, simplified data model. Because there are so many different entry points in SAP S/4HANA, authorization systems need to consider them. An unauthorized application coded in ABAP should not have access to a company’s database. SAP S/4HANA addresses this through a privilege framework on the database layer.
The privilege framework is crucial for understanding how SAP deals with external access methods. As the installation for these systems moves from on-premise to loud-based, IT services play a much more critical part in setting up these databases and their authorization access. IT remains one of the most important stakeholders for a cloud SAP S/4HANA install. Securing the cloud from external malicious users sometimes means correctly setting up the cloud security protocols. Most data leaks come from poorly installed cloud security measures. At that point, authorization wouldn’t be much of a concern if the business’s data was in the public domain. By setting up the business’s cloud security properly, there would be no way for anyone to gain access to the business’s data except through SAP’s authorization system.