An access review is a recurring check of who and what can reach your systems, what each identity can do, why that access still exists, and whether it should be kept, reduced, rotated, disabled, or removed. A useful cloud access review covers human accounts, SSH keys, Windows/RDP users, API keys, service accounts, private-network membership, recovery permissions, and other privileged paths—not only users in a cloud dashboard.
For Raff Technologies environments, the same principle applies across Linux VMs, Windows workloads, private networking, automation, and recovery: every privileged path should have a known owner, current purpose, appropriate scope, and clear next action.
The practical goal is simple:
No privileged access should survive only because nobody remembers why it exists.
Access review: quick framework
For every user, key, token, service account, and privileged network path, answer five questions:
- Who or what owns it?
- Which systems can it reach?
- Which actions can it perform?
- Is that access still required today?
- What should happen next?
Every item should end in one of five decisions:
| Decision | Meaning |
|---|---|
| Keep | Access is justified and correctly scoped |
| Reduce | Access is broader than the current role requires |
| Rotate | The credential is old, shared, exposed, or difficult to attribute |
| Disable | Access may be needed again but should not remain active now |
| Remove | The business or technical reason no longer exists |
“Reviewed” is not an outcome. If excessive or unexplained access is found, the review should produce a change, owner, or documented dependency.
What is a user access review?
A user access review verifies that current permissions still match current responsibilities.
In cloud infrastructure, that usually means reviewing more than human user accounts. Include:
- cloud/project users;
- Linux accounts and SSH keys;
- Windows and RDP users;
- sudo and local Administrator membership;
- API keys and tokens;
- CI/CD and service identities;
- VPN, bastion, and private-network access;
- public administrative exposure;
- backup and recovery permissions;
- break-glass access.
The complete path is:
Identity ↓ Credential ↓ Network reachability ↓ Authentication ↓ Privilege ↓ Resource or business action
Removing a contractor from a cloud dashboard is incomplete if their SSH key still works. Disabling a Windows account is incomplete if the person still knows a shared Administrator password. Rotating one API key is incomplete if an old personal token still runs in CI/CD.
Access reviews should cover identity, credentials, privileges, and reachability together
Checking only one layer creates false confidence.
| Layer | Examples | Review question |
|---|---|---|
| Human identity | Cloud user, Linux user, Windows user | Does this person still need access? |
| Credential | SSH key, password, API key, certificate | Is it attributable, protected, and current? |
| Machine identity | CI/CD job, monitoring agent, backup process | Does the automation still exist and need this scope? |
| Privilege | Root, sudo, local Administrator, backup deletion | Is the permission broader than required? |
| Reachability | Public SSH/RDP, VPN, VPC, bastion | Can this identity reach more systems than it should? |
| Recovery access | Snapshot, backup, restore, break-glass access | Can one identity remove both production and recovery? |
A strong access review evaluates all of these together.
User access review best practices for small teams
Small teams do not need heavyweight governance software to run a useful review. They do need a repeatable process.
1. Maintain a current access inventory
Track privileged access in one place with at least:
| Field | Example |
|---|---|
| Identity | Jane Doe / deploy-api |
| Type | Human / service account / SSH key |
| Owner | Platform team |
| Environment | Production |
| Resource scope | web-01, db-prod |
| Privilege | SSH user / sudo / API write |
| Reason | On-call administration |
| Last reviewed | 2026-09-01 |
| Expiry | None / project end date |
| Decision | Keep / reduce / rotate / disable / remove |
The inventory does not need to mirror every operating-system detail. It needs enough information to explain why access exists and who is accountable for it.
2. Prioritize high-impact permissions
Review identities first when they can:
- create or delete infrastructure;
- change firewall rules or private-network routes;
- add administrators or SSH keys;
- manage DNS;
- view or change secrets;
- export customer data;
- restore or delete recovery points;
- modify production databases;
- change billing or account-level settings;
- disable monitoring or logging.
These permissions have larger failure impact than ordinary read-only access.
3. Prefer named identities over shared credentials
Shared credentials make access reviews difficult because the team cannot reliably attribute use.
Avoid long-lived shared:
- root passwords;
- Administrator passwords;
- SSH private keys;
- API tokens;
- VPN credentials;
- generic production accounts.
Where a shared emergency credential is unavoidable, treat it as break-glass access and protect, audit, and rotate it accordingly.
4. Give temporary access an expiry condition
Temporary access should not silently become permanent.
For migration, support, contractor, or incident access, record:
- owner;
- exact scope;
- reason;
- start date;
- expiry date or completion condition.
5. Verify changes after the review
A planned change and an applied change are not the same thing.
If the review says “remove SSH key,” verify that the key no longer authenticates. If a Windows account is disabled, verify sign-in is blocked. If an API token is rotated, confirm the replacement works and the old credential is rejected.
SSH key review should be treated like user-account review
SSH keys are easy to distribute and forget. Each trusted key should have a known owner, purpose, server scope, and removal condition.
Investigate or remove a key when:
- its owner left the team;
- nobody can identify who owns it;
- several people share the same private key;
- the private key may have been exposed;
- it is trusted by more servers than required;
- the automation or project that used it has been retired.
Linux access reviews should also cover:
- active interactive users;
- service users with shell access;
- sudo groups;
- direct root access;
- deployment users;
- old keys in
authorized_keys; - credentials in home directories;
- forgotten automation accounts.
A developer who needs logs does not automatically need unrestricted sudo.
Windows and RDP access reviews need separate attention
Windows administration has different access patterns from Linux SSH.
Review:
- RDP users;
- local Administrators membership;
- shared Administrator credentials;
- vendor and contractor accounts;
- disabled but reusable accounts;
- saved credentials on jump hosts or staff devices;
- public RDP exposure;
- Network Level Authentication where supported;
- MFA at the access layer where the selected design supports it;
- sign-in evidence where retained.
A user may need Remote Desktop access without needing local Administrator rights.
If the network path itself is too broad, use Private vs Public Admin Access and Bastion Host vs VPN vs Public SSH to redesign the access boundary rather than only reviewing users on the existing path.
API keys and service accounts need owners too
Machine identities often outlive human accounts because nobody notices them until an automation breaks.
Review credentials used by:
- CI/CD pipelines;
- infrastructure automation;
- monitoring;
- backup jobs;
- applications;
- integrations and webhooks;
- migration scripts;
- command-line tooling.
Each machine identity should answer:
| Field | Review question |
|---|---|
| Owner | Which person or team is accountable? |
| Purpose | Which live workload still needs it? |
| Scope | Which resources and actions can it access? |
| Storage | Where is the credential protected? |
| Rotation | How can it be replaced safely? |
| Evidence | Is recent use visible? |
| Retirement | What event should cause removal? |
A credential without an owner is difficult to rotate safely. A service identity without a current service should be disabled or removed.
Do not keep long-lived secrets in source code, reusable VM images, tickets, shared chat, or broadly accessible documentation merely because updating the automation is inconvenient.
Offboarding is the most urgent access-review event
A scheduled review can wait for its planned date. Offboarding should not.
When an employee, vendor, or contractor leaves, remove relevant access across:
- cloud/project membership;
- Linux users and SSH keys;
- Windows and RDP accounts;
- sudo and administrator groups;
- VPN or bastion membership;
- API keys and personal tokens;
- source-control and CI/CD systems;
- password managers and secrets;
- monitoring and incident tooling;
- DNS and domain administration;
- billing access;
- customer environments;
- backup and recovery administration.
Rotate shared credentials the departing person could still use.
Removing the named account is not enough if copied private keys, shared passwords, or personal tokens remain valid.
How often should access reviews happen?
There is no universal review cadence for every workload. Frequency should follow risk, team change, privilege level, and contractual requirements.
A practical starting model can be:
| Access area | Review trigger or cadence |
|---|---|
| Employee offboarding | Immediately |
| Contractor access | At task completion and during long engagements |
| Production administrators | After material role/team changes and on a recurring schedule |
| SSH/RDP access | Recurring, with frequency based on exposure and change rate |
| API keys and service accounts | Recurring and after ownership changes |
| Break-glass access | After every use and during periodic recovery checks |
| Billing and recovery-deletion privileges | Recurring because impact is high |
| Public admin exposure | After architecture changes and on a recurring schedule |
Increase frequency when contractors are common, customer data is sensitive, an MSP manages many environments, or privileges change frequently.
Privileged access review should focus on business actions
Role names can hide excessive privilege. Review what an identity can actually do.
Instead of asking only whether someone is an “admin,” ask whether the identity can:
- create or delete infrastructure;
- modify networking;
- add other administrators;
- export customer data;
- change secrets;
- delete recovery points;
- modify production databases;
- alter billing;
- disable monitoring.
A support contractor may need logs without database export rights. A deployment identity may need to update one service without being able to delete backups.
Least privilege becomes easier to evaluate when access is described as actions rather than titles.
Review network reachability together with identities
A user may have limited operating-system permissions but still be able to connect to too many resources.
Review:
- which servers expose SSH or RDP publicly;
- which source ranges are allowed;
- who can join a VPN or other private-access path;
- which routes those users receive;
- whether one private network creates unnecessary lateral reachability;
- whether databases are reachable from unrelated systems;
- whether IPv6 exposure matches IPv4 policy;
- whether retired hosts still appear in firewall rules.
Private networking reduces exposure. It does not create implicit trust.
Use Cloud Firewall Best Practices and Private Networking: Public vs Private Traffic for the network-policy layer.
Break-glass access needs its own review
Break-glass access is intentionally powerful and rarely used, which makes it easy to forget.
Confirm:
- the emergency identity or credential still works;
- access is protected from casual use;
- authorized users are still correct;
- recovery instructions are current;
- use is logged where possible;
- credentials are rotated after use or exposure;
- the emergency path has not become routine administration.
An emergency path that cannot be used during an incident is not useful. An emergency path used every day is no longer an emergency control.
Backup and recovery permissions deserve stricter review
Recovery systems are high-impact because an identity able to delete production and every backup can remove the team's recovery options.
Review who can:
- create recovery points;
- restore them;
- change retention;
- delete snapshots or backups;
- access application-level exports;
- alter backup credentials.
Where workload impact justifies it, separate ordinary server administration from backup-deletion rights.
Use Cloud Snapshots vs Backups and Restore Testing Checklist for Production VMs for the recovery side of the design.
Access review evidence: activity is not authorization
The access inventory shows who can act. Logs and activity records can help show who did act.
Useful evidence may include:
- SSH login history;
- sudo activity;
- Windows security events;
- cloud account changes;
- API-key use;
- firewall and private-network changes;
- deployment records;
- backup restore/deletion events;
- incident records.
Do not keep an unexplained privilege indefinitely merely because recent activity is unclear. Investigate the owner and dependency, then make an explicit decision.
A practical access-review meeting for small teams
A lightweight review can follow this sequence:
- Inventory users, keys, tokens, service identities, and privileged paths.
- Assign a named owner to every item.
- Compare each item with the owner's current role or workload.
- Review public and private network reachability.
- Check recent use where reliable evidence exists.
- Choose keep, reduce, rotate, disable, or remove.
- Assign required changes to owners.
- Apply the changes.
- Verify the changes took effect.
- Confirm emergency access still works as designed.
- Record unresolved dependencies and the next review trigger.
The output should be a change list with owners and due dates, not only a completed checklist.
MSP access reviews need customer-level separation
MSPs and managed IT providers have a larger version of the same problem because administrators may reach several customer environments.
Review whether:
- one credential is reused across customers;
- one VPN or private network creates excessive lateral access;
- customer production access can be attributed to a named person;
- contractors retain access after an engagement ends;
- one automation token can modify unrelated tenants;
- backup or recovery permissions cross customer boundaries.
Prefer named users, customer-scoped permissions, separate credentials, restricted network paths, auditable access, and explicit offboarding.
Use Private Cloud Networking for MSPs and Secure Remote Access for MSPs for the surrounding architecture.
How this applies to Raff infrastructure
A Raff-focused access review can include:
- Raff Cloud Servers for Linux users, SSH keys, root/sudo access, and VM administration;
- Windows VM for RDP users and local Administrator access;
- Raff VPC for current private-networking paths;
- Data Protection for recovery access, restore authority, and deletion rights;
- Raff account/API credentials used for automation and administration.
Use the live product and pricing pages for current product availability, limits, and commercial values. This guide intentionally avoids hard-coded bandwidth, storage pricing, free-pool amounts, retention limits, and other mutable product details.
Raff provides infrastructure controls and recovery capabilities. Your team still owns guest-OS accounts, SSH/RDP access, credential ownership, application authorization, contractor offboarding, and internal access-review policy.
