"Guía práctica de DevOps": notas de lectura (8)

Parte 6 Integración de prácticas técnicas para la seguridad de la información, la gestión de cambios y el cumplimiento.

En capítulos anteriores, analizamos cómo crear un flujo de trabajo rápido desde el envío del código hasta su lanzamiento, y un flujo de retroalimentación rápido a la inversa. También exploramos prácticas culturales que mejoran el aprendizaje organizacional y amplifican las señales débiles de fracaso, ayudando a crear sistemas de trabajo más seguros.

En la Parte 6, ampliaremos aún más estas actividades no solo para lograr objetivos de desarrollo y operación, sino también para lograr objetivos de seguridad de la información al mismo tiempo, garantizando y mejorando la confidencialidad, integridad y disponibilidad de servicios y datos.

No solo realizamos controles de seguridad del producto al final del proceso de desarrollo, sino que necesitamos integrar controles de seguridad en el trabajo diario de los equipos de desarrollo y operación, haciendo que la seguridad sea parte del trabajo diario de todos (tal vez esto es lo que se llama DevSecOps) . barra ). Lo ideal sería que este trabajo se automatizara y se integrara en el proceso de implementación. Además, optimizaremos las operaciones manuales y los procesos de aceptación y aprobación a través de controles automatizados, reduciendo gradualmente la dependencia de controles como la segregación de funciones y los procesos de aprobación de cambios.

No solo necesitamos mejorar la seguridad, sino que también necesitamos crear procesos que sean más auditables y demuestren la efectividad de los controles para cumplir con las obligaciones regulatorias y contractuales. Las medidas relevantes son las siguientes

• Hacer que la seguridad sea parte del trabajo de todos;
• Integrar código de control preventivo en bases de código compartidas;
• Integre la seguridad con los canales de implementación;
• Integre la seguridad con el monitoreo para una mejor detección y recuperación;
• Proteger los canales de implementación;
• Integrar las actividades de implementación con el proceso de aprobación de cambios;
• Reducir la dependencia de la separación de funciones.

Las organizaciones obtienen una mayor seguridad cuando integramos la seguridad en el trabajo diario de todos y la hacemos responsabilidad de todos. Una mayor seguridad significa que podemos proteger nuestros datos y tratarlos sabiamente. Esto, a su vez, significa confiabilidad y continuidad del negocio porque la disponibilidad es mejor y la recuperación de fallas es más fácil. Podemos abordar los problemas de seguridad antes de que ocurran consecuencias catastróficas y aumentar la previsibilidad del sistema. Quizás lo más importante es que podemos hacer un mejor trabajo que nunca a la hora de proteger nuestros sistemas y datos.

22. Integrar la seguridad de la información en el trabajo diario de todos.

El mayor obstáculo para implementar los principios y modelos de DevOps siempre ha sido " la seguridad de la información y el cumplimiento no están permitidos ". Sin embargo, dentro del flujo de valor de la tecnología, DevOps puede ser la mejor manera de integrar mejor la seguridad de la información en el trabajo diario de todos.

A lo largo de este libro, exploramos cómo integrar completamente el control de calidad y los objetivos operativos dentro del flujo de valor de la tecnología. Este capítulo presentará cómo integrar de manera similar los objetivos de seguridad de la información en el trabajo diario, mejorando así la eficiencia del personal de desarrollo, operación y mantenimiento, aumentando la seguridad del sistema y mejorando la seguridad de la información.

22.1 Integrar la seguridad en las demostraciones de iteraciones de desarrollo.

Uno de nuestros objetivos es que los equipos de funciones colaboren con el equipo de seguridad de la información lo antes posible, en lugar de esperar hasta el final del proyecto. Una forma de hacerlo es invitar al personal de seguridad de la información a una demostración del producto al final de cada intervalo de desarrollo para que puedan comprender mejor los objetivos del equipo de desarrollo en el contexto de los objetivos de la organización y observar la implementación y el proceso de construcción del equipo de desarrollo. Proporcionar orientación y retroalimentación en las primeras etapas del proyecto, lo que permite más tiempo y libertad para solucionar problemas.

Cuando el personal de seguridad de la información pasa a formar parte del equipo, incluso si participa simplemente siendo notificado y observando el proceso, obtiene la información que necesita sobre el contexto empresarial para tomar mejores decisiones sobre riesgos de seguridad. Además, el personal de seguridad de la información puede ayudar a los equipos de funciones a comprender lo que se necesita para lograr los objetivos de seguridad y cumplimiento.

22.2 Integrar la seguridad en el seguimiento de defectos y las reuniones post mortem

Si es posible, nos gusta utilizar un sistema de seguimiento de problemas para que los equipos de desarrollo y operaciones gestionen todos los problemas de seguridad conocidos para garantizar que el trabajo de seguridad sea visible y pueda priorizarse junto con otros trabajos. Esto es completamente diferente a la forma tradicional de trabajar en la gestión de la seguridad de la información. Anteriormente, todas las vulnerabilidades de seguridad se almacenaban en herramientas GRC (gobernanza, riesgo y cumplimiento) a las que solo tenía acceso el personal de seguridad de la información; ahora, pondremos todo el trabajo a realizar en las herramientas utilizadas por desarrollo y operaciones en el sistema.

"Celebramos reuniones post mortem cada vez que surge un problema de seguridad porque educa mejor a los ingenieros sobre cómo evitar que el problema vuelva a ocurrir y es un excelente mecanismo para transferir conocimientos de seguridad al equipo de ingeniería".

22.3 Integrar controles de seguridad preventivos en bibliotecas de código fuente compartido y servicios compartidos

En el Capítulo 20, creamos un repositorio de código fuente compartido que facilita que cualquiera pueda encontrar y reutilizar el conocimiento colectivo de la organización: no solo código, sino también cadenas de herramientas, canales de implementación, estándares y más. Esto permite que todos se beneficien de la experiencia colectiva acumulada por todos en la organización. Ahora agregamos a la base de código fuente compartido cualquier mecanismo y herramienta que ayude a garantizar la seguridad de nuestras aplicaciones y entornos. Agregaremos bibliotecas protegidas por seguridad que cumplan objetivos específicos de seguridad de la información, como bibliotecas y servicios de autenticación y cifrado.

Si existe una organización de servicios compartidos centralizada, también puede colaborar con ella para crear y ejecutar servicios de plataforma compartida relacionados con la seguridad, como autenticación, autorización, registro y otros servicios de seguridad y auditoría necesarios para el desarrollo y las operaciones. Cuando los ingenieros desarrollan algunos módulos de aplicaciones que utilizan estas bibliotecas o servicios predefinidos, ya no necesitan organizar una revisión del diseño de seguridad por separado, sino que utilizarán la información que creamos sobre el refuerzo de la configuración, los ajustes de seguridad de la base de datos, la longitud de la clave, etc., pautas de seguridad.

Para que los servicios y bibliotecas proporcionados se utilicen lo más correctamente posible, podemos brindar capacitación en seguridad a los equipos de desarrollo, operación y mantenimiento y ayudarlos a revisar los productos del proyecto para garantizar la correcta implementación de los objetivos de seguridad, especialmente cuando el equipo utiliza estos por primera vez.hora de la herramienta.

Nuestro objetivo final es proporcionar bibliotecas o servicios de seguridad necesarios para cualquier aplicación o entorno moderno, como permitir la autenticación de usuarios, autorización, gestión de contraseñas, cifrado de datos, etc. Además, puede proporcionar una configuración eficiente de los aspectos de seguridad de los componentes utilizados en la pila de aplicaciones para los equipos de desarrollo y operaciones, como el registro, la autenticación y el cifrado. También puede incluir el siguiente contenido relacionado:

• La base del código y su configuración recomendada [por ejemplo, 2FA (biblioteca de autenticación de dos factores), hash de contraseñas de bcrypt, registro];
• Utilice Vault, Sneaker, Keywhiz, credstash, Trousseau, Red October y otras herramientas para la gestión de claves secretas y contraseñas (como configuraciones de conexión, claves de cifrado);
• Paquetes y compilaciones del sistema operativo (por ejemplo, NTP para sincronización horaria, versiones seguras configuradas correctamente de OpenSSL, OSSEC o Tripwire para monitoreo de integridad de archivos) para garantizar que los registros de seguridad críticos se registren en una configuración de registro de syslog del sistema ELK centralizada en ).

También debemos trabajar con el equipo de operaciones para crear manuales de configuración básica o crear imágenes de sistemas operativos, bases de datos y otra infraestructura (por ejemplo, NGINX, Apache, Tomcat) para garantizar que todos estén en un entorno conocido, seguro y de bajo riesgo. estado . El repositorio de código fuente compartido no es solo el lugar para obtener la última versión, sino también el lugar para colaborar con otros ingenieros y monitorear y alertar sobre cambios en módulos sensibles a la seguridad.

22.4 Integrar la seguridad en el proceso de implementación

Anteriormente, para reforzar una aplicación, empezábamos una revisión de seguridad una vez completado el trabajo de desarrollo. Normalmente, el desarrollo y las operaciones pueden recibir cientos de páginas de documentos PDF que describen diversas vulnerabilidades de seguridad. Estos problemas terminan siendo difíciles de solucionar porque se descubren demasiado tarde en el ciclo de vida del software y se ha perdido la oportunidad de solucionarlos fácilmente, o debido a la presión de los plazos del proyecto.

Ahora, en este paso automatizaremos la mayor cantidad posible de pruebas de seguridad de la información. De esta manera, (idealmente) las pruebas de seguridad se pueden ejecutar junto con todas las demás pruebas en el proceso de implementación cada vez que un desarrollador o personal de operaciones confirma código, incluso en las primeras etapas de un proyecto de software.

Nuestro objetivo es proporcionar comentarios rápidos a los desarrolladores y al personal de operaciones para que puedan recibir notificaciones cuando envíen cambios que presenten riesgos de seguridad. De esta manera, los problemas de seguridad se pueden detectar y solucionar rápidamente, y esta parte del trabajo se puede integrar en el trabajo diario para evitar que se repitan problemas durante el aprendizaje.

Idealmente, estas pruebas de seguridad automatizadas se ejecutarían en paralelo con otras herramientas de análisis de código estático en el proceso de implementación.

Herramientas como Gauntlt estas se pueden integrar en procesos de implementación para realizar pruebas de seguridad automatizadas de aplicaciones, dependencias de aplicaciones, entornos y más. Vale la pena señalar que todas las pruebas de seguridad de Gauntlt utilizan scripts de prueba en formato de sintaxis Gherkin, que los desarrolladores utilizan ampliamente para pruebas unitarias y funcionales.

22.5 Garantizar la seguridad de la aplicación

Por lo general, las pruebas durante la fase de desarrollo se centran en la corrección de la funcionalidad, centrándose en el flujo lógico correcto. Este tipo de prueba a menudo se denomina camino feliz y verifica el flujo normal de operaciones del usuario (a veces hay varias rutas alternativas): todo funciona como se esperaba, sin excepciones ni condiciones de error. Por otro lado, el personal de control de calidad, el personal de seguridad de la información y los estafadores a menudo se centran en el camino triste , que ocurre cuando las cosas van mal, especialmente en relación con condiciones de error relacionadas con la seguridad. (Este tipo de condición específica de seguridad a menudo se denomina en broma un mal camino .

Por ejemplo, considere un sitio web de comercio electrónico donde los clientes ingresan su número de tarjeta de crédito en un formulario al realizar un pedido. Queremos definir todos los caminos desagradables y malos para garantizar que las tarjetas de crédito no válidas sean rechazadas, evitando así fraudes y violaciones de seguridad como inyección SQL, desbordamientos de búfer y otras consecuencias indeseables.

Idealmente, generamos esto como parte de pruebas unitarias o funcionales automatizadas en lugar de ejecutarlas manualmente para que estas pruebas se puedan ejecutar continuamente en el proceso de implementación. Esperamos incluir lo siguiente como parte de las pruebas.

• Análisis estático : esta es la prueba que realizamos en un entorno que no es de tiempo de ejecución, lo que se espera en el proceso de implementación. Normalmente, las herramientas de análisis estático examinarán el código del programa en busca de todos los posibles comportamientos en tiempo de ejecución y buscarán fallas de codificación, puertas traseras y códigos potencialmente maliciosos (a veces llamados "pruebas de adentro hacia afuera"). Dichas herramientas incluyen Brakeman, Code Climate y funciones de búsqueda de código suprimido (por ejemplo, exec()).
• Análisis dinámico : a diferencia de las pruebas estáticas, el análisis dinámico consta de una serie de pruebas que se ejecutan mientras el programa se ejecuta. Las pruebas dinámicas monitorean elementos como la memoria del sistema, el comportamiento funcional, el tiempo de respuesta y el rendimiento general del sistema. Este enfoque (a veces llamado " prueba de afuera hacia adentro ") actúa como si un tercero malintencionado estuviera interactuando con la aplicación. Estas herramientas incluyen Arachni y OWASP ZAP (Zed Attack Proxy). Algunas pruebas de penetración también pueden automatizarse y deben usarse como parte de herramientas de análisis dinámico como Nmap y Metasploit. Idealmente, las pruebas dinámicas automatizadas deberían realizarse durante la fase de pruebas funcionales automatizadas del proceso de implementación, o incluso contra servicios en producción. Para garantizar la eficacia de las medidas de seguridad, se pueden configurar herramientas como OWASP ZAP como un proxy de navegador para el servicio de ataque y el tráfico de red se puede ver en la herramienta de prueba.
• Escaneo de componentes de dependencia : este es otro tipo de prueba estática que generalmente se ejecuta en el proceso de implementación en el momento de la compilación. Realiza un inventario de todos los paquetes y bibliotecas de los que dependen los archivos binarios y ejecutables y garantiza que estos componentes dependientes (sobre los que generalmente no tenemos control) estén libres de vulnerabilidades o archivos binarios maliciosos. Gemnasium y la auditoría de paquetes para Ruby, Maven para Java y la verificación de dependencias de OWASP son algunos ejemplos.
• Integridad del código fuente y firma de código : todos los desarrolladores deben tener sus propias claves PGP que puedan crearse y administrarse en un sistema como keybase.io. Todo lo comprometido con un sistema de control de versiones debe estar firmado y configurado directamente utilizando las herramientas de código abierto gpg y git. Además, todos los paquetes creados por CI deben firmarse y sus hashes deben registrarse en un servicio de registro centralizado para fines de auditoría.

Además, debemos definir patrones de diseño que ayuden a los desarrolladores a escribir código que prevenga el abuso, como establecer límites de velocidad para los servicios y convertir un botón de envío presionado en un estado en el que no se puede hacer clic. OWASP publica una gran cantidad de orientación útil, como la serie Cheat Sheet, que incluye lo siguiente:

• Cómo almacenar contraseñas;
• Cómo lidiar con contraseñas olvidadas;
• Cómo manejar la tala;
• Cómo prevenir vulnerabilidades de secuencias de comandos entre sitios (XSS).

22.6 Asegurar la cadena de suministro de software

Josh Corman señaló que, como desarrolladores, "ya no escribimos software personalizado, sino que ensamblamos los componentes de código abierto que necesitamos, lo que se ha convertido en una cadena de suministro de software de la que dependemos mucho". En otras palabras, cuando utilizamos varios componentes o bibliotecas (comerciales o de código abierto) en nuestro software, heredamos no solo su funcionalidad, sino también cualquier vulnerabilidad de seguridad asociada .

Al seleccionar software, detectamos si los proyectos de software se basan en componentes o bibliotecas con vulnerabilidades conocidas y ayudamos a los desarrolladores a elegir cuidadosamente qué componentes utilizar: eligiendo componentes que hayan sido probados en el pasado y cuyas vulnerabilidades de software se puedan solucionar rápidamente (como el código abierto). proyectos). También necesitamos identificar múltiples versiones de bibliotecas utilizadas en producción, especialmente versiones anteriores con vulnerabilidades conocidas.

22.7 Garantizar un entorno seguro

Durante este paso se debe realizar cualquier trabajo que pueda ayudar a endurecer el medio ambiente y reducir los riesgos. Aunque es posible que hayamos establecido una buena configuración conocida, debemos garantizar mediante el monitoreo que todos los servidores de producción coincidan con estos buenos estados conocidos. Utilizamos pruebas automatizadas para garantizar que todas las configuraciones necesarias se hayan aplicado correctamente, incluida la configuración de refuerzo de seguridad, la configuración de seguridad de la base de datos, la longitud de la clave, etc. Además, utilizaremos pruebas para escanear el entorno en busca de vulnerabilidades conocidas.

Otro tipo de método de verificación de seguridad es comprender el entorno real (es decir, el "estado real"). Dichas herramientas incluyen Nmap para garantizar que solo los puertos esperados estén abiertos y herramientas para garantizar que las vulnerabilidades conocidas específicas se hayan protegido adecuadamente Metasploit, como el escaneo en busca de ataques de inyección SQL. El resultado de estas herramientas debe colocarse en un repositorio de artefactos y compararse con versiones anteriores como parte del proceso de prueba funcional. De esta manera, si se producen cambios no deseados, se pueden detectar inmediatamente.

22.8 Integración de la seguridad de la información en la telemetría de producción

Los controles de seguridad internos a menudo no logran detectar violaciones de manera exitosa y oportuna. Esto se debe a puntos ciegos en el monitoreo o a que nadie en la organización verifica la telemetría relevante a diario.

Implementamos los sistemas de monitoreo, registro y alerta necesarios para lograr plenamente los objetivos de seguridad de la información en todas las aplicaciones y entornos, y garantizar que estén lo suficientemente centralizados para un análisis y una respuesta simples y significativos.

Al integrar la telemetría de seguridad en las herramientas utilizadas por el desarrollo, el control de calidad y las operaciones, todos en el flujo de valor pueden ver cómo se comportan las aplicaciones y los entornos en respuesta a amenazas maliciosas, incluidos los atacantes que intentan continuamente explotar vulnerabilidades y obtener consecuencias imprevistas. puertas traseras, fraude, denegación de servicio y otras actividades de sabotaje.

Exponer públicamente el proceso de ataque de un servicio en producción obliga a todos a considerar los riesgos de seguridad y diseñar contramedidas en su trabajo diario.

22.9 Creación de un sistema de telemetría seguro en su aplicación

El comportamiento cuestionable del usuario puede revelar o desencadenar fraude y acceso no autorizado y, para detectarlo, se deben crear sistemas de telemetría relevantes dentro de la aplicación. Ejemplos incluyen:

• Inicios de sesión de usuarios exitosos y fallidos;
• Restablecimiento de contraseña de usuario;
• Restablecimiento de la dirección de correo electrónico del usuario;
• Cambios en la tarjeta de crédito del usuario

22.10 Establecimiento de sistemas de telemetría seguros en su entorno

Además de perfeccionar la aplicación, es necesario crear un sistema de telemetría integral en el entorno para permitir la detección temprana de signos de acceso no autorizado, especialmente para componentes que se ejecutan en infraestructura no controlada (por ejemplo, entornos alojados, nube).

Necesitamos monitorear y alertar sobre ciertos eventos, que incluyen:

• cambios en los sistemas operativos (por ejemplo, en entornos de producción, en infraestructura de construcción);
• Cambios en los grupos de seguridad;
• Cambios de configuración (por ejemplo, OSSEC, Puppet, Chef, Tripwire);
• Cambios en la infraestructura de la nube (por ejemplo, VPC, grupos de seguridad, usuarios y permisos);
• Intentos XSS (es decir, "ataques de secuencias de comandos entre sitios");
• Intentos de SQLi (es decir, "ataques de inyección SQL");
• Errores del servidor web (por ejemplo, errores 4XX y 5XX).

También queremos confirmar que el registro esté configurado correctamente para que toda la información de telemetría se envíe al lugar correcto. Al monitorear ataques, además de registrar eventos, también puede optar por interceptar el acceso y guardar información sobre el origen y el objetivo del acceso para ayudarnos a elegir las mejores medidas evasivas.

22.11 Asegurar el proceso de implementación

La infraestructura que respalda los procesos de integración y despliegue continuos también se ha convertido en una nueva área de vulnerabilidad. Por ejemplo, si alguien compromete el servidor que ejecuta una canalización de implementación que almacena información de inicio de sesión para un sistema de control de versiones, puede robar el código fuente del programa. Peor aún, si una cuenta en el proceso de implementación tiene acceso de escritura, un atacante podría inyectar cambios maliciosos en el sistema de control de versiones y, por tanto, en las aplicaciones y servicios.

Para proteger completamente la integridad de las aplicaciones y los entornos, también se deben reducir los vectores de ataque contra el proceso de implementación. Los riesgos incluyen que los desarrolladores introduzcan código que dé como resultado un acceso no autorizado (mitigado por controles como pruebas de código, revisiones de código y pruebas de penetración) y usuarios no autorizados que obtengan acceso a aplicaciones o entornos (mitigado por controles tales como: garantizar que la configuración esté siempre en un formato conocido)
. y buen estado, parchado con prontitud y eficacia)

Sin embargo, para proteger su proceso continuo de construcción, integración o implementación, las medidas de mitigación de riesgos también pueden incluir:

• Fortalezca sus servidores de integración y construcción continua y asegúrese de que puedan reconstruirse de manera automatizada, al igual que su infraestructura de servicios de producción de cara al cliente, para evitar infracciones en sus servidores de integración y construcción continua;
• Revise cualquier cambio confirmado en el sistema de control de versiones, ya sea programando pares en el momento de la confirmación o configurando un proceso de revisión de código entre confirmaciones y fusiones troncales, para evitar que el servidor de integración continua ejecute código no controlado (por ejemplo, las pruebas unitarias pueden contener código malicioso que permite o provoca acceso no autorizado);
• Detectar cuándo el código de prueba que contiene llamadas API sospechosas (por ejemplo, pruebas unitarias que acceden al sistema de archivos o a la red) se registra en la base del código y luego se puede aislar inmediatamente y desencadenar una revisión del código;
• Asegúrese de que cada proceso de CI se ejecute en su propio contenedor aislado o máquina virtual;
• Asegúrese de que las credenciales de control de versiones utilizadas por el sistema CI sean de solo lectura.

22.12 Resumen

Este capítulo describe formas de integrar los objetivos de seguridad de la información en todas las fases del trabajo diario. Esto es para garantizar que todos los entornos bajo demanda estén en un estado reforzado y de bajo riesgo mediante la integración de controles de seguridad en los mecanismos que se han creado, y para garantizar que se creen sistemas de telemetría seguros en los entornos de preproducción y producción mediante la integración de la seguridad. pruebas en el proceso de implementación. De esta manera, podemos mejorar la seguridad general al mismo tiempo que mejoramos la eficiencia del desarrollo, la operación y el mantenimiento. A continuación, aseguraremos el proceso de implementación.

23. Proteger el proceso de implementación

Este capítulo explora cómo proteger los procesos de implementación y lograr objetivos de seguridad y cumplimiento dentro de un entorno controlado, incluida la gestión de cambios y la segregación de funciones.

23.1 Integrar la seguridad y el cumplimiento en el proceso de aprobación de cambios

Casi todas las organizaciones de TI de cierto tamaño tienen su propio proceso de gestión de cambios, que es el principal método de control para reducir los riesgos operativos y de seguridad. Los gerentes de cumplimiento y de seguridad dependen de los procesos de gestión de cambios para satisfacer las necesidades de cumplimiento y, a menudo, requieren evidencia de que todos los cambios han sido autorizados adecuadamente.

Si el proceso de implementación se construye correctamente para reducir el riesgo de implementación, la mayoría de los cambios no necesitarán pasar por un proceso de aprobación manual porque dependeremos de controles como pruebas automatizadas y monitoreo proactivo del entorno de producción.

En este paso, tomaremos medidas para garantizar que la seguridad y el cumplimiento se integren exitosamente en cualquier proceso de gestión de cambios existente. Una política eficaz de gestión del cambio reconocerá que diferentes tipos de cambios plantean diferentes riesgos y que existen diferentes maneras de afrontar los diferentes cambios. ITIL define estos procesos y divide los cambios en los siguientes tres tipos.

• Cambio estándar : un cambio de bajo riesgo que sigue un proceso de aprobación establecido, pero que también puede ser aprobado previamente. Los cambios de este tipo incluyen actualizaciones mensuales de las tablas de impuestos de las aplicaciones o códigos de país, cambios de contenido y estilo en el sitio web y parches de aplicaciones o sistemas operativos con impacto conocido. Los solicitantes de cambios no necesitan aprobación antes de implementar los cambios. La implementación de cambios se puede automatizar completamente y se deben dejar registros para su trazabilidad.
• Cambios de rutina : cambios que son de mayor riesgo y requieren revisión o aprobación por parte de una autoridad. En muchas organizaciones, no es razonable poner las responsabilidades de aprobación en manos de una Junta Asesora de Cambios (CAB) o una Junta Asesora de Cambios de Emergencia (ECAB), ya que pueden carecer de la experiencia necesaria para comprender el impacto total del cambio, lo que a menudo resulta en intolerable Largos plazos de entrega. Este problema es particularmente grave para implementaciones de código a gran escala. Las implementaciones a gran escala pueden implicar cientos de miles (o incluso millones) de líneas de código comprometidas por cientos de desarrolladores a lo largo de varios meses de desarrollo. Para completar la autorización de cambios de rutina, es casi seguro que la Junta Asesora de Cambios requerirá una solicitud de cambio (RFC) claramente definida para proporcionar la información necesaria para tomar decisiones. Una solicitud de cambio generalmente contiene los resultados comerciales deseados, la efectividad y seguridad del plan, un caso de negocios que describe los riesgos y las opciones de mitigación, y un cronograma recomendado.
• Cambios de emergencia : los cambios que deben implementarse en el entorno de producción inmediatamente en caso de emergencia (por ejemplo, parches de seguridad de emergencia, restauración de servicios) son cambios potencialmente de alto riesgo. Estos cambios normalmente requieren la aprobación de la alta dirección, pero también es posible implementar los cambios primero y agregar documentación más tarde. Un objetivo clave de las prácticas de DevOps es optimizar los procesos de cambio de rutina para que funcionen igualmente bien en cambios de emergencia.

23.2 Reclasificar una gran cantidad de cambios de bajo riesgo como cambios estándar

Idealmente, al establecer un proceso de implementación sólido, hemos desarrollado una reputación de implementaciones rápidas, confiables y no dramáticas. Sobre esta base, el departamento de operación y mantenimiento y las organizaciones de cambio relevantes deben estar convencidos de que los cambios que realizamos tienen un riesgo bajo y pueden clasificarse como cambios estándar aprobados previamente por el Consejo Asesor de Cambios. Esto permite la implementación directamente en producción sin necesidad de aprobación adicional, aunque, por supuesto, los cambios aún deben documentarse correctamente.

Para demostrar que un cambio es de bajo riesgo, una buena idea es mostrar un historial de cambios durante un largo período de tiempo (por ejemplo, meses o trimestres) y compilar una lista completa de problemas en producción durante el mismo período. Si podemos demostrar una alta tasa de éxito del cambio y un tiempo medio de recuperación (MTTR) bajo, podemos afirmar que tenemos un entorno controlado que previene eficazmente los errores de implementación y demuestra la capacidad de detectar y corregir rápidamente cualquier problema.

Incluso si estos cambios se clasifican como cambios estándar, aún deben registrarse en un sistema de gestión de cambios (por ejemplo, Remedy o ServiceNow) con fines de gestión visual. Idealmente, las implementaciones se automatizarán utilizando herramientas de administración de configuración y herramientas de canalización de implementación (por ejemplo, Puppet, Chef, Jenkins), y los resultados de la implementación se registrarán automáticamente. De esta manera, todos en la organización (DevOps o no) están al tanto de nuestros cambios y también de todos los demás cambios que ocurren en la organización.

Establecer esta trazabilidad y contexto debería ser fácil y no debería sobrecargar a los ingenieros con un trabajo demasiado pesado o que requiera mucho tiempo. Vincular historias de usuarios, requisitos o defectos es casi completamente suficiente; más detalles (por ejemplo, crear un ticket para cada confirmación de código en un sistema de control de versiones) pueden no ser significativos o necesarios, ya que agregarían una resistencia significativa a las tareas diarias.

23.3 Cómo manejar los cambios generales

Los cambios que no pueden clasificarse como cambios estándar son cambios de rutina y requieren la aprobación de al menos algunos miembros del Consejo Asesor de Cambios antes de su implementación. En este caso, incluso si la implementación no está completamente automatizada, el objetivo sigue siendo garantizar una implementación rápida.

En este caso, es importante asegurarse de que la solicitud de cambio enviada sea lo más completa y precisa posible, proporcionando al Consejo Asesor de Cambios toda la información necesaria para una evaluación adecuada. Si una solicitud de cambio tiene un formato incorrecto o tiene información incompleta, será rechazada, lo que, además de aumentar el tiempo que lleva llegar a producción, también puede generar dudas sobre si realmente entendemos los verdaderos objetivos del proceso de gestión de cambios.

Básicamente, podemos automatizar la creación de solicitudes de cambio completas y precisas, completando los tickets con los detalles de cambio correctos. Por ejemplo, puede automatizar la creación de un ticket de cambio de ServiceNow e incluir enlaces a las historias de usuario en JIRA, el manifiesto de compilación y el resultado de la prueba de la herramienta de canalización de implementación, y enlaces a los scripts de Puppet/Chef que se ejecutarán.

Una vez que se envía una solicitud de cambio, los cambios serán revisados, procesados ​​y aprobados por los miembros relevantes del Consejo Asesor de Cambios. Todas las solicitudes de cambio se manejan de la misma manera. Si todo va bien, la organización de cambio aprecia la minuciosidad y la riqueza de detalles de la orden de cambio porque les permitimos verificar rápidamente la exactitud de la información que enviamos (por ejemplo, ver los artefactos a los que se vincula la herramienta de canalización de implementación). Sin embargo, el objetivo debe ser demostrar consistentemente un historial de cambios exitosos para que eventualmente estén de acuerdo en que los cambios automatizados pueden clasificarse de manera segura como cambios estándar.

23.4 Reducir la dependencia de la separación de funciones

Durante décadas, hemos utilizado la segregación de funciones como uno de los controles principales para reducir el riesgo de fraude o errores durante el desarrollo de software. Es una práctica aceptada en la mayoría de los ciclos de vida de desarrollo de software exigir que los cambios del desarrollador se envíen a un administrador del repositorio para su revisión y aprobación, y luego a Operaciones de TI para implementar los cambios en producción.

Cuando el entorno de producción se implementa con poca frecuencia (por ejemplo, una vez al año) y el trabajo no es complejo, la división del trabajo y la transferencia del trabajo son métodos comerciales viables. Sin embargo, a medida que aumentan la complejidad y la frecuencia de implementación, la ejecución exitosa de implementaciones de producción requiere cada vez más que todos en el flujo de valor puedan ver rápidamente los resultados del trabajo que se está realizando.

La separación de funciones puede obstaculizar los requisitos anteriores al ralentizar y reducir la capacidad de los ingenieros para recibir comentarios sobre su trabajo. Esto impide que los ingenieros asuman plena responsabilidad por la calidad de su trabajo y reduce la capacidad de la empresa para crear aprendizaje organizacional.

Por lo tanto, cuando sea posible, debe evitarse el uso de la separación de funciones como medio de control. Deberíamos elegir programación en pares, verificación continua de códigos y revisión de códigos, etc., que pueden brindar la garantía necesaria para la calidad del trabajo. Además, después de implementar estos controles, si se requiere separación de funciones, podemos demostrar que los controles que hemos creado logran los mismos resultados.

23.5 Garantizar que se conserve la documentación y la evidencia para los auditores y el personal de cumplimiento.

A medida que las organizaciones tecnológicas adoptan cada vez más modelos DevOps, la relación entre TI y auditoría se ha vuelto más tensa que nunca. Estos nuevos modelos DevOps desafían el pensamiento tradicional sobre auditoría, controles y prevención de riesgos.

23.6 Resumen

Este capítulo analiza prácticas para responsabilizar a todos por la seguridad de la información, integrando todos los objetivos de seguridad de la información en el trabajo diario de todos en el flujo de valor. Esto aumenta significativamente la eficacia de los controles, lo que permite una mejor prevención de las violaciones de seguridad y una detección y recuperación más rápidas de las violaciones de seguridad. Además, se reduce significativamente el tiempo dedicado a prepararse y aprobar las auditorías de cumplimiento.

23.7 Resumen de la Parte 6

La Parte 6 explora cómo se pueden aplicar los principios de DevOps a la seguridad de la información para ayudarnos a alcanzar nuestros objetivos y garantizar que la seguridad sea parte de la rutina diaria de todos. Una mayor seguridad garantiza que protejamos los datos, los tratemos con prudencia y los recuperemos antes de que los problemas de seguridad conduzcan a un desastre. Lo más importante es que podemos hacer que los sistemas y los datos sean más seguros que nunca.

24. Tomar acción – Resumen del libro

Hemos analizado en detalle los principios y prácticas técnicas de DevOps. En esta era de frecuentes violaciones de seguridad, ciclos de entrega más cortos y transformación tecnológica a gran escala, DevOps surgió cuando los líderes tecnológicos deben abordar simultáneamente los desafíos de seguridad, confiabilidad y flexibilidad. Espero que este libro pueda ayudar a los lectores a comprender profundamente el problema y encontrar soluciones al mismo.

Como siempre se ha enfatizado en este libro, si no se gestionan adecuadamente, los conflictos entre los desarrolladores y el personal de operaciones empeorarán día a día, lo que resultará en mucho tiempo para lanzar nuevos productos y funciones, calidad deficiente, mayor desgaste, acumulación de deuda técnica y pérdida de productividad. Si la situación es baja, la insatisfacción y el agotamiento de los empleados serán cada vez más graves.

Los principios y patrones de DevOps pueden resolver este conflicto central. Después de leer este libro, espero que los lectores comprendan cómo la transformación DevOps puede crear una organización que aprende, cómo acelerar los procesos, crear productos de seguridad y confiabilidad de primera clase y cómo mejorar la competitividad corporativa y la satisfacción de los empleados.

La práctica de DevOps requiere una nueva cultura corporativa y normas de gestión, y también cambiará las prácticas técnicas y la arquitectura. La colaboración entre departamentos es crucial, incluida la gestión, la gestión de productos, los equipos de desarrollo, los equipos de control de calidad, las operaciones de TI, la seguridad de la información e incluso el personal de marketing. Sólo trabajando juntos todos los departamentos pueden crear de forma eficaz un sistema de trabajo seguro. Esto ayuda a los equipos pequeños de forma rápida y sencilla. Desarrollar, verificar e implementar de forma independiente código relacionado con el servicio al cliente de forma independiente, y sólo entonces será posible la innovación tecnológica. Este enfoque maximiza la productividad, la motivación, la satisfacción y la capacidad de la organización para ganar en el mercado.

Conocemos los peligros de dormirnos en los laureles y la dificultad de cambiar los hábitos de trabajo diarios, pero también entendemos los riesgos y costos de introducir nuevas formas de trabajar en las organizaciones. También sabemos que DevOps es solo un grano de sal en la larga historia y pronto será reemplazado por nuevos métodos populares.

Pero creemos firmemente que DevOps transformará la industria tecnológica del mismo modo que Lean transformó la fabricación en los años 1980. Aquellas organizaciones que adopten DevOps ganarán en el mercado y aquellas que rechacen DevOps pagarán el precio. Las organizaciones que adoptan DevOps crean organizaciones de aprendizaje apasionadas por la mejora continua e innovan para superar a sus competidores.

Por lo tanto, DevOps no es sólo un imperativo técnico sino también un imperativo organizacional. El punto más crítico es que DevOps es universal y está especialmente indicado para organizaciones que deben mejorar los procesos de trabajo a través de medios técnicos garantizando al mismo tiempo la alta calidad, confiabilidad y seguridad de los productos.

No seas cínico al respecto. Las personas involucradas en el cambio entienden que, por supuesto, pueden fracasar en lo que hacen, pero independientemente del éxito o el fracaso, siempre lo intentan. La mayor importancia de intentarlo es inspirar a otros a través de la práctica. La innovación no puede tener éxito sin asumir riesgos. Si no está molestando a alguna gerencia, probablemente no se esté esforzando lo suficiente. No permita que el sistema inmunológico de su organización bloquee o interfiera con su visión. Como dijo el ex “maestro de los desastres” de Amazon, Jesse Robbins: “Haz lo correcto y serás despedido”.

DevOps beneficiará enormemente a todos los participantes en el flujo de valor de la tecnología, ya sean desarrolladores, ingenieros de operaciones, ingenieros de control de calidad, personal de seguridad de la información, gerentes de productos o clientes, puede brindarnos la capacidad de desarrollar excelentes productos y el placer de producirlos. Proporciona condiciones de trabajo humanas y nos permite pasar más tiempo con nuestros seres queridos. Permite a los equipos trabajar juntos, aprender, crecer, deleitar y beneficiar a los clientes, mientras ayuda a la organización a tener éxito.