Header Ads Widget

Ticker

6/recent/ticker-posts

Mantener la seguridad de la API en un entorno de entrega continua

 

Seguridad de API en un entorno de entrega continua

La entrega continua es un sello distintivo del mundo del desarrollo moderno. A medida que las herramientas han madurado y las necesidades del consumidor han evolucionado, el desarrollo y la implementación constantes se han convertido en la norma y no en la excepción.

Con este aumento en la implementación, la seguridad ha aumentado en parte y en parcela. En este artículo, analizaremos cómo mantener la seguridad en un entorno de implementación tan único y los desafíos inherentes al mismo.

¿Qué es la entrega continua?

La entrega continua es el proceso mediante el cual los desarrolladores impulsan actualizaciones consistentes y oportunas a través de un sistema de implementación. Suele ser un sistema automatizado, en el que los equipos de DevOps unen la ideación, el desarrollo inicial y la implementación en una única vía de desarrollo ágil.

Hay mucho que decir sobre este tipo de interacción de entrega. Por un lado, el sistema es mucho más ágil para las necesidades del mercado: debido a que la entrega no está ligada a un ciclo a largo plazo, las funciones se pueden desarrollar rápidamente e impulsar la garantía de calidad a medida que los consumidores notifican al desarrollador sus necesidades.

Este cambio de ciclo también significa que cuando llegan errores y errores, generalmente son de corta duración. Los desarrolladores pueden abordar rápidamente problemas de seguridad, errores y errores mediante parches e implementaciones adicionales, lo que reduce la vida útil de los problemas en una API.

Como parte de este cambio a un ciclo de desarrollo continuo y automatizado, existen algunas advertencias que prohíben el desarrollo más tradicional. Lo que es más importante, la práctica común de la auditoría de código manual se vuelve poco realista debido a la rápida agilidad del desarrollo.

Sin embargo, no todo es "sol y arco iris". La entrega rápida y continua tiene algunas advertencias que los desarrolladores deben administrar.

El principal de estos es el hecho de que el desarrollo rápido y continuo puede facilitar la participación en el deslizamiento de funciones. Con los lanzamientos incrementales en curso, a menudo se pierde el “panorama general” y el deslizamiento de funciones se convierte en un problema legítimo. Asimismo, la implementación continua y constante también puede generar errores que, de otro modo, se eliminarían mediante pruebas e implementación a largo plazo.

Estas advertencias no son nada comparadas con los beneficios otorgados por el aumento de la agilidad y la interacción del consumidor, pero permiten una perspectiva única sobre el desarrollo (las implementaciones continuas inherentemente requieren integraciones más consistentes), todas las cuales deben asegurarse adecuadamente.

Consulte también DevOps basado en API: Spotlight on Docker

Auditoría de seguridad

Afortunadamente, hay varias formas en que un proveedor de API puede auditar y asegurar sus API en un entorno de entrega continua. Si bien cada una de estas soluciones es increíblemente poderosa, generalmente se utilizan mejor para casos de uso específicos: no existe una implementación "perfecta".

Escaneo y revisión de códigos

El escaneo de código, el proceso automatizado mediante el cual se escanea el código y se verifica si hay vulnerabilidades, es una herramienta increíblemente poderosa para auditar la seguridad. Una de las características más poderosas del escaneo de código es el hecho de que, en la mayoría de las soluciones, el código se verifica contra vulnerabilidades comunes y conocidas, eliminando muchos de los problemas basados ​​en dependencias que plagan las bases de código rápidas.

Implementar esto como un procedimiento de desarrollo tiene sentido, pero aun así, a menudo se pasa por alto. Cuando presentó un trabajo final en la escuela, ¿era un primer borrador? Por supuesto que no, la mayoría de los estudiantes pasaron el trabajo a través del corrector ortográfico cientos de veces, revisaron la gramática, revisaron cada hecho, revisaron sus puntos y comas, y se aseguraron de que todo fluyera.

En consecuencia, sabiendo cuántas personas dependen de la funcionalidad interna, ¿por qué un desarrollador de API lanzaría un producto sin antes hacer su propia "revisión ortográfica"?

Muchas de estas soluciones son además de código abierto . Si bien ha habido mucho discurso sobre la seguridad de código abierto, y si es o no tan poderoso y útil como se ha dicho, el poder de la colaboración hace que tener una base de datos abierta y de fuentes múltiples de fallas sea más poderoso que tener una lista cerrada y limitada. de referencias posiblemente desactualizadas e irrelevantes.

Creando un ecosistema limpio

Sin embargo, el escaneo de código solo puede llegar hasta cierto punto; para muchos equipos de desarrollo, el diablo está en los detalles. Establecer una plataforma de operaciones y desarrollo segura y estable es tan importante como escanear el código para detectar problemas comunes.

Parece haber una desconexión en la mayoría de los sistemas DevOps donde los clústeres de desarrollo y operaciones están muy alejados unos de otros. En última instancia, esto da como resultado un sistema en el que se aplican revisiones al código que funciona correctamente en un clúster para que funcione en otro clúster.

Si bien esto está bien para el requisito básico, es terrible para la seguridad, ya que a menudo introduce errores y fallas nuevos y únicos que de otro modo no existirían sin esta discrepancia de clúster.

A medida que el crowdsourcing se ha vuelto más aceptado por la corriente principal, se han introducido más y más herramientas en el mercado que aprovechan el poder del grupo para producir resultados sorprendentes.

Una de estas herramientas en el espacio de la seguridad, Evident.io , utiliza registros de protocolo y entornos de colaboración colectiva para analizar el código de forma inteligente, lo que reduce la complejidad para comprender la analítica. Luego, estos análisis se utilizan para identificar vectores de ataque, exponer problemas comunes y aclarar problemas de seguridad que pueden ser difíciles de ver.

Blog-Post-Wide-CTA-API-Stack

Adopción de estrategias de desarrollo más eficaces

La adopción de TI de dos velocidades como principio de producción también es increíblemente poderosa tanto para la producción como para la seguridad. En este enfoque, se forman dos "carriles": desarrollo beta rápido y desarrollo de liberación estática.

En este enfoque, el desarrollo beta rápido es donde se diseñan e implementan nuevas características, mientras que la vía de desarrollo de versiones estáticas se centra en lanzar productos que cumplan con los requisitos necesarios y sean estables.

Colocar pistas separadas ayuda a garantizar la seguridad en un entorno continuo, ya que permite un canal de suscripción para funciones experimentales y beta sin afectar la pista estable. La seguridad de la pista opt-in no tiene que ser necesariamente tan intensa como la pista estable, ya que el principio de jure es sin duda el de “caveat emptor”.

Dicho esto, la implementación de funciones futuras en un entorno de baja seguridad puede ayudar a identificar los agujeros en la armadura que de otro modo podrían quedar ocultos cuando se implementan en un entorno de alta seguridad.

Segmentación de servicios

Si bien la creación de una experiencia "unificada" para los desarrolladores ha sido durante mucho tiempo el grito de guerra de la mayoría de los proponentes de API, en algunos casos, en realidad es mejor segmentar los servicios, especialmente en el caso de la seguridad y la auditoría.

Considere el siguiente ejemplo. Un proveedor de API ha creado una API "unificada" que combina el procesamiento de datos, la conversión de medios y la transferencia de archivos grandes entre servidores, clientes y usuarios. Cada actualización de código requiere una auditoría a largo plazo, con varios equipos utilizando la misma base de código.

¿Cuáles son los problemas con esta aplicación? Bueno, en primer lugar, tenemos varios equipos que utilizan la misma base de código general y aplican soluciones específicas allí. El mejor esquema de operaciones para el equipo de conversión de medios puede no ser necesariamente el mejor para el equipo de procesamiento de datos y, desde luego, no para el equipo de transferencia de archivos grandes. Con cada nueva corrección de código, el código se hincha y los diferentes equipos implementan soluciones que son de naturaleza contradictoria. Incluso con los equipos conversando directamente, esto es inevitable.

¿Cual es la solución? Segmentación . Con la segmentación, los desarrolladores toman la funcionalidad y dividen la API en ese sentido. Esencialmente, se desarrolla una API "principal" para unificar las funciones en estas otras API dispares, lo que permite crear API individuales para casos de uso y funcionalidades específicas.

En un proceso de desarrollo de este tipo, la API, que antes se veía así:

  • API de función : conversión de medios, procesamiento de datos, transferencia de archivos grandes

Se convierte en esto:

  • API de función : API con llamadas de propósito general, vinculada a:
  • API de conversión de medios : API diseñada específicamente para convertir medios para su uso en Procesamiento de datos o Transferencia de archivos grandes;
  • API de procesamiento de datos : API diseñada específicamente para el procesamiento de datos grandes para su uso en Transferencia de archivos grandes o Conversión de medios;
  • Transferencia de archivos grandes : API diseñada específicamente para manejar la transferencia de archivos grandes, incluidos los generados a partir de las API de conversión de medios y procesamiento de datos;

Al segmentar la API en varias API secundarias, cada una se convierte esencialmente en su propio segmento de desarrollo. Al hacer esto, se puede auditar la seguridad para cada función , ya que las necesidades de seguridad de cada una son drásticamente diferentes.

Lo más importante es que la segmentación da como resultado capas secundarias de seguridad. Esto crea una situación en la que, incluso si un pirata informático puede atravesar la "API de función", puertas de enlace adicionales para cada segmento nuevo hacen que sea casi imposible atravesar el ecosistema de seguridad.

Conclusión

mantener-la-seguridad-en-un-entorno-de-entrega-continua

Continuous Delivery es una implementación increíblemente poderosa, pero tiene sus propios problemas y preocupaciones de seguridad. Si bien garantizar que los usuarios tengan las revisiones más actualizadas de una base de código puede generar interacciones más poderosas con esa base de código, también puede aumentar necesariamente la posibilidad de fallas en el código o seguridad laxa. Las soluciones que se ofrecen aquí son solo algunas de las muchas soluciones que se pueden implementar para negar las preocupaciones que ofrece la estrategia de desarrollo.

Si bien la adopción de algunas o incluso de todas estas soluciones de seguridad puede parecer una perspectiva desalentadora, el hecho es que la mayoría de los desarrolladores de API deberían implementarlas independientemente: nada más que bueno puede provenir de enfoques de diseño, segmentación y escaneo de código adecuados.

La implementación de la entrega continua no es solo una de las mejores soluciones para los desarrolladores de API que se enfrentan a grandes ciclos de vida de desarrollo; es posiblemente el método más poderoso para formar una base de usuarios y un ecosistema sólidos.

¿Tiene alguna sugerencia para asegurar un entorno de entrega continua? ¡Comenta abajo!

Publicar un comentario

0 Comentarios