on 09-11-2014 3:07 PM
Hi all,
When you have a standalone HANA;
If you think traditional security models, application/security team takes care of the end users, developers, but usually DBA/BASIS team takes care of database access/creating tables..
What do you see in your environment/clients?
Appreciate your thoughts
Cheers
Tansu
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ah, Ok, I see what you mean.
I guess the answer really depends on what you do.
From my experience, the definition of the security concept is a key part of the actual development. Most implementations define the maintenance (day-to-day) work very much along the lines of traditional systems.
Thus, the developers/architects decide the types of user personas, which lead to role set definitions.
Then the administrators for the solution assign these roles to end users.
Hope that is what you asked for.
Cheers, Lars
I believe it's more than developers and architects; creating developer access, end-user access is one thing, but they/we are usually not involved with compliance, audit, segragation of duties,
In otherwords, during the traditional BW/ECC times
1) we had developers/end-users using the application to build/use solutions usually taking care of by application security teams.
2) we had DBA/BASIS teams to take care of tablespaces(no such thing in HANA), table adjustments, indexes etc..
3) we had change control boards/teams used to approve the usual changes knowing the impacts - now not very sure if for example approving a HANA revision upgrade, or SLT patch is going to impact the HANA ecosytems( HANA, SLT, Lumira server, HANA live etc...) adversely or not.-
4)GRC team to monitor usual activities.
5) And we had internal/external auditors who have built practices, methods for traditional databases over the years. Now with the options availabe within the HANA studio and security, a not very familiar person or extremely aware developer can do a lot - ea, a HANA admin can turn on/off audit trial and not many coompanies know if there is even such a thing.
So what I am asking is a gudience from SAP and feedback from others who have been using HANA while we're building our own.
That would be nice if we all particiapte and create a material
Tansu
"compliance, audit, segragation of duties,"
These are organizational and regulation questions.
They are independent of the underlying technology but depend on the business context.
So how shall SAP provide guidelines for that in relation to a technology platform?
Using SAP HANA doesn't change any of those three aspects.
An idea of what kind of roles could evolve around a SAP HANA system can be found in the technical operations guide which is part of the standard documentation.
However, this doesn't give a complete IT operations organisation blueprint - which is basically what you are asking for.
Concerning statement 5): HANA Studio lets you do whatever you allow the user to do.
That's - again - no different to any other platform tool out there.
- Lars
User | Count |
---|---|
83 | |
24 | |
12 | |
9 | |
7 | |
6 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.