Moving to the cloud does not automatically make your data more secure. While cloud providers handle physical infrastructure security, the shared responsibility model means you are responsible for securing your data, identities, applications, and configurations. Most cloud breaches result from customer misconfigurations, not provider vulnerabilities.
Identity and Access Management
Use the principle of least privilege. Every user and service should have only the permissions required for their specific role. Avoid attaching admin policies to general users. In AWS, use IAM policies with specific resource ARNs. In Azure, use role-based access control (RBAC). In GCP, use predefined roles rather than primitive roles.
Enable MFA for all accounts. Root/owner accounts must have MFA enabled immediately — a compromised root account gives attackers complete control over your entire cloud environment. Use hardware security keys for root accounts.
Audit and rotate credentials regularly. Service account keys, API tokens, and access keys should be rotated every 90 days. Monitor for unused credentials and deactivate them. Never embed credentials in source code — use secrets managers (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager).
Data Protection
Encrypt everything. Enable server-side encryption for all storage services (S3, Azure Blob, GCS). Use customer-managed keys (CMK) for sensitive data rather than provider-managed keys. Encrypt database instances. Enable encryption in transit for all connections.
Secure your storage. The most common cloud breach is a publicly accessible storage bucket. Block public access at the account level (S3 Block Public Access, Azure Storage firewall). Audit bucket permissions regularly. Enable access logging to track who accesses what.
Implement data classification. Tag resources by sensitivity level. Apply different security controls based on classification. Use data loss prevention (DLP) tools to detect sensitive data in unexpected locations.
Network Security
Use VPCs and subnets wisely. Isolate workloads in separate VPCs or virtual networks. Place databases and backend services in private subnets with no direct internet access. Use NAT gateways for outbound internet access from private subnets.
Minimise attack surface. Security groups and network ACLs should follow the principle of least privilege — open only the ports you need, to the specific sources that need them. Never use 0.0.0.0/0 for SSH or RDP access.
Use private endpoints. Access cloud services (S3, databases, key management) through private endpoints rather than the public internet. This keeps traffic within the cloud provider’s network.
Monitoring and Detection
Enable cloud-native logging. AWS CloudTrail, Azure Activity Log, and GCP Cloud Audit Logs record every API call made in your account. Enable these on day one and send logs to a centralised, tamper-proof location.
Set up alerts. Configure alerts for root account logins, IAM policy changes, security group modifications, public resource creation, and large data transfers. Use cloud-native tools (GuardDuty, Defender for Cloud, Security Command Center) for automated threat detection.
Implement CSPM. Cloud Security Posture Management tools continuously audit your configurations against security benchmarks (CIS, NIST). They catch misconfigurations before attackers do.
Backup and Recovery
Automate backups. Enable automated snapshots for databases and compute instances. Store backups in a different region. Test restoration procedures quarterly.
Protect against ransomware. Use versioning on storage buckets. Enable MFA delete for critical S3 buckets. Maintain immutable backups that cannot be encrypted or deleted by a compromised account.
Compliance
Ensure your cloud deployment meets relevant compliance requirements — DPDP Act for Indian data, PCI DSS for payment data, HIPAA for health data. Use cloud compliance tools to continuously monitor compliance posture. Document your controls and maintain audit trails.
