Vault Key Scheduled for Deletion Before a Departure
Helios Health keeps 6 TB of imaging studies in an Object Storage bucket in us-ashburn-1, encrypted with a customer-managed AES-256 HSM-protected key in an OCI Vault in the same region. Cross-region replication copies the bucket to us-phoenix-1 for disaster recovery. A compliance finding requires annual key rotation, that no single person be able to destroy key material, and that the DR copy be unreadable if production key material is lost. Last Friday an administrator with Vault management rights scheduled the key for deletion; HR confirmed his departure on Monday. Object versioning is enabled, with a lifecycle rule deleting noncurrent versions after 30 days. No one has ever tested restoring from the DR copy. A team member has suggested exporting the key material to an encrypted USB drive as an insurance policy in case the vault is lost.
1. What do you do about the scheduled deletion in the next hour, and why does the disable/delete distinction matter more than the outcome of the cancellation?
Read the worked answer
First hour. Cancel the scheduled deletion (cancel-deletion on the key). Key deletion is not instantaneous: OCI enforces a waiting period of 7 to 30 days precisely so a mistake or a malicious schedule can be reversed, and during that window the key still functions. Then check Audit for everything that administrator did in the prior 30 days - schedule deletion is rarely the only action - and remove his Vault rights immediately.
Why disable is a different tool. Disabling a key is a reversible state change: cryptographic operations fail, the data is untouched, and re-enabling restores service. Deleting a key destroys its key versions, and anything wrapped by them - every object in that bucket and its replicas - becomes permanently unreadable. There is no recovery, no Oracle-side unlock, and no support escalation that fixes it. The 7-day window is the only safety net, which is exactly why one administrator should never be able to set it alone.
Do not disable now. Disabling the production key would take the imaging system offline and look like an incident of its own. The correct sequence is: cancel deletion, contain the person's access, assess whether rotation is warranted (it is), and treat the absence of a second approver as the real finding - no policy or group design currently forces four eyes on key destruction.
2. Evaluate the USB export idea and design the key custody model for us-phoenix-1 that satisfies the DR requirement.
Read the worked answer
The export idea is wrong on every axis. The key is HSM-protected; by design its material cannot be extracted from the module, and that non-exportability is the property the compliance finding is buying. A USB copy would be unencrypted-at-rest, outside Audit, outside rotation, unprotected by the deletion-approval control, and it would silently break the HSM's FIPS 140-2 Level 3 claim. It converts a technical control into a physical-security problem held by one person.
DR model. Each bucket carries its own encryption setting, and the replicated destination bucket in us-phoenix-1 is encrypted with a key in a Phoenix vault. That means the DR story is custody of that key, not of the source key: designate key administrators and break-glass approvers in the destination region, document their names in the runbook, and confirm the replication policy and destination bucket exist as expected.
Re-read the requirement. "DR copy unreadable if production key material is lost" is satisfied by the independent DR key - losing Ashburn does not expose Phoenix. If a stakeholder actually means "the same key material must be available in both regions", that requirement contradicts non-exportability and must be rewritten, not worked around.
Also fix today. Versioning with a 30-day noncurrent deletion rule means a malicious or accidental delete destroys the rollback in 30 days. Add an Object Storage retention rule on the bucket so studies cannot be deleted or overwritten inside the regulatory period.
3. The team rotates the key and reports the compliance finding closed. What is wrong with that claim, and how would you restructure the IAM so destruction needs two people?
Read the worked answer
What rotation does and does not do. Rotation in OCI Vault adds a new key version on the rotation schedule; older versions remain usable for decryption. Because Object Storage uses envelope encryption, existing objects keep the data keys wrapped by the version in force when they were written. Rotating therefore limits the useful life of the master key going forward; it does not re-encrypt 6 TB of pre-existing studies, and it does not reduce exposure of anything already written. If the finding means re-keying, you must rewrite the objects, which is a migration project, not a console action.
Restructure the groups.
KeyAdmins:manage keysandmanage vaultsin the Security compartment, with noread objectsanywhere in the tenancy. They can rotate and operate keys but cannot read the data they protect.DataReaders: object read on the imaging compartment, with no Vault rights.- Break-glass: a separate group whose
manage keysmembership is checked out through the safe, MFA-bound, and time-boxed. Key deletion requires that group plus a ticket.
Watch the union rule. OCI policies are additive, so a person in both KeyAdmins and DataReaders holds the union - the group boundary, not the policy text, is your separation of duties. Audit group membership quarterly. Add an Events rule on key-schedule-deletion that pages the security lead, because OCI will not enforce a second approver for you.