0Pricing
Security+ Academy · Lezione

Sicurezza del serverless e delle funzioni

Identifichi la superficie d'attacco specifica delle funzioni serverless (ruoli IAM con privilegi eccessivi, injection di eventi e rischi delle dipendenze) e applichi controlli di least privilege e convalida degli input.

Sicurezza del serverless e delle funzioni è una lezione Security+ Academy gratuita su CoddyKit. Questa è la lezione 3 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Security+ Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Security+ Academy include 4 lezioni in totale.

Che cos'è il computing serverless?

Il computing serverless (Functions as a Service, FaaS) consente agli sviluppatori di distribuire singole funzioni invocate da eventi — richieste HTTP, messaggi in coda, trigger di database o timer pianificati — senza gestire i server sottostanti. Tra le principali piattaforme figurano AWS Lambda, Google Cloud Functions e Azure Functions. Il provider cloud gestisce applicazione delle patch, scalabilità e infrastruttura. Sebbene ciò riduca il carico operativo, modifica il modello di responsabilità della sicurezza: il provider protegge il runtime, ma lo sviluppatore è l'unico responsabile di codice delle funzioni, autorizzazioni e configurazione.

Superficie di attacco specifica del serverless

Le funzioni serverless presentano una superficie di attacco distinta rispetto alle applicazioni tradizionali: in genere sono di breve durata (da pochi secondi a pochi minuti), rendendo meno efficaci i sistemi EDR tradizionali e il monitoraggio della rete; sono basate su eventi, cioè molte origini di input diverse (eventi S3, API Gateway, SNS) possono attivarne l'esecuzione; spesso vengono eseguite con autorizzazioni IAM che consentono di accedere ad altre risorse cloud; inoltre utilizzano dipendenze di terze parti (pacchetti npm e pip) che possono contenere codice malevolo. La superficie di attacco è definita dagli input degli eventi, dalle autorizzazioni IAM e dalle catene di fiducia delle dipendenze.

Ruoli IAM con privilegi eccessivi: la minaccia principale

La vulnerabilità di sicurezza serverless più comune è rappresentata dai ruoli IAM con privilegi eccessivi. Quando gli sviluppatori devono consentire a una funzione di accedere a un bucket S3, può essere allettante assegnare s3:* (accesso completo a S3) per evitare errori di autorizzazione. Una funzione compromessa o vulnerabile con questo ruolo può quindi leggere, scrivere o eliminare qualsiasi bucket nell'account. La difesa consiste nell'uso rigoroso di ruoli IAM con privilegi minimi: ogni funzione dovrebbe avere un ruolo dedicato che conceda solo le autorizzazioni minime necessarie per le attività specifiche di quella funzione. Strumenti come AWS IAM Access Analyzer e Cloudsplaining identificano automaticamente i ruoli Lambda con privilegi eccessivi.

# IAM policy: least privilege for specific Lambda function
{
  'Version': '2012-10-17',
  'Statement': [{
    'Effect': 'Allow',
    'Action': ['s3:GetObject'],
    'Resource': 'arn:aws:s3:::my-specific-bucket/uploads/*'
  }]
}

Attacchi di event injection

La event injection si verifica quando i dati controllati dall'attaccante contenuti nel payload di un evento vengono elaborati in modo non sicuro dal codice della funzione. Poiché le funzioni serverless possono essere attivate da numerose origini di eventi — intestazioni HTTP, parametri di query, record di modifica dei database, corpi dei messaggi in coda, contenuto delle email — ciascuna di esse può trasportare payload malevoli. I tipi comuni di injection includono: SQL injection se la funzione interroga un database usando i dati dell'evento, NoSQL injection (operatori MongoDB nei payload JSON), command injection se i dati dell'evento vengono usati nei comandi del sistema operativo e SSRF (Server-Side Request Forgery) se vengono recuperati URL provenienti dai dati dell'evento. La convalida degli input e le query parametrizzate sono difese essenziali.

# Vulnerable: event data used directly in shell command
# const filename = event.filename;
# exec('convert ' + filename + ' output.jpg');

# Safe: validate and sanitize input
# const filename = path.basename(event.filename);
# if (!/^[a-z0-9_-]+\.(jpg|png)$/i.test(filename)) throw new Error('Invalid');
# execFile('convert', [filename, 'output.jpg']);

Rischio delle dipendenze: pacchetti di terze parti

Le funzioni serverless dipendono spesso da decine di pacchetti di terze parti. Queste dipendenze introducono un rischio per la catena di approvvigionamento: un pacchetto malevolo o compromesso può eseguire codice arbitrario nell'ambiente di esecuzione della funzione, accedere alle variabili d'ambiente (che spesso contengono secret), effettuare connessioni di rete in uscita e utilizzare il ruolo IAM della funzione per accedere alle risorse cloud. Attacchi noti come la compromissione del pacchetto npm event-stream (2018) e numerosi pacchetti typosquatting dimostrano questo rischio. Le difese includono il blocco delle versioni delle dipendenze, l'analisi SCA in CI/CD e un numero minimo di dipendenze.

Secret nel serverless: variabili d'ambiente

Le funzioni serverless ricevono spesso i secret tramite variabili d'ambiente configurate nella console cloud. Queste variabili d'ambiente sono visibili a chiunque disponga dell'accesso IAM alla configurazione Lambda e sono accessibili da qualsiasi codice eseguito all'interno della funzione. Le best practice prevedono di evitare di memorizzare i secret direttamente come variabili d'ambiente in testo non cifrato; memorizzare invece gli ARN o i nomi dei secret e recuperarli a runtime da AWS Secrets Manager o Parameter Store; abilitare la cifratura KMS per le variabili d'ambiente Lambda quando sono inattive; e non registrare mai le variabili d'ambiente nei log (molti logger di debug scaricano tutte le variabili d'ambiente in caso di errore).

# Retrieve secret at runtime instead of hardcoding
# Using AWS SDK in Lambda
# const secretsClient = new SecretsManagerClient({});
# const response = await secretsClient.send(
#   new GetSecretValueCommand({ SecretId: 'prod/myapp/db-password' })
# );
# const dbPassword = response.SecretString;

Limiti di timeout e concorrenza delle funzioni

Un attacco di denial of service contro le funzioni serverless può assumere la forma di un sovraccarico di invocazioni: un attaccante in grado di attivare ripetutamente una funzione può esaurire il limite di concorrenza dell'account (il valore predefinito di Lambda è di 1.000 esecuzioni simultanee per regione), impedendo l'esecuzione delle altre funzioni dell'account. Le funzioni che elaborano input controllati dall'utente devono implementare il rate limiting a livello di API Gateway, convalidare i limiti delle dimensioni dei payload e impostare valori di timeout appropriati per impedire esecuzioni senza fine. Se l'input non è soggetto a limiti di dimensione, le funzioni possono inoltre essere bersaglio di attacchi di espansione in stile Billion Laughs durante l'analisi di XML/YAML.

# AWS Lambda: set reserved concurrency to prevent account-wide DoS
aws lambda put-function-concurrency \
  --function-name my-api-handler \
  --reserved-concurrent-executions 100

Integrazione VPC e isolamento di rete

Per impostazione predefinita, le funzioni AWS Lambda vengono eseguite in una VPC gestita da AWS con accesso a Internet, ma senza accesso alle risorse della VPC privata (database RDS, ElastiCache, API private). Per accedere alle risorse private, Lambda deve essere configurato per l'esecuzione all'interno della Sua VPC, con subnet e gruppi di sicurezza specifici. Tuttavia, le funzioni Lambda collegate a una VPC non dispongono dell'accesso a Internet per impostazione predefinita: per il traffico Internet in uscita necessitano di un NAT Gateway. I gruppi di sicurezza associati alle funzioni Lambda devono seguire il principio del privilegio minimo: consentano solo le porte e le destinazioni specifiche necessarie. Eviti di usare regole in uscita 0.0.0.0/0 nei gruppi di sicurezza delle funzioni di produzione.

Monitoraggio delle funzioni serverless

Il monitoraggio della sicurezza serverless richiede approcci diversi dal monitoraggio tradizionale degli host. Poiché le funzioni sono effimere, gli agenti basati sull'host non sono pratici. Un monitoraggio efficace utilizza: AWS CloudTrail per registrare tutte le chiamate API Lambda (invocazioni, modifiche alla configurazione, assunzioni di ruoli); CloudWatch Logs Insights per interrogare i log di esecuzione delle funzioni alla ricerca di schemi anomali; Amazon GuardDuty per il rilevamento delle minacce, inclusa l'attività di rete Lambda insolita; e strumenti commerciali di sicurezza nativi per il serverless, come Protego (ora parte di Check Point) o il monitoraggio serverless di Datadog, che strumentano le funzioni tramite layer per offrire visibilità a runtime.

# Query CloudWatch Logs for Lambda errors and anomalies
aws logs start-query \
  --log-group-name '/aws/lambda/my-function' \
  --start-time $(date -d '-1 hour' +%s) \
  --end-time $(date +%s) \
  --query-string 'fields @timestamp, @message | filter @message like /ERROR|WARN|credential/'

Test della sicurezza serverless

Il test della sicurezza serverless richiede strumenti specifici: PureSec CLI (ora Check Point) e Prowler analizzano le configurazioni cloud alla ricerca di configurazioni errate serverless; gli strumenti DAST possono testare le funzioni attivate tramite HTTP alla ricerca di vulnerabilità di injection; l'analisi statica del codice delle funzioni con strumenti come Bandit (Python) o i plugin di sicurezza di ESLint rileva pattern di codifica non sicuri; inoltre, i test manuali devono enumerare tutte le origini degli eventi che possono attivare ciascuna funzione e testarle con payload malformati e malevoli. OWASP Serverless Top 10 offre una checklist completa delle vulnerabilità specifica per le architetture serverless.

# Prowler: check Lambda security posture
prowler aws --service lambda
# Checks: public URL, over-privileged roles, unencrypted env vars,
# outdated runtime, missing VPC config, excessive timeout

Responsabilità condivisa nel serverless

Il computing serverless estende ulteriormente verso il provider il modello di responsabilità condivisa. Il provider cloud è responsabile di: ambiente di runtime della funzione, patch del sistema operativo, sicurezza dell'infrastruttura sottostante e strutture fisiche. Il cliente rimane responsabile di: sicurezza del codice delle funzioni, progettazione delle autorizzazioni IAM, gestione dei secret, convalida degli input, gestione delle dipendenze, configurazione del logging e policy di rete. La riduzione della responsabilità sull'infrastruttura non significa una riduzione della responsabilità per la sicurezza: sposta semplicemente l'attenzione degli investimenti di sicurezza, principalmente verso la sicurezza a livello applicativo e IAM.

Verifica rapida

Verifichi la Sua comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

Riepilogo della lezione

In questa lezione ha imparato che: i ruoli IAM con privilegi eccessivi sono il principale rischio serverless — ogni funzione necessita di un ruolo dedicato con privilegi minimi; gli attacchi di event injection sfruttano qualsiasi origine di eventi che fornisca dati controllati dall'attaccante a funzioni prive di convalida degli input; e il rischio per la catena di approvvigionamento delle dipendenze derivante dai pacchetti di terze parti può compromettere l'esecuzione delle funzioni, consentendo l'accesso alle credenziali IAM e ai secret. Nel prossimo argomento esamineremo l'analisi della sicurezza dell'Infrastructure as Code per rilevare le configurazioni errate prima della distribuzione.

Domande Frequenti

La lezione «Sicurezza del serverless e delle funzioni» è gratuita?

Sì — il testo completo di «Sicurezza del serverless e delle funzioni» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Security+ Academy, passa a CoddyKit PRO. Il corso Security+ Academy include 4 lezioni in totale.

Cosa imparerò in «Sicurezza del serverless e delle funzioni»?

Identifichi la superficie d'attacco specifica delle funzioni serverless (ruoli IAM con privilegi eccessivi, injection di eventi e rischi delle dipendenze) e applichi controlli di least privilege e co… Eserciti Security+ Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Security+ Academy?

Non è richiesta alcuna esperienza precedente. Security+ Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 3 di 4.

Quanto tempo richiede la lezione «Sicurezza del serverless e delle funzioni»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Security+ Academy?

Sì. Ogni lezione Security+ Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Sicurezza dei container: hardening delle immagini e protezione a runtime
  2. Sicurezza Kubernetes: RBAC, policy di rete e sicurezza dei pod
  3. Sicurezza del serverless e delle funzioni
  4. Scansione di sicurezza dell'infrastruttura come codice
← Torna a Security+ Academy