Restricting SE16 access to HCM "/BIC/" tables in a BI 7.0 system

[Former Member]

This is our scenario.

- We are already live on BI 7.0

- We will soon be implementing SAP HCM and will also be transferring HCM data to BI for reporting purposes.

We have a large number of SAP Support and Project technical staff (100+) and all have access to data browsers such as SE16. However, only a restricted number of technical staff should have access to HCM data via SE16. This is easy to implement in a HCM system because we know the table auth groups that SAP assigns to HCM tables. Hence, we can restrict SE16 access to HCM data using the auth object S_TABU_DIS.

In a BI system, InfoProviders have a corresponding underlying table that is accessible using SE16. The tables are all named starting "/BIC/" (we are not using standard business content cubes, so I am ignoring the tables named "/BI0/"). When SAP creates the "/BIC/" table, the table auth group is set to blank. Hence, anyone with access to SE16 can browse data in these tables, even the ones containing HCM data.

So, I am looking for the SAP recommended approach to securing SE16 access to the HCM related "/BIC/" tables.

One possible option is to use SE11 and manually update the table auth group. However, this doesn't seem appropriate because I think SAP automatically maintains the "/BIC/" tables in each system whenever the InfoProvider is transported.

Regards,

Richard Cooper.

[Former Member]

That's easy to answer, but considerably more difficult to actually do in the wild.

> Hence, anyone with access to SE16 can browse data in these tables, even the ones containing HCM data.

This is not correct, or at least misleading.

When a table is not assigned, the empty space is replaced with the symbolic value '&NC&' by the data browsers (SE16, etc etc). This means "Not Classified" --> all tables without auth groups have not (yet) had their data classified to find the correct level of protection for them.

Simply remove '&NC&' from the S_TABU_DIS authorizations of the users, and if anyone complains that they cannot display a table anymore which they previously could, then you need to classify it (i.e. assign it to a group).

> One possible option is to use SE11 and manually update the table auth group. However, this doesn't seem appropriate because I think SAP automatically maintains the "/BIC/" tables in each system whenever the InfoProvider is transported.

Why don't you let them use RSA1 to browse the data? Here the new Analysis Authorizations will be checked, so you can re-use your existing concept without having to re-invent another one for direct table access and run both in parrallel.

Cheers,

Julius

[Former Member]

Hi Julius,

Thanks for your reply.

I agree they should normally use RSA1 to browse data. However, SE16 is a very useful transaction to give to SAP technical staff for reasons other than browsing InfoProvider data. Unfortunately, SE16 can now be used as a "back-door" in BI to access HCM related "/BIC/" tables.

Removing authorization to '&NC&' is not a solution because many standard SAP tables are delivered with no auth group and we want to provide our technical staff with SE16 access to these tables. Anyway, it doesn't seem appropriate to leave a table containing HCM data as "not classified".

Directly using SE11 to set the table auth group does not seem viable due to the way SAP technically manages these "/BIC/" tables.

I am keen to know the official SAP approach to the issue.

Regards,

Richard.

[Former Member]

>

> This is not correct, or at least misleading.
> 
> When a table is not assigned, the empty space is replaced with the symbolic value '&NC&' by the data browsers (SE16, etc etc). This means "Not Classified" --> all tables without auth groups have not (yet) had their data classified to find the correct level of protection for them.
> 
> Simply remove '&NC&' from the S_TABU_DIS authorizations of the users, and if anyone complains that they cannot display a table anymore which they previously could, then you need to classify it (i.e. assign it to a group).
>

This is not correct either, Julius. You told this to me once already, but it is still incorrect. There are tables that are assigned a 'BLANK'. SAP standard tables, too. There are however, also a lot of tables that do not even have an entry in view V_DDAT_54, for example the /BIC/ - tables in BI ... this concept you explain is not consistent over all SAP applications or coded authority-checks.

Which brings me to mention to Richard, that you should not change the table attributes in SE11, but - if that ever should be the solution - attach them to an authorization group using transaction SE54.

And no, i have no ideal solution and am not of SAP, either ...

[Former Member]

Sorry to disagree with you, but in this case I stick with my statement.

You need to differentiate between a view (SM31) and browsing a table directly for which there may, or may not, be a view (SE16 etc).

Yes, SAP used to default the authorization group of a view to '&NC&' and that was a contradiction in more ways than not, but even if there is no view with an authorization group and no authorization group assigned to the table itself, the system will find this empty field in TDDAT-CCLASS and symbolicly check '&NC&' instead.

It is a bit like an "unmaintained" table, instead of taking the route of suppressing the check like S_PROGRAM does - it replaces it.

You can find this in LSETBF01 in the form AUTHO_CHECK at around line 2472.

But to this question, like many which have gone before it... you need to decide whether you want to have the users on the tables in the first place.

Also, speaking of VIEWS, it might be worth looking into whether there is any view generated by SAP and whether that authorization group remains stable?

> And no, i have no ideal solution and am not of SAP, either ...

Here I agree with you completely myself, in all aspects.

I would try to convince them to use RSA1 instead, as being next best.

Cheers,

Julius

[Former Member]

Hi

I am from SAP BW, expert on security.

I agree with Julius. SE16 is a quite questionable access to BW data. You should review whether you could not use the official mechanisms for accessing BW data like listcube or RSA1 which do check analyis authorizations for the access which were designed exactly for such purposes. I would also recommend that.

Having SE16 access is a very very powerful authorization.

I know that it is quite common to use SE16, especially by "experts" and people who "understand" such tables (which by far is not always the case). And I agree that it would be nice to have real auth groups for those tables.

But using auth groups for generated tables in a standard as a real security concept is complex. Some people would like to restrict to individual tables, to groups like you (HCM content) etc. What auth group names should one generate and how to group them? Etc.

I even once had a discussion on using analysis auths in SE16 itself (for the data itself) which is interesting but not BW and comes from a similiar use case.

Altogether I also recommend the appraoch suggested by Julius: dont grant access to &NC& fro S_TABU_DIS.You may wait for complains in order to maintain an auth group for the required tables in case you dont know them in advance.

This is a general security guideline: use white lists, not black lists: only allow what you want and donnot forbid things you know of (there might be much more you dont know of).

I hope that helps. Although I did not add too much.

Best regards

Peter John

[Former Member]

> SE16 is a quite questionable access to BW data.

Many customers went through this and still are in their ERP systems, when they realized data protection requirements after implementing HR or credit card payments or obscure places where passwords are saved.

I guess the same is happening to BW now - if the application and business and organizational logic of the system can be bypassed.

But this is not the sole fault or responsibility of transaction SE16. And restricting the transaction code only is less than a workaround.

> Altogether I also recommend the appraoch suggested by Julius: dont grant access to &NC& fro S_TABU_DIS.You may wait for complains in order to maintain an auth group for the required tables in case you dont know them in advance.

SAP is also partly to blaim for this confusion, because creating a view defaulted the authorization group to &NC& in earlier releases. This created urban legends and forced security into granting the value due to the sheer number of the unmaintained views which requested it.

Users grew used to it and then SQVI came along as well. Certainly the tables in the SUSR area should not be taken at face value of their single fields, regardless of the confidentiality of that single field.

Looking back, perhaps the Information System nodes are to be blamed for this... I can go on for ever...

Good thing is that SAP distinguishes more and more between a transactional system and a reporting system - and both enable application logic with a security concept which is more advanced than tables.

Cheers,

Julius

[Former Member]

Hi Peter,

Just to recap... We are not providing access to SE16 for the purposes of accessing BW business data. Our technical support staff already have access to SE16. As you know it is a very useful support transaction and it is not an option for us to remove access to SE16.

My issue is to now prevent use of SE16 to access HCM data. It seems I have no choice but to remove access to auth group &NC&.

QUESTION:

1. I have 1200 tables classified as &NC&. There are also perhaps 10,000 tables that don't have any auth group set. Does SAP support customers changing the auth group for standard SAP tables?

ISSUES:

1. Removing access to &NC& has now created a maintenance overhead having to reclassify table auth groups.

2. It doesn't seem appropriate for SAP to leave a tables containing HCM data as "not classified".

I think these issues are something that SAP should look at.

Regards,

Richard.

[Former Member]

Changing a table auth group is not a modification, however you should tweak SU24 proposals if SAP had assumed that it would remain the same in SU22. Same thing, except there is no tool to adjust the groups back to a customer setting after an upgrade or (as in your case by the sounds of it) SE14 has been used to delete the table.

> 2. It doesn't seem appropriate for SAP to leave a tables containing HCM data as "not classified".

I think these issues are something which SAP should look at. There are several notes which correct views delivered withought values.

I also do agree with you that it should be changed at it's source, but at the same time believe that it should ideally have a view if it is to be displayed at all - which is not the case here either.

A view with &NC& is much more conceptually flawed IMO - and much easier to fix..

Cheers,

Julius

Edited by: Julius Bussche on Sep 30, 2009 9:29 AM

[Former Member]

Richard Cooper,

Did you find any right strategy?? I am in the same situation and planning to remove the Brower from all the technical users in the BI system. Changing the tables with particular auth groups and restrict groups from roles is a pain with lot of security data maintenance.

Experts please advice. I am in the final stage of BI project and trying to restrict access to HR tables from SE16 from all the technical users.

Thanks,

Kumar.

[Former Member]

So we are on the same boat.

Are hands are tied from an SE16 perspective because even if we don't intend to give SE16, we have to if we want the BW guys to view new, active, change log data on the data content tab of a DSO. SAP requires you to have SE16 authorization, even though you are not directly using SE16.

It doesn't seem like an auth group strategy works either since the dynamic nature of the generated /BIC/... tables. We would have to manually applies auth groups to tables that are generated in each system.

[Former Member]

I sometimes have the impression that there are folks out there who convince SAP to code S_TCODE checks into all sorts of crevices within the system because they don't want to rebuild their roles properly to fix application object authorizations (in this case S_TABU_DIS and assigning groups to their own tables).

However in this specific example, I think it will be easiest and better for the BW developers to call an FM of their own to access their change documents. That way they are not dependent on the aged SE16, can use more modern programming techniques and re-use the analysis authorizations to access the change documents...

My 2 cents,

Julius

[Former Member]

BTW: Have you tried creating a transaction couple in SE97 between your BW transaction context and SE16. You can then maintain a "No check" indicator for it.

It does not work in all cases, but most do.

Cheers,

Julius

[Former Member]

Sorry this is late but I came across this while searching for an answer on another topic. We customized a solution with an SAP consultant, because our HR absolutely refused to allow a few technical people to have access to any HCM data.

When our BI team creates any new info object part of the process is to inform security and if it is for HCM, we add it to a custom table. The table contains the infoobject name, version, and what auth groups we want the generated tables to be associated with. (These tables are generated with different names in each progression of the landscape.) We transport this table up the landscape (whats the point of securing production if you don't QA?) Then along each point of the transport we run a customized program that assigns auth groups appropriately.

The draw back, TDDAT looks different per system, however, as seen with this question, it doesn't look like a great solution is availiable.

Funny someone mentions (blank) auth groups that do not default to &nc& in this thread, as that is what I am looking for information on.

[Former Member]

When our BI team creates any new info object part of the process is to inform security and if it is for HCM, we add it to a custom table.

Exactly that is the point of failure. They will give sap_all and it still wont work. Then they will need to start debugging again...

The interfaces (from the outside) must also access those /BIC/ and some /BI0/ objects, so you must consider the client application context and authorizations anyway.

Custom tables only create hassles and invoke workarounds IMO.

Cheers,

Julius

[Former Member]

Someone necro-posted this thread without adding any useful infos, which is why it appeared again...

Note that since then there is also object S_TABU_NAM and in RSA1 the analysis authorizations are also checked for access to the data.

Cheers,

Julius

[Former Member]

This message was moderated.