Cloud Security Controls by Provider: MFA, Scoped Users, Firewalls and Audit Logs Compared
The same security baseline mapped to the specific controls of eleven cloud providers: multi-factor authentication, scoped identities, network filtering, audit logging and posture monitoring.
The security baseline for a cloud account is the same everywhere: protect the owner login, work through scoped identities, close the network by default, log everything and review regularly. What differs is the name of the button. This guide maps that baseline to the specific controls of eleven providers, so the cloud account security checklist can be applied on whichever platform you use.
The baseline, in one table #
| Provider | Owner protection | Scoped identities | Network filtering | Audit logging | Posture and compliance |
|---|---|---|---|---|---|
| AWS | Root user MFA | IAM users, roles and policies | Security groups, network ACLs | CloudTrail | Security Hub, AWS Config |
| Google Cloud | Two-step verification on the Google account | IAM roles and service accounts | VPC firewall rules | Cloud Audit Logs | Security Command Center, Policy Intelligence |
| Microsoft Azure | MFA for Global Administrators | Entra ID users with Azure RBAC | Network security groups, Azure Firewall | Activity logs via Azure Monitor | Defender for Cloud, Azure Policy |
| Oracle Cloud | MFA for the tenancy administrator | IAM users, groups and policies scoped to compartments | Security lists, network security groups | Audit service | Cloud Guard |
| Alibaba Cloud | MFA, 90-day password rotation, logon mask (IP whitelist) | RAM users and ECS RAM roles instead of AccessKeys | Security groups | ActionTrail | Security Center |
| DigitalOcean | 2FA | Teams with member roles, scoped API tokens | Cloud Firewalls | Team activity and API token history | Monitoring alerts |
| Linode (Akamai Cloud) | 2FA, security questions, Login History (90 days) | Users with per-resource permissions | Cloud Firewalls | Login History, event log | Longview and alerts |
| Hetzner | 2FA | Project members and scoped API tokens | Hetzner Firewalls | Project activity | Console and API review |
| UpCloud | 2FA with SMS or call backup | Sub-accounts with granular permissions by category, tags for access control | Server firewall | Account activity | Control Panel review |
| Kamatera | 2FA | Additional users with least privilege | Cloud Firewall, private network segmentation | Console logs | Regular audits |
| OVHcloud | 2FA under My account, Security | Service contacts and access restrictions | Included DDoS protection plus host firewall | Account activity | Control Panel review |
1. Protect the owner login #
Every platform has one identity that can do anything: the AWS root user, the Google account that owns the organization, the Azure Global Administrator, the OCI tenancy administrator, the Alibaba Cloud account, or simply the account login on a developer cloud. Give it a long, unique password, enable multi-factor authentication, and then stop using it for daily work. Alibaba Cloud adds two controls worth copying elsewhere: rotate passwords on a schedule, and restrict console logins to known IP addresses where your team works from fixed locations.
2. Work through scoped identities #
Create an identity per person and per workload with only the permissions that role needs. On the hyperscalers that means IAM users and roles, Entra ID users with RBAC, or OCI groups and policies; on developer clouds it means team members, sub-accounts or additional users with limited permissions. For workloads, prefer roles that issue short-lived credentials, such as ECS RAM roles or AWS instance roles, over long-lived keys stored on a server. UpCloud’s combination of tags and access control, where each person can modify only the servers assigned to them, is a good model of the zero-trust idea on a small platform.
3. Close the network by default #
Security groups, network security groups, VPC firewall rules, security lists and cloud firewalls all do the same job: allow only the traffic you intend. The habits that matter are restricting management ports (SSH, RDP, database ports) to known addresses, segmenting public web tiers from private application and database tiers, and remembering that images such as Oracle Linux and Ubuntu also run a host firewall that must agree with the cloud rules. Our networking basics guide covers the layout.
4. Turn on audit logging #
CloudTrail, Cloud Audit Logs, Azure activity logs, the OCI Audit service and Alibaba ActionTrail record who did what, when. On developer clouds, review login history and activity logs; Linode’s Login History shows attempts for the last 90 days with source addresses. Logs are only useful if someone looks, so route them somewhere searchable and alert on the events that matter, such as new administrator grants or key creation.
5. Monitor posture and review regularly #
Security Hub, Security Command Center, Defender for Cloud, Cloud Guard and Security Center each score the account against a standard and list findings. Schedule a review of the findings, the administrator list, active keys and firewall rules. Quarterly is a reasonable minimum; monthly for production.
Billing alerts are a security control too #
A leaked credential is usually noticed as a spend spike before anything else. Set budgets and billing alerts on every account; our guide to budgets and billing alerts shows where.
A ninety-minute setup order #
- Enable MFA on the owner login and store recovery codes in a password manager.
- Create your own scoped identity and confirm you can do everything you need with it; then stop using the owner login.
- Set a budget alert.
- Write the network rules for the first workload, closing management ports to the internet.
- Turn on audit logging and route it somewhere durable.
- Enable the posture tool and read its first findings.
- Write down what you did, including where the logs go and who holds admin access.
Credentials for workloads, not just people #
The controls above focus on humans, but most leaked credentials belong to software. Give applications an identity of their own (an IAM role, a service account, an ECS RAM role or a scoped API token), grant it only what the application calls, and prefer mechanisms that issue short-lived credentials automatically over keys stored in configuration files. Rotate anything long-lived on a schedule and delete tokens when the integration that used them is retired.
Frequently asked questions #
Which control has the best return on effort?
Multi-factor authentication on the owner login, followed by removing long-lived access keys from servers in favor of roles.
Are developer clouds less secure than hyperscalers?
They offer fewer controls, not weaker ones. The baseline of MFA, scoped users, firewalls and log review is available on all of them; the hyperscalers add posture tooling and finer-grained policy.
How do I know if my account has already been compromised?
Look for unfamiliar users, keys or regions in the audit log, unexpected resources such as large instances in regions you do not use, and a spend spike. If you find them, rotate credentials and contact the provider’s support.
