¿La lectura de un producto a otro es un problema de seguridad? [cerrado]

No creo que sea posible responder a esto en general. Pero puedo pensar en algunas cosas que PODRÍAN ser válidas.

1. El Prod tiene datos que solo deben ver ciertas personas. Debido a que prod normalmente alimenta dev, los "datos secretos" deberían mitigarse de alguna manera antes de que lleguen a ser dev, o los datos en sí son sensibles al tiempo. Si no lo es, entonces la única diferencia entre prod y dev es que dev es generalmente mayor.
2. Prod tiene nombres de usuario / contraseñas / elementos de configuración confidenciales que no debe darse a los desarrolladores.

Sin embargo, como mínimo, su experto en seguridad debería poder identificar la RAZÓN detrás de la preocupación de seguridad en lugar de que usted tenga que adivinarlos. Si no lo está, simplemente está usando su autoridad sin razón, y no está trabajando para encontrar una solución que satisfaga las necesidades de todos.

Es posible que una empresa sujeta a auditorías de PCI o HIPAA tenga que escribir una política de seguridad que prohíba compartir datos entre desarrolladores y productores para cumplir con los estándares de seguridad de datos, pero también es posible que hayan redactado la política para que se aplique. a todos los datos, no solo los datos de PCI o de salud.

Esto no es necesariamente algo malo. La seguridad no se limita a defenderse contra ataques, sino a proteger contra riesgos en general. Muchos de los problemas han sido causados por los datos que cruzan el límite en cualquier dirección, y seguir una buena política puede evitar pérdidas.

Un banco tuvo un ejemplo famoso de un problema que podría haberse evitado siguiendo esta política. Decidieron enviar una carta de solicitud a sus mil clientes principales. Por supuesto, algún desarrollador había ingresado un nombre falso inteligente en su base de datos de prueba. Debido a una confusión entre dev y prod, las cartas salieron a todos sus buenos clientes con el saludo "Estimado Rich Bastard". Si bien no es un riesgo de "seguridad" en el sentido de que un atacante no lo causó, es posible que hayan perdido algunos buenos clientes debido a este error.

Por el contrario, copiar datos de prod a dev puede abrir agujeros en su entorno seguro. Podría argumentar caso por caso por qué los datos X son seguros para moverse a dev mientras que los datos Y no son seguros para moverse, pero incluso eso introduce riesgos. ¿Quién autoriza los datos es seguro moverse? ¿Quién se asegura de que solo se muevan los datos seguros, pero no los datos confidenciales? ¿Se abren los puertos del cortafuegos para mover los datos y, de ser así, quién los abre y los cierra? ¿Quién audita el movimiento de los datos? ¿Quién audita los puertos de firewall que estaban cerrados? Hay muchas partes móviles, cualquiera de las cuales puede fallar y dejar sus datos o sistemas expuestos.

Una sola política que prohíba dicho movimiento elimina el riesgo, pero a un costo. Ahora necesita gastar recursos para crear los datos de prueba. Aquí es donde puede presentar un caso de negocios: el costo de la política es X, el riesgo evitado por la política es Y, ¿vale la pena? Con solo comenzar el análisis, puede llegar rápidamente a la conclusión de que no vale la pena continuar.

No puedo explicar completamente por qué su oficial de seguridad local considera que esto es un riesgo / preocupación de seguridad, pero puedo decirle dos cosas que supongo que está pensando; incluso si él no está pensando en esto, esta será mi respuesta, ya que esto es lo que me preocuparía si fuera el oficial de seguridad local de su organización:

1. Usted mencionó que prod está bloqueado, y dev no tanto. Mi primera preocupación serían los datos confidenciales de la compañía, que pueden no contener PII, pero pueden ser OUO (uso oficial solamente) se filtrarían y tienen una mayor probabilidad de ser filtrados o manipulados, ya que no parece tener la seguridad más estricta controles que hace dev. Una vez más, solo puedo salirme del contexto que configuró en su pregunta, pero si la información de la compañía no está tan controlada en el desarrollo como en la producción, definitivamente puedo ver la preocupación de su tipo de seguridad / gal.
2. También mencionó que los datos pueden fluir de prod a dev y (no debería hacer esto, pero supongo que viceversa; de dev a prod) si los datos pueden fluir de al menos prod a dev, entonces tiene que haber una Conexión de red física / lógica entre los dos. Nuevamente, los entornos de producción deben estar sujetos a controles de seguridad más estrictos para proteger los datos a los que se refiere. Si hay una conexión de red, para mí ese es un punto de entrada para que riesgos potencialmente maliciosos entren en producción. No estoy hablando necesariamente de virus per se (sin embargo, esta amenaza podría ser muy real si su entorno de desarrollo, como la mayoría, tiene una postura de seguridad muy relajada y permite que se instalen y tomen todo tipo de configuraciones y software y otros procesos) place), en lugar de cualquier tipo de vector malicioso que pueda comprometer la integridad, la confidencialidad o la disponibilidad debido a la conexión de red (física o lógica) de prod a dev. Estoy seguro de que hay firewalls involucrados, sin embargo, no estoy al tanto de qué tipo de ACL u otras políticas de acceso tienen implementadas. Esto, nuevamente, justificaría la preocupación de su oficial de seguridad.

Esto no es evangelio, pero proviene de un profesional de seguridad que piensa mucho como tu chico / gal.

Esperemos que eso pueda darte una idea más de lo que están pensando.

Los entornos de producción y no producción deben estar aislados como una buena práctica. Es probable que los entornos que no son de producción tengan menos supervisión, que tengan un código no seguro, que no tengan máquinas actualizadas, etc.

Si tiene algo que pueda ir entre estos entornos, está aumentando el riesgo de:

• Malware que atraviesa desde dev hasta prod.
• Confusión y mezcla de membresías o permisos de grupo
• Personas que accidentalmente usan dev para procesos de producción o toma de decisiones
• La gente está confundida acerca de dónde está accediendo a la información

Si tiene un proceso ETL que envía los mismos datos a producción y no producción, también puede estar violando los requisitos / políticas de privacidad de datos o requisitos externos como los de HIPAA o PCI.

En general, datos no debe ir de la producción al desarrollo o viceversa. Solo se debe migrar código de dev a producción a través de un proceso bien definido y controlado.

Probablemente no deberías compartir sistemas de autenticación o, al menos, cuentas entre ambos entornos. Es posible que ni siquiera desee utilizar cuentas de producción para entornos de "capacitación". Los sistemas de producción deben permanecer aislados de todo lo que no sea prod.

He visto entornos de no producción y de prueba en los que se permitían todo tipo de cosas extrañas, donde las cuentas se compartían entre los desarrolladores, los datos se descargaban, se registraban y se analizaban de manera que no sería aceptable para los datos de producción en ninguna organización .

Leyendo algunos de sus comentarios a otras respuestas: Parece que una preocupación puede ser demasiada información permitida en el entorno de desarrollo. No está claro si está limpiando los datos, pero puede ser un riesgo aceptable tener 1 mes de datos en desarrollo, pero poner el valor de 5 años es una gran exposición al riesgo.

Actualizaré mi respuesta si agrega más detalles a su pregunta.