Protect logs in Object Storage
An Object Storage destination stores the logs delivered by your stream. To ensure those logs stay intact and available, set up your bucket in a way that prevents accidental changes, unauthorized access, or early deletion.
Users should not be able to:
- alter or forge log content
- prevent audit logs from being written
- delete logs before they meet your retention criteria
Users who can delete Object Storage buckets, manage access keys, or change bucket permissions can interfere with audit log delivery. To reduce this risk, store audit logs in a separate account and limit who can manage that account.
A typical setup includes the following steps:
- Create a dedicated account used exclusively for audit log storage.
- Limit access to this account to security administrators.
- Create an Object Storage bucket in that account and enable Object Lock.
- Create a read-write access key for the bucket.
- Apply a lifecycle policy to the logs in the bucket.
- In your main account, configure log delivery using the bucket created in step 3 and the key created in step 4.
- Create read-only access keys for any person or system that needs read access to stored logs.
- Regularly rotate all access keys associated with the bucket.
The following sections expand on these steps and outline practices that help to protect your logs.
Create the audit logs bucket with Object Lock enabled
Object Lock helps prevent log tampering by ensuring that once logs are written, they cannot be deleted or overwritten until their retention period ends. Object Lock must be enabled when the bucket is created.
Example:
aws s3api create-bucket
--bucket my-audit-logs-bucket
--object-lock-enabled-for-bucket
--endpoint=<https://gb-lon-1.linodeobjects.com>
Select a Mode
- COMPLIANCE mode is suitable for strict retention requirements. Objects cannot be deleted by any user or Akamai until the retention period has expired.
- GOVERNANCE allows deletion under certain conditions and may be used if you need the ability to remove logs sooner.
You'll be billed for audit logs stored in a bucket in COMPLIANCE mode until the data is deleted or the account is closed. Data can only be deleted after the original compliance period for that data ends.
Choose a retention period
Select a retention period that aligns with your organization's requirements. Common examples include 90 or 365 days.
Example (365-day retention in COMPLIANCE mode):
aws s3api put-object-lock-configuration
--endpoint=<https://gb-lon-1.linodeobjects.com>
--bucket my-audit-logs-bucket
--object-lock-configuration '{ "ObjectLockEnabled": "Enabled", "Rule": { "DefaultRetention": { "Mode": "COMPLIANCE", "Days": 365 }}}'
Apply a lifecycle policy to the logs in your bucket
Apply a lifecycle policy to ensure that logs are retained according to your organization's data retention requirements. The lifecycle policy should be set to expire logs at the end of their Object Lock retention period.
Example (expires logs after 365 days):
<LifecycleConfiguration>
<Rule>
<ID>audit-log-data-retention</ID>
<Filter><Prefix></Prefix></Filter>
<Status>Enabled</Status>
<Expiration>
<Days>365</Days>
</Expiration>
</Rule>
</LifecycleConfiguration>
Apply this policy using s3cmd:
s3cmd setlifecycle lifecycle_policy.xml s3://my-audit-logs-bucket
Manage access keys
Access key management is a customer responsibility. Rotate the Object Storage access key every 90 days to reduce credential exposure over time.
Suggested rotation flow:
- Log into the account containing the Object Storage bucket used for logs.
- Create a new read-write access key for the bucket.
- Log into your main account and update the destination configuration to use the new access key.
- Wait for the configuration to propagate. This can take an hour or more.
- Return to the account containing the Object Storage bucket and revoke (delete) the old access key.
Updated about 11 hours ago
