¿Cómo puedo evitar que los programadores capturen los datos ingresados ​​por los usuarios?

10

Estoy desarrollando una aplicación web con un fuerte enfoque en la seguridad. ¿Qué medidas se pueden tomar para evitar que quienes trabajan en la aplicación (programadores, DBA, personal de control de calidad) capturen los valores ingresados ​​por el usuario que deberían estar bien protegidos, como contraseñas, números de seguridad social, etc.

security 
— Peter Smith
fuente
3
Le sugiero que publique la pregunta en: security.stackexchange.com/?as=1
— NoChance
"Prevenir" es una palabra muy fuerte. No puedes evitar que los malos actores hagan cosas malas. Lo que puede hacer es aprender y aplicar principios de seguridad fundamentales como "privilegio mínimo", "separación de deberes" y "negación implícita", diseñe las cosas de forma segura y contrate personas en las que pueda confiar. Tenga planes viables para mitigar el daño cuando ocurra lo inevitable.
— Robert Harvey
Los términos técnicos para las tecnologías que necesita: hashing y cifrado.
— Robert Harvey

Respuestas:

22

Esto es bastante simple Los bancos lo hacen todo el tiempo.

Tienes tres grupos de personas involucradas. Estos son grupos de seguridad. Con autorizaciones distintas.

Los desarrolladores no pueden asignar autorizaciones de seguridad y no pueden ver los datos de producción.

Los operadores no pueden asignar autorizaciones de seguridad y no pueden crear software.

Gente de seguridad que establece las autorizaciones y no puede crear ni operar el software.

Los desarrolladores crean software. Los operadores lo instalan y lo operan. La gente de seguridad asegura que los dos grupos se mantengan separados.

— S.Lott
fuente
8
OK, pero un desarrollador aún podría agregar algo al sistema que envíe por correo electrónico datos de producción a su cuenta privada; o escribe datos de producción en algún servidor donde los recogerá. Creo que la única forma de evitar esto es con un riguroso régimen de revisión de código.
— Dawood ibn Kareem
3
Siempre existe ese nivel de confianza que se otorga a los empleados. Alguien tiene que tener las llaves del palacio, y si no puedes confiar en que entienden el poder que se les da, entonces quizás no deberíamos darle esas llaves a esa persona en primer lugar.
— Chris
1
Sí, pero tener claves que requieren más de una persona (como el régimen de revisión de código) significa que necesita dos para "extraviarse" antes de verse comprometido y es menos probable que "solo un" empleado se extravíe y abuse de la clave dada a ellos. Se trata de equilibrar la confianza y las consecuencias del abuso de esa confianza. Y no olvides que las personas y las circunstancias cambian. Una persona en quien se confía cuando se le dan las llaves puede hacer que sucedan cosas en la vida por las cuales se vuelve menos confiable ...
— Marjan Venema
1
@EmmadKareem: Correcto. La persona de seguridad establece y restablece grupos y contraseñas, pero no puede ver los datos. Solo los operadores pueden ver datos reales. Piense en los datos como dinero real manejado por cajeros reales. Los programadores no tocan el dinero; solo cajeros Del mismo modo, las personas de seguridad no tocan dinero; solo los cajeros tocan dinero.
— S.Lott
1
@EmmadKareem: los DBA no son desarrolladores. Hay dos grupos: seguridad y datos. Los DBA de datos son una parte especial de las "operaciones". Deben no tienen autorización para cambiar la seguridad; no pueden escribir código; Sin embargo, verán datos y deben ser tratados como operadores, no como desarrolladores.
— S.Lott
2

Los programadores no tienen acceso a los servidores de producción. Pero alguien tiene que tener acceso. No hay forma de evitarlo. Y siempre existe la posibilidad de que alguien se vuelva loco y abuse de su acceso.

Los datos que se mezclan / salan son teóricamente seguros incluso de las personas que tienen acceso total para verlos. Pero la mayoría de los datos no son apropiados para el hash.

— Lord Tydus
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.