cancel
Showing results for 
Search instead for 
Did you mean: 

Who takes care of HANA security and compliance: Application teams, security, GRC, DBA, basis?

Former Member
0 Kudos

Hi all,

When you have a standalone HANA;

  1. there will be end-users who will access HANA views thru BOBJ,
  2. there will be developers using HANA studio to build views /SQLs etc
  3. there will be developers creating tables(database activity) etc,
  4. some admin stuff to create users, roles, audit activities,
  5. Typical GRC activities/segregation of duties etc

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

Accepted Solutions (0)

Answers (1)

Answers (1)

lbreddemann
Active Contributor
0 Kudos

Did you have a look at s blog and the guide referenced in it: ?

If not, that's what you may want to do.

- Lars

Former Member
0 Kudos

Hi Lars, I have checked these docs. They are great material talking about mostly the roles and authorizations + how to implement "what and how", yet I am looking for an answer for "who".

Regards

Tansu

lbreddemann
Active Contributor
0 Kudos

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

Former Member
0 Kudos

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

lbreddemann
Active Contributor
0 Kudos

"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