According to the IBM Cost of a Data Breach 2024 report, cloud environments are the location of nearly half of all security incidents. And although providers such as AWS, Azure or Google Cloud invest huge resources into securing their infrastructure, the real threat usually does not come from them - but from customers who misconfigure the cloud, manage access incorrectly or neglect monitoring.
We will examine the five most common mistakes we see in companies transitioning to the cloud or already operating in it, and show how to fix each one.
Mistake 1: Misunderstanding the shared responsibility model
This is paradoxically the most fundamental and yet most frequently overlooked mistake. Every major cloud provider operates a Shared Responsibility Model that clearly defines what the provider secures and what the customer must secure. AWS, Azure and GCP are responsible for security of the cloud itself - physical infrastructure, hypervisor, network backbone. For security in the cloud - operating systems, data, configuration, access: the customer is responsible.
Companies that do not understand this division of responsibility rely on the assumption that "the cloud is secure" and overlook their own share of accountability. The result is publicly accessible S3 buckets containing sensitive data, unpatched virtual machines, or databases available from the internet without authentication.
How to repair: Review the shared responsibility model of your provider. Implement a Cloud Security Posture Management (CSPM) tool that continuously checks the configuration of the cloud environment against security standards.Error 2: Incorrect configuration
Misconfiguration is cited by Gartner as the cause of 99% of cloud security failures. These are technically simple errors, yet easily overlooked, especially in dynamic environments where developers rapidly create and modify resources.
Most common examples of misconfigurations:
- Publicly accessible S3 buckets or Azure Blob Storage with internal documents, deposits or logs.
- Security Groups Allowing incoming traffic on SSH (port 22) or RDP (port 3389) from the entire internet (0.0.0.0/0).
- Database without encryption or with the default login credentials.
- Missing disk encryption for virtual machines with sensitive data.
- Logging and audit records disabled or stored outside the primary environment.
Error 3: Weak identity and access management (IAM)
Identity and Access Management in the cloud is significantly more complex than in traditional on-premise environments. There are dozens of identity types, users, roles, service accounts, API keys, functions (Lambda, Azure Functions), each with its own permissions. Typical IAM errors include:
- Excessive permissions (overprivileged accounts): Users and service accounts have more permissions than necessary. Developers have AdministratorAccess in the production environment. Service accounts have permissions for the entire organisation, even though they only need access to a single S3 bucket.
- Unused accounts and keys: Former employees still have active access. API keys are not rotated for months or years.
- API keys in source code: Keys hardcoded in the source code and pushed to a public GitHub repository, attackers actively scan GitHub for such keys.
- Absence of MFA for privileged accounts: AWS root account or Azure Global Administrator without multi-factor authentication.
Error 4: Unencrypted or insufficiently protected data
Data are physically distributed across the provider's data centres in the cloud, and without proper encryption they are exposed to risk. Although modern cloud providers offer encryption as a default or easily activatable feature, companies still fail to enable it or configure it incorrectly.
Key issues: data at rest is not encrypted or is encrypted with keys managed exclusively by the provider without customer control; data in transit is not encrypted or uses outdated TLS versions; backups and snapshots are unencrypted or shared cross-account without authorization; sensitive data (PII, financial records) is not classified and not protected accordingly.
How to repair: Enable encryption at rest for all storage services - S3, EBS, RDS, Azure Blob Storage - and use Customer Managed Keys (CMK) for sensitive data. Enforce TLS 1.2+ for all communication. Deploy DLP and data classification to identify where sensitive data resides.Error 5: Missing or insufficient monitoring
The cloud environment generates huge volumes of logs, API calls, logins, configuration changes, network traffic. Without proper monitoring, these logs are useless: an attacker can operate in the cloud environment for weeks without detection.
Typical failures: CloudTrail (AWS) or Azure Activity Log are disabled, or logs are not retained long enough. No alerts are generated for suspicious activities, logins from unusual locations, sudden creation of new IAM users, massive data downloads from S3. Log integration into a SIEM system is not configured. Responsibility for monitoring is unclear or not assigned at all.
How to repair: Activate and retain all available audit logs. Set up alerts for critical events (new root session, new IAM user, publicly accessible S3 bucket, unusual API activity). Integrate cloud logs into the central PBX. SOC and SIEM solutionsConsider deploying managed detection and response (MDR) for cloud environments.How to start improving cloud security
If you are unsure about the state of your cloud security, we recommend starting with a cloud security assessment: a systematic evaluation of configuration, access controls, encryption and monitoring against best practices (CIS Benchmarks, AWS Well-Architected Framework, Microsoft Cloud Security Benchmark). The result is a prioritised list of measures with an estimate of risk and the effort required for remediation.
Specialists SecureOn.cz They carry out cloud security assessments and help companies set up secure cloud environments from the ground up. Contact us for a free initial consultation.