¿Deberíamos cifrar los mensajes de usuario dentro de la aplicación?

2

Tenemos una aplicación que se ejecuta donde, entre otras cosas, las personas pueden enviarse mensajes entre sí. Obviamente, los administradores y administradores de contenido que tienen acceso a CMS pueden ver lo que las personas se envían entre sí. ¿Se suele cifrar y, en caso afirmativo, cómo, con qué cifrado?

ACTUALIZAR

Todo el sitio está cifrado con SSL, estoy hablando específicamente de que los administradores pueden leer los mensajes de los usuarios entre ellos. Claro, podemos evitar que ciertos administradores tengan acceso a eso, pero, para ser honesto, me gustaría ocultarlo incluso del superadministrador con cifrado. Pero entonces, en caso de que uno necesite leerlos para cualquier propósito, cómo descifrarlos, cómo estructurar el protocolo de administración para eso?

    
pregunta Ska 03.01.2014 - 15:35
fuente

3 respuestas

6

No tenemos forma de saberlo.

Lo que hay que hacer es:

  • Identifique los riesgos derivados de esta vulnerabilidad. (¿Qué cosas malas podrían hacer sus administradores? ¿Qué cosas malas podrían hacer otras personas si los mensajes no están cifrados?)
  • Evalúe la gravedad de estos riesgos.
  • Decida si estos riesgos son aceptables o si deben tratarse.
  • Identifique formas adecuadas de tratar estos riesgos.
  • Trata los riesgos.

Para hacer todo lo que requiere una buena comprensión de para qué se usa su aplicación, qué quieren sus clientes, qué exige la ley de usted, cuáles son sus obligaciones contractuales, qué recursos tiene disponibles, qué capacidades de seguridad tiene su infraestructura y el nivel de riesgo que su empresa considera aceptable.

No es el tipo de respuesta que esperaba, me temo, pero si la seguridad es importante, debe tomar decisiones correctas e informadas al respecto.

    
respondido por el Graham Hill 03.01.2014 - 15:50
fuente
1

Sí, debe cifrar cualquier algoritmo de mensajería o transferencia de datos. Dependiendo del tamaño de la empresa, puede resultarle más caro agregar encriptación a su código, lo cual es comprensible. Sin embargo, esto no es una buena práctica.

Básicamente, una persona con información privilegiada podría oler fácilmente los paquetes y leer los mensajes, que pueden tratarse de datos empresariales críticos, o de algún secreto, etc. De cualquier manera, causaría muchos dolores de cabeza ...

También un extraño podría oler ... No tiene que ser perfecto, pero se necesita algo de cifrado. Si usa claves secretas, puede registrarlas en algún lugar, o hacer que se generen usando el tiempo y el nombre de usuario, por lo tanto; cuando sea necesario, los administradores pueden leer los textos.

    
respondido por el cengizUzun 03.01.2014 - 16:47
fuente
1

Una segunda respuesta, ya que ahora es una pregunta bastante diferente: qué controles puedo implementar para evitar que los administradores lean los mensajes de los usuarios por razones ilegítimas, al tiempo que conservan su capacidad de leer mensajes por razones legítimas. Este es un problema difícil.

Algunos enfoques que puedes investigar:

Primero, el sencillo. Dígale a sus administradores que serán despedidos si son traviesos. Significa esto, y asegúrate de que Recursos Humanos y administración lo sean, y asegúrate de que todos tus administradores creen que lo dices en serio. Haz que firmen documentos de miedo. Recuérdeles regularmente.

Segundo, implementar la segregación de funciones. Necesitará un esquema de cifrado de clave dividida en el que requiera que dos administradores (o un administrador y un administrador) trabajen juntos para descifrar un mensaje.

Tercero, implementa un control de cambios implacable. Registrar todo lo que hace cada administrador. Audítalo regularmente. (Porque hay otras formas de llegar a los mensajes además de obtener la clave).

Gran parte de esto será costoso y todo le dirá a los administradores que no confías en ellos, así que asegúrate de que el valor de los mensajes lo justifique.

    
respondido por el Graham Hill 07.01.2014 - 12:37
fuente

Lea otras preguntas en las etiquetas