Collegamento
Contenuto
Criteri di implementazione del servizio per le PA
ciao,
il paragrafo su IPv6 e’ tecnicamente e concettualmente sbagliato.
innanzitutto il richiamo ai Site-local Addresses e’ deprecato, quanto ai Link-local Addresses nulla hanno a che fare con ARP (che appartiene al campo semantico di IPv4).
lasciamo fare ai link local address il loro lavoro che non e’ quello di essere instradati su Internet, ma quello di connettersi agli host appartenenti allo stesso dominio di broadcast.
in altre parole non e’ corretto traslare l’architettura IPv4 nel mondo IPv6, sarebbe un fallimento, come a esempio il NAT.
infine, incoraggiamo l’adozione di IPv6.
il testo consigliato e’ questo:
#######################
L'uso dello spazio di indirizzamento IPv6, in uno scenario cosiddetto
dual-stack (cioè con la compresenza di IPv4 e IPv6), è auspicabile
nell'erogazione del servizio Wi-Fi.
Il protocollo IPv6 potrà funzionare soltanto se supportato dai Provider
dell'infrastruttura, dal dispositivo dell'utente, dai sistemi operativi
o dalle applicazioni presenti sui dispositivi dell'utente.
A ciascuna rete Wi-Fi è consigliabile assegnare una rete /64 IPv6 di tipo
global unicast, attinta da una /48 allocata dal Provider, con
meccanismi di assegnazione dinamica degli indirizzi come SLAAC
(Stateless autoconfiguration) o DHCPv6.
È necessario anche per IPv6 l'uso di sistemi di packet filtering configurati
in modo tale da garantire la sicurezza dei dispositivi degli utenti che
fruiscono dell'infrastruttura Wi-Fi.
Nell'uso di IPv6 è consigliabile, infine, evitare meccanismi di NAT o di
protocolli di transizione come 6to4 o 6rd così da mantenere semplice e
lineare la configurazione e, al contempo, sfruttare i vantaggi del protocollo.
#######################
ciao
antonio
1 Mi Piace
ciao,
il paragrafo sulle misure minime di sicurezza riporta alcune funzionalita’ che, cosi’ come espresse, sono difficilmente applicabili a un servizio di connettivita’ senza fili a Internet rivolto al pubblico.
mi riferisco all’antivirus “per la protezione a livello centrale, per evitare compromissioni da malware provenienti dai dispositivi mobili”.
cioe’, occorre proteggere Internet dai dispositivi mobili?
oppure occorre evitare che l’utente infetto possa contagiare gli altri utenti?
il primo caso sarebbe fantasioso.
nel secondo caso non occorrerebbe un antivirus centrale, ma il semplice client isolation abbinato a un packet filtering.
e ancora: Data Loss Prevention, per la protezione dei dati e per evitare perdite di informazioni aziendali.
se le reti devono essere segregate (come precedentemente stabilito), quale sarebbe l’ulteriore misura minima da implementare per evitare una perdita di dati eventualmente provocata dagli utenti della rete Wi-Fi?
infine: Policy di web-filtering, per l’utilizzo dei soli protocolli sicuri per l’accesso al servizio e la limitazione ai soli siti web e servizi consentiti.
quali sarebbero i “soli” servizi consentiti fruibili attraverso i “soli” protocolli sicuri?
se da un lato e’ possibile individuare un insieme di siti web inibiti dal nostro ordinamento (AAMS, CNCPO, AGCOM, LEA), e di conseguenza lasciare la navigazione libera verso tutte le altre risorse, dall’altro e’ improduttivo introdurre la nozione di “servizi consentiti”, per di piu’ secondo l’uso di TLS (1.3 compreso o no?).
ciao
antonio
3 Mi Piace
Per la mia esperienza tutti i principali dispositivi utente supportano già IPv6 Comparison of IPv6 support in operating systems - Wikipedia
possiamo evitare di accennare a questo requisito.
Per quanto riguarda i meccanismi di NAT, mi trovo quasi completamente d’accordo se non per NAT64.
L’uso di NAT64, al contrario di altri meccanismi di NAT, semplifica la configurazione della rete in ambienti di una certa dimensione evitando di configurare security policy doppie per entrambi i protocolli del dual stack.
Confermo l’inesistenza di ARP su IPv6 e l’errore concettuale di nattare indirizzi link local che hanno tutt’altro scopo.
1 Mi Piace
ciao,
NAT64 necessita di DNS64 ed e’ documentato che il loro uso provoca alcuni problemi:
- innanzitutto DNS64 modifica le risposte DNS e dunque potenzialmente compromette il DNSSEC;
- proprio la necessita’ di DNS64 provoca difficolta’ a NAT64 che non funziona quando vengono usate API con indirizzi letterali o non adatti a IPv6;
- il solo NAT64 non da’ soluzioni nel caso di client esclusivamente IPv4 connesso a un provider che eroga accesso esclusivamente in IPv6.
Esistono soluzioni e workaround, ma non di semplice attuazione.
Per questi motivi, in un documento di indirizzo, e’ necessario raccomandare di evitare il piu’ possibile meccanismi di transizione diversi dal dual-stack.
Rimane sempre valida la scelta autonoma di quelle PA che, in possesso delle adeguate competenze, decida di operare in modo difforme.
ciao
antonio
1 Mi Piace
ciao,
come vedi non e’ un requisito, ma piuttosto un disclaimer diffuso e usato a esempio anche da google wifi.
ciao
antonio
Potete per favore accettare le pull request di @Antonio-Prado oppure scartarle, ma almeno si lavora su una base condivisa? grazie
ciao,
in merito a “Requisiti del servizio per le Amministrazioni collegate su SPC”, ci sono delle imprecisioni:
Il Capitolato di gara Consip, per la Connettività, ha definito Classi di Servizio e Ambiti atti all” identificazione e separazione dei traffici pregiati e diretti o verso Internet, Intranet e Infranet.
Il testo non deve contenere l’ambito Internet che, per definizione stessa del capitolato, e’ best effort e non soggetta a particolari CoS. Dunque suggerisco:
Il capitolato di gara Consip per la connettività ha definito Classi di
Servizio e Ambiti atti all'identificazione e separazione dei traffici
pregiati e diretti verso intranet e infranet.
ciao
antonio
Organizzazione e ruoli del Servizio
Il Service Provider
Resource provider
User
Riguardo alla descrizione dei compiti del service provider, si richiede di integrare la seguente parte:
“Il Service Provider gestisce le policy di accesso per la connessione al servizio e per la generazione delle credenziali, necessarie agli utenti, per poter accedere alla rete”
con:
“Il Service Provider gestisce le policy di accesso sia per la connessione al servizio che per la generazione delle credenziali (nel caso di presenza di operatore di telecomunicazione nella gestione del servizio wi-fi) , necessarie agli utenti, per poter accedere alla rete”;
in quanto non coerente con l’art. 10 del “Decreto del Fare” DL n.69 del 2013
Il modello dei ruoli descritti non può essere restrittivo ma di mera indicazione generica (flessibile) in quanto per le relative caratteristiche che contraddistinguono i ruoli, le loro combinazioni sono molteplici.
2 Mi Piace
Architettura del servizio per le Reti della PA
L’Ente Locale (Il Comune…), in quanto provider del servizio wi-fi, non solo non è soggetto alla normativa richiamata, che riguarda solamente gli operatori di telecomunicazioni, ma deve ottemperare a quanto disposto dall’art. 10 del cit. “Decreto del Fare” DL n.69 del 2013, ovverosia che “ L’offerta di accesso alla rete internet al pubblico tramite tecnologia WIFI non richiede l’identificazione personale degli utilizzatori. Quando l’offerta di accesso non costituisce l’attività commerciale prevalente del gestore del servizio, non trovano applicazione l’[articolo 25 del codice delle comunicazioni elettroniche, di cui al decreto legislativo 1º agosto 2003, n. 259], e successive modificazioni, e l’articolo 7 del decreto-legge 27 luglio 2005, n. 144, convertito, con modificazioni, dalla legge 31 luglio 2005, n. 155, e successive modificazioni.”
L’attività prevalente di un Comune non è ovviamente l’offerta di accesso. Si ritiene fonte di potenziale confusione ogni ulteriore considerazione volta a introdurre surrettiziamente l’identificazione degli utenti del wi-fi (oltre che onerosa economicamente) e lesivo del diritto di un’amministrazione di offrire un servizio efficiente e ciò particolarmente laddove essa abbia adottato tutte le misure volte a garantire la protezione dei dati, rendendoli sicuri da intrusioni esterne o interne alla rete, oltre che a controllare il servizio e a impedire che atti illeciti possano essere commessi.
Quindi nel documento deve essere inclusa anche la possibilità della non identificazione ”personale degli utilizzatori” se i provider infrastrutturali non rientrano tra gli operatori di telecomunicazione.
4 Mi Piace
Access Point - AP
• Essere conformi agli standard IEEE 802.11a, 802.11b, 802.11g, 802.11n. Quest’ultimo standard deve essere
supportato sia nella banda 2.4 GHz che 5 GHz.
La proposta è quella per cui la conformità degli Access Point sia nella banda 2.4 GHz che 5GHz deve essere obbligatoria nella fase di aggiornamento o installazione di nuovi AP e non per quelli già installati, in quanto l’impatto economico potrebbe non essere sostenibile dalle Amministrazioni Pubbliche.
Inoltre ritengo che l’evoluzione normativa possa rendere tali vincoli rapidamente obsoleti.
1 Mi Piace
ciao,
non so per quella normativa, ma di sicuro quella tecnologica.
infatti, al momento non sono inclusi nell’elenco degli standard assai diffusi come 802.11ac (wave 1 e wave 2) o uno standard in fase di certificazione come 802.11ax.
ciao
antonio
Sottoscriviamo quanto detto da LorenzoTomassoli
Architettura del servizio per le Reti della PA
L’introduzione di una identificazione obbligatoria ridurrebbe significativamente le attività di promozione e sviluppo del wifi gratuito anche perchè notevolmente onerosa per l’ente.
completamente d’accordo con Tomassoli.
Presso il comune di Bologna abbiamo da anni la rete completamente aperta. Ciò la rende estremamente comoda, fruibile, efficace ed apprezzata. L’obbligo di autenticazione ci riporterebbe indietro di 10 anni creando enormi carichi di lavoro per le PA e rendendo la rete più complessa da utilizzare e meno appetibile per l’utente.
Il gran numero di reti oggi utilizzabili tramite autenticazioni facilmente aggirabili (vedi autenticazione via social network di bar, hotel, ristoranti etc) rendono già l’accesso ad internet incontrollato a livello di identità. Obbligare le PA a gestire la registrazione e l’autenticazione utente ritengo sarebbe quindi abbastanza inutile ai fini della sicurezza dell’utilizzo di internet in Italia.
Matteo Melotti
Rispetto al [Par. 4] chiedo di specificare se le linee guida poste in consultazione sono applicabili anche ad Amministrazioni che non utilizzano connettività di tipo SPC in quanto non è chiaro nel testo proposto. Anzi, sembra che la connettività SPC sia un prerequisito.
Chiedo questo perché molte reti WiFi pubbliche regionali non sono basate esclusivamente su SPC che può essere una possibilità, non un obbligo a mio avviso (fatti salvi ovviamente i principi di sicurezza e qualità del servizio).
Rispetto al Paragrafo Misure minime di sicurezza non si comprende la necessità di un sistema di Data Loss Prevention, se le reti di accesso per il wifi pubblico sono separate e segregate. Il DLP necessita di agent a bordo dei client e, oltre a non essere applicabile nello scenario previsto, non sarebbe neanche attuabile su utenze ospiti (non potendo installare agent sui loro client). Si ritiene invece più opportuno che l’erogatore del servizio disponga di un sistema di “intrusion detection and prevention” in grado di monitorare costantemente la rete per verificare e bloccare tentativi di intrusione fraudolenta.
Si ritiene invece utile adottare politiche di URL Filtering condivise tra tutte le Amministrazioni che intendono erogare il servizio per uniformare l’esperienza di accesso dell’utente; si precisa però che non è detto che tutte le Amministrazioni siano già pronte per l’adozione di tali meccanismi per cui l’adozione dovrà essere graduale.
Ritengo utile proporre di adottare politiche condivise in caso di infringement (incidenti di sicurezza, violazioni di copyright, ecc.) relativamente alla gestione degli utenti coinvolti per garantire l’intera federazione.
Rispetto al 4.2.5 , la necessità che tutti gli Access Point siano collegati alla rete cablata non può trovare applicazione in alcune zone del territorio; si richiede pertanto che alcuni vincoli possano essere “rilassati” pur mantenendo salvi i requisiti di sicurezza
Anche per me si sta facendo troppa confusione fra fornire connettività e fare una rete aziendale.
Se si pensa di dare connettività, allora si faccia come i gestori telefonici, che non forniscono (di base) filtraggi, antivirus, isolamento dei client, ma semplicemente rete. (sono consapevole che esistono livelli di filtraggio vari, ma mi sto mantenendo sul generale…)
Diverso è il wifi usato per gli uffici, dove è dovere del gestore proteggere le proprie macchine.
Obbligare a qualunque tipo di filtraggio, firewall, protezione sarebbe inoltre una responsabilità inattuabile verso le pubbliche amministrazione, in quanto le potrebbe esporre a dover rispondere di danni causati dal cattivo funzionamento degli apparati. Sarebbe un po’ come pretendere che le strade avessero delle protezioni per evitare che le auto si possano scontrare fra loro.
1 Mi Piace
in ogni caso “NO CAPTIVE PORTAL” che ha dei problemi di sicurezza insormontabili e non va usato se non come estrema ratio per una autenticazione iniziale.
1 Mi Piace
Buongiorno
sono d’accordo con quanto espone Tamassoli.
Siamo passati da una rete wi-fi con richiesta credenziali ad una senza identificazione personale nel 2016. L’operazione è stata fatta su indirizzo dell’Amministrazione facendo riferimento a quanto disposto dall’art. 10 del cit. “Decreto del Fare” DL n.69 del 2013. Il passaggio è stato ampiamente apprezzato dall’utenza che lamentava la complessità di registrazione della precedente
Saluti