Objects retention, legal hold, and a shared S3 access key
A healthcare claims processor must retain 180 TB of scanned claim images for seven years. The application writes about 30 million objects averaging 4 MB through the S3 API. A single access key is hard-coded in the application config and shared by three developers. The current bucket has versioning disabled. Last month a developer script deleted 12,000 objects; recovery required restoring an older backup and lost two days of claims. Compliance requires legal hold for claims under investigation and an audit trail of every deletion. The Nutanix Objects cluster has four nodes with 60% usable capacity consumed. The team proposes enabling bucket versioning, setting a seven-year lifecycle expiration, and creating one new access key for the application. They want to know whether that is enough and how to avoid another deletion event. The security team also wants to remove the shared developer key without an application outage.
1. Evaluate the proposed versioning, seven-year lifecycle, and one new access key. What is missing?
Read the worked answer
The proposal is directionally right but not enough. Versioning stops a simple delete from removing the only copy, and lifecycle can expire data after seven years, but an authorized identity can still delete individual versions or place delete markers. Enable S3 Object Lock in compliance mode with a default seven-year retention, and keep versioning on because Object Lock requires it. Confirm the Objects release supports Object Lock before promising compliance. Apply a bucket policy that denies s3:DeleteObject and s3:DeleteObjectVersion to everyone except a break-glass role, and do not give the application delete rights at all. One new shared key does not fix the root cause: use a dedicated application user with write and list only, and individual analyst users with read only. Capacity is a separate risk: 60% of usable capacity is already consumed, and versioning plus legal holds will increase stored bytes. Model 30 million objects at 4 MB plus noncurrent versions and keep headroom; do not set lifecycle to expire noncurrent versions before the retention period.
2. How should legal hold and deletion auditing be designed for investigated claims?
Read the worked answer
Legal hold is per object version and is independent of the retention period. When a claim is under investigation, apply a legal hold to the specific object or version; do not rely on copying it to another bucket. Release the hold only through a documented compliance workflow with a second approver. For audit, enable server access logging on the bucket and deliver logs to a separate, write-protected bucket, then export to the SIEM. Log every DELETE, DeleteObjectVersion, PutObjectLegalHold, and retention change. Restrict who can change Object Lock settings. Test with a non-production object: try to delete a held object as the application user, confirm denial, and confirm the event appears in the audit log.
3. How do you rotate the hard-coded access key without an application outage?
Read the worked answer
Do not create one replacement key and leave it in the config. Create a new application identity or second access key, scope it to the minimum bucket and prefix, and deploy it through a secret manager or environment injection. Run both credentials during a short overlap, verify writes and reads, then deactivate the old key. Because the current key is shared by three developers, remove their use first; give each developer a read-only key only if they need it. If the application cannot reload credentials without a restart, schedule a rolling restart behind a load balancer. Monitor authentication failures and 403s during the cutover, and keep the old key disabled, not deleted, until the new path is stable.