Protección de datos confidenciales de desarrolladores

La seguridad no es una varita mágica que se puede agitar al final de un proyecto, debe considerarse y construirse desde el día 1. No es una descarga de pernos, es la aplicación coherente de una gama de soluciones aplicadas iterativamente y revisado regularmente como parte de un sistema completo, que es tan fuerte como el eslabón más débil.

Tal como está, ha marcado un problema de seguridad que es un buen primer paso. Ahora como mínimo tienes que definir: -

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

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

Puede que lo mejor sea reconocer que no tiene la experiencia necesaria y que sería mejor traer a alguien nuevo con esa experiencia. Muy 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 puede acceder al contenido almacenado en las máquinas corporativas sin que el usuario pase información adicional cada vez , entonces los programadores, mantenedores, administradores de sistemas, etc. del proveedor del servicio pueden acceder a ese contenido. Esto es fundamentalmente inevitable y una de las principales fuentes de inseguridad (Edward Snowden era un administrador de sistemas y tenía privilegios especiales sobre "Alto Secreto" porque simplemente no hay una manera de no otorgarlos).

La única forma de evitar esto es exigir al usuario que proporcione información que nunca llega a las máquinas corporativas. Esto es tedioso y propenso a errores, ya que posiblemente nadie pueda recordar suficiente información para formar una barrera de acceso segura y, por lo tanto, la gente comenzará a almacenar sus credenciales de forma electrónica en algún lugar, lo 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 desea afirmar con sinceridad que "nuestros empleados no son físicamente capaces de acceder al contenido de nuestros usuarios", es la única manera.

(Tenga en cuenta también que este modelo de negocios parece ser políticamente insostenible. Los servicios de seguridad han obligado a las empresas a dejar de operar por tratar de hacer exactamente esto. Entiendo que dar garantías de privacidad tiene valor comercial, pero no puede posiblemente tenga más valor comercial que el objetivo fundamental de permanecer en el negocio.)

Tienes toda la razón; algunos desarrolladores siempre necesitarán acceder 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 al reducir 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 mantenerla, y por eso no deberían.

Pregunta: ¿Por qué su equipo de Desarrollo realiza lanzamientos en vivo ?
Le sugiero que necesite un "equipo" de administración de versiones (incluso si es solo un subconjunto de su equipo, además de una representación empresarial para tomar cualquier "decisión" del día, como "Ir / No ir"). Esto eliminaría gran parte de la "necesidad" de que los desarrolladores toquen cualquier cosa en vivo.

¿Tiene algún tipo de acuerdo de confidencialidad / no divulgación entre los desarrolladores y la empresa? Es de mano dura, pero podría 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, déles un volcado de base de datos donde se elimine toda la información confidencial. Entonces los desarrolladores pueden trabajar con ese volcado.

La implementación de una nueva versión no debe involucrar a ningún desarrollador, es decir, solo una tarea de administración o, mejor aún, una tarea totalmente automatizada. También tenga en cuenta que la liberación y el despliegue son dos tareas muy diferentes. Si su proceso no es consciente de eso, cámbielo en consecuencia.

Regla # 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 usted 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 sí lo es), considere crear 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 un software que administra el control de acceso más simple. Ese software está validado y verificado por la mayor cantidad de personas 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 crear un control de acceso más flexible sobre esa capa central. Este código aún tiene que ser V & Vd, pero no es tan estricto porque siempre puedes 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 mientras le brindan a su empresa la seguridad que espera. En particular, deberás aceptar que la depuración exige más privilegios de los que crees que debería, y si intentas bloquearlo, se producirán algunos desarrolladores muy enojados.

Como solución complementaria, considere la posibilidad de crear bases de datos "seguras" para realizar pruebas en las que los desarrolladores puedan eliminar 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 la seguridad y la facilidad de uso. Usted debe hacer lo propio. El equilibrio como empresa. El sistema no será perfectamente seguro y no será perfectamente utilizable. Ese balance probablemente se moverá incluso a medida que su empresa crezca y / o las demandas de los desarrolladores cambien. 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.

El despliegue de prueba solo debe tener datos de prueba. Estos pueden ser datos fantásticos 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 a 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 las máquinas de producción tuvieron que pasar por un proceso de aprobación, con un script, y fueron aprobadas por los gerentes. El equipo de dev-ops completó los despliegues reales. Supongo que este equipo era solo de empleados, y aprobó verificaciones de antecedentes. Tampoco tenían conocimiento del desarrollador, así que probablemente no podrían curiosear si quisieran. Además de esto, cifrarí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 filtraran públicamente, nadie podría leerlo. Esta clave puede protegerse mediante contraseña (PBKDF), por lo que solo un ejecutivo puede desbloquearla. Su sistema podría requerir la contraseña ejecutiva en el arranque (o más probablemente delegado 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 balances. Así es como Coca-Cola protege su fórmula. Honestamente, algunas de estas respuestas son cancelaciones.

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. Crear una valla. El acceso de solo lectura para los desarrolladores a los archivos de registro relacionados con la aplicación debería ser suficiente para la depuración. Automatice 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 propietario, mientras que utilizamos 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 host de bastión, para las operaciones registradas, la capacidad de auditoría proporciona una seguridad aceptable. Si otorga SSH, use selinux para evitar la manipulación de claves, use un host bastión con autenticación ldap / kerberos para la administración y use sudo con prudencia.