Informazioni sugli ACL di rete
Puoi utilizzare un ACL (access control list) per controllare tutto il traffico in entrata e in uscita in IBM Cloud® Virtual Private Cloud. Un ACL è un firewall virtuale integrato, simile a un gruppo di sicurezza. A differenza dei gruppi di sicurezza, le regole ACL controllano il traffico da e verso le sottoreti, piuttosto che da e verso le istanze.
Per un confronto delle caratteristiche dei gruppi di sicurezza e degli ACL, vedi la tabella di confronto.
L'esempio presentato in questo documento mostra come creare gli ACL di rete nel tuo VPC utilizzando la CLI. Per ulteriori informazioni su come impostare le ACL nella console IBM Cloud, vedere Configurazione delle ACL nella console.
Utilizzo degli ACL e delle regole dell'ACL
Per rendere effettivi i tuoi ACL, crea delle regole che determinano come gestire il tuo traffico di rete in entrata e in uscita. Puoi creare più regole in entrata e in uscita. Per ulteriori informazioni sulle quote delle regole, consultare Quote.
- Con le regole in entrata, puoi consentire o negare il traffico da un intervallo IP di origine, con protocolli e porte specificati.
- Con le regole in uscita, puoi consentire o negare il traffico verso un intervallo IP di destinazione, con protocolli e porte specificati.
- Le regole ACL hanno la priorità e vengono considerate in sequenza. Le regole con priorità più alta vengono valutate per prime e sovrascrivono le regole con priorità inferiore.
- Le regole in entrata sono separate dalle regole in uscita.
- Se non viene specificata alcuna regola, il comportamento predefinito è negazione implicita.
Per ulteriori informazioni sull'uso di ICMP, TCP, UDP, e di tutti gli altri protocolli nelle regole ACL, vedere Comprensione dei protocolli di comunicazione Internet.
Limitazioni
- Attualmente, i pacchetti del protocollo ESP sono supportati solo su istanze con Gen2 profili. Nelle istanze con altri profili e su tutti i server bare metal, i pacchetti ESP in entrata e in uscita vengono sempre eliminati. Sebbene sia possibile configurare regole ACL di rete per il traffico ESP con l'API VPC, tali regole influiscono solo sulle istanze con Gen2 profili. Il protocollo ESP non è supportato su altri tipi di profili collegati alla stessa rete di un Gen2 profilo. Il protocollo ESP non viene visualizzato come opzione nella IBM Cloud console per evitare confusione tra le generazioni di profili di istanza. Per ulteriori informazioni, consultare i profili delle istanze di x86-64.
Aggiornamento delle regole ACL predefinite di un VPC
La ACL predefinita è simile a qualsiasi altra ACL, con l'eccezione che non può essere cancellata.
Quando si crea un VPC, il sistema crea un ACL predefinito per il VPC con due regole:
- Una regola denominata
allow-inboundper consentire il traffico ICMP in entrata, TCP e UDP da qualsiasi sorgente - Una regola denominata
allow-outboundper consentire il traffico ICMP in uscita, TCP e UDP verso qualsiasi destinazione
È possibile modificare le regole della ACL predefinita utilizzando la console, la CLI o l'API.
Se si modificano le regole della ACL predefinita, tali regole modificate vengono applicate a tutte le sottoreti attuali e future collegate alla ACL.
Collegamento di un ACL a una sottorete
Quando crei una nuova sottorete, puoi specificare un ACL da collegare. Se non si specifica una ACL, viene allegata la ACL di rete predefinita della VPC.
Ogni sottorete ha esattamente un ACL collegato. È possibile sostituire l'ACL di una sottorete con un'ACL diversa.
Esempio di ACL
Nel seguente esempio, crei due ACL e li associ a due sottoreti utilizzando la CLI (command-line interface). La Figura 1 mostra come si presenta lo scenario.
Come illustra la Figura 1, si dispone di due server Web che gestiscono le richieste provenienti da Internet e di due server back-end che si desidera nascondere al pubblico. In questo esempio, i server sono collocati in due sottoreti separate,
10.10.10.0/24 e 10.10.20.0/24, e occorre consentire ai server Web di scambiare dati con i server back-end. Inoltre, si vuole consentire un traffico limitato in uscita dai server back-end.
Regole di esempio
Le regole di esempio che seguono mostrano come configurare le regole ACL per lo scenario di base.
Come procedura consigliata, assegna alle regole dettagliate una priorità più elevata rispetto alle regole poco dettagliate. Ad esempio, si dispone di una regola che blocca tutto il traffico proveniente dalla sottorete 10.10.30.0/24.
Se gli viene assegnata una priorità più alta, le regole a grana fine con priorità più bassa che consentono il traffico da 10.10.30.5 non vengono mai applicate.
Per i protocolli bidirezionali come TCP, è essenziale definire regole in entrata e in uscita. La regola in uscita consente la richiesta iniziale di connessione TCP SYN, mentre la regola in entrata corrispondente deve accettare la risposta TCP SYN ACK. Senza entrambe le regole, la comunicazione non può essere stabilita.
Regole di esempio ACL-1
| Direzione | Consenti/Nega | IP di origine | Porta di origine | IP di destinazione | Porta di destinazione | Protocollo | Descrizione |
|---|---|---|---|---|---|---|---|
| In entrata | Consenti | 10.10.20.0/24 |
Qualsiasi | 10.10.10.0/24 |
Qualsiasi | Qualsiasi | Consentire tutto il traffico in entrata dalla sottorete 10.10.20.0/24 dove sono collocati i server back-end |
| In entrata | Consenti | 0.0.0.0/0 |
Qualsiasi | 10.10.10.0/24 |
80 | TCP | Consentire il traffico di HTTP da Internet al server web |
| In entrata | Consenti | 0.0.0.0/0 |
Qualsiasi | 10.10.10.0/24 |
443 | TCP | Consentire il traffico di HTTPS da Internet al server web |
| In entrata | Consenti | 0.0.0.0/0 |
80 | 10.10.10.0/24 |
Qualsiasi | TCP | Consentire il traffico di ritorno di HTTP da Internet al server web |
| In entrata | Consenti | 0.0.0.0/0 |
443 | 10.10.10.0/24 |
Qualsiasi | TCP | Consentire il traffico di ritorno di HTTPS da Internet al server web |
| In entrata | Nega | 0.0.0.0/0 |
Qualsiasi | 0.0.0.0/0 |
Qualsiasi | Qualsiasi | Rifiutare tutto il rimanente traffico in entrata |
| In uscita | Consenti | 10.10.10.0/24 |
Qualsiasi | 0.0.0.0/0 |
80 | TCP | Consentire il traffico HTTP dal server web a Internet |
| In uscita | Consenti | 10.10.10.0/24 |
Qualsiasi | 0.0.0.0/0 |
443 | TCP | Consentire il traffico HTTPS dal server web a Internet |
| In uscita | Consenti | 10.10.10.0/24 |
80 | 0.0.0.0/0 |
Qualsiasi | TCP | Consentire il ritorno del traffico HTTP dal server web a Internet |
| In uscita | Consenti | 10.10.10.0/24 |
443 | 0.0.0.0/0 |
Qualsiasi | TCP | Consentire a HTTPS il traffico di ritorno dal server web verso Internet |
| In uscita | Consenti | 10.10.10.0/24 |
Qualsiasi | 10.10.20.0/24 |
Qualsiasi | Qualsiasi | Consentire tutto il traffico in uscita verso la sottorete 10.10.20.0/24 dove sono collocati i server back-end |
| In uscita | Nega | 0.0.0.0/0 |
Qualsiasi | 0.0.0.0/0 |
Qualsiasi | Qualsiasi | Rifiutare tutto il rimanente traffico in uscita |
Regole di esempio ACL-2
| Direzione | Consenti/Nega | IP di origine | Porta di origine | IP di destinazione | Porta di destinazione | Protocollo | Descrizione |
|---|---|---|---|---|---|---|---|
| In entrata | Consenti | 10.10.10.0/24 |
Qualsiasi | 10.10.20.0/24 |
Qualsiasi | Qualsiasi | Consentire tutto il traffico in entrata dalla sottorete 10.10.10.0/24 dove sono collocati i server web |
| In entrata | Nega | 0.0.0.0/0 |
Qualsiasi | 0.0.0.0/0 |
Qualsiasi | Qualsiasi | Rifiutare tutto il rimanente traffico in entrata |
| In entrata | Nega | 0.0.0.0/0 |
80 | 10.0.20.0/24 |
Qualsiasi | Qualsiasi | Consentire a HTTP il traffico di ritorno da Internet |
| In entrata | Nega | 0.0.0.0/0 |
443 | 10.0.20.0/24 |
Qualsiasi | Qualsiasi | Consentire a HTTPS il traffico di ritorno da Internet |
| In uscita | Consenti | 10.10.20.0/24 |
Qualsiasi | 0.0.0.0/0 |
80 | TCP | Consentire il traffico HTTP verso Internet |
| In uscita | Consenti | 10.10.20.0/24 |
Qualsiasi | 0.0.0.0/0 |
443 | TCP | Consentire il traffico HTTPS verso Internet |
| In uscita | Consenti | 10.10.20.0/24 |
Qualsiasi | 10.10.10.0/24 |
Qualsiasi | Qualsiasi | Consentire tutto il traffico in uscita verso la sottorete 10.10.10.0/24 dove sono collocati i server web |
| In uscita | Nega | 0.0.0.0/0 |
Qualsiasi | 0.0.0.0/0 |
Qualsiasi | Qualsiasi | Rifiutare tutto il rimanente traffico in uscita |
Questo esempio illustra solo i casi generali. Nei tuoi scenari, potresti voler avere un controllo più dettagliato sul traffico:
- È possibile che un amministratore di rete abbia bisogno di accedere alla sottorete
10.10.10.0/24da una rete remota per scopi operativi. In tal caso, devi consentire il traffico SSH da Internet a questa sottorete. - Potresti voler restringere l'ambito del protocollo che consenti tra le tue due sottoreti.
Passi di esempio
I seguenti passi di esempio tralasciano i passi preliminari di utilizzo della CLI per creare un VPC, che devono essere eseguiti per primi. Per ulteriori informazioni, consulta Utilizzo della CLI per creare le risorse VPC.
Passo 1. Crea gli ACL
Utilizza i seguenti comandi della CLI per creare due ACL, denominati my_web_subnet_acl e my_backend_subnet_acl:
ibmcloud is network-acl-create my-web-subnet-acl $vpc_id --source-acl-id $old_acl_id
ibmcloud is network-acl-create my-backend-subnet-acl $vpc_id --source-acl-id $old_acl_id
La risposta include gli ID degli ACL appena creati. Salva gli ID di entrambi gli ACL per utilizzarli nei comandi successivi. Puoi utilizzare variabili denominate webacl e bkacl nel seguente modo:
webacl="0738-ba9e785a-3e10-418a-811c-56cfe5669676"
bkacl="0738-a4e28308-8ee7-46ab-8108-9f881f22bdbf"
Passo 2. Richiama le regole ACL predefinite
Prima di aggiungere le regole, richiama le regole ACL in entrata e in uscita predefinite in modo da poter inserire le nuove regole prima di esse.
ibmcloud is network-acl-rules $webacl
ibmcloud is network-acl-rules $bkacl
La risposta mostra le regole in entrata e in uscita predefinite che consentono tutto il traffico IPv4 in tutti i protocolli.
Getting rules of network acl ba9e785a-3e10-418a-811c-56cfe5669676 under account Demo Account as user demouser...
inbound
ID Name Action IPv* Protocol Source Destination Created
0738-e2b30627-1a1d-447b-859f-ac9431986b6f allow-all-inbound-rule-2d86bc3f-58e4-436a-8c1a-9b0a710556d6 allow ipv4 all 0.0.0.0/0 0.0.0.0/0 2 months ago
outbound
ID Name Action IPv* Protocol Source Destination Created
0738-173a3492-0544-472e-91c0-7828cbcb62d4 allow-all-outbound-rule-2d86bc3f-58e4-436a-8c1a-9b0a710556d6 allow ipv4 all 0.0.0.0/0 0.0.0.0/0 2 months ago
Salva gli ID di entrambe le regole ACL come variabili in modo da poter utilizzare i valori nei comandi successivi. Ad esempio, puoi salvare gli ID nelle variabili inrule e outrule:
inrule="0738-e2b30627-1a1d-447b-859f-ac9431986b6f"
outrule="0738-173a3492-0544-472e-91c0-7828cbcb62d4"
Passo 3. Aggiungere nuove regole ACL come descritto
In questo esempio, aggiungi prima le regole in entrata e quindi le regole in uscita.
Inserisci le nuove regole in entrata prima della regola in entrata predefinita.
ibmcloud is network-acl-rule-add my_web_acl_rule200 $webacl deny inbound any 0.0.0.0/0 0.0.0.0/0 \
--before-rule-id $in-rule
Ad ogni passo, salva l'ID della regola ACL in una variabile in modo che l'ID possa essere utilizzato nei comandi successivi. Ad esempio, puoi utilizzare la variabile acl200:
acl200="0738-90930627-1a1d-447b-859f-ac9431986b6f"
Ora aggiungi la regola a acl200:
ibmcloud is network-acl-rule-add my_web_acl_rule100 $webacl allow inbound any 10.10.20.0/24 0.0.0.0/0 \
--before-rule-id $acl200
Aggiungi altre regole fino al completamento della tua configurazione dell'ACL, salvando ogni ID come variabile.
acl100="0738-78340627-1a1d-447b-859f-ac9431986b6f"
ibmcloud is network-acl-rule-add my_web_acl_rule20 $webacl allow inbound tcp 0.0.0.0/0 0.0.0.0/0 \
--source-port-min 443 --source-port-max 443 --before-rule-id $acl100
acl20="32450627-1a1d-447b-859f-ac9431986b6f"
ibmcloud is network-acl-rule-add my_web_acl_rule10 $webacl allow inbound tcp 0.0.0.0/0 0.0.0.0/0 \
--source-port-max 80 --source-port-min 80 --before-rule-id $acl20
Inserisci le nuove regole in uscita prima della regola in uscita predefinita.
ibmcloud is network-acl-rule-add my_web_acl_rule200e $webacl deny outbound any 0.0.0.0/0 0.0.0.0/0 \
--before-rule-id $outrule
acl200e="11110627-1a1d-447b-859f-ac9431986b6f"
ibmcloud is network-acl-rule-add my_web_acl_rule100e $webacl allow outbound any 0.0.0.0/0 10.10.20.0/24 \
--before-rule-id $acl200e
acl100e="22220627-1a1d-447b-859f-ac9431986b6f"
ibmcloud is network-acl-rule-add my_web_acl_rule20e $webacl allow outbound tcp 0.0.0.0/0 0.0.0.0/0 \
--source-port-max 443 --source-port-min 443 --before-rule-id $acl100e
acl20e="33330627-1a1d-447b-859f-ac9431986b6f"
ibmcloud is network-acl-rule-add my_web_acl_rule10e $webacl allow outbound tcp 0.0.0.0/0 0.0.0.0/0 \
--source-port-max 80 --source-port-min 80 --before-rule-id $acl20e
Passo 4. Creare le due sottoreti con la ACL appena creata
Crea due sottoreti in modo che ognuno dei tuoi ACL sia associato a una delle nuove sottoreti.
ibmcloud is subnet-create my-web-subnet $vpc_id $zone --ipv4_cidr_block 10.10.10.0/24 \
--network-acl-id $webacl
ibmcloud is subnet-create my-backend-subnet$vpc_id $zone --ipv4_cidr_block 10.10.20.0/24 \
--network-acl-id $bkacl
Scheda di riferimento dell'elenco di comandi
Per mostrare un elenco completo dei comandi della CLI VPC disponibili per gli ACL:
ibmcloud is network-acls
Per visualizzare il tuo ACL e i relativi metadati, comprese le regole:
ibmcloud is network-acl $webacl
Per elencare tutte le regole ACL:
ibmcloud is network-acl-rules $webacl
Regola ping in entrata di esempio
Per aggiungere una regola ACL, ecco un comando di esempio per aggiungere una regola in entrata ping prima della regola in entrata predefinita:
Sintassi:
ibmcloud is network-acl-rule-add ACL ACTION DIRECTION PROTOCOL SOURCE DESTINATION [--name NAME] [--icmp-type ICMP_TYPE] [--icmp-code ICMP_CODE] [--source-port-min PORT_MIN] [--source-port-max PORT_MAX] [--destination-port-min PORT_MIN] [--destination-port-max PORT_MAX] [--before-rule-id RULE_ID] [--output JSON] [-q, --quiet]
Esempio:
ibmcloud is network-acl-rule-add 72b27b5c-f4b0-48bb-b954-5becc7c1dcb3 allow inbound icmp 10.2.2.2 10.2.2.3 --icmp-type 8 --icmp-code 0