Browse the site
Call Get a quote

How Do You Secure Your AWS, Azure or GCP Cloud Account?

Securing a cloud account means controlling identity first, then the resources that identity can reach. Enforce MFA for every human user, replace the long-lived root or owner keys with short-lived credentials, and give each workload its own role instead of sharing one powerful account. Restrict network access to private subnets, keep storage buckets and blob containers private, and turn on audit logging so that any change to policy is recorded. Indian companies in regulated sectors should treat the CERT-In empanelment and DPDP Act obligations as the baseline, because a cloud breach in India still has to be reported to CERT-In and to affected data principals.

Key takeaways

  • Cloud shared responsibility means the provider secures the infrastructure while you secure everything you deploy on it, and the configuration errors in that second half cause most cloud breaches.
  • Enforce MFA on every human identity and delete unused access keys, because a single leaked key is a faster route in than any exploit.
  • Replace long-lived access keys with short-lived roles or instance profiles, so a stolen credential expires within an hour instead of staying valid.
  • Keep storage buckets, blob containers and databases private by default, and audit that no object is publicly readable without a deliberate, logged exception.
  • Enable audit logging and log export to a separate account, because an attacker who compromises the main account will otherwise delete their own trail.

As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.

Which identity controls matter most on AWS, Azure and GCP?

Identity and access management decides how much damage any single mistake causes. Start with MFA for every human identity, then remove the standing access keys for the root, owner and subscription administrator accounts, because those credentials are permanent by design and are often left in a shared password manager or a CI config. Give every engineer a named identity with just-in-time or group-based roles, and every workload its own service identity rather than a borrowed person's. Review role assignments quarterly and delete anything unused for 60 days. On Azure, check the role assignments in Entra ID; on GCP, check the service account key list, because old keys stay valid until deleted.

How do I check my cloud setup against a known baseline?

Use the CIS benchmark for your provider, because it gives a concrete, versioned checklist rather than general advice. For AWS that is the CIS AWS Foundations Benchmark, for Azure the CIS Microsoft Azure Foundations Benchmark, and for GCP the CIS Google Cloud Platform Foundation Benchmark. A cloud security assessment of a small or mid-sized Indian deployment typically runs in the low hundreds of thousands of rupees and produces a prioritised list of deviations, each with the exact control reference and the console or API call that fixes it. Score the deviations rather than counting them: a public bucket holding customer data outranks fifty untagged resources.

What should be logged, and where should the logs go?

Log the control-plane events an attacker would need: changes to identity and access policy, creation of new credentials, changes to network rules, changes to storage permissions, and the enabling or disabling of logging itself. Keep those logs in a separate account or a dedicated log-analytics workspace that the workload administrators cannot delete, and set an organisation-level retention policy so the 180-day log retention requirement under the CERT-In directions is met without relying on anyone remembering. Enable the provider's own data access audit logs, because they capture reads of sensitive objects that control-plane logs never show.

The controls that decide whether a cloud account is defensible, and what each one blocks
ControlWhat it stopsHow to verify it
MFA on every human identityCredential theft and account takeoverExport the identity list and check the MFA column
No standing root or owner keysLong-lived credential abuseList the access keys and delete unused ones
Per-workload roles, no shared loginsPrivilege escalation through a shared accountMap each role to a named service or person
Private storage by defaultPublic exposure of buckets and blobsRun an open-permission scan across all regions
Private subnets and restricted ingressDirect internet exposure of workloadsReview the firewall and security group rules
Audit logging in a separate accountAnti-forensic deletion of the trailTry deleting a log group from the admin account
Log export and 180-day retentionMissing incident evidenceCheck the retention setting, not just the default

What are the frequently asked questions?

How do I secure my AWS, Azure or GCP cloud account?
Securing a cloud account means controlling identity first, then the resources that identity can reach. Enforce MFA for every human user, replace the long-lived root or owner keys with short-lived credentials, and give each workload its own role instead of sharing one powerful account. Restrict network access to private subnets, keep storage buckets and blob containers private, and turn on audit logging so that any change to policy is recorded. Indian companies in regulated sectors should treat the CERT-In empanelment and DPDP Act obligations as the baseline, because a cloud breach in India still has to be reported to CERT-In and to affected data principals.
What is the first thing to fix in a cloud account?
Identity. Remove the standing keys of the root or owner account, enforce MFA on every human user, and stop sharing one powerful credential across the team. Most cloud intrusions begin with a credential rather than an exploit.
Do I need a separate cloud security assessment for each provider?
Not usually. One assessment can cover all the providers you use, mapped to the CIS benchmark for each, with the findings ranked by business risk. What matters is that the report tells you what to fix first, not that it lists every deviation.
Is a public cloud automatically compliant with the DPDP Act?
No. The provider secures the infrastructure and the physical estate, but data localisation, retention, processor agreements, breach notice to data principals and the security safeguards themselves remain your responsibility under the DPDP Act 2023.
How often should cloud permissions be reviewed?
Quarterly for role assignments, and immediately whenever a person leaves or changes role. Automate it where you can, but review the exceptions yourself, because the stale permission that survives a quarterly sweep is usually the one no one owns.

Get a straight answer on this

Send us your provider list and a redacted IAM export, and we will return a prioritised CIS-gap list with fixed-price remediation steps.

Send us the details See pricing

Last reviewed: 24 October 2026. Information on this page is general guidance, not legal advice. Prices are indicative bands for a typical scope and are confirmed in a written quote before any work begins.