El otoño ha llegado al patio; la utopía tecno está furiosa. La tecnología avanza rápidamente. Llevamos en nuestro bolsillo una computadora cuya potencia informática es cientos de millones de veces mayor que la potencia de las computadoras que controlaban los vuelos a la luna. Con la ayuda de Youtube VR, podemos nadar en el océano con medusas y ballenas, y los robots han estado explorando los horizontes sin vida de los planetas fríos.
Al mismo tiempo, los ingenieros y especialistas en servicios de TI, desarrolladores y sus innumerables colegas se dividen en dos campos: los que crean nuevas soluciones (software, estrategias, sistemas de información) y los que las entienden.
Irrumpir en el ecosistema de desarrollo de aplicaciones y el método de uso de microservicios. Hasta hace poco, era una técnica incomprensible, cerrada desde miradas indiscretas, una técnica fundamentalmente nueva. Pero hoy, después de solo unos años, las grandes y medianas empresas ya están utilizando este enfoque con confianza en su propio entorno de desarrollo. ¿Cómo es él? No utilizaremos las definiciones "clásicas", pero le diremos en nuestras propias palabras.
Arquitectura de microservicios. Contenedores
Los microservicios son un método en el cual la funcionalidad de un sistema se divide en muchos servicios pequeños, y cada uno de ellos realiza una tarea desde una funcionalidad compleja. Uno actúa como un servidor web, el otro como una base de datos, el tercero está ocupado con otra cosa, etc. Entre todos estos microservicios, se establece la interacción de red y se asignan los recursos necesarios. Un ejemplo divertido y no menos obvio de tal concepto es el sistema de ordenar y emitir almuerzos en restaurantes de comida rápida.
El cliente (usuario) crea un nuevo pedido utilizando el terminal o la recepción (servidor web), transfiere datos sobre la cantidad de hamburguesas con queso, papas y el tipo de refresco en su almuerzo (llena la base de datos), realiza un pago, luego de lo cual los datos se transfieren a la cocina, donde parte los empleados fríen papas (servicio de cocina) y la otra parte distribuye alimentos y vierte refrescos (servicio de recolección). Luego, el pedido recogido se transfiere al mostrador emisor (servicio emisor), donde el cliente muestra un cheque con el número de pedido (¡incluso hay verificación!), Y le dan el almuerzo. Cada una de las unidades de proceso en este caso está ocupada con una tarea y, sin embargo, funciona de manera rápida y sin problemas, de acuerdo con un algoritmo establecido. Debe admitir que sería una tontería esperar que en el mostrador de recepción le sirvan refrescos más rápido que en la cocina, o que el empleado que fríe las empanadas podrá aceptar el pago de su pedido. Sin embargo, si el sistema se depura correctamente y los procesos continúan como se esperaba, entonces todo funciona de manera realmente rápida y eficiente.
En cuanto a la arquitectura de microservicios, vale la pena señalar un punto importante: su entorno de ejecución. Hoy, una opción generalizada son los contenedores (hola, Docker). Una característica de los contenedores es la idea de incluir en ellos todo el entorno necesario, comenzando con una imagen liviana del sistema operativo, paquetes instalados, marcos cargados y bibliotecas, y terminando con la aplicación misma. ¿Cómo es esto útil? Al menos el hecho de que el desarrollador no podrá descartar la explicación "Todo funciona en mi computadora" cuando llegas a él con un mensaje de que la aplicación no está funcionando.
Los contenedores le permiten crear aplicaciones, agruparlas junto con todo el entorno en una imagen preparada de un sistema liviano y no preocuparse más por los problemas asociados con el trabajo en diversos entornos. ¿Necesita implementar la aplicación en otro servidor? Lanzamos una imagen de trabajo con ella en el contenedor, y todo funciona.
En un sistema de información construido utilizando contenedores, ya no tiene que preocuparse por las versiones de software en el entorno donde se ejecutan las aplicaciones, y con procesos de entrega continuos implementados, también necesita entregar código, etc. La idea de un contenedor implica que el desarrollo en sí mismo la aplicación se ejecuta en el mismo entorno de contenedor y, dado que el microservicio está cerrado, no importa en qué sistema operativo o con qué paquetes instalados funcione. La aplicación funciona porque se creó para un entorno de contenedor que no cambia independientemente del sistema que rodea el contenedor. Ya no es necesario instalar todo el software necesario durante un período largo y tedioso para establecer conexiones, dependencias y paquetes. No necesita migrar aplicaciones manualmente cuando se mueve entre entornos de desarrollo e implementación o cuando aumentan las capacidades del centro de cómputo. Ha aparecido un nuevo nivel de abstracción, que toma su lugar entre el software final con sus usuarios y el entorno del host (virtual o básico), en el que todo esto funciona. Este enfoque, debido a su conveniencia, está ganando impulso constantemente y no va a disminuir.
Muchas organizaciones grandes se esfuerzan por adoptar las mejores técnicas para mejorar la eficiencia del negocio, su desarrollo, escalabilidad y transformación, incluso en el contexto de los sistemas de información. Después de todo, es precisamente para grandes empresas orientadas a la tecnología digital que están principalmente interesadas en soluciones orientadas a la flexibilidad, la escalabilidad y la movilidad, ya que, al cambiar la industria, se vuelve susceptible a las dificultades asociadas con la expansión, la adaptación a un mercado cambiante, etc. no necesariamente sobre empresas de TI. En el contexto de los problemas de CI / CD y su seguridad, las empresas del sector público, los principales actores del mercado financiero, como los bancos e incluso los monopolistas de logística, recurren a nuestra organización. En todos los casos, una cosa los une: el uso de contenedores de una forma u otra al desarrollar aplicaciones, servicios, etc.
Las grandes empresas a menudo se comparan con los tiburones. En este caso, es difícil llegar a una comparación más adecuada. ¿Has visto cómo los tiburones se aprovechan de los bancos de peces? ¿Te has dado cuenta de lo mucho más manejables que son los peces pequeños, incluso si están en una gran bandada? ¿Quién reacciona de manera más aguda, más maniobrable y más rápida: un tiburón o una caballa pequeña? Lo mismo ocurre con las empresas en el mercado en general. Por supuesto, no tenemos en cuenta a Microsoft o Apple en esos días en que caben en el garaje, estos son casos aislados. Pero estadísticamente, la imagen es tal que las grandes empresas pueden dictar tendencias y establecer direcciones, sin embargo, es más fácil para las pequeñas empresas adaptarse y adaptarse rápidamente. Y las grandes empresas también están tratando de aumentar la movilidad y la flexibilidad de manera asequible.
Pero, como dicen, hay un matiz ... De hecho, las grandes empresas no son un monolito. Se componen de muchos departamentos, con muchos departamentos, equipos, unidades y un grupo aún mayor de empleados. Y en el contexto de los sistemas de información y desarrollo, en particular, las áreas de acción de los equipos pueden superponerse. Y justo en este cruce, esas situaciones de conflicto surgen entre los servicios de IS y los desarrolladores. Es decir, ni las grandes ni las medianas empresas son inmunes a tales dificultades.
Tarde o temprano, cuando use contenedores, la organización tendrá una pregunta. Esto puede suceder al comienzo de su uso, o tal vez después de algún incidente, como resultado de lo cual la compañía incurrirá en pérdidas.
¿Cómo hacer que los procesos sean seguros?
De una forma u otra, a menudo escuchamos esta pregunta y, junto con el cliente, pensamos en la solución y buscamos formas adecuadas. Como regla general, una organización, especialmente una grande que ha implementado CI / CD, está formada por especialistas inteligentes y experimentados, incluidos aquellos en seguridad de la información. Estas personas entienden por qué necesitan usar microservicios, qué problemas resolverá y qué nuevas dificultades aparecerán. Por lo tanto, toman medidas para la implementación y el uso exitoso de la tecnología: preparar la infraestructura, realizar auditorías, implementar sistemas, construir procesos y coordinar regulaciones internas.
Sin embargo, no siempre es posible prever todo, realizar un seguimiento de todo y controlar todo. ¿Cómo, por ejemplo, entender si la versión del servidor SQL en el contenedor contiene una vulnerabilidad crítica? Manualmente? Digamos ¿Y si hay docenas de contenedores? Y cientos?
¿Cómo puede un especialista en seguridad de la información asegurarse de que la imagen del sistema operativo base en el contenedor con la aplicación no contenga un exploit oculto? ¿Verificar manualmente? ¿Y qué comprobar exactamente, dónde buscar? ¿En todas las decenas y cientos de contenedores? ¿Y dónde obtener tanto tiempo y recursos?
Con el desarrollo y la distribución de CI / CD, la cuestión de la seguridad en el ciclo de desarrollo se agudizó. Después de todo, debe asegurarse al menos a un nivel aceptable en la calidad de las imágenes, debe conocer las vulnerabilidades del software y los paquetes, el estado de los contenedores de trabajo, si se están produciendo acciones sospechosas u obviamente ilegítimas en ellos. Y si estamos hablando específicamente sobre el ciclo de desarrollo, entonces valdría la pena tener herramientas para garantizar la seguridad en el proceso de desarrollo en sí, en su canalización, y no solo en contenedores. Y también necesita control sobre los secretos, auditoría de registros, control sobre la interacción de la red, etc. Y aquí llegamos al tema principal.
¿Por qué se necesita seguridad y cuáles son sus características en CI / CD?
Esencialmente, es un conjunto de prácticas para garantizar la seguridad dentro y alrededor del ciclo de desarrollo. Es decir, es el uso de software especial, el desarrollo de métodos y regulaciones, e incluso la preparación de equipos (¡los equipos son la clave de todo!) Para garantizar la seguridad. Y un punto importante: la introducción justificada de toda esta seguridad en el desarrollo, ¡y no cortar desde el hombro!
Aquí nos detenemos con más detalle. El enfoque habitual de la seguridad de TI en general y del desarrollo en particular, que viene a la mente, se basa en los principios de "Prohibir / Restringir / Prevenir". De lejos, el sistema de información más seguro es uno que no funciona en absoluto. ¡Pero debe funcionar! Y las personas que usan este sistema también deberían poder trabajar con él.
Hay un conflicto de intereses mencionado anteriormente. El especialista en seguridad de la información busca hacer que el entorno sea seguro y quiere tener un control completo sobre él, el desarrollador quiere hacer que el producto suceda de manera rápida y conveniente, y el ingeniero de TI hace que el entorno sea viable, tolerante a fallas y junto con el desarrollador se esfuerza por la automatización.
La protección en CI / CD no se trata de software o regulaciones, se trata de trabajar en equipo e incorporar el concepto de seguridad en el flujo de desarrollo. Este enfoque tiene como objetivo la participación equitativa de todos los participantes en el proceso, la distribución de áreas claras de responsabilidad, la automatización, el monitoreo y la presentación de informes transparentes. Y lo más importante, implementar la seguridad dentro del proceso de desarrollo de aplicaciones de tal manera que aparezca en las primeras etapas y no requiera la asignación de recursos adicionales, tanto computacionales como humanos.
Echemos un vistazo a un ejemplo. Supongamos que uno de los equipos de desarrollo crea una aplicación, esto sucede en un medio contenedor bajo la supervisión de especialistas en seguridad de la información, mientras que los administradores de infraestructura mantienen la salud de este entorno. Al final del desarrollo, aparece una aplicación lista para usar que fluye hacia la producción y comienza a funcionar allí, los clientes la usan, todos están contentos. Pero después de un tiempo, se descubre una vulnerabilidad grave en el contenedor con la aplicación. Un especialista en seguridad de la información registra esta vulnerabilidad y la pasa a los desarrolladores para su eliminación; ellos, a su vez, la arreglan con un parche, después de lo cual debe volver a escribir las dependencias y actualizar algunos paquetes. Luego se implementa la próxima versión de la aplicación.
El tiempo dedicado por los especialistas de IS para localizar el problema, el tiempo del equipo de desarrollo para solucionarlo y un poco mientras el servicio de IS llevará a cabo una segunda auditoría y cerrará el caso. Pero, ¿qué pasaría si pudiéramos usar algún tipo de herramienta e implementarla en la etapa de desarrollo? ¿Qué sucede si nuestra aplicación no se implementó en el producto y no es adecuada para el nivel de seguridad dado? Y cada especialista involucrado en el proceso, ¿pudo ver qué amenazas se encontraron en su área de responsabilidad? Pero, ¿qué pasaría si todo el proceso también se automatizara, comenzando con la detección y terminando con incidentes en el rastreador de errores?
Este es el objetivo de organizar el desarrollo y la implementación seguros. Que no solo era seguro, sino también conveniente. La introducción de nuevos procesos o el uso de herramientas adicionales debería simplificar las actividades, y no al revés.
Existen herramientas y técnicas que le permiten monitorear el estado de los elementos del sistema necesarios y las etapas del proceso de desarrollo y ayudan a todas las partes involucradas a mantenerse al tanto de los eventos dentro de su área de responsabilidad. El énfasis aquí no está en el software especializado, sino en la interacción de las personas con el sistema y entre sí. ¿Es más conveniente para el desarrollador arreglar y probar la aplicación dentro del contenedor de trabajo? Bueno, déjalo arreglarlo. Al mismo tiempo, ¿el servicio de IS quiere asegurarse de que no haya acciones ilegítimas dentro del contenedor? No hay problema, ella estará al tanto. La tarea se completó y nadie interfirió con nadie en el proceso. Eficiencia y racionalidad! Y esto es posible si aplica las herramientas de seguridad de la información necesarias en los lugares correctos en el entorno de desarrollo y revisa las reglas de interacción entre los servicios y los equipos. Y luego que no haya utopía, pero debes aceptar que vivir con ambos será un poco más fácil.
¿Por qué vincular las manos de los desarrolladores y cargar el servicio de IB con él, si puede construir procesos para que el desarrollador haga lo que pueda (desinteresadamente, agotado en éxtasis por la perfección de su código), y el especialista de IB controló este proceso (sin interferir, pero solo compartiendo este placer del lado)
Contenedor de seguridad. ¿Vale la pena?
Los clientes nos contactan en etapas completamente diferentes y con diferente experiencia en CI / CD. Hubo grandes organizaciones que enfrentaron una puerta trasera no detectada en el contenedor en producción a través de la cual se obtuvo acceso a datos importantes y se robaron los datos. Como resultado, se hizo obvio que en un sistema descuidado y engorroso, es demasiado difícil hacer un seguimiento y neutralizar preventivamente las posibles amenazas.
También hubo pequeñas empresas que recientemente utilizaron CI / CD en el desarrollo. Después de analizar los procesos en las tuberías, sus expertos llegaron a la conclusión de que las herramientas de seguridad de la información disponibles cubren un volumen insuficiente de procesos, y hay lugares peligrosos a través de los cuales un ataque puede ocurrir tarde o temprano. Tal vez no ahora, tal vez más tarde, o tal vez nunca. Pero si esto sucede, el precio del error será alto.
Nuestros clientes comparten inquietudes, que en la mayoría de los casos se reducen al concepto de vencer a los desarrolladores, ingenieros y todos los involucrados en el proceso cuando intentan ir más allá del límite de tiempo. Pero a veces es más fácil y rápido de esa manera, y en algunos casos generalmente es lo contrario. Y luego el servicio de IS tiene que mirar las violaciones con los dedos. Pero estamos por un concepto diferente. ¿Por qué violar o ignorar las regulaciones que fueron escritas con tanto dolor? ¿Por qué los servicios deberían interferir entre sí para realizar sus tareas? Al trabajar con el cliente, comenzamos la comunicación con sus problemas. Ellos siempre están ahí.
"No busque un cliente, encuentre un problema y ofrezca una solución: el cliente aparecerá por sí mismo".
Habiendo escuchado al cliente, por regla general, entendemos qué problemas enfrentan. Puede haber dificultades en la interacción del equipo, decisiones fallidas en el diseño de la "tubería", falta de recursos informáticos y humanos, y mucho más. En nuestro enfoque para la implementación de mejoras de seguridad en la infraestructura del cliente, nos guiamos por el deseo de ayudar a resolver sus problemas y lograr esto de una manera que minimice la probabilidad de que surjan otros nuevos. Por lo tanto, se crea una base para el futuro, no importa quién dará servicio al sistema creado, muchos problemas deben ser previstos y resueltos al principio. En las primeras etapas, las decisiones en la mayoría de los casos resultan más baratas que con altas cargas de trabajo en la producción profunda.
En base a todo esto, sugerimos comenzar con una auditoría, que incluya no solo el estado de los sistemas de información y sus elementos, sino también una comprensión del componente del proceso entre los equipos de desarrollo, el enfoque de los servicios de seguridad de la información, etc. No olvide que las personas son el factor más importante tanto en términos de amenazas como de los resultados del funcionamiento del sistema. Una auditoría es una etapa necesaria, como resultado de lo cual se pueden revelar fallas importantes del sistema o errores de cálculo en las interacciones que junto con el cliente que intentamos resolver o procesar. Es importante comprender que el objetivo no es acumular muchas soluciones de software y productos y no callar las vulnerabilidades descubiertas por ellos. Por el contrario, es probable un escenario en el que la compra de productos de software caros puede no ser necesaria en absoluto.
A menudo, el proceso de aumentar la seguridad en un entorno de CI / CD se puede lograr con la ayuda de las características de seguridad existentes de la organización, tanto integradas en el entorno de contenedorización (en el orquestador, por ejemplo), como de terceros. Lo importante no es tanto su cantidad o calidad como la aplicación correcta.Con base en los resultados de la auditoría, se hace posible crear un plan de trabajo, una hoja de ruta con objetivos provisionales claros y un objetivo final comprensible. Bueno, todo lo demás es una cuestión técnica. La planificación adecuada en cualquier negocio es una parte masiva de una finalización exitosa.Es importante no dejarse llevar demasiado y no olvidar por qué se hace todo. Nadie tiene la tarea de crear un sistema increíblemente protegido en el que no se inicie ningún contenedor cuando se detecten amenazas, o no se implemente ninguna aplicación en producción si hay alguna desviación del modelo protegido. Vale la pena recordar que la introducción o el lanzamiento de herramientas de protección deberían servir no solo para aumentar la seguridad, sino también por conveniencia.Por ejemplo, uno de estos casos involucró la introducción de software de protección de contenedores y entornos de orquestación. Parecería que implementaron, configuraron, escanearon, vieron todas las vulnerabilidades, y luego el largo proceso de eliminación. Sin embargo, con este enfoque, surgen problemas, que se discutieron al principio. El servicio de seguridad de la información tiene una herramienta que le permite bloquear muchas actividades en un entorno de orquestación que, si se usa incorrectamente, hará más daño que bien. Los desarrolladores tienen las manos atadas, porque el servicio de seguridad de la información está reduciendo sus capacidades. Por ejemplo, ya no es posible arreglar algo dentro del contenedor "en caliente", y cuando se detecta una vulnerabilidad de paquete en la imagen, el desarrollador está involucrado en la burocracia reguladora. Como resultado, la solución a un problema que podría eliminarse durante el día se retrasa indefinidamente.Para evitar tales situaciones, recomendamos que los procesos se organicen de tal manera que el servicio de seguridad de la información no esté alejado del proceso de desarrollo, como sucede a menudo, sino que es un participante en él. Ciertamente lleva algo de tiempo, pero vale la pena depurar el proceso, y la vida realmente se está volviendo más fácil. Por ejemplo, las herramientas IS le permiten monitorear las amenazas que ya se encuentran en la etapa de ensamblaje dentro de la canalización de CI / CD, y el servicio IS puede registrar esto. Al mismo tiempo, la información sobre las amenazas en cada etapa de la asamblea se puede transferir automáticamente al equipo o especialista responsable de una etapa en particular, y eso a su vez tomará las medidas necesarias para eliminar la amenaza. Y todo esto sucede no bajo la supervisión de un látigo, sino bajo la supervisión del servicio IS.En última instancia, el tiempo dedicado a la reparación de vulnerabilidades puede reducirse significativamente y, con ello, los costos comerciales, por ejemplo, financieros o de reputación.Con cualquier dato inicial, nos esforzamos por formar un enfoque para organizar y mejorar el nivel de seguridad del desarrollo de contenedores, centrándonos no solo en el diseño y la implementación de soluciones específicas, sino también en los recursos humanos. Cada participante en el proceso cumple su función, y cuanto más conveniente sea, menos interferencia innecesaria, mejor será su resultado final. Y si encuentra un equilibrio entre la conveniencia de todas las partes involucradas, terminará con un equipo muy efectivo. En el futuro, por supuesto, es posible la optimización, la aplicación o el aumento de la automatización de algunos procesos, la delegación de tareas, etc., pero la idea principal permanece sin cambios: una revisión de la seguridad como tal. Separación de deberes, monitoreo en lugar de prohibiciones sin sentido y la participación de todos dentro de sus áreas de responsabilidad.¡Y por supuesto, conveniencia! La seguridad puede ser conveniente.