Cloud security in AWS, Azure, and GCP operates under shared responsibility model that most organizations fundamentally misunderstand until they experience their first breach. Cloud providers secure infrastructure-physical data centers, hypervisors, and network backbone. You secure everything else-data, applications, identities, and configurations. This division sounds simple in theory but proves dangerously ambiguous in practice.
The reality is that cloud providers have no incentive to clearly communicate where their responsibility ends and yours begins because the ambiguity protects them legally while shifting security burden to customers. Marketing materials showcase cloud security capabilities creating false sense of security. Meanwhile, misconfigured S3 buckets expose millions of customer records, overprivileged IAM roles enable lateral movement, and unencrypted databases leak sensitive data-all customer responsibility, not cloud provider failure.
Understanding precisely what you must secure versus what provider handles determines whether your cloud infrastructure remains secure or becomes next data breach headline. The shared responsibility model isn’t abstract security concept-it’s legal contract defining who’s liable when things go wrong.
At Ambacia, we place cloud security engineers across Europe who implement security controls protecting AWS, Azure, and GCP deployments. We’ve seen which misunderstandings cause breaches and which practices prevent them.
Key Takeaways
Shared responsibility model shifts liability to customers – Cloud providers secure infrastructure layer but accept no responsibility for customer data breaches caused by misconfigured services, weak access controls, or unencrypted data; understanding exact boundary prevents dangerous assumptions.
Identity and Access Management is entirely your responsibility – Cloud providers offer IAM tools but don’t configure them; overprivileged roles, lack of MFA, long-lived credentials, and excessive permissions cause majority of cloud security incidents.
Default configurations prioritize convenience over security – S3 buckets aren’t private by default until you make them private; security groups allow all traffic until you restrict them; encryption isn’t enabled automatically; assuming secure defaults leads to exposure.
Compliance is shared but customer bears audit burden – Cloud providers maintain infrastructure certifications (SOC 2, ISO 27001) but customer must implement and demonstrate controls for data security, access management, and configuration compliance.
Multi-cloud increases complexity exponentially – Each provider has different security services, IAM models, and configuration paradigms; managing consistent security across AWS, Azure, and GCP requires understanding three distinct security frameworks simultaneously.
What Cloud Providers Actually Secure
Infrastructure layer protection
Cloud providers secure physical infrastructure and foundational services that customers can’t directly access or control.
Physical security of data centers including perimeter controls, access restrictions, surveillance, and environmental controls. Customers never enter data centers or touch physical hardware.
Hypervisor security preventing virtual machines from accessing other customers’ VMs. Isolation between tenants is provider’s responsibility and fundamental to cloud security model.
Network infrastructure including backbone routers, switches, and DDoS protection at provider network edge. Massive DDoS attacks get absorbed before reaching customer resources.
Hardware maintenance, patching, and lifecycle management. Providers replace failing disks, update firmware, and manage hardware without customer involvement.
Platform services security
Managed services include some security features but responsibility boundary varies by service abstraction level.
RDS, Azure SQL, Cloud SQL handle database patching, backup management, and high availability. However, customer must configure encryption, access controls, and network restrictions.
Lambda, Azure Functions, Cloud Functions abstract server management. Provider patches underlying OS but customer secures function code and manages IAM permissions.
Container services like EKS, AKS, GKE provide Kubernetes control plane security but customer secures worker nodes, container images, and pod security policies.
Serverless services shift more security responsibility to provider but don’t eliminate customer responsibilities around data protection and access management.
What the marketing doesn’t emphasize
Cloud provider marketing emphasizes robust security without highlighting customer responsibilities prominently.
Compliance certifications (SOC 2, ISO 27001, PCI DSS, HIPAA) apply to provider infrastructure, not customer deployments. Customer must implement additional controls for compliance.
Security features are available but not enabled by default. Encryption, logging, monitoring, and access controls exist but require explicit customer configuration.
Advanced security services like GuardDuty, Security Center, or Security Command Center cost extra money and aren’t included in base compute/storage pricing.
Breach disclosure shows pattern: provider emphasizes infrastructure security while attributing breaches to customer misconfiguration or credential compromise.
Why Misconfigurations Cause Most Breaches
The S3 bucket problem
S3 bucket misconfigurations have exposed billions of records across thousands of companies. This isn’t theoretical risk-it’s documented epidemic.
Public read access to buckets containing sensitive data. Developers testing with public access forget to restrict before production deployment. Automated scanners find exposed buckets within hours.
Bucket policies granting overly broad permissions. Wildcards in policy statements accidentally grant access to unintended principals. Complex policy language makes mistakes easy.
Missing encryption at rest. S3 doesn’t encrypt by default. Customer must explicitly enable encryption. Unencrypted buckets expose data if credentials compromise or misconfiguration occurs.
Access logging disabled means breaches go undetected. No logs means no evidence of unauthorized access, preventing forensic investigation and compliance demonstration.
Security group and network ACL mistakes
Network security in cloud requires explicit configuration. Default settings often insecure or overly permissive.
Security groups allowing 0.0.0.0/0 on sensitive ports. Opening RDP (3389), SSH (22), or database ports (3306, 5432, 1433) to internet invites credential attacks.
Missing egress restrictions. Focus on ingress rules while ignoring egress means compromised instances can exfiltrate data or communicate with command-and-control servers.
VPC misconfigurations exposing internal services. Public subnets containing resources that should be internal. Missing NAT gateways forcing resources into public subnets.
Network ACLs conflicting with security groups creating confusion about actual access. Layered controls should reinforce each other, not contradict.
IAM overprivilege epidemic
Principle of least privilege violated constantly across cloud deployments. Excessive permissions expand blast radius when credentials compromise.
Administrator access granted liberally to developers, contractors, and automated processes. Full admin rights unnecessary for 95% of use cases but granted for convenience.
Wildcard permissions in policies. Using * for resources or actions grants far more access than intended. Specific ARNs and action lists more secure but require more effort.
Long-lived credentials instead of temporary. Access keys created years ago still valid. Compromised credentials provide persistent access.
Service accounts with excessive permissions. EC2 instance roles, Lambda execution roles, and service accounts often have far more permissions than actually needed.
Common Cloud Misconfigurations and Impact
| Misconfiguration | AWS Example | Azure Example | GCP Example | Breach Impact |
| Public storage | S3 bucket with public read | Storage account public access | Cloud Storage bucket AllUsers | Data exposure, compliance violation |
| Open network | Security group 0.0.0.0/0 on 22 | NSG allow any source on 3389 | Firewall rule 0.0.0.0/0 on 22 | Unauthorized access, ransomware |
| Missing encryption | Unencrypted EBS volume | Unencrypted managed disk | Unencrypted persistent disk | Data breach, compliance failure |
| Overprivileged IAM | IAM user with AdministratorAccess | User with Owner role | User with Owner binding | Lateral movement, data exfiltration |
| Disabled logging | CloudTrail disabled | Activity Log not configured | Cloud Audit Logs disabled | Undetected breaches, no forensics |
| No MFA | Root account without MFA | Admin without MFA | Super admin without 2FA | Account takeover, full compromise |
What You Must Secure in Every Cloud
Identity and Access Management
IAM is entirely customer responsibility across AWS, Azure, and GCP. Poor IAM configuration causes majority of cloud security incidents.
Multi-factor authentication must be enforced for all users, especially administrators. Password-only authentication is insufficient in 2025.
Least privilege access through carefully scoped IAM policies. Start with minimal permissions and add as needed rather than granting broad access and hoping to restrict later.
Regular access reviews identifying unused permissions and stale accounts. People change roles, contractors leave, projects end-permissions must be updated accordingly.
Service account management with short-lived tokens instead of long-lived credentials. AWS IAM roles for EC2, Azure managed identities, and GCP service accounts provide temporary credentials.
Conditional access policies based on location, device posture, and risk signals. Azure AD conditional access, AWS IAM conditions, and GCP Context-Aware Access provide context-based authorization.
Data encryption
Cloud providers offer encryption services but customer must enable and manage encryption.
Encryption at rest for all sensitive data. S3 server-side encryption, Azure Storage Service Encryption, and GCP encryption by default (recently enabled) protect data on disk.
Encryption in transit using TLS/SSL for all network communications. Load balancers, CloudFront, Azure Front Door, and Cloud CDN terminate TLS but internal traffic should also encrypt.
Key management through customer-managed keys when regulatory requirements demand. AWS KMS, Azure Key Vault, and GCP Cloud KMS allow customer control over encryption keys.
Encryption key rotation policies ensure cryptographic hygiene. Automatic rotation reduces operational burden while maintaining security.
Database encryption including transparent data encryption (TDE) for SQL databases and encryption for NoSQL stores. RDS encryption, Azure SQL encryption, and Cloud SQL encryption must be explicitly enabled.
Network security
Cloud networks are software-defined requiring explicit security configuration. Default network behavior often insecure.
Virtual Private Clouds (VPC) provide network isolation but customer must configure subnets, routing, and access controls correctly.
Security groups and network ACLs control traffic flow. Default-deny approach where you explicitly allow required traffic is more secure than default-allow.
Private subnets for resources that don’t need internet access. Public subnets should contain only load balancers, NAT gateways, and bastion hosts.
VPN or Direct Connect for hybrid cloud connectivity. AWS Direct Connect, Azure ExpressRoute, and GCP Cloud Interconnect provide private connections to on-premise networks.
Web application firewalls (WAF) protect against application-layer attacks. AWS WAF, Azure Application Gateway WAF, and Google Cloud Armor should front public web applications.
How IAM Differs Across Cloud Providers
AWS IAM complexity
AWS Identity and Access Management uses unique concepts requiring significant learning investment.
IAM users, groups, and roles serve different purposes. Users for human access, groups for permission management, roles for service-to-service access and temporary credentials.
Policy types include identity-based, resource-based, permission boundaries, and service control policies. Understanding which policy applies when requires deep knowledge.
Permission evaluation logic follows specific precedence rules. Explicit deny overrides allow. Permission boundaries limit maximum permissions. SCPs constrain entire accounts.
Cross-account access through IAM roles enables secure resource sharing without credential sharing. Assume role provides temporary credentials for cross-account operations.
Azure AD integration
Azure integrates Active Directory for identity creating unified identity across on-premise and cloud.
Azure AD provides identity services while Azure RBAC provides resource access management. Two systems working together creates powerful but complex model.
Managed identities for Azure resources provide automatic credential management. System-assigned and user-assigned identities eliminate need to manage credentials.
Conditional access policies provide context-aware access decisions. Block access from risky locations, require MFA for sensitive operations, enforce device compliance.
Privileged Identity Management (PIM) provides just-in-time access for administrative roles. Time-bound elevation reduces standing privilege risk.
GCP IAM simplicity
Google Cloud IAM takes simpler approach compared to AWS and Azure complexity.
IAM bindings attach members (users, groups, service accounts) to roles at resource level. Straightforward model easier to understand than AWS policy evaluation.
Predefined roles cover common use cases. Primitive roles (Owner, Editor, Viewer) too broad but predefined roles provide reasonable least privilege starting point.
Custom roles allow fine-grained permission control when predefined roles don’t fit requirements. Define exact permissions needed for specific use case.
Service accounts first-class citizens in GCP. Workload identity federation enables external workload authentication without exporting service account keys.
When Compliance Becomes Customer Problem
Shared compliance responsibility
Cloud providers maintain infrastructure compliance certifications but customer must implement and demonstrate application and data security controls.
Infrastructure compliance like SOC 2, ISO 27001, and PCI DSS Level 1 means provider data centers and services meet standards. This doesn’t mean customer workloads are compliant.
Customer must implement security controls for their specific compliance requirements. GDPR data protection, HIPAA security rules, and PCI DSS requirements are customer responsibility.
Audit evidence collection falls to customer. Cloud provider supplies infrastructure audit reports but customer must document their own controls and evidence.
Compliance inheritance is limited. Provider’s ISO 27001 certification doesn’t make customer ISO 27001 certified without implementing required controls.
GDPR and data protection
General Data Protection Regulation places data protection obligations on customer as data controller. Cloud provider is data processor with limited liability.
Data residency requirements mean understanding where data physically resides. AWS regions, Azure geographies, and GCP locations must align with regulatory requirements.
Data processing agreements (DPA) with cloud providers define processor responsibilities. Standard DPAs cover basics but customer must ensure adequate protection.
Right to erasure and data portability are customer responsibility to implement. Cloud provider stores data but customer must build deletion and export capabilities.
Breach notification timelines start when customer detects breach. Provider detects infrastructure breaches but customer responsible for detecting data breaches in their applications.
HIPAA and healthcare data
Health Insurance Portability and Accountability Act requires business associate agreements (BAA) with cloud providers processing protected health information (PHI).
AWS, Azure, and GCP offer BAAs but only for specific services. Not all cloud services are HIPAA-eligible. Customer must use eligible services and configure them correctly.
Encryption of PHI both at rest and in transit is required. Customer must enable encryption-provider offers capability but doesn’t enforce.
Access logging and audit trails must be maintained. CloudTrail, Azure Activity Log, and Cloud Audit Logs provide infrastructure-level logging but application-level logging is customer responsibility.
Risk analysis and security controls implementation documented by customer. HIPAA compliance isn’t automatic from using HIPAA-eligible services.
What Multi-Cloud Security Looks Like
Consistent security across platforms
Organizations using AWS, Azure, and GCP simultaneously face challenge of implementing consistent security policies across different platforms.
Identity federation provides single source of truth for user identities. Okta, Azure AD, or Ping can federate to multiple clouds enabling centralized identity management.
Cloud security posture management (CSPM) tools provide unified view of security configuration across clouds. Prisma Cloud, Lacework, or Wiz scan all three providers.
Policy-as-code enables defining security requirements once and implementing across platforms. Terraform, CloudFormation, and platform-specific tools enable programmatic security.
Centralized logging and monitoring through SIEM aggregates security events from all cloud environments. Splunk, Microsoft Sentinel, or Elastic ingest logs from AWS, Azure, and GCP.
Provider-specific security services
Each cloud provider offers unique security services requiring specific expertise.
AWS security services include GuardDuty (threat detection), Security Hub (security finding aggregation), Macie (data discovery), and Inspector (vulnerability scanning).
Azure security services include Defender for Cloud (security posture management), Sentinel (SIEM), Defender for Endpoint, and various Defender for… services.
GCP security services include Security Command Center (security posture), Chronicle (SIEM), Security Health Analytics, and Web Security Scanner.
Learning curve multiplies with each platform. Security team must understand three different security service ecosystems, pricing models, and integration patterns.
Cost implications
Multi-cloud security doesn’t just increase complexity-it dramatically increases costs.
Tool duplication across platforms. Some security tools charge per cloud account or per resource. Running same tool in AWS, Azure, and GCP triples costs.
Data transfer costs between clouds can be substantial. Log aggregation from multiple clouds to central SIEM incurs egress charges.
Specialized expertise required for each platform. Finding security professionals with deep knowledge of all three clouds is difficult and expensive.
Third-party CSPM and security tools that support all three clouds provide value despite additional cost by reducing operational complexity.
Cloud Security Service Comparison
| Category | AWS Service | Azure Service | GCP Service | Purpose |
| Threat Detection | GuardDuty | Defender for Cloud | Security Command Center | Anomaly detection, threat intelligence |
| Vulnerability Scanning | Inspector | Defender for Servers | Container Analysis | OS and application vulnerability detection |
| SIEM | Security Hub | Sentinel | Chronicle | Security event aggregation and analysis |
| Data Discovery | Macie | Information Protection | Data Loss Prevention | Sensitive data identification |
| Key Management | KMS | Key Vault | Cloud KMS | Encryption key management |
| Secrets Management | Secrets Manager | Key Vault | Secret Manager | Application secret storage |
| Identity | IAM | Azure AD | Cloud Identity | User and service authentication |
Why Configuration Management Matters
Infrastructure as Code
Manual configuration through web console creates inconsistency, lacks version control, and doesn’t scale. Infrastructure as Code (IaC) solves these problems.
Terraform provides provider-agnostic IaC enabling multi-cloud deployments with consistent tooling. Learn one language, manage all clouds.
CloudFormation (AWS), ARM templates (Azure), and Deployment Manager (GCP) provide native IaC capabilities with deep platform integration.
Security controls defined in code get reviewed like application code. Pull requests, peer review, and automated testing catch misconfigurations before deployment.
Version control for infrastructure enables rollback to known-good configurations. Git history documents who changed what and why.
Configuration scanning
Static analysis of IaC identifies security issues before deployment. Shift-left approach prevents production misconfigurations.
Checkov, tfsec, and Terrascan scan Terraform code for security issues. Public S3 buckets, open security groups, and missing encryption flagged during development.
Provider-specific tools like CloudFormation Guard (AWS) or Azure Policy enable platform-specific validation.
Automated scanning in CI/CD pipeline prevents insecure configurations from reaching production. Failed security scan blocks deployment.
Custom policies enforce organization-specific security requirements. Generic scanning tools augmented with company-specific rules.
Drift detection
Infrastructure drift happens when manual changes diverge from IaC definitions. Drift undermines IaC benefits and creates security risks.
Terraform state tracks actual infrastructure. Regular terraform plan executes show drift from code definitions.
Cloud provider native tools detect drift. AWS CloudFormation Drift Detection, Azure Policy, and GCP Config Connector identify differences between deployed and defined configurations.
Automated remediation can revert drift automatically or create alerts for manual investigation. Choose approach based on change control requirements.
How to Implement Defense in Depth
Layered security controls
Single security control failure shouldn’t cause complete breach. Multiple overlapping controls provide resilience.
Network layer controls include VPC isolation, security groups, network ACLs, and private subnets. Traffic filtering at multiple levels increases attacker difficulty.
Identity layer controls include MFA, conditional access, least privilege IAM, and short-lived credentials. Compromising identity requires defeating multiple authentication factors.
Data layer controls include encryption at rest and transit, data classification, and access logging. Protected data remains secure even if other layers breach.
Application layer controls include WAF, input validation, and secure coding practices. Defense against application-specific attacks.
Monitoring and detection layer identifies attacks that bypass preventive controls. Quick detection and response minimize breach impact.
Zero Trust principles in cloud
Zero Trust architecture translates naturally to cloud environments where traditional network perimeter doesn’t exist.
Identity-first security rather than network-based trust. Cloud IAM systems provide foundation for Zero Trust implementation.
Service-to-service authentication using managed identities or service accounts. Every API call authenticated and authorized.
Micro-segmentation through security groups, network policies, and service mesh. Limit lateral movement within cloud environment.
Continuous monitoring and risk assessment. Behavioral analytics detect anomalous access patterns indicating compromise.
Incident response preparation
Despite best prevention, breaches happen. Incident response preparation minimizes damage and recovery time.
Incident response plan specific to cloud environment. Different procedures for AWS versus on-premise compromise.
CloudTrail, Azure Activity Log, and Cloud Audit Logs configured for comprehensive logging. Logs shipped to immutable storage preventing attacker tampering.
Automated incident response using Lambda, Azure Functions, or Cloud Functions. Immediate isolation of compromised resources.
Regular tabletop exercises and simulations test incident response procedures. Theory differs from practice-test before real incident.
Where Cloud Security Training Fails
Certification versus practical skill
Cloud security certifications validate knowledge but don’t guarantee practical security implementation skill.
AWS Certified Security Specialty, Azure Security Engineer Associate, and Google Professional Cloud Security Engineer certify platform knowledge but don’t test security judgment.
Hands-on experience securing real production environments develops judgment that certification exams don’t assess. Book knowledge differs from practical implementation.
Certifications teach provider’s security services but not when and how to use them appropriately. Tool knowledge without strategy creates dangerous false confidence.
However, certifications do demonstrate commitment to learning and baseline platform knowledge. Combine certifications with practical experience for complete skill set.
Keeping up with changes
Cloud platforms evolve rapidly with new services, features, and security controls released constantly.
What was best practice last year may be outdated now. AWS, Azure, and GCP release major updates quarterly with minor updates weekly.
Security professionals must dedicate time to continuous learning. Following cloud provider blogs, attending webinars, and experimenting with new services maintains current knowledge.
Community resources like cloud security podcasts, Twitter follows, and professional networks share emerging practices before official documentation updates.
Vendor certifications require periodic renewal forcing continued education. Three-year recertification cycle ensures knowledge doesn’t stagnate completely.
Learning from breaches
Public breach disclosures provide valuable lessons about what security controls actually matter in practice.
Capital One breach (AWS S3/WAF misconfiguration) demonstrated SSRF vulnerabilities and privilege escalation risks.
Uber breach (Azure AD misconfiguration) showed insufficient access controls and monitoring.
Public post-mortems when available reveal attack chains and missed detection opportunities. Learning from others’ mistakes less expensive than learning from your own.
However, many breaches remain undisclosed or details suppressed. Public breach information represents small fraction of actual cloud security incidents.
How Ambacia Supports Cloud Security Teams
Cloud security requires specialized expertise across AWS, Azure, and GCP platforms combined with general security knowledge and understanding of shared responsibility model.
Ambacia specializes in placing cloud security engineers, DevSecOps professionals, and security architects across Europe who secure cloud deployments at companies of all sizes.
Our work with cloud security professionals includes:
Matching cloud security engineers with platform-specific expertise to companies using AWS, Azure, or GCP. We assess hands-on experience implementing IAM, encryption, network security, and logging.
Identifying DevSecOps professionals who integrate security into cloud infrastructure pipelines, implement policy-as-code, and automate security controls.
Supporting security architects designing multi-cloud security strategies, implementing Zero Trust in cloud environments, and ensuring compliance with GDPR, NIS2, and industry regulations.
Connecting companies in Zagreb, Croatia and throughout Europe with security talent experienced in cloud migration security, hybrid cloud architectures, and container security.
For cloud security professionals seeking roles:
We help you articulate platform-specific experience and certifications effectively We connect you with organizations at various cloud maturity stages from migration to cloud-native We provide guidance on specialization versus generalist paths in cloud security We match you to companies where cloud security is strategic priority with appropriate budget
For companies securing cloud infrastructure:
We identify candidates with specific platform experience (AWS Security Specialty, Azure Security Engineer) We assess practical implementation skill beyond certification credentials We evaluate cultural fit for DevSecOps collaboration and automation-first approaches We help determine team structure balancing generalists versus platform specialists
Whether you’re security professional specializing in cloud or organization migrating critical workloads to AWS, Azure, or GCP, Ambacia connects you with expertise making shared responsibility model work in practice.
Cloud security isn’t optional add-on-it’s foundational requirement for successful cloud adoption. Getting shared responsibility model right determines whether cloud delivers promised business value or creates liability.
Conclusion
Cloud security in AWS, Azure, and GCP fundamentally depends on understanding and correctly implementing shared responsibility model. Cloud providers secure infrastructure layer but customer bears responsibility for data, applications, identities, and configurations.
The model shifts liability to customers who often don’t realize extent of their responsibilities until breach occurs. “We’re in the cloud so we’re secure” is dangerous misconception.
IAM misconfiguration causes majority of cloud breaches. Overprivileged roles, missing MFA, long-lived credentials, and weak access controls create attack paths that determined attackers exploit.
Default configurations prioritize usability over security. Assuming resources are secure by default leads to public storage buckets, open security groups, and unencrypted data.
Multi-cloud multiplies complexity requiring expertise across different security models, services, and configuration paradigms. Consistent security across platforms demands significant investment.
Compliance responsibility falls to customer despite cloud provider infrastructure certifications. Implementing and documenting security controls for GDPR, HIPAA, or industry regulations requires customer effort.
Infrastructure as Code, configuration scanning, and automated security controls scale security implementation across cloud environments. Manual configuration through web console doesn’t work at cloud scale.
For security professionals throughout Europe-whether in Zagreb, Amsterdam, London, or elsewhere-cloud security expertise is increasingly valuable as organizations migrate to cloud. Understanding shared responsibility model separates theoretical knowledge from practical implementation skill.
Ambacia connects cloud security professionals with organizations that understand security isn’t cloud provider’s problem alone. We match technical expertise with companies making appropriate security investments.
FAQ
1. What exactly does “shared responsibility model” mean in practice?
Cloud provider secures the infrastructure; you secure everything running on it. This includes your data, applications, operating systems, network configuration, and access management.
Provider responsibilities include physical data centers, hardware, network backbone, hypervisor security, and managed service infrastructure. They ensure their platform is secure.
Customer responsibilities include operating system patches (for IaaS), application security, data encryption, identity and access management, network security configuration, and data classification.
Confusion arises with managed services where responsibility boundary shifts. For RDS database, provider handles OS patching but customer manages encryption, IAM, and security groups.
The exact boundary varies by service type. IaaS (EC2, VMs) gives customer most responsibility. PaaS (Lambda, App Service) shifts more to provider. SaaS shifts most responsibility to provider.
Document your understanding of responsibility boundaries for each service you use. Assumptions about provider responsibility cause breaches when customer didn’t implement required controls.
2. Are S3 buckets (or Azure Storage/GCS buckets) secure by default?
No, and this causes thousands of data breaches annually. Storage buckets require explicit security configuration-they’re not secure out of the box.
S3 buckets historically defaulted to allowing public access if you configured public permissions. Recent updates added block public access defaults, but legacy buckets remain misconfigured.
Azure Storage accounts allow public blob access by default if you enable it. “Allowing public access” is configuration choice that’s easy to make accidentally.
GCS buckets require explicit permissions but default ACLs can grant broader access than intended. “AllUsers” and “AllAuthenticatedUsers” are dangerous principals.
Bucket policies and IAM permissions interact in complex ways. Understanding policy evaluation order across resource policies, IAM policies, and ACLs is crucial.
Implement automated scanning for public buckets using AWS Config, Azure Policy, or GCP Security Command Center. Alert on public access before breach occurs.
Ambacia places cloud security engineers who understand storage security nuances and implement preventive controls before exposure occurs.
3. Do I need different security tools for AWS, Azure, and GCP?
Not necessarily, but multi-cloud security is significantly more complex. You can use unified tools or platform-specific services depending on needs and budget.
Cloud Security Posture Management (CSPM) tools like Prisma Cloud, Wiz, or Lacework scan all three providers from single platform. Unified visibility reduces operational complexity.
However, platform-native tools integrate more deeply and cost less. AWS Security Hub, Azure Defender for Cloud, and GCP Security Command Center provide free or low-cost baseline security.
For larger deployments, hybrid approach works best. CSPM for unified posture management plus native tools for deep platform integration and advanced features.
SIEM strategy matters too. Centralized SIEM like Splunk or Microsoft Sentinel ingests logs from all clouds but egress costs can be substantial.
Consider your organization’s multi-cloud commitment. If one cloud is 90% of workload, optimize for that platform. If truly multi-cloud, invest in unified tooling.
4. How do I implement encryption correctly across cloud environments?
Enable encryption at rest and in transit for all sensitive data, using customer-managed keys when regulatory requirements demand. Each cloud provider offers encryption services but requires explicit enablement.
Encryption at rest for storage includes S3 server-side encryption (SSE-S3, SSE-KMS, SSE-C), Azure Storage Service Encryption, and GCS encryption. Enable organization-wide through policies.
Database encryption includes RDS encryption, Azure SQL Transparent Data Encryption (TDE), and Cloud SQL encryption. Must be enabled at creation-can’t encrypt existing unencrypted databases without recreation.
Encryption in transit using TLS/SSL for all network communications. Load balancers, CDNs, and API gateways should enforce HTTPS. Backend services should use encryption even for internal communications.
Key management through AWS KMS, Azure Key Vault, or GCP Cloud KMS. Customer-managed keys (CMK) provide control over encryption keys for compliance requirements.
Regular key rotation policies balance security hygiene with operational complexity. Automatic rotation where supported reduces management burden.
5. What are the most dangerous IAM misconfigurations?
Overprivileged roles with wildcard permissions, missing MFA, and long-lived credentials top the list. These misconfigurations enable attackers to escalate privileges and move laterally.
Administrator access granted to users who don’t need it. Full admin rights (AdministratorAccess in AWS, Owner in Azure, Owner role in GCP) should be rare and time-bound.
Wildcard permissions using * for resources or actions. Policies like “s3:*” or “Resource: *” grant far broader access than typically intended.
Service accounts with excessive permissions. EC2 instance roles, Lambda execution roles, and GKE service accounts often have permissions far exceeding actual needs.
Long-lived access keys never rotated. Credentials created years ago still valid provide persistent access if compromised. Keys should rotate every 90 days maximum.
Missing multi-factor authentication especially for privileged accounts. Password-only authentication is insufficient in 2025 regardless of password complexity.
No conditional access policies restricting access by location, device, or risk level. Context-aware access prevents credential compromise from leading to breach.
6. How do I secure Kubernetes in the cloud (EKS, AKS, GKE)?
Kubernetes security requires securing control plane, worker nodes, containers, and network communications. Managed Kubernetes services help but don’t eliminate security responsibilities.
Control plane security is provider’s responsibility in managed services. EKS, AKS, and GKE secure Kubernetes API server, but customer configures RBAC and admission controls.
Worker node security includes OS patching, runtime security, and node isolation. Customer manages worker nodes even in managed clusters (unless using Fargate, Autopilot, or similar).
Container image security through vulnerability scanning and image signing. Scan images with Trivy, Clair, or cloud-native tools before deployment. Implement admission controllers rejecting vulnerable images.
Pod security policies (deprecated) replaced by Pod Security Standards. Restrict privileged containers, host network access, and dangerous capabilities.
Network policies control pod-to-pod communication implementing micro-segmentation within cluster. Default Kubernetes allows all pod-to-pod traffic-explicit policies required for isolation.
Secrets management using external secret stores (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) rather than Kubernetes secrets. Native secrets are base64-encoded, not encrypted.
Service mesh like Istio provides mutual TLS between services, advanced traffic management, and observability. Adds complexity but provides defense in depth.
7. What compliance certifications does my cloud deployment need?
Depends on your industry, data types, and geographic presence. Cloud provider certifications don’t automatically make your deployment compliant.
GDPR applies if you process EU citizen data regardless of where company is located. Requires data protection measures, breach notification, and user privacy rights.
HIPAA required for US healthcare data. Business Associate Agreement (BAA) with cloud provider plus implementation of HIPAA security and privacy rules.
PCI DSS required for payment card data processing. Applies to merchants and service providers handling card data. Cloud deployment must meet PCI requirements even if provider is PCI certified.
SOC 2 commonly required by enterprise customers evaluating vendor security. Demonstrates security controls around confidentiality, availability, and integrity.
ISO 27001 international standard for information security management. Required by some customers and useful for demonstrating security maturity.
Industry-specific regulations like NIS2 (Europe critical infrastructure), DORA (EU financial services), or FedRAMP (US government) have specific requirements.
Ambacia connects companies with cloud security professionals experienced in compliance implementation and audit preparation across European regulations.
8. Should we use cloud provider’s native security services or third-party tools?
Hybrid approach works best for most organizations. Native services provide baseline security at low cost; third-party tools add capabilities and unified multi-cloud visibility.
Native security advantages include deep platform integration, lower cost (often free tier available), automatic updates, and no additional vendor relationships.
Third-party advantages include multi-cloud support, advanced features, specialized capabilities, and avoiding vendor lock-in. Tools like Prisma Cloud or Wiz provide capabilities beyond native services.
For single-cloud deployments, native tools often sufficient. AWS Security Hub, Azure Defender for Cloud, or GCP Security Command Center provide comprehensive baseline security.
For multi-cloud, CSPM tools providing unified view across platforms reduce operational complexity despite additional cost.
Specialist tools for vulnerability management, SIEM, or secrets management may outperform cloud-native options depending on requirements.
Budget constraints matter. Native services provide significant value at low cost. Third-party tools require budget justification through clear capability gaps.
9. How do we train our team on cloud security across multiple platforms?
Combination of certifications, hands-on labs, and real-world practice develops cloud security expertise. Learning curve is steep but manageable with structured approach.
Platform certifications provide foundation. AWS Certified Security Specialty, Azure Security Engineer Associate, and Google Professional Cloud Security Engineer validate baseline knowledge.
Hands-on practice through cloud provider training platforms. AWS Skill Builder, Microsoft Learn, and Google Cloud Skills Boost offer free labs and scenarios.
Third-party training from A Cloud Guru, Pluralsight, or Linux Academy provides structured learning paths combining video instruction with hands-on labs.
Capture-the-flag (CTF) competitions and security challenges provide gamified learning. Cloud security CTFs teach attack and defense techniques.
Real-world experience securing production systems develops judgment that training can’t replicate. Start with less critical workloads before protecting crown jewels.
Continuous learning essential as platforms evolve rapidly. Dedicate time weekly to exploring new services, reading security blogs, and following cloud security researchers.
Community resources like cloud security Slack channels, Twitter follows, and local meetups provide peer learning and knowledge sharing.
10. How can Ambacia help us build cloud security capability?
Ambacia specializes in placing cloud security professionals across Europe who secure AWS, Azure, and GCP deployments with deep understanding of shared responsibility model.
For companies building cloud security teams, we provide:
Cloud security engineers with platform-specific expertise (AWS Security Specialty, Azure Security Engineer) who implement IAM, encryption, network security, and monitoring.
DevSecOps professionals who integrate security into CI/CD pipelines, implement infrastructure-as-code security, and automate security controls at scale.
Security architects designing multi-cloud security strategies, cloud migration security assessments, and Zero Trust implementations in cloud environments.
Team structure guidance on whether you need dedicated cloud security team, embedded security engineers in DevOps teams, or hybrid models. We help determine right approach for your organization size and cloud maturity.
For security professionals, we provide:
Career guidance on cloud security specialization, certification priorities, and whether to generalize across clouds or specialize in one platform.
Access to opportunities at companies in Zagreb, Croatia and throughout Europe at various cloud adoption stages from initial migration to cloud-native architecture.
Interview preparation for cloud security roles including technical scenarios about IAM design, incident response in cloud, and compliance implementation.
Market intelligence about cloud security demand, salary expectations, and which skills command premium compensation.
We understand cloud security requires both platform-specific technical knowledge and general security principles. Finding professionals with right combination of skills is challenging—that’s where Ambacia provides value.
Whether you’re building cloud security capability or seeking role where you’ll secure cloud infrastructure at scale, reach out to discuss how we can support your goals.
