Logo NEXSYS menu
Cybersecurity
Corso Cybersecurity Specialist
Corso Blue Team
Corso Ethical Hacking
Corso Incident Responder
Corso Secure Coding
Sistemi & Cloud
Corso Sistemista e Networking
Corso Microsoft 365 Administration
Corso Windows Server Administration
Corso AZ-104 Azure Administrator
Corso Active Directory
Data, AI & Programmazione
Corso Programmazione C#
Corso ASP.NET
Corso React
Corso Machine Learning
Corso Power BI PL-300
Digital Skills & Trends
Corso Microsoft 365 per utenti
Corso Security Awareness
Corso NIS2
Corso AI per aziende
Corso Microsoft 365 Copilot
Modalità & extra
Calendario
Catalogo Pdf
Percorsi Microsoft
Corsi finanziati
Open Badge digitali
Tutti i corsi di Cybersecurity
Tutti i corsi di Sistemi & Cloud
Tutti i corsi di Data & Programmazione
Tutti i corsi di Digital Skills & Trends

Cybersecurity
Consulenza Cybersecurity
Penetration Test
Assessment AD
SOC As a Service
Data Protection DPaaS
Microsoft & Cloud
Soluzioni Modern Workplace
Migrazione Microsoft 365
Microsoft 365 Security Assessment
Consulenza Cloud
Cloud Backup & Recovery
Infrastruttura & Sistemi
Network Security
Firewall aziendali
DNS Security
Endpoint Management (UEM)
Secure Access Service Edge (SASE)
Manifatturiero & Industria 4.0
Servizi, Logistica & GDO
Sanità & Pharma
Pubblica Amministrazione
Studi Professionali

Progettiamo la tua soluzione su misura →

La nostra identità
Certificazioni & Partner
Portfolio clienti
ISO 9001

Nexsys Srl è certificata
ISO 9001:2015

Microsoft Solutions Partner

Siamo Microsoft Solution Partner per il Modern Work

APPROFONDIMENTI E NEWS

Hacker: un po’ di chiarezza sui tipi

Il termine hacker viene spesso usato in modo generico per indicare chi viola sistemi informatici, ma nel mondo della cybersecurity esistono categorie molto diverse tra loro. Un conto è un attaccante criminale che sfrutta vulnerabilità per rubare dati; un altro è un ethical hacker che opera con autorizzazione per individuare falle di sicurezza e aiutare le aziende a correggerle.

Capire la differenza tra white hat, black hat, grey hat, script kiddies e altri profili è utile per interpretare correttamente i rischi cyber, le attività di penetration test e i percorsi di formazione legati alla sicurezza informatica.

Vuoi diventare ethical hacker o formare il tuo team cybersecurity?

Nexsys eroga corsi pratici su ethical hacking, cybersecurity, penetration test, Active Directory security e incident response per aziende e professionisti IT.

Scopri il corso Ethical Hacker

Le tipologie principali

White hat hackers

Conosciuti anche come "ethical hackers", sono esperti di sicurezza informatica che effettuano test sul sistema per individuarne le vulnerabilità. Solitamente lavorano per il governo o per associazioni, con lo scopo di rafforzare la sicurezza di un sistema e proteggerlo dagli attacchi. Se vuoi approfondire l'argomento, abbiamo scritto due guide approfondite sulla figura dell'hacker etico e su come diventare un hacker white hat.

I white hat sono alla base delle attività di penetration test e dei percorsi di formazione ethical hacking.

Hacker etico: cosa fa e perché è importante per le aziende

L’hacker etico, o ethical hacker, utilizza tecniche simili a quelle degli attaccanti reali, ma opera con autorizzazione e con l’obiettivo di migliorare la sicurezza. Le sue attività possono includere vulnerability assessment, penetration test, analisi delle configurazioni, verifica dei privilegi, test su applicazioni web, infrastrutture cloud, Active Directory e servizi esposti su Internet.

Per un’azienda, il valore dell’ethical hacking non è “bucare un sistema”, ma identificare in modo controllato le vulnerabilità che potrebbero essere sfruttate da un attaccante reale e trasformarle in un piano di remediation.

Chi vuole sviluppare queste competenze può seguire un percorso di corso Ethical Hacker, integrandolo con competenze su incident response, Active Directory security, strumenti offensivi e metodologie di penetration test.

kevin-mitnick

Black hat hackers

La controparte dei white hat hackers, conosciuti anche come "crackers". Sono le persone dietro i cosiddetti "cybercrimes". Ricercano le vulnerabilità nei sistemi (sia di un singolo che di un'organizzazione) per ottenere informazioni sensibili e utilizzarle a proprio vantaggio.

Grey hat hackers

I grey hat si posizionano tra le prime due categorie. Essi non utilizzano le informazioni ottenute per un ritorno personale, ma le loro intenzioni potrebbero essere sia buone che cattive. Quel che è certo è che i loro tentativi di infiltrarsi in un sistema non sono autorizzati da un'organizzazione. Un hacker che individua una falla in un sistema governativo, ad esempio, e la rende nota al grande pubblico, non è considerato un black hat finché non utilizza le informazioni per un vantaggio personale. Al contrario, se fornisse la sua conoscenza ai proprietari del sistema violato, non potrebbe essere considerato un white hat in quanto ha agito senza autorizzazione.

Nation sponsored hackers

Questa tipologia comprende tutti quegli esperti di sicurezza che sono stati assunti dal governo con lo scopo di penetrare nei sistemi di altri stati e ottenere informazioni riservate della nazione vittima. Questi hacker hanno a disposizione gli strumenti più avanzati per perpetrare gli attacchi.

Le minacce avanzate richiedono capacità di monitoraggio, rilevamento e risposta. In questi scenari diventano centrali servizi come SOC as a Service, Incident Response Plan e formazione Incident Responder.

Le tecniche usate da attaccanti criminali devono essere analizzate all’interno di un percorso di consulenza cybersecurity e gestione del rischio.

Affascinato dal mondo hacker? Fanne una professione.
Il corso Ethical Hacker su standard CEH ti insegna le tecniche reali di attacco e difesa, con lab pratici.
maxresdefault

Altre sfumature di hackers

Script kiddies

Con questo termine ci si riferisce ad hacker "amatoriali" ai quali non interessa possedere troppe conoscenze informatiche. Generalmente utilizzano script già scritti o tool scaricabili per puro divertimento personale. Non sono interessati ad imparare davvero come si crea e dirige un attacco, e neanche alla qualità di ciò che fanno.

Green hat hackers

Simili agli script kiddies per il livello di conoscenza, ma con un'importante differenza: i green hat sono vogliosi di imparare. Frequentano forum e siti, fanno domande, si documentano per imparare il più possibile e migliorare i propri attacchi.

Anche attacchi semplici, se automatizzati, possono creare impatti significativi. Per questo le aziende dovrebbero investire in cybersecurity awareness e formazione di base per gli utenti.

hackaday

Blue hat hackers

Questa categoria comprende tutti gli script kiddies che perpetrano degli attacchi con l'intenzione di vendicarsi di qualcuno. Anch'essi non hanno interesse nell'imparare, e fanno utilizzo di attacchi semplici con il solo scopo di causare un danno a una persona specifica. I tipici attacchi che utilizzano sono i DDoS.

Red hat hackers

I red hat sono per un certo verso simili ai white hat. Il loro scopo è lo stesso: fermare gli attacchi dei black hat. La differenza però è significativa: mentre i cappelli bianchi si occupano di contrastare e fermare l'attacco, i red hat cercano di annientare totalmente il cracker, lanciando degli attacchi a loro volta, più o meno aggressivi, per distruggere il sistema dell'attaccante.

Tipi di Hacker: le tipologie principali

Tipo di hackerObiettivoAutorizzazioneRilevanza per le aziende
White hatIndividuare vulnerabilità e migliorare la sicurezzaPenetration test, vulnerability assessment, ethical hacking
Black hatRubare dati, compromettere sistemi o ottenere vantaggi illecitiNoMinaccia cyber da prevenire e rilevare
Grey hatIndividuare falle senza autorizzazione esplicitaNo o parzialeRischio legale e operativo
Script kiddiesUsare tool già pronti senza competenza avanzataNoRischio frequente per sistemi esposti e mal configurati
Nation sponsoredSpionaggio, sabotaggio, intelligence o attacchi miratiDipende dal contesto stataleMinaccia avanzata per settori critici

Come difendersi dagli attacchi hacker

La difesa dagli attacchi hacker richiede un approccio multilivello. Non basta installare un antivirus o un firewall: servono processi, configurazioni corrette, monitoraggio, formazione degli utenti e verifiche tecniche periodiche.

Vuoi sviluppare competenze pratiche di ethical hacking?

Nexsys eroga corsi cybersecurity per aziende e professionisti IT, con percorsi su ethical hacking, penetration test, Active Directory security, incident response e sicurezza offensiva.

Scopri il corso Ethical Hacker

Servizi di Penetration Test

FAQ sui tipi di hacker

Che differenza c’è tra hacker e cracker?

Nel linguaggio comune hacker viene spesso usato per indicare un attaccante informatico. In senso più preciso, il cracker è chi viola sistemi con finalità illecite, mentre un hacker può anche operare con finalità etiche o di ricerca.

Che cosa fa un ethical hacker?

Un ethical hacker testa sistemi, applicazioni e infrastrutture con autorizzazione, usando tecniche offensive per individuare vulnerabilità e aiutare l’azienda a correggerle.

Qual è la differenza tra white hat e black hat?

Il white hat opera con autorizzazione per migliorare la sicurezza. Il black hat agisce senza autorizzazione con finalità criminali, economiche o distruttive.

Come si diventa ethical hacker?

Serve una base tecnica su reti, sistemi operativi, Linux, sicurezza applicativa, Active Directory, strumenti di penetration test e metodologie di analisi. Un corso ethical hacking permette di costruire un percorso strutturato.

Le aziende dovrebbero fare penetration test?

Sì. Il penetration test consente di simulare attacchi reali in modo controllato e identificare vulnerabilità prima che vengano sfruttate da attaccanti esterni.

Prerequisiti tecnici prima del rollout

Prima di abilitare FIDO2 con Cloud Kerberos Trust in produzione, conviene trattare il progetto come un intervento di architettura identita ibrida, non come una semplice opzione di portale. I prerequisiti principali riguardano client, tenant, dominio Active Directory, sicurezza Kerberos, sincronizzazione directory e gestione del dispositivo.

Area

Verifica richiesta

Client Windows

Windows 10 versione 2004 o successiva, oppure Windows 11. Preferibile standardizzare su build aggiornate e gestite.

Join del dispositivo

Dispositivi Microsoft Entra joined o hybrid joined, con registrazione corretta e utente sincronizzato.

Active Directory

Domain Controller Windows Server 2016 o successivi, patching aggiornato, replica sana, DNS e time sync corretti.

Kerberos

Verificare supporto AES e dismissione algoritmi deboli. Per l’approfondimento operativo vedere disabilitare RC4 in Kerberos.

Sincronizzazione identita

Entra Connect o Cloud Sync correttamente configurato, con attributi necessari e utenti sincronizzati verso Entra ID.

Ruoli amministrativi

Privilegi separati tra dominio e cloud; usare account dedicati e tracciare le operazioni eseguite.

Gestione dispositivi

Policy Intune o GPO coerenti. Nei tenant moderni il canale preferenziale e Endpoint Management e UEM con Microsoft Intune.

Sicurezza tenant

Verificare metodi di autenticazione, Conditional Access, breakglass e account privilegiati tramite Microsoft 365 Security Assessment.

 

Progettazione consigliata Nexsys

L’errore tipico e abilitare FIDO2 a tutti gli utenti senza segmentazione, senza pilota e senza processo di recovery. Un progetto passwordless deve invece partire da un disegno operativo: chi usa FIDO2 fisico, chi usa Windows Hello for Business, quali gruppi vengono abilitati, quali account sono esclusi, come si gestisce lo smarrimento della chiave, quali controlli vengono applicati da Conditional Access e quali risorse on-premises sono coinvolte.

  1. Assessment iniziale su tenant e dominio, collegando la verifica cloud al Microsoft 365 Security Assessment e la verifica AD all’Assessment & Hardening Active Directory.
  2. Definizione dei gruppi pilota: IT, amministratori selezionati, utenti high-value, poi progressione per reparti.
  3. Scelta del metodo: FIDO2 hardware per ruoli critici, Windows Hello for Business per utenti con PC gestiti, eventuali passkey solo dove il modello di rischio lo consente.
  4. Configurazione Microsoft Entra Kerberos nel dominio Active Directory interessato.
  5. Distribuzione policy client tramite Intune o GPO, con controlli su TPM, PIN, biometria, hardware security device e cloud trust.
  6. Test controllati su file share, applicazioni IIS, stampanti, mappature di rete, VPN, accessi remoti e scenari di recovery.
  7. Rollout progressivo con reportistica, troubleshooting e revisione periodica dei metodi di autenticazione registrati.

Configurazione Microsoft Entra Kerberos

Il cuore tecnico del modello e la creazione dell’oggetto AzureADKerberos nel dominio Active Directory. L’oggetto si comporta in modo simile a un oggetto RODC logico usato da Microsoft Entra ID per l’emissione dei ticket Kerberos necessari. Non e un Domain Controller fisico e non sostituisce il controllo locale delle autorizzazioni.

La configurazione va eseguita con account amministrativi separati per il piano cloud e per il dominio. Nel modello operativo Nexsys e preferibile usare sessioni tracciate, MFA phishing-resistant sugli amministratori e un processo di change documentato. Gli account di emergenza devono essere gia definiti; la guida interna correlata e Breakglass in Entra ID.

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

 

$domain = $env:USERDNSDOMAIN

$cloudCred = Get-Credential    # Hybrid Identity Administrator o ruolo equivalente

$domainCred = Get-Credential   # Domain Admin per il dominio interessato

 

Set-AzureADKerberosServer -Domain $domain `

  -CloudCredential $cloudCred `

  -DomainCredential $domainCred

 

Dopo la configurazione, il dominio deve essere verificato lato replica AD, lato portale Entra e lato client. In ambienti multi-dominio o multi-foresta non va dato per scontato che un solo intervento copra tutto il perimetro: ogni dominio interessato va valutato in base a utenti, risorse e trust esistenti.

Abilitazione FIDO2 e metodi passwordless in Entra ID

Il metodo FIDO2 va abilitato in Authentication Methods di Microsoft Entra ID con targeting per gruppi. La configurazione deve essere esplicita: gruppi abilitati, eventuale attestation, restrizioni sui modelli di chiave supportati, criteri di registrazione e processo di revoca. Per account privilegiati e ruoli critici, la governance deve rientrare in un disegno piu ampio di Identity Security.

  • Creare gruppi pilota dedicati per FIDO2 e per Windows Hello for Business.
  • Abilitare FIDO2 solo ai gruppi selezionati nella prima fase.
  • Documentare modelli di security key ammessi, PIN policy e processo di consegna.
  • Prevedere almeno un metodo di recupero forte e controllato, evitando ritorni incontrollati a fattori deboli.
  • Eseguire audit periodico dei metodi registrati dagli utenti e degli account senza metodo forte.

Policy client: Intune o GPO

Una volta pronto il piano identita, il client deve ricevere policy coerenti. Negli ambienti cloud-managed, Intune e il canale piu naturale per standardizzare Windows Hello for Business, requisiti TPM, PIN, biometria, uso di cloud trust e configurazioni di sicurezza endpoint. Negli ambienti ancora fortemente on-premises, le GPO restano utilizzabili, ma devono essere mantenute coerenti con la strategia Entra ID.

Canale

Configurazioni da presidiare

Microsoft Intune / Endpoint Management

Abilitare Windows Hello for Business, Cloud Trust for on-premises authentication, requisiti TPM/security device, profili account protection, compliance e Conditional Access.

Group Policy

Abilitare Windows Hello for Business, usare Cloud Kerberos Trust per autenticazione on-premises, definire policy PIN/biometria e hardware security device dove richiesto.

Conditional Access

Rendere coerenti i controlli con device compliance, ruoli amministrativi, rischio accesso e metodi di autenticazione resistenti al phishing.

 

Test di validazione prima della produzione

Il test non deve limitarsi al fatto che l’utente riesca ad accedere a Windows. Il vero obiettivo e verificare che l’utente acceda senza password e continui a usare le risorse on-premises senza prompt aggiuntivi, senza fallback manuale alla password e senza perdita di autorizzazioni.

  • Login Windows con security key FIDO2 o Windows Hello for Business.
  • Verifica PRT e stato registrazione dispositivo.
  • Accesso a file share SMB con permessi basati su gruppi AD.
  • Accesso ad applicazioni interne con Integrated Windows Authentication.
  • Mappatura stampanti o drive di rete dove ancora presenti.
  • Test da rete aziendale, VPN e scenario remoto previsto dall’organizzazione.
  • Verifica ticket con klist e analisi event log Kerberos lato client e Domain Controller.
  • Test di smarrimento chiave, reset metodo e revoca accesso.
  • Test sugli account esclusi o privilegiati, senza modificare impropriamente la Password Replication Policy.

Comandi utili per troubleshooting

In fase di troubleshooting conviene partire da evidenze semplici: stato dispositivo, PRT, ticket Kerberos, connettivita verso Domain Controller, DNS, time sync, gruppi utente e policy applicate. La presenza di un login passwordless riuscito non garantisce automaticamente che il ticket Kerberos sia utilizzabile verso ogni risorsa locale.

dsregcmd /status

 

klist

klist purge

 

whoami /groups

nltest /dsgetdc:contoso.local

Test-NetConnection dc01.contoso.local -Port 88

Test-NetConnection dc01.contoso.local -Port 445

 

Se il problema riguarda solo alcune risorse, analizzare ACL, SPN, DNS, trust, deleghe e configurazione Kerberos del servizio. Se il problema riguarda tutti gli accessi on-premises dopo login passwordless, la causa e piu probabilmente nella configurazione Entra Kerberos, nella policy client, nella sincronizzazione utente o nella connettivita verso i Domain Controller.

Limiti e scenari da non forzare

FIDO2 con Cloud Kerberos Trust e potente, ma non deve essere interpretato come una soluzione universale per qualsiasi scenario Windows. Alcuni casi richiedono ancora smart card, certificati, PAM, jump server o architetture diverse.

  • Non usare FIDO2 come unica risposta per accessi RDP, VDI o login diretto sui server se lo scenario non e supportato.
  • Non estendere indiscriminatamente CKT agli account privilegiati senza valutare gruppi built-in, policy di replica password e modello Tier 0.
  • Non lasciare password legacy attive senza controllo: il passwordless perde valore se la password resta il fallback principale e attaccabile.
  • Non trascurare DNS, time sync e salute dei Domain Controller: Kerberos resta sensibile alla qualita dell’infrastruttura AD.
  • Non trattare la sicurezza cloud separatamente da AD. In ambienti ibridi, Identity Security e Assessment & Hardening Active Directory devono essere coordinati.

Account privilegiati, breakglass e recovery

Gli account amministrativi richiedono una progettazione distinta. FIDO2 e un metodo eccellente per account critici, ma non deve eliminare la capacita di recovery. Un tenant deve mantenere account breakglass documentati, monitorati e protetti con criteri coerenti. Allo stesso tempo, gli amministratori non devono usare account privilegiati per attivita quotidiane o per test di rollout utente.

Per questo la configurazione passwordless va collegata a un modello di ruoli, privilegi e account amministrativi. La pagina Nexsys su Microsoft Entra ID Tiering puo essere usata come approfondimento sul piano identita; la guida Breakglass in Entra ID resta invece il riferimento per continuita di accesso amministrativo in scenari critici.

Roadmap di implementazione consigliata

Fase

Obiettivo

Output

1. Assessment

Verificare tenant, Entra ID, metodi MFA, Conditional Access, AD, Kerberos, client e gruppi pilota. Collegare a Microsoft 365 Security Assessment e Assessment AD.

Gap list tecnica, prerequisiti, rischi, utenti pilota.

2. Design

Definire chiavi FIDO2, WHfB, criteri Intune/GPO, gruppi, recovery, breakglass, rollout e rollback.

Documento di architettura e piano operativo.

3. Configurazione

Creare oggetto AzureADKerberos, abilitare metodi Entra, configurare policy client e Conditional Access.

Tenant e dominio pronti per pilota controllato.

4. Pilot

Validare login passwordless, accesso file share, applicazioni Kerberos, VPN, recovery e supporto helpdesk.

Esiti test, anomalie, correzioni e decisione go/no-go.

5. Rollout

Distribuire per gruppi progressivi, monitorando registrazioni, ticket, incidenti e fallback.

Rollout controllato e misurabile.

6. Governance

Audit periodico metodi di autenticazione, chiavi, account privilegiati, ticket Kerberos e compliance dispositivi.

Controllo continuativo e miglioramento della postura.

 

Come Nexsys supporta il progetto

Nexsys supporta aziende e reparti IT nella progettazione e implementazione di accessi passwordless in ambienti Microsoft 365, Entra ID e Active Directory. L’intervento puo partire da un assessment puntuale o inserirsi in un percorso piu ampio di modernizzazione della sicurezza, con focus su identita, dispositivi, Conditional Access, hardening AD e formazione tecnica del personale IT.

L’obiettivo non e abilitare una singola opzione, ma rendere operativo un modello di accesso passwordless che riduca il rischio di furto credenziali e mantenga la compatibilita con le risorse aziendali ancora basate su Active Directory.

Per valutare l’adozione di FIDO2 e Cloud Kerberos Trust nel tuo ambiente Microsoft, richiedi una consulenza tecnica Nexsys con analisi del tenant, del dominio Active Directory e dei dispositivi coinvolti.

FAQ

Cloud Kerberos Trust sostituisce Active Directory?

No. Cloud Kerberos Trust non sostituisce Active Directory e non elimina i Domain Controller. Permette a Microsoft Entra ID di partecipare al rilascio dei ticket necessari per l’accesso passwordless, ma autorizzazioni, ACL, gruppi e service ticket restano governati dall’infrastruttura AD on-premises.

FIDO2 permette di accedere ai file server aziendali senza password?

Si, se l’ambiente e configurato correttamente con Microsoft Entra Kerberos e Cloud Kerberos Trust. L’utente puo accedere a Windows con security key FIDO2 o metodo passwordless e ottenere SSO verso risorse Kerberos come file share SMB e applicazioni interne.

Serve ancora Entra Connect?

Nella maggior parte degli scenari ibridi si, perche gli utenti devono essere sincronizzati tra Active Directory e Microsoft Entra ID. La configurazione va verificata soprattutto se il tenant usa regole di sincronizzazione personalizzate o domini multipli.

FIDO2 funziona anche con RDP o VDI?

Non va dato per scontato. Gli scenari RDP, VDI, login diretto sui server ed “Esegui come” hanno limitazioni specifiche. In questi casi possono essere piu adatti certificati smart card, PAM, jump server o altri modelli di accesso privilegiato.

E meglio usare FIDO2 o Windows Hello for Business?

Dipende dallo scenario. FIDO2 hardware e indicato per account critici e utenti high-value. Windows Hello for Business e spesso piu adatto per utenti con PC aziendali gestiti. In molti progetti i due metodi convivono, con regole diverse per gruppi e ruoli.

Quali controlli vanno fatti prima del rollout?

Vanno verificati tenant Entra ID, metodi di autenticazione, Conditional Access, dispositivi gestiti, salute Active Directory, Domain Controller, DNS, time sync, supporto Kerberos AES, sincronizzazione identita e processo di recovery.