Corremos un software financiero en línea. ¿Cómo protegemos la aplicación para que ni nosotros / los creadores podamos ver los datos del cliente?

Interesante pregunta. Quizás alguien pueda dar una mejor respuesta, pero presentando algunas ideas:

• Las contraseñas se anonimizan completamente de los administradores a través de un proceso de salazón y hash. Aunque es posible extraer contraseñas de texto sin formato del software de inicio de sesión, no es de datos en el almacenamiento a largo plazo (por ejemplo, archivo Unix / etc / shadow). Solo es posible hacer una coincidencia (hash un valor ingresado, ver si coincide con el hash almacenado).
• La comunidad de seguridad de la red habitualmente habla de registros de “desinfección”. Por ejemplo, al publicar registros de red o capturar archivos en línea, las direcciones IP se sustituyen por otras aleatorias de un espacio de direcciones privado, y los identificadores como ID de usuario se reemplazan con genéricos “usuario1”, “usuario2”, etc.
• La comunidad de investigación médica tiene una larga historia de anonimato de datos de pacientes y, más recientemente, de leyes de protección de datos, véase, por ejemplo, Información personal de MRC en Investigación médica.
• La comunidad de inteligencia (MI5, etc.) también tiene una larga historia de protección de datos y ha utilizado el principio de “necesidad de saber” y los esquemas de clasificación de datos (Restringido / Confidencial / Secreto) para controlar el acceso dentro de una organización
• El modelo de seguridad de Unix, con una cuenta “raíz” todopoderosa, no es la única. Otros sistemas operativos lo han hecho mejor, con un sistema de control de acceso más granular.

Reuniendo algunas ideas y escupiéndolas de nuevo:

• Los datos en reposo deben estar encriptados. Eso resuelve problemas con las copias de seguridad de datos, el fin de la vida útil del equipo y el robo de medios / hardware.
• Los datos deben ser descifrados para ser procesados, pero la contraseña debe escribirse cuando se inicia el proceso o al menos cuando se inicia la máquina
• No es necesario que todos los desarrolladores tengan acceso a todas las computadoras. La persona que realiza el mantenimiento del sitio web no necesita acceder a los datos financieros. El acceso a máquinas con datos confidenciales (de hecho, todas las máquinas) debe ser auditado y registrado de forma segura. Las contraseñas nunca deben compartirse, sino el acceso compartido a través de ACL para que siempre se pueda decir quién inició sesión desde dónde y a qué hora.
• La información de identificación personal, como el nombre, la fecha de nacimiento y el SIN, podría eliminarse y almacenarse por separado, reemplazarse con un token aleatorio anónimo cuando sea posible. No sé qué tan práctico sería para tratar con clientes individuales, pero significaría que si ejecuta un software estadístico para seguir las tendencias, por ejemplo, ese programa nunca necesita conocer detalles individuales. En el caso de una violación de seguridad, sería más difícil para un pirata informático hacer un volcado de SQL y tener todo a la vista. (Los datos de Ashley Madison, por ejemplo, tenían nombres personales, direcciones, números de teléfono y preferencias sexuales, todo en solo unos pocos registros SQL).

Actualización: Sitaraman tiene una gran respuesta. Me alegra que se esté tomando en serio la privacidad de los usuarios. Solo tengo que agregar una cosa: si realmente está dispuesto a proteger la privacidad de sus clientes, no debe asumir que algunos de sus datos están bien para que se filtren.

por ejemplo, si sus registros de transacciones de usuario se filtran, ¿cómo se asegura de que su cuenta de correo electrónico no? Debe asumir que sus clientes siempre usan algunos servicios que no pueden mantener sus datos de forma segura. Otros tipos de datos filtrados pueden contener la cuenta de correo electrónico de los usuarios, por lo que cada vez se pueden conectar y acumular más datos. Sé que algunas personas están haciendo esto y vendiendo este tipo de base de datos.

Por lo tanto, no puede simplemente asumir que algo filtrado en su mano está bien, porque otros datos filtrados podrían conectarse y usarse para perfilar a una persona. Puede ver un caso interesante que puede demostrar de lo que estoy hablando al buscar “diferenciar la privacidad” en Wikipedia.

Por último, al menos, he visto demasiados casos de piratas informáticos que utilizan registros de transacciones filtrados para defraudar a los clientes.

Cifrado Cifre los datos de su cliente en su dispositivo y luego cárguelos.

Debe usar su contraseña, que no debe conocer el texto sin formato (debe ser hash, usar bcrypt en lugar de MD5), para extender una clave segura para encriptar sus datos (PBKDF2, por ejemplo);

Debe informar a sus clientes que su contraseña también debe ser lo suficientemente segura.

Asegúrese de utilizar el cifrado durante la transmisión.

Por último, asegúrese de que cada paso del cifrado se implemente correctamente y que el entorno del servidor / cliente sea seguro.

Hay un par de cosas a considerar aquí que quizás no haya pensado: cuán sensibles son los datos y las implicaciones para brindar soporte a sus clientes.

Si su personal de desarrollo no tiene acceso a los datos en su aplicación, y un cliente escribe diciendo que algo está mal en su cuenta, ¿cómo podrá solucionar y ayudar a ese cliente?

La segunda parte es, ¿qué tan sensibles son los datos? Si habla de transacciones individuales (compra / venta), asegúrese de que sea información privada pero no particularmente dañina si se filtran esos datos. Lo que quiero decir con eso es que digamos que su aplicación almacena información sobre todas las compras que hice el mes pasado. Tu aplicación ha sido pirateada, y ahora es ahí donde gasté $ 35.42 en gasolina y $ 56.22 en la cena. ¿Y qué? No estaría contento de que mi historial de compras estuviera disponible, pero esa información en sí misma no me expondría al robo de identidad ni a daños adicionales.

Para volver a su pregunta: proteja sus datos. Obtenga auditorías externas de sus sistemas. Haga todo lo posible para asegurarse de no tener una violación de datos. Tenga una política de privacidad que explique cómo / qué datos están disponibles para su personal. Establezca sistemas para registrar su acceso a los datos del cliente. Pero bloquear completamente a su personal de los datos del cliente simplemente no es práctico.

El software de la aplicación necesita guardar los datos en el backend en forma ya encriptada, utilizando una contraseña ingresada por el usuario como clave. El servidor nunca ve datos sin cifrar y no sabe cómo descifrar los datos que recibe.

Mientras la contraseña sea segura (difícil de adivinar), este es un sistema muy seguro. La desventaja es que si el usuario olvida su contraseña, los datos son irrecuperables.

La única forma de hacer esto realmente es dar a los usuarios la capacidad de proporcionar sus propias claves privadas (o usar sus contraseñas como claves, lo cual es menos seguro pero será mucho más fácil para los usuarios). Luego, encriptaría todos sus datos utilizando su clave.

El principal inconveniente de esto es que perderá el acceso a todos los datos de manera irreversible y hará que sea imposible diagnosticar problemas. Además, si un cliente olvida su contraseña, todos sus datos se perderán para siempre. Por estas razones, la mayoría de las empresas no lo hacen a menos que su base de usuarios tenga conocimientos técnicos y entienda las consecuencias.

Quizás alguien pueda escribir una respuesta larga y más detallada. La esencia de esto es cifrar la fecha en reposo y en tránsito y hacer que el cliente almacene la clave para descifrar los datos. No se dé acceso a la clave para descifrar los datos. Amazon hace esto con sus claves SSH.

Creo que no puedes. Incluso si todos los datos del cliente están cifrados, el software debe conocer la clave de descifrado para poder operar con los datos, y si el software puede descifrar los datos con esa clave, usted también puede hacerlo.

Además, incluso si fuera posible, no hay forma de que los clientes puedan estar seguros de que está diciendo la verdad si les dice que no puede leer sus datos.