{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"platform/cloud-misconfiguration","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/cloud-misconfiguration/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/cloud-misconfiguration/"},"term":{"en":"Cloud misconfiguration","da":"Fejlkonfiguration i skyen"},"aka":{"en":[],"da":[]},"domain":["platform","security"],"cluster":"cloud","layer":"infrastructure","status":"current","summary":{"en":"A wrong or careless setting in a cloud service - like storage left open to everyone - that exposes data or systems.","da":"En forkert eller skødesløs indstilling i en cloudtjeneste - fx lager, der står åbent for alle - som blotlægger data eller systemer."},"body":{"formal":{"en":"A weakness created not by a flaw in the provider's software but by the customer's own choice of settings, such as public access to storage, too broad permissions, disabled logging or open network ports.","da":"En sårbarhed, der ikke skyldes en fejl i udbyderens software, men kundens egne valg af indstillinger, fx offentlig adgang til lager, for brede rettigheder, manglende logs eller åbne netværksporte."},"plain":{"en":"Like a sturdy safe bought for the office but left with its door standing open - the safe works fine; the way it was set up does not.","da":"Som et solidt pengeskab, der er købt til kontoret, men står med døren åben - skabet virker fint; det er måden, det er sat op på, der ikke gør."},"inPractice":{"en":"A developer at a hospital region makes a storage bucket public to share a test file and forgets to close it; months later strangers find patient records in it, and the region must report a personal data breach.","da":"En udvikler i en region gør en bucket offentlig for at dele en testfil og glemmer at lukke den; måneder senere finder fremmede patientdata i den, og regionen må anmelde brud på persondatasikkerheden til Datatilsynet."},"whyItMatters":{"en":"Settings can be changed in seconds by many people, and one slip can put large amounts of data on the open internet; the provider will not step in, because settings are the customer's side.","da":"Indstillinger kan ændres på sekunder af mange personer, og én fejl kan lægge store mængder data åbent på internettet; udbyderen griber ikke ind, for indstillingerne er kundens ansvar."}},"deepDive":{"en":"The recurring classes are well known. Storage exposure: an S3 bucket policy with Principal \"*\", an ACL granting AllUsers, anonymous blob access in Azure Storage, or a Google Cloud Storage binding to allUsers or allAuthenticatedUsers (the latter means any Google account at all, not \"our users\", a classic misreading). Network exposure: security groups allowing 0.0.0.0/0 on SSH, RDP or database ports, managed databases with public endpoints, Kubernetes API servers or dashboards open to the internet. Identity: wildcard IAM policies, routine use of the root account, long-lived access keys. Visibility: audit logging, storage access logs or flow logs switched off. OWASP files the web-facing variant under A02:2025 Security Misconfiguration, and MITRE ATT&CK describes exploitation as T1530 Data from Cloud Storage.\n\nMisconfiguration is so common because the control plane lets many principals change security-relevant state in seconds, defaults differ between services, and live state drifts from the infrastructure-as-code that supposedly defines it through console changes and emergency fixes that are never reverted. Providers have tightened defaults: S3 Block Public Access arrived in 2018, and since April 2023 new buckets have Block Public Access enabled and ACLs disabled by default. The 2019 Capital One breach illustrates how misconfigurations chain: a misconfigured web application firewall on EC2 allowed SSRF against the instance metadata service (IMDSv1), which returned credentials for a role broad enough to list and copy S3 data on roughly 100 million people. IMDSv2, with a session token obtained by PUT, was released later that year as a direct countermeasure.\n\nPrevention works at three points. Before deployment, policy-as-code scanners such as Checkov, Trivy or OPA/Conftest check Terraform and Kubernetes manifests in the pipeline. At the organisation level, preventive guardrails block classes of error outright: AWS service control policies, Azure Policy with the deny effect, Google Cloud organisation policy constraints such as storage.publicAccessPrevention. At runtime, cloud security posture management (AWS Config and Security Hub, Microsoft Defender for Cloud, Google Security Command Center, or third-party CSPM) continuously evaluates live resources against the CIS Foundations Benchmarks and flags drift.\n\nA misconfiguration is not a CVE: there is no vendor patch, because the software works as designed and the weakness lies on the customer's side of the shared responsibility model. When personal data has been exposed, GDPR treats this as a personal data breach under Art. 4(12) even without proof of access, and Art. 33(1) requires notification to Datatilsynet within 72 hours unless the breach is unlikely to result in a risk. If access logging was disabled, the controller usually cannot demonstrate that nobody downloaded the data, which pushes the assessment towards notification.","da":"De tilbagevendende typer er velkendte. Eksponeret lager: en S3-bucketpolitik med Principal \"*\", en ACL, der giver AllUsers adgang, anonym blob-adgang i Azure Storage eller en binding i Google Cloud Storage til allUsers eller allAuthenticatedUsers (sidstnævnte betyder enhver Google-konto overhovedet, ikke \"vores brugere\", en klassisk misforståelse). Eksponeret netværk: security groups, der tillader 0.0.0.0/0 på SSH, RDP eller databaseporte, managed databaser med offentlige endpoints, Kubernetes API-servere eller dashboards åbne mod internettet. Identitet: IAM-politikker med wildcards, daglig brug af root-kontoen, langlivede adgangsnøgler. Synlighed: revisionslog, adgangslogs på lager eller flow logs slået fra. OWASP placerer den webvendte variant under A02:2025 Security Misconfiguration, og MITRE ATT&CK beskriver udnyttelsen som T1530 Data from Cloud Storage.\n\nFejlkonfigurationer er så almindelige, fordi kontrolplanet lader mange principals ændre sikkerhedsrelevante indstillinger på sekunder, standardværdierne varierer mellem tjenester, og den faktiske tilstand glider væk fra den infrastructure as code, der angiveligt definerer den, gennem ændringer i konsollen og nødrettelser, der aldrig rulles tilbage. Udbyderne har strammet standarderne: S3 Block Public Access kom i 2018, og siden april 2023 har nye buckets Block Public Access slået til og ACL'er slået fra som standard. Capital One-bruddet i 2019 viser, hvordan fejl kædes sammen: en fejlkonfigureret web application firewall på EC2 muliggjorde SSRF mod instansens metadata-tjeneste (IMDSv1), som udleverede loginoplysninger til en rolle, der var bred nok til at liste og kopiere S3-data om omkring 100 millioner personer. IMDSv2, hvor der kræves et sessionstoken hentet med PUT, kom senere samme år som direkte modtræk.\n\nForebyggelse virker tre steder. Før udrulning tjekker policy-as-code-scannere som Checkov, Trivy eller OPA/Conftest Terraform- og Kubernetes-manifester i pipelinen. På organisationsniveau blokerer forebyggende guardrails hele fejlklasser: service control policies i AWS, Azure Policy med deny-effekt og organisationspolitikker i Google Cloud som storage.publicAccessPrevention. Under drift evaluerer cloud security posture management (AWS Config og Security Hub, Microsoft Defender for Cloud, Google Security Command Center eller tredjeparts-CSPM) løbende de faktiske ressourcer mod CIS Foundations Benchmarks og markerer afvigelser.\n\nEn fejlkonfiguration er ikke en CVE: der findes ingen patch fra leverandøren, for softwaren virker som designet, og svagheden ligger på kundens side af modellen for delt ansvar. Er personoplysninger blevet eksponeret, er det efter databeskyttelsesforordningens art. 4, nr. 12, et brud på persondatasikkerheden, også uden bevis for adgang, og art. 33, stk. 1, kræver anmeldelse til Datatilsynet inden for 72 timer, medmindre bruddet sandsynligvis ikke indebærer en risiko. Har adgangslogning været slået fra, kan den dataansvarlige som regel ikke dokumentere, at ingen har hentet data, hvilket trækker vurderingen i retning af anmeldelse."},"edges":[{"type":"requires","to":"platform/cloud-computing","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/permission","confidence":"high","strength":"normal"},{"type":"kind-of","to":"security/vulnerability","confidence":"high","strength":"normal"},{"type":"causes","to":"security/data-breach","why":{"en":"Storage or services left open by mistake are a common way personal data ends up in the wrong hands.","da":"Lager eller tjenester, der ved en fejl står åbne, er en almindelig måde, hvorpå personoplysninger havner i de forkerte hænder."},"confidence":"high","strength":"primary"}],"depth":6,"sources":[{"title":"CSA Cloud Controls Matrix (CCM)","tier":"reference","publisher":"Cloud Security Alliance"},{"title":"NIST SP 800-145 - The NIST Definition of Cloud Computing","tier":"standard","publisher":"NIST"}],"draft":true}