Reading the SCP NEO Audit Log

The second part of the compliance question I often see is how to use the Audit Log. Whilst we have provided some documentation in 2637286 – How to get Audit Logs on SAP Cloud Platform Neo / Cloud Foundry and on help.sap.com there is still little support for. a worked example.

 

It should be noted that the audit log functionality is quite basic and reports the events in a limited manner. The API should also be used in conjunction with the Audit Log Retention API which configure how long the events should be retained.

 

I am now going to segue into why need the audit log. Most large companies have complex GRC – Global Risk Management and Compliance processes in place to ensure adherence to standards and also to accounting responsibilities such as Sarbanes Oxley. These processes need to be translated into SAP Cloud Platform. Sometimes this is easy, sometimes it is not.

With the “NOT” case the normal process we see is the customer adopts cloud platform slowly, bring more and more applications and processes online. They start with S-Users and then assign a mixture of groups and roles to the those S-Users. This is all working fine until the dreaded audit happens and then it falls apart. Normally remediation consists of either adopting SSO or IAS.

 

On the one hand by converting the tenant to use the enterprise SSO can be challenging as it often requires cross organizational support to implement and some reconfiguration of the tenant, this solves the compliance issues as all user management and reporting is now part of the enterprise authentication and authorisation systems and so the reporting and responsibilities are not aligned with GRC.

 

The other option is use the Identity and Authorization Service (IAS) which offers a front end to user management that is more aligned with enterprise standards by offering custom password policies, two factor authentication, custom UI and multiple identity providers as well as support for identity lifecycle management and identity provisioning.

 

The typical route I see is that customers go from S-Users and the tenant default security model to the IAS option which often fixes many of the compliance issues but the limitation is normally weak reporting functionality.

 

Now back to the reason for this blog post – how do we use the Audit Log? SAP Cloud Platform offers access to the Audit Log through a programmatic API but there is no UI to display this. For the purposes of this post we will be using Postman.

 

The major limitation of the audit log is that the log retains events for a limited time. This means that the if you need to retain it for a longer period you will need to write some middleware that will take the changes in the audit log and persist them into a database where you can then write the reporting functionality that is needed.

 

Getting the log events is, like the member list, a two part operation. The first part is to get the oAuth token and the second is to get the actual events.

 

Part 1: Getting the oAuth token

To access the audit log open your Cloud Platform Cockpit and goto the oAuth panel under security.

Once opened, select the “Platform API” tab.

 

Click the “Create API Client” button to create a new oAuth token. This will open a new form where you need to supply a description and select the “Audit Log Service” scope to ensure the generated token will have access to the audit log.

Click “Save” to create the new client secret and client id

 

This completes the first part of the exercise. Please remember to store the Client ID and Client Secret somewhere safe as these will be used to generate a secure token to access the audit log service in the next part.

 

Now we have the client secret and id we can open postman and generate a new oAuth token.

As we did previously we use the URL

https://api.eu1.hana.ondemand.com/oauth2/apitoken/v1?grant_type=client_credentials

 

This is the data center which hosts our account and that we want a client_credentials token back.

Ensure the request is a post request to the URL above and then under the authentication tab, use the client id and client secret

 

Click “Send” to execute the request

This returns the access token that we need to save as its only valid for 1500 seconds. It would also be good to verify at this point that the scope consists of the manageAuditLogs and readAuditLogs as these are what we need to retrieve the audit log.

This completes the first part of accessing the audit log, getting the access token.

 

Part 2: Reading the Audit Log

Since we now have the token the audit log is accessible.

Following the documentation on accessing the audit log, make a get request using postman to the end point

 

As I mentioned in the previous blog post, the most confusing aspect of this is the name to use for the subaccount. This should be the technical name of the account and not the id.

The subaccount name is located in red rectangle above.

 

The URL we need to use the audit log is thus:

 

https://api.eu1.hana.ondemand.com/auditlog/v1/accounts/a4242032d/AuditLogRecords

 

Go back to postman and use this URL and the oauth token we generated previously to access the audit log.

 

Note that the Auth tab now uses the “Bearer Token” type rather than the previous “Basic” type.

Click “Send” to request the audit log from your tenant subaccount

 

This is the response that comes back from the audit log API. Because there can be substantial numbers of events, the API uses the skip token functionality of the OData specification, allowing you retrieve page after page of events. The documentation covers how to deal with large payloads and using the oData features of the API such as filtering.

 

Wrapup

Often when using these API’s customers ask for a front end to use them. If you do not plan to write a dedicated solution/app to get the data, one of my recommendations would be to use this in an Integration Flow with SAP Cloud Integration to create the token, get the data and transform then deliver it. Otherwise it should be quite easy to write on using UI5 and of course for Cloud Foundry we have done so already. If you look under the Subscriptions section you will find an Audit Log Viewer app that provides access to the audit log. Of course as with the NEO version we built above, your require the correct roles to be able to access the log.