Unauthorized deletion of audit tables

[Former Member]

Hi,

the Identity Center stores audit information in one of the database tables. But as an administrator I can easily configure jobs that perform operations on the database such as the deletion of records and tables. This means that the IC admin should also be able to delete audit records in case he tampered with the configuration.

Has anyone introduced SAP IC for compliancy reasons and found a solution on how the integrity of the audit records can be guaranteed?

Best regards,

Holger

[Former Member]

I concur with Matt this is a problem with any system account with high privileges. In the past I deployed [SNARE|http://www.intersectalliance.com/snareserver/index.html] as a central logging and analysis tool. And of course it always comes back to Quis custodiet ipsos custodes.

[Former Member]

Gregg,

I agree that this is the same problem as with other tools that give you administrator privileges. And the copying of database or using a tool like Snare tables might be a viable way for the customers.

But in general, I would almost consider the logon to the Identity Center with a database account as a design weakness. One problem that we have already discussed is the auditing and the full access of the admin to the database. Another issue that is closely related to this is that the DBA can modify any internal data using SQL Update commands without anybody being able to realize that. Especially in the financial services sector, this might be a no-go. And in addition, because of the usage of the database account for logging on to the system, Identity Center is not able to support role-based or delegated administration for the IC configuration. I can not for example configure that one user can only configure resources and another user can only configure one identity store. This is at least my perception and correct me if I'm wrong.

Other tools solve this by using the users in the identity store for logging on to the system. This means that administrators do not have a database account and do not have full access to the database. In addition, using identity store users that do not have full access to the database allows you to perform delegated administration as I have described above, where certain admins are only able to see certain areas of the configuration. To control changes even further, it is sometimes also possible to start a workflow where all changes by an admin need to be approved by somebody else before the changes take effect.

Best regards

Holger

[Former Member]

Hi Holger,

I aggree with you, that the administrator's access (or the lack of a RBAC in the tool itself) is a design weakness.

Thus, I don't think there are any more answers to your issues (see chapter 8 in the SAP NetWeaver Identity Management Security Guide for even more examples).

Gregg's proposal to guard the db itself (at least that an attack might be detected, if it can't be ruled out) is currently the only approach I am aware of.

[Former Member]

Hi Holger,

I think that either you or I am missing something here. Please see Section 4 of the Identity Management Security Guide -- 4.1 Identity Center database logins and roles. The users can be assigned DB roles that do not have full access and can then be audited as to who did what in the DB.

Best Regards,

Matt

[Former Member]

Hi Matt,

probably I'm missing something, because I do not see, how I can restrict the privileges of an admin, who needs to make changes in the SAP IC, so that he is not able to delete the audit database tables. Maybe manually modifying the role to include read-only rights to the audit table would solve the problem?

Best regards

Holger

[Former Member]

Hi Holger,

Oh, ok, now I see your point. This is why it says in section 9.1 of the Identity Management Security Guide:

>9.1 The Identity Center configuration UI

>The Identity Center configuration UI (Microsoft Management Console snap-in) is intended for implementation of a solution. It should not be made available in a production environment, unless there are very good reasons to use it. Logs and other information can be accessed using the Monitoring interface.

In other words, nobody should be given such access to audit tables in production.

Best Regards,

Matt

[Former Member]

Holger,

One potential workaround is to direct the audit tables to a different server that the IC administrator does not have direct access to. I have heard abou this is done, but I have not seen it done. Also usually the SQL DBAs have knowledge about securing this part of the environment.

Matt

[former_member198313]

Hi Holger

Currently IDM doesnu2019t provide such restriction for the Admin.

The Admin of IDM solution has all the access. I am not sure that how it is handled in Database.

However there can be a email sent or logs saved everynight/changes in audit flags. This will enable the auditing of the audit flags.

Hope this helps,

+ An