Amazon SCS-C02: Networking e sicurezza VPC — Guida allo studio
Fa parte della AWS Security Specialty SCS-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.
Endpoint VPC e Policy degli Endpoint
Gli endpoint VPC mantengono il traffico verso i servizi AWS sulla rete AWS, bypassando la rete internet pubblica, i gateway NAT e gli internet gateway. Esistono due tipi strutturalmente diversi, e confonderli è uno degli errori di progettazione più comuni.
Gli endpoint di gateway esistono solo per Amazon S3 e DynamoDB. Sono voci della tabella di routing: si associa l’endpoint alle tabelle di routing e il traffico destinato alla lista di prefissi del servizio (ad esempio pl-63a5400a per S3 in us-east-1) viene reindirizzato silenziosamente attraverso l’endpoint. Non hanno costi e non possono essere raggiunti dall’esterno del VPC a cui sono collegati.
Gli endpoint di interfaccia (basati su AWS PrivateLink) sono ENI con indirizzi IP privati inseriti nelle tue sottoreti. Sono necessari per ogni servizio che non sia S3 o DynamoDB — Secrets Manager, KMS, STS, SSM, CloudWatch Logs, ECR API/DKR e centinaia di altri. Se un’istanza EC2 in una sottorete privata senza gateway NAT deve eseguire GetSecretValue da Secrets Manager, un endpoint di gateway non sarà d’aiuto; è necessario creare un endpoint di interfaccia com.amazonaws.<region>.secretsmanager e abilitare il DNS privato in modo che l’hostname standard del servizio si risolva nell’IP privato dell’endpoint.
Le policy degli endpoint limitano cosa può essere fatto attraverso l’endpoint, indipendentemente dalle policy IAM dell’entità chiamante. Le due chiavi di condizione più importanti per prevenire l’esfiltrazione di dati sono aws:PrincipalOrgID (l’identità che effettua la chiamata deve appartenere alla tua Organization) e aws:ResourceOrgID (il bucket S3, la chiave KMS, ecc. a cui si accede deve appartenere alla tua Organization). Applicare entrambe chiude il classico percorso di esfiltrazione in cui un’istanza compromessa con permessi S3 legittimi scrive su un bucket controllato dall’attaccante al di fuori della tua organizzazione: le credenziali funzionano ancora contro S3, ma l’endpoint si rifiuta di inoltrare la richiesta.
{
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "o-abc123",
"aws:ResourceOrgID": "o-abc123"
}
}
}]
}
La policy di default dell’endpoint è completamente permissiva ("Action":"*" su "Resource":"*"), motivo per cui una sottorete con solo un endpoint di gateway e IAM con privilegi minimi può comunque essere abusata per l’esfiltrazione, a meno che non si restringa la policy dell’endpoint stessa.
Connettività Ibrida: VPN e Direct Connect
La VPN Site-to-Site stabilisce due tunnel IPsec tra un gateway privato virtuale (o un Transit Gateway) e un dispositivo gateway del cliente. È veloce da provisionare, crittografata di default e attraversa la rete internet pubblica, quindi il throughput e la latenza dipendono dal percorso del tuo ISP.
AWS Direct Connect provisiona un circuito fisico dedicato attraverso una località Direct Connect. Fornisce una latenza bassa e prevedibile e una larghezza di banda elevata e costante (1/10/100 Gbps), il che è importante per il traffico “chiacchierone” dei database on-premise. Direct Connect non è crittografato di per sé a livello 3; i frame viaggiano su fibra privata. Per i carichi di lavoro che richiedono sia bassa latenza che IPsec, la risposta canonica è Direct Connect più una VPN Site-to-Site eseguita su una VIF pubblica (o un Transit Gateway con MACsec su porte DX più recenti). La sola VPN è anche il backup crittografato raccomandato per un link Direct Connect primario, fornendo resilienza in caso di guasto del circuito.
- Solo Direct Connect: bassa latenza, privato, ma non crittografato a livello IP.
- Solo VPN: crittografato, rapido da implementare, ma con latenza e jitter del percorso internet.
- Direct Connect + VPN: bassa latenza e crittografia IPsec; è anche il pattern standard per l’HA.
Gruppi di Sicurezza, NACL, DHCP e Controllo Origine/Destinazione
I gruppi di sicurezza sono stateful: se si consente una richiesta in entrata, la risposta è automaticamente autorizzata in uscita. Supportano solo regole di allow e vengono valutati per ogni ENI.
Le ACL di rete (NACL) sono stateless e operano al confine della sottorete. Ogni flusso richiede due regole: una per la direzione iniziale e una per il traffico di ritorno sull’intervallo di porte effimere (Linux tipicamente 32768–60999, Windows 49152–65535 e NLB/ELB usano 1024–65535). Una NACL che permette il TCP 443 in entrata ma dimentica il TCP 1024–65535 in uscita interromperà silenziosamente il TLS. ICMP non è TCP/UDP: i pacchetti di ritorno “echo reply” devono essere permessi esplicitamente, e il Path MTU Discovery si basa su ICMP tipo 3 codice 4, che è facile bloccare inavvertitamente. Le regole delle NACL sono anche valutate in ordine numerico, vince la prima corrispondenza, con un deny implicito alla fine.
I set di opzioni DHCP controllano ciò che un VPC fornisce alle istanze all’avvio: domain-name-servers, domain-name, server NTP, NetBIOS. Sostituire il AmazonProvidedDNS di default con un resolver on-premise personalizzato può essere legittimo, ma ha reali conseguenze sulla sicurezza. Servizi come GuardDuty derivano i loro risultati basati su DNS (ad esempio i rilevamenti “cryptocurrency” e “C&C domain”) dalle query che attraversano il Route 53 Resolver. Una volta che si indirizzano le istanze a un server DNS di terze parti, GuardDuty smette di vedere le query e quei tipi di risultati scompaiono: un modo facile per accecare accidentalmente il rilevamento.
Il controllo di origine/destinazione è un attributo dell’ENI che scarta qualsiasi pacchetto il cui IP di origine o destinazione non corrisponda all’ENI. Questa impostazione di default è corretta per le istanze ordinarie ma interrompe il funzionamento di qualsiasi appliance il cui compito è inoltrare il traffico: istanze NAT, firewall virtuali (Palo Alto, Fortinet, Check Point), router di transito, concentratori VPN. Per quelle ENI, disabilita il controllo:
aws ec2 modify-instance-attribute \
--instance-id i-0abc123 \
--no-source-dest-check
Peering di VPC, VPC condivisi con RAM e progettazione NAT
Il peering di VPC è un collegamento di livello 3 (layer-3) uno-a-uno e non transitivo. Se A è in peering con B e B è in peering con C, A non può raggiungere C: è necessario stabilire un peering diretto A-C o utilizzare un Transit Gateway. Le tabelle di routing su entrambi i lati devono contenere route verso il CIDR del peer e i gruppi di sicurezza possono fare riferimento agli ID dei gruppi di sicurezza del peer solo all’interno di una stessa Regione.
I VPC condivisi tramite AWS Resource Access Manager (RAM) consentono a un account di networking di possedere un VPC e di condividere singole sottoreti con account partecipanti. I partecipanti avviano risorse nelle sottoreti condivise ma non possono modificare il VPC, le tabelle di routing o gli endpoint: il proprietario mantiene il controllo della policy di connettività. Questa soluzione è spesso più economica e semplice rispetto al peering di numerosi VPC.
Per l’accesso a Internet in uscita dalle sottoreti private, implementare un NAT gateway per ogni Availability Zone e instradare ogni sottorete privata verso il NAT nella propria AZ. Un singolo NAT gateway rappresenta una dipendenza cross-AZ e un collo di bottiglia per la scalabilità e la disponibilità. Quando il carico di lavoro chiama una terza parte che inserisce in una allow-list IP il vostro traffico in uscita (un processore di pagamenti, ad esempio), l’Elastic IP del NAT gateway è l’indirizzo da registrare, e poiché le istanze dietro un Auto Scaling group escono tutte attraverso quell’EIP fisso, l’IP di origine non cambia man mano che il gruppo scala. Posizionare le istanze EC2 e il database RDS in sottoreti private e terminare solo il traffico HTTP/HTTPS sull’ALB completa il pattern.
Route 53 Resolver: Inoltro e Logging delle Query
Il Route 53 Resolver (l’indirizzo .2 in ogni VPC) è il fulcro del DNS ibrido. Gli endpoint del resolver in uscita (outbound) inoltrano nomi di dominio specifici da AWS a server DNS on-premise tramite regole di inoltro condizionale (conditional forwarding), utilizzati, ad esempio, affinché corp.example.internal venga risolto tramite il proprio Active Directory. Gli endpoint del resolver in entrata (inbound) fanno il contrario, fornendo agli host on-premise un IP privato nel VPC che possono interrogare per risolvere *.eu-west-1.compute.internal e le Private Hosted Zone.
Il logging delle query del resolver (Resolver query logging) scrive ogni query DNS effettuata dal VPC su CloudWatch Logs, S3 o Kinesis Firehose. È la registrazione autorevole per investigare sospette esfiltrazioni o usi impropri e integra, ma non sostituisce, GuardDuty. Ricorda che se un set di opzioni DHCP reindirizza le istanze a un resolver non Amazon, sia il logging delle query sia i risultati DNS di GuardDuty vengono meno, perché le query non raggiungono mai il Route 53 Resolver.
Problema Pratico: Scenario d’Uso
Scenario: Meridian Financial gestisce un ambiente AWS multi-account con una rete hub-and-spoke: un VPC di servizi condivisi (shared-services), condiviso tramite RAM, ospita NAT Gateway centralizzati, endpoint di Route 53 Resolver e collegamenti (attachment) a un Transit Gateway, mentre più VPC applicativi sono in peering o collegati al Transit Gateway. I datacenter on-premise si connettono tramite Direct Connect con failover su VPN, e i team si affidano a set di opzioni DHCP centralizzati e a endpoint del resolver condivisi per la risoluzione DNS ibrida.
Sfida: Un recente incidente ha mostrato che oggetti S3 sensibili sono stati accessibili tramite Internet pubblico perché gli spoke instradavano il traffico verso il NAT condiviso anziché verso gli endpoint del VPC, le query DNS per le zone interne sono trapelate verso resolver pubblici e un’istanza EC2 utilizzata come router ad-hoc (con il controllo source/dest disabilitato) ha permesso movimenti laterali.
Approccio Raccomandato:
- Implementare Gateway VPC Endpoint per S3 e DynamoDB e Interface Endpoint (AWS PrivateLink) per Secrets Manager e KMS nel VPC dei servizi condivisi, associando policy di endpoint esplicite che limitino l’accesso a bucket e service principal specifici.
- Riprogettare l’architettura NAT in modo che le sottoreti applicative utilizzino gli endpoint del VPC per le API AWS e S3; mantenere i NAT Gateway solo per il traffico in uscita verso Internet legittimo, con security group di egress restrittivi e Flow Logs verso CloudWatch/S3.
- Riabilitare i controlli source/dest su tutte le istanze EC2, ad eccezione degli apparati di routing documentati; spostare il routing sui collegamenti del Transit Gateway o su istanze NAT gestite e applicare il principio del privilegio minimo (least-privilege) alle tabelle di routing.
- Rafforzare i Security Group e le NACL delle sottoreti con un approccio deny-by-default e applicare baseline centralizzate per IAM e SG tramite SCP di AWS Organizations e regole di AWS Config.
- Rendere più sicuro il DNS ibrido implementando endpoint inbound/outbound di Route 53 Resolver, configurare l’inoltro condizionale e le regole del DNS Firewall, abilitare il logging delle query del resolver su CloudWatch Logs e utilizzare i set di opzioni DHCP per imporre l’uso dei resolver interni per tutti i VPC condivisi tramite RAM.
Motivazione: Questo approccio elimina il traffico in uscita non necessario verso Internet utilizzando endpoint del VPC con policy di endpoint, centralizza e controlla il routing tramite Transit Gateway/Direct Connect, ripristina le protezioni a livello di istanza e previene la fuga di informazioni DNS (DNS leakage) con gli endpoint del resolver e il logging, allineandosi con le best practice di networking e di difesa in profondità (defense-in-depth) di AWS.
Endpoint VPC e Policy degli Endpoint
Gli endpoint VPC consentono ai carichi di lavoro all’interno di una VPC di raggiungere le API dei servizi AWS senza attraversare la rete Internet pubblica o un gateway NAT. Esistono due varianti architetturali, e scegliere quella sbagliata è una causa comune di traffico instradato in modo errato.
Endpoint gateway: Utilizzati solo per Amazon S3 e DynamoDB. Vengono implementati come destinazione (target) in una tabella di routing (lista di prefissi
pl-xxxxxxxxche punta avpce-xxxxxxxx). Non viene creata alcuna ENI, non sono necessarie modifiche al DNS e non c’è un costo orario.Endpoint di interfaccia (PrivateLink): Utilizzati per KMS, SQS, SNS, Secrets Manager, STS, API EC2 e la maggior parte degli altri servizi. Effettuano il provisioning di ENI con indirizzi IP privati all’interno di subnet prescelte e sono fatturati su base oraria più un costo per GB.
Per un processo batch cross-account in cui le istanze EC2 nell’Account B leggono da un bucket S3 nell’Account A, crittografato con una chiave KMS nell’Account A, il design corretto prevede un endpoint gateway per S3 più un endpoint di interfaccia per KMS. L’endpoint gateway evita che le chiamate s3:GetObject, s3:PutObject, s3:PutObjectAcl e s3:ListBucket passino da Internet; l’endpoint di interfaccia fa lo stesso per kms:Decrypt, kms:Encrypt e kms:GenerateDataKey. Poiché l’ARN della chiave KMS utilizza l’hostname standard kms.<region>.amazonaws.com, l’endpoint di interfaccia deve avere il DNS privato abilitato in modo che l’hostname non modificato dell’SDK si risolva nell’ENI dell’endpoint anziché nel servizio KMS pubblico. Senza il DNS privato (o senza che siano abilitati sia gli hostname DNS che la risoluzione DNS a livello di VPC), il client contatterebbe comunque l’endpoint pubblico — di conseguenza, il requisito di “nessuna modifica al codice” richiede implicitamente il DNS privato.
Le policy degli endpoint sono un secondo livello di autorizzazione indipendente. Esiste una policy predefinita permissiva, ma un hardening per un bucket e una chiave specifici si presenta così:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": ["s3:GetObject","s3:PutObject","s3:PutObjectAcl","s3:ListBucket"],
"Resource": ["arn:aws:s3:::acct-a-bucket","arn:aws:s3:::acct-a-bucket/*"]
}]
}
La semplice creazione dell’endpoint non è sufficiente. Si verificano ricorrentemente due modalità di fallimento: (1) l’endpoint esiste ma la tabella di routing della subnet privata non ha una voce per la lista di prefissi S3, quindi il traffico esce ancora tramite il gateway NAT; (2) la policy dell’endpoint omette un’azione come s3:PutObjectAcl o punta all’ARN del bucket sbagliato, bloccando silenziosamente chiamate che IAM altrimenti consentirebbe. Sia la policy del bucket sia la policy dell’endpoint devono consentire la richiesta — le loro autorizzazioni vengono intersecate, non unite.
Gruppi di Sicurezza, NACL e Contenimento Rapido
I gruppi di sicurezza e le NACL (Network ACL) risolvono problemi sovrapposti a livelli diversi, e l’esame spesso impone una scelta tra i due per la risposta agli incidenti.
Gruppi di sicurezza: Stateful, valutati a livello di ENI. Il traffico di ritorno è consentito automaticamente. Esistono solo regole di tipo “allow” (consenti). Ideali per policy a livello di host (“il livello web può raggiungere il livello applicativo sulla porta 8080”).
ACL di rete (NACL): Stateless, valutate al confine della subnet. Esistono sia regole di tipo “allow” (consenti) che “deny” (nega), elaborate in base al numero di regola. Ideali per blocchi grossolani a livello di intera subnet — specialmente per inserire in blocklist un intervallo di IP o chiudere una porta specifica su tutte le istanze di una subnet.
Quando un’epidemia di malware impone di bloccare il traffico in uscita sulla porta TCP/2905 verso un set di IP di comando e controllo (C2) su molte istanze, una regola di “deny” in una NACL è lo strumento corretto. I gruppi di sicurezza non possono esprimere un “deny” e richiederebbero di elencare e modificare ogni gruppo di sicurezza (SG) referenziato da ogni ENI interessata. Una singola regola di “deny” nella NACL a livello di subnet, con un numero di regola basso (es. 90), copre istantaneamente tutte le istanze in quella subnet, preservando il traffico non correlato che viene valutato da regole di “allow” successive.
Poiché le NACL sono stateless, ricorda che sono necessarie regole per entrambe le direzioni. Bloccare il traffico in uscita sulla porta 2905 non richiede una regola in ingresso, ma se si desidera rifiutare anche le risposte in entrata, è necessario aggiungere una regola in ingresso — e devono esistere regole di “allow” in ingresso per le porte effimere (1024–65535) per consentire il passaggio del traffico di ritorno legittimo.
Gateway NAT, Routing e Indipendenza tra AZ
Un gateway NAT è una risorsa zonale. Il pattern canonico prevede un gateway NAT per ogni Zona di Disponibilità (AZ), con la tabella di routing di ogni subnet privata che punta la rotta 0.0.0.0/0 al gateway NAT nella stessa AZ:
PrivateRouteTable-AZ-a: 0.0.0.0/0 -> nat-aaaa (in subnet public-az-a)
PrivateRouteTable-AZ-b: 0.0.0.0/0 -> nat-bbbb (in subnet public-az-b)
PrivateRouteTable-AZ-c: 0.0.0.0/0 -> nat-cccc (in subnet public-az-c)
Un singolo gateway NAT condiviso tra più AZ sembra più economico, ma introduce due problemi: costi di trasferimento dati cross-AZ su ogni pacchetto e una dipendenza critica di disponibilità — se quella AZ dovesse andare offline, ogni subnet privata perderebbe l’uscita verso Internet. Il pattern con un NAT per zona evita anche anomalie di ritorno asimmetrico quando combinato con l’ispezione tramite Transit Gateway (vedi sotto).
VPC Flow Logs per le Indagini
I Flow Logs catturano metadati a 5 tuple (IP sorgente/destinazione, porta, protocollo, azione ACCEPT/REJECT, byte, pacchetti) a livello di VPC, subnet o ENI. Per individuare le istanze che comunicano con host C2 (beaconing) sulla porta TCP/2905, abilita i Flow Logs sulla VPC con il tipo di traffico impostato su REJECT (poiché la NACL sta ora scartando quel traffico) ed esegui una query in CloudWatch Logs Insights o Athena:
SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS hits
FROM vpc_flow_logs
WHERE dstport = 2905 AND action = 'REJECT'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY hits DESC;
La colonna srcaddr rivela gli IP delle istanze infette con il minimo sforzo — senza bisogno di catturare pacchetti o installare agenti sugli host. Scegliere il traffico “ALL” funziona, ma produce più dati e costi; scegliere solo “ACCEPT” mancherebbe completamente i tentativi scartati, che sono precisamente ciò che è necessario vedere.
PrivateLink, Transit Gateway e Network Firewall
PrivateLink estende il modello di endpoint di interfaccia ai propri servizi: un VPC provider espone un NLB dietro un servizio di endpoint VPC, e i consumer creano endpoint di interfaccia per raggiungerlo senza VPC peering o condivisione di rotte. È unidirezionale e nasconde completamente il CIDR del provider.
Transit Gateway (TGW) è l’hub per la connettività many-to-many tra VPC e ambienti on-premise. Un pattern comune è un VPC di ispezione centralizzato che esegue AWS Network Firewall o appliance di terze parti, con le tabelle di routing del TGW che indirizzano il traffico spoke-to-spoke attraverso il VPC di ispezione. Questo design non funziona con il comportamento predefinito del TGW, poiché il TGW esegue l’hashing dei flussi tra le ENI degli attachment in diverse AZ e il percorso di ritorno potrebbe entrare in una AZ diversa da quella di andata. I firewall stateful scartano i pacchetti a metà flusso per i quali non hanno mai visto il SYN.
Sono necessarie due correzioni congiunte. Innanzitutto, abilitare l’Appliance Mode sull’attachment del TGW per il VPC di ispezione; questo “fissa” ogni flusso bidirezionale alla stessa ENI della AZ, in modo che andata e ritorno attraversino lo stesso endpoint del firewall. In secondo luogo, configurare le tabelle di routing del TGW in modo che gli attachment degli spoke inviino il traffico all’attachment del VPC di ispezione, e una tabella di routing separata post-ispezione sul VPC di ispezione restituisca il traffico allo spoke corretto. Omettere uno dei due passaggi — l’appliance mode da solo senza le tabelle di routing, o le tabelle di routing da sole senza l’appliance mode — lascia attivi i drop asimmetrici.
Network Firewall stesso utilizza regole compatibili con Suricata e dipende dal routing simmetrico per mantenere lo stato dei flussi; combinandolo con i Flow Logs sia sul VPC di ispezione che sui VPC spoke si ottiene la traccia forense necessaria per dimostrare quale spoke ha avviato una sessione e se il firewall l’ha permessa o scartata.
Problema Pratico: Scenario d’Uso
Scenario: Meridian Financial gestisce un ambiente AWS multi-account con VPC di produzione distribuiti su tre Availability Zone in us-east-1, collegati tramite un AWS Transit Gateway a un VPC di sicurezza centrale. Utilizzano NAT Gateway in ogni AZ per l’egress, S3 Gateway Endpoint e Interface Endpoint (PrivateLink) per i SaaS dei partner, e un AWS Network Firewall centralizzato insieme a Security Group e NACL; i VPC Flow Logs vengono trasmessi a CloudWatch per il monitoraggio.
Sfida: Un’istanza EC2 di produzione è sospettata di tentativi di movimento laterale ed esfiltrazione di dati verso un IP esterno e verso S3. Meridian necessita di un contenimento rapido attraverso le AZ senza interrompere altri VPC critici per il business.
Approccio Raccomandato:
- Mettere immediatamente in quarantena l’istanza compromessa sostituendo i suoi Security Group con un SG restrittivo di “quarantena” che neghi tutto il traffico in uscita/entrata, e aggiungere un tag all’istanza per la remediation automatizzata tramite Systems Manager; applicare contemporaneamente regole di Network ACL a livello di subnet per bloccare l’egress verso intervalli di IP esterni sospetti.
- Isolare il VPC sul Transit Gateway rimuovendo o modificando l’attachment della tabella di routing del TGW per il VPC interessato, associandolo a una tabella di routing TGW di quarantena (blackhole o senza rotte verso altri attachment), per fermare il movimento laterale verso altri VPC.
- Reindirizzare il restante traffico in uscita (egress) del VPC attraverso l’AWS Network Firewall centralizzato, aggiornando le voci del TGW/tabelle di routing per forzare l’ispezione e bloccare le destinazioni note come maligne, preservando l’indipendenza delle AZ mantenendo i NAT Gateway per ogni AZ per un egress resiliente e ispezionato.
- Rafforzare i controlli del data plane applicando policy restrittive sugli VPC Endpoint per gli S3/DynamoDB Gateway Endpoint per negare Put/Get da principal non approvati e garantire che le API interne utilizzino Interface Endpoint (PrivateLink) per evitare percorsi via Internet.
- Utilizzare i VPC Flow Logs con CloudWatch Logs Insights e AWS CloudTrail per eseguire analisi forensi, quindi procedere alla remediation (reimage, rotazione delle chiavi) e reintrodurre l’istanza solo dopo la validazione; imporre le regole tramite AWS Firewall Manager/AWS Config.
Logica: Questa sequenza fornisce un contenimento rapido e basato sul principio del privilegio minimo (least-privilege) sia a livello di host che di rete, centralizza l’ispezione con Network Firewall e il routing del Transit Gateway per minimizzare il raggio d’impatto (blast radius), preserva la resilienza delle AZ con NAT per ogni AZ, e utilizza i VPC Flow Logs per un’indagine tracciabile, in linea con le best practice di difesa in profondità (defense-in-depth) di AWS.
← Protezione dei dati e S3 · Tutti i domini · Sicurezza perimetrale e delle applicazioni →
Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Supera l'esame →