SecureData incluso para administradores con inicio de sesión externo

La regla es que si los datos están en texto sin cifrar en cualquier momento en una máquina, el administrador de la máquina puede acceder a ellos. Debido a que, por definición, un administrador puede usar herramientas administrativas y leer la memoria de cualquier proceso o instalar programas en cualquier ruta de red.

Hacerlo sin una buena razón es, por supuesto, una falta profesional y el administrador puede ser despedido por eso, no hablando de acciones legales, pero técnicamente se puede hacer.

Lo único que se podría hacer aquí sería tener diferentes zonas administrativas y configurar el sistema para que los administradores de la máquina de la base de datos no puedan acceder a los datos. Para eso, el servidor principal debe ser distinto del servidor de la base de datos y la base de datos solo debe contener datos cifrados. Puede tener sentido si tiene un servidor interno pero desea almacenar la base de datos externamente por razones de redundancia. Pero un caso de uso mucho más común sería tener una base de datos interna, y solo almacenar volcados cifrados en la nube.

TL / DR: si no puede confiar en el administrador, no puede confiar en la máquina, por lo que el servicio web solo debe procesar datos cifrados, lo que significa que necesita otra cosa y en otra parte para procesar, cifrar y descifrar los datos.

  

Para mí sería un poco extraño pedirle un "MasterKey".

No es así si el núcleo del servicio es garantizar que solo esa persona pueda acceder a los datos descodificándolos primero.

La autenticación a través de un tercero en ese caso no es útil, será mejor que se la entregue (correctamente) para que los usuarios solo tengan que pasar por un proceso de autenticación.

El problema obvio con su modelo es que necesita cargar y descifrar todos los registros si desea buscar una base de datos. No va a escalar.

En cuanto al problema de administrar el secreto, guárdelo en el navegador, por ejemplo. en una cookie: mi cifrado del manejador de sesión hace esto: la identificación de la sesión no está cifrada y es la única clave utilizada para buscar los datos, por lo tanto, no hay ningún problema con la indexación. Puede generar un valor inicial y aconsejar al usuario que tome una copia y la almacene de forma segura (en caso de que pierda la copia en la cookie) y luego proporcione un medio para que ingresen el valor más adelante.

No estoy de acuerdo con WoJ sobre la implementación de su propia autenticación. La mayoría de los proveedores grandes emplean a mucha gente inteligente y pueden justificar pasar el tiempo desarrollando y probando mecanismos seguros para administrar cuentas, y con los datos encriptados usando un token que el tercero no tiene acceso, usted tiene menos de qué preocuparse en términos de el proveedor de autenticación actuando como un adversario.