CompTIA SY0-701: Gestione delle Identità e degli Accessi — Guida allo studio

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Fa parte della CompTIA Security+ SY0-701 — Guida allo studio. Esercitati con risposte verificate nel centro esami CompTIA, oppure fai test cronometrati su ExamRoll.io.

La Gestione delle identità e degli accessi (IAM) è la disciplina che garantisce che i soggetti giusti — utenti, servizi e dispositivi — ottengano l’accesso corretto alle risorse corrette al momento giusto, e solo per il tempo necessario. Si basa su due pilastri concettualmente distinti che vengono spesso, e pericolosamente, confusi: l’autenticazione, che dimostra chi è un soggetto, e l’autorizzazione, che determina cosa quel soggetto autenticato può fare. Un utente che accede a una workstation con un’impronta digitale si è autenticato; se quell’utente possa aprire il database delle buste paga è una questione di autorizzazione. Qualsiasi progetto di controllo che confonda i due favorisce le compromissioni.

Fattori di autenticazione e Autenticazione a più fattori

I fattori di autenticazione sono tradizionalmente raggruppati in cinque categorie: qualcosa che si sa (password, PIN), qualcosa che si possiede (smart card, token hardware, telefoni con app TOTP), qualcosa che si è (impronta digitale, retina, geometria facciale), un luogo in cui ci si trova (geolocalizzazione o contesto basato sulla rete) e qualcosa che si fa (biometria comportamentale come la cadenza di digitazione). L’autenticazione a più fattori (MFA) richiede prove da almeno due categorie diverse. Una password combinata con una domanda di sicurezza non è MFA — entrambi sono “qualcosa che si sa”. Una password combinata con un codice TOTP da Google Authenticator è MFA.

I token hardware esistono in diverse forme. Le chiavi di sicurezza FIDO2/WebAuthn come le YubiKey utilizzano la crittografia asimmetrica: la chiave privata non lascia mai il dispositivo e il server detiene solo una chiave pubblica, il che sconfigge il phishing e il replay. I token HOTP generano password monouso da un contatore; i token TOTP le generano dall’ora corrente utilizzando una costruzione HMAC-SHA1:

TOTP = HMAC-SHA1(shared_secret, floor(current_unix_time / 30))

Le smart card, comunemente schede PIV o CAC in ambienti governativi, memorizzano un certificato X.509 e una chiave privata su un chip resistente alla manomissione. La presentazione della carta, combinata con un PIN, soddisfa due fattori e abilita l’autenticazione basata su certificato a sistemi come Active Directory tramite Kerberos PKINIT.

L’MFA è il singolo controllo più efficace contro il furto di credenziali. Quando gli utenti segnalano accessi da indirizzi IP da cui non provengono, reimpostare le password affronta il sintomo; imporre l’MFA affronta la causa principale perché una password rubata da sola diventa insufficiente.

Single Sign-On e Federazione

Il Single Sign-On (SSO) consente a un utente di autenticarsi una sola volta e accedere a più applicazioni senza reinserire le credenziali. La federazione estende questo concetto oltre i confini organizzativi o di trust: l’identity provider (IdP) di un utente in un dominio garantisce per l’utente a un service provider (SP) in un altro. L’equivoco più comune qui è trattare SAML e OAuth come intercambiabili; risolvono problemi diversi.

SAML 2.0 è un protocollo basato su XML progettato per l’SSO aziendale e le asserzioni di autenticazione. Quando un utente richiede un’applicazione SaaS, l’SP reindirizza il browser all’IdP, che autentica l’utente e restituisce un’asserzione SAML firmata contenente gli attributi di identità. Questo è il meccanismo standard per consentire ai dipendenti di accedere ad applicazioni cloud come Salesforce o Workday utilizzando le credenziali aziendali di Active Directory.

OAuth 2.0 è un framework di autorizzazione, non un protocollo di autenticazione. Concede a un’applicazione di terze parti un accesso delegato a una risorsa per conto dell’utente tramite token di accesso. Consentire a un’applicazione di pubblicare sulla propria bacheca di Twitter è un flusso OAuth. OpenID Connect (OIDC) è un livello di identità costruito su OAuth 2.0 che aggiunge un id_token (un JWT) che fornisce asserzioni di autenticazione — è questo che rende possibile il “Sign in with Google”.

Una trappola critica: SSO e federazione riducono la proliferazione delle credenziali ma non eliminano la necessità dell’MFA. Anzi, concentrano il rischio: una credenziale SSO compromessa ora sblocca ogni applicazione federata. L’MFA deve essere imposta presso l’IdP e gli account privilegiati dovrebbero richiedere un’autenticazione step-up anche dopo l’SSO.

Modelli di controllo degli accessi

Una volta stabilita l’identità, un modello di controllo degli accessi governa le decisioni di autorizzazione. Il Controllo degli accessi discrezionale (DAC) consente ai proprietari delle risorse di impostare i permessi, tipicamente tramite liste di controllo degli accessi (ACL). Il Controllo degli accessi obbligatorio (MAC) applica la policy centralmente in base a etichette e livelli di autorizzazione, comune nei sistemi militari e imposto da framework come SELinux. Il Controllo degli accessi basato sui ruoli (RBAC) assegna i permessi ai ruoli e gli utenti ai ruoli — un ruolo “Analista di fatturazione” comporta un set di permessi definito e gli utenti ereditano i permessi tramite l’appartenenza al ruolo. Il Controllo degli accessi basato su attributi (ABAC) valuta le policy rispetto agli attributi del soggetto, della risorsa, dell’azione e dell’ambiente, abilitando regole come “consentire l’accesso in lettura ai file delle risorse umane solo durante l’orario di lavoro da dispositivi gestiti dall’azienda”.

A sovrintendere ogni modello c’è il principio del privilegio minimo: i soggetti ricevono solo l’accesso minimo necessario per svolgere la loro funzione, e non di più. Complementare è la separazione dei compiti, che impedisce a un singolo individuo di controllare un intero processo sensibile — la persona che richiede un pagamento non dovrebbe anche approvarlo.

I controlli di accesso pratici includono le ACL del file system, le ACL di rete su router e firewall e le restrizioni basate sull’orario che consentono l’accesso solo durante le ore autorizzate. Una voce ACL di Windows che concede l’accesso in sola lettura a una condivisione finanziaria potrebbe essere:

icacls C:\Finance /grant "Domain\Finance-RO:(OI)(CI)R"

Gestione degli Accessi Privilegiati (PAM)

Gli account privilegiati — amministratori di dominio, root, sysadmin di database, account root del cloud, account di servizio — sono i gioielli della corona di qualsiasi ambiente. I sistemi di Privileged Access Management (PAM) come CyberArk, BeyondTrust o HashiCorp Vault impongono controlli su questi account: le credenziali vengono archiviate in un vault e ruotate automaticamente, le sessioni vengono registrate, il checkout richiede una giustificazione e spesso un’approvazione, e le password sono frequentemente monouso o effimere.

L’accesso Just-in-time (JIT) eleva i privilegi solo per la durata di un’attività specifica, eliminando i diritti di amministratore permanenti. Uno sviluppatore che deve eseguire una migrazione del database riceve una credenziale a tempo limitato che scade automaticamente dopo 30 minuti — non esiste un account privilegiato persistente da rubare. Privileged Identity Management (PIM) in Azure AD implementa questo pattern in modo nativo, richiedendo flussi di lavoro di approvazione e una nuova autenticazione MFA prima dell’elevazione dei privilegi.

Gli account di servizio presentano una sfida particolare. Sono spesso dotati di privilegi eccessivi, le loro password vengono ruotate raramente e il loro utilizzo è raramente sottoposto ad audit. I Managed Service Accounts (MSAs) e i Group Managed Service Accounts (gMSAs) in Active Directory automatizzano la rotazione delle password ed eliminano del tutto la necessità per gli esseri umani di conoscere le credenziali degli account di servizio.

Servizi di Directory e Provisioning

Active Directory (AD) rimane l’identity store on-premise dominante. Utenti, computer e gruppi sono organizzati in Organizational Units (OUs), e i Group Policy Objects (GPOs) applicano impostazioni di configurazione e sicurezza in modo gerarchico. I trust di AD estendono l’autenticazione tra domini e foreste. Azure Active Directory (Entra ID) estende questi concetti al cloud, aggiungendo policy di accesso condizionale, punteggi di rischio per la protezione dell’identità e un’integrazione trasparente con migliaia di applicazioni SaaS.

LDAP (Lightweight Directory Access Protocol) è il protocollo sottostante per interrogare i servizi di directory. RADIUS centralizza l’autenticazione per l’accesso alla rete — VPN, Wi-Fi e l’autenticazione cablata 802.1X si autenticano comunemente tramite un server RADIUS supportato da AD. TACACS+ svolge un ruolo simile per l’amministrazione dei dispositivi di rete, con il vantaggio aggiuntivo di separare l’autenticazione, l’autorizzazione e l’accounting in fasi distinte.

Il provisioning e il deprovisioning degli utenti devono essere strettamente legati ai processi delle risorse umane (HR). Il fallimento più persistente nell’ambito IAM è l’account orfano — un ex dipendente il cui account Active Directory rimane attivo per settimane o mesi dopo la sua uscita dall’azienda. Il provisioning automatizzato tramite SCIM (System for Cross-domain Identity Management) o connettori HR-to-AD, combinato con checklist di deprovisioning obbligatorie, colma questa lacuna.

Scenario Pratico: Compromissione di Credenziali tramite un Account Orfano

Il team IT di un’azienda manifatturiera ha scoperto un accesso anomalo fuori orario al proprio sistema ERP da un account di servizio creato per un progetto di integrazione ormai dismesso. L’account aveva diritti di utente di dominio e non era mai stato revisionato durante le verifiche trimestrali degli accessi perché non era associato a un dipendente specifico. Un aggressore, che aveva acquistato le credenziali da un dump del dark web, ha utilizzato l’account per enumerare le condivisioni di file, esfiltrare dati sui prezzi e stabilire una testa di ponte persistente tramite un’attività pianificata. La violazione è stata scoperta solo quando il fornitore dell’ERP ha segnalato pattern anomali nelle chiamate API. La causa principale è stata un processo di deprovisioning fallito: l’integrazione è stata dismessa, ma l’account non è mai stato disabilitato. L’implementazione di un sistema PAM con la scoperta automatizzata di account orfani e cicli di revisione obbligatori avrebbe fatto emergere l’account molto prima che venisse sfruttato.

← Governance · Tutti i domini · Minacce →

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