Desarrollo de apps en entornos Cloud: aspectos clave en cuanto a seguridad

Líneas maestras

Las prácticas y tecnologías de desarrollo modernas (CI/CD, contenedores, serverless, etc.) requieren un enfoque integrado con capacidades que ofrezcan una protección conectada a lo largo del ciclo de vida de la aplicación, así como la garantía de que los servicios cloud cumplen con las mejores prácticas de seguridad mientras permiten que los desarrolladores trabajen, con múltiples y exhaustivos controles de seguridad para proteger frente a vulnerabilidades, filtraciones, ataques de malware e infracciones de cumplimiento normativo.
Estos serían algunos de los aspectos esenciales a tener en cuenta:

• Seguridad en la canalización: Es un paso previo y fundamental para garantizar la seguridad. Es recomendable realizar un continuo análisis de logs e imágenes de contenedores, incluyendo aquellas localizadas en instancias Open Source, así como escaneados exhaustivos de la canalización CI/CD.
• Protección de aplicaciones: La automatización de la seguridad debe permitir la protección de los procesos de desarrollo frente a las principales amenazas para aplicaciones en servidores, APIs, contenedores, plataformas serverless, etc.
• Protección del sistema operativo del host. Por lo general, todos los contenedores comparten un mismo kernel, por lo que será esencial su protección frente a vulnerabilidades y ataques en la capa del host.
• Seguridad en el almacenamiento. El sistema debe analizar cualquier tipo de archivo en busca de malware e integrar la seguridad en workflows personalizados con soporte para todo tipo de plataformas de almacenamiento cloud.
• Protección de contenedores. También en este apartado es recomendable un nivel máximo de control sobre eventos y notificaciones para atender a los requisitos de seguridad y cumplimiento normativo y seguridad, incluyendo una monitorización exhaustiva del tráfico en los contenedores.
• Seguridad en los procesos de DevOps. La integración de APIs especificas permite mejorar los ciclos de desarrollo y reduciendo los tiempos de entrega, pero también es un aliado para reducir los puntos de contacto y el factor humano.
• Seguridad de la red: Es cierto que este apartado incluye numerosos elementos para la protección del tráfico de red: firewalls, sistemas de detección de intrusiones, monitorización, gestión de activos y componentes... El objetivo es reducir al máximo la superficie de ataque.
• Seguridad Open Source. Otro aspecto fundamental, especialmente si tenemos en cuenta que una gran parte que el código que circula es de código abierto. Será necesario tener visibilidad sobre las vulnerabilidades de los entornos open source, incluyendo la gestión de riesgos de licencia.

Codificación segura: Principales riesgos según el OWASP.

El OWASP Top 10 es un documento de concienciación estándar para desarrolladores y seguridad de aplicaciones web, reconocido mundialmente por los desarrolladores como el primer paso hacia una codificación más segura.

Las empresas deben adoptar este documento y comenzar el proceso de garantizar que sus aplicaciones web minimicen estos riesgos. Utilizar el OWASP Top 10 es quizás el primer paso más efectivo para cambiar la cultura de desarrollo de software de la organización. A continuación se muestra cada uno de estos riesgos:

• A01. Rotura del control de accesos. Permite a los atacantes comprometer los datos mediante la obtención de acceso con privilegios o la apropiación de cuentas. El 94% de las aplicaciones probadas presentaron este tipo de problema.
• A02. Fallos criptográficos. Son fallos relacionados con el cifrado que a menudo conducen a la exposición de datos confidenciales o a la toma de control de los sistemas. Suelen ser más un síntoma que una causa raíz.
• A03. Inyección. Esta categoría (inyecciones SQL, inyecciones JavaScript) hace referencia en la carga de código malicioso en la aplicación presenta la segunda mayor cantidad de casos. El Cross-site Scripting es ahora parte de esta categoría.
• A04. Diseño inseguro. Una nueva categoría respecto a informes anteriores que hace referencia a los riesgos relacionados con fallos en el diseño. OWASP recomienda elementos como threat modeling, patrones y arquitecturas de referencia.
• A05. Errores de configuración. Cada vez más comunes por el uso de la nube como entorno de desarrollo y el desarrollo con imágenes de contenedores. El 90% de las aplicaciones probadas por la OWASP arrojaron algún tipo de error de este tipo.
• A06. Fallos en los componentes. Un problema conocido, pero que cuesta evaluar. Normalmente, estas vulnerabilidades provienen del uso de marcos o bibliotecas desactualizados que son fáciles de explotar.
• A07. Fallos de identificación y autenticación. Mala gestión de las sesiones, contraseñas débiles o no limitar la tasa de intentos de login siguen suponiendo un problema, pero menos crítico por la cada vez mayor disponibilidad de marcos estandarizados.
• A08. Fallos de integridad en los datos y el software. Una categoría añadida en el último informe que hace referencia a las vulnerabilidades en el software, datos críticos y canalizaciones de CI/CD.
• A09. Fallos de registro y monitorización. Los fallos en esta categoría pueden afectar a la capacidad de su empresa para detectar y responder ante posibles brechas, ya que dificulta la visibilidad, las alertas sobre incidentes y el análisis forense.
• A10. Falsificación de solicitudes del lado del servidor. Añadida en el último informe, es un problema relativamente medible y monitorizable. Ocurre cuando los atacantes hacen que los servidores realicen solicitudes no autorizadas.

Seguridad en cada fase del proceso

La definición de niveles aceptables de seguridad y privacidad desde el principio de cada proyecto ayuda a los equipos de DevOps a comprender los riesgos, identificar y corregir errores durante el desarrollo y aplicar estos niveles a lo largo de todo el proyecto.

1. Diseño

Durante esta fase habrá que plantear cuestiones fundamentales de seguridad y privacidad, anticipando todos los vectores de ataque y vulnerabilidades. La definición de los niveles aceptables de seguridad y privacidad al principio de un proyecto ayuda a un equipo a comprender los riesgos asociados a problemas de seguridad, corregir fallos de seguridad durante el desarrollo y aplicar los niveles adecuados de seguridad y privacidad a lo largo de todo el proyecto.

2. Implementación

Antes de insertar el código en el repositorio, será necesario realizar revisiones para aumentar la calidad general y reducir el riesgo de errores. El análisis de código fuente es un elemento clave en la revisión de código estático para encontrar posibles vulnerabilidades en el código que no se está ejecutando, Asimismo, será necesario prevenir los ataques por inyección con la validación de entradas para evitar que los datos con formato incorrecto se conserven en la base de datos o desencadenen errores en otros componentes. La codificación de salidas proporciona defensas por niveles para aumentar la seguridad del sistema como un todo.

También será esencial separar los datos de producción, y no utilizarlos para desarrollo, pruebas o cualquier otro fin distinto al establecido. Y, desde luego, seguir otras buenas prácticas como la anonimización para todo el proceso, o evitar el almacenamiento en caché de contenido confidencial.

3. Comprobación

Esta fase pasa por verificar que el código cumple los principios de seguridad y privacidad que se establecieron en las fases anteriores. Incluye, por ejemplo, la búsqueda y corrección de vulnerabilidades en las dependencias de la aplicación.

Otra buena práctica es probar la aplicación en estado operativo. Las pruebas dinámicas de seguridad de aplicaciones (DAST, por sus siglas en inglés) permiten analizarlas mientras se ejecutan para buscar vulnerabilidades como daños en la memoria, configuraciones de servidor no seguras, ataques de script entre sitios, inyección de código, etc. Las pruebas de vulnerabilidades, por su parte, consisten en inducir un error introduciendo datos aleatorios o con formato incorrecto, lo que ayuda a revelar posibles problemas de seguridad antes del paso a producción.

Por último, la revisión de la superficie de ataque tras completar el código ayudará a garantizar que se han tomado en cuenta los cambios en el diseño y la implementación, y que los nuevos vectores de ataque se han revisado y mitigado. Por su parte, las pruebas de penetración (o pentesting) son ataques simulados para encontrar las vulnerabilidades de seguridad y todos los sistemas que podrían tener acceso a las aplicaciones, su funcionalidad y sus datos.

DevSecOps: una nueva forma de concebir el desarrollo

De acuerdo con un informe publicado en 2020, el 92% de los profesionales de TI no creen que su organización esté preparada para proteger los servicios de nube pública. Esto sucede porque no solo depende de la seguridad como parte del equipo de desarrolladores y operadores, también lo es la propia infraestructura de seguridad.

DevSecOps es la práctica de integrar las pruebas de seguridad en cada etapa del proceso de desarrollo de software. Incluye herramientas y procesos que fomentan la colaboración entre los desarrolladores, los especialistas en seguridad y los equipos de operaciones para crear un software que sea eficiente y seguro.

Los beneficios son múltiples y perfectamente visibles: reducción en el tiempo de entrega, detección temprana y automática de vulnerabilidades, desarrollo de nuevas características de forma segura, mejoras en la colaboración y la comunicación entre equipos y garantía de cumplimiento normativo, entre otras.

En definitiva, hoy en día, el cloud es un espacio preferente a la hora de crear aplicaciones y servicios, y métodos como el DevSecOps son fundamentales para el funcionamiento de la infraestructura y seguridad de la tecnología en las empresas. Pero sólo una estrategia integral y que se ponga en práctica desde el inicio de cada proyecto permitirá agilizar los tiempos, reducir los costes y garantizar la seguridad en el desarrollo