Sicurezza

Cifratura

Gestione dei segreti

• Tutti i segreti applicativi (chiavi di cifratura, credenziali di database, chiavi private di firma, credenziali dei fornitori) risiedono in Azure Key Vault, nella stessa regione UE dei dati.
• I servizi accedono al vault tramite identità gestita, senza credenziali statiche incorporate nel codice o nelle immagini.
• Nessun segreto è presente nei repository di codice o nelle variabili di ambiente in chiaro degli ambienti produttivi.
• L'accesso al vault è tracciato e limitato al minimo indispensabile.
• La rotazione delle chiavi di cifratura è annuale, con supporto alla decifratura dei dati cifrati con la chiave precedente.

Hashing delle password

Le password non sono mai memorizzate, trasmesse né registrate nei log in forma leggibile. La reimpostazione avviene tramite collegamento firmato a scadenza breve, valido una sola volta.

Politiche configurabili dal Cliente:

• lunghezza minima (predefinita 12 caratteri);
• blocco delle password compromesse note;
• scadenza periodica (sconsigliata se è attiva MFA);
• numero di tentativi falliti prima del blocco temporaneo (predefinito 5).

Rotazione delle chiavi JWT

I token di sessione sono firmati con chiavi RSA sottoposte a rotazione senza interruzione di servizio. Ogni chiave attraversa tre stati:

ACTIVE        firma i nuovi token e ne verifica la validità
VERIFY_ONLY   non firma più, continua a verificare i token già emessi
RETIRED       rimossa dal set pubblico, nessun token firmato con essa è più valido

Chiavi API

• Le chiavi sono generate con un generatore crittograficamente sicuro e mostrate una sola volta.
• In archivio è memorizzato solo l'hash SHA-256; il prefisso visibile (es. bp_live_7f3a…) serve unicamente all'identificazione nell'elenco.
• Ogni chiave ha ambito (permessi granulari), scadenza opzionale e traccia dell'ultimo utilizzo.
• La rotazione supporta un periodo di sovrapposizione configurabile in cui vecchia e nuova chiave sono entrambe valide.
• La revoca ha effetto immediato su tutte le richieste in corso.

Autenticazione a più fattori

L'MFA può essere resa obbligatoria per tutto il tenant o per singoli ruoli:

RBAC e minimo privilegio

I permessi seguono il formato {servizio}:{risorsa}:{azione}, per esempio:

identity:users:read
identity:users:write
identity:audit:read
identity:audit:export
console:sessions:read
console:contacts:write
config:knowledge:write
billing:invoices:read

Principi applicati:

• negazione predefinita: nessun permesso è implicito, tutto deve essere concesso;
• ruoli componibili: un utente può avere più ruoli, i permessi si sommano;
• verifica a ogni richiesta: i permessi non sono memorizzati nel token in modo permanente ma rivalutati, così la revoca ha effetto immediato;
• separazione dei compiti: chi gestisce gli utenti non ha necessariamente accesso ai dati delle conversazioni.

Vedi Ruoli e permessi per la matrice completa.

Isolamento dei tenant

Ogni tenant dispone di uno schema di database dedicato (bp_t_{identificativo}). Il contesto del tenant è derivato dai claim firmati del token e validato a ogni richiesta: non è possibile forzare l'accesso a un altro tenant modificando un parametro. Dettagli in Residenza dei dati.

Hardening dell'infrastruttura

• Esecuzione in container su Azure Container Apps, con immagini minime e utente non privilegiato.
• Nessun accesso SSH ai nodi di produzione: le operazioni avvengono tramite pipeline automatizzate.
• Web Application Firewall e protezione anti-DDoS a livello di Azure Front Door.
• Rete privata fra i servizi; i database non sono raggiungibili da Internet.
• Header di sicurezza applicati: HSTS, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
• Segregazione degli ambienti: sviluppo, staging e produzione sono infrastrutture separate; i dati di produzione non vengono copiati negli ambienti inferiori.

Gestione delle vulnerabilità e patching

Test di sicurezza

• Penetration test annuale condotto da fornitore terzo indipendente, su applicazione e API. La lettera di attestazione (attestation letter) è disponibile su richiesta sotto accordo di riservatezza; il rapporto integrale non viene distribuito.
• Test di sicurezza automatizzati in pipeline a ogni rilascio.
• Programma di segnalazione responsabile: le segnalazioni vanno inviate a support@blupantheon.com con oggetto “Security report”. Ci impegniamo a un riscontro entro 3 giorni lavorativi e a non intraprendere azioni verso chi segnala in buona fede rispettando le regole di ingaggio.

Continuità operativa

• Il piano di continuità è verificato semestralmente con esercitazione documentata.
• Il ripristino da backup è testato trimestralmente su un ambiente isolato.
• Lo stato del servizio, lo storico degli incidenti e la disponibilità misurata sono disponibili su richiesta a support@blupantheon.com.

Backup e ripristino

Incident response

Contatti di sicurezza

Checklist di sicurezza per il cliente

Controlli che dipendono dalla tua configurazione. Rivedila almeno ogni sei mesi.