aws-ct-landingzone-controls-org
Control Tower landing-zone administration is effectively organization administration.
match
A conjunctive graph pattern. Variables (?x) bind node ids; every clause must hold.
where
node_type(?landing_zone) == LandingZone (ManagementService)
node_class(?org) == AdministrativeBoundary and node_type(?org) ==
Organization
?principal holds EFFECTIVE controltower:CreateLandingZone OR UpdateLandingZone OR ResetLandingZone (or broad controltower:* / EnableControl+ManageOrganizationalUnit at landing-zone scope)
?principal is a management-account principal
emit
| source type | Identity |
|---|---|
| target type | * |
| source | ?principal |
| target | ?org |
| permissions | controltower:UpdateLandingZone controltower:ResetLandingZone controltower:CreateLandingZone |
| conditions | iam_permission |
| state logic | ACTIVE when the principal holds landing-zone lifecycle actions (Create/Update/ResetLandingZone) unconditionally from the mgmt account: re-baselining the landing zone re-deploys roles/SCPs/OUs org-wide, which is org control. CONDITIONAL(iam_permission) when gated. This Controls(Organization) then FEEDS hierarchy-chains.yaml admin-inherits-down-contains to descend to every OU and account under the org — DO NOT hand-enumerate the subtree here. Overlaps can-control.yaml control-boundary-via-iam-admin for the boundary roll-up; dedupe on (Controls, principal, org). |
Narrative
{principal.name} can create/update/reset the Control Tower landing zone (controltower:UpdateLandingZone/ResetLandingZone), re-baselining roles and SCP guardrails across the organization - effective control of {org.name}.
Raw rule rules/derived/aws/controltower.yaml
id: aws-ct-landingzone-controls-org
emits: Controls
description: Control Tower landing-zone administration is effectively organization administration.
match:
- - landing_zone: null
- LocatedIn
- org: null
where:
- node_type(?landing_zone) == LandingZone (ManagementService)
- node_class(?org) == AdministrativeBoundary and node_type(?org) == Organization
- ?principal holds EFFECTIVE controltower:CreateLandingZone OR UpdateLandingZone OR ResetLandingZone (or
broad controltower:* / EnableControl+ManageOrganizationalUnit at landing-zone scope)
- ?principal is a management-account principal
emit:
source_type: Identity
target_type: '*'
source: ?principal
target: ?org
permissions:
- controltower:UpdateLandingZone
- controltower:ResetLandingZone
- controltower:CreateLandingZone
conditions:
- iam_permission
state_logic: "ACTIVE when the principal holds landing-zone lifecycle actions (Create/Update/ResetLandingZone)\
\ unconditionally from the mgmt account: re-baselining the landing zone re-deploys roles/SCPs/OUs\
\ org-wide, which is org control. CONDITIONAL(iam_permission) when gated. This Controls(Organization)\
\ then FEEDS hierarchy-chains.yaml admin-inherits-down-contains to descend to every OU and account\
\ under the org \u2014 DO NOT hand-enumerate the subtree here. Overlaps can-control.yaml control-boundary-via-iam-admin\
\ for the boundary roll-up; dedupe on (Controls, principal, org)."
confidence: min(contributing_confidences) * 0.95
derived_from:
- <LocatedIn edge (LandingZone -> Organization)>
- <effective controltower landing-zone actions>
false_positive_note: "Reserve for genuine landing-zone lifecycle / org-wide control actions. Single-control\
\ or single-account CT actions (EnableControl on one OU) are NOT org control \u2014 those are boundary-scoped\
\ and inherit via hierarchy-chains, not this rule. controltower:GetLandingZone / read actions confer\
\ nothing. Only management-account principals hold these effectively. Cite, do not duplicate, the\
\ org SCP/CanEnterOrganization modeling in identity-escalation.yaml."
narrative: "{principal.name} can create/update/reset the Control Tower landing zone (controltower:UpdateLandingZone/ResetLandingZone),\
\ re-baselining roles and SCP guardrails across the organization \u2014 effective control of {org.name}."