Cloud access management is the practice of controlling which human and machine identities can reach cloud resources, what actions they can perform, and how that access changes over time.
For a small team, IAM does not need to become an enterprise identity program. The useful baseline is simpler: use named identities, grant the smallest practical privilege, separate human and machine access, review privileged access regularly, and remove access immediately when its business purpose ends.
For Raff Technologies workloads, the recurring access risk is often privilege that accumulates over time: old SSH keys, broad API credentials, temporary contractor access, shared admin accounts, and production permissions that no longer match a person's role.
This guide explains cloud IAM for small teams through roles, least privilege, access lifecycle, API and service identities, access reviews, and recovery access. For the recurring review process, use User Access Review for Cloud Servers.
Cloud access management controls identities, actions, and resources
Identity and Access Management (IAM) answers three operational questions:
Who or what is requesting access? What resource are they trying to reach? Which actions should they be allowed to perform?
The identity may be a person, an application, a CI/CD workflow, an API key, or another service. The resource may be a cloud project, VM, network, backup, database, repository, or administrative console.
A useful small-team model separates five elements:
| IAM element | Question | Example |
|---|---|---|
| Identity | Who or what is acting? | Developer, contractor, CI job |
| Resource | What is being accessed? | Production project, VM, backup |
| Permission | Which action is allowed? | Read, create, modify, delete |
| Scope | Where does the permission apply? | One project, staging only, account-wide |
| Lifecycle | When should access change or end? | Role change, expiry, offboarding |
Cloud access management becomes weak when one identity has broad scope, unclear ownership, and no removal condition.
The decision framework starts with six access questions
Before granting privileged access, record the decision in a form the team can review later.
| Decision | Question | Preferred outcome |
|---|---|---|
| Identity | Is this a named human or machine identity? | One accountable owner |
| Purpose | Why is access required? | Specific current task or role |
| Action | What must the identity actually do? | Minimum required permissions |
| Scope | Which resources must it affect? | Smallest practical project or environment |
| Duration | How long should it remain active? | Expiry or review condition |
| Recovery | What happens if normal access fails? | Separate controlled emergency path |
Grant standing access when the person or service genuinely needs the permission as part of normal operations.
Grant temporary access when the task has a clear end, such as migration, support, incident response, or contractor work.
Use separate machine credentials for CI/CD, monitoring, backups, and automation rather than reusing a human administrator's credential.
Use break-glass access only for recovery when normal identity or network controls fail. Emergency access should have an owner, storage method, use condition, and post-use rotation process.
The Raff decision rule is practical: if the team cannot name the owner, purpose, scope, and removal condition for privileged access, the access is not ready to be granted.
Roles are easier to govern than one-off permissions
Roles group permissions around a responsibility. They help small teams avoid rebuilding an access decision for every user.
Examples of useful conceptual roles include:
Viewer Developer Operator Billing administrator Network administrator Backup operator Project administrator
The exact role names depend on the platform and team. The important rule is that the role should describe permitted actions rather than job seniority.
A senior engineer does not automatically need billing changes, backup deletion, DNS administration, and access to every production environment.
Prefer roles when:
- several people need the same responsibility;
- access should change when a person changes function;
- onboarding needs to be repeatable;
- reviews should compare actual access with an approved pattern.
Use exceptions sparingly. Too many one-off grants make the effective permission model difficult to explain and remove later.
For small teams, three or four useful roles are often better than dozens of narrowly named roles nobody maintains.
Least privilege should be expressed as business actions
Least privilege means granting only the access required to complete an approved task or responsibility.
The concept becomes easier to apply when permissions are reviewed by action.
| Need | Narrower access question |
|---|---|
| Deploy an application | Does the user need VM deletion or only deployment access? |
| Troubleshoot a server | Is read/log access enough, or is sudo required? |
| Verify backups | Does the workflow need restore/delete permission or read-only status? |
| Update a firewall | Does the identity need all network administration? |
| Run CI/CD | Does the pipeline need account-wide access or one project? |
| Support a customer | Does access need to remain after the ticket closes? |
Least privilege also applies to scope.
A staging automation key should not control production. A backup checker should not delete VMs. A contractor working on one project should not automatically see unrelated projects.
Reduce privilege in layers:
Account -> Project -> Resource category -> Allowed actions -> Time / expiry condition
No cloud IAM model eliminates the need for review. Permissions that were correct six months ago may be excessive today because the team, workload, or automation changed.
Human and machine identities need separate lifecycles
Human identities and machine credentials fail in different ways and should not be governed as one group.
Human access follows employment and responsibility
Human access should change when a person:
- joins the team;
- changes project or role;
- moves from development to production responsibility;
- becomes an administrator;
- starts or ends a contractor engagement;
- leaves the organization.
Prefer named accounts and individual SSH keys where practical. Shared administrator accounts weaken attribution and make offboarding harder.
Require multifactor authentication for privileged cloud and recovery accounts where the platform or identity provider supports it. MFA does not replace least privilege, but it reduces the risk that one stolen password becomes immediate administrative access.
Machine access follows the workflow lifecycle
Machine identities include:
- API keys;
- CI/CD credentials;
- infrastructure-as-code credentials;
- monitoring agents;
- backup automation;
- service accounts;
- internal integrations.
Every machine credential needs:
- a named human or team owner;
- one documented purpose;
- narrow resource scope;
- the minimum actions required;
- secure storage;
- a rotation or expiry strategy;
- a retirement condition.
A credential should not outlive the automation that required it.
Access reviews prevent privilege from becoming permanent
Access reviews are the maintenance process for IAM.
Review both entitlement and reachability:
- platform users and roles;
- project membership;
- SSH keys;
- Linux sudo users;
- Windows/RDP administrators;
- API keys and service accounts;
- CI/CD credentials;
- VPN or bastion membership;
- public administrative firewall rules;
- backup and recovery privileges;
- billing and destructive permissions.
For every item, choose one outcome:
Keep Reduce Rotate Disable Remove
Prioritize reviews around change events rather than relying only on a calendar.
| Event | IAM action |
|---|---|
| New employee | Grant approved baseline role |
| Role change | Remove old permissions before adding new ones where practical |
| Contractor task complete | Remove temporary access |
| Employee leaves | Offboard immediately across all systems |
| API workflow retired | Revoke its credentials |
| Security incident | Rotate or revoke affected access and review adjacent privilege |
| Major architecture change | Recheck roles and machine scope |
Use User Access Review for Cloud Servers for the detailed SSH, RDP, API-key, and offboarding checklist. For the boundary between application events and account actions, see Application Logs vs Audit Logs.
Network access and IAM should reinforce each other
IAM controls authorization. Networking controls reachability. Strong cloud access management uses both.
A production database may allow only a specific application identity at the database layer while also accepting network traffic only from approved private application paths.
A practical model is:
Internet user -> public application edge Administrator -> controlled admin path -> approved private resources Application identity -> private VPC path -> database / cache / internal service
Private networking does not mean every connected resource should trust every other resource. A compromised VM should not automatically gain administrative access across the VPC.
Likewise, a strong account role does not justify exposing SSH, RDP, databases, or admin panels broadly to the internet.
Use Private vs Public Admin Access when deciding whether administration should use direct public access, a VPN, bastion, or private path.
Raff access controls should be treated as a practical shared-responsibility layer
Raff's current access-control surface supports small-team governance without requiring teams to treat Raff as a full enterprise identity suite.
The Raff Identity and Access Management product covers current platform roles, project scopes, API keys, MFA, and account activity records. These platform controls do not replace guest operating-system user or SSH/RDP administration.
Current Raff automation and access documentation shows support for:
- projects as resource and automation boundaries;
- team members;
- roles and permissions;
- project-scoped API access;
- API-key names and key prefixes;
- account roles and project access when creating API keys;
- expiration settings for API keys;
- SSH-key management for VM access;
- VPC and firewall controls for network reachability.
A practical Raff model is:
Human administrator -> named account / approved role -> required projects CI/CD or automation -> dedicated API key -> project scope -> minimum required permissions -> expiry / rotation owner VM administration -> individual SSH key or named Windows access -> restricted network path where practical
Raff controls the platform access mechanisms it provides. Your team still decides who should receive access, how broad the scope should be, whether a machine credential remains necessary, and how quickly offboarding happens.
Do not design around unverified enterprise features. If your organization requires SSO, SCIM, conditional access, just-in-time privilege, or another specific identity-provider integration, verify current Raff support before making it an architectural dependency.
