2011-02-01 12 views
6

Estoy utilizando NServiceBus con MSMQ entre mi aplicación web y el servicio y necesito poder encriptar la carga útil del mensaje para que si un mensaje se pone en cola localmente en el servidor web (el host del servicio está inactivo) no se puedan visto.¿Dónde colocas una clave de cifrado en un servidor público?

Como el servidor web es público, no solo estoy obligado a cifrar datos que pueden ser serializados en el disco de todos modos, sino que tampoco puedo almacenar la clave de cifrado en el servidor web.

He considerado el uso de DPAPI para almacenar la clave, pero dado que la clave se almacenará en el host, no sé si eso entra en conflicto con el requisito o no. La otra opción que he considerado es que cuando se inicia la aplicación web, podría solicitar la clave de un servicio y mantenerla en la memoria durante la vida del grupo de aplicaciones.

No he tenido que trabajar antes con este nivel de requisitos de cifrado y me gustaría saber qué hacen los demás y obtener comentarios sobre las ideas mencionadas anteriormente.

+4

Hagas lo que hagas, contrata a un consultor de seguridad para verificar la eficacia de tu diseño/implementación. Si no es un experto en este campo, es trivialmente fácil cometer un error y los costos de ese error podrían ser enormes en comparación con los costos de pagarle a alguien para ayudarlo a hacerlo bien. cf. Sistemas de pago Heartland. – jason

+1

Esto no me parece un problema que resuelve la criptografía asimétrica. – rook

+0

La clave asimétrica al menos reduciría la probabilidad de que un observador lea el estado existente del disco. Aunque con la llave asimétrica en la mano, un observador podría usar eso para comenzar un ataque de fuerza bruta. – stephbu

Respuesta

0

Puede reemplazar la fuente de donde saca su NServiceBus clave de cifrado - esto se describe en los documentos aquí: http://docs.particular.net/nservicebus/security/encryption

De esta manera, se puede evitar que esta información sensible residen fuera de la zona de distensión.

+0

Gracias! No sabía que era una opción. Después de conversar con nuestro director de seguridad, solicitaremos la clave de un servidor no público y la almacenaremos en la memoria. –

7

¿Se puede utilizar el cifrado de clave pública/privada? Entonces solo necesita la clave pública en el servidor, y los datos se descifrarán utilizando la clave privada en otro lugar.

+0

Vale la pena señalar que el cifrado público-privado puede requerir una gran cantidad de entropía criptográficamente segura (para las claves de mensaje, IV y relleno); esto puede ser un problema con altos rendimientos. – bdonlan

+0

Sí, estoy de acuerdo, las claves asimétricas serían de gran ayuda.Para lograr una encriptación lo suficientemente robusta podría tomar una gran potencia en un sistema de alto rendimiento. En uno de nuestros escenarios recurrimos al hardware criptográfico: costoso, difícil de integrar, valió la pena aunque. – stephbu

+0

suena genial, pero no estoy seguro de que pueda aprobar el costo. Como dijo sin hardware dedicado, el cifrado asimétrico ahogaría el rendimiento. Consideré usar asimétrico solo para la clave, pero la clave para descifrar la clave aún tendría que almacenarse donde la aplicación web podría acceder. –

0

El mejor lugar para encrypt is at the queue level. Haga esto por sending private messages y cree colas que solo acepten mensajes privados. Si bien puede establecer el nivel de privacidad de la cola cuando crea la cola en el momento de la creación, no estoy seguro si puede configurar NServiceBus para enviar mensajes privados.

+0

Sí, he visto esto, pero de acuerdo con los documentos en sus enlaces: "Cuando se envían mensajes privados, Message Queue Server garantiza que el cuerpo de los mensajes se mantenga cifrado desde el momento en que abandonan el gestor de colas de origen hasta el momento llegan a su administrador de colas de destino ". Necesito el mensaje cifrado mientras está en la cola también y MSMQ no parece apoyar esto de forma nativa. –

1

"Como el servidor web es público, no solo estoy obligado a cifrar datos que pueden ser serializados en el disco de todos modos, sino que tampoco puedo almacenar la clave de cifrado en el servidor web".

Parece que esta es la única restricción para enfocarse - validar que es cierto para los principiantes. Se descartarán los enfoques de DPAPI + tienda de clave local.

Es plausible entregar la llave por servicio, pero ese servicio aún tiene que autenticar a la persona que llama. Si su servidor está enmascarado como una persona que llama legítimamente, es posible observar la llamada, etc. Además, si almacenó la clave solo en la memoria, esa memoria aún se puede detectar en un depurador o volcado de memoria, proceso de privilegio elevado, etc.

Las tarjetas de cifrado de hardware son la única forma de superar estos últimos escenarios.

+0

Creo que tiene razón sobre la entrega de la llave por servicio. Si bien me dijeron que no podemos almacenar la clave en el servidor web, dudo que obtenga la aprobación para una tarjeta de cifrado de hardware. He estado buscando más en DPAPI y puedo obtener su aprobación si uso el alcance del usuario en lugar del alcance de la máquina. Mi gerente está en reuniones todo el día, así que tendré que esperar para obtener la aprobación hasta entonces. –

Cuestiones relacionadas