Los riesgos de la conectividad a las API
Según Tyler Jewell, director general de Dell Technologies Capital, el mundo va camino de contar con un billón de puntos de conexión programables, o lo que cualquier técnico está habituado a leer como “endpoints". Las permutaciones para combinar APIs y fuentes de datos son infinitas. Y en 2020, para bien y para mal, la carrera hacia la transformación digital es más feroz que nunca.
En la economía de la nube, hay cierta belleza en la facilidad con la cual los datos se mueven entre plataformas, pero estar tan expuestos y conectados a extraños y terceros no deja de entrañar sus riesgos. Si bien es cierto que las instalaciones de herramientas Atlassian en servidores propietarios ofrecen mayores opciones de securización, existen problemas específicos relacionados con el gran volumen de usuarios y el difícil equilibrio entre dar libertad al usuario para que cree valor y controlarlo para evitar incidentes indeseables.
Pongamos el clásico ejemplo de JIRA, una plataforma usada cada día por cientos de miles de desarrolladores en todo el mundo. ¿Con cuántos sistemas diferentes está integrada su API REST? Es imposible dar un número. Y aunque no faltan scripts e integraciones esenciales para personalizar una plataforma que debe soportar prácticamente cualquier lógica de negocio, muchas de esas conexiones se nos pueden escapan a quienes tenemos la responsabilidad de controlarlas. Nunca serán auditadas. Nunca se les dará seguimiento. Seguirán siendo desconocidas.
Las plataformas no-code son los principales impulsores de la TI en la sombra
En el mundo Atlassian y más allá, las plataformas de automatización sin código como Zapier, Unito, IFTTT o automate.io son una de las principales fuerzas que impulsan la TI en la sombra. Gracias a ellas, cualquier usuario sin conocimientos de programación puede configurar integraciones en minutos sin pedir ayuda (o permiso) al departamento de TI. Y todo lo que necesita este hipotético usuario son... ¡sus credenciales!
Sin embargo, usar las credenciales para autorizar el acceso al API REST de Jira supone un problema doble:
- El problema interno es que cada empleado puede usar la API de Jira como quiera.
- El problema externo es que las credenciales se transmiten por Internet sin haber sido encriptadas y se almacenan en una base de datos externa. Eso hace que las claves de los usuarios sean tan vulnerables como la peor gestionada de entre todas las aplicaciones externas que se hayan integrado.
¿Pero realmente es tan grave el problema? ¿No se podría estar tomando una decisión implícita de externalizar también la seguridad de la API en los equipos de Zapier y compañía? ¿Y no podría esa decisión ser acertada?
Para aclarar esas dudas, que sin duda son razonables, en este artículo echaremos un vistazo, en primer lugar, a los abusos más típicos de las plataformas no-code y a sus consecuencias para la productividad. Para finalizar, veremos qué se puede hacer para retomar el control de las API sin cerrar su uso a los usuarios no técnicos.
Un breve catálogo de integraciones monstruosas que reducen valor
Todos los ejemplos de este catálogo incluyen un usuario no cualificado, una plataforma de automatización sin código como Zapier, y una conexión a la API de una aplicación Atlassian... que no debería haber existido. Un cóctel explosivo.
El resultado es una galería de los horrores con el susto añadido de que está instalada en nuestras oficinas. Como la arquitectura corporativa es el hábitat perfecto para que estas pequeñas bestezuelas se extiendan y florezcan, es muy probable que ya estés coexistiendo con ellas. Esa es la definición de Shadow IT: sólo la verás cuando sea demasiado tarde.
El Project Management Institute recomienda reconocer la existencia de un problema para que deje de ser un factor que no sabemos que desconocemos y se convierta en algo que sabemos desconocer: al pasar del unknown unknown al known unknown, podemos gestionar la amenaza de las plataformas no-code como cualquier otro riesgo. Esa es la función de esta galería de los horrores.
Un diseño pobre
Como a menudo quien está tras las integraciones no tiene formación en ingeniería, es posible que el diseño no sea una auténtica solución al problema, ya sea porque está mal conceptualizado o porque añade nuevas ineficiencias.
Un ejemplo bastante básico, pero no demasiado raro se da con el uso de Google Forms para recoger comentarios de clientes que luego se vuelcan en JIRA para tratarlos. Si la solución consiste sólo en reunir la información sin un proceso completo que tenga en cuenta cómo se realizará el análisis y el triaje de lo que se está volcando, entonces sencillamente estamos convirtiendo Jira en un basurero. La aplicación se ralentizará, será más difícil tener una visión global y los resultados de negocio serán escasos o nulos.
Por si fuera poco, si el formulario sigue estando accesible a cualquiera, podría ser una superficie desde la que lanzar ataques DDOS contra tu instancia de JIRA.
Una mala ejecución
También puede suceder que el problema sea importante, la solución razonable... pero la ejecución fracase. Detrás de una mala ejecución puede haber muchísimos factores (y a veces concurren varios a la vez). Por dar un ejemplo, un usuario habituado a emplear un único tipo de ticket en JIRA puede carecer de la información necesaria para:
- Tener en cuenta excepciones y casos límites al flujo
- Planificar cambios a los campos y los workflows de JIRA afectados por la integración
- O identificar conflictos con otras automatizaciones.
Los bucles infinitos son un ejemplo particularmente destructivo de mala ejecución que ocurre con relativa facilidad cuando se emplean asistentes visuales para crear nuevas lógicas de negocio. Cuando ocurra, cualquier bucle infinito utilizará tantos recursos como estén disponibles: ancho de banda, potencia de cálculo, memoria... nada es suficiente una vez están desencadenados. Y lo peor es que incluso los usuarios avanzados pueden caer en esta trampa, como puedes ver en el testimonio de Melissa Hubbard con Microsoft Flow.
En la definición de Melissa, "El bucle infinito ocurre cuando se establece un flujo que 1) se inicia al actualizar o modificar los datos, 2) a su vez esos mismos datos son modificados por el flujo, volviendo a activar el flujo una y otra vez".
Una integración redundante
Ya que estamos hablando de integraciones descentralizadas en grandes paisajes corporativos, es cuestión de tiempo antes de que diferentes equipos empiecen a dar respuestas solapadas al mismo problema, reinventando la rueda y acabando por sobrecargar sus sistemas.
Un ejemplo clásico es cuando dos individuos que trabajan en equipos separados utilizan Zapier para crean notificaciones de JIRA en Slack contra los canales de sus respectivos equipos. Como no necesitan involucrar a nadie más, no comparten su conexión más allá de su equipo y no descubrirán lo que la otra persona está haciendo. Y al ser diferentes las implementaciones, cada uno de estos dos equipos comenzará a recibir información diferente de la misma fuente, creando distorsiones sobre el contenido de JIRA.
Un trabajo innecesario
A veces no hay ningún problema de fondo que resolver, sino que se crean automatizaciones o integraciones para satisfacer preferencias personales.
Por ejemplo, aunque muchas compañías tienen Outlook, muchos empleados prefieren leer sus correos electrónicos en Gmail. Algunos de ellos podrían ver con buenos ojos una integración que envíe notificaciones de correo electrónico a su dirección personal de gmail con los asuntos pendientes más destacados de JIRA.
Aunque se gane en productividad, la integración con una cuenta de correo electrónico personal que no está protegida por el SSO corporativo es difícil de justificar desde el punto de vista de la organización.
Los olvidados
También es muy común olvidarse de integraciones superfluas. ¿Quién no ha visto alguna vez un canal de Slack en el que alguien montó algunas notificaciones de JIRA como un experimento, pero cuando esa misma persona abandonó el canal, olvidó desactivar la automatización? Este tipo de comportamiento sucede constantemente, y no sólo es un desperdicio: también ofrece una superficie de ataque adicional a la espera de ser explotada.
Recomendación: Establece una política de confianza cero con perfiles no técnicos
Si tras haber repasado estos clásicos ejemplos de integraciones monstruosas todavía prefieres permitir a todos tus empleados que creen integraciones con tus instancias Atlassian, adelante. Es posible que se genere más valor para el negocio del que vayas a poder perder. Pero asegúrate de tener preparados procedimientos que te permitan manejar los incidentes de seguridad que aparezcan. Porque aparecerán.
Pero si te preocupa que la TI en la sombra esté generando mucho tráfico de datos, consumiendo espacio de almacenamiento y abriendo las puertas para la pérdida de información confidencial, puedes establecer una política de confianza cero entre perfiles no técnicos con la cual proteger JIRA y Confluence de los riesgos de erosión que representan las API.
Para ello, recomendamos dos apps disponibles en el Marketplace de Atlassian y fabricadas por resolution, partner de AT Sistemas y líder del mercado en soluciones de gestión de usuarios para clientes enterprise. Aunque hay competidores para cada una de estas dos apps, resolution garantiza la mejor calidad-precio y las características más completas, además de ofrecer el mejor soporte del ecosistema Atlassian.
Paso 1: Deshacerse por completo de las credenciales
Con SSO, los usuarios podrán navegar entre sus aplicaciones empresariales sin tener que autenticar en cada herramienta, porque las contraseñas locales desaparecen y son sustituidas por una única identidad centralizada. Las soluciones de Single Sign-On tienen una consecuencia muy interesante: si tus usuarios no tienen una contraseña local en JIRA, no podrán usarla para acceder a la API REST de JIRA.
SAML SSO permite generar una experiencia de inicio de sesión centralizada y sin fricciones que se extiende a las aplicaciones Atlassian en Server y Data Center.
Paso 2: Centralizar las conexiones de la API
Ahora que los usuarios no pueden crear zaps con sus credenciales, comenzarán a enviar solicitudes a los administradores Atlassian, quienes pueden utilizar la app API Token Authentication (para JIRA o para Confluence) para crear tokens de acceso por cada conexión solicitada por un usuario.
La aplicación tiene varias características interesantes con el objetivo de maximizar la seguridad:
- Las contraseñas pueden ser desactivadas completamente como método para acceder a la API. En ausencia de una solución de SSO, esta opción genera el mismo resultado.
- Un modelo de permisos flexible define quién puede crear tokens y quién puede usarlas. Por ejemplo, algunos clientes de resolution establecen que sólo los administradores puedan crear tokens en nombre de otros usuarios.
- Los tokens pueden ser de sólo lectura, de modo que las integraciones creadas por los usuarios no tengan la capacidad de alterar o contaminar la base de datos de JIRA.
Los tokens de la API se han convertido rápidamente en la forma más común, cómoda y segura de reemplazar las contraseñas como método para acceder a las API.
Conclusión y beneficios de crear una cultura que antepone la seguridad
Centralizar las conexiones a las API REST de tus herramientas Atlassian permitirá a tu organización supervisar su uso y mantener a raya a la TI en la sombra. En términos generales, tu tecnología será más segura y más productiva. Asegúrate de tener en cuenta los principales beneficios del enfoque, porque los necesitarás para establecer como una visión compartida y combatir la resistencia al cambio.
Al establecer este proceso, estás comunicando claramente que, si bien la innovación es primordial, la seguridad es insuperable. Los empleados deben evitar siempre riesgos innecesarios manteniendo sus credenciales seguras, lo que implica no utilizarlas para conectarse a servicios de terceros, por mucho que les facilite la vida.
Es de esperar que la implementación de un enfoque de tolerancia cero a este tipo de riesgos sea el pistoletazo de partida para una conversación en toda la organización que podría llegar a ser acalorada. Esperemos que eso cree un impulso que el liderazgo pueda utilizar para concienciar sobre los riesgos asociados a las mala prácticas de las API, junto con los beneficios de hacerlo bien. No dudes en mostrar los resultados del esfuerzo: cuánto trabajo superpuesto se ha identificado, cuántas cuentas se han asegurado y cuántas automatizaciones de negocios seguras se han conseguido catalogar.
Este artículo, escrito por Jaime Capitel, es fruto de una colaboración con re:solution, Gold Marketplace Partner de Atlassian y líder en apps de Enterprise User Management para aplicaciones Atlassian en Server y Data Center.