Si desea que los administradores no puedan acceder a los datos, los datos sin cifrar nunca podrán afectar a los servidores que controlan. Además, la clave de descifrado tampoco puede estar en el servidor, ya que si lo estuviera, un administrador malintencionado podría tomar tanto los datos cifrados como la clave, y descifrarlos.
Entonces, ¿qué opciones tienes?
-
Encriptación del lado del cliente. Si el usuario final cifra los datos utilizando una clave que nunca se envía al servidor, y los datos cifrados se envían a su servidor, no hay forma de que el administrador los descifre, pero el usuario puede descargar y descifrar, siempre y cuando tener la llave Sería mejor encriptar con una clave derivada de una contraseña que de la propia contraseña, solo desde la perspectiva de la longitud de la clave, aunque esto no es nada raro.
El problema que tiene con esto, si le preocupa que los administradores intenten acceder a los datos, es que presumiblemente pueden modificar el código de cifrado enviado al cliente, si está usando JS: tienen acceso a la servidor. No sería particularmente difícil cifrar los datos dos veces, una vez con la clave de usuario y una vez con una clave conocida por los administradores. Puede evitar la manipulación en tránsito (es por eso que tiene SSL habilitado), pero el administrador que puede editar el contenido del sitio probablemente puede editar cualquier suma de verificación utilizada para preservar la integridad del código del lado del cliente.
-
Requerir que el usuario encripte antes de enviar. Si el usuario final utiliza una aplicación de cifrado de terceros, sus administradores no pueden hacer nada al respecto, excepto la fuerza bruta, lo que debería ser difícil. Sin embargo, reduce su servicio a un almacén de archivos, lo que podría no ser aceptable.
-
Difunde el riesgo. Tener un servidor que sirva las rutinas de encriptación al cliente, que es administrado por la compañía A. Tener un servidor que recibe datos encriptados y los almacena, que es administrado por la compañía B. Tener el resto de la aplicación web en un servidor administrado por la compañía C. El usuario final recibe el código de encriptación del servidor A, que presumiblemente no está modificado, ya que los administradores de ese servidor nunca ven los datos encriptados, y no pueden modificar el código sin romper las sumas de control que se entregan desde el servidor C. clave del lado del cliente (que nunca se envía a ningún lado), y envía los datos al servidor B.
Los administradores de A no pueden manipular el cifrado, o dónde se envían los datos, a menos que colaboren con los administradores de C. Los administradores de C pueden modificar a dónde se envían los datos, o enviar rutinas de cifrado incorrectas, pero B Puede informar si no están recibiendo ningún dato. Los administradores de B tendrían que conseguir que los administradores de C les pasaran la clave, o los administradores de A para modificar las rutinas de cifrado para obtener acceso.
Ahora, esto parece un escenario muy complicado, pero eso solo muestra cuánta potencia tienen los administradores del servidor; por definición, tienen acceso para leer y modificar prácticamente cualquier cosa.
Básicamente, usted se compromete entre la facilidad de mantenimiento y la seguridad: la opción 1 es fácil de mantener, ya que tiene el control total del servidor desde un solo punto. La opción 3 es difícil, ya que tiene que coordinar cualquier cambio entre varios administradores, pero hace que sea muy difícil para cualquier individuo obtener los datos. Si vale la pena ese esfuerzo depende de los datos que se almacenan.