Cloud Security 2025: Best Practices for AWS, Azure, and GCP - Zero Trust, IAM, CSPM, and Shared Responsibility Model
Cloud Infrastructure Security: A Collection of Best Practices for AWS, Azure, and GCP
In the era of rapid digitalization and migration of critical resources to public cloud environments, traditional security paradigms based on a static network perimeter ("castle and moat") have become completely obsolete. This guide analyzes the evolution of responsibility models and key protection mechanisms within the Amazon Web Services, Microsoft Azure, and Google Cloud Platform ecosystems.
1. Evolution: From Shared Responsibility to "Shared Fate"
The foundation of cloud security is understanding where the provider's responsibility ends and the client's begins. While all major providers operate on a Shared Responsibility Model, their approaches differ significantly:
- AWS (Binary Model): AWS defines the division precisely. AWS is responsible for "Security OF the Cloud" (physical protection, virtualization). The client is fully responsible for "Security IN the Cloud" (OS configuration, firewalls, data encryption).
- Azure (Layered Model): Responsibility shifts dynamically depending on the service model (IaaS, PaaS, SaaS). However, responsibility for identity and data always remains with the client.
- GCP (Shared Fate): Google introduces the "Shared Fate" concept. The provider actively engages in the client's security by offering "opinionated architectures" and secure-by-default configurations to reduce the operational burden.
Zero Trust Architecture
Regardless of the provider, modern environments require the implementation of Zero Trust (NIST 800-207). The core assumption is a lack of default trust for any user or component, requiring continuous verification, least privilege, and microsegmentation.
2. Identity (IAM) – The New Security Perimeter
Identity has become the effective, and often only, security perimeter. IAM misconfigurations are the most common cause of security incidents.
IAM Model Comparison
| Feature | AWS IAM | Azure (Entra ID + RBAC) | GCP Cloud IAM | | : | : | : | : | | Structure | JSON documents, no traditional inheritance logic | Hierarchical (Mgmt Group -> Subscription -> Resource) | Tree-like (Organization -> Folder -> Project) | | Evaluation | Implicit Deny -> Explicit Allow -> Explicit Deny | Strict inheritance of permissions downwards | Policies at the Project level apply to all resources within | | Key Risks | Long-term Access Keys for IAM Users | Excessive inherited permissions; lack of role separation | Leakage of Service Account Keys (JSON files) | | Citations | | | |
Key Protection Strategies
- Conditional Access: Verification of context (device, location) before granting access. Azure Conditional Access and AWS Verified Access allow blocking access from unmanaged devices or untrusted networks.
- Elimination of Static Keys: Move towards temporary credentials (AWS STS, Azure Managed Identities, GCP Workload Identity Federation) instead of static key files.
- CIEM (Cloud Infrastructure Entitlement Management): Use tools to analyze excessive permissions and enforce "Rightsizing" to avoid "Toxic Combinations" that allow privilege escalation.
3. Network Security Engineering
Despite the dominance of Zero Trust, the network layer remains a critical element of Defense-in-Depth, protecting against lateral movement and exfiltration.
Firewalls: Statefulness vs. Statelessness
- AWS Security Groups: These are stateful, meaning return traffic for allowed ingress is automatically permitted. They are the primary line of defense.
- Azure NSG & ASG: Application Security Groups (ASG) allow for creating logical rules (e.g., "Allow AppServer to DBServer") without managing IP addresses.
- GCP Firewall Rules: Enable binding rules to machine identity (Service Accounts), which aligns closely with Zero Trust principles.
Data Exfiltration Protection
- GCP VPC Service Controls: Creates a logical perimeter around managed services (e.g., BigQuery, Storage). Even with stolen credentials, an attacker cannot exfiltrate data from outside the defined network perimeter.
- Private Connectivity (AWS/Azure): It is critical to use PrivateLink (AWS) or Private Link (Azure) so that traffic to PaaS services does not traverse the public internet.
4. Cryptography and Key Management (KMS)
The choice of key management strategy determines the level of control and data sovereignty.
- Platform Managed Keys: Generated and managed by the provider. The client lacks control over rotation or access policies.
- Customer Managed Keys (CMK): The client controls the key policy. This enables "Crypto-shredding"—deleting the key effectively renders the data unreadable.
- External Key Manager (EKM/HYOK): Keys are stored outside the cloud (e.g., on-premise HSM) for strict data sovereignty.
Critical Note for Azure: Always enable Soft Delete and Purge Protection on Key Vaults to prevent ransomware attacks from permanently deleting keys and secrets.
5. Security Posture Automation (CSPM)
The scale of cloud environments makes manual verification impossible. "Guardrails" must be applied to prevent drift.
-
Organizational Policies:
- AWS SCP: Blocks dangerous actions (e.g., disabling security services) at the root level, overriding local admin permissions.
- Azure Policy: Can block resource deployment in non-compliant regions to ensure Data Residency.
- GCP Constraints: Predefined constraints, such as disabling serial port access to VMs.
-
CSPM Tools: Native tools like AWS Security Hub, Microsoft Defender for Cloud, and GCP Security Command Center are essential for continuous compliance monitoring against benchmarks like CIS or NIST.
6. DevSecOps and Infrastructure as Code (IaC)
In the "Shift-Left" approach, security is integrated into CI/CD pipelines.
- IaC Scanning: Tools like Checkov, Prowler, or Trivy analyze configuration files (Terraform, ARM, K8s) before deployment to detect vulnerabilities.
- Supply Chain Security: Use Hardened Images (CIS Benchmarks) and scan container images in registries to prevent the deployment of vulnerabilities.
Summary and Strategic Recommendations
Building a resilient Multi-Cloud environment requires:
- Identity First: Investing in phishing-resistant MFA (FIDO2) and Least Privilege access yields the highest ROI.
- Automated CSPM: Automated detection and remediation of misconfigurations are essential for hygiene.
- Shared Fate Adoption: Leveraging provider-managed secure patterns and architectures rather than building custom security solutions from scratch.
Need Help with Secure Cloud Migration?
If you're planning migration to AWS, Azure, or GCP, need an audit of your current cloud infrastructure security, or want to implement Zero Trust Architecture – contact us. We'll help you design a secure multi-cloud architecture compliant with NIS2, GDPR, and ISO 27001 requirements.
What we offer
- Cloud Security Assessment - audit of IAM configuration, network segmentation, and encryption in AWS/Azure/GCP
- Zero Trust Architecture implementation - deploying NIST 800-207 model in cloud environments
- CSPM and compliance automation - configuration of AWS Security Hub, Microsoft Defender for Cloud, GCP Security Command Center
- Secure Cloud Migration - planning and execution of migration maintaining business continuity and regulatory compliance
- Multi-cloud security strategy - optimizing costs and security in heterogeneous environments (AWS+Azure+GCP)
- DevSecOps and IaC scanning - integrating security in CI/CD (Terraform, Checkov, Prowler)
📧 Contact a Cloud Security expert →
See Also - Related Topics
Architecture and Security Strategy
- Zero Trust Architecture - New Security Paradigm - How to implement Zero Trust model in AWS, Azure, and GCP environments
- NIS2 in Poland - Complete Guide - Cloud security requirements in the context of NIS2 directive and data sovereignty
- Security Operations Center (SOC): Comprehensive Guide for 2026 - Integrating SIEM/XDR with cloud logs for full visibility
Monitoring and Detection Technologies
- SIEM vs XDR - Which Solution to Choose? - Cloud security monitoring: CloudTrail, Azure Monitor, GCP Cloud Logging
- SOAR - Security Operations Automation - Automating response in cloud incidents (Lambda, Azure Functions, Cloud Functions)
- Threat Hunting - Advanced Guide - Proactive threat detection in multi-cloud infrastructure
FAQ - Frequently Asked Questions about Cloud Security
What is the Shared Responsibility Model and how does it differ between AWS, Azure, and GCP?
Shared Responsibility Model defines the division of security duties between the cloud provider (CSP) and the customer. AWS (Binary Model): Clear division of "Security OF the Cloud" (AWS responsible: physical infrastructure, hypervisor, network layer) vs "Security IN the Cloud" (customer responsible: OS, applications, data, firewall, encryption). AWS gives maximum control but requires the most expertise. Azure (Layered Model): Responsibility dynamically shifts depending on service model - IaaS (customer manages OS), PaaS (Azure manages OS), SaaS (Azure manages everything except data/users). Identity and data always remain the customer's responsibility. GCP (Shared Fate): Google promotes a "shared fate" model where the provider actively engages in customer security through "opinionated architectures" (secure-by-default configs), reducing operational burden. Key takeaway: Regardless of model, the customer is ALWAYS responsible for IAM, data, and application configuration - these are the most common sources of incidents.
What are the most common IAM misconfiguration errors in the cloud?
Most common IAM errors leading to incidents: 1. Excessive permissions (Overprivileged Identities): Granting AdministratorAccess/Owner instead of granular permissions. In AWS: IAM Users with PowerUserAccess, in Azure: overly broad roles at Management Group level (inheritance downward), in GCP: Service Accounts with Editor role across entire organization. 2. Long-term access keys: AWS Access Keys never rotated (should be replaced with STS Temporary Credentials), Azure Service Principal secrets in code (use Managed Identities), GCP Service Account JSON keys in repo (use Workload Identity Federation). 3. Toxic Combinations: Permission combinations allowing escalation - e.g., in AWS: iam:PutUserPolicy + iam:CreateAccessKey = ability to create an admin. 4. Missing MFA: Accounts with console access without Multi-Factor Authentication - phishing is the most common attack method. 5. No Conditional Access: Not enforcing context (device compliance, trusted IP) in Azure Entra ID or AWS Verified Access. Remediation: Use CIEM (Cloud Infrastructure Entitlement Management) tools like AWS IAM Access Analyzer, Azure Entra Permissions Management, GCP Policy Intelligence to identify and "rightsize" permissions.
What is CSPM and why is it crucial for NIS2 compliance?
CSPM (Cloud Security Posture Management) is a category of tools that automatically detect security misconfigurations and monitor compliance with benchmarks (CIS, NIST, ISO 27001). Why crucial for NIS2? The NIS2 Directive (Article 8) requires entities to maintain continuous security monitoring and vulnerability management - in cloud environments with dynamic scale (hundreds of AWS accounts/Azure subscriptions), manual auditing is impossible. How CSPM works: Scans resource configurations (S3 buckets, Security Groups, NSG, IAM policies) and detects risks like: unencrypted disks, public S3 buckets, overly permissive Security Groups (0.0.0.0/0 SSH), disabled CloudTrail/logging. Generates alerts and compliance reports. Tools: AWS Security Hub (integrates GuardDuty, Inspector, Macie), Microsoft Defender for Cloud (formerly Azure Security Center), GCP Security Command Center. External: Wiz, Orca Security, Prisma Cloud - offer unified view for multi-cloud. Best practice: Enable CSPM from day one of cloud migration - detects 80% of most common errors before they become incidents.
What's the difference between CMK and Platform Managed Keys?
Platform Managed Keys (PMK): Encryption keys automatically generated and managed by the cloud provider. Customer has no control over access policy, rotation, or key geography. Advantages: Free, zero operational overhead, automatic rotation. Disadvantages: No "crypto-shredding" capability (cryptographic data deletion by removing key), lack of sovereignty (key in provider infrastructure), doesn't meet some regulatory requirements (e.g., GDPR for sensitive data). Use cases: Non-critical data, dev/test environments. Customer Managed Keys (CMK): Key created by customer in KMS (AWS KMS, Azure Key Vault, GCP Cloud KMS). Customer controls access policy (who can use the key), rotation, and lifecycle. Advantages: Crypto-shredding (key deletion = data immediately unreadable), audit control (who and when used key in CloudTrail/Azure Monitor), compliance fulfillment (NIS2, HIPAA, GDPR). Disadvantages: Cost (AWS KMS: $1/key/month + $0.03/10k operations), requires management (rotation, backup). Use cases: Production data, PII, financial records, compliance-driven industries. HYOK/EKM (Bring Your Own Key): Key stored on-premise (e.g., HSM), provider never sees it - maximum sovereignty, but highest cost and complexity. For sensitive sectors (military, intelligence, banking).
How to implement Zero Trust Architecture in cloud environments?
Zero Trust in cloud is based on the principle "never trust, always verify" and requires implementation across 4 layers: 1. Identity: Zero Trust foundation. Enforce phishing-resistant MFA (FIDO2/WebAuthn, not SMS), use Conditional Access (Azure) / Verified Access (AWS) - block access from unmanaged devices/untrusted IPs, eliminate long-term keys - use temporary credentials (AWS STS AssumeRole, Azure Managed Identities, GCP Workload Identity). Apply Just-in-Time access (PIM in Azure) - admin permissions only on request. 2. Device: Enforce device compliance (Microsoft Intune, Jamf) - only managed devices can connect, use Device Trust (Chrome Enterprise, Azure AD joined). 3. Network: Microsegmentation - don't trust internal network. In GCP use Firewall Rules bound to Service Accounts (not IPs), in AWS/Azure: Application Security Groups (ASG) instead of traditional Security Groups. VPC Service Controls (GCP) or Private Link (AWS/Azure) - PaaS traffic doesn't leave private network. 4. Workload: End-to-end encryption, mutual TLS (mTLS) between services, Zero Trust Workload Security (Illumio, Google BeyondCorp). Tools: BeyondCorp (Google), Azure AD Conditional Access, AWS Verified Access, Palo Alto Prisma Access.
How to secure multi-cloud environments (AWS + Azure + GCP)?
Multi-cloud security strategy: 1. Unified Identity Plane: IAM centralization through Federation - use one Identity Provider (Azure Entra ID, Okta) as single source of truth, configure SAML/OIDC federation to AWS (AssumeRoleWithSAML), Azure (native), GCP (Workload Identity Federation). Benefit: Single point of user management, common Conditional Access policies, easier offboarding. 2. Centralized Logging and SIEM: Aggregate logs from all clouds into one SIEM (Splunk, Microsoft Sentinel, Chronicle) - AWS CloudTrail + Azure Activity Log + GCP Cloud Audit Logs. Risk without this: No visibility on cross-cloud attacks (e.g., lateral movement from AWS to GCP through stolen credentials). 3. Unified CSPM: Use tools covering all providers (Wiz, Orca, Prisma Cloud) instead of 3 separate ones (AWS Security Hub, Defender, SCC) - single compliance dashboard, uniform policy enforcement. 4. Network Isolation: Don't connect VPC/VNet between clouds without segmentation and inspection - use Cloud Interconnect (GCP) / ExpressRoute (Azure) / Direct Connect (AWS) with firewalling (Palo Alto VM-Series, Fortinet). 5. Consistent Tagging and Policy: Unified naming convention and tagging (CostCenter, Environment, DataClassification) for all clouds - enables automation and compliance tracking. 6. Cross-cloud Disaster Recovery: Don't assume one cloud is a "safe haven" - have backup strategy in another cloud (e.g., RDS snapshots AWS → Azure Blob cold storage).
What are key differences in network security between AWS, Azure, and GCP?
Network model comparison: AWS (Security Groups - Stateful): Security Groups are virtual firewalls at ENI (Elastic Network Interface) level. Stateful = automatic return traffic allowance. Network ACLs are stateless (must manually allow response), rarely used as fallback. VPC Flow Logs for traffic monitoring. Private Link for AWS service access without internet. Azure (NSG + ASG): Network Security Groups (NSG) also stateful, but Application Security Groups (ASG) allow logical VM grouping (e.g., "WebServers", "DBServers") and writing rules without IPs ("Allow ASG:WebServers to ASG:DBServers port 3306"). Azure Firewall for central inspection (OSI Layer 7). Private Endpoints for PaaS services. GCP (Firewall Rules + VPC Service Controls): Firewall Rules can be bound to Service Accounts instead of IPs - closest to true Zero Trust (firewall at identity level, not network). VPC Service Controls - logical perimeter around managed services (BigQuery, Storage) - even with stolen credentials, can't exfiltrate data from outside defined perimeter. Hierarchical Firewall Policies at organization/folder level. Key differences: AWS/Azure = traditional model with IP-based rules + Private connectivity, GCP = most advanced identity-based model + Service Controls. Multi-cloud best practice: For each cloud use native mechanisms (don't try to "unify" through third-party firewall unnecessarily).
How to automate security in DevOps (DevSecOps)?
Shift-Left Security = integrating security at every CI/CD stage, not just at the end. 1. Pre-Commit (IDE): IDE linters and plugins detecting secrets (git-secrets, TruffleHog) - block credential commits to repo, static code analysis (SonarQube, Semgrep) detecting vulnerabilities (SQL injection, XSS). 2. Code Repository (GitHub/GitLab): Secret Scanning (GitHub Advanced Security, GitGuardian) - automatic detection of leaked API keys/passwords in commits/PRs, Dependency Scanning (Dependabot, Snyk) - detecting library vulnerabilities (npm, pip, Maven). 3. CI Pipeline (Build): IaC Scanning (Checkov, Terraform Sentinel, CloudFormation Guard) - block deployment of unencrypted S3/disks, Security Groups 0.0.0.0/0 SSH, missing MFA delete on buckets, Container Scanning (Trivy, Anchore, AWS ECR/Azure ACR built-in) - detecting CVEs in images before registry push. 4. CD Pipeline (Deploy): Policy-as-Code (OPA - Open Policy Agent, Azure Policy, AWS Config Rules) - enforce guardrails (e.g., "deploy only to approved regions", "all VMs must have CostCenter tag"), DAST (Dynamic Application Security Testing) - OWASP ZAP, Burp Suite scan running application in staging. 5. Runtime (Production): Runtime Security (Falco, Aqua, Sysdig) - detects workload anomalies (unauthorized process execution, file modification), CSPM continuous - AWS Security Hub/Defender for Cloud/SCC scan production 24/7. End-to-end tools: GitHub Advanced Security, GitLab Ultimate, Snyk, Aqua Security, Prisma Cloud.
Do small companies need CSPM and advanced cloud security mechanisms?
Yes, even small companies need basic CSPM, because: 1. Compliance requires it (NIS2/GDPR): NIS2 covers companies ≥50 employees or ≥€10M turnover - many SMBs are subject. Requirement: continuous security monitoring and vulnerability management. No CSPM = no compliance evidence during audit. 2. Default configurations are insecure: Out-of-the-box cloud is insecure by default (S3 buckets can be public, Security Groups can have 0.0.0.0/0, logging is disabled). Typical IT admin doesn't know all security controls. CSPM detects these errors automatically. 3. Data breach risk is high: Ransomware-as-a-Service attacks everyone. Leaked S3 bucket with customer data = GDPR fine 4% of global turnover + reputation loss. 4. Low cost vs risk: AWS Security Hub: $0.0010/check (first 10k checks/month free), Microsoft Defender for Cloud: free tier for basic posture, GCP Security Command Center: standard tier free. Alternative: External security audits cost more ($5-20k/audit) and are one-time. Solutions for SMB: Minimal configuration (free): Enable AWS Security Hub (free tier), Azure Defender for Cloud (free tier), GCP SCC standard + enable logging (CloudTrail/Azure Monitor/Cloud Logging) + configure alerts on critical events (IAM changes, Security Group changes, S3 bucket public). Managed Security (paid): Outsourcing to MSSP offering CSPM-as-a-Service (monitoring + remediation) for $500-2000/month. Bottom line: For small companies, CSPM isn't a luxury, it's baseline - lacking it is like driving without seatbelts.
How to manage cloud security costs?
Cloud security generates costs at 4 levels - all can be optimized: 1. Tooling costs: CSPM: AWS Security Hub ($0.001/check after 10k free tier), Defender for Cloud ($15/server/month for advanced), Wiz/Orca ($$$ enterprise). Optimization: For small environments use free tiers of native tools instead of external vendors, consolidate tools - one SIEM instead of separate per-cloud, disable unused security services (e.g., GuardDuty in regions where you have no resources). 2. Data/Logging costs: CloudTrail/Azure Monitor Logs/GCP Cloud Logging generate gigabytes of logs daily. 1-year retention in S3/Blob/GCS = thousands USD/month. Optimization: Short-term retention (90 days) in hot tier, long-term (1-7 years for compliance) in cold/archive tier (10x cheaper), filter logs - don't log everything (e.g., S3 data events only for sensitive buckets), use log aggregation (ship to Splunk/Sentinel only alerts, not raw logs). 3. Encryption (KMS) costs: AWS KMS: $1/CMK/month + $0.03/10k API calls. 100 keys + million operations = $130/month. Optimization: Reuse CMKs (one key for multiple resources of same type), use envelope encryption (data key wrapping) instead of direct KMS calls per-operation, for non-critical data use Platform Managed Keys (free). 4. Personnel costs: Cloud Security Engineers ($100-200k/year) are expensive. Optimization: Automation (SOAR, auto-remediation in Security Hub/Defender), MSSP outsourcing for Tier 1/2 (keep only Tier 3 strategic in-house), training existing IT team (AWS/Azure/GCP certifications) instead of hiring new headcount. Security ROI: Data breach cost per IBM 2024: average $4.88M. Cost of well-configured CSPM + IAM + encryption: $10-50k/year. ROI = 100x.
What are best practices for disaster recovery in the cloud?
Cloud DR (Disaster Recovery) requires strategy at 4 levels: 1. RTO/RPO Definition: RTO (Recovery Time Objective) - maximum downtime (how long to recover?), RPO (Recovery Point Objective) - maximum data loss (how old data is acceptable?). Tier 1 (critical): RTO <1h, RPO <15min = expensive (multi-region active-active). Tier 2 (important): RTO <4h, RPO <1h = moderate (automated failover). Tier 3 (non-critical): RTO <24h, RPO <24h = cheap (manual restore from backups). 2. Backup Strategy (3-2-1 Rule): 3 copies of data (production + 2 backups), 2 different media (e.g., disk + tape/cold storage), 1 copy off-site (different region/cloud). In cloud: Automated snapshots (EBS/Azure Disks/GCP Persistent Disks) every 6-12h, cross-region replication (S3 CRR, Azure GRS, GCP dual-region buckets), immutable backups (AWS Backup Vault Lock, Azure Immutable Blobs) - ransomware protection. 3. Multi-Region Architecture: Active-Passive: Production in one region, standby in another (Route53/Traffic Manager failover). Cost: Medium, RTO: 15-60 min. Active-Active: Production in 2+ regions simultaneously (Global Load Balancer). Cost: High (doubled resources), RTO: <5 min. Pilot Light: Minimal infrastructure in DR region (only database replicated), rest starts on-demand. Cost: Low, RTO: 1-4h. 4. DR Testing: Minimum 2x/year full failover test (not just backup restore!). Tabletop Exercise: Disaster simulation (e.g., "entire us-east-1 region down"), team goes through procedures. Automated testing: AWS Resilience Hub, Azure Site Recovery drills. Common mistakes: DR plan only on paper (never tested), backups in same region as production (total loss in regional outage), no offline documentation (how to failover if can't access cloud wiki?). Best practice: One backup copy in different cloud (AWS → Azure Blob Archive) for maximum resilience.
About the Author
Dyrektor ds. Technologii w SecurHub.pl
Doktorant z zakresu neuronauki poznawczej. Psycholog i ekspert IT specjalizujący się w cyberbezpieczeństwie.
Powiązane artykuły
NIS2 w Polsce 2025: 5 prawd, które zmienią wszystko w Twojej firmie - Kompletny przewodnik
Dyrektywa NIS2 to nie kolejne RODO - to rewolucja w cyberbezpieczeństwie z osobistą odpowiedzialnością zarządu i karami do 100 mln PLN. Odkryj, czy Twoja firma jest objęta regulacją i jak uniknąć dotkliwych sankcji.
MSSP 2025: 4 Pułapki Przy Wyborze Dostawcy Managed Security (I Dlaczego Własny SOC Kosztuje 5x Więcej)
Własny SOC 24/7 wymaga 5-6 analityków na etat i kosztuje 5x więcej niż myślisz. Odkryj 4 krytyczne błędy przy wyborze MSSP, różnicę MSP vs MSSP, prawdę o "15 minutach reakcji" i dlaczego outsourcing nie zwalnia zarządu z odpowiedzialności NIS2.
Security Operations Center (SOC): Kompleksowy Przewodnik na 2026 | Budowa i Wdrożenie
Poznaj wszystko o Security Operations Center (SOC) - od budowy zespołu, przez technologie SIEM/XDR/SOAR, wymogi NIS2, modele wdrożenia, aż po przyszłość z AI. Praktyczny przewodnik dla CISO i menedżerów IT.
Komentarze
Ładowanie komentarzy...