¿Cómo hacer un esquema / protocolo seguro de distribución de claves?

4

Estamos construyendo una plataforma de procesamiento de datos en Amazon AWS. Vamos a almacenar datos confidenciales en el S3 (cifrado) y luego se utilizará el nodo Amazon EC2 para procesar estos datos. Estamos planeando utilizar cifrado híbrido para los datos S3, es decir, mediante el uso de claves de cifrado de datos simétricas (DEK) & Claves de cifrado de claves asimétricas (KEK) & se hará en el lado del cliente antes de cargar los datos a S3. El DEK encriptado se almacenará con el objeto S3 en los metadatos. Van a ser un grupo de conjuntos de datos & Las claves serán diferentes para estos conjuntos de datos.

Estamos planeando construir un pequeño sistema KMS que pueda distribuir claves a los nodos EC2 cuando vayan a procesar los datos para descifrarlos. El KMS se alojará en nuestras instalaciones y la transferencia de las claves se realizará en VPN.

La pregunta que tenemos es sobre el protocolo de distribución de claves más adecuado para compilar y distribuir las claves a los nodos EC2. Estamos considerando la posibilidad de crear un servicio web que utilice REST / SSL para distribuir las claves. Sin embargo, dado que no hay especificaciones WS-Security disponibles para REST, creemos que solo REST / SSL no será suficiente.

  1. ¿Qué puede ser una implementación adicional para reforzar la seguridad?
  2. ¿Cuáles son las formas de autenticar / aprovisionar el nodo EC2 cuando llama al servicio web REST que hemos generado?
  3. Lo que es más adecuado: pasar DEK encriptado a webservice & descifrar DEK vs simplemente obtener KEK del servicio web & ¿Usándolo para descifrar DEK para descifrar los datos?
  4. ¿Algún punto adicional a considerar?
pregunta Deepesh M 02.02.2013 - 19:34
fuente

1 respuesta

4

Primero, no puede mover datos de manera segura a través de una red no confiable entre dos puntos finales no confiables. Para distribuir de forma segura cualquier cosa , ya sean claves o imágenes de Blu-Ray de 100 GB, necesitará una o dos cosas configuradas en cada punto final para establecer una confianza mutua inicial entre los dos:

  • Un secreto compartido (es decir, una contraseña o una clave compartida)
  • La mitad de un par de llaves asimétricas (es decir, un certificado de confianza)

Segundo, dices que estás usando una VPN. El objetivo principal de una VPN es transformar una red no confiable en una red confiable entre dos puntos finales ahora confiables. Si sus hosts se autentican automáticamente y se unen a la VPN, ya tienen un secreto compartido o un certificado de confianza.

Suponiendo que su VPN esté encriptada, sus datos ya estarán encriptados en tránsito entre su red y la red EC2. Si sus hosts EC2 pueden unirse a la VPN en el inicio, ya tienen suficiente información para identificarse como uno de sus hosts. Si no pueden, puede establecer confianza cuando un administrador haya conectado manualmente los hosts a la VPN.

Una vez que los puntos finales se autentican para unirse a su red de confianza, los hosts de EC2 pueden intercambiar certificados, estableciendo un enlace de confianza en todo momento. Esto es (sorta) cómo funciona Kerberos.

Tenga en cuenta que esto no protegerá sus datos contra:

  • Un insider malicioso, por ejemplo, uno de sus propios administradores de sistema o de red
  • Los programas que conservan el material clave en los hosts de EC2 más tiempo del que necesitan

Tercero, como mínimo absoluto, para su propia protección, su empresa querrá poder auditar todo el acceso a los materiales clave de una manera que esté protegida contra un atacante con acceso de raíz. Es posible que también deba auditar todo el acceso a los materiales cifrados en la base de datos. Piensa bien en lo que se necesitaría para implementar eso.

En cuarto lugar, proteger sus claves en reposo (contra un atacante que desea obtener root en su KMS o cualquiera de sus hosts EC2) es un problema completamente diferente, y es incluso más difícil de resolver que proteger las claves en tránsito entre dos hosts de confianza mutua. He estado involucrado en la implementación de una "isla de red PCI-DSS" en el pasado, y es un dolor enorme.

Recomiendo encarecidamente que su empresa contrate a un asesor de seguridad con experiencia en la configuración de sistemas de administración de claves distribuidas. El problema aquí no es solo los riesgos conocidos, las cosas que sabe que necesita para defenderse. - pero lo que Rumsfeld llamó "incógnitas desconocidas", corre el riesgo de que ni siquiera sepa que lo tiene.

Como desarrollador, no confiaría en mi capacidad para diseñar e implementar un sistema criptográfico completo sin el asesoramiento externo de un experto.

    
respondido por el Devin R 26.03.2013 - 14:53
fuente

Lea otras preguntas en las etiquetas