Cloud Security in 2025: AWS, Azure, and GCP Hardening Guide

Executive Summary

Cloud adoption has fundamentally changed the security perimeter. The traditional castle-and-moat model — protect the network edge, trust everything inside — fails in cloud environments where infrastructure is API-driven, identities are the new perimeter, and misconfigurations can expose sensitive data to the public internet in seconds.

This guide provides actionable hardening guidance for AWS, Azure, and GCP environments. It is written for cloud architects, security engineers, and DevOps teams who are responsible for securing cloud infrastructure. Each section covers controls applicable across all three platforms, with platform-specific implementation details.

The controls in this guide align with CIS Benchmarks (v3.0 for AWS, v2.0 for Azure, v1.3 for GCP), NIST SP 800-53, and ISO 27001:2022 Annex A.

Chapter 1: Understanding the Shared Responsibility Model

The most important concept in cloud security is also the most frequently misunderstood.

Shared Responsibility

The critical implication: Cloud providers secure the infrastructure. You are responsible for what you build on it, how you configure it, who can access it, and what data you store in it.

The majority of cloud security incidents are caused by customer misconfiguration — not provider vulnerabilities.

Chapter 2: Identity and Access Management

Identity is the primary attack surface in cloud environments. Compromised credentials and over-permissioned roles are the leading cause of cloud security incidents.

Principle of Least Privilege

Every identity — human or machine — should have only the permissions required to perform its specific function, for the minimum time required.

AWS implementation:

• Use IAM policies with specific Allow statements — never use wildcards (*) in production
• Use SCPs (Service Control Policies) at the AWS Organizations level to enforce guardrails
• Use IAM Access Analyzer to identify unused permissions and external access
• Replace long-lived IAM access keys with IAM Identity Center for human access, and IAM roles for application access

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::company-data-bucket/*"
    }
  ]
}

Azure implementation:

• Use Azure RBAC with built-in roles wherever possible; custom roles for edge cases
• Implement Privileged Identity Management (PIM) — no persistent privileged assignments
• Use Conditional Access policies to enforce MFA and device compliance
• Use Managed Identities for Azure resources — eliminates service account credentials

GCP implementation:

• Use predefined IAM roles; avoid primitive roles (Owner, Editor, Viewer at project level)
• Implement Workload Identity Federation for service-to-service authentication
• Use VPC Service Controls to restrict API access to trusted networks
• Review IAM recommendations from Security Command Center

Multi-Factor Authentication

Enforce MFA universally. No exceptions for service accounts or “low-risk” users.

• AWS: MFA policy in IAM; SCP to deny all actions except MFA-related when no MFA session
• Azure: Conditional Access policy requiring MFA for all users; phishing-resistant MFA (FIDO2/hardware tokens) for privileged roles
• GCP: Organisation policy: iam.allowedPolicyMemberTypes + enforce MFA in Cloud Identity

Eliminating Long-Lived Credentials

Credential detection: Enable GitHub Advanced Security secret scanning on all repositories. AWS, Azure, and GCP all have partner integrations that revoke detected credentials automatically.

Chapter 3: Network Security

Defence in Depth for Cloud Networks

Cloud networks should implement multiple layers of controls:

Layer 1 — Perimeter

• Web Application Firewall (WAF) for all internet-facing applications
• DDoS protection (AWS Shield, Azure DDoS Protection, GCP Cloud Armor)
• Only expose services that must be publicly accessible

Layer 2 — Network segmentation

• Separate VPCs/VNets for production, staging, and development
• Subnet segmentation within VPCs: public subnets for load balancers only, private subnets for compute, isolated subnets for databases
• No direct internet access from compute or database tiers

Layer 3 — Host-level controls

• Security Groups / NSGs / Firewall Rules: deny-all by default, explicit allow
• Never allow 0.0.0.0/0 inbound on management ports (SSH 22, RDP 3389)
• Use bastion hosts or, better, session manager/bastion-less access

Platform-Specific Network Controls

AWS:

VPC Design:
├── Public Subnet (Load Balancer, NAT Gateway)
├── Private Subnet (EC2, ECS, Lambda)
└── Isolated Subnet (RDS, ElastiCache)

Security Groups: stateful, per-resource
NACLs: stateless, subnet-level, backup layer
VPC Flow Logs: enable in all VPCs → S3/CloudWatch

Azure:

Hub-Spoke topology (recommended):
├── Hub VNet (Azure Firewall, Bastion, VPN/ER Gateway)
└── Spoke VNets (workload-specific)

NSGs: applied at subnet AND NIC level
Azure Firewall: centralised egress filtering
Private Endpoints: for all PaaS services (SQL, Storage, Key Vault)
NSG Flow Logs → Log Analytics

GCP:

VPC Networks (global, not regional):
├── Shared VPC for centralised control
├── Firewall Rules: ingress/egress, tag-based
└── Private Google Access: PaaS without internet

Cloud Armor: WAF + DDoS at load balancer layer
Cloud NAT: outbound internet for private instances
VPC Flow Logs: per subnet, configurable sampling rate

Chapter 4: Logging, Monitoring, and Threat Detection

You cannot defend what you cannot see. Comprehensive logging is foundational to security operations.

What to Log

Centralised Log Management

All logs should flow to a centralised, tamper-resistant log store:

• AWS: CloudTrail → S3 (separate security account) + CloudWatch Logs; consider Amazon Security Lake
• Azure: All diagnostic settings → Log Analytics Workspace; Microsoft Sentinel as SIEM
• GCP: Cloud Logging → centralised log bucket (locked retention); Chronicle SIEM

Key principle: Log storage should be in a separate account/project/subscription from production. An attacker who compromises your production environment should not be able to modify audit logs.

Threat Detection Services

AWS GuardDuty: Analyses CloudTrail, VPC Flow Logs, and DNS logs using ML and threat intelligence. Detects: credential compromise, cryptomining, C2 communication, instance metadata API abuse.

Microsoft Defender for Cloud: Provides security recommendations (Secure Score) + threat detection across VMs, containers, databases, app services, Key Vault, and storage.

GCP Security Command Center: Vulnerability detection, threat detection (Event Threat Detection), and compliance posture management.

Alerting

Define critical alerts that require immediate response:

• Root/Global Admin account used for any action
• MFA disabled on any user account
• New IAM user or service account with admin permissions created
• Security monitoring service disabled (GuardDuty, Defender, SCC)
• Large data egress from storage (>1GB in a single request)
• Console login from an unfamiliar country
• Mass resource deletion

Chapter 5: Data Protection and Encryption

Encryption at Rest

AWS:

• S3: Enable S3 server-side encryption (SSE-S3 or SSE-KMS) — use bucket policies to deny unencrypted uploads
• EBS volumes: Enable encryption by default at the account level
• RDS: Enable encryption at rest (must be enabled at creation; cannot enable later without snapshot restore)
• Secrets: AWS Secrets Manager or Parameter Store (SecureString) — never environment variables or config files

Azure:

• All Azure storage is encrypted by default (AES-256). For compliance, use Customer-Managed Keys (CMK) via Azure Key Vault
• Azure SQL: Enable Transparent Data Encryption (TDE) with CMK
• Key Vault: Enable soft delete (90 days), purge protection, private endpoint

GCP:

• All data encrypted by default with Google-managed keys
• CMEK (Customer-Managed Encryption Keys) via Cloud KMS for compliance requirements
• Secret Manager for credentials and secrets — not environment variables or Compute Engine metadata

Encryption in Transit

• Enforce TLS 1.2 minimum across all services; TLS 1.3 preferred
• Disable legacy protocols: SSLv3, TLS 1.0, TLS 1.1
• Enforce HTTPS on all load balancers and application endpoints
• Use private endpoints/service endpoints for PaaS services — eliminate transit over public internet

Data Classification and Access Controls

Implement data classification before designing access controls:

Chapter 6: Vulnerability Management and Patch Management

VM Instances and Container Images

• Enable automatic OS patch management (AWS Systems Manager Patch Manager, Azure Update Manager, GCP OS Config)
• Scan all container images on build and before deployment (Trivy, Snyk, Amazon ECR scanning, Azure Defender for Containers, Artifact Analysis)
• Implement a 72-hour SLA for Critical CVE patches on internet-facing systems

Cloud Configuration Vulnerability Management

Cloud misconfigurations are not traditional vulnerabilities but are equally dangerous:

• Run cloud security posture management (CSPM) tools continuously
• AWS Security Hub: aggregates findings from GuardDuty, Inspector, Config, Macie, and third-party tools
• Azure Defender for Cloud: Secure Score + recommendations mapped to compliance frameworks
• GCP Security Command Center: continuous posture assessment

Set remediation SLAs for CSPM findings:

• Critical misconfigurations (public S3 bucket, no MFA on root): 24 hours
• High: 7 days
• Medium: 30 days

Chapter 7: Compliance and Governance

Cloud Governance Controls

AWS:

• AWS Organizations: centralised account management + SCPs for guardrails
• AWS Config: tracks resource configuration changes; Config Rules for compliance
• AWS Control Tower: pre-built landing zone with guardrails for multi-account setup
• AWS Security Hub: compliance dashboards for CIS, PCI DSS, NIST, AWS Foundational

Azure:

• Azure Management Groups: governance hierarchy above subscriptions
• Azure Policy: enforce and audit resource configurations at scale
• Azure Blueprints: package policies, RBAC, and Resource Manager templates as deployable units
• Microsoft Defender for Cloud: compliance dashboard for ISO 27001, PCI DSS, NIST, CIS

GCP:

• Organisation Policies: enforce constraints on GCP resources across the organisation
• Cloud Asset Inventory: track all assets and their configurations
• Policy Intelligence: IAM recommendations, access transparency
• Assured Workloads: data sovereignty controls for regulated industries

Compliance Frameworks and Cloud Mapping

Chapter 8: Multi-Cloud Security Considerations

Organisations operating across multiple cloud providers face additional complexity:

Identity Federation

Rather than managing separate identity stores in each cloud, federate authentication to a central IdP (Okta, Azure AD, Google Identity):

• AWS: IAM Identity Center with external IdP SAML/OIDC
• Azure: Guest accounts or B2B federation from external IdP
• GCP: Cloud Identity with external IdP SSO

Unified Visibility

Third-party CSPM tools provide cross-cloud visibility:

• Wiz, Orca Security, Palo Alto Prisma Cloud — normalise findings across AWS, Azure, GCP
• Consider these for organisations with significant workloads in multiple clouds

Network Connectivity

Use private connectivity between clouds where possible:

• AWS Direct Connect + Azure ExpressRoute + GCP Cloud Interconnect for private cloud-to-cloud traffic
• Avoid sending sensitive data between clouds over the public internet

Conclusion and Hardening Checklist

Quick-Start Hardening Checklist

Identity and Access

• MFA enforced for all users (no exceptions)
• Root/Global Admin accounts locked with hardware MFA, used only for break-glass scenarios
• No long-lived access keys; use SSO and role assumption
• Privileged access managed via PIM/JIT with approval and time limits
• Access reviews conducted quarterly

Network

• No management ports (22, 3389) open to 0.0.0.0/0
• VPC/VNet segmented: public, private, isolated tiers
• All PaaS services accessed via private endpoints
• WAF deployed for all internet-facing applications
• VPC Flow Logs enabled in all regions

Logging and Detection

• CloudTrail/Activity Log/Cloud Audit Logs enabled in all regions
• Logs shipped to separate, tamper-resistant account/project
• Threat detection enabled (GuardDuty/Defender/SCC) in all regions
• Alerts configured for critical events
• SIEM integrated with cloud logs

Data Protection

• All data encrypted at rest (CMK for regulated data)
• TLS 1.2+ enforced; legacy protocols disabled
• No secrets in code, environment variables, or config files
• Secrets managed via Secrets Manager / Key Vault / Secret Manager
• No public storage buckets (unless intentionally public static content)

Governance

• CSPM tool running continuously
• Patch management automated with SLA tracking
• Cloud security posture reviewed monthly
• Annual penetration test of cloud environment

CyberneticsPlus provides cloud security assessments, hardening implementations, and ongoing posture management across AWS, Azure, and GCP. Contact us to schedule a cloud security assessment.