Cisco 200-301: Sicurezza di Rete e Controllo degli Accessi — Guida allo studio

By Laurynas Brazys · 14 August 2026 · #cisco #200-301 #certification #exam-prep #study-guide

Fa parte della Cisco CCNA 200-301 — Guida allo studio. Esercitati con risposte verificate nel centro esami Cisco, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La sicurezza di rete e il controllo degli accessi garantiscono che solo le entità autorizzate utilizzino le risorse di rete nei modi previsti, proteggendo al contempo dati e servizi da compromissioni o interruzioni. Una progettazione efficace allinea i controlli tecnici con i principi fondamentali di riservatezza, integrità, disponibilità e minimo privilegio. I controlli devono estendersi al piano di gestione (come vengono amministrati i dispositivi), al piano di controllo (come i dispositivi formano adiacenze e scambiano informazioni di routing) e al piano dei dati (come viene inoltrato il traffico degli utenti), con difese stratificate a Layer 2, Layer 3 e superiori. Questa sezione illustra i meccanismi pratici—AAA, ACL, protezioni di Layer 2, VPN, firewall/IPS, hardening e monitoraggio operativo—insieme a logiche di progettazione, modalità di guasto comuni ed esempi di configurazione concisi.

Principi di Sicurezza e Fondamenti del Controllo degli Accessi

Riservatezza: Prevenire la divulgazione non autorizzata. Applicata con crittografia in transito (SSH, IPsec), crittografia a riposo (at-rest) e policy di accesso mirate.
Integrità: Prevenire l’alterazione non autorizzata. Ottenuta tramite controlli crittografici (HMAC, firme digitali), controlli di configurazione e immutabilità dei record di audit.
Disponibilità: Mantenere i servizi raggiungibili nonostante guasti o attacchi. Realizzata con ridondanza, rate-limiting, policing e architetture resilienti che mantengono la connettività continua durante i guasti.
Minimo privilegio: Concedere i diritti minimi necessari, limitati per ruolo, dispositivo, protocollo, tempo e posizione. Implementato tramite il controllo degli accessi basato sui ruoli (RBAC), la segmentazione e l’autorizzazione per singolo comando.

Logiche di progettazione:

Le policy di accesso devono derivare dai ruoli aziendali. L’RBAC sull’infrastruttura (es. network-operator vs. network-admin) riduce il raggio d’impatto di un uso improprio delle credenziali e degli errori operativi.
Separare le mansioni (es. security operations vs. network operations). Applicare tramite gruppi AAA distinti e autorizzazione dei comandi.
Preferire un approccio “nega per impostazione predefinita” (deny-by-default). Permettere esplicitamente i flussi e le sorgenti di gestione previsti, con logging delle eccezioni.

Errori comuni:

Privilegi eccessivi concessi per comodità (es. un generico privilege 15). Questo favorisce il movimento laterale e gli errori irreversibili.
Reti piatte prive di segmentazione. Domini di broadcast e confini di policy non differenziati amplificano gli attacchi (es. ARP spoofing).
Controlli eccessivamente restrittivi senza telemetria. La mancanza di contatori/logging ostacola il troubleshooting e può prolungare le interruzioni di servizio.

AAA e Gestione Sicura dei Dispositivi

Panoramica su AAA:

Authentication (Autenticazione): verifica l’identità. Authorization (Autorizzazione): determina cosa può fare un’identità. Accounting (Tracciamento): registra cosa è stato fatto e quando.
Autenticazione locale: Il dispositivo memorizza utenti e password. Utile per accessi di emergenza (break-glass); non è scalabile e non centralizza le policy.
TACACS+: TCP/49, crittografa l’intero payload, supporta autorizzazioni granulari per singolo comando; preferito per l’amministrazione dei dispositivi.
RADIUS: UDP/1812 (authn/author), UDP/1813 (acct), crittografa solo il campo della password; si integra bene con 802.1X e l’accesso alla rete, ma offre un’autorizzazione meno granulare per la CLI.

Tipica configurazione AAA con TACACS+ e fallback locale: aaa new-model tacacs server TAC1 address ipv4 10.20.20.10 key $uperSecretKey aaa group server tacacs+ TAC-GRP server name TAC1 aaa authentication login default group TAC-GRP local aaa authorization exec default group TAC-GRP local if-authenticated aaa accounting exec default start-stop group TAC-GRP username breakglass privilege 15 secret StrongLocal!Pass

Accesso basato sui ruoli:

Mappare gli attributi TACACS+/RADIUS a livelli di privilegio del dispositivo o a set di comandi. Usare l’autorizzazione per singolo comando per limitare azioni rischiose (es. reload, write, modifiche alle policy-map).
Validare l’RBAC con account di test; assicurarsi che l’account locale di emergenza (break-glass) sia documentato, protetto e monitorato.

Piano di gestione sicuro:

Preferire SSHv2 per la CLI. Disabilitare Telnet e i server non utilizzati. ip domain-name corp.local crypto key generate rsa modulus 2048 ip ssh version 2 line vty 0 4 transport input ssh login authentication default access-class MGMT_VTY in ip access-list standard MGMT_VTY permit 10.10.10.0 0.0.0.255
Limitare la gestione a VLAN/VRF dedicate o fuori banda (out-of-band). Applicare ACL sull’interfaccia SVI o sull’interfaccia fisica di gestione per consentire solo le sorgenti autorizzate.
Control-plane policing (CoPP) per proteggere i protocolli di routing, gestione e controllo da attacchi di tipo flood: class-map match-any CONTROL-PLANE-MGMT match protocol ssh match protocol snmp match protocol ntp policy-map COPP-POLICY class CONTROL-PLANE-MGMT police 32000 conform-action transmit exceed-action drop class class-default police 64000 conform-action transmit exceed-action drop control-plane service-policy input COPP-POLICY Logica e avvertenze: Applicare il police, non un drop generalizzato sulla class-default; una classificazione errata può interrompere le adiacenze di routing o il BFD e causare interruzioni. Iniziare con valori di rate generosi, osservare i contatori e poi restringerli.

Hardening delle password e integrità del dispositivo:

Usare enable secret (con hash) invece di enable password.
Imporre una lunghezza minima e rallentare gli attacchi di login: security passwords min-length 12 login block-for 60 attempts 5 within 60
Preferire i secret per gli utenti locali (PBKDF2/scrypt sulle piattaforme supportate). Comprendere che service password-encryption offusca soltanto le vecchie password di tipo 7.
Secure boot e configurazione sicura: secure boot-image secure boot-config
Proteggere e versionare le configurazioni; considerare l’archiviazione periodica su storage locale e su un repository remoto sicuro. Usare SCP o SFTP per il trasferimento di file; evitare il TFTP in chiaro per i file sensibili.

Operazioni di Sicurezza: Monitoraggio, Logging e Triage degli Incidenti

Log di audit e sincronizzazione temporale:

Sincronizzare gli orologi per l’accuratezza forense:

undefined

Abilitare il logging locale e remoto con la severità appropriata:

undefined

Aumentare la visibilità degli eventi di autenticazione e dell’uso dei comandi con l’accounting AAA:

undefined

Usare il logging ACL sui ‘deny’ con giudizio; log ad alto volume possono causare picchi di CPU. Considerare il campionamento con NetFlow/IPFIX per il baselining del traffico.

Flusso di lavoro per il triage degli incidenti:

Rilevare e definire l’ambito: Usare syslog, trap SNMP e dati di flusso per identificare sorgenti, porte e volumi anomali. Correlare i contatori in ACL, CoPP e interfacce.
Contenere: Applicare temporaneamente ‘deny’ mirati tramite ACL, disattivare le porte switch compromesse o mettere in quarantena le VLAN. In caso di DDoS sul control plane, regolare il policing CoPP e considerare rate-limit upstream o il blackholing.
Sradicare e ripristinare: Rimuovere gli artefatti malevoli, ruotare le credenziali (incluse chiavi e segreti condivisi), riabilitare i servizi in modo incrementale monitorando la situazione.
Post-incidente: Conservare snapshot di log/configurazione, condurre un’analisi della causa radice (root-cause analysis) e codificare i controlli preventivi (es. espandere le protezioni di Livello 2, affinare l’RBAC).

Lacune operative comuni:

L’assenza di NTP porta a timeline inutilizzabili.
Loggare tutto ovunque crea rumore; ottimizzare la severità e i filtri in base al ruolo del dispositivo.
L’assenza di una procedura di ‘break-glass’ testata prolunga le interruzioni quando i server AAA non sono raggiungibili.

Scenario di Problema Pratico

Orion Retail Group deve mettere in sicurezza l’amministrazione dei dispositivi, segmentare il traffico utente-applicazione per IPv4/IPv6, bloccare l’attività DHCP/ARP non autorizzata (‘rogue’) nei negozi, abilitare l’accesso remoto sicuro per il personale e migliorare la visibilità per la risposta agli incidenti, il tutto senza interrompere le operazioni.

Implementare AAA centralizzato con TACACS+ e fallback locale

Configurazione: Predisporre i server TACACS+; definire

undefined

con il gruppo

undefined

, authentication/authorization/accounting; creare un utente locale ‘breakglass’ con privilegio 15.

Motivazione: Le identità centralizzate e l’autorizzazione per singolo comando applicano il principio del privilegio minimo (least privilege), forniscono audit trail delle azioni amministrative e consentono una rapida revoca delle credenziali. Il fallback locale preserva l’accesso durante le interruzioni del servizio AAA.

Migrare l’accesso di gestione a SSH e limitarlo per sorgente

Configurazione: Generare chiavi RSA, forzare

undefined

, disabilitare Telnet, impostare

undefined

con

undefined

; applicare

undefined

in ingresso per consentire solo i jump host del NOC.

Motivazione: Cifrare il traffico di gestione previene l’intercettazione delle credenziali; le ACL di gestione riducono la superficie d’attacco a un insieme piccolo e noto di sorgenti.

Proteggere il control plane con un CoPP conservativo

Configurazione: Creare una class-map per SSH, SNMP, NTP; applicare una policy-map

undefined

che applica il policing al traffico di gestione/controllo noto e un rate-limit alla

undefined

; associarla all’input del control-plane.

Motivazione: Il rate-limiting del traffico del control plane mantiene la disponibilità durante i flood senza bloccare i protocolli essenziali. Partire con rate più permissivi evita un’auto-negazione accidentale del servizio.

Applicare l’integrità di Livello 2 nei negozi

Configurazione: Abilitare il DHCP snooping sulle VLAN di accesso, considerare attendibili (’trust’) solo gli uplink verso la WAN/relay; applicare rate-limit per request/offer. Abilitare il DAI sulle stesse VLAN; aggiungere binding statici per i dispositivi con IP fisso. Abilitare IP Source Guard sulle porte di accesso.
Motivazione: Queste funzionalità bloccano i server DHCP non autorizzati (‘rogue’), l’ARP spoofing e l’impersonificazione di IP al primo hop, prevenendo movimenti laterali e attacchi man-in-the-middle.

Segmentare le applicazioni con ACL precise (IPv4 e IPv6)

Configurazione: Distribuire ACL IPv4 estese sulle interfacce rivolte verso l’accesso per permettere solo i protocolli richiesti (es. HTTPS verso i server applicativi) e negare/loggare tutto il resto. Distribuire ACL IPv6 con permessi espliciti per ICMPv6 per ND/RA/RS e permessi specifici per le applicazioni; applicare con

undefined

Motivazione: Filtri vicini alla sorgente e specifici per protocollo minimizzano il traffico indesiderato e riducono lo spreco di banda; preservare ICMPv6 assicura che la neighbor discovery e il PMTU funzionino in modo affidabile.

Abilitare l’accesso remoto sicuro e la cifratura site-to-site

Configurazione: Costruire tunnel IPsec site-to-site in tunnel mode tra i negozi e i data center usando IKEv2, AES-GCM, PFS e lifetime allineati con le finestre operative. Fornire VPN di accesso remoto basata su SSL/TLS per il personale con split tunneling per ridurre il carico sull’headend, abbinata a controlli di postura dell’endpoint.
Motivazione: Cifrare i percorsi non attendibili protegge la confidenzialità/integrità; lo split tunneling bilancia la sicurezza con le prestazioni se abbinato a controlli sugli endpoint.

Distribuire firewall e IPS sul perimetro e nell’aggregazione del DC

Configurazione: Implementare una policy firewall stateful tra le zone non attendibili, utente e server; posizionare l’IPS inline sui percorsi critici con signature ottimizzate per le applicazioni retail. Assicurare la simmetria del percorso o abilitare la condivisione dello stato.
Motivazione: I firewall applicano policy di zona di alto livello; l’IPS rileva/blocca gli exploit che sfruttano le debolezze di applicazioni e protocolli. Il posizionamento e la messa a punto corretti prevengono falsi positivi e problemi di stato asimmetrico.

Rafforzare l’hardening, il logging e la risposta

Configurazione: Impostare

undefined

, forzare una lunghezza minima della password e il throttling dei login; abilitare

undefined

. Configurare NTP, syslog bufferizzato e remoto con severità informational, e l’accounting dei comandi AAA. Aggiungere istruzioni

undefined

con parsimonia sulle ACL chiave. Testare la procedura di break-glass.

Motivazione: Credenziali robuste e integrità del dispositivo riducono il rischio di compromissione; log sincronizzati e durevoli e l’accounting accelerano il triage. Procedure di ripristino collaudate minimizzano il downtime durante gli incidenti.

Eseguendo questi passaggi in ordine — dall’identità e dal management plane, all’hardening di Livello 2, alla segmentazione e al trasporto cifrato, e infine all’ispezione perimetrale e alla visibilità operativa — Orion ottiene una sicurezza stratificata basata sul principio del privilegio minimo (least-privilege), con controlli misurabili e interruzioni minime.

← Progettazione e Operazioni di LAN Wireless · Tutti i domini · WAN →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →