13.2 Data Integrity Protection: Object Lock, Vault Lock & Code Signing

13.2 Data Integrity Protection: Object Lock, Vault Lock & Code Signing

In mission-critical enterprise environments, preventing unauthorized data modification, tampering, and deletion is just as critical as enforcing confidentiality. Regulated sectors—such as financial institutions governed by SEC Rule 17a-4(f), FINRA Rule 4511, and CFTC 1.31, healthcare systems governed by HIPAA, and government organizations following NIST SP 800-53—mandate Write Once, Read Many (WORM) storage guarantees. Under WORM compliance, records committed to storage must remain strictly immutable, tamper-evident, and protected against deletion for mandated retention periods.

AWS provides native, certifiable WORM storage across hot and cold storage tiers through Amazon S3 Object Lock and Amazon S3 Glacier Vault Lock. Furthermore, to extend cryptographic integrity guarantees into the application execution tier, AWS Signer coordinates with AWS Lambda Code Signing Configurations (CSC) and container registries to ensure that only verified, cryptographically signed binaries execute in production.

---

Amazon S3 Object Lock Architecture & WORM Storage

Amazon S3 Object Lock implements immutable WORM storage for objects residing within standard S3 storage classes. It prevents objects from being deleted or overwritten for a fixed retention period or indefinitely via legal holds.

Loading diagram...

Mandatory Architectural Prerequisites

1. S3 Versioning Mandatory: S3 Object Lock operates exclusively on object versions. S3 Versioning is automatically enabled and permanently locked when Object Lock is enabled on a bucket. S3 Versioning cannot be suspended on an Object Lock-enabled bucket.
2. Bucket-Level Activation: Object Lock can be enabled when a bucket is created or, for an existing bucket, with PutObjectLockConfiguration (console, CLI, or API) once Versioning is enabled; no AWS Support request is needed. Objects already in the bucket are not locked automatically, so apply retention to them with S3 Batch Operations if required. Once enabled on a bucket, Object Lock cannot be disabled.
3. Granular Version Locking: When an application writes an object to an Object Lock-enabled bucket, the lock configuration applies to that specific version ID. If a client uploads a new object with the identical key name, S3 does not overwrite the locked version; it simply creates a newer, distinct version ID, keeping the older locked version completely intact.

---

Retention Modes: Governance Mode vs. Compliance Mode

S3 Object Lock provides two distinct retention modes that establish the operational strength of the WORM boundary:

1. Governance Mode

In Governance Mode, object versions are shielded against deletion, overwriting, and retention period truncation by standard IAM users and roles.

• Privileged Override (s3:BypassGovernanceRetention): A user possessing the specific IAM permission s3:BypassGovernanceRetention can override Governance Mode. To delete a locked version or reduce its retention period, the caller must explicitly pass the request header x-amz-bypass-governance-retention: true in their API request.
• Use Case: Protecting critical records against accidental deletion or rogue user actions while preserving administrative flexibility for authorized compliance officers to purge data if business requirements change.

2. Compliance Mode

In Compliance Mode, object versions are protected by an absolute, non-negotiable cryptographic lock.

• Inviolable by Any Principal: Nobody—including the AWS account root user, organization administrators, or AWS Support engineers—can overwrite or delete a locked object version during its retention period.
• Unshortenable Retention Period: The retention period cannot be decreased under any circumstances. It can only be extended to a later date.
• Bucket Deletion Barrier: An S3 bucket containing objects locked under active Compliance Mode cannot be deleted, even by the root user, until all retention periods on all object versions have fully expired.
• Regulatory Adherence: Fully vetted and certified for SEC 17a-4(f), FINRA 4511, and CFTC 1.31 compliance.

Comparison: Governance Mode vs. Compliance Mode

---

S3 Legal Holds: Mechanics & Operational Governance

While retention periods enforce immutability based on deterministic calendar timestamps (e.g., retain for 7 years), legal discovery and regulatory audits frequently demand immediate, open-ended data preservation pending the resolution of litigation or investigations.

• Indefinite Duration: An S3 Legal Hold does not have an expiration timestamp. Once placed on an object version, it remains locked until explicitly removed.
• Binary Status: A Legal Hold is either ON or OFF. It is applied via the PutObjectLegalHold API.
• Decoupled from Retention Periods: Legal Holds operate independently of Governance and Compliance retention modes. An object version can have both a retention period and a Legal Hold simultaneously. If a 3-year Compliance retention period expires but a Legal Hold remains ON, the object remains strictly undeletable.
• IAM Authorization: Placing or removing a legal hold requires the explicit IAM permission s3:PutObjectLegalHold. Organizations typically restrict this action to legal and corporate compliance roles.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictLegalHoldManagementToComplianceOfficer",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/ChiefComplianceOfficer"
      },
      "Action": [
        "s3:PutObjectLegalHold",
        "s3:GetObjectLegalHold"
      ],
      "Resource": "arn:aws:s3:::litigation-hold-records/*"
    }
  ]
}

---

Amazon S3 Glacier Vault Lock Architecture

For long-term archival storage, Amazon S3 Glacier Vault Lock allows security engineers to deploy and lock compliance policies directly on individual S3 Glacier vaults. Vault Lock enforces compliance controls (such as denying deletion of archives before a mandatory 10-year holding period) that cannot be altered or overwritten once locked.

Loading diagram...

The Two-Step Locking Workflow & 24-Hour Window

To prevent administrative lockouts caused by syntax errors or accidental policy misconfigurations, Glacier Vault Lock implements an ironclad two-step workflow:

1. Step 1: InitiateVaultLock:
   • The administrator attaches a proposed Vault Lock policy document to the target vault.
   • Glacier places the policy in an InProgress state and generates a unique LockId.
   • Glacier initiates a mandatory 24-hour testing countdown.
2. Step 2: Testing & Validation:
   • During the 24-hour window, the policy is enforced, allowing the administrator to test compliance rules against test archives.
   • If the policy contains an error, the administrator can call AbortVaultLock using the LockId, which immediately terminates the lock process and purges the in-progress policy.
3. Step 3: CompleteVaultLock:
   • Within 24 hours of initiation, the administrator must call CompleteVaultLock specifying the exact LockId.
   • Once completed, the vault lock transitions to the Locked state.
   • Permanent Immutability: Once in the Locked state, the Vault Lock policy cannot be modified, deleted, or overridden by anyone—including the AWS account root user.
   • Timeout Expiration: If 24 hours elapse without calling CompleteVaultLock, the lock state expires automatically, and the in-progress policy is purged.

Glacier Vault Lock Policy Example

The following policy locks an Amazon S3 Glacier vault to deny the deletion of any archive that has been stored for less than 3,650 days (10 years):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPrematureArchiveDeletion",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "glacier:DeleteArchive",
      "Resource": "arn:aws:glacier:us-east-1:123456789012:vaults/legal-archive-vault",
      "Condition": {
        "NumericLessThan": {
          "glacier:ArchiveAgeInDays": "3650"
        }
      }
    }
  ]
}

---

AWS Signer: Code Signing, Container Integrity & Platform Enforcement

Data integrity extends beyond static storage into the software supply chain. Malicious actors frequently attempt to inject tampered code into continuous integration/continuous deployment (CI/CD) pipelines or deploy backdoored container images. AWS Signer is a fully managed code-signing service that establishes cryptographic authenticity, integrity, and non-repudiation for code artifacts.

Loading diagram...

Key Concepts of AWS Signer

• Signing Profile: A template that defines cryptographic parameters, including the target platform (e.g., AWSLambda-SHA384-ECDSA, Notation-OCI-SHA384-ECDSA), signing key validity period, and signature validity period (default 135 months or custom).
• Signing Job: The automated operation where AWS Signer takes an unsigned payload from Amazon S3 or a container registry, applies a digital signature using the managed private key associated with the signing profile, and writes the signed artifact and signature metadata to the target destination.
• Revocation: If a signing profile's integrity is questioned, administrators can revoke the profile. AWS Signer supports setting an effective revocation date, allowing signatures created before a specific timestamp to remain valid while immediately invalidating signatures generated after the compromise.

AWS Lambda Code Signing Configurations (CSC)

To enforce that only verified code runs in AWS Lambda, security teams attach a Code Signing Configuration (CSC) to the Lambda function. The CSC specifies two critical parameters:

1. Allowed Signing Profiles: A list of up to 20 AWS Signer signing profile ARNs that are authorized to sign code for the function.
2. Signature Validation Policy (Untrusted Artifact Action):
   • Warn: If a deployment package is unsigned, has an invalid signature, or was signed by an unauthorized profile, Lambda logs a warning metric to Amazon CloudWatch and allows the deployment to proceed. (Primarily used for testing/auditing).
   • Enforce: If the deployment package fails signature verification or lacks a valid signature from an allowed profile, Lambda blocks the deployment immediately, returning an InvalidCodeSignatureException.

{
  "CodeSigningConfig": {
    "CodeSigningConfigArn": "arn:aws:lambda:us-east-1:123456789012:code-signing-config:csc-0123456789abcdef0",
    "CodeSigningConfigId": "csc-0123456789abcdef0",
    "AllowedPublishers": {
      "SigningProfileVersionArns": [
        "arn:aws:signer:us-east-1:123456789012:/signing-profiles/ProductionReleaseProfile/v1"
      ]
    },
    "CodeSigningPolicies": {
      "UntrustedArtifactOnDeployment": "Enforce"
    }
  }
}

---

Comparison: S3 Object Lock vs. Glacier Vault Lock vs. AWS Backup Vault Lock

---

Specialty Exam Pitfalls & Architectural Traps

1. Attempting Object Lock on Suspended Versioning: Assuming Object Lock can function on an S3 bucket with versioning suspended or disabled. S3 Object Lock binds cryptographic immutability directly to specific object version IDs. Enabling Object Lock permanently enforces Versioning.
2. The Root User Compliance Override Myth: Believing that the AWS account root user or a support ticket to AWS Support can delete an object locked under S3 Object Lock Compliance Mode or an archive under a locked Glacier Vault Lock. Neither the root user nor AWS engineering possesses a backdoor mechanism to bypass Compliance mode locks.
3. Glacier Vault Lock 24-Hour Expiration: Forgetting to call CompleteVaultLock within 24 hours of calling InitiateVaultLock. If the 24-hour window lapses without completion, the lock state expires, and the proposed compliance policy is discarded completely.
4. Lambda Code Signing Configured with Warn: Assuming that creating a Code Signing Configuration automatically prevents unsigned code from deploying. If the untrusted artifact action is set to Warn, untrusted or tampered code will still deploy and execute in production. High-security environments must explicitly configure Enforce.