SAA-C03 Study Guide: Secure Application Access

This guide covers the essential strategies and services required to secure applications and workloads within the AWS environment, specifically focusing on identity management, network boundaries, and application-layer protection.

Learning Objectives

By the end of this module, you will be able to:

• Design secure access models using IAM roles, policies, and federation.
• Differentiate between Security Groups and Network Access Control Lists (NACLs).
• Implement application-layer protection using AWS WAF and AWS Shield.
• Architect multi-tier VPC structures to isolate sensitive data and workloads.
• Manage application credentials and encryption keys securely using AWS Secrets Manager and KMS.

Key Terms & Glossary

• IAM Role: An identity that you can create in your account that has specific permissions but is not associated with a specific person or service; instead, it is intended to be assumed by anyone who needs it.
• AWS STS (Security Token Service): A web service that enables you to request temporary, limited-privilege credentials for users.
• Stateful: A system that remembers the state of a connection (e.g., Security Groups allow return traffic automatically).
• Stateless: A system that does not remember connection states; every packet must be explicitly allowed in both directions (e.g., NACLs).
• SQL Injection: A type of vulnerability where an attacker interferes with the queries that an application makes to its database.

The "Big Idea"

[!IMPORTANT] Defense in Depth is the core philosophy. Security in AWS is not a single "wall" but a series of layers. If an attacker bypasses the network perimeter (Shield/WAF), they are met by VPC boundaries (NACLs), then instance-level firewalls (Security Groups), and finally resource-level permissions (IAM/Resource Policies).

Formula / Concept Box

Hierarchical Outline

1. Identity and Access Management (IAM)
   • Principal of Least Privilege: Grant only the permissions required for the task.
   • Roles over Access Keys: Use IAM Roles for EC2 instances to avoid hard-coded credentials.
   • Federation: Integrating external directories (e.g., Active Directory) using SAML 2.0 or OIDC.
2. Network Security
   • Public vs. Private Subnets: Databases and application logic should reside in private subnets.
   • NAT Gateways: Allow private instances to access the internet for updates without being reachable from the internet.
3. Threat Protection
   • AWS WAF: Blocks SQLi, XSS, and rate-limits IP addresses.
   • AWS Shield Standard: Automated protection for common infrastructure attacks (SYN floods).
   • AWS Shield Advanced: 24/7 access to DDoS response team and cost protection.

Visual Anchors

Application Request Flow

Two-Tier VPC Architecture

\begin{tikzpicture}[node distance=2cm] \draw[thick, dashed] (0,0) rectangle (8,6) node[pos=0.9, above] {VPC}; \draw[blue, thick] (0.5,3.5) rectangle (7.5,5.5) node[midway, above=0.8cm] {Public Subnet}; \draw[red, thick] (0.5,0.5) rectangle (7.5,2.5) node[midway, above=0.8cm] {Private Subnet}; \node[draw, fill=blue!10] (ALB) at (4,4.5) {ALB}; \node[draw, fill=red!10] (APP) at (2.5,1.5) {App Server}; \node[draw, fill=red!10] (DB) at (5.5,1.5) {Database}; \draw[->, thick] (4,6.5) -- (ALB); \draw[->, thick] (ALB) -- (APP); \draw[->, thick] (APP) -- (DB); \end{tikzpicture}

Definition-Example Pairs

• Resource-Based Policy: A policy attached to a specific resource (like an S3 bucket or SQS queue) rather than an IAM identity.
  • Example: An S3 bucket policy that allows an external AWS account to upload files directly to your bucket.
• Security Group Chaining: Using the security group ID of a source resource as the "Source" in an inbound rule for a destination resource.
  • Example: Allowing traffic to a Database Security Group ONLY if it originates from the Web Server Security Group, rather than using IP addresses.
• AWS Secrets Manager: A service to manage, retrieve, and rotate database credentials, API keys, and other secrets.
  • Example: Automatically rotating a MySQL database password every 30 days without updating the application code.

Worked Examples

Scenario 1: Securing a Third-Party Auditor

Problem: A third-party firm needs to audit your S3 buckets. You do not want to create IAM users for them. Solution:

1. Create an IAM Role in your account.
2. Define a Trust Policy that allows the third party's AWS Account ID to assume the role.
3. Require an External ID (secret identifier) in the trust policy for added security.
4. Attach a Permissions Policy to the role granting s3:Get* and s3:List* access.

Scenario 2: Protecting against SQL Injection

Problem: Your web application is being targeted by attackers attempting to inject malicious SQL commands through search forms. Solution:

1. Deploy AWS WAF.
2. Associate the WAF WebACL with your Application Load Balancer (ALB).
3. Enable the AWS Managed Rules for SQL database protection (SQLi).

Checkpoint Questions

1. Which service is best for protecting against Layer 3 and 4 DDoS attacks automatically for all AWS customers?
2. Is a Security Group stateful or stateless?
3. What is the main advantage of using an IAM Role for an EC2 instance instead of IAM User access keys?
4. Which service would you use to discover and protect sensitive data (like PII) in S3 buckets?

▶Click to see answers

1. AWS Shield Standard.
2. Stateful (Return traffic is automatically allowed).
3. Automatic rotation of temporary credentials and elimination of hard-coded secrets.
4. AWS Macie.