Da SysAdmin a Cloud Security Engineer: un percorso dall'infrastruttura

Perché i sysadmin sono forti cloud security engineer

Gli amministratori di sistemi hanno passato anni a costruire esattamente il modello mentale che il lavoro di cloud security richiede: come i sistemi sono interconnessi, come l'accesso viene concesso e revocato, dove vivono i modi di fallimento e come operare sotto cambiamento. La transizione non è ricostruire quell'intuito. È reindirizzarlo da rack e foreste di Active Directory a account AWS e ruoli IAM.

Il cambiamento è reale ma limitato. Il cloud cambia gli strumenti, la velocità e le superfici di fallimento. Non cambia come si presenta la buona sicurezza di infrastruttura. Gli hiring manager lo sanno, ed è per questo che i sysadmin competono fortemente per i ruoli descritti nella pagina di carriera cloud security engineer e nella pagina di carriera security engineer.

Perché la disciplina sysadmin si trasferisce direttamente alla cloud security

La cloud security non è una disciplina fondamentalmente nuova. È sicurezza di infrastruttura con un modello operativo diverso. Le discipline che già pratichi come sysadmin si proiettano da vicino su come i team di cloud security passano realmente le loro giornate.

La cadenza di patch diventa gestione delle vulnerabilità per AMI, immagini base di container e versioni di servizi gestiti. Il lavoro di backup e ripristino diventa ingegneria della resilienza e ripristino validato contro scenari ransomware. L'igiene degli account utente diventa ciclo di vita IAM e governance degli account break-glass. La segmentazione di rete tra VLAN on-premises diventa progettazione di VPC con subnet privati, security group e routing via Transit Gateway.

Il lavoro day-two in cui i sysadmin sono bravi, monitorare i log, validare il cambiamento, mantenere la linea del minimo privilegio, è esattamente il lavoro che distingue un cloud security engineer utile da qualcuno che riesce solo a passare un esame. Le piattaforme cloud rendono l'automazione più facile e veloce, ma la disciplina sottostante è la stessa che ha mantenuto stabili gli ambienti on-premises nell'ultimo decennio.

Per questo gli hiring manager apprezzano i sysadmin per ruoli di cloud security. I riconvertiti da puro sviluppo spesso mancano di istinto operativo, e gli analisti di sicurezza puri spesso mancano di esperienza pratica di infrastruttura. I sysadmin arrivano con entrambi.

Il modello mentale cloud che ti serve (responsabilità condivisa, identity-first, everything-as-code)

Tre cambi mentali separano i sysadmin che atterrano in ruoli di cloud security da quelli che si bloccano.

Il primo è la responsabilità condivisa. Il provider cloud è responsabile della sicurezza della piattaforma. Tu sei responsabile della sicurezza nella piattaforma. Sembra ovvio, ma la maggior parte degli incidenti cloud risale a clienti che configurano male qualcosa che il provider proteggeva già di default. Il tuo lavoro è il lato cliente del confine.

Il secondo è il pensiero identity-first. Le reti on-premises trattavano il perimetro come controllo primario. Il cloud tratta l'identity come controllo primario. Ogni chiamata API, ogni workload, ogni interazione cross-account è mediata da IAM. AWS IAM, Azure RBAC e Microsoft Entra ID, Google Cloud IAM e Workload Identity Federation sono il nuovo perimetro. Se non capisci role chaining, condition keys, controllo di accesso basato su attributi e flussi assume-role, non puoi fare cloud security in profondità.

Il terzo è everything-as-code. La cloud security in click-ops si stabilizza rapidamente. I team moderni descrivono reti, identity, regole di detection e baseline di compliance in Terraform, OpenTofu, Pulumi o Bicep. Le pull request sono il modo in cui avviene il cambiamento. Il code review è il modo in cui il rischio viene filtrato. Se non hai mai gestito infrastruttura tramite version control, quel gap è la singola cosa più importante da chiudere.

Lo stack di skill IaC security (Terraform + Checkov + Pulumi + Open Policy Agent)

L'infrastructure as code è il punto di ingresso per shift-left security su piattaforme cloud. Lo stack minimo viable:

Terraform o OpenTofu per infrastruttura dichiarativa. Pulumi se il tuo team preferisce linguaggi general-purpose come TypeScript o Python. CloudFormation e Bicep restano validi rispettivamente nelle shop AWS e Azure.

Analisi statica con Checkov, tfsec, KICS o Trivy. Questi scanner intercettano bucket S3 pubblici, flag di cifratura mancanti, security group troppo permissivi e policy IAM con azioni wildcard prima che raggiungano la produzione. La maggior parte dei team di cloud security blocca le pull request con almeno uno di questi strumenti.

Policy as code con Open Policy Agent e Conftest, o Sentinel se operi Terraform Cloud. Questo permette di codificare regole specifiche dell'organizzazione, ad esempio vietare load balancer pubblici negli account di produzione o richiedere tag per attribuzione costi e risposta agli incidenti.

Detection del drift con AWS Config, Azure Policy o moduli personalizzati di GCP Security Command Center. Il punto non è solo trovare il drift ma riportarlo nel repository IaC come fonte di verità.

Se riesci a costruire un piccolo repository di riferimento che provisiona una landing zone hardened, scansiona ogni cambiamento con Checkov e blocca i merge in caso di violazioni di policy, hai un artefatto di portfolio che si mappa direttamente su una job description di cloud security engineer.

Kubernetes Security è la falesia di skill più dura (e dove la domanda è più alta)

Kubernetes è dove la cloud security separa i candidati forti dal resto. La piattaforma espone più superficie di configurazione di qualsiasi account cloud, e la maggior parte dei cluster di produzione è mal configurata in almeno un modo materiale.

Le competenze che contano:

Role-Based Access Control oltre cluster-admin. I workload reali hanno bisogno di ruoli namespaced, service account con scope e igiene dei binding. Il service account di default in ogni namespace è il percorso di privilege escalation più comune.

NetworkPolicy come primo livello di segmentazione, seguito da policy di service mesh in Istio, Linkerd o Cilium per ambienti che ne hanno bisogno. Senza NetworkPolicy ogni pod può parlare con ogni altro pod, l'equivalente cloud di una VLAN piatta.

Pod Security Admission, il sostituto della deprecata PodSecurityPolicy. La maggior parte dei team accoppia PSA con OPA Gatekeeper o Kyverno per controlli di admission più ricchi: bloccare container privilegiati, richiedere utenti non-root, imporre allow-list di registry e richiedere immagini firmate.

Workload identity. I pod dovrebbero autenticarsi alle API cloud tramite IRSA su AWS, Workload Identity su GCP o Azure AD Workload Identity. Le credenziali statiche di lunga durata in variabili di ambiente di container sono il singolo pattern di breach cloud-native più grande.

Controlli di supply chain inclusi generazione SBOM con Syft, scansione vulnerabilità con Trivy o Grype e verifica firme con Cosign e Sigstore. SLSA e in-toto forniscono il vocabolario di framework, e qualsiasi team che prenda sul serio la supply chain si aspetterà che tu li conosca.

Se costruisci profondità genuina in Kubernetes Security, diventi difficile da sostituire. La pagina di carriera security engineer segnala Kubernetes come requisito senior ricorrente.

CSPM, CWPP, CNAPP: cosa significano davvero questi acronimi

Il mercato del tooling di cloud security è denso di acronimi. Tre contano per qualsiasi sysadmin che entra.

Cloud Security Posture Management, o CSPM, valuta in continuo la configurazione cloud rispetto a benchmark come CIS, PCI DSS o baseline interne. AWS Security Hub, Azure Defender for Cloud, GCP Security Command Center e strumenti di terze parti come Wiz, Prisma Cloud e Orca sono gli esempi principali. CSPM risponde alla domanda, questo account è configurato come abbiamo detto che dovrebbe essere.

Cloud Workload Protection Platforms, o CWPP, monitorano i workload in esecuzione per minacce: macchine virtuali, container e serverless. AWS GuardDuty per rilevamento di minacce in runtime, Microsoft Defender for Servers, Microsoft Sentinel per correlazione SIEM e strumenti runtime come Falco sono CWPP. CWPP risponde a, sta succedendo qualcosa di brutto in questo momento.

Cloud-Native Application Protection Platforms, o CNAPP, raggruppano CSPM, CWPP, scansione IaC, analytics di identity e a volte data security in un singolo prodotto. CNAPP è la direzione del mercato e l'ombrello sotto cui si collocano la maggior parte degli RFP dei vendor.

Non hai bisogno di padroneggiare ogni prodotto. Hai bisogno di poter ragionare su quale controllo appartiene a quale livello e di articolare perché un finding CSPM che dice bucket S3 pubblico è diverso da un finding CWPP che dice istanza EC2 che contatta C2 noto.

La decisione delle cert tre cloud: AWS Security Specialty, Azure SC-100, GCP PCSE

Scegli prima una piattaforma. La familiarità superficiale su tre è costantemente meno assumibile della profondità reale su una.

Percorso AWS: Solutions Architect Associate come prerequisito per il vocabolario, poi AWS Certified Security Specialty (SCS-C02) come credenziale specifica di sicurezza. Mercato del lavoro più grande, ecosistema di tooling più ampio, scelta di default in assenza di altri vincoli. La pagina di certificazione AWS Security Specialty dettaglia lo scope dell'esame.

Percorso Azure: AZ-104 per vocabolario fondamentale, poi AZ-500 (Microsoft Certified: Azure Security Engineer Associate). Per ruoli a livello architect, SC-100 (Cybersecurity Architect Expert) è la credenziale senior, spesso accoppiata con SC-200 per lavoro orientato al SOC in Microsoft Sentinel. Scelta forte per enterprise, industrie regolate e lavoro governativo in Europa. Vedi la pagina di certificazione Azure Security Engineer per la guida di preparazione.

Percorso GCP: Professional Cloud Security Engineer (PCSE) è la credenziale focalizzata. Il mercato è più piccolo di AWS o Azure ma paga bene presso datori tech-forward. Da accoppiare con Professional Cloud Architect per ampiezza. La pagina di certificazione GCP Security riassume l'esame.

Credenziali cross-platform utili includono CCSP di ISC2 per ruoli orientati alla governance e CKS (Certified Kubernetes Security Specialist) per qualsiasi team che gestisca cluster.

Contesto compliance UE: NIS2, DORA, GDPR per il cloud

I datori europei filtrano sempre più sulla fluidità di compliance, e il pavimento regolatorio è salito nettamente.

NIS2, recepita in legge nazionale in tutta l'UE, espande l'ambito degli obblighi di cybersicurezza a molti più settori e alza i requisiti su reporting di incidente, sicurezza della supply chain e responsabilità del management. I workload cloud nei settori in scope hanno bisogno di mapping di controllo chiari, e l'evidence CSPM è spesso parte dell'audit trail.

DORA, il Digital Operational Resilience Act, si applica ai servizi finanziari e ai loro terzi critici, inclusi i provider cloud. Impone gestione del rischio ICT, mantenimento di un registro dei terzi, threat-led penetration testing per entità significative e rigorosa classificazione degli incidenti. Dai cloud security engineer in banche, assicurazioni e fintech ci si aspetta una conoscenza operativa di DORA.

Il GDPR continua a plasmare i requisiti di residenza dei dati, cifratura e logging degli accessi. Per il cloud, l'implicazione pratica è che i workload che gestiscono dati personali UE hanno bisogno di documentazione chiara dei flussi di dati, strategie di gestione delle chiavi che tengano conto dell'esposizione ai sub-processor ed evidence audit-grade del controllo di accesso.

Non ci si aspetta che tu sia un avvocato. Ci si aspetta che tu traduca fra regolatori, auditor e ingegneri, e che tu sappia quali regole AWS Config, quali iniziative Azure Policy o quali finding GCP Security Command Center forniscono l'evidence richiesta da ciascun controllo.

Un piano di transizione realistico di 9 mesi

La timeline di transizione che funziona davvero per i sysadmin in attività:

Mesi 1 e 2: scegli una piattaforma principale e completa la certificazione di architect a livello associate. L'obiettivo è il vocabolario di piattaforma e la capacità di navigare console e CLI sotto pressione.

Mesi 3 e 4: deep dive su identity. Costruisci una organizzazione AWS multi-account con Control Tower o equivalente, configura SSO da un identity provider esterno, scrivi policy IAM per tre persona di workload realistici e documenta i modi di fallimento che trovi.

Mesi 5 e 6: infrastructure as code e scansione IaC. Riscrivi il tuo ambiente di laboratorio in Terraform o OpenTofu, aggiungi Checkov a un hook pre-commit e costruisci un ruleset minimo di Open Policy Agent che blocchi storage pubblico e volumi non cifrati.

Mese 7: sicurezza container e Kubernetes. Solleva un cluster EKS, AKS o GKE, hardalo contro il benchmark CIS, installa Falco per detection runtime e dimostra generazione SBOM più firma immagine su un workload di esempio.

Mese 8: supera la certificazione specifica di sicurezza, AWS Security Specialty, AZ-500 o GCP PCSE.

Mese 9: rifinitura del portfolio e ricerca lavoro. Pubblica un write-up del laboratorio, contribuisci una regola di detection o un modulo IaC a un progetto open-source e inizia ad applicare a ruoli cloud security engineer. Il programma del bootcamp è costruito intorno a questo tipo di progressione per progetto e comprime il loop di apprendimento per professionisti in attività.

Realtà salariale: da sysadmin a cloud security junior a senior nell'UE

Il panorama retributivo UE premia il movimento in modo chiaro.

I ruoli di sysadmin e operazioni di infrastruttura in Europa Occidentale pagano tipicamente fra 35.000 e 45.000 EUR per professionisti mid-level, con specialisti senior on-premises che raggiungono i cinquanta bassi.

I ruoli di cloud security engineer junior e mid-level, l'obiettivo realistico dopo una transizione riuscita, pagano fra 55.000 e 80.000 EUR a seconda della località e del settore. Berlino, Amsterdam, Dublino, Parigi e Madrid si raggruppano intorno alla metà di quella banda, con Londra e Zurigo sopra.

I ruoli di cloud security engineer senior, raggiunti tipicamente tre o cinque anni dopo la transizione, pagano fra 75.000 e 95.000 EUR. Specialisti in Kubernetes Security, detection engineering o industrie regolate spingono l'estremo superiore.

I ruoli di cloud security architect in settori regolati superano regolarmente 100.000 EUR nei principali hub europei. Il lavoro di consulenza in firme Big 4 e boutique di sicurezza segue una curva simile con utilizzo fatturabile e viaggi come variabili.

Il delta salariale fra sysadmin e cloud security engineer è reale, tipicamente fra 15.000 e 30.000 EUR al punto della transizione, e la traiettoria sopra è più ripida delle carriere ops tradizionali. Il premio è sostenuto e non transitorio perché la domanda supera l'offerta anno dopo anno.

Dove si inserisce il bootcamp

Il Bootcamp Cybersecurity Unihackers copre i fondamentali di cloud security nel modulo m11 (Security Engineering and Emerging Topics), insieme al contesto di sicurezza più ampio di cui hanno bisogno i cloud security engineer. Per i sysadmin con basi forti di infrastruttura, il bootcamp aggiunge il contesto di sicurezza e offensivo che le basi pure di infrastruttura mancano. Leggi il programma per il dettaglio modulo per modulo.

Blocchi comuni

Tre pattern spiegano la maggior parte delle transizioni sysadmin verso cloud security bloccate:

1. Distribuirsi su tre cloud prima di padroneggiarne una. La familiarità superficiale vale meno della profondità reale. La maggior parte dei ruoli cloud security senior vuole expertise specifica per piattaforma.

2. Saltare l'infrastructure as code. Il lavoro cloud security moderno presuppone fluidità in IaC. Esistono cloud security engineer click-ops ma tendono a fermarsi a livelli junior.

3. Sottovalutare la complessità di identity. L'identity cloud è il vettore di attacco più comune e la competenza più difficile da fingere. Costruisci profondità genuina qui.

La transizione è reale e ben pagata, ma premia la profondità sull'ampiezza. I cloud security engineer senior hanno prima costruito bene una piattaforma, poi espanso.