Audit Finding on a 4 TB COS Bucket with BYOK
An audit of a 4 TB IBM Cloud Object Storage bucket in us-south finds three issues: the bucket has public access enabled so a marketing site can read objects directly; a service ID with Writer access has its API key stored in a CI repository; and Activity Tracker events are not routed to the SIEM. The bucket uses Key Protect with a customer root key, versioning is on, and there is no lifecycle policy. The auditor asks for evidence of encryption at rest, key rotation, least privilege, and object-level access logging within 10 days. The team says rotating the root key will re-encrypt 4 TB and may take days, and that disabling public access will break the marketing site. A security engineer proposes moving the site to Cloud Internet Services and using signed URLs.
1. Correct the team's assumption about Key Protect rotation and describe the evidence you would provide.
Read the worked answer
Key Protect root-key rotation creates a new key version; it does not rewrite the 4 TB of object data. Existing objects remain decryptable because prior key versions are retained, and the service uses the new version for future wrap operations. If policy requires existing data to be wrapped by the latest version, that is a separate rewrap or re-encryption migration, not the routine rotation itself. The team is conflating rotation with bulk data re-encryption.
Evidence to provide: the bucket's encryption configuration showing Key Protect and the root key ID; the Key Protect key version list with rotation dates and the rotation policy; Activity Tracker events for key create, rotate, disable, and delete; IAM policies showing who can administer the key; and a statement of the rewrap policy for existing objects. Also show that versioning and retention protect against accidental deletion. If the auditor requires all objects under the newest key version, scope a rewrap project with a sample validation plan rather than claiming rotation did it.
2. How do you remove public access without breaking the marketing site, and what do you do about the leaked API key?
Read the worked answer
For the site: do not disable public access until the replacement path is live. Put Cloud Internet Services in front of a private bucket, use signed URLs or a controlled proxy, test with a staging hostname, then cut DNS over. Keep the bucket private and verify with an unauthenticated request that objects are no longer readable directly. If the site is static, consider a CIS cache and origin protection so the bucket is not exposed. For the leaked key: revoke the service ID's API key immediately, remove it from the repository, scan history and build logs for reuse, and replace it with a trusted profile or a service ID that has only the required bucket and path permissions. Move credentials to Secrets Manager and rotate on a schedule. Add a pre-commit secret scan and a CI policy that fails on long-lived API keys. Verify no other policies grant public access to the bucket or its objects.
3. What logging and alerting would satisfy the auditor, and what are the limits?
Read the worked answer
Route Activity Tracker events through Activity Tracker Event Routing to the SIEM and retain them per policy. Alert on bucket public-access changes, IAM policy changes that grant public or broad access, key disable/delete/rotate events, and failed authorization spikes. For object-level reads and writes, enable COS server access logging to a separate log bucket, because Activity Tracker primarily records control-plane actions; object-level telemetry needs the access-log path or event notifications. Protect the log bucket with its own private access and retention. Limits to disclose: access logs are delivered with delay and incur storage cost; retention is finite; and control-plane logs do not prove who read an object unless data-plane logging is enabled. Give the auditor a sample query, retention period, alert rule, and a test event showing the pipeline works end to end.