Cloud security architecture review

    Reviewing an architecture before it ships is orders of magnitude cheaper than remediating it afterwards. This engagement takes your target design and stress-tests it against realistic attacker behaviour and the operational reality of the team that will run it.

    Updated

    What gets reviewed

    • Trust boundaries and blast radius: subscription or project topology, tenancy, environment separation and cross-boundary paths.
    • Identity model: human and workload identity, federation, secret-less authentication, privileged administration and escalation paths.
    • Data flows and classification, including third-party flows, plus where encryption, keys and access decisions are enforced.
    • Detection and response design: logged identity and control-plane events, on-call ownership and the runbook.
    • Operability: can the owning team run these controls, or will a deployment, recovery or support path bypass them?

    1Internet edge

    • Public endpoints
    • WAF / CDN
    • DDoS protection

    2Identity plane

    • Entra ID
    • Conditional Access
    • PIM elevation

    3Workload zones

    • Prod subscription
    • Non-prod subscription
    • Shared services

    4Data plane

    • Encrypted stores
    • Key management
    • Private endpoints
    Trust boundaries in a hybrid landing zone

    I trace user, administrator, workload and vendor paths to the protected resource, then test identity, network, token and workload-access assumptions against NIST SP 800-207 zero-trust principles. For each material control, I name the enforcement point, owner, evidence and shared-responsibility boundary; CSA CCM helps where provider and customer responsibilities blur.

    Frequently asked questions

    How early should this happen?

    As soon as there is a diagram and a decision that is still reversible. Reviewing after go-live turns design changes into migration projects.