Identity is where cloud security starts
In a data centre, a network perimeter does a lot of the protecting. In the cloud, the perimeter is mostly identity. Anyone with a valid credential and the right permissions can create resources, read data or delete backups from anywhere. If you migrate workloads before settling identity, you end up with local users, shared logins and keys in scripts, each of which is hard to remove later.
Identity work is therefore built early in our cloud migration service, alongside the landing zone, and it underpins the security baseline.
What good looks like
- One directory is the source of truth for who works at the company.
- People sign in through SSO with MFA, and receive access by group.
- No human has a standing access key or a local cloud user, apart from monitored break-glass accounts.
- Workloads authenticate with roles or managed identities, not stored passwords.
- Permissions follow least privilege and are reviewed on a schedule.
- Domain-joined servers keep working, including when the link to the site fails.
Integration models
There are a few common shapes, and the right one depends on what you already have.
Cloud identity provider synced from AD. Microsoft Entra Connect synchronises users and groups from on-premises AD to Entra ID. Entra ID then acts as the identity provider for Azure, Microsoft 365 and, through SAML, for AWS IAM Identity Center. This suits organisations already on Microsoft 365.
Directory connected to AWS. IAM Identity Center can use AWS Managed Microsoft AD, an AD Connector to your existing domain, or an external provider. A managed directory also serves domain-joined EC2 instances. AD Connector is a proxy and does not host a copy of your directory, so it needs a reliable link.
Extended domain controllers. Adding domain controllers in the cloud network, in the same forest, gives local authentication for workloads. It also means you now operate those controllers, which need patching, backup and monitoring.
For existing AD estates, the question we ask first is: what depends on AD? Kerberos-based applications, file shares with ACLs, SQL Server integrated security and group policy all do. Those answers drive the design far more than the product catalogue does.
Mapping groups to access
The aim is that access changes by editing group membership in the directory, and nowhere else. In IAM Identity Center that means permission sets assigned to groups on accounts. In Terraform, an assignment can look like this:
data "aws_ssoadmin_instances" "this" {}
resource "aws_ssoadmin_permission_set" "readonly" {
name = "ReadOnlyAccess"
instance_arn = tolist(data.aws_ssoadmin_instances.this.arns)[0]
session_duration = "PT4H"
}
resource "aws_ssoadmin_managed_policy_attachment" "readonly" {
instance_arn = tolist(data.aws_ssoadmin_instances.this.arns)[0]
permission_set_arn = aws_ssoadmin_permission_set.readonly.arn
managed_policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
}
resource "aws_ssoadmin_account_assignment" "platform_readonly" {
instance_arn = tolist(data.aws_ssoadmin_instances.this.arns)[0]
permission_set_arn = aws_ssoadmin_permission_set.readonly.arn
principal_id = var.platform_group_id # object ID of the synced directory group
principal_type = "GROUP"
target_id = var.workload_account_id
target_type = "AWS_ACCOUNT"
}
On Azure, the equivalent is role assignments for Entra groups at management group or subscription scope, ideally with Privileged Identity Management so elevated roles are requested and expire. Where your team uses Kubernetes later, group-based access carries through to cluster RBAC.
Servers and service accounts
Domain-joined workloads are where identity and the network design meet. If the nearest domain controller is across a VPN, a link failure turns into an application outage. We prefer controllers or a managed directory in the same region as the workloads, with sites and subnets defined in AD so clients find the closest one. DNS must resolve domain names from the cloud network, covered in hybrid DNS planning.
Service accounts are the part that causes surprises. Old accounts with never-expiring passwords run scheduled tasks, database jobs and integrations. We build an inventory from the directory and from the servers themselves, identify owners and migrate them deliberately. Where an application can use a role or managed identity instead of a password, we make that change. Where it cannot, we vault and rotate.
Decisions and trade-offs
Managed directory or self-run controllers. A managed directory reduces patching, with less control over schema and some features. Self-run controllers give full control and full responsibility.
Federation or sync. Federation keeps authentication on-premises, which means your AD Federation Services must be highly available for cloud sign-in to work. Password hash sync or pass-through approaches reduce that dependency. We weigh security policy against resilience.
When not to integrate AD. A company with no existing AD and no Windows estate should use a cloud-native identity provider and skip a directory altogether. Introducing AD only to migrate to the cloud is unnecessary.
A worked example: the leaver test
Before handover we run a leaver test with a real but disposable test account. We add it to a group, sign in through SSO, confirm the expected role appears in the target account, then disable the user in the directory. We then check three things: the existing session expires at the configured duration, a new sign-in is refused, and no access key or local user remains for that person anywhere. If any of those fail, the design has a gap, and it is far better to find it with a test account than during a real departure. The same test is repeated for a mover who changes teams, since stale group membership is the more common problem.
Common failure modes
- Break-glass account not tested, then locked out during an identity provider outage.
- Over-broad administrator groups mapped for convenience.
- Orphaned local users created “temporarily” during the project.
- Time skew breaking Kerberos on new servers.
- Sync scope too wide, exposing service or test accounts to the cloud.
Delivery and handover
Role definitions, group mappings and policies are in code. We hand over a joiner, mover and leaver procedure, the break-glass runbook and a periodic access review checklist, which also appear in the operations runbook.
How to tell it is working
A new starter gets the right access by being added to groups. A leaver loses access everywhere the same day. Access key reports show no human keys. Break-glass sign-in is tested and alerts when used. To review your identity design, contact us.