Lab 03 — Organizations guardrails¶

✅ Done 🧭 Management and Security Governance 💲 $0

Services: Organizations (SCPs, RCPs, delegated admin), S3, IAM Access Analyzer

In one sentence

See SCPs and RCPs deny real requests, learn which side of the request each one restricts (my principals vs my resources), and use a delegated administrator to run org-wide Access Analyzer without touching the management account.

The idea¶

                 SCP                                     RCP
  limits ──► PRINCIPALS in member accounts      limits ──► RESOURCES in member accounts
             (what my people can do)                       (who can touch my stuff)
                                                applies to callers from ANY account,
                                                  including other orgs and the mgmt account
  Effect:   Allow (allow-list) or Deny          Effect:   Deny only (+ RCPFullAWSAccess)

  Never applies to: the management account, service-linked roles
  Never GRANTS anything. It only sets the maximum.

What happened in the lab run¶

Every result matched the expectations. A member account sec3-member (222222222222) was created in OU sec3-sandbox and kept for later labs (org trail, GuardDuty and Security Hub delegated admin).

Part B — SCPs¶

SCP	Caller	Action	Result
`sec3-region-deny` on root	member	SNS in us-east-2	✅
	member	SNS in us-west-2	❌ "explicit deny in a service control policy"
	management account	SNS in us-west-2	✅ still works — SCPs never apply to the management account
`sec3-protect-baseline` on OU	member admin role	`iam:TagRole` on `OrganizationAccountAccessRole`	❌ explicit deny — the admin role can't change itself
`sec3-allow-list` replaces `FullAWSAccess` on OU	member	`sns list-topics` (allowed)	✅
	member	`logs describe-log-groups` (not listed)	❌ "no service control policy allows" — implicit deny
	member	`sts get-caller-identity`	✅ always — needs no permission

Part C — RCPs (member bucket shared with the management account)¶

RCP on OU	Caller	Request	Result
none	management account	HTTPS and plain HTTP	✅ both
`sec3-rcp-tls`	management account	HTTPS	✅
	management account	plain HTTP	❌ AccessDenied — an RCP restricts the resource, whoever the caller is
`sec3-rcp-perimeter` (org-only)	management account	HTTPS	✅ — it's inside `o-exampleorg1`

Part D — delegated admin + zone of trust¶

Analyzer (in the member, as delegated admin)	Findings
`ACCOUNT`	⚠️ `sec3-data-*` bucket (shared with 111111111111) and `OrganizationAccountAccessRole` (trusts the management account)
`ORGANIZATION`	✅ none — the management account is inside the zone of trust

Key lessons¶

SCPs and RCPs never restrict the management account — not its principals (SCP) and not its resources (RCP), even when attached to the root. Keep workloads out of it. They also never affect service-linked roles.
SCP = my principals; RCP = my resources. Only an RCP can stop an outside caller (another org, or even your own management account) from reaching a member account's resource.
Explicit vs implicit: "explicit deny in a service control policy" = a Deny matched; "no service control policy allows" = some level on the path (root, OU or account) has no Allow.
Allow-lists intersect down the tree: an action must be allowed at every level. FullAWSAccess on the account doesn't help if the OU doesn't allow it.
Delegated admin lets the security account run org-wide services; the analyzer's zone of trust is its type, not your intent.

Exam notes¶

SCPs need the org in all features mode; consolidated billing only = no SCPs.
Enabling a policy type attaches FullAWSAccess / RCPFullAWSAccess everywhere; nothing changes until you attach your own. A target must always keep at least one SCP (attach the new one before detaching).
SCPs apply to every principal in a member account, including its admin role and root user (a few root-only tasks are exempt).
CreateAccount creates OrganizationAccountAccessRole (AdministratorAccess, trusts the management account). Invited accounts don't get it — create it yourself. A created account has no root password ("Forgot password" on the root email).
Region-deny SCPs use NotAction with the global services (IAM, STS, Organizations, Route 53, CloudFront, Support…), because their endpoints are in us-east-1.
RCP syntax: Effect must be Deny, Principal must be "*", no NotAction (NotResource is ok). RCPFullAWSAccess can't be detached → RCPs are always deny-lists. Only supported services (S3, STS, KMS, SQS, Secrets Manager, ECR, OpenSearch Serverless, …) are affected.
Data perimeter RCP: deny if aws:PrincipalOrgID ≠ your org, using …IfExists and aws:PrincipalIsAWSService so AWS services (CloudTrail, Config, ALB logs) can still write to your buckets.
An ORGANIZATION analyzer only flags access from outside the org — it can't catch "shared with the wrong account inside the org".
Closing an account: SUSPENDED for 90 days and still counts toward the account quota.

Review questions¶

Question 1

An SCP attached to the root denies s3:DeleteBucket. An admin in the management account deletes a bucket. What happens, and why?

Show answer

The delete succeeds. SCPs never apply to principals in the management account, even when attached to the root — they only limit member accounts. Protect the management account with tight IAM, MFA and by keeping workloads (and day-to-day users) out of it.

Question 2

You replace FullAWSAccess on an OU with an SCP that allows only ec2:*. A user in an account under that OU has AdministratorAccess. Can they call s3:ListBucket? What does the error say?

Show answer

No. The SCP sets the maximum, and at the OU level only ec2:* is allowed, so S3 is implicitly denied regardless of AdministratorAccess (effective permissions = identity ∩ SCP at every level). The error says "… because no service control policy allows the s3:ListBucket action" — an implicit deny, not "explicit deny".

Question 3

A partner account outside your org is named in a member account's bucket policy. Which policy type stops it centrally, and why can't an SCP do it?

Show answer

A resource control policy (RCP) — e.g. the data-perimeter RCP denying S3 access when aws:PrincipalOrgID isn't your org. SCPs only restrict principals in your own member accounts; the partner's principals live in another org, so your SCPs never evaluate for them. An RCP is evaluated on the resource side, whoever the caller is, so it overrides the bad bucket policy.

Question 4

You write an RCP with "Effect": "Allow" and "Principal": {"AWS": "arn:aws:iam::111122223333:root"}. Name two reasons it's rejected.

Show answer

(1) Custom RCPs support Effect: Deny only — allowing is done by the AWS-managed RCPFullAWSAccess, which can't be detached. (2) The Principal must be "*" — you narrow who is affected with conditions (aws:PrincipalOrgID, aws:PrincipalAccount, …), not by naming principals.

Question 5

Your region-deny SCP uses Action: "*" with StringNotEquals aws:RequestedRegion. Users in us-east-2 suddenly can't use IAM. Why, and what's the fix?

Show answer

IAM (like STS global endpoint, Organizations, Route 53, CloudFront, Support) is a global service whose requests are made to us-east-1, so aws:RequestedRegion is us-east-1 and the Deny matches. Fix: use NotAction to exempt the global services from the region deny (or add us-east-1 to the allowed regions, which is weaker).

Question 6

The security team wants org-wide Access Analyzer findings without logging in to the management account. What two Organizations calls set this up, and which analyzer type do they create?

Show answer

From the management account: EnableAWSServiceAccess (trusted access for access-analyzer.amazonaws.com) and RegisterDelegatedAdministrator for the security account. The security account then creates an ORGANIZATION analyzer, whose zone of trust is the whole org.

Remember

The management-account exemption: SCPs don't restrict its principals and RCPs don't restrict its resources — but an RCP on a member's resource does stop a caller from the management account.