Oracle on SAP Auditing

[Former Member]

Hi

we recently had an audit on our Oracle databases which are used by SAP. The audit came back with some points which we were asked to change. I informed the auditor the the Oracle SAP databases were created by the application during the installation of the applications (modules) and that the DBA did not set any of these parameters therefore if SAP had set them then there has to have been a reason behind it therefore it should not be changed to avoid any interruption to services

Here were some of the findings

1. Default database role (PUBLIC) has been granted u201CExecuteu201D access to 98 financially significant tables. This may result in unauthorized users being granted key privileged rights or access to key resources, including access to sensitive utilities and master files.

We recommend that:

A. Following sensitive object privileges should not be assigned to the PUBLIC role:

INSERT

UPDATE

ALTER

DELETE

EXECUTE

B. Default SAP accounts are active and can bypass database authentication from any server on the network, due to which key privileged rights are granted to unauthorized users. Besides, unauthorized access attempts may not be detected and resolved by Management.

Host-based authentication is utilized to ensure security controls outside the database (such as operating system controls) support database authentication. This means all the user accounts will have to authenticate before accessing the database server from any other connected server.

During our review, we noted that default SAP accounts OPS$B72ADM, OPS$SR4ADM can bypass host-based authentication for database server from any server on the network.

RECOMMENDATION(S)

We recommend that

for default SAP accounts access level to the database is controlled by changing the OS_AUTHENT_PREFIX value of u201C u201C (blank) indicates that this feature is disabled

My Questions are

1. Since the above findings were set on the database during the installation of the application as per the SAP installation guidelines , should they be changed and would changing have any impact if we apply the above recommendations

2. Shouldnt the Oracle databases be audited using special auditing tools/scripts which have an understanding of how Oracle works with SAP instead of using the general oracle auditing which are very general and common , if so what is the best method to audit the oracle databases which are running on SAP

[Former Member]

Hi Rayyan,

1. Since the above findings were set on the database during the installation of the application as per the SAP installation guidelines , should they be changed and would changing have any impact if we apply the above recommendations

As per the [Help Link|http://help.sap.com/saphelp_nw70ehp1/Helpdata/EN/fa/bc883989676778e10000000a11402f/content.htm|http://help.sap.com/saphelp_nw70ehp1/Helpdata/EN/fa/bc883989676778e10000000a11402f/content.htm],

SAP does not support changes of the Oracle parameter os_authent_prefix whose default value is OPS$.

The 11th question of the SAP Note [562863|https://websmp230.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=562863|FAQ Logon mechanisms] clarifies on who will be able to access the DB with the OPS$ user. Also the 29th question of the SAP Note [700548|https://websmp230.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=700548|FAQ Oracle authorizations] says that,

You must not simply delete grants on DBA, USER or ALL views (for example, ALL_USERS) that were assigned to PUBLIC. It is not possible to estimate where these objects are accessed (monitoring transactions, BR*TOOLS, and so on).However, you can avoid problems if, when deleting grants, you make individual grants for potentially relevant users, for example:

REVOKE ALL ON ALL_USERS FROM PUBLIC;
GRANT ALL ON ALL_USERS TO SAP<sid>;
GRANT ALL ON ALL_USERS TO OPS$...;

So we cannot simply fulfill the recommendations by changing the OS_authent_prefix parameter and by removing the Grants from the oracle users without knowing the impacts/side effects of doing so.

2. Shouldnt the Oracle databases be audited using special auditing tools/scripts which have an understanding of how Oracle works with SAP instead of using the general oracle auditing which are very general and common , if so what is the best method to audit the oracle databases which are running on SAP.

Based on the above mentioned facts, I too agree with you that it would be better to audit the oracle databases, built for SAP, using special auditing tools/scripts instead of auditing with the general/classical method.

Regards,

Varadharajan M

[volker_borowski2]

Hi,

if you are on version 11 and able to switch to the brand new AKK 7.20 Kernel you can dump the OPS$ connect.

Note 1622837 - New connect method of AS ABAP to Oracle via SSFS

Keep in mind not to dump the OPS$ User, which is still used by brtools, but authenticates locally.

If you can not do this (6.40, ...),

Note 157499 - OPS$ connect and security aspects

decribes how to tighten the listener a bit.

Note 926023 - Oracle database security

describes a couple of security settings that can be applied and in addition some

revokes for the public role, as long as you have SAPUPROF in action.

Hope this helps

Volker