SAP HANA 2.0 Security Guide - Part 1

SAP HANA 2.0 Security Guide - Part 1

Understanding Object Ownership

Before we can start managing authorizations in SAP HANA, is important to understand the basic ownership concept of the database objects, such as tables or schema and and the implications of this concept.
The owner of an object is the user who creates the object ,only the object owner can initially access the object and grant privileges on the object to others. However, all objects are located in a schema and the schema itself it is an object with an owner.

Object Ownership – Example


Object Ownership in Hana Security

In the figure above, How SAP HANA Handles Ownership of Catalog Objects , we can see the following example:

User BILL owns the schema BILL and WDF
User JIM owns the schema JIM
As the owners can grant privileges to others, user BILL grants to user JIM the privilege to create objects over schema BILL
User JIM creates the table ORDERS inside schema BILL (table name = BILL.ORDERS).

Based on our example, we need to understand which objects can be accessed by which users.
We can conclude that user JIM can only access schema JIM and the table BILL.ORDERS. On the other hand, user BILL has access to schema WDF and schema BILL. Notice that user BILL also has access to all the content of those schemas, and so, user BILL also have access to table BILL.ORDERS.

Object Ownership – Implications
Now let us take a look at the implications of the ownership concept in the case when one of the users needs to be dropped, the following rules apply:
  • You can only drop a user if he owns no objects (except their own schema).
  • If the user owns further objects, the only option is to drop the user with the “cascade” option. This means that all the objects owned by the user are dropped and all the privileges on these objects are revoked.
  • If one of the objects of the user to be dropped is a schema, ALL the objects located in that schema are also dropped (even if they are owned by a different user).
Going back to our example, let us analyze what would happen if we drop each of the users.
The following rules apply:
  • In both cases we need to use the cascade option as both users own other objects beside their own schema.
  • If we drop user JIM with the“cascade” option, the schema JIM and the table BILL. ORDERS are also dropped.
  • If we drop user BILL with the“cascade” option, the schema WDF and its content (table WDF.SALES) are dropped. Also, the schema BILL and the table BILL.ORDERS (owned by JIM) are dropped.
The deletion of users also has an impact on the privileges that the user granted to others. When a user is dropped, all the privileges granted by the user to others (users or roles) are also revoked.

When we try to drop a user using UI support by using SAP HANA Studio or SAP HANA Cockpit, we can easily analyze the impact of the action as we could identity all the objects owned by the user to be deleted. Dropping users using SQL commands is risky as the objects to be dropped are not displayed.

You can also analyze the ownership of the objects in your SAP HANA system by using the system view named “OWNERSHIP”, “SCHEMAS” or “ROLES” depending of the type of object you would like to analyze.

Similar to dropping a user, revoking a privilege from a user can also provoke a “recursive” revoking situation in cases where the privilege was extended further to others users or roles.To understand this, you should know that the following two possible options to grant a privilege exist:

Granting a privilege to a user or role
This option allows user A to grant a privilege to user B. User B is not allowed to further extend this privilege to others.

Granting a privilege to a user or role with GRANT/ADMIN option
This option allows user A to grant a privilege to user B. User B is allowed to extend this privilege to others. For example, user B can extend the same privilege to user C.

To grant a privilege, the user granting the privilege should be the “owner” of the privilege (owner of the object related to the privilege) or should have the privilege assigned to them with the GRANT/ADMIN option.

If user A revokes the privilege from user B, the privilege is also revoked indirectly from user C as user B no longer has the privilege. This also happens if user A is dropped from the database.
In the case of roles, these are owned by the database user who creates them. To create a role, a database user needs to be granted all the privileges of the role. If any of these privileges are removed from the creating user, then these automatically removed from the role. Similarly, if the creating user is dropped, all roles that they created are also dropped.


Introducing SAP HANA Repository
With SAP HANA 1.0 SPS05 the SAP HANA Repository was introduced. It is technically linked to the SAP HANA Extended Application Services (XS) and it is where all the design-time objects reside.
 
The SAP HANA Repository allows you to create design-time objects, such as schema, procedures, roles, and so on, and manage their entire lifecycle within the SAP HANA database.

_SYS_REPO Authorization in the Repository
Any developer with the proper privileges on the repository can create the design-time object, but at the moment of activation, the run time version of the object is created and owned by technical user _SYS_REPO.

Another benefit of the SAP HANA Repository is that all the content (design-time objects) can be transported between the SAP HANA Repository. The only prerequisites is that the package where the design-time objects are located is assigned to a delivery unit.

Any repository content can be transported as long as it is assigned to a delivery unit. This means that package system-local cannot be transported. The following three transport applications can be transported.
  • CTS+
  • Classical ABAP transports, with “HANA Transport Container” integrated Native HANA > HANA transports, using XS application sap.hana.xs.lm.
  • Native HANA > HANA transports, using XS application sap.hana.xs.lm.
After maintaining your delivery units and assigning packages to them, you can transport the content of a delivery unit using the export and import functionality. Additionally, you can use one of the following transport applications:
  • SAP HANA Native transport
  • Enhanced Change and Transport System (CTS+)
  • SAP HANA transport for ABAP
Proposed Repository Layout
By default, the SAP HANA Repository is delivered with the following two packages:
Package “sap”
This is reserved for all the build-in applications delivered with SAP HAHA and any official SAP-delivered content.
Package “system-local”
This is a package for sandbox purposes. This package and sub-packages cannot be assigned to a delivery unit, and so, the content of this package cannot be transported.

Any vendor should create their own package directly in the repository root. There is no recommendation for the sub-structure inside the vendor package.



SAP HANA 2.0 Security Guide - Part 1 SAP HANA 2.0 Security Guide - Part 1 Reviewed by NEXT GEN Technologies on 12:56 PM Rating: 5

No comments:

Powered by Blogger.