Estoy tratando de aplicar el principio de que los datos son tóxicos activo en un sistema con muchos servicios a través de los cuales debe fluir este activo tóxico.
El sistema se puede resumir en 3 actores: clientes, intermediarios y fuentes (de datos). Los clientes eventualmente desearán ver algunos datos confidenciales (como los números de tarjetas de crédito o información de PI) que se encuentran en una fuente de datos segura. Los intermediarios son los servicios entre el cliente y la fuente, por lo que deben entrar en contacto con esta información confidencial, que es el problema en su totalidad.
Para los fines de este esquema, quiero asumir que el cliente y la fuente son seguros (no son vulnerables a XSS, inyección, etc.). Mi objetivo es diseñar un esquema que mitigue la amenaza de exponer datos confidenciales de servicios intermediarios. El método de exposición podría ser cualquier cosa, pero puede incluir empleados descontentos que indagan en busca de números de tarjetas de crédito, o que el servicio los registre accidentalmente en lugares a los que puedan acceder administradores no privilegiados.
Existe un requisito adicional de que el intermediario pueda reestructurar los datos (de lo contrario, no tendría ningún sentido tener un intermediario en el medio). Por ejemplo, imagine que la siguiente carga útil proviene de una fuente:
{"credit cards": [
{
"type": "visa",
"number": "1234-5678-9012-3456",
"expiry": "10-10-2020"
}]}
El intermediario, por ejemplo, un servidor web de representación HTML, puede desear insertar este número de tarjeta de crédito en una parte específica de su respuesta HTML al cliente.
Mi primera pregunta es ¿existe alguna solución para proteger los datos confidenciales que deben fluir a través de una red de microservicios desde esos servicios?
Parece que, dada la naturaleza de los datos confidenciales, es necesario que tenga cuidado de asegurarse de que los servicios que lo manejan sean "bastante" seguros. Esto hace que los datos no solo sean un activo tóxico, sino también infecciosos: a medida que los datos confidenciales proliferan a través de una red de microservicios, todos deben hacerse a prueba de balas.
Creo que he encontrado una forma sensata de resolver este problema; sin embargo, dada la constante seguridad de que no debería, bajo ninguna circunstancia, lanzar mi propio sistema criptográfico . Tengo menos confianza en utilizar una solución casera.
Esto es lo que he encontrado:
En nuestra arquitectura, usamos JWT para administrar las sesiones de los usuarios, por lo que esto nos da la capacidad de transmitir información adicional junto con el token de sesión del usuario a través del sistema, con alguna garantía de que nadie lo ha manipulado.
Mi solución es que el cliente genere un par de llaves público / privado, y tenga su clave pública incluida en su JWT cuando inicie sesión. Los clientes enviarán el JWT (con su clave pública personal) a través de una red de intermediarios donde finalmente terminará en una fuente de datos.
Desde allí, simplemente haga que la fuente de datos se cifre, por campo , aquellos campos que se consideran "sensibles" o especialmente tóxicos. Entonces, del ejemplo anterior:
{"credit cards": [
{
"type": "visa",
"number": "hQEMAwbqkJO6To1iAQf/UHf9ymLR8ejY/A1KouFCGoh9gBE71JgiAuQq5CMkuO7XLViDyf941dTUG==",
"expiry": "10-10-2020"
}]}
Por lo tanto, el intermediario es libre de incrustar el campo number donde quiera, y nunca tendrá acceso al valor original ya que no tiene acceso a la clave privada del usuario.
Por supuesto, el cliente tendrá que ser lo suficientemente inteligente como para descifrar el campo usando su clave privada una vez que el intermediario lo coloque en un lugar arbitrario en su propia respuesta.
Mi segunda pregunta es, por lo tanto, ¿parece esto un esquema sensato para negar la calidad "infecciosa" de los datos tóxicos?
Por supuesto, I no veo ningún punto de vulnerabilidad que vaya más allá de los ataques estándar contra los algoritmos de cifrado y descifrado que elegimos usar, pero esa es una de las razones por las que uno no debe rodar. su propio criptosistema :)
¡Gracias por aguantar la lectura larga si has llegado hasta aquí!