Cloud SecOps Engineer vs Security Architect: sådan vælger du rolle og vej

I cloudmiljøer betyder Security Operations Engineering at overvåge, styre og forbedre sikkerheden gennem detektion, hændelseshåndtering, identitetskontrol, automatisering og løbende compliance.

Rollen er blevet mere relevant, fordi mange danske organisationer ikke længere driver én afgrænset infrastruktur. De arbejder ofte med Azure til identitet og Microsoft 365, AWS til applikationsplatforme, Google Cloud til data- eller analysearbejde og SaaS-løsninger på tværs af forretningen. Det gør cloud-sikkerhed mindre som klassisk perimeterbeskyttelse og mere som en driftsdisciplin, hvor signaler, rettigheder, politikker og konfigurationer hele tiden skal valideres.

En Cloud Security Operations Engineer sidder typisk tættere på den daglige drift end en Security Architect og tættere på cloud-platformene end en traditionel SOC-analytiker. Det er en rolle for personer, der kan læse alarmer, forstå IAM, tale med platformsteams, skrive eller vedligeholde automatisering og forklare risiko på en måde, som både udviklere og ledere kan handle på.

Hvor rollen adskiller sig fra SOC og arkitektur

Cloud SecOps forveksles ofte med både SOC-analyse og cloud security architecture. Overlap findes, men leverancerne er forskellige. En SOC-analytiker fokuserer primært på triage, eskalering og analyse af sikkerhedshændelser. En Security Architect designer principper, målbilleder og kontrolmønstre. En Cloud Security Operations Engineer får kontrollerne til at virke i drift, måler om de dækker reelle risici og forbedrer dem, når cloudmiljøet ændrer sig.

I praksis kan forskellen ses i en almindelig IAM-fejlkonfiguration. SOC’et ser måske en alarm om mistænkelig brug af en privilegeret konto. Arkitekten har defineret princippet om least privilege, conditional access og adskillelse af administratorroller. Cloud SecOps-rollen undersøger, hvorfor kontoen havde for brede rettigheder, om samme mønster findes i andre subscriptions eller accounts, hvordan politikken kan håndhæves med policy-as-code, og hvordan en tilsvarende hændelse detekteres tidligere næste gang.

Den stærke Cloud SecOps-profil kan derfor både reagere og forbedre. Det er ikke nok at lukke en alarm; rollen skal også reducere sandsynligheden for, at samme klasse af fejl gentages. Det kræver teknisk dybde i platformen og en driftsmæssig forståelse for, hvad der kan ændres uden at stoppe forretningen.

Hverdagen i en Cloud Security Operations Engineer-rolle

En arbejdsdag kan begynde med gennemgang af sikkerhedsalarmer, men den ender sjældent der. Cloud SecOps handler lige så meget om at forbedre signalerne som om at reagere på dem. Hvis et team modtager mange støjende alarmer fra offentligt eksponerede storage-ressourcer, er den vigtige opgave ikke kun at lukke de enkelte fund. Det er at finde mønstret, indføre en forebyggende policy, tilpasse detektionsreglen og dokumentere en playbook, så både sikkerhed og platformsteam ved, hvad der skal ske.

Derfor arbejder rollen ofte på tværs af fire spor: overvågning, konfigurationsstyring, identitet og respons. Overvågning omfatter logkilder, SIEM-regler og hændelseskorrelation. Konfigurationsstyring handler om at opdage og rette usikre cloudressourcer. Identitet omfatter adgangsmodeller, privilegerede roller, servicekonti og føderation. Respons dækker undersøgelse, containment, recovery og læring efter hændelser.

Målepunkterne bør afspejle den drift, rollen påvirker. MTTD viser, hvor hurtigt organisationen opdager relevante hændelser, mens MTTR viser, hvor hurtigt den bringer risikoen ned igen. Policy-dækning viser, om kritiske kontroller faktisk håndhæves på subscriptions, accounts, projects og workloads. Least-privilege-fremdrift viser, om brede rettigheder bliver reduceret over tid, ikke kun diskuteret i principper.

Cloud-native værktøjer og hvornår de bruges

Cloud SecOps kræver fortrolighed med platformenes egne sikkerhedstjenester, fordi mange hændelser først bliver synlige i cloud-native telemetri. Et team kan bruge et centralt SIEM, men de bedste signaler kommer ofte fra identitetslogs, control plane-aktivitet, container-telemetri, endpoint-signaler, netværksflow og konfigurationsfund. NIST-vejledning om incident response og ENISA-materiale om cloud security kan bruges som neutrale rammer, men den daglige implementering sker i de konkrete platforme.

I Azure-miljøer arbejder rollen typisk med Microsoft Sentinel til detektion, korrelation og KQL-baserede analyser, mens Microsoft Defender for Cloud bruges til posture management, anbefalinger og workload-beskyttelse. I AWS er Amazon GuardDuty relevant til trusselspåvisning, mens AWS Security Hub samler sikkerhedsfund og compliance-signaler fra flere tjenester. I Google Cloud bruges Security Command Center til posture og risikofund, mens Chronicle kan indgå i detektion, analyse og respons på tværs af større datamængder.

Valget handler ikke kun om produktnavne. Hvis organisationens identitet, endpoints og collaboration allerede er stærkt forankret i Microsoft-økosystemet, vil Sentinel og Defender ofte være naturlige at prioritere. Hvis produktplatformen kører tungt på AWS, er GuardDuty, Security Hub, IAM Access Analyzer og CloudTrail centrale kilder. Hvis data- og analyseplatforme ligger i Google Cloud, bør Security Command Center, audit logs og Chronicle forstås som en del af den operative sikkerhedsmodel.

En konkret mini-case viser forskellen mellem værktøj og praksis. En udvikler giver en CI/CD-servicekonto brede rettigheder for at få en deployment til at virke. Det løser et kortsigtet problem, men øger risikoen, hvis pipeline-tokenet misbruges. En Cloud SecOps Engineer bør kunne opdage rettigheden gennem posture- eller IAM-analyse, afgrænse den til nødvendige handlinger, indføre en policy der blokerer tilsvarende brede tildelinger og tilføje en detektionsregel for ændringer på privilegerede servicekonti.

Dansk og europæisk compliance i praktisk drift

For danske organisationer er cloud security operations tæt forbundet med GDPR, Datatilsynets vejledninger og interne krav til auditability. Det betyder ikke, at Cloud SecOps-rollen skal være jurist. Det betyder, at tekniske valg om logging, datalokalitet, adgangsstyring og retention skal kunne forklares og dokumenteres.

Logning er et godt eksempel. Sikkerhedsteams vil ofte gemme detaljerede logs længe nok til at kunne opdage langsomme angreb og gennemføre efterforskning. Samtidig kan logs indeholde personoplysninger, brugeridentifikatorer, IP-adresser eller aktivitetsdata. Rollen skal derfor samarbejde med compliance, privacy og platformsejere om formål, opbevaringsperiode, adgang til logs og placering af logdata. En teknisk korrekt loggingstrategi kan stadig være problematisk, hvis adgangen er for bred eller retention ikke er begrundet.

Multi-tenant governance er en anden praktisk udfordring. Mange virksomheder har flere Azure tenants, AWS accounts eller Google Cloud projects, ofte som resultat af opkøb, selvstændige udviklingsteams eller historiske beslutninger. Cloud SecOps skal skabe overblik uden at kvæle teamsenes leveranceevne. Det kræver standardiserede guardrails, fælles logkilder, tydeligt ejerskab og automatiseret rapportering, ellers bliver governance afhængig af manuelle kontroller, der hurtigt forældes.

Kompetencer, der gør rollen ansættelig

Arbejdsgivere efterspørger sjældent en person, der kun kan nævne cloud-sikkerhedsbegreber. De leder efter beviser på, at kandidaten kan få sikkerhed til at fungere i et rigtigt miljø. Det kan være erfaring med at reducere for brede IAM-rettigheder, skrive KQL-detektioner, forbedre en incident playbook, indføre policy-as-code eller etablere logdækning for kritiske workloads.

De mest almindelige fejl hos aspiranter er at fokusere for ensidigt på certifikater, overse cloud-native telemetri og undervurdere infrastructure-as-code. Certificeringer kan give struktur og fælles sprog, men de erstatter ikke praktisk erfaring med fejlfinding, rettigheder, logs og automatisering. En kandidat, der kan forklare en gennemført least-privilege-migration eller en testet incident response-øvelse, står ofte stærkere end en kandidat med en bred, men overfladisk certificeringsliste.

En god læringsplan bør derfor bygges omkring laboratorier. Først etableres en sandbox med realistiske ressourcer, identiteter og logkilder. Dernæst indføres policy-as-code for at blokere eller markere usikre konfigurationer. Derefter bygges detection-as-code, hvor regler versioneres og testes. Til sidst gennemføres incident response-øvelser, hvor kandidaten måler, hvor hurtigt hændelsen opdages, begrænses og dokumenteres.

1. Byg en sandbox i den cloudplatform, organisationen eller jobmålet bruger mest.
2. Aktivér centrale logs for identitet, control plane og netværks- eller workloadsignaler.
3. Skab en bevidst fejlkonfiguration, for eksempel en for bred servicekonto eller offentlig storage.
4. Ret fejlen med least privilege og dokumentér ændringen som kode eller policy.
5. Skriv en detektionsregel og test, om alarmen udløses på den forventede aktivitet.
6. Gennemfør en kort incident response-øvelse og noter forbedringer i playbooken.

Denne type øvelse gør læringen konkret. Den træner både den tekniske håndtering og den dokumentation, der gør arbejdet brugbart for drift, ledelse og revision.

Certificeringer: vælg efter platform og rolle

Certificeringsvalg bør begynde med to spørgsmål: hvilken cloudplatform fylder mest i den nuværende eller ønskede rolle, og om målet er operations, arkitektur eller governance. En Azure-tung organisation peger ofte mod Microsoft AZ-500 for Azure security engineering og SC-200 for security operations. En mere arkitekturrelevante vej kan omfatte SC-100, når kandidaten allerede har praktisk sikkerhedserfaring og skal arbejde med strategiske sikkerhedsmodeller.

I AWS-miljøer er AWS Certified Security – Specialty relevant for personer, der skal forstå sikkerhedskontroller, logging, identitet og beskyttelse i AWS. I Google Cloud-miljøer passer Professional Cloud Security Engineer bedre til roller, hvor Google Cloud er den primære platform. CISSP, CCSP, CISM og CISA kan stadig være værdifulde, men de bør vælges, når rollen kræver bredere sikkerhedsledelse, cloud governance eller auditforståelse frem for daglig cloud operations.

En praktisk beslutningsramme er derfor enkel. Operations-profiler bør prioritere den platform, de skal overvåge og forbedre dagligt. Arkitekturprofiler bør supplere med certificeringer, der tester design, risikostyring og tværgående kontrolmodeller. Personer på vej fra traditionel SOC til Cloud SecOps bør vælge én primær platform først og bygge dybde, før de spreder sig over alle tre store cloududbydere.

Readynez kan indgå som en struktureret træningspartner, når en kandidat allerede har valgt platform og certificeringsmål, men kursusvalg bør følge den tekniske retning frem for ønsket om at samle flest mulige badges. Det bedste udbytte kommer, når undervisning kombineres med egne labs, loganalyse og praktiske forbedringsprojekter.

Karriereprogression fra SOC eller platformsteam

Overgangen til Cloud SecOps sker ofte fra to retninger. SOC-analytikere har erfaring med alarmer, hændelser og triage, men skal opbygge dybere forståelse for cloudkontrolplanet, IAM og automatisering. Cloud- eller platform engineers forstår drift, netværk, deployment og infrastruktur, men skal styrke trusselsforståelse, detektion og respons.

Den mest overbevisende progression dokumenteres gennem projekter. En SOC-profil kan for eksempel bygge cloud-detektioner, reducere false positives og koble alarmer til klare playbooks. En platformprofil kan indføre guardrails, least-privilege-roller, loggingstandarder og sikkerhedstests i CI/CD. Begge veje kan føre videre til senior Cloud SecOps, team lead eller security architecture, men næste skridt afhænger af, om personen trives bedst med drift, design eller ledelse.

Ansættelsesmæssigt er det en fordel at kunne beskrive konkrete forbedringer uden at afsløre følsomme detaljer. Eksempler kan være etablering af centraliseret cloudlogging, reduktion af permanente administratorrettigheder, indførelse af incident playbooks eller implementering af policies for kryptering og netværkseksponering. Det viser modenhed, fordi kandidaten ikke kun forstår værktøjerne, men også kan få dem indført i en organisation.

Udfordringer i danske organisationer

De største udfordringer er sjældent rent tekniske. Identitetsføderation på tværs af tenants, gamle undtagelser i cloudmiljøet, uklart ejerskab af workloads og uens modenhed mellem udviklingsteams skaber mere friktion end selve værktøjerne. Derudover kan driftsomkostninger blive et sikkerhedstema. Det er let at aktivere flere logkilder, længere retention og avanceret analyse; det er sværere at vælge en model, der giver tilstrækkelig detektion uden unødvendige omkostninger.

Shared responsibility-modellen er også en kilde til misforståelser. Cloududbyderen sikrer dele af infrastrukturen, men kunden er stadig ansvarlig for mange valg om data, identitet, konfigurationer, adgang og applikationssikkerhed. En Cloud SecOps Engineer skal kunne oversætte den model til konkrete kontroller, så ingen antager, at en sikker cloudplatform automatisk betyder et sikkert cloudmiljø.

Alert fatigue kræver særlig opmærksomhed. Når alt klassificeres som kritisk, mister driften evnen til at prioritere. En moden Cloud SecOps-funktion arbejder derfor med tuning, kontekst og automatiseret berigelse. Alarmer skal kobles til forretningskritikalitet, identitetsrisiko og eksponeringsgrad, ellers ender teamet med at bruge tid på støj, mens reelle angreb udvikler sig langsomt i baggrunden.

Et realistisk næste skridt

Den mest robuste vej ind i Cloud Security Operations Engineering er at vælge én primær platform, bygge en labportefølje og dokumentere forbedringer, der ligner rigtige driftsopgaver. Certificeringer kan understøtte den vej, men praktisk bevis vejer tungt: en detektionsregel, en IAM-forbedring, en policy, en playbook og en kort rapport om, hvad der blev målt før og efter.

Et godt næste skridt er at kortlægge den cloudplatform, der allerede bruges i organisationen, og vælge et lille sikkerhedsproblem, der kan løses fra ende til anden. Det kan være offentlig eksponering, manglende logdækning, privilegerede servicekonti eller uens tagging af kritiske ressourcer. Når problemet er løst med både teknisk kontrol og operationel dokumentation, begynder erfaringen at ligne det arbejde, rollen faktisk kræver.

Readynez kan være relevant i den fase, hvor kandidaten vil strukturere forberedelsen til en valgt certificering, men karriereudviklingen bør fortsat bindes til målbare forbedringer i cloudmiljøer. Cloud SecOps belønner personer, der kan kombinere sikkerhedstænkning med drift, automatisering og samarbejde på tværs af teams.