Si003 - Sicurezza delle reti nell'Amministrazione federale - Sicurezza delle reti nell'Amministrazione federale
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Dipartimento federale delle finanze DFF
Centro nazionale per la cibersicurezza NCSC
Sicurezza informatica della Confederazione
Versione 3.1
Si003 – Sicurezza delle reti
nell’Amministrazione federale
del 19 dicembre 2013 (stato: 1° aprile 2021)
Ai sensi dell’articolo 11 capoverso 1 lettera e dell’ordinanza del 27 maggio 2020 sui ciber-
rischi (OCiber) [1], il delegato alla cibersicurezza emana la seguente direttiva per la
protezione di base di cui all’articolo 14c OCiber.
Il documento «Si002 - Matrice d’accesso» del 19 dicembre 2013 (versione 5.1, stato:
22 maggio 2019) [2] è integrato nelle presenti direttive ed è abrogato all’entrata in vigore
della loro versione 3.0.Si003 – Sicurezza delle reti nell’Amministrazione federale
Indice
Indice 2
1 Disposizioni generali .................................................................................... 3
1.1 Oggetto ................................................................................................................... 3
1.2 Campo d’applicazione ........................................................................................... 3
1.3 Definizioni ............................................................................................................... 3
2 Modello delle zone della Confederazione ................................................... 4
3 Principi .......................................................................................................... 5
4 Matrice d’accesso ......................................................................................... 7
5 Altri requisiti ............................................................................................... 10
6 Finanziamento............................................................................................. 11
7 Entrata in vigore e disposizioni transitorie .............................................. 12
Abbreviazioni ........................................................................................................... 13
Riferimenti................................................................................................................ 14
Allegato A: Zone policy per il dominio di rete blu ................................................ 15
A.1 Requisiti e direttive per i sistemi TIC .................................................................. 15
A.2 Requisiti e direttive per il dominio di rete blu .................................................... 15
A.3 Requisiti e direttive per le comunicazioni autorizzate ....................................... 15
A.3.1 Comunicazione interna ........................................................................................ 15
A.3.2 Comunicazione esterna ....................................................................................... 15
Allegato B: Matrice d’accesso per il dominio di rete blu e la SSZ ...................... 16
2/17Si003 – Sicurezza delle reti nell’Amministrazione federale
1 Disposizioni generali
1.1 Oggetto
1
Le presenti direttive devono essere intese come parte della protezione di base delle TIC
nell’Amministrazione federale [3] specifica per la sicurezza delle reti.
1.2 Campo d’applicazione
1
Il campo d’applicazione è disciplinato dall’articolo 2 dell’ordinanza del 27 maggio 2020 sulla
protezione contro i ciber-rischi nell’Amministrazione federale (ordinanza sui ciber-rischi,
OCiber) [1].
1.3 Definizioni
1
Nelle presenti direttive vengono utilizzati i termini e le espressioni seguenti.
a) Sistema TIC (sistema): sistema tecnico informatico e per le comunicazioni che viene
gestito come un software su un hardware dedicato o virtuale oppure su un dispositivo
virtuale1. Nel secondo caso si parla di sistema TIC virtuale.
b) Un sistema TIC è2:
• un sistema di server quando fornisce principalmente prestazioni TIC;
• un sistema client quando è principalmente il beneficiario di prestazioni TIC;
• un componente di rete se serve principalmente per il trasporto di dati tra altri
sistemi TIC (ad es. switch, router o filtri di pacchetti statici semplici [firewall
IP]). Nel modello di riferimento OSI (open systems interconnection) i
componenti di rete funzionano fino al livello 4 compreso (livello di trasporto);
• un policy enforcement point (PEP), quando serve principalmente ad
applicare regole (o linee di condotta) come ad esempio filtri di pacchetti
dinamici, gateway per protocolli applicativi, server proxy e server proxy
inversi3. Nel modello di riferimento OSI i PEP intervengono fino al livello 7
compreso (livello applicativo).
c) Zona: raggruppamento logico di sistemi TIC che presentano requisiti di sicurezza
simili e sottostanno alla stessa zone policy. Pertanto, una zona non è limitata a un
determinato luogo (ad es. centro di calcolo). La connessione a livello di rete degli
elementi di una zona avviene tramite i componenti di rete, mentre l’applicazione delle
regole della zone policy è effettuata dai PEP, che idealmente sono gestiti in una zona
specifica (policy enforcement zone, PEZ).
d) Sottozona: una zona può essere suddivisa in sottozone se la policy corrispondente
lo prevede. Ogni sottozona costituisce a sua volta una zona. In particolare, ogni
sottozona deve avere una policy che preveda requisiti più severi rispetto alla zona
superiore. In altre parole, questa policy può contenere soltanto requisiti o prescrizioni
supplementari (non sono ammesse attenuazioni). In linea di massima una sottozona
può essere ulteriormente suddivisa in sottozone supplementari, ma soltanto in casi di
estrema necessità.
1
Il sistema TIC che mette a disposizione l’hardware virtuale o un dispositivo virtuale (hypervisor) è a sua volta un
software ed è quindi considerato un sistema TIC autonomo.
2
Questa distinzione non è precisa perché un sistema TIC può svolgere contemporaneamente diverse funzioni e
quindi essere considerato sia un sistema client sia un sistema server.
3
La caratteristica principale di un PEP è data dal fatto che interviene a livello applicativo e controlla i protocolli
trasmessi.
3/17Si003 – Sicurezza delle reti nell’Amministrazione federale
e) Segmento: parte di una rete (all’interno di una zona) che, per ragioni di
bilanciamento del carico e/o di sicurezza, è separata dal resto della rete mediante
componenti di rete secondo le prescrizioni della zone policy. Tutti i segmenti di una
rete (all’interno di una zona) sottostanno fondamentalmente alla stessa zone policy,
sebbene sia possibile prevedere regole specifiche più severe.
2 Modello delle zone della Confederazione
1
Il modello delle zone della Confederazione è un modello generico che serve a definire le
zone nell’Amministrazione federale. Esso è vincolante per tutte le unità amministrative (UA;
beneficiari delle prestazioni [BP] e fornitori delle prestazioni [FP]) e stabilisce, in particolare, i
sistemi TIC e le reti dell’Amministrazione federale che devono essere organizzati e gestiti in
zone e sottozone.
2
Ad eccezione di Internet, ogni (sotto)zona deve avere un proprietario e un gestore (cfr.
n. 3). Il proprietario è responsabile della zone policy, mentre il gestore dell’attuazione della
policy. Nel caso in cui il proprietario di una (sotto)zona modifichi la policy, al gestore deve
essere concesso un termine di attuazione adeguato.
Figura 1: Modello (generico) delle zone della Confederazione
3
La figura 1 illustra schematicamente il modello delle zone. Si fa una distinzione tra le
seguenti zone e sottozone:
a) Internet: zona che non corrisponde a nessun criterio delle altre zone e per la quale
non può essere definito nessun requisito (di sicurezza);
b) policy enforcement zone (PEZ): zona per i PEP necessari per l’applicazione delle
regole relative alla comunicazione esterna con altre zone;
c) zona dei servizi (service zone): zona destinata a sistemi di server necessari per la
fornitura di servizi infrastrutturali (ad es. server DNS e time server);
4/17Si003 – Sicurezza delle reti nell’Amministrazione federale
d) zona server (server zone, SZ): zona destinata a sistemi di server sui quali sono
gestite applicazioni specializzate che non presentano un bisogno di protezione
elevato secondo l’analisi del bisogno di protezione;
e) zona server con un elevato bisogno di protezione (SZ+): sottozona della SZ per i
sistemi di server sui quali sono gestite applicazioni specializzate che presentano un
bisogno di protezione elevato secondo l’analisi del bisogno di protezione;
f) zona client (client zone, CZ): zona per i sistemi client. L’esercizio di sistemi di
server nella CZ o in una sottozona è ammesso se la policy corrispondente lo prevede
e se i sistemi di server sono utilizzati principalmente dai sistemi client della stessa
(sotto)zona (ad es. server locale per la burotica o di stampa);
g) zona SPL: sottozona della CZ per i sistemi client che funzionano come sistemi di
postazioni di lavoro (SPL) e sono utilizzati esclusivamente dal servizio standard TIC
Burotica / UCC;
h) zona ospiti: sottozona della CZ per i sistemi client che non sono gestiti da un’UA
della Confederazione, ad esempio dispositivi utilizzati da collaboratori esterni o da
dipendenti dell’Amministrazione federale nell’ambito della politica «Bring Your Own
Device» (BYOD).
i) zona speciale: zona per i sistemi TIC dell’Amministrazione federale che presentano
caratteristiche speciali ed esigenze corrispondenti, come ad esempio l’autonomia
operativa o la connessione alla rete a banda stretta, e che possono essere gestiti
dalla zona di gestione (ad es. rete di trasporto con requisiti specifici);
j) zona tecnica: zona specifica per i sistemi TIC e IoT, come ad esempio i sistemi per
l’impiantistica degli edifici o per il facility management, i sistemi di rilevamento del
tempo di lavoro, i sistemi di misurazione e i sistemi di supporto diagnostico a
distanza;
k) zona di gestione: zona specifica per i sistemi TIC che sono utilizzati esclusivamente
per amministrare i sistemi TIC di altre zone.
Oltre a queste zone, esistono diversi domini di rete che possono essere gestiti nel quadro
delle disposizioni transitorie di cui al numero 7 capoverso 2. Essi non rientrano nel modello
delle zone e non sono illustrati nell’immagine 1.
4
In linea di principio, ogni (sotto)zona del modello delle zone dell’Amministrazione federale
può essere attivata più volte.
5
Se un’applicazione specializzata non è gestita in una zona dell’Amministrazione federale
(ad es. in un cloud pubblico), la relativa documentazione sulla sicurezza (ossia il documento
«Attuazione delle misure per la protezione di base delle TIC nell’Amministrazione federale» o
il piano SIPD esteso) deve indicare come poter raggiungere e garantire, in questo ambiente,
un livello di sicurezza adeguato e paragonabile a quello dell’Amministrazione federale. Tale
documentazione deve essere esaminata dall’incaricato della sicurezza informatica dell’UA
(ISIU) e approvata dai responsabili dei processi aziendali.
Le spiegazioni seguenti valgono sia per le zone sia per le sottozone. Per facilitare la lettura
di seguito sarà utilizzato soltanto il termine «zona».
3 Principi
1
All’interno dell’Amministrazione federale possono essere create e gestite soltanto zone
conformi al modello delle zone della Confederazione, che adempiono i requisiti indicati ai
numeri 4 (matrice d’accesso) e 5 (requisiti di sicurezza) e che hanno un proprietario, un
nome univoco, una zone policy definita dal proprietario e un gestore.
5/17Si003 – Sicurezza delle reti nell’Amministrazione federale
a) Proprietario: nome dell’UA della Confederazione responsabile della zona. Il
proprietario della zona deve garantirne il finanziamento (si veda il n. 6) e decidere
quali sistemi TIC possono essere gestiti nella zona.
b) Nome: nome univoco della zona, che può essere ottenuto, ad esempio, associando
l’identificativo del proprietario al nome come suffisso (ad es. SZ-BAC per una zona
server gestita dalla Base d’aiuto alla condotta [BAC]). Se un proprietario attiva più
volte una zona, i nomi corrispondenti devono essere chiaramente distinguibili.
c) Zone policy: descrizione strutturata, elaborata dal proprietario conformemente alle
direttive dell’NCSC, dei requisiti e delle direttive concernenti:
• i sistemi TIC della zona;
• la zona stessa, ad esempio se può essere segmentata sulla rete e, in caso
affermativo, in che modo;
• l’autenticazione delle persone e dei processi automatizzati che possono accedere
ai sistemi TIC e alle applicazioni gestiti nella zona (conformemente alla matrice
d’accesso di cui al n. 4); e
• le comunicazioni interne (anche quelle tra segmenti) ed esterne (anche quelle che
esulano dall’ambito della PEZ) ammesse nella zona, cioè le comunicazioni
consentite in entrata e in uscita4. Una comunicazione tra due o più zone simili5 è
considerata interna se le interfacce tra le zone sono conformi ai regolamenti e
sono controllate in una PEZ comune. Le comunicazioni esterne comprendono
anche quelle con i domini di rete che continuano a essere gestiti ai sensi delle
disposizioni transitorie di cui al numero 7 capoverso 2.
d) Gestore: nome dell’UA della Confederazione che in qualità di FP gestisce la zona
per conto del proprietario dal punto di vista della tecnologia delle reti6. In particolare, il
gestore deve garantire che possano avere luogo soltanto le comunicazioni da e verso
la zona consentite dalla zone policy e che, con l’ausilio di adeguate misure di
sicurezza complementari, tali comunicazioni non costituiscano un’ulteriore minaccia
per le altre zone. Se non indicato diversamente nella zone policy, con il consenso del
proprietario di una zona, all’interno della stessa si possono gestire anche i sistemi
TIC di altri FP (anche esterni). I FP sono quindi corresponsabili per l’osservanza della
zone policy nel loro ambito di competenza.
2
Ogni zona deve essere documentata e verificata7 sia dal proprietario sia dal gestore nonché
approvata analogamente alla documentazione sulla sicurezza di un’applicazione
specializzata.
3
L’ISID tiene un elenco aggiornato delle zone il cui proprietario o gestore è un’UA del
dipartimento e mette questo elenco a disposizione dell’NCSC.
4
Ogni sistema TIC utilizzato nell’Amministrazione federale deve essere assegnato a una
zona e gestito conformemente alla policy in vigore per quest’ultima. Se non è assegnato a
4
Una comunicazione è considerata in uscita se il relativo scambio di dati è attivato da un sistema TIC della zona
interessata. Per contro, è considerata in entrata se lo scambio di dati, pur essendo attivato da un sistema TIC al
di fuori della zona, riguarda un sistema TIC nella zona. In entrambi i casi i dati possono essere scambiati nelle
due direzioni.
5
Queste zone possono anche avere proprietari diversi.
6
Se il proprietario della zona è un FP, il proprietario e il gestore possono coincidere. Se la zona comprende
sistemi TIC e applicazioni gestiti al di fuori dell’Amministrazione federale (ad es. in un cloud pubblico), la
gestione della zona si limita al collegamento alla rete di questi sistemi TIC e applicazioni.
7
Spetta al rispettivo ISIU del proprietario o del FP effettuare tale verifica. Dal punto di vista del FP occorre
verificare, in particolare, che l’esercizio della zona non comporti rischi aggiuntivi non prevedibili dai proprietari
delle altre zone.
6/17Si003 – Sicurezza delle reti nell’Amministrazione federale
nessuna zona, per quanto riguarda le presenti direttive il sistema TIC appartiene a Internet.
4 Matrice d’accesso
1
La matrice d’accesso stabilisce i requisiti minimi concernenti l’autenticazione (centrale o
decentralizzata) e i relativi mezzi di autenticazione e di identificazione. Su questa base,
conformemente al numero 3 capoverso 1 lettera c, nella zone policy occorre stabilire in che
modo le persone e i processi automatizzati possono accedere ai sistemi TIC e alle
applicazioni gestiti nella zona nonché come autenticare ed eventualmente autorizzare tali
persone e processi. Inoltre, il responsabile di un sistema o di un’applicazione può specificare
ulteriori requisiti in merito alle modalità di accesso o vietare determinate modalità di accesso.
2
In linea di principio, l’autenticazione dovrebbe essere eseguita a livello centrale nella PEZ
prima dell’accesso alla zona. Se ciò non fosse possibile o opportuno, l’autenticazione può
essere eseguita anche a livello decentrato su un PEP nella zona stessa. Tuttavia, in questo
caso la zone policy deve indicare come proteggere da eventuali accessi non autorizzati i
sistemi TIC e le applicazioni specializzate gestiti nella zona. In particolare, sarebbe
necessario segmentare la rete e isolare il più possibile questi sistemi TIC e queste
applicazioni specializzate sotto il profilo della tecnologia della rete.
3
I mezzi di autenticazione e di identificazione disponibili con i relativi sistemi federati sono
suddivisi nei seguenti quattro livelli di sicurezza (basso, medio, elevato e molto elevato)8:
a) basso: le credenziali di autenticazione trasmesse attraverso la rete sono statiche e
identiche per ogni autenticazione, vale a dire che possono essere intercettate da un
hacker e utilizzate illecitamente, ad esempio durante un replay-attack, nel quale viene
simulata l’identità del titolare delle credenziali. Tipici esempi di credenziali di questo
tipo sono il nome utente e la password. Se sono utilizzate come token per
l’autenticazione federata ai sensi del documento [4], le credenziali di autenticazione
devono essere protette solo marginalmente contro gli attacchi all’integrità e associate
al contesto dell’utente. Possibili esempi sono diversi token d’accesso come i cookies;
b) medio: le credenziali di autenticazione cambiano a ogni accesso e risultano dunque
dinamiche. Tali credenziali non possono quindi essere utilizzate illecitamente durante
un replay-attack, nel quale viene simulata l’identità del titolare delle credenziali.
Esempi di credenziali di questo tipo sono il nome utente e la password con codice di
verifica via SMS9 o vincolati al dispositivo, le soluzioni software OTP (ad es. Google
Authenticator) e i certificati di software emessi dalla SG-KPI (classe C, D o E). Le
credenziali utilizzate come token per l’autenticazione federata devono essere protette
contro gli attacchi all’integrità e associate al contesto dell’utente avvalendosi di
tecnologie innovative. Esempi di credenziali di questo tipo sono i cosiddetti ticket
Kerberos delle foreste di risorse del servizio standard TIC Burotica nonché i token
d’accesso trasmessi tramite SAML o OIDC/OAuth come JWT;
c) elevato: le credenziali di autenticazione sono dinamiche e protette da una chiave
crittografica inserita in un modulo hardware dedicato, dal quale (con un onere
sostenibile) non possono essere lette. Se il mezzo di autenticazione e identificazione
è personale, la registrazione della persona interessata o la consegna del mezzo di
8
In linea di principio lo standard TIC I050 [4] definisce quattro livelli di affidabilità (Level of Assurance, LoA) 1–4,
ai quali si potrebbe ricorrere per specificare i requisiti minimi di sicurezza dei mezzi di autenticazione e
identificazione da impiegare. Dal momento che non è stata ancora presentata la classificazione LoA dei mezzi
di autenticazione e identificazione oggi disponibili e in uso, nel presente documento si utilizza, come soluzione
transitoria, una classificazione semplice che si limita ad alcuni aspetti tecnici di sicurezza dei suddetti mezzi.
9
Anche se sono ancora indicati come esempio, allo stato attuale il nome utente e la password con codice di
verifica via SMS non dovrebbero più essere utilizzati come mezzi di autenticazione e identificazione. Si è
rilevato infatti che la verifica via SMS viene aggirata troppo spesso e troppo facilmente nella pratica.
7/17Si003 – Sicurezza delle reti nell’Amministrazione federale
identificazione ad essa deve essere effettuata sulla base di un documento d’identità
ufficiale (ad es. passaporto o carta d’identità). Se l’identità della persona viene
verificata all’atto della registrazione, il mezzo di identificazione deve essere
consegnato con raccomandata. La consegna può anche essere protetta mediante un
codice segreto (ad es. password o PIN) o un elemento biometrico (ad es. Touch ID o
Face ID per Apple o Hello per Windows). Esempi di credenziali di questo tipo sono i
token OTP, le soluzioni OTP basate su un Trusted Platform Module (TPM), i token
FIDO2, Swisscom Mobile ID o SuisseID. Le credenziali di autenticazione utilizzate
come token per l’autenticazione federata devono essere protette contro gli attacchi
all’integrità e associate al contesto dell’utente avvalendosi di tecnologie innovative.
Nel complesso, il sistema federato deve corrispondere a un profilo di protezione
equivalente ai Common Criteria EAL4+. Esempi di credenziali di questo tipo sono
SSO-Identity e SSO-Federation del portale SSO e i ticket Kerberos delle foreste di
utenti, se questi sono stati emessi sulla base dell’autenticazione dell’utente con
certificato rilasciato dalla SG-PKI;
d) molto elevato: i mezzi di autenticazione e identificazione soddisfano i requisiti del
livello «elevato» (compresi quelli relativi al sistema federato). Inoltre, sia il modulo
hardware che il rispettivo processo di registrazione devono essere riconosciuti
dall’NCSC per l’Amministrazione federale. Gli unici esempi in questo caso sono i
certificati emessi dalla SG-PKI sulle smart card (classe B).
Gli esempi menzionati e riassunti nella tabella 1 non sono esaustivi.
Livello di
Esempi di mezzi di autenticazione e identificazione
sicurezza
Basso • Nome utente e password
• Token d’accesso (ad es. cookies)
Medio • Nome utente e password con codice di verifica via SMS
• Nome utente e password vincolati al dispositivo
• Soluzione software OTP (ad es. Google Authenticator)
• Certificato di software emesso dalla SG-PKI (classe C, D oppure E)
• Ticket Kerberos delle foreste di risorse del servizio standard TIC Burotica
• Token d’accesso trasmessi tramite SAML o OIDC/OAuth come JWT
• Token OTP (ad es. RSA, Vasco ecc.)
Elevato • Soluzione OTP basata su un TPM
• Token FIDO2
• Swisscom Mobile ID
• SuisseID (finché offerto ufficialmente)
• SSO-Identity/SSO-Federation del portale SSO
• Ticket Kerberos delle foreste di utenti (SG-PKI)
Molto • Certificato emesso dalla SG-PKI su smart card (classe B)
elevato
Tabella 1: Livelli di sicurezza di alcuni mezzi di autenticazione e identificazione
In linea di principio il livello di sicurezza non può essere aumentato a seguito dell’accumulo
di diversi mezzi di autenticazione e identificazione. Ciò significa che un certificato software
8/17Si003 – Sicurezza delle reti nell’Amministrazione federale
emesso dalla SG-PKI continua a mantenere, ad esempio, il livello di sicurezza «medio»
anche se combinato con nome utente e password con codice di verifica per SMS.
4
Sono escluse dai requisiti della matrice d’accesso le possibilità di accesso anonimo e
personalizzato create nel quadro delle applicazioni di Governo elettronico e che vengono
rese accessibili a una larga fascia della popolazione in una zona server (come ad es. le
pagine web pubbliche dell’Amministrazione federale), le possibilità di accesso limitate nel
tempo per caricare i dati su un sistema di server in una zona server10 nonché gli accessi
automatizzati eseguiti con il consenso del proprietario di una zona nell’ambito di controlli
della sicurezza di pagine web (scan).
5
L’accesso limitato11 a una zona è consentito a persone e processi automatizzati che si
autenticano almeno con una credenziale di livello «medio» (anche di livello «basso» per gli
apparecchi di misurazione12). Se si accede a una zona con un elevato bisogno di protezione
(ad es. SZ+), il mezzo di autenticazione e identificazione deve presentare almeno il livello di
sicurezza «elevato».
6
L’accesso illimitato a una zona è consentito unicamente a persone che si collegano tramite
un sistema client gestito nel servizio standard TIC Burotica13 e autenticate nella PEZ con un
mezzo di autenticazione e identificazione almeno di livello «elevato».
7
La matrice d’accesso e i capoversi 5 e 6 possono quindi essere schematizzati come segue
[2]:
10
In questo caso la distinzione dei sistemi server corrispondenti dagli altri sistemi TIC nella zona server deve
essere documentata in una zone policy oppure – insieme a tutte le misure di sicurezza complementari prese allo
scopo di minimizzare i rischi – nella documentazione sulla sicurezza dell’applicazione. Naturalmente, anche il
proprietario della zona deve essere d’accordo con l’esercizio dei sistemi di server.
11
Un accesso si dice limitato quando, mediante provvedimenti tecnici (ad es. filtraggio pacchetti IP), è limitato a
pochi sistemi TIC o applicazioni definiti o a uno soltanto di questi e ai protocolli obbligatoriamente necessari per
l’accesso. Altrimenti, l’accesso si dice illimitato.
12
Un apparecchio di misurazione è un sistema TIC il cui compito principale consiste nel trasmettere i valori
misurati da un sensore, presente sul luogo della misurazione, a un secondo sistema TIC lontano attraverso una
connessione dedicata che non può essere utilizzata per altri scopi. Il sistema TIC ricevente può soltanto
raccogliere e registrare i valori misurati o può anche analizzarli ed elaborarli ulteriormente. Le comunicazioni
possono essere effettuate bilateralmente e comprendere, ad esempio, la trasmissione di informazioni di
controllo all’apparecchio di misurazione.
13
Può trattarsi di un SPL oppure di un sistema client virtuale e gestito all’interno di una sandbox con Mobile
Device Management (MDM). In entrambi i casi vengono rispettate le prescrizioni di sicurezza
dell’Amministrazione federale; nel documento [2] e nella tabella 2 questi sistemi client sono definiti client della
Confederazione (CC).
9/17Si003 – Sicurezza delle reti nell’Amministrazione federale
Sistema TIC utilizzato per l’accesso
AM
(apparecc CC SP TE
hio di (client della (sistema (terminale
misurazio Confederazione) partner) esterno)
ne)
illimitato elevat
elevato Accesso non consentito
Accesso
o
limitato basso elevat med elevat med elevat
medio
o io o io o
Protezione Protezione Prote Prot Prote Prot Prote
di base di base zione ezio zione ezio zione
elevat ne di elevat ne di elevat
a base a base a
Bisogno di protezione
Tabella 2: Matrice d’accesso
5 Altri requisiti
1
All’interno di una zona i sistemi TIC possono essere gestiti virtualmente. La virtualizzazione
tra diverse zone e tra diversi segmenti è ammessa, tenendo in considerazione il
requisito 13.1.2 della protezione di base delle TIC [3], nella misura in cui nessuna zone
policy interessata lo vieti. Ciò vale anche per le parti di una PEZ che non riguardano le
interfacce con Internet (in questo caso la virtualizzazione tra diverse zone non è ammessa).
2
All’interno di una zona, la comunicazione deve essere monitorata in modo da permettere
che gli attacchi basati sulla rete e quelli perpetrati su sistemi TIC siano individuati nel modo
più affidabile possibile (ad es. con l’ausilio di software che verificano l’integrità e sistemi di
individuazione degli attacchi [IDS] o di prevenzione degli attacchi [IPS]) e che, in caso di
necessità, il gestore reagisca rapidamente e in maniera adeguata.
3
Qualsiasi comunicazione tra zone deve passare attraverso una PEZ14. Essa deve garantire
che la comunicazione sia conforme alla pertinente zone policy. A tal fine, i modelli di
comunicazione e le relazioni di comunicazione autorizzati devono essere definiti con la
massima precisione nelle zone policies, idealmente a livello applicativo e sotto forma di «lista
bianca» (white list). Se non è possibile verificare la conformità in una PEZ (ad es. nel caso di
una comunicazione end-to-end crittografata), la verifica può essere effettuata anche tramite i
sistemi TIC nelle zone stesse (sotto forma di PEP). Occorre tuttavia prevedere misure
complementari di attenuazione dei rischi. È inoltre possibile consultare l’NCSC.
4
Si devono utilizzare protocolli di comunicazione standardizzati e consolidati provenienti
dalla serie di protocolli TCP/IP (anziché protocolli proprietari). A tal fine si deve considerare il
principio del privilegio minimo (least privilege) ai sensi del requisito 7.1.4 della protezione di
base delle TIC [3]. In altre parole, possono essere supportati soltanto i protocolli che sono
anche effettivamente necessari ai sistemi TIC gestiti nella zona.
14
Sebbene, in linea di principio, questa regola valga anche per le comunicazioni da una sottozona alla zona
superiore, in casi motivati e documentati nelle policies delle rispettive sottozone è possibile derogarvi.
10/17Si003 – Sicurezza delle reti nell’Amministrazione federale
5
Ai sensi del requisito 13.1.5 della protezione di base delle TIC [3] occorre disciplinare
l’accesso alle risorse in Internet mediante un’infrastruttura web proxy e gli accessi consentiti.
Tale regolamentazione può essere definita nella zone policy della PEZ attraverso la quale
avvengono gli accessi, nelle policies delle zone interessate o in una direttiva separata. In
ogni caso, l’NCSC può contribuire a inserire i dati nei rispettivi set di regole.
6
La connessione di una PEZ a Internet deve essere altamente disponibile ed eventualmente
ridondante. Inoltre, il gestore deve garantire con misure appropriate che i sistemi TIC
separati da Internet con la PEZ siano adeguatamente protetti da attacchi DoS e DDoS.
7
Le raccomandazioni di sicurezza [5] si applicano all’utilizzo di procedure e meccanismi
crittografici.
6 Finanziamento
1
Il finanziamento di una zona e la sua attuazione devono essere garantiti dal proprietario. Si
applicano i principi di contabilità analitica nell’Amministrazione federale.
11/17Si003 – Sicurezza delle reti nell’Amministrazione federale
7 Entrata in vigore e disposizioni transitorie
1
Le direttive sulla sicurezza delle reti entrano in vigore il 1° gennaio 2021.
2
Eventuali deroghe devono essere richieste mediante il processo standard P035 («IKT-
Anforderungs und Vorgabenmanagement Stufe Bund»).
3
Il settore Trasformazione digitale e governance delle TIC (TDT) chiarisce se, e in caso
affermativo in quale forma, l’adeguatezza e l’economicità delle zone devono essere verificate
e approvate ed emana pertinenti direttive. Nel frattempo, le zone devono essere richieste al
TDT mediante il suddetto processo standard P035.
4
Fino a quando la proprietà del dominio di rete blu non sarà chiarita e non saranno emanate
direttive in materia, si applicheranno sia la zone policy dell’allegato A con tutte le deroghe
autorizzate e gli accordi conclusi15 sia la matrice d’accesso dell’allegato B16.
5
Fino all’entrata in vigore di una direttiva di cui al numero 5 capoverso 5, all’infrastruttura
web proxy del servizio standard TIC Trasmissione dati si applicherà il documento [6].
6
Le direttive sulla sicurezza delle reti nell’Amministrazione federale vengono costantemente
verificate e, se necessario, modificate.
15
In questo caso si tratta di un accordo con i Servizi del Parlamento.
16
Eventuali decisioni al riguardo saranno sottoposte all’NCSC dal TDT.
12/17Si003 – Sicurezza delle reti nell’Amministrazione federale
Abbreviazioni
BP Beneficiario delle prestazioni
BYOD Bring Your Own Device
CC Client della Confederazione
CZ Client Zone
DDoS Distributed Denial of Service
DoS Denial of Service
EAL Evaluation Assurance Level
FIDO Fast IDentity Online
FP Fornitore delle prestazioni
HTTPS Hypertext Transfer Protocol Secure
IDS Intrusion Detection System (sistemi di individuazione delle intrusioni)
IoT Internet of Things (Internet delle cose)
IP Protocollo Internet
IPS Intrusion Prevention System (sistema di prevenzione delle intrusioni)
JSON JavaScript Object Notation
JWT JSON Web Token
LoA Level of Assurance
MDM Mobile Device Management
NCSC Centro nazionale per la cibersicurezza
NW Full Network Access
OAuth Open Authorization
OCiber Ordinanza sui ciber-rischi
OIAF Ordinanza sull’informatica nell’Amministrazione federale
OIDC OpenID Connect
OSI Open Systems Interconnection
OTP One-Time Password
PEP Policy Enforcement Point
PEZ Policy Enforcement Zone
PIN Personal Identification Number
RA Restricted Access
REST Representational State Transfer
SAML Security Assertion Markup Language
SG-PKI Swiss Government Public Key Infrastructure
SIPD Sicurezza delle informazioni e protezione dei dati
SMS Short Messaging Service
SOAP Simple Object Access Protocol
SPL Sistemi di postazioni di lavoro
SSZ Shared Service Zone
SZ Server Zone (zona server)
SZ+ Server Zone+ (zona server con un elevato bisogno di protezione)
TCP Transport Control Protocol
TE Terminale esterno
TDT Trasformazione digitale e governance delle TIC
TIC Tecnologie dell’informazione e della comunicazione
TPM Trusted Platform Module
UCC Unified Communication & Collaboration
XML Extensible Markup Language
13/17Si003 – Sicurezza delle reti nell’Amministrazione federale
Riferimenti
[1] Ordinanza del 27 maggio 2020 sulla protezione contro i ciber-rischi
nell’Amministrazione federale (ordinanza sui ciber-rischi, OCiber).
[2] Si002 – Matrice d’accesso, versione 5.1 del 19 dicembre 2013 (stato:
22 maggio 2019).
[3] Si001 – Protezione di base delle TIC nell’Amministrazione federale, versione 4.4 del
19 dicembre 2013 (stato: 1° gennaio 2020).
[4] Standard TIC I050 sull’affidabilità delle conferme dell’identità, disponibile in tedesco
(«Verlässlichkeit von Identitätsbestätigungen»), versione 1.0 del 1° luglio 2019.
[5] Raccomandazioni in materia di sicurezza per la protezione di base delle TIC −
procedura di crittografia: algoritmi e protocolli, disponibile in tedesco («IKT-
Sicherheitsempfehlungen für den IKT-Grundschutz – Kryptografische Verfahren:
Algorithmen und Protokolle»), versione 1.2 del 13 dicembre 2019.
[6] Si004 – Regolamentazione degli accessi alle risorse su Internet, direttiva sui web proxy
dell’AF, versione 1.3 del 4 ottobre 2016 (stato: 1° aprile 2019).
14/17Si003 – Sicurezza delle reti nell’Amministrazione federale
Allegato A: Zone policy per il dominio di rete blu
A.1 Requisiti e direttive per i sistemi TIC
1
Un sistema TIC può essere gestito nel dominio di rete blu se soddisfa i requisiti di cui al
capitolo 3a OCiber [1], ovvero i requisiti relativi all’analisi del bisogno di protezione, alla
protezione di base delle TIC e al piano SIPD.
A.2 Requisiti e direttive per il dominio di rete blu
1
Il dominio di rete blu può essere segmentato sulla rete.
2
È possibile effettuare una suddivisione in sottodomini di rete ai sensi del numero 1.3
lettera d.
A.3 Requisiti e direttive per le comunicazioni autorizzate
A.3.1 Comunicazione interna
1
La comunicazione interna può essere effettuata direttamente, non soggiace ad alcuna
restrizione derivante da una segmentazione della rete ai sensi del numero A.3 capoverso 1.
A.3.2 Comunicazione esterna
1
La comunicazione esterna non deve essere effettuata direttamente ma deve avvenire
tramite uno o più PEP (ad es. in una PEZ).
2
Si deve garantire che un sistema TIC del dominio di rete blu non possa mantenere
contemporaneamente più comunicazioni esterne con i sistemi TIC di altre zone.
3
I requisiti e le direttive seguenti valgono per le comunicazioni in entrata:
a) È possibile utilizzare soltanto protocolli noti e standardizzati o per i quali esiste un
server proxy inverso affidabile. Per i servizi web si devono utilizzare i protocolli e i
formati di dati SOAP/XML, REST/XML e/o REST/JSON.
b) La comunicazione viene garantita da un server proxy inverso che (i) autentica la
persona che inizia la comunicazione, (ii) protegge il traffico dati e (iii) registra e valuta
tempestivamente i relativi dati secondari. Nel caso dei servizi web è sufficiente
autenticare i processi (consumatori e fornitori di questi servizi) in base a certificati
riconosciuti SSL/TLS e la protezione del traffico dati deve essere effettuata
verificando il contenuto del messaggio17, autenticando e crittografando i dati in
maniera trasparente in base all’HTTPS.
c) Un accesso illimitato alla rete è possibile soltanto da un sistema TIC gestito da
un’unità organizzativa dell’Amministrazione federale.
3
Alle comunicazioni in uscita si applica la direttiva sui web proxy dell’AF [6].
17
Se una crittografia end-to-end tra il consumatore e il fornitore di servizi web è necessaria e se il firewall di
questo servizio non può pertanto verificare direttamente il contenuto dei messaggi, devono essere adottate
misure complementari per garantire che i contenuti dei messaggi siano controllati almeno indirettamente.
15/17Si003 – Sicurezza delle reti nell’Amministrazione federale
Allegato B: Matrice d’accesso per il dominio di rete blu e la
SSZ
Le seguenti tabelle sono riprese dalla versione 4.0 della matrice d’accesso e valgono per
l’autenticazione di persone al dominio di rete blu e alla SSZ (tabella B.1) o per
l’autenticazione di sistemi partner e processi (tabella B.2). Le eccezioni riguardanti le
applicazioni di Governo elettronico di cui al numero 4 capoverso 4 si applicano anche in
questo caso.
Livello di protezione Base (LP0) 1 (LP1) 2 (LP2)
Terminale utente CC CC TE FT CC CC TE TE CC CC TE TE
Metodo di accesso NW RA NW RA NW RA NW RA NW RA NW RA
Hard Crypto Token Sì Sì No Sì Sì Sì No Sì Sì Sì No Sì
Dominio di rete blu
OTP Sì Sì No Sì Sì Sì No Sì Sì Sì No Sì
OTP senza dispositivo No Sì No Sì No Sì No Sì No No No No
Soft Crypto Token No No No No No No No No No No No No
Password o PIN token No No No No No No No No No No No No
Hard Crypto Token Sì18) Sì No Sì Sì18) Sì No Sì Sì18) Sì No Sì
OTP Sì18) Sì No Sì Sì18) Sì No Sì Sì18) Sì18) No Sì
SSZ
OTP senza dispositivo No Sì No Sì No Sì No Sì No No No No
Soft Crypto Token No Sì No Sì No Sì No Sì No No No No
Password o PIN token No Sì No Sì No Sì No Sì No No No No
Tabella B.1: Autenticazione di persone al dominio di rete blu o alla SSZ
Livello di protezione Base (LP0) 1 (LP1) 2 (LP2)
Metodo di accesso NW RA NW RA NW RA
Dominio di rete blu /
Hard Crypto Token No Sì No Sì No Sì
OTP / OTP senza dispositivo Nessuna applicazione pratica
SSZ
Soft Crypto Token No Sì No Sì No Sì19)
Password o PIN token No Sì20) No No No No
Tabella B.2: Autenticazione di sistemi partner e relativi processi
18
L’unico caso è l’amministrazione di sistemi tramite rete Admin-LAN (zona di gestione del FP).
19
Concesso soltanto per l’accesso a Sedex e ad altre applicazioni, attraverso le quali possono essere scambiati
unicamente messaggi standardizzati e/o possono essere seguiti processi definiti.
20
Concesso soltanto per dati telemetrici (apparecchi di misurazione).
16/17Si003 – Sicurezza delle reti nell’Amministrazione federale
17/17Puoi anche leggere
