Cap 2 - Identity and Access Management

Cosa fa

#

Copre autenticazione (4 fattori), gestione credenziali, SSO/LDAP/SAML/OAuth, modelli di autorizzazione (RBAC/DAC/MAC/ABAC), account lifecycle, PAM e indicatori di attivita' malevola. Dominio 4.6 Security+.

TL;DR

#

Identification → Authentication → Authorization → Accounting (AAA) 4 fattori auth: Know / Have / Are / Somewhere you Are MFA = due fattori DIVERSI. Stesso fattore = NON e' MFA. Biometria: iris e retina = piu' forte. FAR / FRR / CER (piu' basso = meglio). SSO = un login, piu' risorse. SAML = SSO per web. OAuth = AUTHORIZATION (non auth!). LDAP = directory. Modelli autorizzazione: RBAC (ruoli) / Rule-BAC (ACL) / DAC (proprietario) / MAC (label) / ABAC (attributi). PAM = just-in-time. Admin = due account separati. Account inattivi = disabilitare subito. Indicators: account lockout, concurrent session, impossible travel, blocked content, resource consumption.

mindmap
  root((Cap 2
Identity &
Access Mgmt))
    [AAA - 4 fasi]
    [I 4 Fattori]
    [MFA]
    [Passwordless]
    [Auth Log Files]
    [Tipi di Account]
    [PAM]
    [Due Account per Admin]
    [Deprovisioning]
    [Time-Based e Audit]
    [Auth Services SSO LDAP SAML OAuth]
    [Authorization Models RBAC DAC MAC ABAC]
    [Auth Indicators]
    [Trappole Esame]

AAA — Identification, Authentication, Authorization, Accounting

#

mindmap
  root((AAA))
    Identification
      Dichiara chi sei
      Username
      Email
    Authentication
      Prova chi sei
      Password
      Fingerprint
      Smart card
    Authorization
      Cosa puoi fare
      Permessi
      ACL
    Accounting
      Tutto registrato
      Audit log
      SIEM

graph LR
    A[Utente] -->|Username| B[Identification
    Dichiara chi e']
    B -->|Password / fingerprint smart card / token| C[Authentication
    Prova chi e']
    C -->|Verifica permessi e ACL| D[Authorization
    Cosa puo' fare]
    D -->|Log di tutto| E[Accounting
    Tutto registrato]

    style B fill:#4a90d9,color:#fff
    style C fill:#e67e22,color:#fff
    style D fill:#27ae60,color:#fff
    style E fill:#8e44ad,color:#fff

Se un attaccante bypassa l'Authentication, Authorization e Accounting diventano inutili — non sai chi ha fatto cosa.

I 4 Fattori di Autenticazione

#

mindmap
  root((4 Fattori
Auth))
    Know
      Password PIN KBA
      Piu debole
      Rubabile
    Have
      Smart card Token YubiKey
      HOTP counter
      TOTP 30-60 sec
    Are
      Biometria
      Iris Retina piu forti
      FAR FRR CER
    Somewhere
      IP address
      MAC address
      Impossible travel

graph TD
    F[Fattori di Autenticazione]
    F --> K["Something you KNOW
    Password, PIN, KBA
    Piu debole — rubabile"]
    F --> H["Something you HAVE
    Smart card, token, security key
    Puo essere perso o clonato"]
    F --> A["Something you ARE
    Biometria
    Non cambiabile se compromessa"]
    F --> S["Somewhere you ARE
    Geolocation, IP, MAC address
    Debole da solo — usato come rinforzo"]

    style K fill:#e74c3c,color:#fff
    style H fill:#e67e22,color:#fff
    style A fill:#27ae60,color:#fff
    style S fill:#3498db,color:#fff

Something You Know

#

Il fattore piu' debole — la conoscenza puo' essere rubata o indovinata.

Password policy:

NIST SP 800-63B "Digital Identity Guidelines" — il documento di riferimento per le password policy moderne. Raccomandazioni principali:

• Hash all passwords (mai in chiaro)
• Require MFA
• Non imporre reset periodico obbligatorio (cambio frequente → password deboli prevedibili)
• Minimo 8 caratteri
• Check contro password comuni e già compromesse
• Permettere tutti i caratteri speciali inclusi gli spazi
• Non riciclare la stessa password su più siti

Passphrase — NIST raccomanda frasi semplici da ricordare invece di stringhe casuali complesse. Esempio: ICanCountTo6 è più sicuro di xK#9q! perché è più lungo e comunque memorizzabile. La lunghezza batte la complessità.

Password Manager (vault): repository cifrato. Master password unica per aprirlo. Backup obbligatorio — device perso = tutte le password perse.

Knowledge-Based Authentication (KBA):

Changing Default Passwords

#

Molti sistemi e dispositivi vengono forniti con password predefinite — cambiarle è la prima azione di sicurezza prima di metterli in rete. Molti router hanno account admin/admin di default: se non si cambia, chiunque conosca i default può prendere il controllo. Cambiare i default include anche rinominare l'account Administrator dove possibile, per non offrire all'attaccante un target noto.

Remember This! Le password di default vanno cambiate su ogni applicazione e dispositivo prima della messa in produzione.

Training Users About Password Behaviors

#

Gli utenti non sempre capiscono il valore della propria password o il danno potenziale se viene compromessa. Le organizzazioni devono formare gli utenti su: creare password forti, non condividerle con colleghi, non riutilizzarle su più sistemi, non scriverle su foglietti. La password 123456 compare costantemente nelle liste delle password più comuni — un po' di training va lontano.

Something You Have

#

Oggetti fisici o digitali che provi di possedere.

HOTP vs TOTP:

graph LR
    subgraph HOTP ["HOTP — HMAC-based One-Time Password"]
        H1[Server
    Condivide secret key] <-->|Shared secret| H2[Token]
        H2 -->|Premi bottone| H3[Counter++]
        H3 -->|HMAC algorithm| H4[OTP generato]
    end

    subgraph TOTP ["TOTP — Time-based One-Time Password"]
        T1[Server
    Condivide secret key] <-->|Shared secret| T2[Token]
        T2 -->|Ora corrente| T3[Timestamp]
        T3 -->|HMAC algorithm| T4[OTP cambia ogni 30-60 sec]
    end

Entrambi open-source. Entrambi usano una shared secret key — nessuna connessione necessaria per sincronizzarsi.

Kerberos usa ticket invece di password — distinzione chiave per l'esame quando chiede di confrontarlo con HOTP/TOTP.

Hook mnemonico: H = HMAC = il motore matematico. Lo stesso algoritmo HMAC-SHA512 e' usato in Bitcoin per derivare le chiavi private dal seed del wallet. Ogni volta che vedi HMAC pensa: segreto → trasformazione deterministica → output verificabile. HOTP: secret+counter → OTP. Bitcoin: seed → chiave privata. H → nessun tempo, nessuna scadenza — come il counter che non ha orologio.

Something You Are — Biometria

#

Il fattore piu' forte. Misura caratteristiche fisiche uniche dell'utente.

Iris e retina = metodi biometrici piu' forti secondo Gibson.

Passivo vs Enrollment — discriminante chiave per l'esame:

Gait e Facial sono gli unici che bypassano il processo di enrollment — identificano senza che l'utente lo sappia o cooperi. Utili per sorveglianza passiva. Retina e' il piu' invasivo — contatto fisico quasi diretto con l'occhio.

Metriche biometriche:

Sensitivita' alta  → FAR scende ↓  FRR sale ↑   (pochi impostori passano, piu' falsi rifiuti)
Sensitivita' bassa → FAR sale ↑    FRR scende ↓  (piu' impostori passano, meno falsi rifiuti)

        FAR \            / FRR
             \          /
              \        /
               \  CER /   ← punto di equilibrio. Piu' e' basso, meglio e'.
                \    /
                 \  /
                  \/

Matrice acceptance/rejection:

Varianti della domanda d'esame — pattern da riconoscere:

Somewhere You Are

#

La posizione come fattore aggiuntivo. Non e' un fattore forte da solo — usato sempre in combinazione.

• IP address → indica paese/regione (non posizione esatta — VPN lo bypassa facilmente)
• MAC address → identifica il computer specifico su Active Directory (solo da quel device)
• Impossible travel time: login da Springfield alle 9:00, login da Roma alle 9:05 → fisicamente impossibile → alert automatico

Two-Factor e Multifactor Authentication

#

mindmap
  root((MFA))
    Regola
      2 fattori categorie DIVERSE
      Stessa categoria = single factor
    Valido
      Have + Know
      Are + Know
      Have + Are
    NON valido
      Are + Are
      Know + Know
      Have + Have
    Esempi ok
      Soft token + password
      Fingerprint + PIN
      Security key + retina

La regola fondamentale: MFA = due fattori di categorie DIVERSE.

graph TD
    Q{Stai usando
    due fattori?} -->|Si| Q2{Appartengono a
    categorie diverse?}
    Q -->|No| NO1[Single Factor Auth
    Non e MFA]
    Q2 -->|Si| YES[MFA / 2FA
    Valido]
    Q2 -->|No stessa categoria| NO2[Single Factor Auth
    Non e MFA anche se usi due cose]

    style YES fill:#27ae60,color:#fff
    style NO1 fill:#e74c3c,color:#fff
    style NO2 fill:#e74c3c,color:#fff

Passwordless Authentication

#

Authentication Log Files

#

mindmap
  root((Auth
Log Files))
    Ogni entry contiene
      What login success failure
      When timestamp
      Where IP hostname
      Who account username
    Scopo
      Audit trail
      Ricostruisce sequenza eventi
      Integrato con SIEM
      Alert automatici

I log tracciano ogni tentativo di login, riuscito o fallito. Ogni entry contiene:

Fondamentali per l'audit trail: ricostruire la sequenza di eventi prima di un incidente. Integrati con SIEM per correlazione e alert automatici.

Managing Accounts — Tipi di Account e Credential Policy

#

mindmap
  root((Tipi
Account))
    End-user
      Least privilege
      Solo ruolo corrente
    Administrator
      Non usare quotidianamente
      Rischio malware
    Service
      Usato da app
      Password lunghe e complesse
    Device
      Gestito da AD
    Third-party
      Temporaneo
      Scadenza definita
    Guest
      Disabilitato di default
    Shared Generic
      VIETATO
      Rompe accounting
      Eccezione kiosk pubblici

Privileged Access Management (PAM)

#

mindmap
  root((PAM))
    Just-in-time
      Privilegi solo quando servono
      Revocati automaticamente
    Password vault
      Admin non vede mai la password
      Auto-rotation
    Temporary accounts
      Si auto-distruggono
    Full logging
      Chi cosa quando
    Obiettivo
      Ridurre finestra esposizione
      Account privilegiato non sempre attivo

PAM implementa controlli stringenti sugli account privilegiati. Il problema che risolve: un admin che usa sempre l'account privilegiato espone quell'account h24. PAM riduce la finestra di esposizione.

graph TD
    A[Admin ha bisogno
    di accesso privilegiato] --> B[Richiesta just-in-time
    al PAM]
    B --> C[PAM verifica e approva]
    C --> D[PAM concede accesso
    temporaneo es 15 minuti]
    D --> E[Admin esegue il task]
    E --> F[Tempo scaduto]
    F --> G[PAM revoca i privilegi
    automaticamente]
    G --> H[PAM registra tutto:
    chi cosa quando]

    style D fill:#27ae60,color:#fff
    style G fill:#e74c3c,color:#fff
    style H fill:#8e44ad,color:#fff

Funzionalita' PAM:

• Just-in-time permissions: privilegi concessi solo quando servono, revocati dopo
• Password vault: gli admin non vedono mai la password dell'account privilegiato — il PAM la gestisce e la ruota
• Temporary accounts: crea account temporanei con privilegi che si auto-distruggono
• Full logging: ogni accesso privilegiato registrato — chi, quando, cosa ha fatto
• Auto-rotation: cambia automaticamente le password degli account privilegiati

Due Account per Admin

#

mindmap
  root((Due Account
Admin))
    Account normale
      Email browser Office
      Lavoro quotidiano
    Account admin
      Solo task amministrativi
    Perche
      Malware infetta sessione normale
      Non ha privilegi admin
      Privilege escalation rilevabile
    Account condivisi
      Rompono IAAA
      Identification impossibile
      Accounting impossibile

Account normale → email, browser, Office, lavoro quotidiano Account admin → SOLO per task amministrativi

Malware infetta sessione normale → non ha privilegi admin Malware deve fare privilege escalation → passaggio extra rilevabile

Riduce l'attack surface: se un admin usa sempre l'account privilegiato per tutto, un trojan che arriva via email ha subito accesso completo al sistema.

Account Condivisi — Perché Rompono IAAA

#

Account condivisi o generici violano tutti e quattro i principi IAAA.

Esempio Gibson: Bart, Maggie e Lisa usano tutti l'account Guest.

Eccezione: un singolo utente temporaneo che usa Guest supporta ancora IAAA — il problema nasce solo quando l'account è condiviso tra più persone.

Exam tip: shared/generic account = vietato. Ogni utente deve avere il proprio account univoco. Gli admin devono avere due account separati (normale + privilegiato) per ridurre il rischio di privilege escalation.

Deprovisioning e Ciclo di Vita degli Account

#

mindmap
  root((Account
Lifecycle))
    Provisioning
      Account creato
      Permessi assegnati
      Least privilege
    Disabilitare
      Terminazione immediata
      Leave of absence
      Mai cancellare subito
    Cancellare
      Solo dopo 60-90 giorni
      Se no dati cifrati persi
    Scadenza automatica
      Contractor con data fine nota
      Account expiration ideale
    Deprovisioning
      Automatizzato con HR
      Non dipendere da notifica manuale

Deprovisioning = processo per disabilitare l'account di un utente quando lascia l'organizzazione. Spesso automatizzato: appena l'HR inattiva il dipendente nel sistema, l'account viene disabilitato.

Provisioning = processo inverso: creazione dell'account e assegnazione dei permessi quando un nuovo dipendente arriva.

graph TD
    A[Nuovo dipendente] --> B[Provisioning
    Account creato + permessi assegnati]
    B --> C[Account attivo
    Least privilege applicato]
    C --> D{Evento}

    D -->|Leave of absence| E[Account DISABILITATO
    temporaneamente]
    E -->|Rientro| C

    D -->|Licenziamento Terminazione| F[Account DISABILITATO
    immediatamente]
    F --> G{60-90 giorni}
    G -->|Nessun bisogno dei dati| H[Account CANCELLATO]
    G -->|Dati cifrati necessari| I[Account mantenuto
    disabilitato]

    style E fill:#e67e22,color:#fff
    style F fill:#e74c3c,color:#fff
    style H fill:#c0392b,color:#fff

Perche' disabilitare e NON cancellare: Cancellare un account distrugge le chiavi crittografiche associate. Qualsiasi file cifrato con quell'account diventa inaccessibile per sempre — anche per l'organizzazione stessa. Disabilitare mantiene l'account (e le chiavi) intatto ma bloccato.

"Disabling the account ensures that data associated with it remains available." — Gibson

Time-Based Logins e Account Audits

#

mindmap
  root((Time e
Audit))
    Time-based logins
      Blocca accesso fuori orario
      Sessioni gia aperte NON tagliate
      Solo blocca nuovi accessi
    Location-based policy
      Blocca per paese o rete
      Geolocation o IP
      Non e time-based
    Account Audit
      Indipendente e periodico
      Least privilege check
      Privilege creep rilevato
      Attestation dai manager
    Privilege creep
      Permessi entrano mai escono
      Cambio ruolo senza rimozione
      Rilevato con audit

Time-Based Logins (time-of-day restrictions): Il sistema blocca l'accesso fuori dagli orari autorizzati — anche con credenziali corrette.

Esempio: l'azienda consente accessi dalle 6:00 alle 20:00 lun-ven. Se qualcuno prova a loggare alle 3:00 di notte nel weekend, il sistema blocca. Maggie puo' fare straordinari solo se il manager la aggiunge a un gruppo con orari estesi.

Location-based policies — bloccano l'accesso da determinate posizioni geografiche o reti. Diverso dai time-based logins: non è "quando" ma "da dove". Esempio: bloccare login da paesi ad alto rischio, o permettere accesso solo dalla rete aziendale o VPN. Usato come quarto fattore (somewhere you are) applicato come policy di accesso. Exam tip: se la domanda menziona geolocation o restrizioni per paese → location-based policy, non time-based login.

Attenzione — le sessioni attive non vengono interrotte: Il time-based login controlla solo l'accesso in entrata, non taglia le sessioni gia' aperte. Se Maggie e' loggata dalle 9:00 e sta lavorando fino alle 21:30, alle 20:00 la sua sessione rimane attiva. Pero' il sistema le impedisce di aprire nuove connessioni di rete (connettersi a un altro server, aprire una VPN, ecc.). Chi era dentro prima dell'orario limite continua a lavorare — chi prova a entrare dopo viene bloccato.

Account Audit: Esame sistematico e indipendente di un sistema, processo o record per determinare se e' conforme ai criteri stabiliti. La parola chiave e' indipendente: lo fa qualcuno che non ha interesse a nascondere problemi. E' programmato e periodico — non si fa perche' si hanno dubbi, si fa anche quando tutto sembra ok.

In pratica: l'admin estrae da Active Directory la lista completa dei permessi di tutti gli utenti e la confronta con la lista HR dei dipendenti attivi. Cerca privilege creep, account di ex-dipendenti ancora attivi, service account con password vecchie, account guest abilitati senza motivo.

Risponde a una domanda sola: ogni account ha solo i permessi che servono per il suo ruolo attuale?

Privilege creep — trappola classica: Lisa lavora in HR per 2 anni. Poi passa alle Vendite. L'admin aggiunge i permessi Sales ma dimentica di rimuovere quelli HR. Lisa ora ha accesso a dati HR + Sales — viola least privilege. Gli audit periodici rilevano e correggono questo accumulo.

Gli audit si fanno almeno una volta l'anno. Alcune organizzazioni li fanno trimestralmente. L'obiettivo e' farli abbastanza spesso da intercettare i problemi prima che diventino incidenti — ma non cosi' spesso da diventare un peso inutile per i security admin. Giornalieri o settimanali sono eccessivi a meno che non siano completamente automatizzati.

Attestation: Processo formale in cui i manager revisionano i permessi di ogni utente del loro team e certificano che quei permessi siano necessari per svolgere il lavoro. Non lo fa l'admin da solo — lo fa il manager che conosce le responsabilita' reali di ogni persona. Se il manager non certifica un permesso, viene revocato.

Due tipi di audit — exam trap:

Permission auditing → risponde a "ha i permessi giusti?" Usage auditing → risponde a "cosa ha fatto con quei permessi?"

Comparing Authentication Services

#

mindmap
  root((Auth
Services))
    SSO
      Un login piu risorse
      Token di sessione
      Kerberos su AD
      TGT + Service Ticket
    LDAP
      Directory protocol
      Query su utenti e gruppi
      Active Directory
    Federation
      Organizzazioni diverse
      IdP + SP + Principal
      Trust reciproca
    SAML
      XML assertion
      SSO web B2B
      IdP emette token
    OAuth
      AUTHORIZATION non auth
      Token scope limitato
      App terze parti
    OIDC
      OAuth + identita
      Login con Google

Obiettivo comune di tutti i protocolli di autenticazione: garantire che le credenziali non viaggino in chiaro sulla rete (cleartext). Se le credenziali sono in cleartext, un attaccante con un protocol analyzer (es. Wireshark) le cattura e le legge direttamente.

Exam tip: quando una domanda chiede perche' usare LDAPS, SAML, o autenticazione cifrata al posto delle versioni base — la risposta e' sempre questa: prevenire la trasmissione di credenziali in cleartext.

SSO — Single Sign-On

#

Un unico login per accedere a piu' risorse senza autenticarsi di nuovo. Il sistema genera un token alla prima autenticazione — quel token viene presentato agli altri sistemi.

Vantaggio: l'utente ricorda una sola password, meno friction. Rischio: password compromessa = attaccante accede a tutto.

Hook mnemonico: "Il passaporto aziendale" — lo mostri una volta all'aeroporto (login), poi entri in tutti i paesi del blocco (risorse aziendali) senza rifarlo ogni volta.

Esempio vita reale — SSO consumer: Fai login su Google una volta. Poi apri Gmail: sei gia’ dentro. Apri YouTube: sei dentro. Apri Drive, Calendar, Maps: sei dentro ovunque, senza reinserire la password. Il token di sessione ottenuto al primo login viene riutilizzato automaticamente dai vari servizi Google.

Esempio vita reale — SSO aziendale: Senza SSO: un utente che lavora su 5 server deve ricordare credenziali diverse per ogni server — e le scrive su un foglietto. Con SSO: fa login una volta sul dominio, il sistema crea un secure token valido per tutta la sessione, e ogni volta che accede a un server il token viene presentato automaticamente al posto delle credenziali.

graph TD
    A[Utente vuole accedere a una risorsa] --> B{Ha gia' un
    SSO token?}

    B -->|NO — prima volta| C[Sistema chiede
    username e password]
    C --> D[SSO verifica le credenziali]
    D --> E[SSO genera un secure token
    valido per tutta la sessione]
    E --> F[Accesso alla risorsa concesso]
    E --> G[(Token memorizzato
    nella sessione)]

    B -->|SI — token gia' presente| H[SSO presenta il token
    alla risorsa automaticamente]
    H --> F

    F --> I[Utente accede a un'altra risorsa]
    I --> B

    style C fill:#e74c3c,color:#fff
    style E fill:#27ae60,color:#fff
    style H fill:#27ae60,color:#fff
    style G fill:#8e44ad,color:#fff

Beneficio di sicurezza: l’utente ricorda una sola password — meno probabilita’ che la scriva su un foglietto.

Rischio di sicurezza: password compromessa = attaccante accede a tutti i sistemi collegati all’SSO. Per questo SSO richiede autenticazione forte — password debole su SSO e’ molto piu’ pericolosa che su un singolo sistema.

Interoperabilita’: SSO funziona come sistema centralizzato di IAAA per tutti i servizi dell’organizzazione — OS, dispositivi, applicazioni, servizi cloud. Tutti si appoggiano all’SSO per identificazione, autenticazione, autorizzazione e accounting.

Chi crea il token — Kerberos

#

In un dominio Windows, il token SSO e’ creato da Active Directory tramite il protocollo Kerberos. Il componente che emette i ticket si chiama KDC — Key Distribution Center.

Kerberos usa due tipi di ticket:

Cosa contiene il token: Il token NON contiene la password in chiaro. Contiene:

• Username e timestamp
• Periodo di validita’
• PAC (Privileged Attribute Certificate): SID dell’utente + gruppi di appartenenza + diritti
• Chiave di sessione cifrata

La password non viaggia mai sulla rete — viene usata solo localmente per derivare la chiave crittografica che decifra la risposta del KDC.

Ogni utente ha il suo token: si’ — il TGT e’ personale, cifrato con le credenziali di quell’utente specifico.

sequenceDiagram
    participant U as Utente
    participant KDC as KDC / Active Directory
    participant R as Risorsa (server)

    U->>KDC: 1. Username + password hashata
    KDC->>KDC: Verifica credenziali
    KDC->>U: 2. TGT (valido ~10 ore)
    Note over U: La password non esce mai dal PC

    U->>KDC: 3. Voglio accedere al server X (presenta TGT)
    KDC->>U: 4. Service Ticket per server X (valido ~1 ora)
    Note over KDC,U: Il Service Ticket include il PAC con i gruppi e i diritti dell’utente

    U->>R: 5. Presenta Service Ticket
    R->>R: Legge il PAC — sa gia’ cosa puo’ fare l’utente
    R->>U: 6. Accesso concesso senza chiedere la password

LDAP — Lightweight Directory Access Protocol

#

Protocollo core dei sistemi di directory. Windows Active Directory usa LDAP come protocollo di query. Centralizza informazioni su utenti, dispositivi, gruppi e risorse. Quando premi login su un dominio Windows, LDAP interroga AD per verificare le credenziali e recuperare i permessi.

Active Directory non e' un protocollo — e' un software (directory service) prodotto da Microsoft che gira su Windows Server. Internamente usa piu' protocolli standard:

graph TD
    AD["ACTIVE DIRECTORY
    software/servizio su Windows Server"]
    AD --> LDAP["LDAP
    memorizza e cerca utenti/gruppi"]
    AD --> KRB["KERBEROS
    autentica gli utenti in modo sicuro"]
    AD --> DNS["DNS
    trova il Domain Controller in rete"]
    AD --> GPO["GPO — Group Policy Object
    distribuisce policy a tutti i PC"]

    style AD fill:#4a90d9,color:#fff
    style LDAP fill:#27ae60,color:#fff
    style KRB fill:#e67e22,color:#fff
    style DNS fill:#8e44ad,color:#fff
    style GPO fill:#c0392b,color:#fff

Samba su Linux implementa gli stessi protocolli — per questo e' compatibile con Windows AD. La differenza e' solo il software, non il protocollo.

Il Domain Controller e' il server fisico (o virtuale) su cui gira Active Directory. E' il cervello del dominio — fa tre cose:

graph TD
    DC["DOMAIN CONTROLLER
    Il server centrale del dominio"]

    DC --> A["AUTHENTICATION
    Verifica le credenziali tramite Kerberos
    Emette il TGT"]
    DC --> B["DATABASE
    Contiene tutti gli utenti, gruppi,
    computer e permessi tramite LDAP"]
    DC --> C["POLICY
    Distribuisce le regole aziendali
    a tutti i PC tramite GPO"]

    style DC fill:#4a90d9,color:#fff
    style A fill:#e67e22,color:#fff
    style B fill:#27ae60,color:#fff
    style C fill:#8e44ad,color:#fff

Nel lab: Ubuntu con Samba e' il Domain Controller. Kali e' il client che gli parla.

Federation e Identity Provider

#

Perche' si chiama Federation?

Federare (dal latino foedus = patto, accordo) significa unirsi sotto regole comuni mantenendo la propria indipendenza. Due organizzazioni diverse si accordano per riconoscere reciprocamente le identita' — senza fondersi e senza condividere i sistemi.

Mario e' uno studente della Sapienza. Microsoft 365 e' un'organizzazione completamente diversa. Non si uniscono — si federano: stringono un patto di fiducia reciproca: "io mi fido della tua identita', tu ti fidi della mia assertion."

Il contrario della federation e' avere un account separato su ogni sistema — Mario dovrebbe creare un account Microsoft separato, uno Coursera, uno Zoom. Con la federation: un solo account Sapienza, accesso ovunque.

sequenceDiagram
    participant M as Mario (Principal)
    participant IdP as IdP - Sapienza
    participant SP as SP - Microsoft 365

    M->>IdP: 1. Login con credenziali Sapienza
    IdP->>IdP: Verifica identita nel proprio AD
    IdP->>SP: 2. Assertion di identita (SAML)
    SP->>M: 3. Accesso concesso senza nuovo account

La federation richiede che le due organizzazioni si accordino sullo standard di identity (es. SAML). Non si uniscono i sistemi — si fidano reciprocamente delle identita'.

Deprovisioning in un sistema federato: Quando Mario si laurea, la Sapienza disabilita il suo account nel proprio AD. In quel momento perde automaticamente l'accesso a tutti i SP federati — Microsoft 365, Coursera, Zoom, biblioteche digitali — in un colpo solo. Nessun admin deve andare a cancellare account su 10 sistemi diversi. Un solo deprovisioning sull'IdP, tutto va via. Questo e' uno dei vantaggi operativi piu' importanti della federation.

SAML — Security Assertion Markup Language

#

SAML (Security Assertion Markup Language) e' un formato dati basato su XML usato per l'SSO sui web browser. Serve a scambiare informazioni di autenticazione e autorizzazione tra organizzazioni diverse.

Espansione da ricordare: Security Assertion — SAML trasporta delle assertion (dichiarazioni firmate) sull'identita' dell'utente da un'organizzazione all'altra.

Caso reale — Universita' e servizi esterni: Sei studente alla Sapienza con account mario.rossi@studenti.uniroma1.it. Con quell'unico account accedi a Microsoft 365 (Teams, Word), Coursera, biblioteche digitali (JSTOR, IEEE), Zoom istituzionale — senza mai creare un account separato. Nessuno di questi servizi conosce la tua password. La Sapienza dice "questo e' Mario, e' uno studente attivo" e loro si fidano. Quando ti laurei e l'universita' disabilita il tuo account, perdi l'accesso a tutti i servizi in un colpo solo — un solo deprovisioning, tutto va via.

sequenceDiagram
    participant M as Mario (Principal)
    participant SP as Service Provider (Microsoft 365)
    participant IdP as Identity Provider (Sapienza)

    M->>SP: Vuole accedere a Teams
    SP->>M: Redirect alla Sapienza
    M->>IdP: Login con credenziali Sapienza
    IdP->>IdP: Verifica nel proprio AD/LDAP
    IdP->>M: Token SAML - XML assertion firmata
    M->>SP: Presenta token SAML
    SP->>M: Accesso concesso - Microsoft non ha mai visto la password

SAML gestisce sia autenticazione che autorizzazione — ma sono separati. Avere il token non significa avere tutti i permessi.

I tre ruoli SAML:

SAML e Authorization — distinzione fondamentale:

SSO autentica — non autorizza. Sono due cose separate.

• Autenticazione = verificare chi sei → "Mario e' uno studente Sapienza valido" ✅
• Autorizzazione = decidere cosa puoi fare → dipende dalle regole del SP

Esempio: Mario si autentica alla Sapienza e accede a Microsoft 365. Entra in Teams — autenticato ✅. Prova ad accedere al pannello di amministrazione di Teams — bloccato ❌. Il token SAML ha confermato la sua identita', ma Microsoft ha le proprie regole di autorizzazione indipendenti.

Il fatto che la Sapienza si fidi di Microsoft non significa che Mario abbia accesso a tutto su Microsoft. La federation non azzera le autorizzazioni del SP.

Il colpo di scena — SAML puo' trasportare anche autorizzazione:

SAML avanzato permette all'IdP di includere attributi di autorizzazione dentro l'assertion. La Sapienza puo' aggiungere nel token: "Mario e' studente, iscritto a Informatica, ha licenza Office 365 Education." Microsoft legge questi attributi e autorizza di conseguenza — senza fare query aggiuntive.

Non e' automatico — dipende da cosa l'IdP decide di includere nell'assertion.

Dove viene verificata la password e in quale database?

Solo nell'IdP (la Sapienza) — nel proprio Active Directory / LDAP. La password non esce mai dal sistema universitario. Microsoft 365 non la vede, non la tocca, non ne ha copia. Riceve solo l'assertion firmata: "Mario e' autenticato, e' uno studente attivo del corso X."

La federation e' bidirezionale? Dipende da come e' configurata la trust tra le organizzazioni.

La trust non e' automatica — le due organizzazioni devono accordarsi esplicitamente. Exam tip: "mutual trust" o "bidirectional trust" = Caso 2. "Trust" senza specifiche = di solito unidirezionale.

Terza opzione — IdP esterno:

Sapienza   ──┐
             ├──→ IdP di terza parte (es. Okta, Azure AD) ──→ assertion
Microsoft  ──┘

Nessuna delle due organizzazioni fa da IdP — entrambe si fidano di un provider esterno come Okta o Azure AD. Mario si autentica una volta sola sull'IdP esterno e accede sia ai sistemi Sapienza che a Microsoft 365. Comune nelle grandi aziende che devono federare decine di organizzazioni senza che nessuna gestisca l'identita' delle altre.

OAuth — ATTENZIONE trappola esame

#

OAuth = Open Authorization.

OAuth e' uno standard aperto (Open) per l'AUTHORIZATION, non per l'authentication.

Exam trap doppia:

• La O = Open — standard aperto, non proprietario
• Auth = Authorization, non Authentication — il nome inganna deliberatamente

sequenceDiagram
    participant U as Utente
    participant S as Spotify
    participant G as Google Calendar

    U->>S: Vuole aggiungere concerti al calendario
    S->>G: Richiesta: accesso al Google Calendar di questo utente
    G->>U: Popup consenso - Google autentica l'utente
    U->>G: Approvo accesso al calendario
    G->>S: Token OAuth (accesso solo Calendar - non email, non Drive)
    S->>G: Aggiunge eventi concerti al Calendar con il token
    Note over S,G: Spotify non ha mai visto la password Google dell'utente

OAuth consente a un servizio di accedere a risorse di un altro servizio per conto dell'utente, senza condividere le credenziali. Il token e' limitato — Spotify accede solo al Calendar, non all'email o a Drive. (scope limitato)

"Login o Continua con Google" su Spotify — cosa sta succedendo davvero:

OAuth da solo autorizza ma non sa chi sei. OIDC aggiunge un ID token con le informazioni di identita'. Il "Continua con Google" li usa entrambi insieme.

Confronto SSO / SAML / OAuth / LDAP:

Authorization Models

#

Concetti base comuni a tutti i modelli:

Il controllo degli accessi determina come il sistema concede ai subject l'autorizzazione sugli object. Parte sempre dall'identificazione e autenticazione accurata del subject — senza sapere chi e' Mario, non puoi decidere a quali object puo' accedere.

mindmap
  root((Authorization
    Models))
    RBAC
      Ruoli e gruppi
      Admin crea ruoli
      Utenti assegnati ai ruoli
      Windows AD groups
      Hierarchy-based
      Job function-based
    Rule-BAC
      Regole in ACL
      Dinamico
      IPS modifica ACL dopo attacco
      Firewall rules
    DAC
      Il proprietario decide
      NTFS Windows
      SID identificatori
      DACL lista permessi
      ACE singola voce
    MAC
      Il sistema decide
      Label sensibilita
      Top Secret Secret Confidential
      Need to know
      Lattice gerarchia
      SELinux Enforcing Permissive Disabled
    ABAC
      Attributi multipli
      Subject Object Action Environment
      SDN cloud
      Piu granulare di RBAC

RBAC — Role-Based Access Control

#

Il principio fondamentale: i permessi si assegnano al ruolo, non all'utente.

L'admin non dice "Mario puo' accedere al server Sales" — dice "il ruolo Sales puo' accedere al server Sales", poi aggiunge Mario al ruolo. Mario eredita tutto. Se Mario cambia reparto, basta toglierlo dal ruolo Sales e aggiungerlo al ruolo HR — i permessi seguono automaticamente, senza toccare i singoli file o risorse.

Modalita':

• Hierarchy-based: ruoli alti includono i permessi dei ruoli inferiori (Administrator > Manager > User)
• Job/function-based: i ruoli rispecchiano le funzioni lavorative dell'organizzazione (Accounting, Sales, IT)

Come funziona in pratica: L'organizzazione ha tre reparti con tre server separati. L'admin crea i ruoli Accounting, Sales, IT — assegna ogni ruolo al server corrispondente — aggiunge gli utenti ai ruoli in base al reparto. Il risultato: ogni utente accede solo al server del proprio reparto, senza configurare permessi per ogni singola persona.

Group-based privileges: gli admin creano security groups, assegnano permessi ai gruppi, aggiungono utenti ai gruppi.

Built-in groups vs Custom groups:

L'ordine corretto dei 3 passi — Gibson lo testa:

1. Crea il gruppo (es. Sales)
2. Aggiungi il gruppo alla risorsa (es. cartella Sales)
3. Assegna i permessi al gruppo sulla risorsa
→ Solo dopo aggiungi gli utenti al gruppo

L'ordine conta: prima esiste il gruppo, poi la risorsa, poi i permessi. Non aggiungi prima gli utenti.

Rimozione = revoca automatica: Quando togli un utente dal gruppo, perde automaticamente tutti i permessi del gruppo. Se invece i permessi fossero assegnati direttamente all'utente (senza gruppi), non ricorderesti mai cosa togliere quando cambia reparto — violazione di least privilege garantita.

RBAC vs LDAP — non fanno la stessa cosa:

Esempio con Mario alla Sapienza:

1. Il PC usa LDAP per chiedere ad AD: "esiste mario.rossi? quali gruppi ha?"
2. AD risponde via LDAP: "si', e' nel gruppo Students e nel gruppo MicrosoftLicensed"
3. RBAC entra in gioco: il gruppo Students ha accesso a Moodle, il gruppo MicrosoftLicensed ha accesso a Teams

LDAP e' il mezzo di trasporto — porta le informazioni. RBAC e' la logica — usa quelle informazioni per decidere i permessi. Senza LDAP non sai chi e' Mario. Senza RBAC non sai cosa puo' fare.

Rule-BAC — Rule-Based Access Control

#

Basato su un insieme di regole approvate in una ACLs (Access Control List). Le regole definiscono cosa e' permesso o negato. Possono essere statiche (create dall'admin, restano finche' non le cambia) o dinamiche (si modificano automaticamente in risposta a eventi).

Tre casi da ricordare:

Exam trap — RBAC vs Rule-BAC: Si somigliano nel nome ma sono diversi. RBAC usa Ruoli (chi sei nell'organizzazione). Rule-BAC usa Regole in una ACL (firewall, IPS). La parola chiave nella domanda e' sempre "rules" o "ACL" per Rule-BAC, "roles" o "groups" per RBAC.

DAC — Discretionary Access Control

#

Il proprietario dell'oggetto (come un file o una cartella) decide chi puo' accedervi. Windows usa DAC tramite il filesystem NTFS (New Technology File System) — il "NT" viene da Windows NT (1993), il progetto Microsoft che introdusse il nuovo kernel. FAT32 e exFAT non supportano permessi per utente — solo NTFS li supporta.

Analogia Linux: DAC su Windows e' lo stesso concetto di chmod e chown su Linux.

NTFS e' piu' granulare di Linux: invece di tre categorie fisse (owner/group/others), puoi definire ACE diverse per ogni singolo utente nella DACL.

Ogni file/cartella ha:

• Un proprietario identificato dal SID (Security Identifier) — equivalente del UID su Linux (S-1-5-21-399187189-223218)
• Una DACL (Discretionary Access Control List) — la lista dei permessi, composta da ACE

Esempio DACL con quattro ACE (Access Control Entry):

• ACE 1: Homer — Full Control
• ACE 2: Marge — Read
• ACE 3: Bart — Modify
• ACE 4: Everyone — Deny

Il sistema usa il SID internamente, non il nome account. Rinominare "Homer" in "Barney" non cambia i permessi — stesso comportamento di Linux, dove rinominare un utente non cambia il suo UID.

Struttura DAC — i tre elementi:

La DACL e' il contenitore — le ACE sono le voci dentro. Ogni file/cartella NTFS ha esattamente una DACL, che puo' contenere zero o piu' ACE.

DAC vs MAC — differenza chiave: Con DAC il proprietario decide — se vuoi dare accesso a un file che possiedi, fai la modifica e l'altro utente ha accesso. Con MAC i permessi sono predefiniti dal sistema e solo l'amministratore puo' cambiarli — il proprietario non ha questo potere.

Permessi NTFS in ordine crescente:

MAC — Mandatory Access Control

#

Il MAC scheme usa label di sicurezza (chiamate anche sensitivity labels) per classificare sia gli utenti (subject) che i dati (object). Quando le label corrispondono, il sistema concede l'accesso. Quando non corrispondono, blocca. Il proprietario non puo' cambiare i permessi — solo l'amministratore puo' farlo, su indicazione del security professional.

Cosa sono le Label:

Nel MAC ogni oggetto (file, cartella, risorsa) e ogni soggetto (utente) riceve una label — un'etichetta di sicurezza assegnata dal sistema. La label ha due componenti:

La label completa e' la combinazione dei due: SECRET / QUANTUM-PHYSICS. Il sistema confronta la label del soggetto con la label dell'oggetto — se entrambi i componenti corrispondono, accesso concesso. Se uno dei due non corrisponde, accesso negato senza eccezioni.

Lattice (reticolo) e Need to Know — con Mario alla Sapienza:

La Sapienza gestisce dati con un sistema MAC. I livelli di classificazione formano il reticolo:

graph TD
    CL["CLASSIFICATO
    Ricerca militare / difesa"]
    RIS["RISERVATO
    Compartimenti: QUANTUM-PHYSICS
    NUCLEAR-SCIENCE / ANAGRAFE"]
    INT["INTERNO
    Materiale didattico
    Comunicazioni facolta"]
    PUB["PUBBLICO
    Sito web / orari / programmi"]

    CL --> RIS --> INT --> PUB

    style CL fill:#e74c3c,color:#fff
    style RIS fill:#e67e22,color:#fff
    style INT fill:#f39c12,color:#fff
    style PUB fill:#27ae60,color:#fff

Mario e' un dottorando in Fisica Quantistica. Il sistema gli assegna la label: RISERVATO / QUANTUM-PHYSICS.

*Clearance = autorizzazione di sicurezza, nulla osta.

Need to Know: avere la clearance giusta non basta — serve anche il compartimento giusto. Mario ha clearance RISERVATO ma non puo' leggere i dati di NUCLEAR-SCIENCE perche' non e' nel suo compartimento. Il professore che supervisiona Mario non puo' dargli accesso — nel MAC il proprietario non decide. Solo l'amministratore puo' farlo, su indicazione del security professional.

Establishing Access — chi fa cosa:

Nel MAC, l'accesso non viene configurato dal proprietario del file — il processo e' formale e separato:

• Il security professional definisce i compartimenti e le label, coordina con enti governativi superiori per upgrade/downgrade di clearance
• L'amministratore implementa tecnicamente — assegna le label sui sistemi seguendo le indicazioni del security professional
• Il proprietario del file non assegna permessi — i permessi sono predefiniti dal sistema

Se un utente ha bisogno di accesso diverso, l'amministratore puo' approvare o negare la richiesta. La modifica richiede spesso approvazioni a piu' livelli — non e' immediata come nel DAC.

Differenza chiave con DAC: nel DAC se vuoi dare accesso a un file che possiedi, lo fai tu direttamente. Nel MAC non puoi — l'accesso e' deciso dal sistema in base alle label, non dalla tua discrezionalita'.

Lattice (reticolo) — la struttura matematica:

Il lattice — in italiano reticolo — e' una struttura che definisce la gerarchia di tutti i livelli e compartimenti e le loro relazioni. La stessa parola usata in fisica per il reticolo cristallino: nodi collegati in una struttura ordinata con relazioni definite. In MAC ogni livello e' un nodo, le connessioni definiscono chi e' sopra e chi e' sotto. Ogni livello sa esattamente chi e' sopra e chi e' sotto. Con i compartimenti il lattice non e' piu' una linea verticale ma una griglia — SECRET/QUANTUM e SECRET/NUCLEAR sono allo stesso livello ma "incomparabili": nessuno dei due domina l'altro.

Il lattice impone due regole fondamentali (modello Bell-LaPadula):

No write down e' la regola piu' importante — esiste per prevenire la fuga di informazioni. Se Mario ha accesso a dati CLASSIFICATI non puo' copiarli in una cartella PUBBLICA, neanche per errore. Il sistema blocca fisicamente la scrittura verso il basso.

CLASSIFICATO  ← puoi leggere da qui in giu' se hai questa clearance
      |
RISERVATO     ← puoi scrivere da qui in su' se sei a questo livello
      |
INTERNO
      |
PUBBLICO

SELinux — MAC su Linux:

SELinux (Security-Enhanced Linux) e' una delle implementazioni MAC piu' diffuse su Linux. E' uno dei pochi sistemi operativi che usa il mandatory access control scheme. In Windows, il controllo degli accessi discrezionale (DAC) e' il modello standard — MAC non e' il default.

ABAC — Attribute-Based Access Control

#

Un sistema ABAC valuta gli attributi di subject, object, action e environment e concede l'accesso quando il sistema trova una corrispondenza con la policy. Gli attributi possono essere qualsiasi cosa — ruolo, stato, orario, posizione, tipo di dispositivo.

I quattro elementi di ogni access request:

graph LR
    S["SUBJECT
    Chi accede
    Attributi: ruolo, gruppo,
    reparto, stato, clearance"] --> P{Policy Engine
    Valuta gli attributi}
    O["OBJECT
    Cosa viene accesso
    Attributi: tipo, classificazione,
    sensibilita', proprieta'"] --> P
    A["ACTION
    Cosa vuole fare
    Leggere, scrivere,
    eseguire, cancellare"] --> P
    E["ENVIRONMENT
    Contesto
    Orario, posizione,
    dispositivo, protocollo"] --> P
    P -->|Match| Y[Accesso Concesso]
    P -->|No match| N[Accesso Negato]

    style Y fill:#27ae60,color:#fff
    style N fill:#e74c3c,color:#fff

I quattro elementi — con Mario alla Sapienza:

La policy ABAC che governa l'accesso ai dati di ricerca alla Sapienza:

SE subject.dottorando = true
AND object.compartimento = subject.dipartimento
AND action = "leggere"
AND environment.rete = "sapienza"
AND environment.orario = "lun-ven 8-20"
ALLORA → accesso concesso

Mario corrisponde → accesso ai dati di Fisica Quantistica ✅ Uno studente triennale (dottorando=false) → accesso negato ❌ Mario da casa fuori rete universitaria → accesso negato ❌ (environment non corrisponde)

Molti SDN usano ABAC. Le policy usano statement in plain language: "Allow logged-on researchers to access research sites via the main network."

ABAC vs MAC — differenza chiave:

• Nel MAC il sistema usa label fisse predefinite dall'admin
• In ABAC il system owner puo' creare policy e assegnare attributi — molto piu' flessibile
• ABAC puo' emulare sia DAC che MAC a seconda di come si configurano le policy

Confronto finale modelli

#

Analyzing Authentication Indicators

#

mindmap
  root((Auth
Indicators))
    Account lockout
      Brute force
      Dictionary attack
    Concurrent session
      Stesso utente piu sistemi
      Account compromesso
    Impossible travel
      Login fisicamente impossibile
      Account compromesso
    Blocked content
      Filtri bloccano accessi inusuali
      Malware verso C2
    Resource consumption
      CPU memoria anomali
      Cryptominer ransomware
    Log anomalies
      Log mancanti o cancellati
      Attaccante copre tracce
    Out-of-cycle logging
      Attivita notturna o weekend
      Accesso non autorizzato

I log di autenticazione rivelano comportamenti anomali. Il SOC li monitora per rilevare account compromessi.

graph TD
    LOG[Log di Autenticazione] --> I1[Account Lockout
    Brute force o dictionary attack]
    LOG --> I2[Concurrent Session Usage
    Stesso utente piu sistemi
    Account compromesso o condiviso]
    LOG --> I3[Impossible Travel Time
    Login fisicamente impossibile
    Account compromesso]
    LOG --> I4[Blocked Content
    Filtri bloccano accessi inusuali
    Malware verso C2]
    LOG --> I5[Resource Consumption
    CPU memoria anomali
    Malware o cryptominer]
    LOG --> I6[Resource Inaccessibility
    Servizi non disponibili
    Malware interferisce]
    LOG --> I7[Log Anomalies
    Log mancanti o volumi anomali
    Attaccante copre tracce]
    LOG --> I8[Out-of-Cycle Logging
    Attivita in orari inusuali
    Accesso notturno non autorizzato]

    style I1 fill:#e74c3c,color:#fff
    style I3 fill:#e74c3c,color:#fff
    style I4 fill:#e67e22,color:#fff
    style I7 fill:#8e44ad,color:#fff

Chapter 2 Topic Review — Gibson

#

Riepilogo ufficiale Gibson — punti chiave per l'esame.

Autenticazione:

• Identification: username, email, biometria-
• Authentication: prova dell'identita' — password, smart card, token
• Authorization: fornisce accesso alle risorse in base all'identita' provata
• Accounting: traccia l'attivita' dell'utente nei log
• 4 fattori: Know (password, PIN, KBA) / Have (smart card, token) / Are (biometria) / Somewhere (posizione)
• I password manager semplificano la gestione delle credenziali — il sistema memorizza e compila automaticamente
• Le push notification sono usate per 2FA — friendly e non disruptive perche' l'utente deve premere un tasto
• Account lockout policy blocca l'account dopo troppi tentativi falliti — difesa anti brute force
• Le password di default vanno cambiate su ogni device e applicazione prima del deployment
• FAR = tasso di falsa accettazione / FRR = tasso di falso rifiuto / CER = punto di equilibrio — CER piu' basso = sistema piu' accurato
• HOTP e TOTP sono standard open-source per OTP. HOTP non scade, TOTP scade dopo 30-60 secondi
• Single-factor: un fattore. Dual-factor (2FA): due fattori. Multi-factor (MFA): due o piu' fattori — piu' forte di qualsiasi autenticazione single-factor

Gestione Account:

• Gli utenti non devono condividere account — gli account condivisi impediscono identification, authorization e accounting individuali
• PAM implementa controlli stringenti sugli account privilegiati — include just-in-time access, password vaulting, ephemeral credentials
• Gli admin devono avere due account separati (normale + privilegiato) per prevenire privilege escalation
• Account disablement policy: gli account inattivi di chi lascia l'organizzazione vanno disabilitati il prima possibile
• Time-of-day restrictions: impediscono login o accesso a risorse di rete fuori dagli orari autorizzati
• Account audit: verifica i permessi assegnati agli utenti

Confronto Authentication Services:

• SSO: un account, accesso a piu' risorse senza riautenticarsi
• SSO puo' usare un federated database — un'identita' su una rete viene trattata come trusted su un'altra
• Kerberos: SSO per reti interne (Active Directory, Unix realm) — usa ticket invece di password. NON usato su Internet.
• SAML: standard XML per SSO su applicazioni web tra organizzazioni diverse — questo e' usato su Internet e in federation
• OAuth: standard aperto per l'autorizzazione — consente login con Google, Facebook, PayPal, Microsoft, Twitter. Usa API calls e token per mostrare che l'accesso e' autorizzato
• RADIUS: AAA (Authentication, Authorization, Accounting) per accesso remoto, reti cablate e wireless — VPN, Wi-Fi aziendale, switch, router. Non e' per applicazioni web.

Confronto Modelli di Autorizzazione:

• Role-BAC: usa ruoli per concedere accesso basato su job functions o tasks. I privilegi sono assegnati ai gruppi (group-based privileges)
• Rule-BAC: basato su ACL con regole approvate. Alcune implementazioni usano regole dinamiche — modificano le ACL dopo aver rilevato un attacco, o concedono permessi aggiuntivi in certe situazioni
• DAC: ogni oggetto ha un proprietario che ha full explicit control. NTFS usa DAC — ogni file ha una DACL che identifica chi puo' accedervi e con quali permessi
• MAC: usa security/sensitivity labels su utenti e dati. Accesso ristretto in base al need to know. Le label riflettono livelli di classificazione e clearance
• ABAC: valuta attributi di subject, object, action e environment e concede accesso quando trova corrispondenza. Comune nei SDN. Alta flessibilita' — puo' applicare policy sia DAC che MAC

Trappole d'Esame — Parole chiave che cambiano la risposta

#

mindmap
  root((Trappole
Esame))
    logs vs verifies
      logs records = Accounting non MFA
      verifies blocks = fattore auth
    Stesso fattore
      Are+Are = single factor
      Know+Know = single factor
    OAuth trappola
      Auth = Authorization NON authentication
      Identita serve OIDC
    Disabilita non cancellare
      Cancellare distrugge chiavi crittografiche
    RBAC vs Rule-BAC
      roles groups = RBAC
      rules ACL = Rule-BAC
    MAC clearance
      Clearance non basta
      Serve anche compartimento
    Deprovisioning timing
      Licenziamento = subito
      Dimissioni = exit interview

Trappola 1 — "logs" vs "verifies" Se la domanda dice che il sistema registra (logs, records, tracks, monitors) qualcosa — non e' un fattore di autenticazione, e' accounting. Se la domanda dice che il sistema verifica o richiede (verifies, requires, must provide, blocks if not) — quello e' un fattore.

Esempio trappola: "L'app registra la posizione GPS dell'utente" → One-factor (solo username+password). Il GPS e' un log, non autentica. Se dicesse "L'app blocca l'accesso se l'utente non e' nella rete aziendale" → Two-factor (know + somewhere).

Dettaglio aggiuntivo dal libro: Something you have = una fonte di informazione in tuo possesso. Il GPS non e' in tuo possesso — e' l'app che lo legge. Un token fisico, uno smartphone, una smart card sono in tuo possesso. Questo e' il secondo motivo per cui il GPS loggato non conta come fattore.

Trappola 2 — stesso fattore ≠ MFA Due fattori della stessa categoria non sono MFA, anche se sembrano "cose diverse". Thumbprint + retinal scan = Are + Are = single factor. Password + PIN = Know + Know = single factor.

Trappola 3 — OAuth si chiama "Auth" ma non autentica "Auth" in OAuth = Authorization, non Authentication. OAuth autorizza un'app ad accedere a risorse — non verifica chi sei. Per l'identita' serve OpenID Connect sopra OAuth.

Trappola 4 — disabilitare non cancellare Al termine di un dipendente: sempre disabilitare, mai cancellare subito. Cancellare distrugge le chiavi crittografiche — i file cifrati diventano inaccessibili per sempre.

Trappola 5 — RBAC vs Rule-BAC Si somigliano nel nome. RBAC = Ruoli (chi sei). Rule-BAC = Regole in ACL (firewall, IPS). La parola chiave nella domanda: "roles/groups" → RBAC. "rules/ACL" → Rule-BAC.

Trappola 6 — clearance non basta nel MAC Avere la clearance giusta non garantisce l'accesso. Serve anche il compartimento giusto (need to know). L'accesso e' dato dall'intersezione: livello giusto AND compartimento giusto.

Trappola 7 — timing del deprovisioning L'account si disabilita quando il rapporto di lavoro termina effettivamente — non quando viene annunciato.

• Licenziamento immediato → disabilita subito, prima che lasci l'edificio
• Dimissioni con preavviso → disabilita all'exit interview (l'ultimo giorno, non il giorno dell'annuncio)

Exit interview = colloquio formale con HR l'ultimo giorno lavorativo — si consegnano badge e laptop, si firmano i documenti di fine rapporto. NON e' il momento in cui il dipendente annuncia che se ne va — quello puo' essere 2 settimane prima. Se Artie annuncia lunedi' e l'ultimo giorno e' venerdi' tra due settimane, l'account va disabilitato venerdi', non lunedi'.

Domande Esplose — Barno's Questions

#

• Q: OAuth autentica o autorizza? A: Autorizza. "Auth" in OAuth = Authorization, NON Authentication. Il nome inganna deliberatamente. SAML fa entrambe, OAuth solo authorization.

• Q: Thumbprint + retinal scan e' 2FA? A: No. Entrambi appartengono a "something you are". Servono due fattori di categorie DIVERSE.

• Q: Disabilitare o cancellare un account al termine? A: Disabilitare. Cancellare un account distrugge le chiavi crittografiche — tutti i file cifrati diventano inaccessibili per sempre.

• Q: Differenza RBAC e Rule-BAC? A: RBAC usa ruoli (chi sei nell'organizzazione). Rule-BAC usa regole in ACL (firewall, IPS). Facile confonderli — RBAC = Role, Rule-BAC = Rule.

• Q: Mario ha clearance RISERVATO ma non puo' leggere un documento RISERVATO di un altro compartimento. Come? A: Need to Know. La clearance da' il livello, ma serve anche il compartimento giusto. MAC usa sia livello sia compartimento — l'accesso e' dato dall'intersezione di entrambi.

• Q: Il sistema registra la posizione GPS dell'utente durante il login. E' 2FA? A: No. "Logs" = accounting, non autenticazione. Per essere un fattore MFA il sistema deve verificare e bloccare l'accesso in base a quella cosa. Se la registra solo, non e' un fattore.

Scenari Reali

#

Scenario 1 — Authentication Indicators + PAM + MFA

Il SOC rileva un alert: login all'account svc-sqlserver alle 02:47 da un IP in Romania (impossible travel — l'ultimo login era dalla sede italiana 10 minuti prima). Il PAM registra che nessun admin ha richiesto just-in-time access. L'attaccante ha rubato le credenziali del service account (something you know — vulnerabile). Con MFA sul service account, il furto della sola password non sarebbe bastato. Il SIEM correla: stesso IP ha anche tentato brute force su altri 3 account → account lockout attivato → alert escalato al tier 2.

Scenario 2 — Deprovisioning mancato + Account Lifecycle

L'audit trimestrale rileva che luca.ferrari@azienda.it e' ancora attivo nel dominio AD con accesso completo ai sistemi HR e Finance. Luca ha lasciato l'azienda 47 giorni fa. Il deprovisioning non e' stato eseguito perche' il manager non ha notificato l'IT prima che Luca lasciasse l'edificio. In quei 47 giorni i log mostrano 3 accessi ai report finanziari dell'ultimo trimestre — tutti dall'IP VPN di Luca. Azione immediata: disabilitare l'account (non cancellare — ci sono file cifrati con le sue chiavi). Lezione: il deprovisioning deve essere automatizzato e legato al sistema HR, non dipendere da una notifica manuale.

Scenario 3 — Privilege Creep + RBAC + Audit

L'audit annuale dei permessi rivela che sara.bianchi ha accesso a: cartella Sales (dal 2022, quando era in Sales), cartella HR (dal 2023, quando e' passata a HR), cartella Finance (dal 2024, aggiunto per un progetto temporaneo mai revocato) e gruppo IT-Admins (nessuno sa perche'). Sara lavora in HR da 18 mesi ma ha accumulato i permessi di 4 reparti diversi — classico privilege creep. L'admin rimuove i 3 gruppi extra, documenta nel ticket. L'audit ha funzionato esattamente come previsto.

Scenario 4 — SSO compromesso + Concurrent Session

Il SIEM genera un alert: marco.russo risulta loggato contemporaneamente da Milano (ufficio) e da Amsterdam (IP residenziale anonimo) — concurrent session usage. L'attaccante ha rubato il token SSO di Marco dopo che Marco aveva cliccato su un link di phishing. Con il token SSO valido, l'attaccante ha accesso a tutti i servizi del dominio — Outlook, SharePoint, il gestionale CRM — senza bisogno della password. Il SOC invalida la sessione SSO di Marco, forza il re-login con MFA, e isola la workstation per analisi. Lezione: SSO amplifica il danno di un token rubato — per questo richiede MFA forte.

Scenario 5 — Deprovisioning Federato + SAML

Mario si laurea alla Sapienza il 15 marzo. L'HR della Sapienza disabilita il suo account nel proprio AD il giorno stesso. Alle 09:47 del 16 marzo Mario tenta di accedere a Microsoft Teams con le sue credenziali universitarie. Il token SAML non viene emesso — l'IdP (Sapienza) rifiuta l'autenticazione perche' l'account e' disabilitato. Accesso negato su Microsoft 365, Coursera, Zoom e tutte le biblioteche digitali simultaneamente, senza che nessun admin abbia toccato quei sistemi. Questo e' il vantaggio operativo della federation: un solo deprovisioning sull'IdP, effetto su tutti i Service Provider federati.

Scenario 6 — Violazione MAC + Need to Know

Mario (dottorando in Fisica Quantistica, label RISERVATO/QUANTUM-PHYSICS) tenta di aprire un dataset del gruppo di Scienze Nucleari condiviso su un server universitario. Il sistema MAC confronta le label: object = RISERVATO/NUCLEAR-SCIENCE, subject = RISERVATO/QUANTUM-PHYSICS — compartimento non corrisponde → accesso negato e tentativo loggato. Mario chiede al suo professore di dargli accesso "temporaneo". Il professore non puo' — nel MAC il proprietario non ha discrezionalita'. La richiesta deve passare per il security professional della Sapienza che valuta il need to know. Il processo richiede 5 giorni lavorativi. Nel frattempo il tentativo di accesso negato e' gia' nel log per l'audit.

Risorse

#

• Gibson SY0-701 Study Guide — Chapter 2 completo (p. 107-200 circa)

Collegato a

#

• iam — hub principale di questo capitolo
• cap-01-security-fundamentals — AAA introdotto in Cap 1, approfondito qui
• indice-gibson-messer-burning-Ice — indice completo del libro con mappa Gibson-BurningIceTech
• pre-assessment-risultati — Q4 (MFA), Q11 (OAuth/SAML), Q12 (ABAC) collegati a questo cap