Come proteggiamo i tuoi certificati

Tutti i file di certificato (.p12, .cer, .key, .pem) sono archiviati cifrati con AES-256-GCM seguendo un modello di chiave a due livelli: ogni file ha la propria chiave di cifratura dei dati (DEK), avvolta da una chiave di cifratura delle chiavi (KEK) gestita in AWS KMS. Le password dei certificati vengono cifrate prima di essere scritte nel database — non viene applicato l'hash, perché devono essere usate operativamente per caricare i certificati.

AlertaCert supporta chiavi di accesso biometriche (Face ID, impronta digitale, Windows Hello) come secondo fattore di autenticazione. Le chiavi di accesso sono resistenti allo phishing per design — non vengono mai trasmesse al server.

Le azioni ad alto rischio — rivelare la password, scaricare il certificato, eliminare, firmare documenti, gestire i membri — richiedono una re-autenticazione recente. Se la tua sessione è vecchia, ti verrà chiesto di confermare la tua identità prima di procedere.

Ogni organizzazione ha ruoli di amministratore e membro. I membri non possono invitare utenti, cambiare ruoli, eliminare clienti o annullare flussi di firma. Gli amministratori controllano esattamente quali permessi sono sensibili nella loro organizzazione.

Ogni azione sensibile — caricamento, download, visualizzazione password, firma, eliminazione, cambio ruolo — viene registrata in un log di audit. Il log non ha politica di INSERT, UPDATE o DELETE per nessun utente o amministratore: solo il client di servizio può aggiungere voci. Le voci del log sono collegate tramite hash — ogni voce include l'hash della precedente, rendendo rilevabile qualsiasi manomissione silenziosa.

Gli endpoint di caricamento, download, firma e autenticazione hanno limiti di velocità per utente. I tentativi eccessivi vengono bloccati prima di raggiungere il database.

Ogni tabella del database ha la sicurezza a livello di riga (RLS) abilitata. I dati di un'organizzazione sono inaccessibili dalle query di un'altra organizzazione, anche se si utilizza la stessa istanza del database. Le chiavi di ruolo del servizio sono archiviate nella gestione dei segreti, mai nel codice dell'applicazione, e ruotate regolarmente. Gli URL dei file di archiviazione sono firmati con finestre di scadenza brevi e serviti tramite un proxy lato server — mai a lunga durata o indovinabili pubblicamente.

Ogni file caricato viene convalidato tramite magic bytes prima di essere archiviato. Un file che non sia un file DER/PKCS12 o PEM valido viene rifiutato. Non vengono mai archiviati file arbitrari mascherati da certificati.