Todo.io learns AWS
Level 0 quizzesQuizzesLevel 0 examExam

The core four · 4 of 4

Security

Who can do what, and what did they do?

Security isn't a fourth box beside the others: it wraps all of them. It answers who may do what, keeps a record of what they did, and has a piece inside every other pillar.

The services

OrganizationsGroups many AWS accounts under one management account, with one bill and shared guardrails.The building management company that owns every flat.Control TowerSets up and governs a multi-account AWS environment (a landing zone) for you.A developer who builds the whole apartment complex to code, then inspects it regularly.IAM Identity CenterOne place for people to sign in and get access to many AWS accounts.The front desk that hands you a temporary key card for whichever flat you're cleared for.IAMDecides who can do what to which AWS resource.The building's security office that issues every badge.CloudTrailA record of every AWS API call. Who did what, when, from where.The building's CCTV and visitor book.ConfigRecords how your resources are configured over time and checks them against rules.A building inspector with a notebook and a camera.CloudWatch LogsWhere applications and AWS services send their log lines.The building's logbook.

How it fits together

1. Walls: accounts and the organization

An AWS account is the strongest wall AWS has. An organization holds all of them, and Control Tower can build a landing zone and new accounts (Account Factory) for you.

2. Who are you?

The root user is locked away with MFA. People sign in through IAM Identity Center and get a permission set as an IAM role with temporary credentials. Apps get roles too.

3. What may you do?

IAM policies allow actions on resources named by ARN. SCPs and Control Tower controls set limits on whole accounts that no one inside can pass, not even an admin.

4. What happened?

CloudTrail records AWS API calls, AWS Config records how resources are set up and flags rule breaks, and CloudWatch Logs keeps your own app's log lines.

Security inside the other three

Compute

Every server, task and function gets an IAM role: everything its code may do in AWS. No access keys in files.

Networking

A security group on each network card decides what may connect, and private subnets keep the database off the internet.

Storage

RDS: a security group, then a password. DynamoDB: IAM approves every call. S3: buckets start private; IAM and the bucket policy decide who reads.

See it in a request

What you need to know

Every Level 0 fact about this pillar's words. The exam and quizzes only ask about these.

AWS account A container for AWS resources, with its own identities and its own bill.
  • An account is the strongest isolation boundary in AWS: nothing in one account can reach another unless it's explicitly allowed. That's why Prod and Dev get separate accounts, each with its own bill and limits.
Open in the glossary →
Root user The identity you sign in as with the account's email address. It can do almost anything; only an SCP can limit it.
  • Root can do almost anything in its account. IAM policies can't restrict it; only an SCP can, and only in a member account.
  • Turn on MFA, never create root access keys, never share the password, and use root only for the few jobs that need it, like closing the account or changing its email. Day to day, people sign in through IAM Identity Center.
  • You sign in as root with the account's email address. It has no username and can't be renamed.
Open in the glossary →
MFA (multi-factor authentication) A second proof of identity, like a code from an app or a security key, on top of a password.
  • With MFA, a stolen password alone isn't enough to sign in. Turn it on for root first.
  • When staff sign in through IAM Identity Center, MFA is required in one place: Identity Center's sign-in settings, for every user.
Open in the glossary →
AWS Organizations Groups many AWS accounts under one management account, with one bill and shared guardrails.
  • Consolidated billing: the management account pays one bill for every account, and usage is added together for volume pricing.
  • An OU (organizational unit) is a folder of accounts. A policy attached to an OU applies to every account in it, including accounts in OUs nested inside it and accounts moved in later.
  • Keep workloads out of the management account: SCPs never apply to it, so no guardrail can protect what runs there.
  • Every account that Organizations creates gets a role called OrganizationAccountAccessRole, which the management account can assume. That's the first way in, with no new password.
Open in the glossary →
SCP (service control policy) An organization-wide guardrail that sets the most any identity in an account may do.
  • An SCP never grants anything. It sets the most an account may do; an IAM policy (or a resource policy) must still allow the request, or it's implicitly denied.
  • SCPs apply to every user and role in a member account, root included. They never apply to the management account or to service-linked roles.
  • An SCP is a preventive guardrail: a Deny in an SCP blocks the call before it happens, for everyone in the account. Use one when something must never be possible, like stopping CloudTrail or using an unapproved Region. Attached at the organization's root, it covers every member account, including future ones.
Open in the glossary →
IAM Identity Center One place for people to sign in and get access to many AWS accounts.
  • Each person exists once in Identity Center and has one sign-in. The access portal lists the accounts they're assigned to and the permission sets they can use in each.
  • Opening an account from the portal assumes a role, so the person gets temporary credentials that expire on their own. No long-lived keys exist to leak.
  • Identity Center can use a company directory (Okta, Microsoft Entra ID, Active Directory) as its identity source, so people use their usual login.
  • To remove someone's access to every account, disable them once: in Identity Center, or in the directory it's connected to.
  • Identity Center and IAM are for the people and software that manage or call AWS. An app's own customers never become IAM or Identity Center users; Amazon Cognito handles them (Level 2).
  • Identity Center used to be called AWS SSO, so the roles it creates are named AWSReservedSSO_…. Change them through the permission set, never by hand.
Open in the glossary →
Permission set A reusable bundle of permissions that Identity Center turns into a role in each account you assign it to.
  • Assigning a permission set to someone in an account creates an IAM role there with those permissions, which they assume when they open that account.
  • Assignments are per account, so one person can have broad access in Dev and read-only access in Prod: least privilege.
Open in the glossary →
AWS Control Tower Sets up and governs a multi-account AWS environment (a landing zone) for you.
  • Control Tower builds a landing zone, the AWS-recommended multi-account setup, by setting up Organizations, IAM Identity Center, CloudTrail and AWS Config for you. It manages them; it doesn't replace them.
  • If someone changes something Control Tower manages by hand (one of its SCPs, say), Control Tower reports drift so the setup can be repaired.
  • Accounts that existed before Control Tower can be enrolled, which applies the landing zone's logging, guardrails and sign-in to them.
Open in the glossary →
Landing zone A ready-made, well-run multi-account AWS environment that your apps can "land" in.
  • A landing zone keeps every account's logs in a separate Log Archive account where nobody runs apps, so someone who breaks into a workload account can't erase the evidence.
Open in the glossary →
Account Factory Control Tower's way to create new AWS accounts from a standard template.
  • Account Factory creates new accounts from a template, already enrolled: logging on, guardrails applied, sign-in through Identity Center.
Open in the glossary →
Controls (guardrails) Control Tower's rules for every account in an OU. Some block, some report, some check before deploying.
  • Preventive controls are SCPs: they stop something happening. Detective controls are AWS Config rules: they spot it afterwards and report it. Proactive controls are CloudFormation hooks: they check a resource before CloudFormation creates it.
  • Exam wording: "must never be possible" or "block" means preventive; "find out when", "report on" or "be told" means detective.
  • Each control is mandatory (always on), strongly recommended or elective. You turn the optional ones on per OU.
Open in the glossary →
IAM (Identity and Access Management) Decides who can do what to which AWS resource.
  • Everything starts denied. A request is allowed only if some policy explicitly allows it and nothing explicitly denies it, so a new role with no policies can do nothing.
  • IAM is global: users, roles and policies work in every Region.
Open in the glossary →
IAM role An identity with permissions that something can "wear" temporarily. No password.
  • Software gets AWS permissions from a role, never from stored access keys: an instance profile on EC2, a task role on ECS, an execution role on Lambda.
  • A role's trust policy says who may assume it (for example ec2.amazonaws.com); its permissions policy says what it can do once assumed.
Open in the glossary →
IAM policy A JSON document listing allowed (or denied) actions on resources.
  • An explicit Deny anywhere (an IAM policy, a resource policy or an SCP) always beats any number of Allows. Which policy is more specific doesn't matter.
  • An identity-based policy is attached to a user, group or role and says what they may do. A resource-based policy is attached to a resource (a Lambda function, an S3 bucket, an SQS queue) and names who may use it.
  • Least privilege: allow only the actions a job needs, only on the resources (by ARN) it uses. Avoid *.
  • An AccessDenied error means no policy allowed the call, so fix the caller's policy. A network problem looks different: it times out.
Open in the glossary →
ARN (Amazon Resource Name) The unique full name of an AWS resource.
  • Read an ARN left to right: arn:aws:<service>:<Region>:<account ID>:<resource>, for example arn:aws:dynamodb:us-east-1:111122223333:table/Todos.
  • S3 bucket ARNs leave out the Region and the account, because bucket names are already unique across AWS: arn:aws:s3:::todoio-pictures.
Open in the glossary →
Temporary credentials Short-lived AWS keys handed out for a role, which expire automatically.
  • Temporary credentials expire on their own, and the SDK refreshes them; nothing long-lived is stored. On EC2, the SDK fetches them from the instance metadata service at 169.254.169.254.
Open in the glossary →
Service-linked role A role an AWS service creates and owns so it can act in your account on its own behalf.
  • A service-linked role is created and owned by an AWS service and named AWSServiceRoleFor… (RDS has AWSServiceRoleForRDS). You can't edit its permissions, and SCPs don't apply to it.
Open in the glossary →
iam:PassRole The permission to hand an existing role to an AWS service.
  • Giving an existing role to a service (an execution role to Lambda, a monitoring role to RDS) needs iam:PassRole on that role, on top of permission to create the resource.
Open in the glossary →
CloudWatch Logs Where applications and AWS services send their log lines.
  • Logs go into log groups (one per app or function). Each group holds log streams, one per source, such as a container or a Lambda instance.
  • Log groups keep data forever by default. Set a retention period (say 30 days) and older events are deleted for you.
  • You can search and query a log group (Logs Insights), and a metric filter turns matching lines into a number you can set an alarm on.
  • CloudWatch Logs holds what your software printed; CloudTrail holds who did what to AWS.
  • Never log secrets: anyone allowed to read the log group can read them.
Open in the glossary →
CloudTrail A record of every AWS API call. Who did what, when, from where.
  • CloudTrail records AWS API calls: who, what, when and from where. Console, CLI and SDK actions are all API calls, and failed calls are recorded too.
  • Event history keeps 90 days of management events in each Region, with no setup.
  • A trail saves events to S3 for as long as you like. An organization trail, created from the management account, covers every account and Region, and member accounts can't change or stop it.
  • By default only management events (like creating a bucket) are logged. Data events, such as S3 object reads or DynamoDB item reads, have to be turned on.
Open in the glossary →
AWS Config Records how your resources are configured over time and checks them against rules.
  • Config records each resource's configuration, and every change to it, over time.
  • Config rules mark resources compliant or noncompliant and keep the history as audit evidence. Config reports problems; it doesn't block them. Control Tower's detective controls are Config rules.
  • Config tells you what changed and when; CloudTrail tells you who made the call.
  • Config records per Region, so it must be turned on in every Region you use (Control Tower does this). An aggregator collects results from every account and Region into one view.
Open in the glossary →