[Data Protection and privacy Compliance] API Audit Logs behavior after 1802 release
Reproducing the Issue
1. Currently, If RAL switch is ON and you try to view payload under "Admin Center -> OData API Audit Log -> HTTP Message -> Reponse Payload" or "Admin Center -> SFAPI Audit Log -> HTTP Message -> Reponse Payload", it displays message:"Payload viewing disabled when Read Audit Logging is enabled":
- For any new company instance, both OData and SFAPI audit log switch will be switched off from provisioning backend system.
- For all the existing customer who have enabled API audit logs from provisioning, OData API audit log and SFAPI Audit log will be available under Admin Center.
- When OData/SFAPI audit log switched on:
- request and response header should always be logged (for read and write operation) no matter the request is success or fail.
- when request success either for read or write operation, request and response payload should not be record in api audit log
- when request of Read operation fail:
- when RAL is on, request and response payload should not be record in api audit log.
- when RAL is off, request and response payload should not be record in api audit log.
- Request and response payload will display message: "Payload will only be logged for failed Write operation".
- when request of Write operation fail:
- when RAL is on, request and response payload should not be recorded in api audit log.
- Request and response payload will display message:"Payload viewing disabled when Read audit logging is enabled"
- when RAL is off, request and response payload should be recorded in api audit log.
All API audit payloads will be off when Read Audit logging (RAL) is turned on because RAL is not enabled for API Audit Log payloads. Any reads of Sensitive Personal Data contained in a API audit payload will not be logged to Read Audit log, hence that will be out of compliance.
We are still researching how to implement read audit logging for API Center users that view API audit payloads but currently, we do not yet have a reasonable solution.
The guardrails were introduced to limit payload logging volume because the existing back end can not scale full api payload logging to our ever increasing API usage. Please note we are working on plans to improve our Audit Log infrastructure so we can relax these limitations but the release date is not yet committed.
Please note that the API Audit logs were never intended to be a replacement for proper error handling and reporting client software or middleware. API error responses should be processed and reported on the client side i.e source from where API call has been triggered.
After patch b1802p2 release on 24th March, 2018 as highlighted in KBA 2620222 ,if the RAL switch in the instance has never been modified in Admin Center, between 10th March-24th March 2018, the SuccessFactors instance will have the RAL feature automatically switched off.
Already modified RAL switches will preserve their existing RAL states, and no modification will be applied to the current RAL state. Customers are still highly recommended to double check their new RAL enablement switch after 24-March-2018.
In order to have the logs available, whenever possible/necessary the RAL switch can be updated, according to the aforementioned KBA 2620222.
Payload viewing disabled when Read Audit Logging is enabled , KBA , LOD-SF-INT , Integrations , LOD-SF-INT-ODATA , OData API Framework , LOD-SF-INT-API , API & Adhoc API Framework , How To