Come si gestisce in sicurezza la coda di firme elettroniche in blocco?

Come mantenere sicura una coda di firme elettroniche in blocco?

Fissare ogni lavoro di firma con digest del documento, versione, firmatario e chiave di operazione univoca; verificare l'autorizzazione al momento del consumo, deduplicare i ripetuti e conteggiare come successo solo l'output verificato.

Quando il carico aumenta, l'obiettivo non è soltanto accelerare la coda. Serve una macchina a stati che impedisca la doppia firma dello stesso documento, l'avanzamento di un PDF modificato con un'approvazione precedente, la permanenza di un errore temporaneo del servizio come successo duraturo e la disconnessione della prova di firma dal record operativo.

Con quale identità il lavoro di firma deve essere preso in coda?

L'identità del lavoro deve basarsi non solo sul nome file, ma su identità del documento, versione immutabile, digest crittografico, identità del firmatario, politica di firma e tipo di operazione prevista.

L'attuale pagina del BTK che illustra il quadro della Legge n. 5070 indica che la firma elettronica sicura consente di rilevare modifiche successive sui dati firmati. Anche il contenuto delle FAQ tecniche del BTK spiega i limiti della visibilità dei dati da firmare da parte del firmatario prima della firma e del divieto di estrazione dei dati di generazione della firma dallo strumento. La conseguenza per la progettazione della coda è netta: se il PDF viene rigenerato dopo che l'utente ha approvato una versione, lo stesso lavoro non deve proseguire; occorre aprire una nuova approvazione con un nuovo digest. [1] [2]

Quali stati devono essere distinti in coda?

La terna «in attesa, riuscito, fallito» è insufficiente; accettazione, precontrollo, approvazione umana, firma, verifica, archiviazione e stato di revisione devono essere separati.

1. Accettato: Documento sorgente, versione, digest e chiave di idempotenza vengono registrati atomicamente.
2. Precontrollo: Vengono verificati accesso al documento, formato, titolarità, ruolo del firmatario, selezione del certificato e conformità alla politica.
3. In attesa di approvazione: Il firmatario visualizza la versione corretta del documento da firmare e dà l'approvazione per l'operazione specifica.
4. In firma: Il worker acquisisce l'incarico con un blocco di breve durata; anche se il blocco scade, il registro di idempotenza previene un secondo effetto collaterale.
5. In verifica: La firma generata viene verificata tecnicamente nel contesto del documento firmato e del certificato.
6. Archiviato: L'output firmato, l'esito della verifica, la prova della marcatura temporale e il tracciamento delle operazioni sono conservati nello stesso legame di record.
7. Revisione necessaria: Verifica ambigua, errore permanente o contraddizione vengono assegnati a un responsabile autorizzato senza convertirli in successo automatico.

La guida OWASP sull'autorizzazione delle operazioni raccomanda di proteggere sul server i dati significativi dell'operazione, eseguire i passaggi in sequenza e adottare un legame di autorizzazione univoco per ogni operazione. Ciò significa che il consumatore della coda non deve fidarsi di un campo «approvato» proveniente dal browser, ma deve riverificare digest del documento, autorizzazione e transizione di stato dal registro del server. [5]

Come eseguire i nuovi tentativi senza produrre firme duplicate?

Ritentare solo gli errori temporanei in modo limitato e ritardato; collegare ogni tentativo alla stessa chiave di idempotenza e registrare atomicamente l'esito della firma esterna.

La guida OWASP Business Logic Security raccomanda di conservare transazionalmente la chiave di idempotenza insieme all'esito per le chiamate esterne e di cambio di stato. Se la connessione di rete si interrompe dopo che il worker ha inviato la richiesta al servizio di firma, l'assunzione «nessuna risposta, operazione non avvenuta» è pericolosa. Occorre prima interrogare l'esito registrato o l'identificativo di operazione del fornitore con la stessa chiave di lavoro; solo se è dimostrato che l'operazione non si è verificata, si deve rinviare. [4]

Classificare gli errori: l'interruzione di connessione di breve durata e il sovraccarico temporaneo dichiarato esplicitamente dal servizio sono ritentabili; utente non autorizzato, digest del documento modificato, selezione di certificato non valida o verifica fallita non devono essere ripetuti automaticamente. I tentativi ritardati possono usare attesa crescente e scostamento casuale; tuttavia il numero di tentativi e la durata complessiva vanno determinati secondo l'obiettivo di servizio e la valutazione del rischio dell'organizzazione, senza dichiarare numeri universali privi di fonte.

Quando un lavoro si considera davvero riuscito?

La creazione del file firmato non è di per sé un successo; valore della firma, legame con il documento, certificato di firma, politica di verifica ed eventualmente esito della marcatura temporale vanno registrati insieme.

ETSI EN 319 102-1 V1.4.1 definisce gli input e gli esiti dei processi di generazione e verifica AdES; mostra che nell'esito di verifica gli stati riuscito, fallito e ambiguo non coincidono. Nel flusso di lavoro VizyonTech il worker non deve chiudere il lavoro solo perché il file è stato scritto; deve conservare la regola di verifica usata e il suo esito e spostare gli esiti falliti o ambigui nella coda di revisione. [3]

RFC 3161 definisce la marcatura temporale come protocollo richiesta-risposta che fornisce la prova dell'esistenza di un dato prima di un determinato istante. Pertanto, se la marcatura temporale è richiesta, non va conservato solo un registro «richiesta»; message imprint, stato della risposta, token restituito ed esito della verifica vanno collegati allo stesso lavoro di firma. Un nonce o un digest del documento non corrispondente, una risposta ritardata o una richiesta respinta non devono considerarsi successo. [6]

L'esigenza di verifica a lungo termine dipende da formato, politica e durata di conservazione. Invece di presupporre lo stesso profilo di archiviazione per ogni firma, la procedura dell'organizzazione e i criteri tecnici vigenti vanno applicati come politica versionata.

Come proteggere sistema e firmatario in condizioni di carico?

Quando il tasso di accettazione supera la capacità di firma, non accumulare lavori illimitati; applicare quote per cliente/organizzazione, priorità, backpressure e metriche visibili di invecchiamento.

• Capacità equa: Il pacchetto voluminoso di un singolo cliente non deve trattenere indefinitamente i lavori delle altre organizzazioni; i limiti per tenant e priorità devono essere espliciti.
• Backpressure: Quando la coda raggiunge la soglia operativa definita, l'accettazione di nuovi pacchetti va rallentata o programmata.
• Visibilità della durata dei lavori: La media da sola non basta; il lavoro in attesa più vecchio, l'età per stato, il numero di tentativi e la coda di revisione vanno monitorati separatamente.
• Blocco breve, registro permanente: Il blocco del worker è temporaneo; identità del lavoro, storico dei tentativi ed esito devono essere permanenti.
• Osservazione sicura: Nei log non devono comparire contenuto del documento, dati di accesso, PIN, chiave privata o dati personali superflui.
• Annullamento controllato: Un lavoro non ancora firmato può essere annullato; se la firma è stata generata, la decisione su stato e distribuzione passa a una revisione autorizzata senza eliminare l'output.

Quali scenari vanno testati prima della messa in produzione?

Non solo il flusso di successo: eseguire con prova il crash del worker, il timeout, la doppia consegna, la modifica del documento, la perdita di autorizzazione e gli scenari di verifica ambigua.

• Quando la stessa chiave di idempotenza arriva con due richieste simultanee, si produce un solo output di firma?
• Quando la chiamata di firma si conclude ma la risposta va persa, il nuovo tentativo ritrova l'esito registrato?
• Se il documento cambia dopo l'approvazione, il controllo del digest arresta il lavoro e richiede una nuova approvazione?
• Se il ruolo o lo stato del certificato del firmatario cambiano durante l'attesa, il consumatore li rivaluta?
• Quando l'esito della verifica è ambiguo, il sistema non invia la notifica di consegna riuscita?
• Il lavoro nella coda degli errori può essere riavviato da un responsabile autorizzato conservandone causa e tentativi precedenti?
• Il record di archivio riesce a mostrare output firmato, esito della verifica, marcatura temporale e tracciamento delle operazioni sotto la stessa versione?

Come VizyonTech gestisce questo flusso?

VizyonTech configura tutte le fasi, dalla produzione dei rapporti all’approvazione umana, dalla coda di firma elettronica alla verifica e all’archiviazione, insieme ai ruoli, alle versioni dei documenti e alle regole sulle eccezioni dell’organizzazione.

Nella progettazione della firma in blocco perimetriamo prima i tipi di documento reali, i ruoli dei firmatari, la politica di certificati e marcatura temporale, gli scenari di interruzione del servizio e i canali di consegna. Poi validiamo l'identità univoca del lavoro, le transizioni di stato permesse, il comportamento dei nuovi tentativi, la coda di revisione e le misure operative visibili in un flusso documentale pilota.

Come correggere successivamente un rapporto firmato nella guida alla revisione del rapporto e firmato, mentre per come l'utente finale controlla l'output aggiornato nella guida alla pagina di verifica dei rapporti trattiamo l'argomento. Per pianificare un pilota sicuro in base al volume documentale e agli scenari di errore della Sua organizzazione potete contattare VizyonTech.