{"id":3069,"date":"2026-10-19T03:25:58","date_gmt":"2026-10-19T03:25:58","guid":{"rendered":"https:\/\/aiunplugged.io\/blog\/?p=3069"},"modified":"2026-10-19T03:26:01","modified_gmt":"2026-10-19T03:26:01","slug":"cybersecurity-for-the-cloud","status":"publish","type":"post","link":"https:\/\/aiunplugged.io\/blog\/cybersecurity-for-the-cloud\/","title":{"rendered":"Cybersecurity For The Cloud"},"content":{"rendered":"\n

Why most cloud breaches start on the customer\u2019s side, and what to do about it<\/p>\n\n\n\n

Many companies move to the cloud believing that the provider will take care of security. That is only half true. The space between \u201cthe provider protects some things\u201d and \u201cthe provider protects everything\u201d is where most cloud breaches happen. Anyone who wants to build a serious cloud security programme has to start by understanding that gap<\/u><\/a>.<\/p>\n\n\n\n

Who is responsible for what?<\/strong><\/p>\n\n\n\n

AWS, Microsoft Azure and Google Cloud all follow a shared responsibility model. The provider protects the infrastructure: the data centres, the hardware, the virtualisation layer and the physical network. The customer protects everything they build on top of it, which means configuration, identities, applications and data.<\/p>\n\n\n\n

Where exactly the line falls depends on the type of service. With virtual machines (IaaS), the customer has to patch the operating system. With a managed platform (PaaS), the provider takes over more of the work. With SaaS products, the customer mainly decides who has access and which data is stored. Renting a flat is a good comparison. The landlord looks after the building, but if you leave your door unlocked, that is your problem, not his.<\/p>\n\n\n\n

Why misconfiguration is the biggest threat<\/strong><\/p>\n\n\n\n

Year after year, industry reports show the same pattern: cloud incidents are caused far more often by customer mistakes than by failures at the provider. A storage bucket that is public by accident, a database reachable from the whole internet or an access key pushed to GitHub is enough. None of these needs a clever attacker.<\/p>\n\n\n\n

The Capital One breach in 2019 is still the classic example. The attacker found a misconfigured web application firewall, used it to reach the cloud metadata service and received credentials for a role that had far too many permissions. With those credentials, the data of around 100 million customers in the United States and about 6 million in Canada was copied from storage. No zero-day exploit was involved. Every step worked because of configuration and permission errors. The protection that would have blocked this specific trick, the newer metadata service version IMDSv2, has existed for years, yet according to Datadog\u2019s 2025 State of Cloud Security study only about half of EC2 instances enforce it.<\/p>\n\n\n\n

More recent cases follow the same logic. In 2024, criminals logged into the Snowflake accounts of around 165 companies, including Ticketmaster and Santander, with passwords stolen by infostealer malware, some of them years old. Snowflake itself was not hacked. The affected accounts simply had no MFA and no rule limiting where logins could come from. In August 2025, attackers stole OAuth tokens from the Salesloft Drift chatbot integration and used them to export data from the Salesforce environments of hundreds of organisations. They were especially interested in AWS keys and passwords that employees had pasted into support tickets. Verizon\u2019s 2026 Data Breach Investigations Report shows how big this supply-chain problem has become: third parties were involved in almost half of all breaches.<\/p>\n\n\n\n

The controls that matter most<\/strong><\/p>\n\n\n\n

    \n
  1. Identity comes first. <\/strong>In the cloud, the network perimeter is weak and identity has become the real perimeter. Apply least privilege, so that every user and every service gets only the permissions it actually needs. Protect admin and root accounts with MFA, ideally phishing-resistant methods such as FIDO2 keys. Use roles with temporary credentials instead of long-lived access keys. This advice is old, but many organisations still ignore it: Datadog found that 59% of AWS IAM users have an active access key older than one year. Review permissions regularly, because they grow over time and almost never shrink by themselves.<\/li>\n\n\n\n
  2. Do not forget third-party access. <\/strong>SaaS integrations, OAuth apps and API connections often have broad and permanent access to your data. Keep a list of them, give them only the permissions they need, rotate their tokens and remove the ones nobody uses. The Drift case showed that a trusted integration can become an open door.<\/li>\n\n\n\n
  3. Protect the data itself. <\/strong>Encrypt data at rest and in transit. Use the provider\u2019s key management service, and think about customer-managed keys for very sensitive data. Classify your data so that everyone knows where the critical information is. Turn on \u201cblock public access\u201d for storage by default, so that one mistake cannot expose everything.<\/li>\n\n\n\n
  4. Control the network. <\/strong>Put workloads in private subnets, keep security groups as narrow as possible and never leave SSH or RDP open to the whole internet. A bastion host or a session manager service is a much safer choice. Segmentation also limits how far an attacker can move after the first compromise.<\/li>\n\n\n\n
  5. Log everything from day one. <\/strong>Turn on audit logs such as AWS CloudTrail, Azure Activity Log or Google Cloud Audit Logs before you need them, and keep a copy in a separate account with restricted access. Then create alerts for the events that really matter: root logins, changes to security policies and attempts to switch logging off. Attackers often try to blind the defenders before they make their move. From a SOC point of view, a disabled CloudTrail trail should be treated as a high-priority alert, not as an admin task.<\/li>\n\n\n\n
  6. Secure the pipeline, not only the servers. <\/strong>Today most infrastructure is created with code, for example with Terraform. Scan this code and your container images before deployment, so that a risky setting is caught in code review and not in production. Never store secrets in source code. Bots scan public repositories around the clock, and a leaked key can be abused within minutes. The 2025 \u201cShai-Hulud\u201d worm, which spread through malicious npm packages and stole GitHub and cloud tokens from developers, showed that the pipeline itself is now a target.<\/li>\n\n\n\n
  7. Plan for failure. <\/strong>Keep backups, make them immutable and test whether you can actually restore them. Ransomware groups now go after cloud backups on purpose. Your incident response plan also has to fit the cloud. Who can revoke a compromised key? How do you take a snapshot of an affected machine for forensics? These questions are much easier to answer before an incident than in the middle of one.<\/li>\n<\/ol>\n\n\n\n

    Multi-cloud makes it harder<\/strong><\/p>\n\n\n\n

    Many organisations now use more than one provider. This reduces dependency on a single vendor, but it also multiplies the work. Each platform uses its own names, defaults and tools for the same ideas, and security rules easily become inconsistent. In a multi-cloud environment, policies should be defined once in a central place. A Cloud Security Posture Management (CSPM) tool should detect configuration drift, and a clear tagging system should make sure that every resource has an owner.<\/p>\n\n\n\n

    Common mistakes<\/strong><\/p>\n\n\n\n