Una soglia di inattività di due ore non supera alcun framework di sicurezza riconosciuto. CIS Control 4.3 limita le sessioni OS generali a 15 minuti e i dispositivi mobili a 2 minuti. PCI DSS 8.1.8, NIST SP 800-53 AC-11 e HIPAA § 164.312(a)(2)(iii) convergono sullo stesso principio: una postazione di lavoro incustodita deve bloccarsi abbastanza rapidamente da negare l'accesso opportunistico, mai dopo ore di inattività.
I timeout brevi hanno tradizionalmente contrastato con la produttività degli utenti. Gli operatori aggirano il blocco, condividono le password o disabilitano completamente lo screensaver. Questo compromesso non vale più. L'autenticazione di prossimità e le chiavi hardware FIDO2 consentono ora impostazioni di inattività aggressive senza attrito, bloccando il dispositivo nel momento in cui l'utente si allontana e riautenticandosi al ritorno.
Le sezioni seguenti risolvono la contraddizione che circola online, associano ogni requisito di conformità a un preciso valore di timeout e descrivono come configurare il blocco automatico della sessione su Windows, macOS, Linux e sessioni remote.
Cosa sia davvero un blocco automatico della sessione (e perché «2 ore» è sbagliato)
Definizione e meccanismi: blocco sessione vs disconnessione automatica vs terminazione della sessione
Un blocco automatico della sessione sospende una sessione attiva dopo un periodo di inattività definito e richiede la riautenticazione (password, PIN, biometria, smart card) prima di riprendere. La sessione stessa rimane attiva in memoria: i processi in esecuzione, i file aperti e le connessioni di rete persistono dietro uno schermo bloccato, spesso abbinato a un display occultante o a uno screensaver. La disconnessione automatica termina completamente la sessione utente e chiude le applicazioni. La terminazione della sessione va oltre, recidendo il contesto autenticato sottostante presso il provider di identità. Ogni controllo risponde a un rischio distinto: accesso fisico opportunistico, credenziali persistenti o token obsoleti.
Il verdetto sull'affermazione delle «2 ore» — cosa dicono davvero le fonti autorevoli
Falso. Nessun framework riconosciuto approva un massimo di 120 minuti. CIS Control 4.3 limita il tempo di inattività a 15 minuti per le postazioni di lavoro e 2 minuti per i dispositivi mobili; PCI DSS 8.2.8 e NIST AC-11 si allineano allo stesso limite.
Matrice di conformità dei framework: timeout richiesti per standard
Confronto diretto: CIS 15 min, CJIS 30 min, PCI DSS 15 min, NIST AC-11, HIPAA §164.312(a)(2)(iii), ISO/IEC 27002
I revisori raramente accettano «la prassi del settore» come evidenza. Si aspettano una clausola specifica associata a un timeout configurato. La matrice seguente consolida ciò che ogni standard richiede.
| Framework | Clausola | Inattività max. | Ambito |
|---|---|---|---|
| CIS Controls v8.1 | Safeguard 4.3 | 15 min (OS) / 2 min (mobile) | Asset aziendali |
| NIST SP 800-53 | AC-11 | Definito dall'organizzazione, ≤15 min tipico | Sistemi federali |
| NIST SP 800-171 | 3.1.10 | Display occultante richiesto | Ambienti CUI |
| PCI DSS v4.0 | 8.2.8 | 15 min | Dati dei titolari di carta |
| HIPAA Security Rule | §164.312(a)(2)(iii) | Ragionevole, indirizzabile | Postazioni ePHI |
| CJIS Security Policy | 5.5.5 | 30 min | Informazioni di giustizia penale |
| ISO/IEC 27002:2022 | 8.1 | Definito dalla politica | Tutti gli endpoint |
Display occultanti, riautenticazione e requisiti di evidenze di audit
Tre sottocontrolli determinano se un'implementazione supera l'audit. Il blocco deve nascondere il contenuto precedente dello schermo (NIST AC-11(1)), richiedere una riautenticazione basata su credenziali anziché un semplice gesto di chiusura, e produrre voci di registro che provino l'applicazione sull'intera flotta di dispositivi.
Configurare il blocco automatico della sessione su ogni piattaforma
Windows GPO e registro, profili MDM macOS e Linux (GNOME/KDE/TMOUT)
Su Windows, applicate la politica tramite Computer Configuration → Policies → Administrative Templates → Control Panel → Personalization → Enable screen saver combinato con Password protect the screen saver e Screen saver timeout impostato a 900 secondi. Il percorso di registro equivalente è HKLM\Software\Policies\Windows\Control Panel\Desktop. Per macOS, distribuite un profilo di configurazione con le chiavi askForPassword e askForPasswordDelay tramite MDM. Su Linux, GNOME espone org.gnome.desktop.session idle-delay, KDE utilizza kscreenlockerrc, e le sessioni shell devono impostare TMOUT=900 in /etc/profile.d/.
RDP, VDI, SSH e blocchi a livello applicativo (EHR, ERP, console di amministrazione)
Le sessioni remote necessitano di propri controlli. Configurate fSessionTimeoutIdleLimit per RDP, impostate ClientAliveInterval in sshd_config e definite le politiche di inattività in Citrix o VMware Horizon. L'applicazione a livello di applicazione è altrettanto importante: Epic, SAP e la console AWS espongono tutti impostazioni di riautenticazione per inattività che operano indipendentemente dal blocco OS.
Eliminare il compromesso usabilità-sicurezza con prossimità e FIDO2
I timeout aggressivi falliscono quando gli utenti li combattono. Appaiono post-it, i mouse jiggler si diffondono e i blocchi vengono disabilitati all'helpdesk. L'autenticazione di prossimità rompe questo schema.
Chiavi hardware, FIDO2 e blocco automatico per prossimità all'allontanamento, sblocco automatico al ritorno
Una chiave hardware FIDO2 abbinata al Bluetooth con blocco automatico all'allontanamento e sblocco automatico al ritorno consente di applicare un blocco di inattività di 2 minuti senza un singolo reclamo. La postazione di lavoro si blocca nel momento in cui l'utente si allontana e si sblocca automaticamente al ritorno, con la riautenticazione crittografica gestita dalla chiave. Nessuna riscrittura di password, nessuna attrito con lo screensaver, nessun compromesso sulla soglia di inattività.
Blocco di sessione in un'architettura Zero Trust
Zero Trust richiede una verifica continua, non un semplice accesso singolo. Il blocco di sessione operazionalizza il pilastro Verify Explicitly imponendo una riautenticazione legata al contesto: postura del dispositivo, posizione, ora del giorno. Combinato con l'accesso condizionale, ogni sblocco diventa una nuova decisione di fiducia piuttosto che un diritto ereditato.
Insidie dell'audit, lavoro remoto e lista di controllo di implementazione
Principali motivi per cui le organizzazioni non superano gli audit di blocco sessione — e timeout per ruolo per configurazioni remote, ibride e postazioni condivise
I revisori segnalano ripetutamente le stesse lacune: GPO limitati all'OU sbagliato, account di servizio lasciati interattivi, display occultanti mancanti richiesti da NIST AC-11(1), utenti che disabilitano i blocchi screensaver localmente e sessioni applicative che persistono dietro un OS bloccato. Le configurazioni remote e ibride amplificano il rischio. Calibrate i timeout per ruolo: 2 minuti per i terminali condivisi clinici, 5 minuti per gli uffici domestici e i laptop BYOD, 10 minuti per gli agenti di call center, 15 minuti per gli endpoint di ufficio generale.
Lista di controllo di implementazione ed elementi essenziali del modello di politica
Una politica distribuibile copre sette elementi: inventario degli asset, classificazione dei rischi, applicazione GPO e MDM, riautenticazione a livello applicativo, registrazione di audit degli eventi di blocco, revisione annuale e governance delle eccezioni. Abbiatela allo sblocco per prossimità per mantenere soglie aggressive praticabili — prenotate una demo per una guida di distribuzione personalizzata.
Domande frequenti
Un blocco automatico della sessione dovrebbe avvenire dopo un massimo di due ore di inattività?
No. Una soglia di 120 minuti contraddice ogni standard riconosciuto. CIS Control 4.3 limita le sessioni OS generali a 15 minuti di inattività e i dispositivi mobili a 2 minuti. PCI DSS 8.2.8 e NIST AC-11 si allineano intorno allo stesso limite di 15 minuti.
Quali framework di conformità richiedono esplicitamente un blocco automatico della sessione?
Sei framework fanno riferimento diretto a questo controllo: NIST SP 800-53 AC-11, NIST SP 800-171 §3.1.10, CIS Critical Security Controls v8.1, PCI DSS Requirement 8.2.8, HIPAA §164.312(a)(2)(iii) e ISO/IEC 27002. Il CJIS aggiunge un massimo di 30 minuti per i sistemi di giustizia penale.
Il blocco di sessione basato su password o su prossimità è più sicuro?
Il blocco per prossimità supera i metodi basati esclusivamente su password. Elimina l'attrito per l'utente, azzera i blocchi manuali dimenticati e applica automaticamente timeout aggressivi. Combinato con l'autenticazione hardware FIDO2, colma il divario tra la politica e il comportamento reale degli utenti — il rilievo di audit più comune sui controlli di blocco sessione.