¿No tiene sentido el cifrado completo del disco en un servidor en un centro de datos seguro?

Dos cosas genéricas que aparentemente has perdido:

• En caso de falla del disco, tener los datos cifrados en reposo resuelve el problema de tener datos potencialmente confidenciales en un medio al que ya no puede acceder. Hace que deshacerse de unidades defectuosas sea más fácil y más barato (y es un problema menos)

• El cifrado completo del disco también dificulta que un atacante recupere datos del espacio "vacío" en las unidades (que a menudo contiene un rastro de datos previamente válidos)

Y si estás usando máquinas virtuales:

• El cifrado de la partición lo hace menos dependiente de la seguridad de su hipervisor: si de alguna manera el contenido bruto de una de sus unidades se "filtra" a otra VM (lo que podría suceder si el espacio de la unidad se reasigna a otra VM y no se pone a cero) ), será menos probable que la VM tenga acceso a los datos reales (también necesitaría obtener la clave de descifrado).

Si la clave de descifrado se almacena de forma sencilla en los mismos medios que los datos cifrados, el cifrado no tiene sentido. Si tiene un conjunto de reglas, que requieren que los datos estén encriptados, pero permiten almacenar la clave en forma sencilla en el mismo medio, entonces las reglas son erróneas. Si alguna vez se enfrenta a un conjunto de reglas tan defectuoso, debe señalar la falla.

Si la clave no está almacenada en el mismo medio que los datos. Entonces el cifrado tiene un propósito. Sin embargo, eso plantea la pregunta sobre de dónde obtiene la clave el servidor durante el arranque. Hay algunas opciones:

• Requiere que se ingrese una contraseña durante el arranque. Esto no es muy práctico para un servidor.
• Obtenga la clave de descifrado de un servidor de claves. Esto puede evitar que los datos se descifren si el servidor fue robado, solo requiere que el servidor de claves solo responda a las solicitudes desde dentro del centro de datos.
• El secreto comparte la clave en varios discos. No hace nada por el caso donde el servidor es robado. Pero si tiene un RAID en el que los discos individuales se reemplazan ocasionalmente, garantiza que cualquier información que quede en los discos devueltos bajo la garantía se cifrará correctamente. Cuando se agrega un nuevo disco al RAID, una implementación de esta técnica tendría que hacer lo siguiente:
  • Genere una clave de cifrado para este disco individual.
  • Genera una nueva clave maestra.
  • El secreto comparte la nueva clave maestra en todos los discos.
  • En cada disco, escriba la clave de cifrado del disco cifrada bajo la nueva clave maestra.

Los tres enfoques descritos anteriormente se pueden combinar. Si se combinan, el servidor de claves podría implementarse utilizando un RSA ciego.

Hay ataques en el firmware de los discos duros. Buscar en Google para hard drive firmware attack devolverá algunos resultados sobre lo que la NSA hace o puede hacer, lo que probablemente no sea muy relevante para ti; Pero incluso los aficionados pueden modificar el firmware de las unidades. Este tipo incluso instaló un kernel de Linux en su disco duro. No, no fue la PC la que ejecutó Linux, el disco duro. el controlador mismo hizo eso.

Si alguien obtiene acceso al firmware de sus discos (por ejemplo, si alguien alquila un servidor de su centro de datos durante un mes, luego lo devuelve; la empresa del centro de datos borra las unidades y luego le asigna ese servidor), podrían hacer que el firmware de la unidad haga algo como "Siempre que un bloque que se escribe en el disco contenga un patrón especial, durante los siguientes 5 minutos, en cada bloque de lectura que comience con root:$1$ , reemplace los primeros bytes con (algún hash de contraseña)" , tienes un ataque que es casi indetectable. Su archivo /etc/shadow le parecerá normal, excepto durante el lapso de tiempo de 5 minutos después de que su atacante haya solicitado un archivo con un nombre que contenga el patrón de activación de su servidor web, que lo escribió en su registro de errores.

¿Es poco probable? Por supuesto. ¿Imposible? Definitivamente no. ¿Es paranoico asumir que esto podría suceder? Probablemente sí, dependiendo de lo interesantes que sean tus datos. Sin embargo, el cifrado de sus unidades lo protegerá de este tipo de ataque, y no le costará más que unos pocos ciclos de CPU. Y, si hay alguna ley o reglamento a seguir, en caso de una violación de seguridad, ciertamente no quiero estar en la posición de tener que explicar por qué pensé que no importaría.

Considere lo que quiere decir por centro de datos "seguro".

En general, no considero nada seguro contra un atacante determinado y con muchos recursos. Es cierto que tener 18 "de concreto reforzado, trampas dobles y seguridad armada proporciona una buena cantidad de protección, pero es raro que esta protección sea solo para usted. En la mayoría de las instalaciones de ubicación conjunta, lo único que lo protege de un Una persona con $ 500 y suficiente conocimiento para alquilar espacio en rack en las mismas instalaciones que usted es una jaula de alambre con un tambor de tres clavijas.

Ocasionalmente, los desastres naturales y provocados por el hombre inundan las cosas, reducen el suministro eléctrico, envenenan los suministros de agua y hacen todo tipo de cosas inusuales que hacen que los guardias de seguridad y los técnicos no se presenten al trabajo o simplemente vayan a casa con sus familias. Lo que digo es que los centros de datos solo brindan un nivel de seguridad que probablemente no sea tanto como piensan muchos de sus clientes.

Reconsidere su postura sobre el bajo riesgo de que su contratista de eliminación pierda unidades.

Un certificado de destrucción también le da derecho ... ¿los $ 20 que le pagaron para destruir una unidad que en realidad no se destruyó?

¿Ha visitado su instalación de eliminación de unidades? ¿Comprobado sus procedimientos de contratación? ¿Han visto sus salvaguardias? Asegúrate de que eres sólido en esto porque es una de las vulnerabilidades más obvias: un cambio en la custodia.

Entonces, eso no es en absoluto lo que preguntaste, ¿qué hay de la amenaza interna que realmente preguntaste?

Ok, un usuario interno tendría acceso a través de su FDE y vería los archivos sin cifrar. En su escenario de FDE, no hará nada para detener o ralentizar el acceso del informante a los datos.

Lo que hará es canalizar su amenaza interna para que pase por su FDE, lo que le permitiría registrar, monitorear e identificar a un culpable, o al menos a un sospechoso. Ser capaz de identificar a su atacante es una capa de seguridad.

Pero, estoy bastante seguro de que la canalización no es principalmente para lo que es FDE. Incluso si tiene FDE, aún puede implementar otro cifrado de datos u otro nivel de archivo sobre FDE. También puede seguir utilizando los controles de acceso del sistema operativo.

FDE protege contra información privilegiada que no tiene acceso a través de FDE. Protege a los técnicos de los servidores que reemplazan las unidades de disco, quitándolas con datos. Protege a un empleado de la instalación del servidor que recoge uno de un contenedor de envío en su instalación esperando el transporte a su contratista de destrucción.

FDE le permite otro nivel para detener las amenazas internas también, si segrega su granja de servidores o usa un acceso granular, por ejemplo, sus empleados solo tienen acceso a ciertos servidores, etc. FDE evitaría que simplemente copien unidades al por mayor que no tienen. No tengo acceso a través del FDE para.

En pocas palabras, FDE protege los datos en la unidad del acceso físico a la unidad. Puede intentar controlar el acceso físico todo lo que desee, pero las unidades siempre se encontrarán con alguna vulnerabilidad (robadas por personas con información privilegiada, copias por personas con información privilegiada, custodia en tránsito donde personas con información privilegiada la tocan, sin vigilancia debido a un desastre, etc.) ). Si la gente toca la unidad, FDE es una capa de defensa contra ella.

David

No es seguro. Depende de, contra lo que quieras defenderte. Algunos ejemplos:

• Si vive en un país, donde el gobierno puede confiscar su servidor para analizar su contenido y luego usarlo contra usted o su empleador.
• Si usted es el propietario del servidor, pero no le da la posibilidad de que sus empleados / colegas tengan acceso físico al mismo, que robaron / reflejaron su contenido. Luego, les habilita para que lo reparen / arranquen, pero no les da las claves de cifrado.
• Igual podría ser una protección eficaz si no puede / no quiere confiar en su solución de alojamiento de servidor.

Depende de las circunstancias. Estas circunstancias que muestro como ejemplo, son al menos infrecuentes en mi entorno, pero podrían ser posibles.

Si estás en un entorno de negocios normal, no lo hagas. Quitó muchas horas de trabajo y tiene un tiempo de servicio extendido. En mi opinión, en la mayoría de los casos no vale su precio.

Cita: "... han hecho poco o nada para reducir realmente el riesgo asociado con los datos sin cifrar ..."

Ok, sí, creo que tienes razón. La respuesta simple es "no tiene sentido", pero "tampoco es inútil". Por eso, y perdóname por decir esto, creo que puedes estar ladrando el árbol equivocado. Dejame explicar. El cifrado completo del disco (FDE) tiene algún propósito, incluso si es solo para un subconjunto de explotaciones que son de baja probabilidad. Hay una serie de posibles explotaciones, y la probabilidad BAJA no es igual a NO probabilidad.

Entonces, ¿es inútil? No completamente. ¿Pero por qué estás discutiendo contra eso? ¿Desea que se le preste más atención a la seguridad cuando los servidores se están ejecutando y los datos no están cifrados? Esto ingresa a la región donde los hechos pueden hacerte menos bien, y un sentido de la política puede serte de gran ayuda.

Podría ser que su objetivo en este argumento en el trabajo sea establecer su experiencia. O tal vez hay algo que crees que se necesita hacer, y nadie está prestando atención. Todo lo anterior es válido y razonable, y forma parte del entorno laboral cotidiano. Podría estar malinterpretando su pregunta, pero me parece que puede obtener un mejor resultado argumentando la acción que cree que debe realizarse, en lugar de una acción que se está realizando. Elige tus peleas.

Por su descripción, sospecho que es correcto. Es decir, el cifrado completo del disco no agrega ninguna protección real para sus datos en un servidor en ejecución si alguien compromete a ese servidor para extraer los datos. Esto no es lo que el cifrado de disco completo está diseñado para lograr. Sin embargo, esto no significa que no haya ningún caso para tener un cifrado completo del disco en un servidor. Como se señaló en otras publicaciones, existen buenas razones para tener el cifrado completo del disco en un servidor, como la protección contra el robo, el control efectivo de la eliminación del disco o la devolución de discos defectuosos al proveedor, etc. Sin embargo, si necesita proteger los datos en el servidor cuando se está ejecutando, normalmente necesitará cifrado de archivos, tablas, etc. además del cifrado del disco; no es necesariamente una situación de uno u otro.

La otra cosa a considerar es que la seguridad se trata de capas de protección. Al sugerir que tiene buenos controles para desechar los discos y, por lo tanto, no necesita un cifrado completo del disco, se supone que los controles que se usan para deshacerse de los discos nunca fallarán. Sin embargo, estos tipos de controles generalmente tienen un alto contenido humano y de procedimiento: dependen en gran medida del administrador que sigue el procedimiento correctamente. En mi experiencia, estos son los tipos de controles que tienen más probabilidades de fallar. Podría ser ese nuevo empleado que se olvida o no conoce el procedimiento, podría ser que un administrador de sistemas con experiencia se haya ocupado de un fallo de alta presión en el que el jefe lo esté presionando para que realice una copia de seguridad del servicio tan pronto como sea posible. simplemente otro control de protección que elimina parte de la presión del personal y reduce el posible impacto de un simple error humano.

Cuando las cosas van mal con el cifrado completo del disco es cuando las personas asumen que resuelven más problemas de los que realmente lo hacen, esto parece ser el impulso de su argumento / preocupación. He visto a muchos proveedores e incluso a administradores que convencen a la administración de que los datos están seguros simplemente porque utiliza el cifrado completo del disco. Como resultado, se realiza poco o ningún análisis de riesgo real con respecto a los riesgos cuando el servidor se está ejecutando. Hace poco realicé un gran proyecto de almacenamiento de datos para un cliente que involucraba datos potencialmente confidenciales y / o valiosos. Fue bastante sorprendente la cantidad de proveedores que no respondieron correctamente las preguntas de cifrado. Su respuesta original fue que "está bien, el sistema usa cifrado completo del disco". Una vez que indagué y di ejemplos y pregunté cómo protegería su encriptación de disco completa contra varios escenarios para un servidor en ejecución, su respuesta general fue "Oh, bueno, ese es un problema que la aplicación necesita resolver".

Para mí, el mayor problema que he encontrado con el cifrado de disco completo y el cifrado a nivel de archivo / tabla es la falta frecuente de cualquier consideración real con respecto a la administración de claves. Para mí, la mayoría de las soluciones parecen ser débiles en su soporte para permitir una administración de claves consistente y confiable. Muchas veces he visto un sistema en el que se me ha informado sobre el maravilloso uso del cifrado para proteger los datos, solo para encontrar que las claves utilizadas están mal protegidas, casi un pensamiento posterior. Peor aún, debido a la falta de un enfoque bueno o comprendido, se encuentra con centros de datos en los que se utiliza la misma clave en múltiples lugares o en múltiples niveles para que los administradores puedan gestionarlos de manera eficaz y puedan recuperarse cuando sea necesario.

Gracias a todos por los comentarios. En resumen, la pregunta del título, ¿no tiene sentido FDE para un servidor en un centro de datos seguro? La respuesta no es necesariamente ya que podría haber escenarios en los que uno quisiera la protección adicional en los dispositivos físicos. Por ejemplo, protección durante la destrucción, protección desde el país anfitrión o protección en caso de fallo del disco, entre otras situaciones.

En el texto, la pregunta se modificó un poco respecto de lo que se indica en el título. La preocupación en la pregunta principal era si los datos se comprometían no a través del acceso físico al servidor, sino al acceso lógico a los datos. Según las respuestas, parece que FDE no proporciona esta protección. La solución es transparente para el usuario donde los datos se descifran en el servidor al iniciar. En ese punto, uno depende de otros controles como los firewalls, la buena administración de acceso, la autenticación sólida y la aplicación de parches.

Mi preferencia es que, además de los controles para el cifrado a nivel de archivo o campo, se usen con acceso a las claves de cifrado restringidas para proporcionar una capa adicional de seguridad.

Una cosa que no vi mencionada es que he escuchado que FDE también puede brindar protección contra ciertos tipos de malware que podrían copiar la información mediante programación. Sin embargo, no he podido confirmar esta declaración a través de la investigación.

Aquí hay 2 ventajas más (suponiendo que utilice nuevas claves de cifrado cada vez que vuelva a instalar):

• Si ejecuta herramientas de recuperación de archivos que analizan el dispositivo de bloque completo, por ejemplo. PhotoRec, no tiene que revisar toneladas de archivos antiguos que ya no son de su interés.

• Si ejecuta herramientas de reparación del sistema de archivos que analizan el dispositivo de bloque completo, no corre el riesgo de confundir las estructuras y los metadatos de un sistema de archivos antiguo con el actual.

JJ