AWS Security from First Principles: Identity, Encryption, and Governance (Part 2)

In Part 1, we covered the network layer: Security Groups, NACLs, WAF, load balancers, and VPC endpoints. That's how you control where traffic can go.

This post covers the other half: who can do what, how data is protected, and how you detect when something goes wrong.

Authentication vs Authorization

Two different questions:

Authentication (AuthN) asks "who are you?" This is handled by IAM users, IAM roles, Cognito, and IAM Identity Center (SSO).

Authorization (AuthZ) asks "what can you do?" This is handled by IAM policies, resource policies, SCPs, and permission boundaries.

You can be authenticated (AWS knows who you are) but not authorized (you don't have permission to do what you're trying to do). Every API call goes through both checks.

IAM Policy Evaluation

When you make an AWS API call, IAM evaluates multiple layers of policies in a specific order. Understanding this order is the key to debugging "access denied" errors:

1. Explicit Deny -- always wins, no matter what. If any policy says Deny, it's denied.
2. SCP boundary -- if the account is in an AWS Organization, SCPs set the maximum permissions.
3. Permission boundary -- if one is attached to the user or role, it caps what identity policies can grant.
4. Identity-based policies -- the policies attached to the IAM user or role.
5. Resource-based policies -- policies on the resource itself (S3 bucket policy, KMS key policy, etc.).
6. If nothing explicitly allows the action, it's an implicit deny.

The mental model: think of it as a series of gates. The request must pass through every gate. An explicit Deny at any gate stops it immediately. An Allow only matters if no gate before it said Deny.

SCPs (Service Control Policies)

SCPs are guardrails at the AWS Organization level. They don't grant permissions. They restrict what's possible, even for administrators.

Use cases: prevent anyone from disabling CloudTrail, restrict which AWS regions can be used, prevent accounts from leaving the organization, block root user actions, force everyone to use SSO instead of IAM users.

For example, to deny all actions outside approved regions:

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["us-east-1", "eu-west-1"]
    }
  }
}

One important detail: SCPs never affect the management account. If you want to restrict the management account, you need to do it through IAM policies directly. This is why best practice is to not run workloads in the management account.

If you want to go deeper on SCPs and how they compare to the newer Resource Control Policies (RCPs), I covered that in my post on SCPs vs RCPs.

Encryption

Encryption has two sides: at rest and in transit.

Encryption at rest protects data sitting on disk. If someone physically stole a hard drive, they'd see gibberish. On AWS:

• S3 supports SSE-S3 (AWS manages the key), SSE-KMS (you control the key via KMS), and SSE-C (you provide the key with each request)
• EBS volumes can be encrypted via KMS
• RDS encryption must be enabled at creation time (you can't enable it later on an existing database)
• DynamoDB is encrypted by default

Encryption in transit protects data moving across the network. Use TLS everywhere: ALB, API Gateway, S3 endpoints. Use VPC endpoints (Gateway for S3/DynamoDB, Interface for everything else) to keep traffic off the public internet. Enforce the aws:SecureTransport condition in S3 bucket policies to reject any non-HTTPS requests.

KMS Key Hierarchy

AWS KMS (Key Management Service) manages your encryption keys. There are two types:

AWS managed keys are free and AWS controls the rotation. You don't manage the key policy. These are the default when you enable encryption on most services.

Customer managed keys give you full control. You set the key policy, control rotation, and can disable or delete the key. Use these when you need to control who can encrypt and decrypt, or when compliance requires it.

KMS key policies and IAM policies work together. The key policy is the primary control (it must explicitly allow access), and IAM policies provide additional permissions on top of that. This two-layer model means even an IAM admin can't use a KMS key unless the key policy allows it.

Security Services

AWS has a set of security services that work together. Each one does something different:

CloudTrail logs every API call in your account. Who did what, when, from where. Enable it in all regions, send logs to a central S3 bucket with object lock so they can't be tampered with. This is your audit trail.

GuardDuty is threat detection. It analyzes CloudTrail logs, VPC Flow Logs, and DNS logs to find suspicious activity: unusual API calls, crypto mining, compromised credentials, communication with known malicious IPs. Low effort to enable, high value.

Config tracks resource configuration changes over time. It answers "what changed and when?" Use Config Rules to automatically check if resources comply with your policies (like "all S3 buckets must have encryption enabled").

Security Hub aggregates findings from GuardDuty, Inspector, Macie, and Config into one dashboard. It also checks your configuration against compliance frameworks like CIS benchmarks and NIST 800-53.

VPC Flow Logs capture IP traffic metadata at the VPC, subnet, or ENI level. Essential for troubleshooting connectivity issues and auditing network traffic patterns.

IAM Access Analyzer finds resources that are shared externally. It scans your S3 buckets, IAM roles, KMS keys, Lambda functions, and SQS queues to identify anything accessible from outside your account or organization.

Inspector scans EC2 instances and ECR container images for software vulnerabilities and network exposure.

Macie discovers and protects sensitive data (PII) in S3 buckets. It uses machine learning to find things like credit card numbers, social security numbers, and API keys sitting in your data lake.

Putting It All Together

Here's the full defense-in-depth model, combining both parts:

Internet
  |
  v
CloudFront + WAF          -- L7 filtering, geo-block, rate limit
  |
  v
ALB + SG + ACM cert       -- TLS termination, L3/4 filtering
  |
  v
Subnet + NACL             -- Coarse L3/4 deny rules
  |
  v
Instance + SG             -- Fine-grained L3/4 allow rules
  |
  v
Data at rest              -- KMS encryption

Across everything: IAM + SCPs + CloudTrail + GuardDuty

Each layer adds defense that the others don't cover. Network security (Part 1) controls where traffic can go. Identity and encryption (this post) controls who can do what and protects the data itself. Security services detect when something goes wrong.

No single layer is sufficient alone. That's the whole point of defense in depth.

Quick Decision Guide

← Back to all posts