¿Las mejores prácticas de seguridad para el desarrollo y lanzamiento de software?

Los desarrolladores nunca deben tener acceso directo al entorno de producción. Desde una perspectiva de auditoría, esto es un gran no-no, ya que plantea riesgos de fraude. Además, si un desarrollador comete un error, puede eliminar sus sistemas críticos, lo que podría tener un gran impacto en su negocio.

La mejor práctica es tener 4 entornos, Desarrollo, Pruebas, Aceptación y Producción separados. Los desarrolladores pueden tener acceso a las pruebas y, en algunos casos, a la aceptación, pero NUNCA a la producción. Esto se llama el principio DTAP:

  

1. El programa o componente se desarrolla en un sistema de desarrollo. Esta   El entorno de desarrollo podría no tener capacidades de prueba.
  

2. Una vez que el desarrollador cree que está listo, el producto se copia en un   Entorno de prueba, para verificar que funciona como se espera. Esta prueba   El entorno está supuestamente estandarizado y en estrecha alineación con   el entorno de destino.

  

3. Si la prueba es exitosa, el producto se copia en una Aceptación   entorno de prueba. Durante la prueba de aceptación, el cliente probará   El producto en este entorno para verificar si cumple con sus   expectativas.

  

4. Si el cliente acepta el producto, se implementa en una Producción   medio ambiente, haciéndolo disponible para todos los usuarios del sistema.

  

Como se dijo, si un auditor ve o incluso recibe la más mínima pista de que un desarrollador puede obtener acceso a un entorno de producción, es casi seguro que se producirá un error. Si desea realizar auditorías, es mejor que lo haga una persona / organización independiente. Si desea configurar más procesos y reglamentos, consulte el marco COBIT .

Asegúrese de definir los KPI y los SLA para tener una forma de poder para hacer cumplir sus regulaciones.

por lo que estoy de acuerdo con lo que @lucaskauffman y @terrychia han dicho hasta ahora, pero aquí hay algunos consejos más que podrían ser útiles para mejorar el control sobre el entorno de desarrollo. En última instancia, deberías intentar llegar al nivel de control que menciona lucas, pero podría ser difícil venderlo directamente, así que hay algunos pasos intermedios que podrías tomar.

• Comience moviendo los desarrolladores desde el acceso de lectura-escritura a producción a solo lectura. Introduzca un proceso de control de cambios para que los cambios en los datos de producción se realicen y apliquen de manera controlada, no por desarrolladores individuales. Si los desarrolladores necesitan probar cosas, entonces introduzca un entorno de pre-producción y pruebe cosas por ahí.
• Eliminar el acceso de desarrollador al servidor. Administración de cambios para todos los cambios de código, los desarrolladores no deberían tener acceso directo de escritura al servidor de producción, una de las cosas buenas de git es que es fácil tener una copia del código, así que espero que no haya ninguna circunstancia donde el código directo Se harían cambios para producir.
• Una vez que haya personas que trabajan de esa manera, lo ideal sería que no tuvieran personas trabajando con datos en vivo, deberían trabajar con datos de muestra anonimizados, lo que reduce los riesgos de perder la información del cliente. Existen herramientas para anonimizar datos, pero incluso algo tan simple como un script que reemplaza nombres con Mr M Mouse y similares podría ayudar a reducir el impacto de que alguien se lleve una copia de la base de datos con ellos.
• si puede llegar tan lejos como este punto, entonces considere ir más lejos (por ejemplo, los modelos de estilo COBIT / ITIL)

Lo importante de todo esto es que requerirá un buen nivel de aceptación por parte de su gerencia. Todos estos pasos cuestan dinero y ralentizarán el proceso de desarrollo / prueba a corto plazo (aunque a largo plazo probablemente salvarán a toda la compañía).

Conseguir la compra puede ser complicado si la administración no ve el problema. Yo sugeriría buscar historias de terror de desarrolladores no controlados. entornos, incluso mejor si ha habido problemas en el sistema en el que está trabajando, use estos como ejemplos de cosas que podrían evitarse agregando un poco más de proceso a las cosas.

Por el amor de Dios. Nunca realice pruebas o depuración en sistemas de producción y datos ... Especialmente ya que usted es un sistema crítico y de gran volumen ...

Configure un entorno de desarrollo adecuado que duplique un subconjunto de sus datos de producción para trabajar con ... Cualquier versión nueva debe ser probada exhaustivamente por QA antes de ser eliminada en los sistemas de producción. Esto reduce en gran medida el riesgo de que un código incorrecto corrompa los datos importantes.

La mayoría de los miembros del equipo no necesitan acceso al entorno de producción. Puede y debe configurar un sistema para implementar código automáticamente después de que se haya registrado en su VCS y se haya probado ...