Alguien me dijo que su compañía está almacenando todos los datos de la aplicación (al menos los datos confidenciales, supongo) en la RAM por seguridad. Su aplicación se ejecuta durante largos períodos de tiempo, por lo que los datos permanecen en la memoria durante mucho tiempo.
¿Cómo es esto más seguro si lo mantiene en la RAM, en lugar de en el disco? ¿Es la RAM más difícil de acceder / explotar, o solo porque es volátil?
Mantener la información en la RAM puede mejorar la seguridad, si se hace correctamente y si los requisitos lo permiten. Voy a mostrar dos arquitecturas de seguridad en las que mantener los datos en la RAM proporciona un beneficio de seguridad. Estos son escenarios bastante específicos; la mayoría de las veces, mantener los datos en la RAM no ayuda.
Considere una aplicación web que manipula archivos en el servidor. Un tipo de vulnerabilidad que podría tener es permitir que los usuarios descarguen archivos que se supone que no deben exponerse de forma remota. Si una parte de los datos críticos solo se almacena en la memoria de algunos procesos (en este caso no es la RAM lo que es relevante, sino la memoria virtual en oposición al sistema de archivos), entonces no será revelada por una vulnerabilidad de exposición del archivo.
Por supuesto, los datos pueden revelarse a través de otras vulnerabilidades, por ejemplo, con una cadena de ataques que primero organiza la escritura de los datos confidenciales en un archivo (como un volcado de errores de algún tipo) y luego el archivo de volcado. expuesta.
Mantener los datos en la memoria solo ayuda si no se carga desde un archivo en primer lugar. ¿De dónde sacas los datos después del arranque? Los datos se pueden almacenar encriptados, pero eso requiere que alguien ingrese la clave de descifrado después de un reinicio; Esto no es bueno para la mayoría de las aplicaciones web, ya que no pueden permitirse el tiempo de inactividad. Los datos se pueden almacenar en un archivo que requiere privilegios adicionales que el servidor web no tiene: el proceso del servidor web comenzaría con privilegios elevados, leer el archivo y luego soltar privilegios. Esto eleva el estándar para un atacante, ya que tendrían que encontrar una vulnerabilidad de escalada de privilegios locales además de la vulnerabilidad remota que les daba una base. El beneficio sigue siendo pequeño porque muchos ataques que le dan al atacante acceso local sin privilegios también proporcionan una forma de inspeccionar la memoria de los procesos activos.
La información en la RAM desaparece si la RAM está apagada. Por lo tanto, si el atacante solo puede controlar el sistema de destino al apagarlo, tendrá más problemas para acceder a los datos si está solo en la memoria RAM. Sin embargo, almacenar los datos en la RAM no servirá de mucho por sí solo, ya que RAM tiene alguna remanencia de datos de De unos segundos a unos minutos. (Consulte también Recupere los contenidos anteriores de ¿RAM de una PC apagada? ). Esto es suficiente para reiniciar la computadora en un sistema operativo controlado por el atacante o para transferir las memorias RAM a otra computadora. (Consulte también ¿Hay volátiles? ¿Chips de memoria que no retienen datos después de apagarlos? )
El cifrado de los datos ayuda, pero tienes que almacenar la clave de cifrado en algún lugar. Y si va a cifrar los datos, puede hacerlo en un disco de todos modos. El cifrado de la mayoría de los datos confidenciales ayuda en que si el atacante tiene la mala suerte de perder la clave, los datos están seguros.
Entonces, para almacenar los datos en la memoria RAM para mejorar la seguridad, debe haber medidas de seguridad física adicionales. Si la memoria RAM está dentro de una caja a prueba de manipulaciones que hace que se apague la alimentación si se abre, podría ser suficiente para superar la remanencia de la memoria RAM. Para obtener mejores resultados, los intentos de manipulación deben hacer que la placa base ponga a cero la memoria RAM antes de apagar la alimentación (lo que significa que la placa base debe tener una batería pequeña). Encriptar los datos ayuda porque entonces solo es necesario poner a cero la clave, lo que lleva menos tiempo. Incluso si las medidas anti-manipulación pueden ser derrotadas con herramientas suficientemente buenas, hace que el ataque sea más difícil que un simple pase y arranque (un intruso con un cortador de pernos es más notable que un atacante con una placa de circuito dentro de una caja de teléfono móvil) ).
Yendo más allá, puede valer la pena cifrar la RAM y asegurarse de que la clave se mantenga en la caché del procesador o registros . El atacante normalmente tiene que reiniciar para intentar obtener la clave; reiniciar lo suficientemente rápido como para encontrar un caché prístino y sin obstruir el caché es más difícil, y desconectar la CPU es más difícil que desconectar la RAM.
Por supuesto, siempre existe el problema de dónde se cargan los datos (o si están cifrados, donde se almacena la clave). Algunos casos de uso valoran la confidencialidad sobre la disponibilidad y pueden permitirle a alguien que ingrese una clave después de cada reinicio (por ejemplo, un centro de datos grande puede tener a alguien disponible para hacerlo las 24 horas del día, en caso de que un intruso llegue tan lejos). Esta medida de seguridad también puede beneficiar a los sistemas que procesan datos pero no los almacenan.
Se sienten reconfortados por una falsa sensación de seguridad por la oscuridad
Si alguien obtiene acceso de root a su máquina, puede ver todos los contenidos de todo lo que cualquier aplicación pueda. El cifrado no ayudará si la aplicación tiene que poder trabajar con texto sin formato, ya que la aplicación tendrá que almacenar las claves en algún lugar. Ocultar esas claves es de donde viene la seguridad por oscuridad - eventualmente el intruso las encontrará y las copiará.
A pesar de lo anterior, tener todos los datos almacenados en la RAM proporciona una medida de seguridad física ya que la pérdida de potencia significa la pérdida de datos. Sin embargo, una vez que los datos están fuera de la memoria RAM y en un almacén persistente, por ejemplo, a través de una operación de intercambio de memoria, todas las apuestas están desactivadas. Además, cualquier centro de datos que valga la pena tendrá un sólido plan de seguridad física en su lugar que está asegurado contra los robos, por lo que es inútil.
Por supuesto, mantener los datos en la RAM para un acceso rápido por razones de rendimiento es completamente válido, simplemente no creas que la seguridad se haya mejorado de alguna manera como resultado.
Es un poco más difícil, ya que desaparece cuando se apaga la máquina. Requiere que alguien tenga acceso a la máquina cuando está funcionando, en lugar de simplemente robar el disco duro / computadora portátil.
Dicho esto, la memoria debe llenarse desde en algún lugar . Si esa es una máquina remota, entonces ha abierto esa vía de ataque que generalmente es más arriesgada que mantener los datos en el disco en la mayoría de los escenarios.
La memoria puede ser más difícil de recuperar información confidencial de un disco, pero la posibilidad aún existe. Si los datos no están también encriptados, entonces se pueden comprometer. Recientemente hemos buscado cadenas seguras en PowerShell por este motivo. Sí, debe ser texto sin formato en algún momento, pero no mientras se espera su uso. Los datos de la RAM se pueden recuperar de un volcado forzado forzado, y solo porque esté en la RAM no significa que nunca se introduzca en el disco durante una operación de paginación.
Me sorprende que nadie haya señalado el peligro de los archivos principales. La mayoría de las variantes de Unix o Linux escribirán de manera útil un archivo "núcleo" en el disco cuando un proceso falla. El archivo principal generalmente contiene los contenidos de RAM de ese proceso en el momento del fallo, de modo que puede intentar encontrar qué datos o condiciones causan el problema. Más tarde, un usuario con los privilegios adecuados puede acceder a este archivo y buscar los restos de los datos que el proceso muerto guardó una vez en la memoria. Solo por esta razón, diría que los datos guardados en la memoria no son realmente más seguros que los datos almacenados en el disco. ¿Alguien tiene algo que añadir sobre esto?
Creo que esto es sobre todo tonto. Si un atacante puede acceder a los datos en su disco duro, es casi seguro que también tendrán acceso a su memoria (y viceversa ). Independientemente de dónde vivan los datos, es necesario cifrarlos. Esa es la verdadera solución a este problema.
Además, mantener todos sus datos en la memoria puede tener algunos efectos secundarios negativos en su aplicación (aumento de memoria, código más complicado, etc.) Esta no es la forma "correcta" de resolver el problema.
Lo que puede ayudar es que las nuevas tecnologías de encriptación de memoria, como el SGX de Intel y el SEV de AMD, se basen en una raíz de confianza del hardware. En el caso de Intel SGX, los datos de una aplicación se cifran en la memoria mediante una clave a la que solo puede acceder la CPU, y se pueden anclar a un código específico, de manera que ninguna otra aplicación (ni siquiera un usuario root) podría acceder los datos. Además, es posible cifrar los datos almacenados (en reposo) utilizando una clave específica de la CPU, lo que evita algunos de los ataques mencionados anteriormente.
Lea otras preguntas en las etiquetas attack-prevention storage confidentiality memory