Contenido


DevOps con controles

Releases más rápidos con las plataformas de infraestructura en la nube

Comments

Introducción

Muchas empresas se desplazan hacia un abordaje de DevOps, donde los despliegues de software y las operaciones en curso de entornos de producción se encuentran incorporados en el ciclo de vida del desarrollo de software. En lugar de lanzar el código completo sobre el muro, desde el desarrollo hasta las operaciones cuando el software esté listo para el release en entornos de producción, DevOps incorpora el release a la producción dentro del proceso de release completo. Esto generalmente se basa en tener una infraestructura programable, tal como la nube y la red definida por software (SDN), de modo que todo el entorno se defina como código. Solamente las plataformas de infraestructura en la nube cumplen con este requisito.

Al utilizar DevOps, las empresas pueden moverse más rápidamente que nunca. Con los constantes cambios dinámicos en la nube, es difícil para las partes interesadas clave en TI, operaciones y seguridad tener la seguridad de que se cumplen las políticas corporativas de conformidad. Aplicar un abordaje de automatización orientado a eventos, centrado en el descubrimiento puede brindar a las organizaciones la configuración de los controles que necesitan para mantenerse seguras en la nube.

Visión general rápida de DevOps

DevOps es un abordaje que despliega software rápidamente cuando se ponen a disposición nuevos releases. Una de las metas primarias de DevOps es ayudar a las organizaciones que se muevan rápidamente. Nuevos releases se exponen a usuarios, clientes y usuarios del mundo real tan pronto como sea posible y se prueban para obtener funcionalidad y valor con el objetivo de incrementar el beneficio de la aplicación. La mayoría de las organizaciones utiliza una infraestructura de nube como el entorno operativo para sus equipos de DevOps. Un proceso simplificado podría incluir las siguientes etapas:

  1. Confirmar el código.
  2. Empaquetar automáticamente la aplicación para implementación.
  3. Ejecutar un conjunto de pruebas de regresión para la verificación del código y pruebas aleatorias para la preparación del entorno de producción. Ejecutar otras pruebas, tales como detectar la seguridad/vulnerabilidad.
  4. Dependiendo de los resultados de la prueba:
    • Pruebas que fallaron: Genere alertas y registros para los equipos de desarrollo, operaciones y seguridad. Regresa a la codificación.
    • Pruebas pasadas: Lanzar automáticamente a producción.
  5. Ejecutar en producción hasta el próximo release.

Todo este proceso, desde el principio al fin, menudo se conoce como una rutina de DevOps o playbook.

Pero no todos los equipos de DevOps saben cómo aprovisionar la infraestructura correctamente para mantenerla de acuerdo con los requisitos de seguridad y conformidad de la organización. Y para añadir más complejidad, la mayoría de los abordajes de DevOps incluyen el siguiente mecanismo de mitigación para cualesquier problema: Revertir todo el entorno. Los playbooks de DevOps casi siempre incluyen mecanismos de reversión.

Figura 1. El playbook de DevOps
development, build, test, delivery
development, build, test, delivery

Por Medrecs (trabajo propio) [CC BY-SA 4.0 (http://creativecommons.org/licenses/by-sa/4.0)], vía Wikimedia Commons

La nube para DevOps

La nube está posicionada de manera única para funcionar como la infraestructura para un abordaje de DevOps por muchas razones, que incluyen:

  • La nube se define por software; es programable y flexible.
  • La nube se acciona por software y tiene muchas capas. El cliente es responsable por cada capa y debe diseñarla, desde la configuración para la cuenta de servicios y credenciales hasta la protección de los datos y los valores de cifrado.
  • La infraestructura de la nube se factura, por lo general, en un modelo por estilo de utilidad, pague según el uso. Esto significa que los costos de ejecución de la aplicación total se pueden determinar separadamente, y las compañías pueden hacer cálculos de ROI precisos para determinar el valor de una aplicación.

Adopción de la nube

La mayoría de las organizaciones piensan que pueden utilizar una infraestructura de nube similar a la que utilizan con la infraestructura de TI — específicamente a través de un equipo centralizado de TI. Sin embargo, los abordajes como: catálogos de servicios, plantillas de suministro y el acceso limitado a la consola fallan a escala, porque las necesidades de los distintos equipos son muy diversas, y TI lucha por mantenerse al día con ellas. Eventualmente, la adopción seria de la nube se vuelve descentralizada, y muchos equipos acceden a la infraestructura de la nube. Esto el problema fundamental: No todos estos equipos son expertos en infraestructura. Y muchos simplemente no saben o no entienden los requisitos de seguridad de la organización o cómo implementarlos en entornos de nube definidos por software. Cuando se combina con la complejidad de las grandes empresas, unidades comerciales, equipos distribuidos y varios regímenes de conformidad, este problema se vuelve más y más difícil de gestionar a escala.

El abordaje de DevOps para resolver los problemas

Muchos equipos de DevOps automatizan ambos despliegues y retrotracción de nuevas aplicaciones y releases de aplicaciones. De modo que si identifican un problema, se derriba todo el entorno.

Este derribo completo a menudo implica tiempo de inactividad para el entorno, seguido por un análisis exhaustivo del origen. Al mismo tiempo que éste es un buen ejercicio para la mejora organizacional a largo plazo, es un desafío para la disponibilidad inmediata de la aplicación.

El desafío secundario es que la cobertura de la prueba podría no incluir cada condición que se debería considerar para tomar la decisión de mantener o revertir. Las pruebas, con frecuencia, se enfocan en el comportamiento de la aplicación, correcciones de códigos y, algunas veces, en la evaluación de la seguridad. Los equipos de desarrollo tienden a dominar los grupos de DevOps, sin embargo, pueden carecer de los antecedentes para verificar la optimización o configuración de la infraestructura.

Implementar un conjunto de controles de seguridad y configuración (a veces referido como rieles de seguridad) puede brindar a los ejecutivos clave la protección y tranquilidad que necesitan para permitir que los equipos de DevOps operen rápidamente, sin poner a la organización en riesgo.

Percepción de seguridad de DevOps

La principal preocupación que las grandes organizaciones tienen acerca de DevOps es la falta de enfoque en la seguridad. Esto es, con frecuencia, una compensación consciente: Permitir que los equipos de DevOps se muevan rápidamente porque están trabajando en nuevos riesgos críticos para la organización. Sin embargo, frecuentemente se sacrifica, de modo que los equipos y sus entornos no se limiten.

Seguridad de la nube

Una de las razones por las que la percepción de seguridad de DevOps es tan negativa es que con la infraestructura de la nube, puede ser difícil gestionar el número de controles de seguridad y configuraciones que necesiten programarse. En un diseño de arquitectura de aplicación de la nube sencilla, hay, por lo menos, diez controles exclusivos para implementar y configurar correctamente. Algunos ejemplos:

  • ¿Están activados los registros de auditoría para todos los recursos de la infraestructura?
  • ¿Están configuradas correctamente las reglas del firewall?
  • ¿Se utilizan los certificados de SSL en los puntos correctos?
  • ¿Los certificados de SSL son válidos e inmunes a partir de las vulnerabilidades conocidas?
  • ¿Las cuentas de servicios son utilizadas correctamente y seguras para el lanzamiento de los servicios?
  • ¿Tienen las cuentas de servicios los permisos, políticas y rotación de clave apropiadas?
  • ¿Tienen las subredes el tamaño adecuado?
  • ¿Se usan y se configuran correctamente las Listas de Controles de Acceso de red (ACLs)?
  • ¿Se utiliza el cifrado en los datos en reposo cuando es necesario?
  • ¿Se utiliza el cifrado en tránsito y está configurado correctamente donde se necesita?
  • ¿La comunicación entre los niveles de la aplicación está asegurada adecuadamente con las cuentas de servicio?
  • ¿Los activos estáticos tienen la debida seguridad con los conjuntos de permisos adecuados?
Figura 2. Muestra de arquitectura en la nube
Sample cloud architecture
Sample cloud architecture

Crédito de la imagen: DivvyCloud; Utilizado con autorización

¿Qué controles se necesitan?

Uno de los desafíos importantes para las organizaciones en la adopción de la nube es definir las políticas y estándares que desean implementar para sus entornos de nube. Estos requisitos pueden variar por aplicación y, a menudo, vienen de las diversas partes interesadas. Por ejemplo:

  • Los entornos de producción pueden tener el nivel más alto de restricción de seguridad:
    • Requieren MFA para todas las cuentas administrativas
    • Sólo se permite abrir el puerto 443 de firewall
    • La pista de auditoría debe estar activada
  • Los entornos de prueba y desarrollo podrían tener un enfoque en controlar los costos, aunque no se permita ningún acceso de fuera de la organización:
    • Sin ACLs en las redes de la nube, pero ningún acceso a la red pública
    • No hay instancias sobre ocho núcleos (control de costo híbrido y enfoque forzado en la ampliación en lugar del incremento progresivo)
    • Edad máxima de 30 días para cualquier instancia basada en el cálculo, base de datos o volumen de almacenamiento
  • Las aplicaciones de back office probablemente necesiten conectarse nuevamente a las redes corporativas y:
    • El acceso SSH debe estar abierto al rango de IP de red corporativa
    • Bases de datos respaldadas cuatro veces al día
    • Todo el tráfico IP enrutado a través de VPN

Los clientes pueden implementar estos controles de configuración con diferentes herramientas, que van desde las disponibles de cada proveedor de nube hasta herramientas de inspección de código abierto o software comercial. Estas herramientas pueden inspeccionar y tomar medidas para los problemas identificados. Las organizaciones utilizan códigos, convenciones de nombres, región de la nube o ubicación de la cuenta para determinar qué conjuntos de controles de configuración se aplican a cada aplicación o carga de trabajo, en adición a las políticas globales que se aplican universalmente.

Además, los requisitos de seguridad probablemente provienen de diferentes fuentes. En el ejemplo anterior, por ejemplo, las partes serían probablemente:

Control Partes interesadas
Solamente el tráfico del Puerto 443 Equipo de seguridad, CISO, SecOps
No hay instancias sobre ocho núcleos Finanzas, CFO, CIO
Acceso SSH al rango de TI corporativa Equipo de Operaciones, TI, TechOps
Copias de seguridad de base de datos Equipo de operaciones, TechOps, CIO, DR
Figura 3. Políticas de toda la empresa subyacentes con las políticas y aplicaciones de unidades de negocios, proyectos o políticas específicas para los productos
policies
policies

Imagen por DivvyCloud; utilizada con permiso

Un abordaje comúnmente exitoso en la automatización de la nube es iniciar con visibilidad. Tener una herramienta que supervisa continuamente y recibe inventarios del entorno de la nube no es solamente útil, es necesario para asegurar que toda la infraestructura de la nube se evalúe contra todos los controles.

Algunas organizaciones confían en recopilar este inventario de varias herramientas de implementación que deberían "verificarse" cuando se lanzan nuevas aplicaciones. Otro abordaje es utilizar agentes para rendir cuentas de un inventario central. Estos dos abordajes confían en los agentes o en las herramientas de implementación que se instalan, se configuran apropiadamente y son accesibles.

Un abordaje alternativo es utilizar las capas de API de la nube con la finalidad de realizar una consulta exhaustiva y repetida de los entornos. Si bien esto siempre conduce a una visibilidad completa de la infraestructura, tiene la desventaja de no poder consultar profundamente en el sistema operativo o niveles de la aplicación. Como tal, muchas organizaciones emplean un abordaje combinado y usan APIs para consolidar los datos.

Una vez que se descubre la infraestructura, los controles de la configuración aplicables son identificados y evaluados para cada máquina virtual, aplicación, red, activo de almacenamiento y carga de trabajo. Cuando se identifican los problemas, el cliente tiene dos opciones: recibir una notificación y responder o configurar las automatizaciones predeterminadas para tomar una medida casi en tiempo real.

Un ejemplo simple es:

  1. El cliente pone un mecanismo de control en el sitio que imposibilita el acceso SSH a las máquinas virtuales de producción.
  2. Se lanza una nueva aplicación a la producción. La aplicación define un entorno de red de nube que abre por descuido el puerto 22 hacia el mundo.
  3. Las herramientas de automatización de la nube descubren la nueva aplicación y determinan que es un entorno de producción.
  4. Las herramientas comparan la nueva aplicación con la política de producción aplicable y determinan que hay una plataforma.
  5. El cliente tiene una respuesta predefinida que crea una notificación, registra un evento para el seguimiento de auditoría y cierra el puerto de firewall.

Esto les brinda a las partes interesadas tanto controles de seguridad como tranquilidad al aplicar DevOps y mayor adopción a la nube. Estos dos factores juntos pueden ayudar a la organización a ser ágil y a moverse rápido.

Figura 4. Diagrama del Proceso de Control de la Configuración de la Nube
global cloud policy
global cloud policy

Crédito de la imagen: DivvyCloud; Utilizado con autorización

Conclusión

La nube permite a las organizaciones a moverse rápidamente. El valor verdadero, aparte de los posibles ahorros, es la agilidad que la nube permite. Los clientes pueden compilar, modificar y destruir los entornos a velocidades sin precedentes. Al combinar la infraestructura definida por software con las interconexiones de releases de aplicaciones, las compañías pueden permitir un abordaje de DevOps verdaderamente ágil para releases. Esto reduce significativamente el tiempo entre releases y entre el release y la recepción de los datos del usuario en el mundo real lo que induce a la mejoría continua de la aplicación.

Si bien la nube es potencialmente transformadora, la naturaleza en tiempo real y el acceso más amplio a la infraestructura trae un nuevo conjunto de desafíos para las partes interesadas clave para la seguridad, controles de los costos y la conformidad de la política. El uso de una herramienta de supervisión centrada en el descubrimiento, que puede verificar y hacer cumplir los controles, puede ayudar a eliminar las principales preocupaciones para la adopción de la nube. Las organizaciones pueden seguir adelante con seguridad de manera más rápida con la nube.


Recursos para Descargar


Temas relacionados


Comentarios

Inicie Sesión o Regístrese para agregar comentarios.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Cloud computing
ArticleID=1057965
ArticleTitle=DevOps con controles
publish-date=02082018