Security Layer

Hardening the Permission Model

The configuration built so far is functionally correct. This section addresses the gaps between functionally correct and production-ready.

IAM User Hardening

audit-user-01 has console access but no MFA requirement enforced at the policy level. In production, you would add a condition to every policy that denies all actions unless MFA is present. The condition looks like this:

{
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "true"
    }
  }
}

You do not need to implement this now, but you should understand that a policy without this condition grants access even if a password is compromised and the attacker has not passed MFA. This is why MFA enforcement at the policy level is standard practice, not optional hardening.

Restricting the Role’s Trust Policy

The current trust policy allows any EC2 instance in your account to assume EC2DocumentProcessorRole. In a multi-team account, this is too broad. You can restrict assumption to specific instance conditions using condition keys such as aws:RequestedRegion or by tagging the instance and using aws:ResourceTag conditions in the trust policy. For now, understand that the trust policy is itself a security boundary that deserves the same scrutiny as the permission policy.

S3 Bucket Policies as a Defense-in-Depth Layer

IAM policies control what an identity can do. S3 bucket policies control what can be done to a bucket, from either direction. Adding a bucket policy to the source bucket that explicitly denies any s3:DeleteObject call — regardless of the calling identity — provides a backstop that survives even if an IAM policy is misconfigured. This is defense in depth: two independent controls must both fail before data is deleted.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllDeletes",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:DeleteObject",
      "Resource": "arn:aws:s3:::cloudboxio-lab-source-{your-account-id}/*"
    }
  ]
}

Apply this bucket policy to the source bucket. After applying it, attempt to delete a file from the bucket using your admin credentials. You should receive an access denied error even as an administrator, because explicit Deny statements in resource policies override identity-based Allow statements.

Credential Hygiene

audit-user-01 currently has only a console password. Ensure no programmatic access keys are created for this user. Access keys are long-lived credentials that bypass MFA entirely. If this user does not need CLI access, no access keys should exist. In the IAM console, verify the Security Credentials tab for this user shows no active access keys.