Asegurar datos confidenciales de los desarrolladores

Tengo una aplicación empresarial en ejecución que utiliza almacenes de datos MySQL y MongoDB . Mi equipo de desarrollo tiene acceso SSH a la máquina para realizar lanzamientos de aplicaciones, mantenimiento, etc.

Recientemente planteé un riesgo en el negocio cuando los usuarios comenzaron a almacenar datos altamente confidenciales en la aplicación de que los desarrolladores tienen acceso indirecto a estos datos, lo que causó una tormenta, por lo que ahora se me ha ordenado proteger los datos para que no accesible.

Para mí, esto no parece posible porque si la aplicación tiene acceso a la base de datos, un desarrollador con acceso a la máquina y a la fuente de la aplicación siempre podrá acceder a los datos.

La seguridad no es una varita mágica que puede agitar al final de un proyecto, debe ser considerada e incorporada desde el día 1. No es un atornillado, es la aplicación constante de una gama de soluciones aplicadas de forma iterativa y revisada. regularmente como parte de un sistema completo, que es tan fuerte como el eslabón más débil.

Tal como está, ha señalado un problema de seguridad, que es un buen primer paso. Ahora, como mínimo, debe definir: -

• ¿Qué datos estás tratando de proteger?
• ¿De quién está tratando de proteger esos datos?
• ¿Quién realmente necesita acceso a qué (y cuándo)?
• ¿Cuál es el impacto legal / financiero / comercial de los datos comprometidos?
• ¿Cuál es la necesidad legal / financiera / comercial para que una persona / grupo tenga acceso a los datos?
• ¿Qué presupuesto está dispuesto a asignar la empresa a una estrategia de "obtener seguridad, mantenerse seguro" cuando antes no era un requisito comercial?
• ¿Qué acceso necesita el sistema a los datos?
• ¿De qué depende este proceso y los sistemas de esta aplicación?
• ¿Qué se hace para asegurar esos entornos?
• ¿Quién será responsable de implementarlo y revisar todo el proceso?

Hasta que conozca todos los detalles, realmente no tiene nada con qué trabajar. Esa información definirá qué mitigaciones para esas amenazas puede (y no puede) aplicar y por qué.

Es posible que lo mejor sea reconocer que no tiene la experiencia necesaria y que sería mejor traer a alguien nuevo con esa experiencia. A menudo escucho la respuesta de que no hay presupuesto: si se considera realmente importante, se encontrará el presupuesto.

Tienes razón. Si una aplicación es capaz de acceder al contenido almacenado en máquinas corporativas sin que el usuario pase información adicional cada vez , entonces los programadores, mantenedores, administradores de sistemas, etc. del proveedor de servicios pueden acceder a ese contenido. Esto es fundamentalmente inevitable y una fuente importante de inseguridad (Edward Snowden era un administrador de sistemas y tenía privilegios especiales sobre "Top Secret" porque simplemente no hay forma de no otorgarlos).

La única forma de evitar esto es exigir al usuario que proporcione información que nunca llegue a las máquinas corporativas. Esto es tedioso y propenso a errores, ya que nadie puede recordar suficiente información para formar una barrera de acceso segura y, por lo tanto, las personas comenzarán inmediatamente a almacenar sus credenciales electrónicamente en algún lugar, que luego se convertirá en el nuevo objetivo de ataque (y probablemente un objetivo más débil que el que estás manteniendo). Pero si quiere afirmar sinceramente "Nuestros empleados no son físicamente capaces de acceder al contenido de nuestros usuarios", es la única forma.

(Tenga en cuenta también que tal modelo de negocio parece estar volviéndose políticamente insostenible. Las empresas se han visto obligadas a dejar de funcionar por los servicios de seguridad por tratar de hacer exactamente esto. Entiendo que dar garantías de privacidad tiene valor comercial, pero posiblemente no puede tener más valor comercial que el objetivo fundamental de permanecer en el negocio.)

Tienes toda la razón; algunos desarrolladores siempre necesitarán acceso a los datos en vivo, aunque solo sea para diagnosticar problemas de producción. Lo mejor que puede hacer es limitar el daño potencial reduciendo la cantidad de personas involucradas.

With great power comes great ... opportunity to really, *really* foul things up. 

Muchos desarrolladores no querrán esa responsabilidad y otros, simplemente no estarán "listos" para asumirla y, por lo tanto, no deberían haberlo hecho.

Pregunta: ¿Por qué su equipo de desarrollo realiza lanzamientos en vivo ?
¿Le sugeriría que necesita un "equipo" de Administración de versiones (incluso si es solo un subconjunto de su equipo, además de representación comercial para tomar "decisiones" en el día, como "Ir / No ir")? Esto eliminaría gran parte de la "necesidad" de los desarrolladores de tocar cualquier cosa en vivo.

¿Tiene algún tipo de acuerdo de confidencialidad / no divulgación entre los desarrolladores y la empresa? Es duro, pero puede tener algún mérito.

El problema es que sus desarrolladores tienen acceso a los sistemas. Si necesitan datos de producción para la depuración, dele un volcado de la base de datos donde se elimine toda esa información confidencial. Entonces los desarrolladores pueden trabajar con ese volcado.

La implementación de una nueva versión no debería involucrar a ningún desarrollador, que sea una tarea de administrador pura, o incluso mejor, una tarea totalmente automatizada. También tenga en cuenta que liberar y desplegar son dos tareas muy diferentes. Si su proceso no es consciente de eso, cámbielo en consecuencia.

Regla n. ° 1 de seguridad: si alguien tiene acceso a la información, tiene acceso a esa información

Esa tautología es molesta, pero es verdad. Si le da acceso a un individuo, ellos tienen acceso a los datos. Para los usuarios, esto generalmente significa control de acceso, pero para los desarrolladores ... bueno ... ellos son los que tienen que escribir el control de acceso.

Si este es un problema importante para usted (y parece que lo es), considere incorporar seguridad en su software. Un patrón común es diseñar software seguro en capas. En la capa más baja, un equipo de desarrollo de confianza diseña software que gestiona el control de acceso más simple. Ese software es validado y verificado por tantas personas como sea posible. Cualquiera que diseñe ese código tiene acceso a todo, por lo que la confianza es esencial.

Después de eso, los desarrolladores pueden construir un control de acceso más flexible sobre esa capa central. Este código todavía tiene que ser V y Vd, pero no es tan estricto porque siempre puede confiar en la capa central para cubrir lo esencial.

El patrón se extiende hacia afuera.

La parte difícil, de hecho, el arte de diseñar estos sistemas, es cómo construir cada capa para que los desarrolladores puedan continuar desarrollando y depurando al mismo tiempo que proporcionan a su empresa la seguridad que espera. En particular, deberá aceptar que la depuración exige más privilegios de los que cree que deberían, e intentar bloquearlos provocará algunos desarrolladores muy enojados.

Como solución secundaria, considere crear bases de datos "seguras" con fines de prueba donde los desarrolladores puedan extraer todos los mecanismos de seguridad y realizar una depuración seria.

Al final, tanto usted como sus desarrolladores deben comprender un principio clave de seguridad: toda la seguridad es un equilibrio entre seguridad y usabilidad. Usted debe golpear su propio balance de una empresa. El sistema no será perfectamente seguro y no será perfectamente utilizable. Ese equilibrio probablemente incluso se moverá a medida que su empresa crezca y / o cambien las demandas de los desarrolladores. Si está abierto a esta realidad, puede abordarla.

Configure dos implementaciones de la aplicación que también usan implementaciones de bases de datos separadas. Uno es el despliegue de producción y el otro es el despliegue de prueba.

La implementación de prueba solo debe tener datos de prueba. Estos pueden ser datos de fantasía que se crearon para ese propósito o una copia de los datos de producción que se anonimizaron para evitar que los desarrolladores descubran las personas y entidades reales detrás de los datos.

En dos empresas financieras, los desarrolladores no tenían acceso a las máquinas de producción. Todas las solicitudes para modificar máquinas de producción tuvieron que pasar por un proceso de aprobación, con un script, y fue aprobado por los gerentes. El equipo de dev-ops completó las implementaciones reales. Supongo que este equipo solo eran empleados, y pasó las verificaciones de antecedentes. Tampoco tenían conocimiento del desarrollador, por lo que probablemente no podrían espiar si quisieran. Además de esto, encriptaría todas las entradas de la base de datos utilizando una clave secreta almacenada en las variables de entorno. Incluso si las bases de datos se filtraron públicamente, nadie podría leerlo. Esta clave se puede proteger con contraseña (PBKDF) para que solo un ejecutivo pueda desbloquearla. Su sistema podría requerir la contraseña ejecutiva al inicio (o más probablemente delegada a dev-ops o un administrador de dev-ops). Básicamente, la estrategia es dispersar el conocimiento para que no exista una masa crítica de conocimiento requerido en una persona y haya controles y equilibrios. Así es como Coca-Cola protege su fórmula. Honestamente, algunas de estas respuestas son evasivas.

MongoDB tiene controles de seguridad limitados y depende de un entorno seguro. Enlace a una ip y puerto específicos (y ssl desde 2.2), y una autenticación cruda, eso es lo que ofrece. MYSQL agrega GRANT o ON db.t TO ... Los datos en reposo no están encriptados y ssl no se usa por defecto. Crea una cerca. El acceso de solo lectura para los desarrolladores a los archivos de registro relacionados con la aplicación debería ser suficiente para depurar. Automatizar el ciclo de vida de la aplicación.

Ansible nos ayudó a automatizar las operaciones estándar (implementación, actualización, restauración) en muchos entornos de un solo inquilino mientras usamos bóvedas cifradas distintas para almacenar variables de entorno sensibles como hosts, puertos y credenciales. Si cada bóveda solo puede ser descifrada por diferentes roles, y solo en un servidor bastión, para operaciones registradas, la auditabilidad proporciona una seguridad aceptable. Si otorga SSH, utilice selinux para evitar la manipulación de claves, use un host de bastión con autenticación ldap / kerberos para la administración y use sudo sabiamente.