top of page

IL PROGETTO (seconda parte)

andreamorselli

Ci eravamo lasciati con la costatazione che IL PROGETTO fosse tutt'altro che facile e che ci troviamo con un sistema in grado di gestire i token che dovremo consegnare ai colleghi per applicare le firme elettroniche ai vari documenti.

Voglio fare una piccola digressione, quando parlo di firma elettronica, molti di voi penseranno subito al sistema di firma elettronica rilasciata dalle varie entità pubbliche, come le camere di commercio o quelle società autorizzate a rilasciare marche temporali. La nostra necessità non quella di garantire la data e l'ora di una determinata firma nei confronti con un ente pubblico, ma verso un ente certificatore, il quale si "accontenta" di avere un sistema in grado di creare record in una data certificata anche "solo" da un server aziendale, a patto che anche quest'ultimo sia stato validato in conformità con quanto richiesto da FDA.

Come dicevamo, ora abbiamo un sistema in grado di gestire I token da utilizzare per l'applicazione della firma, questo è reso possibile perché il sistema sviluppato è composto da:

• Un sistema che rilascia il token associandolo ad un utente di AD

• Associa all'utente di AD un documento di riconoscimento

• Gestisce la sostituzione di un eventuale token smarrito o guasto

• Gestisce l'archiviazione di un token nel momento in cui un utente lascia l'azienda.

Ovviamente il sistema descritto sopra, sarà parte della validazione di tutto quello che stiamo chiamando IL PROGETTO, di cui il vero nome è e-DHR che sta per Electronic Device History Record, cioè una specie di "libretto di circolazione" che segue ogni singolo lotto di materiale prodotto e rilasciato dalla qualità, dopo averlo ritenuto conforme per la vendita.

A questo punto, per validare il sistema dobbiamo garantire che nel caso in cui un record venisse modificato, questo venga evidenziato tramite un sistema di reportistica "audit Trail", in pratica come funziona tutto questo?

Tutti I dati vengono salvati all'interno di un database relazionale, all'interno del quale troviamo n tabelle, ogni tabella contiene un minimo di 3 campi. I campi in questione sono due campi ID uno auto incrementale e due interi, uno dei quali conterrà eventualmente si trattasse di una modifica l'id del record modificato, l'ultimo campo intero conterrà l'MD5 creato passando come argomenti tutti quei campi ritenuti sensibili, oltre ovviamente all'iD.

Ovviamente non contenti di quanto il sistema sia diventato complicato, volendo seguire I nostri comandamenti, dobbiamo sviluppare un sistema in grado di firmare e quindi sostituire il maggior numero di documenti/file, cosi abbiamo deciso di costruire un sistema di tabelle , anch’esse validate, dove viene specificato per ogni tabella, quali sono I campi da includere all'interno del campo MD5 il quale conterrà il valore calcolato passando alla funzione I campi specificati nelle apposite tabelle di configurazione.

Penso che anche per questo post vi abbia dato diverse informazioni, tutt'altro che facili da metabolizzare, sappiate che IL PROGETTO, non è ancora iniziato.

Siamo ancora solo all'inizio….



9 visualizzazioni0 commenti

Post recenti

Mostra tutti

Comments


andreamorselli.blog

  • alt.text.label.LinkedIn

©2023 by andreamorselli.blog. Orgogliosamente creato con Wix.com

bottom of page