¿No es aconsejable utilizar Redis para almacenar PII, claves privadas y otros secretos?

Question

¿No es aconsejable utilizar Redis para almacenar PII, claves privadas y otros secretos?

#1 de Lucas Kauffman (5 votos)

8

Estoy revisando un sistema que usa Redis para almacenar todos los secretos del cliente, las claves privadas y otras cosas. El problema es que Redis carga toda la base de datos en la RAM

Debido a que se sabe que heartbleed de SSL, Rowhammer y otros hacks exponen la memoria a usuarios no confiables, creo que cualquier otro hack similar podría exponer el Toda la base de datos, en la que si utilizara el servidor SQL, habría menos claves privadas en la RAM en un momento dado.

Probablemente hay una mejor manera de hacer esto.

Como se requiere que alojen y almacenen los secretos del cliente y PI, quiero que utilicen un enfoque de carga bajo demanda y que no carguen de manera demasiado agresiva los datos innecesarios en la RAM, y que descarguen lo que tengo en la RAM lo antes posible.

Si me suscribo a la filosofía de que ...

Mis datos están a salvo del ataque cuando hay menos copias por ahí

... entonces, ¿cuál es el mejor enfoque para reducir la exposición en la RAM? SecureErasing de la memoria?

Estoy viendo SecureString con ASP.NET y DiskIO , pero me cuesta mucho encontrar un Implementación de extremo a extremo que no deja copias innecesarias de la cadena en controladores, colas de búsqueda previa u otras ubicaciones.

privacy tls asp.net threat-mitigation memory

pregunta random65537 22.03.2015 - 13:43

fuente

1 respuesta

Lea otras preguntas en las etiquetas privacy tls asp.net threat-mitigation memory

Instalando una CA solo para dominios específicos ¿Por qué es difícil evitar que los revendedores usen bots para comprar muchas entradas para conciertos?

score 5 · Answer 1

El riesgo / problema es exactamente el mismo y la mitigación también. Independientemente de si carga la base de datos parcial o completamente en la memoria. No habrá manera de que usted sepa qué claves se han comprometido y cuáles no. Por lo tanto, la única opción sería revocarlos todos, independientemente de si se trata de una base de datos Redis o SQL.

La mayoría de las veces, la razón por la que las personas usan Redis vs SQL es debido a problemas de rendimiento. Creo que la probabilidad de un ataque tan exitoso es bastante baja si tiene un diseño decente y evita la exposición directa de su servidor de base de datos. Si ya lo han implementado, la inversión para solucionarlo por un lado será excelente si se considera que la mitad del código base requerirá actualizaciones. Creo que debería considerar aislar el clúster de Redis, monitorear todas las operaciones (registros SIEM), ver si puede implementar controles adicionales (comportamiento anómalo) y verificar su plan de respuesta a incidentes en caso de incumplimiento, en lugar de rechazar su solución.