Identity
Cloud identity and access
Plan cloud access for staff, administrators and workloads with narrow permissions, protected sign-in and a reviewable removal process.
Cloud identity and access management determines which people and workloads can use cloud resources, what they can do, and when access ends. Start with an inventory of identities and material grants. Give each identity access for a defined purpose, protect privileged routes, and review access when that purpose changes.
Map identities to work
For each material workload, identify the staff, contractors, applications and automated jobs that use it. Record the action and resource each needs, plus a business owner and technical contact. A report reader may need data access without permission to change the application that produces it.
Check the full access path. Group membership, inherited assignments and other grants can give an identity more permission than a single role suggests.
| Identity | Main decision | Review trigger |
|---|---|---|
| Employee or contractor | Which role and resource scope fit the current duty? | A move, departure, contract change or scheduled review |
| Privileged operator | Which administrative actions are needed, and for how long? | A role change, emergency grant or privileged-access review |
| Application or automation | Which workload identity and authentication method fit the task? | A deployment, owner change or workload retirement |
| Long-lived credential | Why is it needed, where is it used and who can retire it? | Replacement, suspected exposure or uncertain use |
Keep grants narrow
Describe the task before assigning a role: required actions, resources, environment and duration. Check the resulting scope and any other grants to the same identity. Do not grant broad administration to fix an access error before identifying the missing permission.
Protect administrative access
Identify people and accounts that can assign roles, change identity settings or administer important resources. Keep their access attributable and review both standing and activatable grants.
Confirm the current duty, resource scope and whether access can be reduced or time limited. Keep an approved emergency access route and check its use.
Key Cloud Identity Best Practices (Australia)
- ATO Compliance
- Essential Eight Maturity Model requires least-privilege access and regular reviews
- AWS Recommendation
- Use temporary credentials; avoid long-lived keys for humans
- Azure Guidance
- Use managed identities to reduce credential risk
- Australian Business Context
- Remote staff accessing offshore data must follow strict identity controls
Give workloads their own identities
Give an application or job its own identity rather than using an employee login. Where source and target support it, prefer temporary credentials or a managed identity over a long-lived key.
AWS recommends IAM roles with temporary credentials for workloads. Azure managed identities can obtain Microsoft Entra tokens without application-owner credential management when the identity path is supported.
If a long-lived credential is necessary, record its owner, consumers, protected storage and replacement method. Removing a copy from configuration does not retire the provider-side credential.
Distinguish principal types
Human identities include administrators, developers, operators and application users. AWS recommends human users access AWS through federation with an identity provider and temporary credentials, not long-lived credentials.
A cloud principal can be an individual user, a group, a managed identity or a service principal. A group assignment gives members access together, so review both the grant to the group and who belongs to it.
A managed identity is associated with an Azure resource. The target service still authenticates and authorises that identity; an identity alone does not grant permission to the target.
Make access decisions traceable
An Azure role assignment records the principal, assigned role and scope. It can include a name and description explaining why the role was assigned, so reviewers can judge whether the grant still matches its purpose.
AWS IAM Access Analyzer can generate least-privilege policies from access activity and validate policies for secure, functional permissions. AWS also recommends checking public and cross-account access and setting permissions guardrails across multiple accounts.
Use activity data as evidence alongside the workload's purpose, owner knowledge and schedule. A quiet period alone does not show that an annual job or recovery action is unnecessary.
Run the access lifecycle
Record the purpose, approver, scope and intended duration of material grants. On a job change, compare old access with the new duty. On departure or workload retirement, remove relevant assignments and credentials, then check other paths through groups or direct grants.
Decide whether to retain, reduce, remove or investigate each grant, and record who will make the change. A useful access register shows an owner, purpose and removal path for every material identity.
Where an AWS use case requires long-term credentials, AWS recommends updating access keys when needed. Its IAM guidance also recommends regularly reviewing and removing unused users, roles, permissions, policies and credentials.
In this guide
- Designing roles with the minimum required permissionsBuild cloud roles from required tasks, resource scope and duration, then check the grant and its holder's other access.
- Reviewing privileged cloud accountsIdentify privileged cloud grants, confirm each business need and close retain, reduce or remove decisions with platform limits in view.
- Managing service identities separately from employee accessGive applications owned identities, choose supported authentication, limit runtime access and retire identities with their workloads.
- Removing dormant credentials from cloud environmentsFind cloud credentials that appear unused, check dependencies, disable and observe them, then delete confirmed dormant credentials.
