Design Secure Access To AWS Resources

Source: Dev.to

Exam Guide: Solutions Architect – Associate

🛡️ Domain 1 – Design Secure Architectures

📘 Task Statement 1.1

Secure access means you can clearly answer the following questions:

1. Who is trying to access AWS?
2. What are they allowed to do?
3. Where are they allowed to do it (which account / which resources)?
4. How are they proving it’s really them (password, MFA, federation)?
5. How long should that access last (temporary vs. long‑term)?

This task is mostly about identity + permissions + multi‑account setup.

Knowledge

1️⃣ Access Controls and Management Across Multiple Accounts

As a company grows, a single AWS account becomes messy:

A multi‑account strategy helps you:

• Isolate workloads (dev / prod)
• Apply security rules consistently
• Reduce risk

Common Patterns

Note: SCPs do not grant permissions. They only set the maximum allowed actions in an account/OU. You still need IAM permissions to allow anything.

2️⃣ AWS Federated Access and Identity Services

IAM & IAM Identity Center

Instead of creating an AWS username for every employee, many organizations use federation so people sign in with their existing corporate login.

Simple Comparison

Recommendation: Prefer roles + federation for humans, and avoid creating lots of IAM users with long‑term credentials.

3️⃣ AWS Global Infrastructure

Regions & Availability Zones

• Some services are global (e.g., IAM, Route 53) – identity or permissions concepts apply broadly.
• Many resources are regional – they live in a specific Region.

Your access rules may include where actions are allowed, for example:

• “Only allow deployments in eu‑west-1”
• “Deny creating resources outside approved Regions”

4️⃣ AWS Security Best Practices

Principle of Least Privilege

Least privilege means:

1. Don’t give “admin” unless truly needed.
2. Grant only the actions required for the job.
3. Limit access to specific resources – avoid Resource: "*" whenever possible.

Examples

If you see broad permissions like Action: "*", the “best answer” is usually narrower permissions + conditions.

5️⃣ The AWS Shared Responsibility Model

Security is shared:
AWS secures the cloud; you secure what you put in the cloud.

Skills

A – Apply Best Practices to IAM Users and Root Users

Multifactor Authentication (MFA)

• The root user is the account’s master key.
• Enable MFA on the root user and never use root for daily tasks.
• Use roles or controlled identities for admin work.

Scenario tip: If a question says “root user used daily,” the fix is almost always: enable MFA and stop daily root usage.

B – Design a Flexible Authorization Model (Users, Groups, Roles, Policies)

• Humans → sign in via Identity Center / federation → assume roles.
• Applications / services → use roles (no long‑term access keys in code).

C – Role‑Based Access Control (RBAC) Strategy

• Access is granted by assuming a role, not by permanent admin rights.

AWS STS (Security Token Service)

• Issues temporary credentials → reduces long‑term secret exposure.
• Enables clean cross‑account access.

Cross‑Account Access

• Users in Account A assume a role in Account B.
• No shared passwords, no copying access keys between accounts.

D – Multi‑Account Security Strategy

Control Tower & Service Control Policies

• Use a structured account layout (e.g., prod / dev / security).
• Apply org‑wide guardrails with SCPs to keep shared security functions isolated.

SCP Mindset

Effective permissions = Allowed by IAM AND not blocked by SCP.

E – Determine Appropriate Use of Resource Policies

Some AWS services support resource‑based policies (e.g., S3 bucket policies, SNS topic policies, SQS queue policies). Use them when you need to:

• Grant cross‑account access directly on the resource.
• Allow services to act on your behalf (e.g., Lambda invoking an S3 bucket).
• Apply conditions that are easier to express on the resource than in an IAM policy.

Summary

• Identify who, what, where, how, and for how long access is needed.
• Leverage multi‑account designs, AWS Organizations, and Control Tower for isolation and governance.
• Prefer federation + roles over long‑term IAM users.
• Apply least‑privilege principles, MFA, and SCPs to enforce guardrails.
• Use resource policies where they simplify cross‑account or service‑to‑service permissions.

Keep these concepts handy for the Design Secure Architectures domain of the Solutions Architect – Associate exam.

Resource‑Based Policies

Definition: Policies that are attached directly to the resource.

Common examples

• S3 buckets
• SQS queues
• SNS topics
• KMS keys
• Lambda functions

Typical uses

• Cross‑account access to a bucket, queue, or topic
• Service‑to‑service permissions
• Enforcing conditions (e.g., “HTTPS only”)

Decision Table

When to Federate a Directory Service With IAM Roles

Federation is ideal when:

• Users already have corporate identities (Google Workspace, Okta, Azure AD, AD, etc.)
• You want easy onboarding and off‑boarding
• You want fewer long‑term IAM users

Cheat Sheet

Recap Checklist ✅

If you can explain these ideas in simple terms, you are well‑prepared for Task Statement 1.1:

1. The root user is protected with MFA and not used for daily work
2. IAM roles are preferred over long‑term IAM users
3. Least privilege is applied: only needed actions, only needed resources
4. Multiple AWS accounts are managed centrally
5. Cross‑account access uses role assumption: temporary credentials
6. Workforce access uses federation or IAM Identity Center
7. You understand when to use identity‑based vs. resource‑based policies

AWS Whitepapers and Official Documentation

These are the primary AWS documents behind Task Statement 1.1.
You don’t need to memorize them; use them to understand why AWS security works the way it does.

Core Whitepapers

• AWS Well‑Architected Framework – Security Pillar – Principles behind secure access design (least privilege, identity management, governance).
• IAM Best Practices – Users, roles, groups, policies; why roles & temporary credentials are preferred.
• AWS Shared Responsibility Model – What AWS secures vs. what you must secure.

Identity and Federation References

• IAM User Guide – Deep dive on policies, roles, permission evaluation, policy conflicts.
• IAM Identity Center (AWS SSO) Documentation – Workforce access at scale.
• AWS Security Token Service (STS) Documentation – Temporary credentials & role assumption (key for cross‑account access).

Multi‑Account and Governance References

• AWS Organizations User Guide – Organizational units (OUs) and account structure (critical for SCP behavior).
• Service Control Policies (SCPs) Documentation – How SCPs restrict permissions (important for “even admins must not be able to…” scenarios).
• AWS Control Tower Overview – Visualizing a standard, secure multi‑account setup (often implied for large organizations or governance questions).