Introducción a APIM

Objetivos de la sesión

En la siguiente sección, se plantea cubrir los siguientes objetivos de estudio.

1. Aprender la historia de API y APIM.
2. Conocer los pilares básicos de APIM.
3. Conocer la historia resumida de APIM.
4. Entender las diferencias de publicación de APIs.
5. Conocer sobre la economía de API.
6. Conocer cuáles son los principales pilares sobre los que se fundamenta APIM.
7. Entender los retos que implica compartir los activos de información.
8. Conocer los conceptos principales de seguridad, gobierno y observabilidad relacionados.

Conceptos de APIM

Que es API

API: Acrónimo de Application Programming Interface. Se refiere al conjunto de librerías, servicios y/o componentes que facilitan la interacción entre diferentes sistemas

Que es APIM.

Acrónimo de API Management o Gestión de API. Se trata de una práctica, que viene desarrollándose desde hace más de 20 años, en la cual se busca exponer los activos informáticos de las organizaciones; agregando Gobierno y Seguridad en dicha exposición.

Breve historias de las APIs

Orígenes

• Las API se usaban como bibliotecas para los sistemas operativos.
• Se empezaron a desarrollar para compartir y reutilizar código, lo que simplificó el proceso de desarrollo.
• En 1974, el término API se introdujo en un artículo que comparaba los enfoques relacionales y de red.

Evolución

A principios del 2000, las API se habían convertido en una tecnología importante para integrar datos de forma remota.

• La API moderna se basa en estándares como HTTP y REST, que son sencillos para los desarrolladores.
• La API moderna se concibe más como un producto que como código.
• La API moderna tiene un ciclo de vida de desarrollo de software (SDLC).

Aplicaciones

• Las API se han aplicado en el comercio electrónico, las redes sociales, el cloud computing y la movilidad.
• La integración de API ha ayudado a hacer posible que negocios como Amazon y eBay se convirtieran en algo común.

Conceptos relacionados

APIS Públicas y Privadas.

	API Publica	API Privada
Disponibilidad	Está disponible para cualquier persona	Solo para usuarios autorizados
Uso	Puede ser utilizada por empresas, desarrolladores y el público	Utilizada internamente por una organización o un aliado autorizado.
Objetivo	Permite a los desarrolladores externos acceder a información	Mejora la conectividad interna y la seguridad de la empresa

Las API privadas son más utilizadas en entornos empresariales y se suelen implementar para:

• Integrar sistemas internos
• Construir nuevos sistemas
• Aumentar la productividad
• Integrar diferentes sectores
• Optimizar la comunicación interna
• Reducir costos
• Aumentar la flexibilidad

Las API públicas pueden ser gratuitas u de pago, y normalmente se accede a ellas mediante una clave API. Un ejemplo de API pública es la API de Google Maps.

Economía de API

La economía de las API es un modelo de negocio que se basa en el uso de las interfaces de programación de aplicaciones (API). Las API son conjuntos de reglas y protocolos que permiten que diferentes aplicaciones se comuniquen entre sí.

La economía de las API ha revolucionado la forma en que las empresas desarrollan, operan y expanden sus negocios.

Ventajas de la economía de las API

Principales pilares de APIM

Los siguientes pilares, permiten tener un mejor entendimiento de los temas que giran entorno a la practica de APIM y a sus principlaes objetivos y necesidades.

Principales retos de APIM

Cuando se habla de los beneficios de adoptar APIM, se debe tener en cuenta los principales retos de la práctica, que se vuelven factores clave al momento de ejecutarlos.

Los principales retos de la gestión de API son la seguridad, la disponibilidad, la escalabilidad y la coordinación.

Las principales amenazas de seguridad (OWASP Top 10)

El OWASP Top 10, es una lista de los 10 riesgos de seguridad más críticos para las aplicaciones web. La lista es elaborada por el Open Web Application Security Project (OWASP), una organización sin fines de lucro.

Objetivos de OWASP Top 10

• Ayudar a los desarrolladores a proteger mejor las aplicaciones que diseñan e implementan.
• Aumentar la concienciación sobre las debilidades de seguridad comunes de las aplicaciones web.
• Minimizar y mitigar los riesgos de seguridad más recientes.

Como se elabora la lista

• Se basa en el consenso de expertos en seguridad de todo el mundo.
• Se clasifica los riesgos en función de la frecuencia de los defectos de seguridad, la gravedad de la vulnerabilidad y su impacto potencial.
• Se actualiza regularmente.

Cuales son los principales riesgos

En la siguiente table, podemos observar todas las vulnerabilidades más importantes, que deben ser consideradas al afrontar proyectos de API que expondrán los activos tecnológicos de la organización.

A01:2021 – Pérdida de Control de Acceso.

Sube de la quinta posición a la categoría con el mayor riesgo en seguridad de aplicaciones web; los datos proporcionados indican que, en promedio, el 3,81% de las aplicaciones probadas tenían una o más Common Weakness Enumerations (CWEs) con más de 318.000 ocurrencias de CWEs en esta categoría de riesgo. Las 34 CWEs relacionadas con la Pérdida de Control de Acceso tuvieron más apariciones en las aplicaciones que cualquier otra categoría.

A02:2021 – Fallas criptográficas

Sube una posición ubicándose en la segunda, antes conocida como A3:2017-Exposición de Datos Sensibles, que era más una característica que una causa raíz. El nuevo nombre se centra en las fallas relacionadas con la criptografía, como se ha hecho implícitamente antes. Esta categoría frecuentemente conlleva a la exposición de datos confidenciales o al compromiso del sistema.

A03:2021 – Inyección

Desciende hasta la tercera posición. El 94% de las aplicaciones fueron probadas con algún tipo de inyección y estas mostraron una tasa de incidencia máxima del 19%, promedio de 3.37%, y las 33 CWEs relacionadas con esta categoría tienen la segunda mayor cantidad de ocurrencias en aplicaciones con 274.000 ocurrencias. El Cross-Site Scripting, en esta edición, forma parte de esta categoría de riesgo.

A04:2021 – Diseño Inseguro

Nueva categoría para la edición 2021, con un enfoque en los riesgos relacionados con fallas de diseño. Si realmente queremos madurar como industria, debemos "mover a la izquierda" del proceso de desarrollo las actividades de seguridad. Necesitamos más modelos de amenazas, patrones y principios con diseños seguros y arquitecturas de referencia. Un diseño inseguro no puede ser corregida con una implementación perfecta debido a que, por definición, los controles de seguridad necesarios nunca se crearon para defenderse de ataques específicos.

A06:2021 – Componentes Vulnerables y obsoletos.

Antes denominado como Uso de Componentes con Vulnerabilidades Conocidas, ocupa el segundo lugar en el Top 10 de la encuesta a la comunidad, pero también tuvo datos suficientes para estar en el Top 10 a través del análisis de datos. Esta categoría asciende desde la novena posición en la edición 2017 y es un problema conocido que cuesta probar y evaluar el riesgo. Es la única categoría que no tiene ninguna CVE relacionada con las CWEs incluidas, por lo que una vulnerabilidad predeterminada y con ponderaciones de impacto de 5,0 son consideradas en sus puntajes.

A07:2021 – Fallas de Identificación y Autenticación.

Previamente denominada como Pérdida de Autenticación, descendió desde la segunda posición, y ahora incluye CWEs que están más relacionadas con fallas de identificación. Esta categoría sigue siendo una parte integral del Top 10, pero el incremento en la disponibilidad de frameworks estandarizados parece estar ayudando.

A08: 2021 – Fallas en software y en la integridad de datos.

Es una nueva categoría para la edición 2021, que se centra en hacer suposiciones relacionadas con actualizaciones de software, los datos críticos y los pipelines CI/CD sin verificación de integridad. Corresponde a uno de los mayores impactos según los sistemas de ponderación de vulnerabilidades (CVE/CVSS, siglas en inglés para Common Vulnerability and Exposures/Common Vulnerability Scoring System). La A8:2017-De-serialización Insegura en esta edición forma parte de esta extensa categoría de riesgo.

A09:2021 – Fallas en registro y monitoréo.

Previamente denominada como A10:2017-Registro y Monitoréo Insuficientes, es adicionada desde el Top 10 de la encuesta a la comunidad (tercer lugar) y ascendiendo desde la décima posición de la edición anterior. Esta categoría se amplía para incluir más tipos de fallas, es difícil de probar y no está bien representada en los datos de CVE/CVSS. Sin embargo, las fallas en esta categoría pueden afectar directamente la visibilidad, las alertas de incidentes y los análisis forenses.

A10:2021 – Falsificación de Solicitudes del Lado del Servidor.

Es adicionada desde el Top 10 de la encuesta a la comunidad (primer lugar). Los datos muestran una tasa de incidencia relativamente baja con una cobertura de pruebas por encima del promedio, junto con calificaciones por encima del promedio para la capacidad de explotación e impacto. Esta categoría representa el escenario en el que los miembros de la comunidad de seguridad nos dicen que esto es importante, aunque no está visualizado en los datos en este momento.

Fuente: OWASP Top 10

Al tomar en cuenta los riesgos y vulnerabilidades anteriores; se vuelve más fácil la solución y anticipación de dichas vulnerabilidades, con lo que podemos fortalecer los elementos necesarios para garantizar su mitigación, con los controles y prácticas que se describirán en la siguiente sección.

Conceptos y prácticas de mitigación de riesgos.

Como parte de los elementos que conforman APIM, se cuenta con diversas herramientas y practicas destinadas a la mitigación y control de riesgos y exposición de los activos informáticos. Estas van desde el control de consumo y tráfico, hasta detección de fallas e interrupción controlada de los servicios; elementos que previenen escenarios catastróficos de caídas más severas de la infraestructura de la organización, así como la prevención de robo de información por implementar componentes de muy alta complejidad. Además, al incorporar prácticas como el desacoplamiento y miniaturización de servicios, acompañado de integración continua; pueden ayudar a controlar de mejor forma el rendimiento y la seguridad de la plataforma.

La siguiente es una lista de conceptos y prácticas, así como ubicación y componentes responsables de apoyar en las labores anteriormente descritas. Se clasificará por Dominio para un mejor entendimiento conceptual y para comprender mejor el valor final de G6Flow® como acelerador de estos elementos.

Arquitectura

Micro servicios

• El uso de Micro servicios, propicia la aplicación de estrategias de división de las cargas de trabajo que se deben soportar por parte de la infraestructura.

Disponibilidad

• Al usar micro servicios, se puede jugar con la disponibilidad de la plataforma, habilitando más pods a los servicios específicos que así lo requieran, y limitando el crecimiento, en activos ociosos; tomando en cuenta horarios, temporadas del año, o algún otro parámetro que sirva para garantizar la disponibilidad.

Seguridad

Autenticación y Autorización

• Se debe utilizar siempre un esquema de Zero Trust, que garantice que los consumidores SIEMPRE tengan que solicitar llaves y tokens efímeros, lo que garantiza que se renueven constantemente estas llaves y no se comprometan los accesos.
• OAUTH2 y OpenID Connect, garantizan que con la verificación del cliente (app) que consume, y el usuario que utiliza el cliente, obtengan tokens que cuenten por lo menos con 2 factores de autenticación o MFA.
• En caso de comunicación entre servidores, se sugiere habilitar MTLS (Mutual Transport Layer Security), para agregar un factor de seguridad adicional.

Cifrado de canales y mensajería

• TLS, y HTTPS se deben utilizar siempre, usando certificados validados por una CA publica o una privada de la organización.
• Si existe información sensible, se debe enmascarar mediante las capacidades propias de los API Gateways o sus componentes internos.

Inyección de código

• Se debe evaluar el 100% de la mensajería, en búsqueda de código malicioso, inyectado al momento de recibir las peticiones por parte de los consumidores.
• Se debe tener especial cuidado con:
• Inyección de SH
• Inyección de SQL
• Inyección de Cross-site
• Inyección de XML.

Uso de componentes actualizados

• Se debe ejecutar componentes que no usen tecnología obsoleta, sobre todo a nivel de seguridad, ya que, desde ahí, se abren brechas importantes que pueden comprometer la integridad de la plataforma, y nuestra información.

Perímetro y Firewall

• Siempre se aconseja el uso de un firewall especializado de capa 4 para el bloqueo de paquetes maliciosos.
• Además, se recomienda usar un Application Gateway, que funciona en la capa 7 de red, y refuerza los elementos de seguridad existentes en los API Gateways o las mallas de servicios.

Trafico

Cuotas y Limites de consumo

• Desde la observación del tráfico, se deben implementar mecanismos de Cuota de consumo y Limites por segundo, que ayuden a mantener los niveles de servicio del backend en óptimas condiciones.

Gestión de errores

• Si algún endpoint presenta errores al momento de consumir su backend, o al momento de ser consumido, se deben aplicar controles de “Circuit Breaker”, para impedir que se sigan respondiendo a servicios que se encuentran “Abajo”.

Monetización y empaquetado

• A partir de la identificación del cliente que consume los servicios, es posible agruparlos, y contabilizar la cantidad de veces que se han consumido ciertos servicios, con lo que se puede habilitar el modelo de negocio de monetización por consumo de servicios, y se pueden cobrar, por ejemplo, por paquete, por consumos mensuales o por subscripción limitada o ilimitado, según el paquete que se requiera.

Intercambio de información

Formato de datos unificado

• Se sugiere establecer un formato específico para intercambiar información. Este puede ser XML, JSON, YAML, etc. Siempre se sugiere un formato comun y abierto, que puede ser JSON o YAML.

Homogeneidad de consumo de los servicios

• Para acelerar las facultades del desarrollador, siempre es mejor manejar un formato de presentación y consumo de servicios especifico, con lo que la adopción y resistencia al cambio por parte de los equipos de desarrollo e integración, se reduce y se aprovecha los equipos al máximo.

Monitoreo

Supervisión de eventos y trafico

• Se debe cuidar la integridad de la plataforma, mediante el monitoreo de la infraestructura y de las respuestas que se emiten desde la plataforma. Cada componente debe contar con la posibilidad de monitoreo con sus propios medios, o mediante integración con otras soluciones específicas de monitoreo.

Recolección de métricas

• Todos los componentes, deben ser capaces de informar mediante protocolos de monitoreo como SNMP o envío REST hacia recolectores diseñados para obtener métricas, y concentrarlas para las labores de monitoreo requeridas.

Recolección de auditoria

• Se debe tener la capacidad de recolectar la mensajería que ocurre entre los componentes. Esto puede ser total o parcial, según las necesidades de recolección y la importancia de los servicios a nivel transaccional y de generación de evidencias de consumo.

Alertas en la operación

• Al momento de detectar una anomalía, o un grupo de anomalías consecutivas, se debe contar con mecanismos que puedan notificar de manera oportuna sobre estos comportamientos, para así garantizar los niveles de servicio requeridos por los consumidores.

Documentación e independencia tecnológica

Generación de catálogo de servicios

• Una buena práctica, es la de contar con un portal, donde se puede acceder a la documentación de los servicios, así como que ayude a solicitar permisos y llaves para lograr dichos consumos. Un API Developer Portal es vital para esto.

Servicios soportados por varios lenguajes

• Al utilizar un formato soportado universalmente, se habilita la omni canalidad, y se facilita que pueda ser consumido por virtualmente cualquier lenguaje de programación existente.

Uso de estándares, sin limitación por los mismos.

• Al usar formatos estándares, se minimiza el margen de error al consumo, debido a fallas en los formatos, con lo que se utiliza el estándar de presentación de los datos, pero fácilmente se debería agregar soporte a diversos formatos de datos, sin cambiar la estructura de los servicios de manera importante.
• Para esto, los Gateways y mallas, deberían de contar con identificadores de tipo de contenido, y de tipo de respuesta, para poder manejar la recepción y envió de mensajería, en los formatos soportados declarados en la documentación y definición de los servicios.

Con la ayuda de los conceptos anteriores, se logrará un entendimiento más profundo de las capacidades del producto, así como del valor real de contar con una herramienta que simplifique la aplicación y vigilancia de todos los puntos más destacados de seguridad, gobierno, monitoreo, integración y control de la disponibilidad del inventario de servicios API de nuestra organización.

Las herramientas

API Gateway

Un API Gateway (Puerta de Enlace de Aplicación Programada) es una capa de abstracción que se encuentra entre los clientes y los servicios web en la nube, permitiendo a los desarrolladores crear, gestionar y proteger las APIs sin tener que preocuparse por la infraestructura subyacente.

Las principales características de un API Gateway son:

• Abstracción: El API Gateway se encarga de ocultar la complejidad de la infraestructura subyacente (por ejemplo, servidores, bases de datos) a los clientes y servicios web.
• Autenticación y autorización: El API Gateway puede autenticar y autorizar a los clientes antes de permitirles acceder a las APIs protegidas por contraseña o tokens de acceso.
• Caching y optimización: El API Gateway puede cachear respuestas comunes y realizar otras optimizaciones para mejorar el rendimiento de la aplicación.
• Monitorización y seguimiento: El API Gateway puede proporcionar métricas y registros sobre el tráfico de API, lo que ayuda a los desarrolladores a identificar problemas y mejorar la experiencia del usuario.
• Seguridad: El API Gateway se encarga de proteger las APIs contra ataques como la inyección SQL, cross-site scripting (XSS) y otros tipos de ataques maliciosos.

Service Mesh

Un Service Mesh (Malla de Servicios) es una capa de abstracción que se encuentra entre los servicios y la infraestructura de red, permitiendo a los desarrolladores gestionar y controlar el tráfico entre servicios en un entorno distribuido. El objetivo principal de un Service Mesh es proporcionar funcionalidades de gestión de servicio (como autenticación, autorización, monitorización, etc.) que pueden ser utilizadas por múltiples aplicaciones.

Las principales características de un Service Mesh son:

• Abstracción: El Service Mesh se encarga de ocultar la complejidad de la infraestructura subyacente a los servicios y aplicaciones.
• Control de tráfico: El Service Mesh puede controlar el tráfico entre servicios, permitiendo a los desarrolladores configurar rutas específicas o rechazar solicitudes basadas en criterios como IP, puerto, etc.
• Autenticación y autorización: El Service Mesh puede autenticar y autorizar a los servicios antes de permitirles acceder a otros recursos.
• Monitorización y seguimiento: El Service Mesh puede proporcionar métricas y registros sobre el tráfico entre servicios.
• Seguridad: El Service Mesh se encarga de proteger las comunicaciones entre servicios contra ataques como la inyección SQL, cross-site scripting (XSS) y otros tipos de ataques maliciosos.
• Flexibilidad: Los desarrolladores pueden personalizar el comportamiento del Service Mesh para adaptarlo a las necesidades específicas de su aplicación o entorno.

Swagger y Open API

Los Swagger Docs y OpenAPI son dos especificaciones similares para definir la estructura y funcionalidad de una API, lo que facilita a los desarrolladores documentar, probar y mejorar sus servicios.

La diferencia principal entre Swagger Docs y OpenAPI es que OpenAPI es el nuevo nombre del proyecto originalmente conocido como Swagger. La especificación OpenAPI es más completa y flexible que la versión anterior de Swagger.

Aquí hay algunas características clave de OpenAPI:

• Definición de API: OpenAPI permite definir la estructura y funcionalidad de una API, incluyendo métodos HTTP, parámetros, encabezados, cuerpos de respuesta y otros aspectos.
• Documentación: La especificación OpenAPI proporciona un lenguaje para documentar las APIs, facilitando a los desarrolladores entender la estructura y funcionalidad de la API.
• Generación de clientes: OpenAPI puede ser utilizada para generar clientes automatizados para las APIs, reduciendo el esfuerzo necesario para crear clientes personalizados.
• Integración con herramientas: OpenAPI se integra con varias herramientas y frameworks populares, como Spring Boot, Node.js, entre otros.

Diseño y estrategia API First

El concepto API First implica diseñar la estructura de una aplicación a partir de los servicios web que la comprenderán, en lugar de comenzar por el diseño del código. Esto tiene varios beneficios:

• Mayor claridad y simplicidad: Al enfocarse en la estructura de los servicios web, se puede lograr una mayor claridad y simplicidad al diseñar la aplicación
• Flexibilidad y escalabilidad: El enfoque API First permite a las aplicaciones ser más flexibles y escalables, ya que se pueden agregar o eliminar servicios sin afectar el código existente
• Mejor comprensión de los requisitos del negocio: Al centrarse en la estructura de los servicios web, es posible tener una mejor comprensión de los requisitos del negocio y crear soluciones más efectivas

Al utilizar OpenAPI como parte del diseño API First, se puede lograr un conjunto completo de beneficios, incluyendo:

• Mayor precisión: Al definir la estructura y funcionalidad de las APIs con detalle, se reduce el riesgo de errores o incompatibilidades.
• Mejora en la productividad: La generación de clientes automatizados y la integración con herramientas populares simplifican y aceleran el desarrollo de aplicaciones.
• Mayor escalabilidad: Al diseñar las APIs para ser flexibles y escalables, se pueden agregar o eliminar servicios sin afectar el código existente.

Conclusiones

La práctica de Gestión de APIs, involucra elementos que van desde el cambio de formatos, hasta el aseguramiento de la información, pasando por la recolección de datos en el medio y ciertas transformaciones útiles para el negocio. Siempre se debe tener en cuenta las capacidades del backend, para no sobre cargar la plataforma al momento de realizar las llamadas a la misma, y también se debe contemplar mecanismos para garantizar la disponibilidad de consumo, y la selectividad de los consumidores, lo que garantizara la protección de los datos al momento de abrir el consumo a los clientes.

Es de vital importancia considerar la clasificación de vulnerabilidades en la web realizada por OWASP, como un punto de partida para garantizar la tranquilidad y seguridad al momento de publicar los servicios y solicitar estándares rigurosos a los clientes y consumidores, para que no se vuelvan una brecha de nuestra información.

Para garantizar la aplicación de los elementos de seguridad, trazabilidad, exposición y disponibilidad, se pueden utilizar herramientas como los API Gateways y las mallas de servicio (Service Mesh), que sirven como puntos de control de tráfico, donde se puede realizar transformaciones y composición de datos, así como la incorporación de sensores para prevención de ataques a nivel de capa de aplicación de red.