One area that didn't have a lot of information available was HANA security and how you should set your environment up. I always look at security as one of the most important capabilities that needs to be set up correctly in the beginning or you are destined for a large amount of rework in the future or subsequent failure. We all know that security is one of the hottest topics in today's economy. Though, we may not dealing with credit card or social security numbers, we are dealing with data that can be extremely sensitive internally and if there are outside users, then we really have to make sure this is designed correctly. Some of the main questions that you must ask yourself are the following:
- What type of users will be accessing your HANA database?
- What type of restrictions should be at the end users?
- Should all the restrictions occur at the HANA database or should it be controlled at the BusinessObjects level?
Let's keep it simple at first and think about some basics that everyone should follow:
Setting up security
As we may be understanding, grantors and the spider web that can be created with multiple users granting security to different users can become complicated. Not only can it become complicated but over time, it can be difficult to change. In addition, if one of the grantor's leaves the company and this user is deleted, then we may lose all of the security that was set up. Some basics that I try to implement is a basic security user that can be leveraged by multiple users so there is always one grantor. This obviously has a dependency on correctly assigning the underlying artifacts correctly to the security user or the roles with the grantable capabilities but it provides a simple approach.
Schemas
Since there are multiple ways that schemas are created, with some requiring the end users to be able to access them while others do not require the end users, simplifying this process will make your security model flexible. What I would recommend is creating a role for each schema that is created and then assigning this role to the necessary composite roles. This will allow you to specifically assign to developers, that are in charge of focused development projects, while not opening up all of the schemas to every developer. At the same time, you can easily open up to all developers by assigning to the modeler role, etc...
The schema that is created when a user is created, should not be assigned to others and these should be used as sandbox areas for the developers. Please make sure that you also assign select and grant access to system user _sys_repo.
Packages
Similar to schema security, you should create 2 roles for every package. One of the roles should be read only, while the other should be edit. You may choose to do this at the root or at the sub folders, depending on your set up. As a best practice, I usually do at the root unless I know there will be additional future considerations. This will allow you to provide the necessary access to developers where required. You can either assign the role to the individual users or the composite roles that are created for developers, admin, etc...This will provide the most flexibility and it will be simple to do as you create the package.
In many cases, clients only have a 2 tier landscape, so they don't have a DEV and QA, but only a QA. In order for you to support a 2 tier landscape within 1 HANA instance, you should create a DEV package separately. Now you have the capability to have a controlled area for packages that will be assigned to a delivery unit.
Packages should also follow the same folder structure that you will have within your front end reporting system, similar to BOBJ. This will allow you to have the consistent and organized approach.
SAP Landscape Transformation Considerations
This is one of the areas that gets a little confusing and there is a lot of content out there on setting up SLT and the necessary configuration entries that are required so I won't get into that. One that that I will briefly discuss is the roles that are created for the schema, which is created automatically by SLT. There are 4 main roles that are created and they tie to the following areas:
- DATA_PROV - this role is for the developers who will be responsible for data provisionin
- POWER_USER - this role has full control over the replication process and should not be given to anyone accept in emergencies
- SELECT_USER - This allows you to grant or revoke specific access
- USER_ADMIN - Gives the right for the entire schema
What I would recommend (if you have multiple source systems that are replicated), is to create a composite role for each of the above, which will combine all of the same responsibilities together. This may not be the case in your system but something to consider. If not, the main role that you will give to most developers is DATA_PROV. After this, please validate that the role that you are providing is required by that developer / end user.
I hope this helps with some basics on security and how you can set up your basic artifact items. Please comment and let me know what questions that you may have security and we can work through the issues. Thanks for reading!
Please follow me on Twitter @Tim_korba and on linkedin at http://www.linkedin.com/in/timkorba/www.linkedin.com/in/timkorba/
