Daniel Berlin on Security Insight on SAP security, development stuff… and all the rest

28Apr 12

Find SAP tables without table authorization group

Hi people,
another common finding of audits is, that not all (of your customer-) tables are assigned to a table authorization group — allowing everyone with S_TABU_DIS and DICBERCLS = "&NC&" to access them. Therefore, you might want to take care of this…

(Certainly, this is not always a sensible check 🙄 – it depends on the data contained in the respective tables! … but anyway many auditors check for it.)

The challenge

The assignment of tables to authorization groups is defined in table TDDAT; but it only contains registered assignments. If a developer never assigned his/her table to an authorization group, it won't appear in it. So the problem is to find all tables without an entry in TDDAT plus all tables with an empty entry there. Furthermore, some "tables" are uninteresting, e.g. structures, help views and temporary or local tables, as they don't contain any sensible data.

Please, do not start Excel at this point… there is a better way!

The idea

Obviously we need a way to list all unprotected tables (no matter whether they're in TDDAT or not) and automatically exclude all table- (and view-) types containing uncritical or no data.

Therefore, we need to find DDIC objects, which…

  • have no entry in TDDAT or
  • are assigned to the authorization group "&NC&" (which has the same effect as no entry) or
  • are assigned to an empty authorization group (same effect) and
  • aren't internal tables or append structures (as they cannot contain data) and
  • aren't help views, structure views or append views (which do not contain real data as well) and
  • aren't tables for temporary data and
  • aren't local (i.e. not transportable) ← YMMV.

The solution

Fortunately, I was bored some time ago and programmed a report for this…
So:

  • Create a new program in SE38:

  • Fill in the attributes:

… and choose a suitable authorization group (P_GROUP, marked red)!

  • Maintain the selection texts:

… and leave P_COUNT and P_EMPTY empty, tick "Dictionary reference" for the other ones.

  • Activate and execute it.

Usage

The report shows the following selection screen on execution:

On the first tab you can:

  • Select the range of Table names to inspect, e.g. "Z*".
  • Choose whether or not to Check tables for data (i.e. determine whether the number of rows is > 0)
    … which might heavily increase the runtime!
  • Decide whether to Show empty tables (if you've selected the previous option).

The second tab is pre-filled with sensible values (YMMV):

  • The Authorization group field is set to "&NC&" and empty values (only for tables that exist in TDDAT).
  • The Table category is set to exclude structures and append structures.
  • The View type field excludes help-, structure- and append-views as well as views without any type,
  • The Delivery class option excludes tables for temporary data.
  • The Package field is dynamically ❗ filled with all local packages on the system, the report runs on.

Now execute it and you'll get a result like this:

In the ALV header, you can see the number of tables matching your selection and the number without an authorization group.

Columns:

  • Table name — … self-explanatory.
  • Short description — table description from the data dictionary.
  • AuGr — assigned authorization group (usually "&NC&" or empty).
  • Description — the authorization group's description from TBRGT.
  • Data — whether or not the table contains any data (only available if you ticked "Check table for data").
    If it contains a flash symbol, the check failed.
  • Cl.-spec. — whether or not the table is client specific.
  • Log — whether or not the table has "Log data changes" enabled in its technical settings.
  • Del. class — the delivery class, which might give you an indication to classify the table contents.
  • Package — the package the table belongs to (might point you to the "area" the table belongs to).
  • Tab. cat. — the type of the table (e.g. transparent -, cluster -, pool table or view).

Furthermore, you can double-click on the following fields:

  • Table name — jump to SE11.
  • Short description — inspect the selected table via SE16.
  • AuGr — open SE54.
  • Data — show the number of entries in the table.
  • Cl.-spec. — show description.
  • Log — show technical table settings.
  • Del. class — show all available delivery classes.
  • Package — open the package explorer.
  • Tab. cat. — show a list of table types.

Conclusion

Have fun, play around with the options and clean up your system! 😀

Comments (5) Trackbacks (0)
  1. Hi Daniel.
    Thank you for this interesting post. I know it’s an old post, but please assist me if you can. From an audit point of view, the risk is that these tables can be accessed by people that should not have access if they are not assigned to authorization groups.

    If IT advises that they have mitigated this risk by strictly controlling their user access in terms of granting, modifying and terminating user access, do you think this would be sufficient and it would be ‘Ok’ in essence to have custom tables/reports not assigned to authorization groups?

    Are there any other risks that we can bring to their attention? Thanks!

    Kind Regards,
    Jasmine

  2. Hi Daniel;
    I know it’s a old post, but any way I would like ask something about that. We have some tables without auth group in a production system. How we can remediate it; how we can add the right auth group to the tables now without problems.

    Regards,
    Marcos

    • Ciao Marcos,
      you can assign a table to an authorization group via tcode SE54:

      First, choose option “Assign authoriz. group” and then click on the “Create/change” button.
      In the popup select “Table name”, submit and then enter the name of the table(s) you want to assign to a group. The next screen is a simple table maintenance view, where you can enter your assignments.

      Alternatively, you can also go to SM30 directly, enter view name V_DDAT_54 and perform your changes there.

      There’s only one thing left to say: of course, this change needs to be made on the development system and transported to production afterwards.

      Best regards,
      Daniel

      • Thank you Daniel for your response.
        It might be a problem for all the Z-transactions and -programs, which are using these tables; it could be a problem when we just add the tables to an authorization group. Should we validate all this codes and programs? What is your opinion about that?

        Thank you in advance.

        • Hi Marcos.
          Programs (and the respective tcodes) that are using your tables in their source code (e.g. SELECT or UPDATE table rows) should not run into any problems, once the tables are assigned to an authorization group. That’s because the ABAP- (or OPEN SQL-) statements do not trigger an authorization check by themselves – you have to add such a check explicitly to your code.
          Nevertheless, SE16 and similar transactions will definitively check for the new authorization group – so this is something to take care of!

          Regards, Daniel


Leave a comment


No trackbacks yet.