Reviewing Multi-Layered Security Solutions in AWS

This guide focuses on the continuous evaluation of implemented security controls across all layers of an AWS architecture, a critical skill for the SAP-C02 exam.

Learning Objectives

• Differentiate between AWS and Customer responsibilities within the Shared Responsibility Model.
• Implement and review a Zero-Trust Security Model versus traditional perimeter-based security.
• Analyze and configure Network ACLs (NACLs) and Security Groups (SGs) for defense-in-depth.
• Evaluate protection against DDoS and application-layer attacks using AWS Shield and Route 53 DNSSEC.
• Ensure data integrity via Encryption in Transit (TLS 1.2/1.3) and Encryption at Rest.

Key Terms & Glossary

• Shared Responsibility Model: A framework where AWS secures the "Cloud" (infrastructure) and customers secure "in the Cloud" (data, OS, and configurations).
• Zero-Trust: A security concept where no system is trusted by default, regardless of its location relative to the network perimeter.
• Stateless: A network filter (like NACLs) that does not remember the state of previous packets; both inbound and outbound traffic must be explicitly allowed.
• Stateful: A network filter (like Security Groups) that tracks the state of connections; allowing inbound traffic automatically allows the outbound response.
• DNSSEC: Domain Name System Security Extensions; adds cryptographic signatures to DNS records to prevent tampering.

The "Big Idea"

In an AWS environment, security is not a single "wall" but a series of interconnected layers. Reviewing implemented solutions requires shifting from a "perimeter-only" mindset to a defense-in-depth strategy where every access request is validated, every data packet is encrypted, and every resource is shielded at the host, network, and application levels.

Formula / Concept Box

Hierarchical Outline

• I. Foundational Principles
  • Shared Responsibility: AWS (Facilities/Hardware) vs. Customer (Resources/Config).
  • Zero-Trust Evolution: Moving away from trusted internal networks to per-request validation.
• II. Network Layer Security
  • Subnet Protection: Using NACLs as a stateless perimeter.
  • Resource Protection: Using Security Groups as virtual stateful firewalls.
  • DNS Integrity: Enabling DNSSEC validation on Route 53 Resolvers.
• III. Infrastructure & Edge Protection
  • AWS Shield Standard: Automatic protection for L3/L4 attacks.
  • AWS Shield Advanced: Managed protection for L3, L4, and L7; specialized support.
• IV. Data Transmission Security
  • Encryption in Transit: Default TLS usage for APIs; transitioning to TLS 1.2/1.3.

Visual Anchors

The Security Onion (Multi-Layer Defense)

Traffic Flow Logic

Definition-Example Pairs

• Stateful Filtering: A mechanism that allows return traffic automatically if the original request was permitted.
  • Example: If an EC2 instance initiates a web request on port 443, the Security Group allows the response back into the instance without a specific inbound rule.
• Stateless Filtering: A mechanism that requires manual configuration for both directions of traffic.
  • Example: To allow web traffic in a subnet via NACL, you must create an Inbound rule for port 443 and an Outbound rule for the ephemeral port range (typically 1024-65535).
• DNSSEC Validation: Validating the digital signature of a DNS response.
  • Example: Preventing a "Man-in-the-Middle" attack where an attacker tries to redirect your VPC resources to a malicious IP by spoofing a DNS response.

Worked Examples

Scenario: Securing a 3-Tier Web App

Problem: A legacy app is being migrated to AWS. It currently trusts all traffic from the "internal" network. How do we apply defense-in-depth?

Step-by-Step Breakdown:

1. Identity Layer: Assign IAM Roles to EC2 instances using the principle of least privilege; remove long-term access keys.
2. Edge Layer: Deploy CloudFront with AWS WAF to block SQL Injection and XSS at Layer 7.
3. Network Layer:
   • Place Web Servers in a public subnet with a NACL allowing only 80/443.
   • Place DB Servers in a private subnet with a NACL allowing only the DB port (e.g., 3306) from the Web subnet.
4. Resource Layer: Apply a Security Group to the DB that references the Web Server's Security Group ID as the source (not an IP range).
5. Data Layer: Force TLS 1.2 for all connections between the Web tier and the DB tier.

Checkpoint Questions

1. What is the primary operational difference between a Security Group and a Network ACL?
2. Which AWS Shield tier is activated by default and protects against SYN floods?
3. If you allow port 80 inbound in a NACL but forget the outbound rule, will the client receive a response? Why?
4. What is the minimum version of TLS required for AWS service API connections as of 2023?

Muddy Points & Cross-Refs

• XKS (External Key Store): A common point of confusion. While it gives you maximum control by keeping keys outside AWS, it introduces high latency and availability risks. Only use it when regulatory requirements strictly forbid cloud-based key management.
• DNSSEC Complexity: Note that while Route 53 Resolver can validate signatures, it doesn't always return the full DNSSEC response to the client. If your application needs the raw signed data, you must use a custom resolver.
• Cross-Ref: For more on automated monitoring of these layers, see AWS Config Rules and Amazon GuardDuty.

Comparison Tables

Security Groups vs. NACLs

AWS Shield Comparison