0Pricing
Ethical Hacking Academy · Lezione

Superficie d'attacco del cloud

AWS, Azure, GCP

Superficie d'attacco del cloud è una lezione Ethical Hacking Academy gratuita su CoddyKit. Questa è la lezione 1 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 Ethical Hacking Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Ethical Hacking Academy include 4 lezioni in totale.

Che cos'è la superficie d'attacco cloud?

La superficie d'attacco cloud è l'insieme complessivo dei punti attraverso i quali un aggressore potrebbe tentare di entrare in un ambiente cloud o di estrarne dati. A differenza delle reti on-premise, la superficie cloud è definita soprattutto da configurazione e identità, non da un perimetro fisico.

  • API e console di gestione esposte pubblicamente
  • Gestione delle identità e degli accessi (IAM)
  • Bucket di storage, database e funzioni serverless
  • Esposizione della rete (gruppi di sicurezza, load balancer)

Una sola impostazione errata può esporre un intero account.

I tre grandi provider: AWS, Azure, GCP

La maggior parte dei pentest cloud prende di mira uno dei tre principali provider. Ognuno ha un proprio modello di identità e una terminologia specifica, ma i pattern d'attacco sono simili.

  • AWS — utenti/ruoli IAM, S3, EC2, Lambda
  • Azure — Entra ID (Azure AD), Blob Storage, VM, Functions
  • GCP — account di servizio IAM, Cloud Storage, Compute Engine

Impararne a fondo uno rende più semplici gli altri, perché i concetti fondamentali (identità, calcolo, storage, rete) corrispondono in tutti e tre.

Il modello di responsabilità condivisa

I provider cloud proteggono l'infrastruttura; il cliente protegge ciò che inserisce al suo interno. Questo è il modello di responsabilità condivisa e quasi ogni violazione del cloud avviene dal lato del cliente.

  • Provider: data center fisici, hypervisor, applicazione delle patch ai servizi gestiti
  • Cliente: policy IAM, dati, applicazione delle patch al sistema operativo (IaaS), configurazione della rete

In qualità di pentester, si concentri sulle responsabilità del cliente, perché è lì che si trovano gli errori sfruttabili.

Enumerazione delle identità cloud

Il primo compito in una valutazione cloud è capire chi è Lei e cosa può fare con le credenziali in suo possesso. La AWS CLI espone immediatamente l'identità del chiamante.

Se una chiave dispone di autorizzazioni eccessive, questa singola identità può spostarsi lateralmente nell'intero account.

# Confirm which AWS identity a credential belongs to
aws sts get-caller-identity

# Example output
# {
#   "UserId": "AIDA...",
#   "Account": "123456789012",
#   "Arn": "arn:aws:iam::123456789012:user/devuser"
# }

Superficie pubblica e privata

Le risorse cloud possono essere raggiungibili da Internet pubblico oppure soltanto dall'interno di una rete virtuale. Un'esposizione configurata in modo errato è uno dei problemi più comuni.

  • Security group / NSG aperti a 0.0.0.0/0
  • Bucket di storage configurati per la lettura pubblica
  • Database con endpoint pubblici abilitati
  • Porte di gestione (22, 3389, 5432) esposte

Mappare quali risorse sono pubbliche è la base della ricognizione cloud.

Individuazione delle risorse dall'esterno

Anche senza credenziali, gli aggressori enumerano l'impronta cloud di un target. La denominazione prevedibile e il DNS rivelano una quantità sorprendente di informazioni.

Gli strumenti eseguono tentativi automatizzati sui nomi di bucket e storage basandosi sul nome dell'azienda e su pattern comuni.

# Resolve a cloud-hosted hostname to map provider/region
nslookup assets.example.com

# Probe a guessed S3 bucket name
curl -s -o /dev/null -w '%{http_code}\n' https://example-backups.s3.amazonaws.com/

Piano di gestione e piano dati

In ogni account cloud esistono due distinti livelli d'attacco:

  • piano di gestione/controllo — le API che creano, modificano ed eliminano le risorse (ad esempio iam:CreateUser, ec2:RunInstances)
  • piano dati — l'accesso ai dati contenuti nelle risorse (lettura di un oggetto S3, esecuzione di query su un DB)

Compromettere il piano di gestione di solito significa compromettere l'intero account, perché l'aggressore può concedersi qualsiasi accesso al piano dati desideri.

Superficie di logging e rilevamento

Le azioni sul cloud vengono registrate centralmente. In qualità di pentester, è necessario sapere che esistono perché i difensori le monitorano; inoltre, scoprire che sono disabilitate costituisce a sua volta un finding.

  • AWS CloudTrail — registra tutte le chiamate API
  • Azure Activity Log / Monitor
  • GCP Cloud Audit Logs

Un account con il logging disabilitato o non monitorato costituisce un finding ad alto rischio, anche prima di qualsiasi exploit.

# Check whether CloudTrail logging is active
aws cloudtrail describe-trails
aws cloudtrail get-trail-status --name my-trail

Punti di ingresso comuni nel cloud

La maggior parte delle compromissioni cloud inizia da uno di pochi punti d'appoggio:

  • Chiavi di accesso esposte in repository Git, log CI o app mobili
  • Ruoli IAM con permessi eccessivi associati a server compromessi
  • SSRF che raggiunge il servizio di metadati dell'istanza
  • Bucket di storage pubblici che espongono segreti o backup

Riconoscere questi schemi consente di stabilire dove cercare per prima cosa.

Mappatura metodica della superficie

Un approccio strutturato mantiene completa la valutazione del cloud. Una volta ottenute le credenziali, gli strumenti automatizzati enumerano l'intero account.

Strumenti come ScoutSuite e Prowler verificano la configurazione dei servizi e segnalano automaticamente i rischi.

# Audit an AWS account for misconfigurations (read-only)
prowler aws

# Multi-cloud configuration review
scout aws

Prima di tutto, ambito e autorizzazione

I test sul cloud devono rimanere entro i limiti dell'autorizzazione prevista dall'incarico. Anche i provider hanno proprie regole di ingaggio.

  • Confermare gli account, le subscription o i progetti esatti inclusi nell'ambito
  • Evitare azioni che incidano su altri tenant o sull'infrastruttura condivisa
  • Non eseguire mai test di tipo denial-of-service senza un'approvazione scritta esplicita

Test cloud non autorizzati possono violare i termini del provider e la legislazione locale.

Verifica rapida

Nel modello di responsabilità condivisa, quale parte è responsabile dei criteri IAM e della configurazione dei dati?

Riepilogo: superficie di attacco cloud

Ha imparato che cosa definisce la superficie di attacco cloud e in che modo differisce dalle reti tradizionali.

  • La superficie è determinata da identità e configurazione, non da un perimetro fisico
  • AWS, Azure e GCP condividono gli stessi concetti fondamentali: identità, calcolo, storage, rete
  • Il modello di responsabilità condivisa attribuisce al cliente la configurazione e i dati
  • Distinguere il piano di gestione dal piano dati
  • Confermare sempre l'ambito e l'autorizzazione prima dei test

Ora analizzeremo in dettaglio le configurazioni errate di IAM, il cuore degli attacchi cloud.

Domande Frequenti

La lezione «Superficie d'attacco del cloud» è gratuita?

Sì — il testo completo di «Superficie d'attacco del cloud» è 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 Ethical Hacking Academy, passa a CoddyKit PRO. Il corso Ethical Hacking Academy include 4 lezioni in totale.

Cosa imparerò in «Superficie d'attacco del cloud»?

AWS, Azure, GCP Eserciti Ethical Hacking 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 Ethical Hacking Academy?

Non è richiesta alcuna esperienza precedente. Ethical Hacking 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 1 di 4.

Quanto tempo richiede la lezione «Superficie d'attacco del cloud»?

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 Ethical Hacking Academy?

Sì. Ogni lezione Ethical Hacking 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. Superficie d'attacco del cloud
  2. Configurazioni errate dell'IAM
  3. Esposizione di S3 e dello storage
  4. Metadati e SSRF
← Torna a Ethical Hacking Academy