Cloud identity

Cloud access decisions connect a principal, an operation, a resource, and applicable policy. Network reachability still matters, but reaching an API does not establish permission to use it. Identity review and platform security complement each other.

Azure provides the concrete vocabulary here. AWS and Google Cloud have related concepts with different resource hierarchies and evaluation rules. Translate the purpose of a control carefully instead of assuming similarly named roles are equivalent.

Tenant, subscription, and resource

A Microsoft Entra Tenant holds directory objects such as users, groups, and application identities. An Azure subscription is a resource-management and billing scope associated with a directory. A resource group organizes resources such as virtual machines, storage accounts, and vaults.

A directory and a subscription are not interchangeable containers. Directory administration governs identities and related policy; Azure Resource Manager governs resource management. Data services enforce their own applicable access decisions.

Global Administrator and subscription Owner are distinct roles. They have different responsibilities, although powerful directory administration can affect resource access through documented administrative mechanisms. “Separate roles” does not mean there are no relationships between their authorities.

Users, applications, and workloads

An app registration describes an application in its home directory. A Service principal represents an application or service within a tenant. These objects are related but not interchangeable. A multitenant application can have service principals in more than one tenant.

A Managed identity lets supported workloads authenticate without the developer directly managing the same kind of stored application secret. It still has permissions, dependencies, and a lifecycle. Compromise of an authorized workload can expose the authority available to that workload.

A Role assignment joins principal, role, and scope. Inherited assignments, conditions, deny mechanisms, and other provider rules may affect the result. Review the actual action and resource rather than relying only on a role’s name.

Three permission systems

Azure role definitions distinguish management actions from data actions. Management access does not universally grant direct data access, although some management powers can indirectly affect data exposure. Evaluate the particular operations and service design.

Microsoft Graph and Azure Resource Manager are distinct APIs. In a token request, the .default scope follows configured-permission and consent rules for the relevant resource and flow; it does not create unrestricted privileges or access to other organizations.

Tokens and federation

An access token has an intended recipient, or audience, and a lifetime under its issuer’s rules. A token accepted by one API is not automatically valid at another. Applications must validate appropriate issuer, audience, lifetime, and permissions.

Federation relies on a defined issuer and accepted claims. Workload federation can reduce stored long-lived secrets, but requires careful subject and audience restrictions. Entra business-to-business collaboration and AD forest trusts both involve trust relationships; they are not the same protocol or authorization model.

A workload stops running. Has its cloud access ended?

Not necessarily. Role assignments, application credentials, cached tokens, or a separately managed identity may remain. Retirement must account for each resource and credential lifecycle, including what is shared with other workloads.

Credential lifetime and durable changes

Some credentials, such as AWS IAM user access keys, do not expire automatically. Others, such as Entra client secrets, have an expiry date. Revocation, rotation, token expiry, and removal of a role have different timing and effects. Short lifetime reduces an exposure window but does not choose least privilege.

Access can persist through an authorized credential, membership, consent grant, or role assignment after its original purpose ends. Track ownership, review dates, and dependencies. A new configuration entry is not automatically malicious, but sensitive changes deserve auditable approval and review.

Defensive review and reporting

Prioritize narrow workload permissions, protected administrative changes, appropriate time-bound elevation, carefully scoped federation, and credential storage suited to the application. MFA and Conditional Access protect supported flows; they do not automatically invalidate every existing token or cover every workload.

Audit sources differ: directory changes, sign-ins, resource-management operations, and service data access may require separate configuration and retention. An installed monitoring product does not prove all of them are collected.

A useful finding states the principal, action, resource, scope, supporting evidence, and intended correction. Verify the owner’s necessary work after reducing access. The shorter cloud lessons explore resource retirement and audit context in more detail.

Worked review: the photo archive has two identities

The fictional Grove archive supplies effective permissions after relevant policy evaluation. Lea’s access uses Microsoft Entra authentication; assume no additional data grants, account keys, shared access signatures, or anonymous access.

F1, approved duties: Lea reviews storage settings, without viewing photographs. The PhotoImport managed identity must create, update, and read incoming photos, but must not delete them.

F2, actual grants: Lea has Azure Reader at the storage-account scope. PhotoImport can read, write, and delete blobs in the Incoming container.

F3, evidence boundary: These are configuration records, not data-operation logs. The owner has not approved deletion or given Lea a data role.

PredictShould Lea receive photograph access because she can inspect the storage account?

No. Azure Reader covers resource management visibility, not the blob data grant needed here. F1 also excludes photo viewing from her duty. Meanwhile, F2 gives PhotoImport an unnecessary delete operation; platform-managed credentials do not make that permission appropriate.

The owner should approve a supported permission design that preserves the importer’s required read/write actions while removing deletion. Verify effective permissions after all applicable grants are evaluated; attaching a narrower role alongside the old broad role may leave the excess intact.

Acceptance should demonstrate approved imports and reads, denied deletion for PhotoImport, and continued settings review without photo access for Lea. F3 does not justify claiming that deletion occurred. If PhotoImport is later retired, separately review attached workloads, role assignments, and already issued tokens before concluding its authority ended.