Overview
Every YaaS service potentially deals with personal data. Therefore, the Audit Ingestion service enables YasS services to create the appropriate audit logs. With the Audit Retention Service, you can modify your audit logs' Retention Policy. This policy states how long your audit logs are stored before they are permanently deleted. By default, audit logs are stored for two months upon ingestion via the Audit Ingestion service.
The Audit Retention service, like the Audit Ingestion Service, supports three types of audit logs:
- security event logs - logged security events, such as attempts to change address information without sufficient permissions
- personal data change logs - logged events of any personal data amendments, such as an email address change
- configuration change logs - logged events of configuration changes, such as assigning a new user to a project
Note that as a data owner, you are responsible for providing logs for events related to personal data to the data subject or data controller, for auditing purposes. The Audit Retention service allows you, as a YaaS user, to define retention policies for your audit logs.
API Reference
/policy/{auditType}/{sourceType}/{source}
/policy/{auditType}/{sourceType}/{source}
Creates or updates the retention policy for the given auditType, sourceType, and source.
Gets the retention policy stored for the provided audit-type, source-type, and source The caller of the query must fulfill the same yaas authorization requirements as the original query.
Security Considerations
Changes applied to a retention policy affect the permanent deletion of audit logs. Deleted logs are no longer accessible and cannot be restored. For this reason, restrict access to this service to only the people allowed to change retention policies, who are generally those people allowed to decide when to delete audit logs.
Scopes
To access the Audit Retention service, use one of the following scopes.
hybris.audit_retention_view
gives you read access to your audit data retention policy. With this scope, you can query the audit retention policies that you defined for your audit data.hybris.audit_retention_modify
gives you write access to your audit data retention policy. With this scope, you can modify the audit retention policies for your audit data.
Limitations to Changing Retention Policy Periods
The Audit Retention service assigns all audit logs a default retention policy with a retention period of two months. If you want to change your audit logs' default retention policy, you may do so provided you specify a retention period that satisfies the following three requirements:
- The retention period must at least span two months.
- The retention period may not span more than tree years.
- The retention period uses only up to day precision, you may not specify retention periods mentioning hour or minute durations.
Examples of correct retention policy periods:
P1Y3M22D
: a retention period of one year, three months, and 22 days.P1M2D
: a retention period of one month and two days.
Examples of wrong retention policy periods and causes:
P5Y
: The maximum retention period cannot be more than three years.P2D
: The minimum retention period cannot be less than two months.P2M2DT3H
: The retention period cannot be specified to a precision of hours, only days.
Use the service
The Audit Retention endpoints allow you to change the retention policy for your audit logs.
Get a retention policy for audit logs
There are three types of audit logs. Always retrieve retention policies by type through these endpoints:
/policy/personal-data-changes/{sourceType}/{source}
for personal data change events./policy/configuration-changes/{sourceType}/{source}
for configuration change event./policy/security-event-changes/{sourceType}/{source}
for security-related events.
You can retrieve retention policies for audit logs through the following source types:
- Use tenant for all the audit logs owned by a certain tenant. In this case use
tenant
for the sourceType andhybris-tenant
for the source. To get the policy for a specified tenant, provide a token in whichhybris-tenant
has the same value as the source field, and a scope of hybris.audit_retention_view. - Use organization for all audit logs owned by a specific organization. In this case, use
organization
for the sourceType andhybris-org
for the source. To get the policy for a specified organization, provide a token in whichhybris-org
has the same value as the source field, and the scope hybris.audit_retention_view. - Use account for all the audit logs owned by a certain
yaas
account. In this case useaccount
for the sourceType and thehybris-user-id
for the source. To get the policy a specified user, provide a token in whichhybris-user-id
have the same value as source field, and the scope hybris.audit_retention_view.
When you provide all values as expected, the service responds with a 200 OK
response code that contains the retention policy as JSON in the message body. For example:
GET /policy/personal-data-changes/tenant/tollans
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
HTTP/1.1 200 OK
Content-Type: application/json
{
"retention-period": "P2M"
}
The retention-period field is an ISO8601 duration. In the example, P2M means two months.
Change a retention policy for audit logs
To change the retention policy for your audit logs, you can send a POST query to the same endpoint that you use to retrieve the policy. In this case, provide the scope hybris.audit_retention_modify. Provide a JSON body that includes the new retention policy. For example:
POST /{log-type}/{sourceType}/{source}
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
Content-Type: application/json
{
"retention-period": "P2M"
}
When your request is successful, the service returns a 201 Created
response code.
The service requires a minimum retention period of one month and a maximum retention period of three years. Moreover, in between the minimum and maximum allowed retention periods, your provided ISO8601
period can be precise only up to days. See the Limitations section for details. If your retention policy change query does not fulfill this limitation, the service returns a 400 Bad Request
error.
If you find any information that is unclear or incorrect, please let us know so that we can improve the Dev Portal content.
Use our private help channel. Receive updates over email and contact our specialists directly.
If you need more information about this topic, visit hybris Experts to post your own question and interact with our community and experts.