Cloud security architecture: accepting landing-zone accounts safely

Cloud security architecture becomes an operational acceptance decision when a platform team must decide whether a new AWS account, Azure subscription, or Google Cloud project is safe to release to a product team. A diagram can show the right folders, organizational units, policies, and logging services while leaving the decisive questions unanswered: which controls are effective at this child resource, which identities sit outside them, what happens to resources that already exist, who may approve an exception, and how is a harmful control-plane change reversed?

Fictional scenario — Northstar Retail. The company is onboarding a payments workload into a multi-cloud landing zone. The platform team says every child inherits the corporate baseline. The payments owner sees one Azure exemption, an AWS workload that needs a service-linked role, and a Google project migrated from an older folder. Procurement must accept or reject the environment before production data arrives. “The policy is assigned” is not an acceptance criterion; Northstar needs evidence of the resulting state and a named owner for every gap.

Define the acceptance decision before choosing controls

A landing zone is a governed foundation for cloud accounts, subscriptions, and projects. It supplies hierarchy, identity entry points, network patterns, logging destinations, policy deployment, ownership, and lifecycle rules. Its security architecture should therefore be expressed as decisions and invariants, not as a catalogue of provider features.

Start with a short acceptance statement for each workload class. For example: production onboarding is accepted only when the child is under the intended parent, effective restrictions match the approved baseline, required telemetry reaches the central destination, local administrators cannot remove protected controls, exceptions have an owner and expiry, and a harmless canary proves the expected allow and deny paths. Record what is intentionally outside that claim, such as a provider-managed identity that the chosen organization policy does not constrain.

A long control list can conceal a missing administrative boundary, while a “green” compliance view can mix prevention, detection, and unfinished remediation. The acceptance decision forces the team to explain each state.

Build an effective-policy acceptance matrix

Analyze the workload, its complete ancestor path, and relevant identity layers. Direct assignments miss inheritance; the organization baseline misses child overrides and exclusions. Resolve each row for a representative production child and every materially different onboarding pattern.

Guardrails set ceilings or configuration restrictions; they do not automatically grant a workload the permissions it needs. Runtime IAM, resource policies, network access, encryption settings, service configuration, and application authorization remain separate layers. The matrix should name which layer proves each claim.

AWS: trace the full SCP path and state the exclusions

In AWS Organizations, a service control policy limits the maximum permissions available to IAM users and roles in member accounts. It does not grant permissions. For an allow-list design, the relevant action must remain allowed through the root, every organizational unit in the path, and the account; an explicit deny anywhere on that path prevails. The account still needs an identity or resource policy that grants the action.

Acceptance evidence should therefore include the account’s organization path, every applicable SCP identifier, controlled content revision or digest, attachment state, and a small test set. One canary should attempt an action expected to succeed with a deliberately narrow IAM grant. Another should attempt a harmless action that a guardrail denies. Capture the actor, account, API, result, policy-specific denial reason, and control-plane event. A denial alone proves little: missing IAM permission or an invalid request can produce the same surface result. Use the positive control and attribution evidence to show that the intended SCP made the decision.

The assurance statement must preserve AWS boundaries. SCPs do not restrict management-account identities or service-linked roles, and do not directly constrain an external principal reaching a member-account resource through a resource-based policy. Keep workloads out of the management account and evaluate the other paths through the controls that govern them.

AWS recommends testing SCP effects in a test organizational unit and moving accounts in controlled groups. Rollback must protect the allow chain: an incorrect replacement can block actions below it. Record prior attachments and content, the canary account, and an operator who remains able to restore them.

Azure: separate evaluation, enforcement, and remediation

Azure Policy uses effects with different operational meanings. A deny assignment can block a matching create or update request, while an existing matching resource is reported as non-compliant. Audit records a compliance result without preventing the request. Modify can alter supported fields during create or update, but an evaluation cycle does not silently rewrite an old resource. DeployIfNotExists and modify can bring existing resources toward compliance through explicit remediation tasks.

This difference changes acceptance. A subscription with a deny initiative assigned at a management group may be protected against a future prohibited deployment while still containing an older prohibited configuration. Request the assignment scope, parameters, exclusions, enforcement mode, compliance snapshot, and a resource inventory reconciled to it. For modify and DeployIfNotExists, also request remediation-task status and the exact failed resources. “Non-compliant” is evidence of detection, not proof of correction.

Remediation has its own privilege boundary. The policy assignment’s managed identity performs deployments or modifications and needs the roles named by the definition. Those permissions should be reviewed as control-plane authority: scope them narrowly, identify who may change the definition or assignment, and verify that a rollback will not leave the identity with unnecessary access. A broad remediation role can undermine a carefully constrained workload administration model.

Azure policy exemptions should record the assignment, affected definitions, category, scope, requester, approver, ticket, expiry, and compensating measure. Safe deployment uses staged assignments, observation before enforcement, automated checks, health gates, and gradual expansion. Ask for that change path, not just the final JSON.

Google Cloud: calculate inheritance by constraint type

Google Cloud Organization Policy restricts how resources may be configured; IAM determines who is authorized to act. An organization policy therefore does not give a project owner access, and an IAM grant does not prove that the requested configuration is permitted. Both layers must be tested for an onboarding claim.

Effective behavior depends on the constraint type and child policy. Legacy list rules can merge with a parent when inheritance is enabled, with denied values taking precedence. Boolean rules do not merge: the child value is effective there. Inherited managed constraints apply as the parent set or are replaced by the child policy. A project override can therefore change the outcome.

For each critical constraint, record its type, parent policy, child policy, inheritance or override setting, conditions and tags, effective result, and the operation used as a canary. Dry-run evaluation is useful before enforcement, but acceptance should distinguish the dry-run observation from the active policy. Changes may take time to propagate, so the evidence timestamp and the first successful or denied operation after propagation matter.

Organization policy changes are usually not retroactive. An older resource can remain in a violating state until the team addresses it, unless the particular constraint documents retroactive enforcement. The onboarding pack must pair effective policy evidence with an inventory query for legacy state. For custom constraints, also confirm that the targeted service, resource type, method, and fields are supported; the existence of a custom constraint definition does not prove that it covers every operation the architecture assumes.

Treat onboarding as an evidence-gated state transition

An account factory or subscription vending pipeline is useful only if it turns a request into a predictable state. The gates should be explicit enough that an auditor can replay them and a platform engineer can diagnose a failure.

1. Requestbind workload class, data sensitivity, region, owner, and exception needs
2. Placementcreate or move the child under the approved parent and verify the full hierarchy
3. Effective stateexport evaluated guardrails, IAM boundaries, logging, and unresolved legacy resources
4. Canaryrun harmless allowed and denied operations and trace the control-plane records
5. Acceptsign the evidence pack, record exception expiry, and register drift and rollback owners

Make failed onboarding safe. A child that misses a gate should remain in an intentionally engineered restricted state without production identities or data; this requires a concrete parent, policies, network path, and allowed operations rather than a native “quarantine” label. The pipeline must not “temporarily” place it in a permissive parent and rely on a later move. If a required service needs an exception, create the exception record before release, test the compensating control, and set a decision date for removal or renewal.

Bind evidence to immutable identifiers and controlled revisions. “Production subscription compliant” means little without its ID, assignment revision, evaluation time, and unresolved count. If no single effective-policy export exists, preserve the inputs and evaluation procedure.

Manage old resources and exceptions as separate work queues

Preventive policy, legacy remediation, and exceptions have different completion conditions. Keep three registers. The prevention register asks whether new or changed resources are blocked or transformed as designed. The remediation register tracks existing resources, owner, action, failure reason, and retest. The exception register records a deliberate departure, its risk decision, compensating control, scope, and expiry.

Do not close a legacy item because the baseline now contains the right rule. Close it when the resource is removed, changed, isolated, or explicitly accepted, and when the evidence matches that disposition. Likewise, do not label every non-compliant resource an exception. Some are deployment errors, some await an approved remediation window, and some reflect a policy query that does not apply as expected. Mixing them destroys accountability.

Exception expiry needs an executable consequence. Decide whether expiry blocks deployment, removes access, opens a ticket, quarantines the child, or escalates for renewal. Test that mechanism before production onboarding. Emergency access should have its own owner and evidence trail; it should not be hidden inside a permanent policy exclusion.

Assign control-plane ownership and make rollback testable

The workload owner is rarely the organization-policy owner. Name the baseline author, deployment operator, exception approver, and workload responder. Where risk warrants, separate policy proposal, approval, deployment, and exemption powers.

Every material guardrail change should carry a versioned diff, affected hierarchy, expected new violations, canary cohort, propagation allowance, health and compliance gates, stop condition, and rollback method. Test rollback with the same seriousness as rollout. Confirm that credentials, break-glass paths, policy repositories, and deployment systems needed to restore the previous state remain usable after the new policy takes effect.

Monitoring should detect drift in both directions: a restrictive control disappearing and an untested restriction arriving. Useful events include policy and hierarchy changes, child moves, exemption creation or extension, remediation-role grants, logging destination changes, and failed canaries. Link these events to the change record so the response team can distinguish an approved rollout from unauthorized control-plane activity.

Specify the evidence a supplier must deliver

A useful supplier deliverable includes the hierarchy and ownership map; a provider-specific effective-policy matrix; sampled account, subscription, and project evidence; the old-resource reconciliation; exception and remediation registers; control-plane privilege paths; rollout and rollback test results; and acceptance decisions with assumptions. Findings should identify the claim that failed, the affected children, a reproducible query or harmless operation, the responsible owner, and a retest criterion.

Ask bidders how they will sample a large estate, reconstruct effective policy, handle provider exclusions, separate prevention from remediation, and validate rollback without disrupting production. A scope based only on the number of cloud accounts is weak. Effort is driven by distinct hierarchy patterns, policy variants, exception classes, legacy inventory, control-plane identities, and the number of canaries and retests.

The broader multi-cloud security assessment guide helps frame assurance across providers, while the hybrid cloud security audit addresses identity, network, agents, and evidence across on-premises and cloud boundaries. For the landing-zone decision described here, keep the scope on organization guardrails and account acceptance.

An independent check is useful before a major migration, after a hierarchy redesign, or when several teams cannot produce one defensible acceptance pack. In a written, authorized scope, Pentest.red’s cloud security audit can review effective controls and inspect agreed read-only exports. Selected harmless canaries require separately agreed permissions beyond the default read-only access; the resulting report can document reproducible gaps, ownership, and retest criteria. It cannot guarantee that every future cloud change will be safe, and a mature platform team may be able to perform this acceptance internally. The scope planner helps define the children, identities, exclusions, test actions, and stop conditions; the sample report shows the expected distinction between evidence, impact, and remediation.