Informazioni

Tutte le comunicazioni tra browser e server transitano su canale cifrato HTTPS/TLS. I dati in transito non sono intercettabili né alterabili da terzi.

Le password sono sottoposte a hashing con algoritmo bcrypt a costo computazionale elevato prima della memorizzazione. Non vengono mai archiviate o trasmesse in chiaro. Sono applicate politiche di complessità minima (lunghezza, varietà di caratteri) validate sia lato client che lato server.

Gli account con privilegi elevati (admin, tenant admin, security manager) devono obbligatoriamente attivare un secondo fattore di autenticazione prima di accedere ai moduli dell'applicazione. Il metodo supportato è TOTP (RFC 6238), compatibile con le principali app di autenticazione (Google Authenticator, Authy, ecc.). Il segreto TOTP è cifrato a riposo con AES-256-CBC e chiave derivata da segreto applicativo esterno alla webroot. Ogni codice TOTP è valido per un'unica autenticazione (anti-replay) nell'arco della finestra di 30 secondi.

L'applicazione supporta l'autenticazione tramite passkey secondo lo standard WebAuthn (FIDO2). Le credenziali crittografiche sono generate e conservate sul dispositivo dell'utente (hardware security key, Touch ID, Windows Hello) e non transitano mai sui server. Il meccanismo è resistente al phishing per design: la verifica crittografica è vincolata all'origine del sito. Gli account privilegiati possono registrare più passkey per ridondanza.

È disponibile un flusso di autenticazione basato su codice QR per scenari operativi in cui l'inserimento della password non è praticabile (es. postazione condivisa). Il token QR è monouso, ha una durata di validità breve e può essere rifiutato esplicitamente dall'utente autenticato sul proprio dispositivo. L'approvazione richiede una sessione già autenticata su un secondo dispositivo. I token consumati o scaduti sono eliminati automaticamente.

Al momento della creazione o del cambio password, la scelta viene verificata contro un dizionario locale di password comuni e compromesse. Vengono rifiutate automaticamente le password rilevate come banali o già presenti in data breach pubblici noti, riducendo il rischio di attacchi a dizionario. Il controllo avviene esclusivamente lato server, senza trasmissione delle credenziali a servizi esterni.

L'identificativo di sessione viene rigenerato dopo ogni autenticazione per prevenire attacchi di session fixation. I cookie di sessione sono configurati con attributi HttpOnly (non accessibili da JavaScript), SameSite=Strict (protezione CSRF nativa) e nome non standard per ridurre il fingerprinting. Le sessioni scadono automaticamente dopo un periodo di inattività configurato.

Ogni richiesta che modifica dati (creazione, aggiornamento, eliminazione) include un token crittografico univoco verificato lato server, a protezione da attacchi Cross-Site Request Forgery. Il token è generato con entropia crittografica e associato alla sessione corrente.

Tutte le interazioni con il database avvengono esclusivamente tramite query parametrizzate (prepared statements). L'input utente non viene mai concatenato nelle istruzioni SQL, eliminando il rischio di iniezione.

Tutti i dati in ingresso sono validati per tipo, formato e intervallo sia lato client che lato server. L'output verso il browser è sottoposto a codifica contestuale per prevenire attacchi Cross-Site Scripting (XSS), inclusa la codifica dei caratteri speciali HTML.

Ogni richiesta viene verificata lato server per sessione attiva, ruolo e permessi specifici dell'utente. Il controllo accessi opera sul principio del minimo privilegio: ciascun ruolo ha accesso esclusivamente alle risorse e alle operazioni strettamente necessarie. Il sistema supporta l'isolamento multi-tenant per separare i dati tra organizzazioni distinte.

Ogni risposta HTTP include un insieme completo di intestazioni di sicurezza: Content-Security-Policy con nonce crittografico (blocca l'esecuzione di script non autorizzati), X-Frame-Options (previene il clickjacking), X-Content-Type-Options (impedisce il MIME sniffing) e Referrer-Policy (limita l'esposizione degli URL di provenienza).

Dopo un numero limitato di tentativi di accesso falliti, l'account viene temporaneamente bloccato. Il meccanismo di rate limiting è applicato lato server e non è aggirabile dal client. I tentativi falliti vengono registrati con timestamp e indirizzo IP di origine.

Tutte le autenticazioni (riuscite e fallite), le operazioni di modifica su dati sensibili e gli eventi di sicurezza vengono registrati in log strutturati con timestamp ISO 8601, identificativo utente e indirizzo IP di origine. I log coprono tutti gli endpoint che modificano dati e sono progettati per supportare il rilevamento di anomalie e le procedure di gestione degli incidenti. In caso di impossibilità di scrittura sul file di log, il sistema attiva un canale di fallback per non perdere eventi critici.

Un ruolo dedicato (Security Manager), distinto dagli amministratori applicativi, ha accesso in sola lettura a una dashboard di sicurezza riservata. La dashboard include in tempo reale: sessioni utente attive, tentativi di brute-force nelle ultime 24 ore, accessi fuori dall'orario lavorativo, compliance MFA e stato delle password di tutti gli account, log di audit completi con filtri avanzati per livello, data e contenuto. L'accesso alla dashboard richiede obbligatoriamente MFA e non consente alcuna modifica ai dati applicativi.

Il Security Manager può sospendere immediatamente un account utente in caso di sospetto furto di credenziali o altra compromissione, senza rimuovere l'account definitivamente. La sospensione blocca istantaneamente ogni nuovo tentativo di accesso e termina le sessioni attive al successivo heartbeat (entro circa 60 secondi). Il Security Manager può inoltre imporre un cambio obbligatorio di password al prossimo accesso. Ogni azione è registrata nell'audit log con motivazione obbligatoria; gli account privilegiati (admin, tenant admin, security manager) non possono essere bersaglio di queste azioni.

Il sistema mantiene un registro aggiornato di tutte le sessioni utente correntemente attive, con indicazione dell'indirizzo IP di origine, dello user agent, del timestamp di apertura e dell'ultima attività registrata. Il registro è visibile al Security Manager e viene aggiornato dal meccanismo di heartbeat ogni 60 secondi. Le sessioni scadute vengono rimosse automaticamente dal registro. Le sessioni degli account sospesi vengono terminate al successivo heartbeat senza richiedere intervento manuale.

Il Security Manager può esportare i log di audit in due formati. Il formato CSV include banner di classificazione obbligatorio e BOM UTF-8 per l'importazione in fogli elettronici, con protezione da formula injection. Il formato JSON segue lo standard Elastic Common Schema (ECS) e include un oggetto wrapper con metadati (timestamp di esportazione, periodo, numero di eventi) e i record di log originali in formato compatto, direttamente ingestibili da sistemi SIEM (Splunk, Elastic, Graylog, ecc.). L'esportazione è limitata al periodo scelto (7, 30 o 90 giorni) e ogni download è tracciato nell'audit log.

L'applicazione non carica alcuna risorsa da CDN o servizi esterni a runtime. Tutte le librerie di terze parti sono incluse localmente, verificate e aggiornate manualmente. L'applicazione non effettua chiamate HTTP verso servizi esterni durante il normale funzionamento.

In ambiente di produzione, gli errori applicativi vengono registrati internamente ma non esposti all'utente. I messaggi mostrati sono generici e non rivelano dettagli dell'implementazione (stack trace, nomi di tabelle, percorsi di file, versioni software).

Le operazioni critiche che coinvolgono più entità (es. eliminazione utente con riassegnazione risorse) sono eseguite in transazioni atomiche: o tutte le modifiche vengono applicate, o nessuna. Questo garantisce la coerenza dei dati anche in caso di errore parziale.

Il sistema conserva un archivio cifrato delle password precedenti di ciascun utente e impedisce il riutilizzo delle ultime password già impiegate. Questa misura riduce il rischio di compromissione derivante dalla rotazione ciclica tra un numero limitato di credenziali.

Al login degli amministratori viene segnalata automaticamente la presenza di account che non effettuano accesso da un periodo prolungato. Questo supporta la revisione periodica degli account attivi e la disattivazione tempestiva di quelli non più in uso, riducendo la superficie di attacco.

Dopo un periodo di inattività l'interfaccia viene automaticamente oscurata da uno schermo di blocco che nasconde tutti i contenuti, a protezione da accessi visivi non autorizzati (shoulder surfing). L'utente può tornare alla schermata di accesso per autenticarsi nuovamente.

Prima dell'accesso viene mostrato un avviso che informa l'utente sulla natura riservata del sistema, sulla registrazione delle attività e sulle conseguenze dell'uso non autorizzato, in conformità ai requisiti di notifica pre-login.

Le chiavi utilizzate per cifrare dati sensibili a riposo (segreti MFA, credenziali SMTP) sono derivate da un segreto applicativo conservato al di fuori della directory pubblica del web server. È prevista una procedura documentata per la rotazione periodica delle chiavi senza interruzione del servizio. L'avvio in produzione è bloccato se il segreto non è stato configurato.

Nelle configurazioni multi-organizzazione, i dati di ciascun tenant sono isolati a livello applicativo: ogni richiesta viene filtrata lato server in base al perimetro organizzativo dell'utente. Un amministratore di tenant non può accedere, visualizzare né modificare dati appartenenti ad altri tenant.

Le notifiche push inviate dal server al browser degli utenti sono cifrate end-to-end tramite lo standard Web Push con autenticazione VAPID. Il payload viaggia cifrato con ECDH su curva P-256 e AES-128-GCM: solo il browser di destinazione può decifrarlo. La chiave privata VAPID è conservata esclusivamente lato server e non viene mai esposta al client. Ogni invio di notifica è registrato nell'audit log con identificativo utente e timestamp. Le iscrizioni push degli utenti sono associate alla sessione autenticata e revocabili in qualsiasi momento.

L'applicazione è installabile come Progressive Web App tramite Service Worker. La strategia di caching è progettata con criteri di sicurezza espliciti: gli asset statici (CSS, JavaScript, icone) sono gestiti con cache-first per prestazioni; le pagine PHP e tutti gli endpoint API sono gestiti con network-only, impedendo che sessioni, token CSRF o risposte dati vengano memorizzati nella cache del browser. I dati personali e le risposte autenticate non transitano mai attraverso la cache del Service Worker. Ogni aggiornamento dell'applicazione incrementa la versione della cache, forzando il rinnovo completo degli asset.

L'accesso al server è riservato al personale tecnico autorizzato tramite autenticazione a chiave crittografica (RSA/Ed25519). L'accesso con sola password è disabilitato. L'accesso come utente root è proibito. Il servizio SSH utilizza esclusivamente algoritmi crittografici moderni (Curve25519, AES-GCM, ChaCha20-Poly1305) e rifiuta protocolli e cifrari obsoleti. Ogni sessione amministrativa è registrata con timestamp, origine e operazioni eseguite. Un banner legale avvisa che l'accesso è riservato e monitorato.

Il sistema operativo, il web server, il runtime applicativo e il database sono soggetti a un ciclo di aggiornamento regolare che include patch di sicurezza e aggiornamenti minori. Gli aggiornamenti di sicurezza vengono applicati automaticamente con cadenza giornaliera. Le versioni in uso sono monitorate rispetto ai bollettini CVE pubblicati. L'applicazione non dipende da librerie caricate da internet a runtime, eliminando il rischio di compromissione della supply chain software.

Le regole firewall seguono il principio deny-by-default: sono esposti esclusivamente i servizi strettamente necessari (HTTP/S). Il database non è raggiungibile dall'esterno e accetta connessioni solo dall'applicazione locale. Le porte di amministrazione sono filtrate per indirizzo IP di origine. Il protocollo IPv6 è disabilitato in quanto non utilizzato, riducendo la superficie di attacco.

Il web server è configurato per disabilitare il directory listing, nascondere le informazioni sulla versione software nelle risposte HTTP, e impedire l'accesso diretto a file di configurazione, log e risorse interne. I file sensibili sono protetti a livello di configurazione del server. In ambiente di produzione gli errori applicativi non vengono mai mostrati all'utente: sono registrati solo nei log interni.

Il servizio database è accessibile esclusivamente dall'applicazione tramite connessione locale e non accetta connessioni dalla rete esterna. Le credenziali di accesso al database sono conservate al di fuori della directory pubblica del web server, in file con permessi restrittivi. Il charset Unicode completo (UTF-8 MB4) è garantito per prevenire attacchi basati su encoding.

Il certificato TLS è emesso da un'autorità di certificazione riconosciuta, con rinnovo automatico prima della scadenza. Il server accetta esclusivamente protocolli e cipher suite conformi alle raccomandazioni correnti, rifiutando connessioni con protocolli obsoleti (SSL, TLS 1.0/1.1). L'intestazione HSTS con preload forza il browser a utilizzare esclusivamente connessioni cifrate, anche per le richieste successive.

I dati del database sono sottoposti a backup automatico giornaliero in locale e settimanale su cloud. I backup completi (database, applicazione, configurazione di sistema) sono cifrati con AES-256 prima del trasferimento e dell'archiviazione. Le copie di sicurezza sono archiviate in posizione geograficamente separata dai dati operativi, con politica di retention definita. Le procedure di ripristino sono documentate con script dedicati.

Il server è dotato di sistemi di monitoraggio per la disponibilità dei servizi e la rilevazione di accessi anomali. I log di sistema e i log applicativi sono conservati separatamente e protetti da modifiche non autorizzate, a supporto delle attività di incident response. Un report giornaliero automatico analizza e sintetizza gli eventi di log per facilitare l'individuazione tempestiva di attività sospette.

Il sistema operativo è configurato secondo le raccomandazioni CIS Benchmark con uno script di hardening automatizzato e verificabile. Le misure includono: protezione della memoria tramite randomizzazione dello spazio di indirizzamento (ASLR), protezione contro attacchi di rete (anti-spoofing, SYN cookies, blocco dei redirect e del source routing), restrizione dell'accesso ai log del kernel e limitazione delle capacità di debug tra processi. Le configurazioni sono verificate periodicamente con script di controllo automatizzato.

Sul server sono attivi esclusivamente i servizi necessari al funzionamento dell'applicativo. Tutti i servizi non essenziali (Bluetooth, stampanti di rete, discovery automatico, reporting crash) sono stati disabilitati o rimossi. I permessi sui file di sistema sensibili (credenziali, configurazione accessi, crontab) sono ristretti al solo amministratore.

Un sistema di prevenzione automatica monitora i tentativi di accesso falliti e blocca a livello firewall gli indirizzi IP che superano la soglia configurata. Il blocco è efficace su tutte le porte, non solo sul servizio attaccato. Le policy di ban prevedono soglie e durate differenziate in base alla gravità del comportamento rilevato.

Un daemon di audit dedicato registra in modo continuo le modifiche ai file critici del sistema operativo (credenziali, configurazione accessi privilegiati, configurazione SSH, crontab), l'esecuzione di comandi con privilegi elevati e le modifiche alla configurazione di rete. I record di audit sono conservati con buffer dedicato e sono separati dai log applicativi.

Il server dispone di due strumenti indipendenti di scansione per rootkit e software malevolo, eseguibili periodicamente per verificare l'integrità del sistema operativo. L'utilizzo di due strumenti distinti fornisce una verifica incrociata e riduce il rischio di falsi negativi.

La configurazione di sicurezza del server è documentata e applicata tramite script versionati, garantendo riproducibilità e verificabilità. Ogni modifica alla configurazione è tracciabile. Uno script di verifica automatizzato confronta periodicamente lo stato corrente del sistema con la baseline di sicurezza attesa, segnalando eventuali deviazioni.

Vengono raccolti esclusivamente i dati strettamente necessari al funzionamento dell'applicativo: dati identificativi (nome, cognome), credenziali di accesso (email), ruolo organizzativo e unità di appartenenza. Nessun dato superfluo viene richiesto o memorizzato.

L'accesso ai dati personali è confinato in base al ruolo dell'utente e alla sua posizione nell'organigramma. Ogni utente visualizza esclusivamente le informazioni pertinenti alle proprie responsabilità. L'isolamento è applicato a livello di query e verificato lato server ad ogni richiesta.

I dati personali non vengono condivisi, venduti o trasferiti a soggetti terzi. L'applicazione non integra servizi di analisi, tracciamento o advertising esterni. Nessun dato transita verso server al di fuori dell'infrastruttura controllata.

L'applicazione utilizza esclusivamente cookie di sessione tecnici, indispensabili al funzionamento. Non sono presenti cookie di profilazione, di marketing né script di tracciamento di terze parti.

Gli utenti possono esercitare i diritti di accesso, rettifica, cancellazione e portabilità dei propri dati personali inviando una richiesta via email allo sviluppatore indicato nella sezione contatti. Le richieste vengono evase entro i termini previsti dalla normativa.