¿Las grandes empresas que almacenan datos privados de los usuarios se aseguran de que nadie solo pueda abusar de los datos de los usuarios? ¿si es así, cómo?

En primer lugar, la mayoría de las empresas no emplean (o siguen) todos los procedimientos necesarios para evitar que los usuarios accedan a datos a los que no deberían poder acceder.

Suponiendo que la empresa X sigue los procedimientos necesarios, estos procedimientos se desarrollarán en torno a algunos principios fundamentales:

Acceso necesario para saber
Cada usuario tiene acceso a la información que es obligatoria dadas sus tareas de trabajo. Dado que este principio se sigue correctamente, incluso los administradores de sistemas no deben tener acceso a los datos del usuario más allá de sus tareas de trabajo.

Separación de funciones
A cada usuario se le asignan tareas que no se superponen para evitar conflictos de intereses. Por ejemplo, un administrador del sistema que puede alterar los permisos de los usuarios puede ver los archivos de registro pero no puede eliminar las entradas del registro .

Principio de cuatro ojos o Regla de dos hombres
Los procedimientos críticos deben ser revisados por dos personas antes de llevarse a cabo. Esto asegura que un interno malicioso no actuará solo. Por ejemplo, si un administrador del sistema desea modificar los permisos de los usuarios, necesitarían la autorización de un administrador del sistema o usuario adicional para hacerlo.

Datos pseudonimización o anonimización Si, por cualquier motivo, los datos confidenciales se presentan a un usuario (es decir, una hoja de cálculo que presenta datos confidenciales y no confidenciales), los datos que no sean relevantes para sus funciones serán pseudonimizados (es decir, reemplazados por seudónimos) o anonimizados (es decir, eliminados) o encriptado).

Entonces, básicamente, su pregunta es "¿Qué acciones / políticas puede promulgar una empresa para limitar el abuso y el uso indebido de datos privados (de los usuarios)?"

Bueno, de hecho hay varios enfoques estándar de la industria para esto. A continuación, enumeraré algunas de ellas con una breve explicación de lo que están buscando:

• principio de los 4 ojos
• algoritmo de intercambio secreto de Shamir .
• control de acceso multifactorial.
• Llaves de tarjeta inteligente.
• NDA's

• Reglas éticas.

  1. el principio de los 4 ojos (o la regla de los dos hombres) básicamente significa que para realizar cualquier acción necesitas tener 2 personas juntas para realizar dicha acción (1 para realizar y 1 para sancionar).

  2. El intercambio secreto de Shamir es una manera de dividir un secreto 'compartido' para que no haya 1 persona tiene el secreto completo y n los encargados del secreto deben trabajar juntos para reconstruir el secreto.

  3. control de acceso multifactor simple significa más de 1 factor para basar la autenticación y autorización (2fa se usa comúnmente, pero se pueden emplear más factores [algo que tienes, algo que sabes, algo que eres, en algún lugar donde son, alguna acción que realizas])

  4. Se pueden usar claves de tarjetas inteligentes u otros dispositivos de almacenamiento secreto para limitar la filtración del secreto. Nitrokey y Yubico tienen varios buenos productos que pueden hacer eso (como ejemplo de 2).

  5. Los NDA, más un límite legal que un límite técnico pueden hacer que las personas no abusen de los datos privados de ninguna manera, excepto por lo que se especifica como uso apropiado.

  6. Las reglas éticas están presentes en algunos sistemas legales en todo el mundo que limitan lo que se le permite hacer legalmente con la información de otra persona. Si bien no es tan específico como otras razones, puede ser implementado por los tribunales tan estrictamente cuando es parte del sistema legal.

En cuanto a su idea de separar las claves de cifrado de los sistemas de almacenamiento, esto ya se hace comúnmente pero no para limitar el abuso como este (sería inútil para un caso de uso como el administrador puede simplemente extraer los datos del sistema a través de algunos medio). La Bóveda de Hashicorp es uno de esos proyectos de código abierto para habilitarlo.

Esto variará mucho según la organización.

Solía trabajar como desarrollador para una gran empresa basada en tecnología en el sector financiero. Para acceder a una base de datos de producción para acceso de solo lectura había una herramienta especial. Esto le permitió extraer casi cualquier cosa de cualquier base de datos a la que tuviera acceso (que era solo las bases de datos a las que tenía razón para necesitar acceso), pero registró absolutamente todo lo que hizo.

Si necesitaba ejecutar un comando en una máquina de producción, tenía que colocar un ticket seleccionando el riesgo que consideraba y enumerando exactamente lo que quería ejecutar y por qué. Cuando digo exactamente quiero decir que había un campo para escribir los comandos. Este boleto iría a su administrador para aprobarlo o ajustarlo (generalmente aumenta o disminuye su riesgo seleccionado). Dependiendo del riesgo que seleccionó, una o más personas, tanto en su cadena de administración como en la sala de operaciones del centro de datos, podrían tener que aprobar el ticket. Para acciones de menor riesgo, estas se ejecutarían automáticamente contra la máquina. Para acciones de mayor riesgo, un operador de centro de datos permitiría manualmente que cada línea se ejecute y observe la salida. Una vez más, absolutamente todo sería registrado.

Se implementaron herramientas para obtener un shell raíz en una máquina de producción, pero estas solo se aprobarían si fuera absolutamente necesario; por lo general, se trata de una situación "muy dañada". Y nuevamente, todo se registrará a través de los sistemas que podrían obtener ese acceso.

Me imagino que dentro de los centros de datos el personal tendría mejores opciones. Sin embargo, estas son instalaciones extremadamente seguras con cámaras en todas partes. Muy pocos miembros del personal tendrían acceso físico a las máquinas y las credenciales necesarias para el acceso de la raíz a ellas y varias personas estarían involucradas en la obtención del acceso físico. Mientras tanto, necesitaría una buena excusa para acceder a una máquina de producción que todavía está en comunicación con el almacén de datos o acceder tanto a un rack de almacenamiento como a un lugar donde las claves de cifrado están disponibles. Y el personal del centro de datos tampoco suele saber qué bases de datos contienen qué información o cómo está estructurada.

Hubo lagunas. Por ejemplo, como desarrollador fue relativamente fácil obtener una base de datos de producción copiada en un entorno beta con fines de prueba / depuración y tenía más herramientas a su disposición allí. Aunque todavía va a haber un registro de la solicitud. Entonces tiene el desafío de obtener grandes cantidades de datos fuera del entorno del servidor y en su PC local, esto no será trivial. Tampoco lo haría fuera del entorno corporativo: los puertos USB y las unidades de disco se desactivaron y todo el tráfico de Internet se monitorizó, incluido el HTTPS.

¿Entonces podrías sacar grandes cantidades de datos? Sí. Pero sería rastreable para usted.