Diseño de cifrado de archivos

1

Estoy construyendo una aplicación y un servidor. El servidor es una API node.js con un backend de Postgres.

Las imágenes creadas en la aplicación se almacenarán en Amazon S3. Los metadatos sobre los archivos se almacenarán en Postgres.

He acercado dos soluciones posibles para las claves de cifrado. Ambas involucran las amazonas URLs firmadas. Amazon genera estas URL como resultado de una llamada de mi servidor.

  1. Foto tomada en la aplicación
  2. Metadatos de archivos guardados en Postgres a través de mi API
  3. El servidor obtiene la URL previamente firmada de Amazon para cargar los archivos
  4. La URL se devuelve a la aplicación como resultado de la llamada en el paso 2.
  5. La aplicación utiliza la URL para publicar el archivo en Amazon S3

En cuanto al cifrado de archivos, puedo elegir utilizar el Servicio de administración de claves de Amazon (kms), es decir, Amazon genera y realiza un seguimiento de las claves de cifrado con sal individual para cada archivo. Mi servidor necesitaría usar la clave maestra para obtener las URL previamente firmadas generadas.

O podría elegir generar claves de cifrado individuales para cada archivo en mi servidor y almacenar estas claves con el resto de los metadatos en Postgres. Amazon todavía haría el cifrado / descifrado, pero yo pasaría cada clave individual en la solicitud de URL presignadas en lugar de pasar la clave maestra.

KMS, pro:

  • No hay claves de cifrado almacenadas con los metadatos del archivo en Postgres

KMS, con:

  • La clave maestra desbloquea todos los archivos en S3 (pero la clave maestra se puede rotar)

Claves personalizadas generadas, pro:

  • Es más fácil implementar una clave de usuario adicional con XOR: ingiriendo las claves. Si un cliente no confía en mi manejo de claves, podría agregar una clave adicional que solo existe en el dispositivo, probablemente en la cadena de claves de iOS.

Claves generadas personalizadas. con:

  • Si la base de datos de Postgres está comprometida, los archivos en S3 también podrían estar comprometidos.

Soy un programador, no un experto en seguridad. Si es necesario, consultaré a un experto, pero pensé que los expertos en este foro podrían darles más información primero.

Por supuesto, se han tomado otras medidas de seguridad. La aplicación solo habla con la API a través de HTTPS y la aplicación se autentica con la API (usando Oath2 y JWT).

Realmente me gusta el concepto de URL presignado, ya que esto permite que la aplicación no tenga ni idea de las claves necesarias para la carga / descarga de S3.

¿Debo usar kms o generar claves yo mismo?

¡Gracias!

    
pregunta Michael 31.05.2017 - 16:06
fuente

2 respuestas

2

Solo para resumir la discusión:

necesitas saber contra qué tipo de ataques quieres proteger las claves. Como comentamos, mencionó correctamente los pros y los contras de ambas soluciones.

Recomendé mezclarlos para que uses dos claves: KEK (clave de cifrado de clave) y DEK (clave de cifrado de datos). Tendrá solo un KEK y tantos DEK como datos almacenados en la base de datos.

Cuando vaya a almacenar los datos en la base de datos, generará DEK, cifrará los datos con DEK, cifrará el DEK con KEK y almacenará el DEK cifrado junto con los datos en la base de datos. Para la lectura, obtendrá datos y DEK encriptados de la base de datos, usará KEK para descifrar DEK y DEK para descifrar los datos.

Se supone que DEK se utiliza solo en la memoria de la aplicación. Nunca debe almacenarse sin cifrar en ningún otro lugar. Y debe ocuparse de su eliminación segura de la memoria inmediatamente una vez que no sea necesaria (es decir, volver a escribir el byte buffer con ceros y liberarlo, tenga cuidado con las cadenas, ya que generalmente son inmutables).

La forma correcta de almacenar y usar el KEK debe almacenarlo y usarlo dentro del HSM (KMS) para que nadie lo pueda revelar, ni siquiera los administradores del servidor / aplicación.

El lado oscuro es probablemente el precio de AWS KMS. Si lo almacena en la configuración, puede ser robado por el atacante y luego usarlo para descifrar el volcado de la base de datos. Pero ustedes, probablemente no están asegurando un sitio del ejército;)

También es necesario mencionar que si alguna vez necesitarás cambiar el KEK, tendrás que volver a cifrar todos los DEK almacenados en la base de datos.

    
respondido por el Fis 31.05.2017 - 16:57
fuente
0

Revisitado ... publicando una respuesta también.

Respuesta corta: iré con KMS.

Después de leer un poco más sobre KMS, en realidad parece que se ajusta muy bien a mis necesidades, y no es caro en absoluto. Ya usamos S3 para el almacenamiento de archivos y usaremos AWS para nuestro entorno de producción cuando estemos listos, por lo que es fácil agregar KMS a la configuración. También dejaré que KMS maneje otros secretos también, es decir, que no haya más archivos de configuración secretos.

Tenía miedo de que KMS lo hiciera más complicado, pero en realidad es muy fácil trabajar con él.

También tenía miedo del precio. Pensé que tendría un precio como un HSM, pero es mucho más barato.

Dejaré algunos enlaces aquí para que otros los encuentren, en caso de que estén en la misma situación que yo. Lamentablemente, no tengo la reputación suficiente para poder publicar más de dos enlaces, así que publicaré algunos de ellos sin el prefijo https: //.

Descripción general:

Precio:

Probablemente manejaré esto desde Node.js:

  • github.com/DavidTanner/nodecredstash

También es fácil de usar desde la línea de comandos:

  • github.com/fugue/credstash

Lectura esclarecedora si necesita información para principiantes como yo:

  1. blog.threatstack.com/cloud-security-best-practicesfinding-securing-managing-secrets-part-1

  2. blog.threatstack.com/cloud-security-best-practices-finding-securing-managing-secrets-part-2

respondido por el Michael 01.06.2017 - 09:47
fuente

Lea otras preguntas en las etiquetas