Come si registrano dati potenzialmente sensibili?

Sono piuttosto costernato per queste altre risposte. La procedura migliore consiste solo nel registrare ciò che è necessario registrare, quindi non l'intera richiesta e risposta.

Devi quindi considerare la legge sulla protezione dei dati. Ovviamente questo varia in base alla giurisdizione, ma generalmente segue gli stessi principi:

• Devi documentare ciò che stai facendo, perché e le precauzioni che prendi per proteggere i dati.

Troverai difficile giustificare una regola generale per tutto il registro. 'perché è facile' non conta come una buona ragione.

• Probabilmente avrai dovuto chiedere ai tuoi clienti il permesso di usare i loro dati per lo scopo che descrivi.

Anche se un "segno di spunta qui per accettare tutti i TnC" con "... usa i tuoi dati per mantenere il sistema .." potrebbe sembrare che ti coprano, questo è stato contestato in tribunale alcune volte. La realtà è che non lo saprai fino a quando non sarai citato in giudizio.

• Quindi probabilmente hai alcune classi di dati che devono essere crittografati.

• Quindi devi disporre di una politica sulla durata della conservazione dei dati e della relativa eliminazione.

La legge sulla protezione dei dati può essere stranamente severa su alcune cose e lassista sugli altri. Per esempio, ricordo un caso in cui le opzioni del pasto in volo erano tutte criptate perché avevi opzioni per halal, kosher ecc in modo che potessero rivelare potenzialmente la religione dei viaggiatori, che conta come dati personali sensibili.

Cose che non lo taglieranno.

Sanificazione dei log. Se anche una cosa scivola anche se sei fregato. Non a causa dei dati. A causa di tutta la documentazione che hai scritto, hai detto che non hai archiviato quei dati. E la roba scivolerà via.

Registrazione di tutto tranne che in un archivio crittografato. Non importa quanto sia sicuro perché la legge copre più di una semplice conservazione dei dati. Qualsiasi scenario in cui stai tenendo "tutto" verrà bloccato perché devi indicare lo scopo di mantenerlo.

******** modifica: modi suggeriti per risolvere bug senza registrazione ************

Quindi per le chiamate api con richieste malformate trovo il modo migliore per restituire un messaggio di errore. Non dovrebbe contenere alcun dato, ma dovrebbe indicare chiaramente e in modo univoco quale era l'errore.

es

BAD: errore - bob utente non può mangiare carne di maiale

GOOD: errore - codice pasto non consentito per questo utente

Assicurati di reinserire l'errore fino in fondo all'utente se il codice non può gestirlo. Bob sa di amare il maiale e telefonerà per segnalare l'errore. Inoltre, poiché non ci sono dati, puoi loggarlo senza problemi e controllare i modelli.

regola 2: test test di test. Scrivi quei test unitari ed eseguili continuamente. Quando Bob telefona e dice che non può ordinare la carne di maiale a causa di un bug, scrivi un test non funzionante prima di risolverlo in modo che tu sappia se accadrà di nuovo.

regola 3: controlli di integrità, se si dispone di una API o di un servizio, inserire un metodo di controllo sanitario su di esso. Hai monitorato il sistema colpire quel controllo di salute ogni pochi minuti per verificare che tutto sia a posto con il servizio, può ancora parlare con il DB che sta rispondendo prontamente alle richieste ecc.

Disinfetta il registro. La routine che registra le richieste API dovrebbe cercare ed essere in grado di riconoscere parametri sensibili come password e sostituirli con * s o simili, e quindi passare l'output censurato al normale logger.