Most of the security model in a cloud platform is decided early, and often by people whose priority at the time is getting something working rather than considering what it will look like in three years. Tenant separation, the identity model, and where the trust boundaries sit are none of them difficult to change while they are still on a whiteboard, and all of them become expensive once teams have built on top of them.
We do that design work together with your cloud and platform teams. In practice that means working through:
- How tenants, accounts and subscriptions are separated, and what that separation actually enforces
- How identity and access is implemented for people, for workloads, and agents
- Where the trust boundaries are, and how they hold against threats
- How data moves through the platform, including the paths that were never documented
- Which controls the platform should enforce, and which can reasonably be left to policy
New platforms
A new platform is where this work costs least. Correcting a landing zone design before anyone has provisioned from it is a workshop, and correcting it after teams have been onboarding onto it for a couple of years is a project with its own budget.
Platforms that already exist
We do the same work on platforms that already exist, which is more common. That normally means reviewing a target architecture that somebody else drew, redesigning an identity model that has outgrown what it was originally built for, or setting the security architecture for a migration that has already started.
What you get
A documented target architecture, the reasoning behind the decisions, and a realistic order to do things in. Our architects stay involved through the build, since most of the questions worth answering come up once somebody starts implementing.
We work across Microsoft Azure, Amazon Web Services, Google Cloud Platform, OCI, and Kubernetes.