Cloud er ikke automatisk sikkert. AWS, Azure og Google Cloud sikrer datacentre, hardware og platform, men I har selv ansvaret for brugere, adgange, konfiguration og data. De fleste cloud-brud skyldes fejl på kundens side, fx en åben storage-bucket eller en admin-konto uden MFA.
Er cloud automatisk sikkert?#
Nej. Der er en udbredt misforståelse blandt danske SMV'er, der flytter til AWS, Azure eller Google Cloud (GCP): "Nu er sikkerheden Amazons/Microsofts problem." Det er den ikke. Cloud-udbyderne leverer en meget sikker platform, men det er jeres ansvar at bruge den korrekt.
I Thales' Cloud Security Study 2024 var menneskelige fejl og fejlkonfiguration den hyppigste årsag til cloud-databrud med 31%, efterfulgt af udnyttelse af kendte sårbarheder (28%) og manglende MFA (17%). En åben storage-bucket, en admin-konto uden MFA eller en database, der er eksponeret mod internettet. Det er jeres ansvar, og det er også der, I kan gøre den største forskel.
Denne artikel gennemgår de grundlæggende koncepter, du skal forstå, uanset om du kører AWS, Azure eller GCP.
Hvad er shared responsibility-modellen i cloud?#
Shared responsibility-modellen (delt ansvar) betyder, at cloud-udbyderen sikrer selve platformen, mens I sikrer det, I bygger og lægger på den. AWS, Azure og Google Cloud bruger alle modellen, og grænsen flytter sig afhængigt af, hvilken type tjeneste I bruger.
Hvad sikrer cloud-udbyderen?
- Fysisk sikkerhed i datacentre
- Hardware og hypervisor
- Netværksinfrastruktur på tværs af regioner
- Grundlæggende platformstjenester (compute, storage, netværk)
- Compliance-certificeringer (ISO 27001, SOC 2, PCI-DSS mv.)
Dette er reelt uden for din rækkevidde og fungerer bedre, end du kunne opnå selv.
Hvad skal I selv sikre i IaaS, PaaS og SaaS?
Her flytter grænsen sig alt efter tjenestetype:
IaaS (Infrastructure as a Service, fx EC2, Azure VM, Compute Engine):
- Operativsystem og patches
- Applikationer og deres sårbarheder
- Netværkskonfiguration (security groups, firewall-regler)
- Adgangsstyring (IAM)
- Data og kryptering
PaaS (Platform as a Service, fx App Service, App Engine, Elastic Beanstalk):
- Applikationskonfiguration
- Adgangsstyring
- Data og kryptering
- (Udbyderen håndterer OS og runtime)
SaaS (Software as a Service, fx Microsoft 365, Google Workspace):
- Brugeradministration
- Adgangsstyring
- Data-klassificering og deling
- Konfiguration (fx sharing policies, DLP)
Reglen er enkel: jo mere abstraktion, jo mindre skal du håndtere, men adgangsstyring og data er altid dit ansvar.
Hvorfor er adgangsstyring (IAM) det vigtigste i cloud?#
Identity and Access Management (IAM) er den kontrol, der oftest fejler i praksis, og den, der har størst konsekvens, når den fejler. AWS IAM, Azure Entra ID og GCP IAM er hver især omfattende systemer, men de deler nogle grundprincipper.
Least privilege: giv kun den adgang, der er brug for
Giv altid den mindste adgang, der er nødvendig for at udføre opgaven. En medarbejder der skal læse fra én database, skal ikke have adgang til hele kontoen. En automatiseret proces, der skal skrive til én storage-bucket, skal ikke have "AdministratorAccess".
Det lyder banalt, men i praksis ser man konstant "det er nemmere lige at give det hele", særligt i små virksomheder uden et dedikeret cloud-team. Konsekvensen kommer, når et enkelt kompromitteret login eller en lækket nøgle giver adgang til alt.
MFA på root- og admin-konti uden undtagelser
- AWS: MFA på root-brugeren. Root-brugeren skal ikke bruges i dagligdagen. Opret en administrativ IAM-bruger og lås root væk med MFA-nøgle i et pengeskab.
- Azure: MFA på Global Administrator-konti. Overvej at kræve MFA på alle brugere via Conditional Access.
- GCP: MFA på Organization Admin og Owner-roller.
Ideelt er MFA baseret på authenticator-app eller hardware-nøgle, ikke SMS.
Brug service accounts til automatisering, ikke personlige logins
Applikationer og scripts skal ikke logge ind med en medarbejders personlige konto. Brug dedikerede service accounts / IAM roles:
- AWS: IAM Roles til EC2, Lambda mv., undgå at hardkode access keys
- Azure: Managed Identities til App Service, VM's mv.
- GCP: Service Accounts med workload identity
Fordelen ud over sikkerhed: når en medarbejder forlader virksomheden, skal du ikke pludselig regne ud, hvilke systemer der bryder sammen.
Undgå delte konti i cloud
"Vi har én bruger, som hele teamet logger ind på" er en garanti for problemer. Hver medarbejder skal have sin egen login, med sine egne rettigheder, og sin egen aktivitetslog. Det er både et sikkerheds- og et compliancespørgsmål (GDPR, revision).
Rotér access keys og API-nøgler
Access keys, service account keys og API-tokens skal ideelt roteres jævnligt. Hvis I ikke ved præcis hvor jeres keys ligger, er svaret ikke at lade være. Det er at finde dem, rotere dem og bygge et system, hvor det næste gang er nemt.
Kryptering i cloud: data i transit og i hvile#
Kryptering er både forventet af moderne compliance-frameworks og aktivt understøttet af alle cloud-platforme.
Kryptering af data i transit (TLS)
- Al kommunikation mellem klient og cloud skal gå over TLS (HTTPS)
- Intern trafik mellem cloud-tjenester bør også være krypteret. Det er default de fleste steder, men tjek konfigurationen
- Sørg for at TLS-versioner er opdaterede (TLS 1.2 minimum, TLS 1.3 hvor muligt) og at ældre cipher suites er slået fra
Kryptering af data i hvile i AWS, Azure og GCP
- AWS S3: siden januar 2023 krypteres alle nye objekter automatisk med SSE-S3 (AWS). Overvej SSE-KMS, hvis I vil styre nøglerne og have revisionsspor på brugen af dem
- Azure Blob Storage: kryptering er slået til som standard og kan ikke slås fra, men tjek om I har brug for kundestyrede nøgler
- GCP Cloud Storage: kryptering aktiveret som default med Google-managed keys. Overvej Customer-Managed Encryption Keys (CMEK) til følsomme data
- Databaser: aktiver TDE (Transparent Data Encryption) eller equivalent
- Persistente diske og volumer: kryptering aktiveret
Til de fleste SMV'er er platform-managed keys tilstrækkelige. Til særligt følsomme data (persondata i særlige kategorier, sundhedsdata) kan customer-managed keys give bedre kontrol og revisionsspor.
Hvad er de mest almindelige fejlkonfigurationer i cloud?#
De fejl, der går igen, er åbne storage-buckets, databaser eksponeret mod internettet, overprivilegerede IAM-roller og manglende logning. I de kendte cloud-brud er det sjældent cloud-udbyderen, der fejler. Det er kunden, der har konfigureret noget forkert.
Åbne S3-buckets og storage-containere
S3-buckets, Azure Blob Containers og GCS-buckets, der er markeret som offentlige, nogle gange bevidst, oftere ved et uheld. Millioner af filer med persondata, dokumenter og backups har været frit tilgængelige på internettet, fordi nogen klikkede "Public" for at teste noget og glemte at sætte det tilbage.
Forsvar:
- AWS: hold "Block Public Access" slået til. Det er standard på nye buckets siden april 2023 (AWS), men ældre buckets kan stadig være åbne
- Azure: slå "Allow Blob anonymous access" fra på storage-kontoen
- GCP: brug "public access prevention" på buckets eller som organisationspolitik
- Overvåg for offentlige buckets med værktøjer som AWS Config, Azure Policy, GCP Security Command Center
- Kræv aktiv beslutning for at gøre en bucket offentlig
Databaser eksponeret mod internettet
MongoDB, Elasticsearch, Redis og relationsdatabaser der er åbne mod internettet, ofte uden autentifikation. Har været en af de mest almindelige kilder til datalæk i årevis.
Forsvar:
- Databaser skal ikke eksponeres direkte mod internettet
- Brug VPC/VNet med security groups/network security groups, der kun tillader trafik fra kendte IP-ranges
- Kræv autentifikation, og MFA hvor muligt
- Aktivér logning af adgang
Overprivilegerede IAM-roller
Roller med *:*: adgang til alt. Enten fra dovenskab eller fra copy-paste af eksempelkode. Når rollen kompromitteres, bliver alt kompromitteret.
Forsvar:
- Regelmæssig gennemgang af roller (AWS IAM Access Analyzer, access reviews og PIM i Entra ID, GCP IAM Recommender)
- Fjern ubrugte tilladelser
- Split roller efter funktion
Manglende logning i cloud
Uden logs kan I ikke opdage, hvad der skete under et brud, og ikke leve op til compliancekrav.
Forsvar:
- AWS: aktiver CloudTrail på alle regioner, gem logs i separat, låst konto
- Azure: aktiver Activity Log og send til Log Analytics workspace
- GCP: aktiver Cloud Audit Logs
- Opbevaring: fastlæg en periode ud fra jeres egne krav. Mange vælger mindst 12 måneder, så et brud, der opdages sent, stadig kan efterforskes
Indbyggede sikkerhedsværktøjer i AWS, Azure og GCP#
Alle tre store cloud-udbydere tilbyder indbyggede sikkerhedsværktøjer. De fleste koster penge ud over en grundpakke, men de er tæt integreret med platformen og er et naturligt sted for en SMV at starte.
Sikkerhedsværktøjer i AWS
- AWS Security Hub: samler findings på tværs af AWS-sikkerhedstjenester og third-party
- GuardDuty: trusselsdetektion baseret på VPC flow logs, DNS logs, CloudTrail
- Config: konfigurationsovervågning og compliance-tjek
- IAM Access Analyzer: finder ressourcer med bred adgang
Sikkerhedsværktøjer i Azure
- Microsoft Defender for Cloud: samlet CSPM- og trusselsdetektionsplatform
- Entra ID Conditional Access: kontekstbaseret adgangsstyring
- Sentinel: SIEM for enterprise-brug
- Azure Policy: governance og compliance
Sikkerhedsværktøjer i Google Cloud
- Security Command Center: samlet security- og risk-management
- Cloud Armor: DDoS-beskyttelse og WAF
- VPC Service Controls: data-exfiltrationsforsvar
- Recommender: automatiske sikkerheds- og optimeringsanbefalinger
Start med grundpakken eller en prøveperiode, og se hvilke fund der dukker op, før I køber mere. Tjek den aktuelle prismodel hos udbyderen, for den ændrer sig jævnligt.
Hvor skal en SMV starte med cloud-sikkerhed?#
Start med admin-kontiene, logning og blokering af offentlig adgang. Hvis I er ved at flytte til cloud eller lige er kommet i gang, er det de otte ting herunder, der giver størst effekt for mindst indsats.
1. Sikr root- og Global Admin-konti først
- AWS: lås root, aktiver MFA, opret separat admin-IAM-bruger, gem root-credentials sikkert
- Azure: MFA på alle Global Admins, brug Privileged Identity Management (PIM) hvis muligt
- GCP: MFA på Organization Admin og Owner-roller
2. Slå logning til fra dag ét
CloudTrail / Activity Log / Cloud Audit Logs skal være aktive før noget produktivt kører. Gem logs i en separat konto eller et separat projekt, og beslut hvor længe de skal opbevares.
3. Bloker offentlig adgang til storage som standard
For storage: block public access på konto/subscription-niveau. For at gøre en bucket offentlig skal det være en aktiv beslutning.
4. Opdel netværket med VPC eller VNet
Kør ikke alt på "default network". Opret separate netværkssegmenter for produktion, test og administration.
5. Slå platformens security posture-tjeneste til
Security Hub (AWS), Defender for Cloud (Azure), Security Command Center (GCP). Selv i grundversionen giver de et overblik af, hvor jeres største fejl er.
6. Automatisér compliance-tjek med politikker
AWS Config Rules, Azure Policy, GCP Organization Policy. Definér de regler I gerne vil håndhæve (fx "ingen offentlige S3-buckets"), og lad platformen tjekke det for jer.
7. Sæt budgetalarmer og hold øje med forbruget
Omkostningsovervågning er ikke en sikkerhedstjeneste, men en uventet faktura kan være det første tegn på misbrug (fx en kompromitteret konto, der bruges til kryptomining). Sæt budget alerts og gennemgå fakturaer månedligt.
8. Træn udviklere og admins i cloud-sikkerhed
Cloud-sikkerhed er en disciplin, ikke en engangsopsætning. Sørg for at udviklere og admins forstår IAM-modellen og shared responsibility, og ikke klikker rundt efter hukommelsen.
Cloud-sikkerhed afhænger af medarbejderne#
Cloud-platformene giver jer stærkere værktøjer, end en SMV kunne bygge selv, men de er komplekse nok til, at én forkert indstilling kan åbne alt.
Mange cloud-brud starter med, at en udvikler, en admin eller en almindelig medarbejder ikke vidste bedre eller tog en genvej. Teknisk beskyttelse virker først, når menneskerne omkring den forstår, hvad der er på spil. Rammer det persondata, gælder de samme 72-timers-regler som ved ethvert andet databrud.
ShieldUp har ikke et selvstændigt cloud-spor til arkitekter. Modulerne om sikker fildeling, passwords og MFA og Microsoft 365 dækker den del, der handler om almindelige medarbejderes adfærd: hvad man deler, hvordan man logger ind, og hvad man gør, når noget ser forkert ud. Læs mere om awareness-træning, eller start gratis.
Ofte stillede spørgsmål om cloud-sikkerhed#
Er cloud sikrere end on-premises?
For de fleste SMV'er: ja, hvis I konfigurerer det korrekt. Cloud-udbyderne investerer milliarder i sikkerhed, som ingen enkelt SMV kan matche. Men "sikrere hvis konfigureret korrekt" er det vigtige forbehold. En dårligt konfigureret cloud kan være mindre sikker end en velvedligeholdt on-prem-server.
Skal produktion og test ligge i separate konti eller projekter?
Ja. Adskillelse på konto-niveau (AWS accounts, Azure subscriptions, GCP projects) er den mest effektive form for isolation. En fejl eller et kompromitteret login rammer så kun ét miljø.
Er det en risiko kun at bruge én cloud-udbyder?
Multi-cloud for sikkerheds skyld er sjældent værd for en SMV. Kompleksiteten stiger markant, og hver ekstra platform er en ny angrebsflade at forstå. Vælg én primær udbyder og gør det godt, medmindre I har konkrete forretningsgrunde til det modsatte.
Må persondata ligge hos amerikanske cloud-udbydere?
Ja, hvis I har et gyldigt overførselsgrundlag, men vælg regioner i EU for persondata om EU-borgere. Overførsler til USA sker i dag typisk under EU-US Data Privacy Framework fra juli 2023, som EU-Retten opretholdt i september 2025 i sagen Latombe (T-553/23). Afgørelsen er appelleret til EU-Domstolen (C-703/25 P), så grundlaget kan ændre sig igen, ligesom det skete med Schrems II i 2020. Brug krypteringsopsætninger, hvor nøglerne holdes af jer eller en EU-part, hvis I har særligt følsomme data, og spørg jeres DPO eller advokat ved tvivl. Se også vores side om GDPR.
Har en SMV brug for en cloud-sikkerhedskonsulent?
Sjældent fast. For små virksomheder kan det sjældent betale sig. Start med at aktivere de indbyggede værktøjer og følge udbyderens well-architected framework (AWS Well-Architected, Azure Well-Architected Framework, Google Cloud Well-Architected Framework). Ved specifikke, større initiativer (cloud-migration, compliance-audit, sikkerhedsvurdering) kan et par dages ekstern konsulentbistand være pengene værd.
Kilder og forskning#
Brancherapporter og officielle rammeværker der understøtter denne artikel.
Cloud-brud: årsagsstatistik
- Thales (2024). 2024 Thales Cloud Security Study: 31% af cloud-databrud skyldtes fejlkonfiguration eller menneskelig fejl, den hyppigste enkeltårsag, baseret på 3.000 respondenter i 18 lande. Link
Standardindstillinger i AWS S3
- AWS (2023). Amazon S3 now automatically encrypts all new objects. Link
- AWS (2023). Amazon S3 now applies two security best practices to all new buckets by default. Link
Overførsel af persondata til USA
- EU-Retten (2025). Pressemeddelelse om dom i sag T-553/23, Latombe mod Kommissionen. Link
Officielle rammeværker