Sto cercando di applicare il principio che i dati sono tossici asset in un sistema con molti servizi attraverso i quali questo asset tossico deve fluire.
Il sistema può essere astratto a 3 attori: clienti, intermediari e fonti (dati). I clienti vorranno eventualmente visualizzare alcuni dati sensibili (si pensi ai numeri delle carte di credito o alle informazioni PI) che si trovano in un'origine dati protetta. Gli intermediari sono i servizi tra il cliente e la fonte, e quindi devono entrare in contatto con questi dati sensibili, che è l'intero problema.
Ai fini di questo schema, voglio presumere che il client e la fonte siano sicuri (non vulnerabili a XSS, injection, ecc.). Il mio obiettivo è progettare uno schema che mitigherà la minaccia di esporre i dati sensibili dai servizi di intermediazione. Il metodo di esposizione potrebbe essere qualsiasi cosa, ma potrebbe includere impiegati insoddisfatti per il numero di carte di credito, oppure il servizio accedendo accidentalmente a luoghi a cui gli amministratori non privilegiati possono accedere.
C'è un ulteriore requisito che l'intermediario possa ristrutturare i dati (altrimenti non avrebbe senso avere un intermediario nel mezzo). Ad esempio, immagina il seguente carico utile proveniente da una fonte:
{"credit cards": [
{
"type": "visa",
"number": "1234-5678-9012-3456",
"expiry": "10-10-2020"
}]}
L'intermediario, ad esempio un server web di rendering HTML, potrebbe voler incorporare questo numero di carta di credito in una parte specifica della sua risposta HTML al client.
La mia prima domanda è esiste una soluzione per proteggere i dati sensibili che devono scorrere attraverso una rete di microservizi da quei servizi stessi?
Sembra che, data la natura dei dati sensibili, sarebbe necessario fare attenzione a garantire che tutti i servizi che lo gestiscono siano "abbastanza" sicuri. Questo rende i dati non solo una risorsa tossica, ma anche infettiva: poiché i dati sensibili prolifiano attraverso una rete di micro-servizi, tutti devono essere resi a prova di proiettile.
Penso di aver trovato un modo corretto per risolvere questo problema; tuttavia, data la costante rassicurazione che non dovrei, in nessuna circostanza, rotolare il mio criptosistema , sono meno che sicuro di andare con una soluzione casalinga.
Ecco cosa ho scoperto:
Nella nostra architettura, utilizziamo le JWT per gestire le sessioni degli utenti, e quindi questo ci dà la possibilità di trasmettere informazioni aggiuntive insieme al token di sessione dell'utente attraverso il sistema, con la garanzia che nessuno l'ha manomesso.
La mia soluzione è che il cliente generi una coppia di chiavi privata / pubblica e che la sua chiave pubblica sia inclusa nel proprio JWT al momento dell'accesso. I clienti invieranno il JWT (con la loro chiave pubblica personale) attraverso una rete di intermediari dove finirà in una fonte di dati.
Da lì, devi semplicemente crittografare il sorgente dati - su base per campo - quei campi che sono considerati "sensibili" o particolarmente tossici. Quindi, dall'esempio precedente:
{"credit cards": [
{
"type": "visa",
"number": "hQEMAwbqkJO6To1iAQf/UHf9ymLR8ejY/A1KouFCGoh9gBE71JgiAuQq5CMkuO7XLViDyf941dTUG==",
"expiry": "10-10-2020"
}]}
L'intermediario è quindi libero di incorporare il campo number dove preferisce e non avrà mai accesso al valore originale poiché non ha accesso alla chiave privata dell'utente.
Naturalmente, il client dovrà essere abbastanza intelligente da decodificare il campo utilizzando la sua chiave privata una volta che l'intermediario lo ha inserito in una posizione arbitraria nella propria risposta.
La mia seconda domanda è quindi, questo sembra uno schema sano per negare la qualità "infettiva" dei dati tossici?
Naturalmente, I non vedo alcun punto di vulnerabilità al di sopra e al di là degli attacchi standard contro gli algoritmi di crittografia e decrittografia che scegliamo di usare, ma questo è un po 'il motivo per cui non si deve rotolare il loro proprio cryptosystem:)
Grazie per aver sopportato la lunga lettura se ce l'hai fatta fino ad ora!