adam121 - Fotolia

Resolver Problemas Consiga ayuda para problemas específicos con sus proyectos, procesos y tecnologías.

Puntos esenciales para el desarrollo de aplicaciones seguras en DevOps

Para asegurar el desarrollo de aplicaciones, aquí está lo que los equipos DevOps deben hacer para superar a los hackers de hoy, cuyas herramientas y prácticas se han vuelto muy sofisticadas.

Los problemas más comunes en el desarrollo y despliegue de aplicaciones seguras son la incertidumbre sobre las responsabilidades de desarrollo y operaciones, el despliegue y las políticas anticuadas de seguridad de la empresa, según Owen Garrett, jefe de productos de NGINX. Bajo presión para construir y desplegar software rápidamente, es fácil para un lado pensar que el otro ha hecho las tareas de seguridad necesarias. En segundo lugar, las empresas necesitan renovar las políticas de seguridad para adaptarse al modelo de desarrollo y despliegue rápido. Haga estas dos cosas bien, y los equipos de aplicaciones pueden trabajar a máxima velocidad y todavía tener visibilidad completa y control sobre la seguridad.

En esta entrevista, Garrett explicó cuáles tareas de desarrollo seguro de aplicaciones de software pertenecen a desarrollo u operaciones, así como los riesgos de seguridad con los contenedores y el desarrollo de microservicios.

Hoy en día los hackers tienen herramientas sofisticadas, como los servicios de nube de hackers. ¿Qué tácticas pueden tomar los equipos de DevOps para hacer frente a estas herramientas más sofisticadas?

Owen Garrett: En DevOps, los desarrolladores y el equipo de operaciones cada uno necesita aprovechar sus fortalezas. Necesitan coordinarse para asegurarse de que, entre ellos, todas las medidas de seguridad necesarias estén debidamente cubiertas de una manera estándar.

Owen Garrett

En primer lugar, los desarrolladores deben seguir buenas prácticas de seguridad de las aplicaciones al diseñar aplicaciones. Eso implica codificar defensivamente. Por lo tanto, hay que suponer que todas las entradas que llegan –es decir, en lenguaje NGINX, todo el tráfico de red– deben asumirse como tráfico de ataque potencial, y construir la aplicación para que sea muy defensiva en la forma en que maneja las solicitudes. Y, a menudo, lo que es necesario hacer es seguir un patrón cuando se construye una fachada delante de la aplicación. Y esa fachada expone una versión muy sencilla. Expone solo las APIs que necesita consumir externamente, y luego las traduce a las APIs internas más ricas. En segundo lugar, los desarrolladores deben seguir buenos principios, como el mínimo privilegio [y] los datos mínimos.

¿Cuáles son algunas de las responsabilidades de operaciones en la defensa contra los hackers?

Garrett: El equipo de operaciones debe asumir la responsabilidad de estándares como la autenticación o el cifrado o los certificados. Quite eso de los desarrolladores, para que no necesiten preocuparse de ellos, y póngalos en las manos de expertos en la materia en el equipo de operaciones.

El equipo de operaciones necesita construir un entorno que sea robusto y fiable, que les permita identificar problemas de seguridad y responder a ellos rápidamente. Para operaciones, las buenas prácticas incluyen implementar un equilibrador de carga o dispositivos de proxy inverso con escáneres de seguridad para garantizar que todo el tráfico entrante tiene que pasar por esos puntos de entrada, asegurándose de que no hay ninguna manera de evitar esos puntos de entrada.

¿Qué es un resultado común de una mala coordinación entre equipos de desarrolladores y de operaciones en el desarrollo de aplicaciones seguras?

Garrett: El resultado es usualmente interfaces no seguras o sin seguimiento para sus aplicaciones. Estos parecen ser comúnmente explotados o explorados como una manera de tratar de encontrar una manera de evitar la seguridad principal de una aplicación. Cuando una aplicación complicada se despliega en línea, a menudo está compuesta de muchos componentes diferentes, y puede ser posible evitar las medidas de seguridad de algunos de esos componentes. Puede ser muy difícil para el equipo de seguridad saber todo sobre la envoltura completa que necesitan proteger.

¿Diría que existen situaciones de seguridad diferentes, peores o mejores para los equipos de DevOps que desarrollan microservicios?

Garrett: Es una situación de seguridad muy diferente con microservicios por un par de razones.

Una razón es que los microservicios tienden a ser utilizados porque las organizaciones quieren iterar y desplegar aplicaciones muy, muy rápidamente. Y cuando están realizando despliegues muy rápidos, eso puede agravar el desafío de seguridad porque usted no puede permitirse ejecutar largos procedimientos de seguridad contra cada despliegue. Así que ese es un desafío a considerar.

Otro desafío a considerar es que, si un microservicio individual fuera a ser explotado de alguna manera, entonces eso podría proporcionar una pasarela hacia toda la aplicación. Por lo tanto, es muy importante rastrear y gestionar todo el tráfico que entra, controlar qué microservicios pueden ser directamente abordados por las partes externas, y centrarse en ellos con sus esfuerzos de seguridad para garantizar que son muy, muy difíciles de comprometer y tienen privilegios limitados si llegaran a ser comprometidos.

Con los microservicios, la tentación es hacer que muchos de sus servicios sean accesibles externamente a través de las APIs. Y si esos servicios no han sido diseñados con seguridad en primer lugar, entonces es una decisión muy, muy arriesgada. Así que se necesita disciplina. El patrón de fachada donde construye una pared frente a su aplicación que expone APIs seguras, auditadas por la seguridad y administradas, y luego tiene el caos y la validez de la aplicación de microservicios detrás.

¿Cómo afecta el uso de contenedores al desarrollo seguro de aplicaciones?

Garrett: Es muy similar a la anarquía que se crea con microservicios. Así como los microservicios permiten a los desarrolladores extender la funcionalidad mucho más rápidamente, los contenedores permiten a [DevOps] implementar el código más rápidamente. En muchos casos como este que he visto, los estándares de seguridad corporativos son evitados para asegurar la velocidad.

Parte de la justificación para el uso de contenedores es que cada componente individual tiene su propio entorno operativo. Por lo tanto, si necesita una versión diferente de una biblioteca de sistema operativo o un marco diferente, entonces eso se puede lograr poniendo eso en el contenedor. Pero el riesgo es, entonces, que el desarrollador pueda crear una aplicación que contenga componentes que no cumplan con los estándares de seguridad internos. Tal vez utilizan componentes que no han sido examinados o han conocido errores. Tal vez no están usando contenedores seguros.

Hay un creciente cuerpo de pensamiento sobre cómo usted necesita auditar y rastrear el software que se despliega dentro de los contenedores para asegurarse de que esos cumplen con los estándares arquitectónicos internos de calidad y fiabilidad, de capacidad de soporte.

¿Cuáles son las principales responsabilidades de los arquitectos empresariales en la creación y mantenimiento de políticas de desarrollo y despliegue de aplicaciones seguras y arquitecturas de soporte?

Garrett: Construir seguridad en la arquitectura para la aplicación de una organización es la parte más importante del desarrollo y el despliegue seguros. Esta es la arquitectura de implementación, por lo que los arquitectos deben crear un entorno seguro en el cual se despliegue la aplicación.

La seguridad requiere una visibilidad completa del tráfico que entra. Además, debe ser capaz de correlacionar el comportamiento inesperado de la aplicación con ese tráfico. Si falla o los usuarios bloquean la CPU, puede correlacionar eso con las solicitudes y tener la capacidad de controlar ese tráfico. Por lo tanto, usted debe ser capaz de aplicar límites de velocidad o bloquear solicitudes particulares, si determina que éstas son malas para la aplicación. Debe ser capaz de administrar todo el tráfico que ingresa y aplicar esas reglas.

Construya una arquitectura, un entorno, donde pueda desplegar la aplicación y, a continuación, podrá controlar y rastrear y monitorear cómo se está comportando. Dentro de esa arquitectura, puede proporcionar información accionable a los desarrolladores si ve una anomalía o un error. Si lo construye bien, eso le quita algo de la carga a los desarrolladores para centrarse en las áreas arquitectónicas de seguridad.

Mientras tanto, el desarrollador, por supuesto, tiene que seguir centrándose en cuestiones clásicas de seguridad, como ataques de inyección, o referencias a objetos inseguros, o contraseñas deficientes. Si primero se ha centrado en la infraestructura y ha creado un entorno en el que puede controlar y proteger el tráfico, el desarrollo y el despliegue seguros son más fáciles: no fáciles, sino más fáciles.

Este artículo se actualizó por última vez en agosto 2017

Profundice más

PRO+

Contenido

Encuentre más contenido PRO+ y otras ofertas exclusivas para miembros, aquí.

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Enviando esta solicitud usted acepta recibir correos electrónicos de TechTarget y sus socios. Si usted reside afuera de Estados Unidos, esta dando autorización para que transfiramos y procesemos su información personal en Estados Unidos.Privacidad

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close