SimAWSby ShahriarLabs
Search

Defence in depth · Chapter 1 of 1

How security layers defend in depth

Layering network, identity, and cryptographic controls ensures that a single misconfiguration does not lead to a catastrophic security breach.

23 min3 sectionsBack to Defence in depth

FoundationsBuilds the idea from nothing. No prior AWS assumed.

The principle of defence in depth

Why should you never rely on a single security control to protect your data?

AttackerSecurity GroupNetworkIAM PolicyIdentityKMS KeyEncryptionS3 BucketPrivate DataDefence-in-depth security ensures that if a single layer like a Security Group is misconfigured, subsequent layers like IAM or Encryption block unauthorized access.

Defence-in-depth architectures deploy multiple independent security barriers between untrusted actors and sensitive data.

1/5
  1. 01

    A single line of defence fails

    In cloud security, mistakes are inevitable. A developer might accidentally commit an IAM access key to a public repository, or configure a security group to allow port 22 open to the world. If that single control is your only defence, your account is compromised.

  2. 02

    Layering controls reduces risk

    Defence in depth means configuring multiple independent security layers: identity, network, encryption, and logging. For an attacker to steal data, they must bypass every single layer. A network leak is harmless if the data is encrypted; a leaked key is useless if blocked by a network boundary.

  3. 03

    The role of detection

    Preventive controls block attacks, while detective controls alert you when security layers are breached. Real-time logging and threat detection ensure that if an attacker does compromise a credential, you can identify and isolate the breach before data exfiltration occurs.

Check yourself

Which of the following describes the core principle of defence in depth?

Under the hoodThe same thing from underneath: limits, failure modes, numbers.

Enforcing organisational policies

How do AWS organisational, boundary, and logging policies restrict access?

AttackerSecurity GroupNetworkIAM PolicyIdentityKMS KeyEncryptionS3 BucketPrivate DataDefence-in-depth security ensures that if a single layer like a Security Group is misconfigured, subsequent layers like IAM or Encryption block unauthorized access.

Defence-in-depth architectures deploy multiple independent security barriers between untrusted actors and sensitive data.

1/5
  1. 01

    SCPs set the absolute ceiling

    Service Control Policies (SCPs) are managed at the AWS Organizations level and apply to all accounts in an Organizational Unit. An SCP cannot grant permissions; it can only filter them. Even an administrator in a child account cannot bypass a restriction set by an SCP.

  2. 02

    Permissions boundaries prevent escalation

    A permissions boundary is an IAM policy attached to a user or role that defines the maximum permissions they can possess. Developers can create new IAM roles for their applications, but they must attach the permissions boundary, preventing them from granting themselves administrator rights.

  3. 03

    Envelope encryption protects data

    AWS Key Management Service (KMS) uses envelope encryption. Data is encrypted using a unique data key, and that data key is encrypted using a root KMS key. To read data, an application must have permissions to both the storage resource (like S3) and the KMS key.

  4. 04

    CloudTrail and GuardDuty detect breaches

    AWS CloudTrail records every API call made in your account. Amazon GuardDuty continuously analyzes CloudTrail logs, VPC flow logs, and DNS query logs using machine learning to detect suspicious activities, such as credential theft or port scanning.

The numbers

SCP maximum size
5,120 bytesForces policies to be concise and focused on high-level guardrails.
CloudTrail log delivery delay
15 minutesThe latency between an API call execution and its appearance in your CloudTrail S3 bucket.
GuardDuty threat detection time
Within 5 minutesProcesses logs near real-time to alert you of active compromises.
KMS key rotation frequency
Once per yearAWS managed keys rotate automatically every year, preventing long-term key compromise.

Check yourself

A developer in a member account has AdministratorAccess. An SCP on the parent OU denies the action kms:Decrypt. Can the developer decrypt KMS keys?

In practiceThe judgement call you actually have to make.

Implementing least privilege in practice

How do you design secure IAM roles without breaking engineering velocity?

  1. 01

    Avoid writing policies from scratch on day one

    Attempting to enforce perfect least privilege during active development leads to constant permission errors and frustrated developers. Instead, start with broad read-only access and narrow write permissions, then use IAM Access Analyzer to refine policies based on actual logs.

  2. 02

    Decouple database access from credentials

    Do not rely on database passwords stored in application configuration files. Use IAM database authentication for RDS or store passwords in AWS Secrets Manager with automatic rotation. Ensure the application role is the only entity allowed to read the secret.

  3. 03

    Restrict administrative access to roles

    No human user should possess permanent administrative permissions. Human users should log in with read-only rights and assume a temporary administrative IAM role only when performing active maintenance. This ensures all administrative actions are logged to a specific name.

Check yourself

Why should database credentials be stored in AWS Secrets Manager rather than environment variables?

Official references & further reading

These lessons simplify selected behaviors for learning. Verify current service limits, Region support and production requirements with the official references. Experiments describe their own assumptions.

Report an error or suggest a clearer explanation →