Header Ads Widget

Ticker

6/recent/ticker-posts

¿Qué hace que una API de SaaS sea buena (desde una perspectiva de gestión de TI)?


 Las aplicaciones SaaS están a la vanguardia de las iniciativas de digitalización. Ponen a los usuarios empresariales en el asiento del conductor, lo que les permite probar y comprar directamente productos que satisfacen sus necesidades.

Los usuarios comerciales pueden estar comprando, pero los equipos de TI son en última instancia responsables de las mejores prácticas de seguridad de la información y gobierno. El personal de TI soporta la mayor parte de la aplicación de políticas lo mejor que puede a un número cada vez mayor de aplicaciones SaaS. A esta escala, las tareas rutinarias como la creación de cuentas de usuario o el análisis de la información de licencia requieren mucho tiempo, a menos que exista un elemento de automatización involucrado, preferiblemente a través de una API.

Las API de SaaS a menudo se centran en áreas funcionales del producto en lugar de aspectos de gestión. Este artículo analiza qué puntos finales de API importan desde una perspectiva de gestión de TI. Los compradores de TI pueden usar esto como una guía para la funcionalidad de API que deben buscar al adquirir aplicaciones SaaS, y los proveedores pueden comprender mejor cómo pueden ayudar a los gerentes de TI implementando API de administración sólidas.

Inicio de sesión único

Puede que no sea la API más moderna o sofisticada, pero la buena noticia es que la compatibilidad con SAML2 ahora está muy extendida en toda la industria. Los proveedores de identidad (IdP) como Okta y Azure AD enumeran más de 1000 aplicaciones SaaS que admiten SAML2. SAML facilita la vida de los usuarios al eliminar las contraseñas de aplicaciones individuales, lo que reduce significativamente las preocupaciones de los equipos de TI sobre la reutilización de contraseñas entre aplicaciones o contraseñas débiles.

Si bien SAML no admite directamente la administración de usuarios, dos formas sutiles en las que una aplicación implementa SAML pueden marcar una gran diferencia para los equipos de TI:

  1. Las aplicaciones pueden elegir qué hacer si un IdP presenta un nuevo usuario que la aplicación no ha visto antes. Al admitir el aprovisionamiento de usuarios "justo a tiempo" (creando automáticamente una cuenta de usuario básica cuando el IdP presenta un nuevo usuario), la carga de TI se reduce a la modificación de permisos.
  2. Cuando SSO está habilitado, una aplicación debe ofrecer la capacidad de evitar inicios de sesión convencionales con nombre de usuario / contraseña (a veces conocido como “habilitación de SAML big bang”). Esto significa que los equipos de TI pueden responder inmediatamente eliminando el acceso de un usuario en el IdP cuando un usuario abandona la organización. El usuario no podrá eludir el IdP iniciando sesión con credenciales específicas de la aplicación. Si bien es una buena práctica desactivar la cuenta de usuario en cada aplicación, tener una forma centralizada de bloquear rápidamente el acceso es un respaldo adecuado.

Gestión de cuentas y SCIM2

El protocolo SCIM es el mecanismo estándar de la industria para aprovisionar y desaprovisionar cuentas de usuario en productos SaaS. Las aplicaciones pueden elegir qué parte de la especificación SCIM implementar, pero incluso un subconjunto básico de SCIM proporciona una forma mucho más directa y completa de administrar cuentas de usuario que confiar en SAML. Los puntos finales de API REST estándar de SCIM permiten que un IdP enumere todas las cuentas de usuario, cree o actualice perfiles de usuario y los asigne a grupos de seguridad.

En comparación con confiar en una implementación de SSO específica, SCIM ofrece una forma mucho más estandarizada de aprovisionar y desaprovisionar el acceso. SCIM no es demasiado exigente en lo que respecta a los protocolos, pero los catálogos de aplicaciones de IdP indican que solo alrededor del 20% de las aplicaciones que admiten SAML también admiten SCIM. Esta cifra está creciendo pero aún muestra una gran brecha.

Para los proveedores desanimados por la especificación completa, vale la pena ser pragmático. Al decidir qué implementar, considere qué funciones de SCIM utilizan los principales IdP . En su mayoría, consisten en solo funciones de filtro básicas; rara vez tocan la sección de actualización masiva más compleja de la especificación SCIM.

Gestión básica de datos de usuario

Si no se admite SCIM, las API pueden ofrecer sus propios mecanismos para la gestión de usuarios. En el nivel más simple, muchos productos SaaS tienen un punto final para extraer una lista de usuarios actuales. Algunos también tendrán puntos finales para crear o modificar cuentas de usuario. Aunque estos pueden no ser compatibles con un IdP y pueden requerir la escritura de scripts personalizados, al menos ofrece una forma de automatizar algunos aspectos de la gestión de usuarios.

Cuentas de usuarios privilegiados

Un elemento importante de las revisiones periódicas de acceso de usuarios es centrar la atención en las cuentas privilegiadas. Si bien la pertenencia a un grupo llamado "Administradores" implica acceso privilegiado, esta no es una forma muy sólida de determinar si un grupo o función tiene privilegios, especialmente si una aplicación le permite crear sus propias funciones.

Algunas API te permitirán enumerar roles personalizados y enumerar sus capacidades, lo que te dará una forma de decidir si un rol tiene privilegios mediante programación. DocuSign es un buen ejemplo . En un nivel más simple, una API puede devolver un campo contra una cuenta de usuario como is_administrator.

Uso de licencia

Desde el punto de vista de la optimización de costos, una API necesita devolver si un usuario está accediendo activamente a la aplicación y el tipo de licencia que tiene. Esto le dará una forma clara de saber si desaprovisionar o degradar a un usuario.

Solo un subconjunto de API que devuelve una lista de usuarios también devolverá información como la última fecha de inicio de sesión que indica la actividad del usuario. Sin embargo, si los usuarios se autentican a través de un IdP usando SAML, esto es un problema menor, ya que normalmente puede obtener esta información del IdP.

De cualquier manera, si desea optimizar el uso de manera eficiente, la aplicación debe proporcionar una API que especifique el plan de licencia de cada usuario. Para algunas aplicaciones, debe comprender los patrones de uso con más profundidad para saber si se puede desaprovisionar a un usuario. El ejemplo clásico aquí es Zoom, donde un usuario puede iniciar sesión con poca frecuencia y tener un asiento pagado, pero esto podría ser innecesario si no está llevando a cabo ninguna reunión de más de 40 minutos con más de dos asistentes (la regla para un asiento pagado) . Se necesitan conocimientos específicos de la aplicación y un análisis potencialmente más profundo para automatizar realmente la optimización de la cuenta.

Pagos

Siguiendo con los temas financieros, puede ser útil para un equipo de TI recuperar la información de facturación y pago. Esto le permite realizar un seguimiento de los montos reales gastados sin tener que solicitar informes al equipo de finanzas. Esto podría ser útil si los equipos de TI están internamente intercambiando el acceso a las aplicaciones a diferentes departamentos, según el uso, también conocido como contracargo.

Registros de auditoría

Los registros de auditoría son un pilar de la gestión adecuada de la seguridad de la información, pero ya no es suficiente tener una página web con capacidad de búsqueda o una exportación CSV manual.

Los equipos de TI están alimentando cada vez más los datos de auditoría a las herramientas SIEM, que permiten la detección automatizada de brechas y el análisis detallado de incidentes. Por lo tanto, las herramientas SIEM necesitan algún tipo de API para extraer datos de un registro de auditoría. Idealmente, el registro de auditoría contendrá los conceptos básicos de la marca de tiempo, el actor, la entidad sobre la que se actuó y la dirección IP del actor.

Tenga en cuenta que las herramientas SIEM no sean compatibles con el acceso a la API de aplicación directa, por lo que puede que tenga que crear una secuencia de comandos para sondeo de datos de registro de auditoría y escribir en un archivo, que puede ser procesada por fluentdlogstasho alguna otra herramienta de la ingestión de registro SIEM . Por ejemplo, salesforce le permite recuperar fácilmente una lista de archivos de registro de eventos y descargarlos individualmente como CSV.

Estandarizar las API de eventos de auditoría, potencialmente como una extensión de SCIM, sería un movimiento positivo para la industria de aplicaciones SaaS.

Autenticación y autorización de API

Las API suelen ofrecer una clave de API o compatibilidad con OAuth2 para autenticación y autorización. Las claves de API son fáciles de entender e implementar, pero tienen desventajas importantes: a menudo están vinculadas a cuentas de administrador y pueden proporcionar a los clientes de API acceso administrativo completo.

La compatibilidad con OAuth2 bien implementada le permitirá limitar con precisión qué "alcances" de acceso se otorgarán a los clientes. Los alcances son definitivamente preferibles ya que limitan los datos expuestos. Si está escribiendo scripts para conectarse a través de OAuth2, si la aplicación ofrece el flujo de Credenciales de cliente , le facilitará la vida, ya que es fácil de implementar. Sin embargo, el flujo del código de autorización ofrece una experiencia de usuario final más sencilla al conectarse a una API.

Cualquiera de los enfoques significará que obtendrá un token de acceso de corta duración, que puede actualizarse o regenerarse. Esto le da la tranquilidad de que las credenciales no se envían con cada solicitud (como ocurre con una clave API), y el token de acceso tiene una vida limitada si se filtra.

Una clave de API filtrada es más importante, ya que es inherentemente de larga duración hasta que la rota. La rotación manual de claves de API puede resultar incómoda si varios scripts utilizan la misma clave de API, por lo que OAuth2 es definitivamente un enfoque más sólido.

Una palabra final sobre costos

Los proveedores de aplicaciones SaaS son cada vez más conscientes del valor que los equipos de TI otorgan a las buenas API de gestión.

Desafortunadamente, los proveedores también ven esto como una manera fácil de presionar a las empresas para que paguen por planes más costosos al restringir el soporte SAML o SCIM a puntos de precio premium. Algunos proveedores incluso restringen el acceso al registro de auditoría a menos que tenga un costoso plan empresarial. Verifique la matriz de características del plan cuidadosamente cuando seleccione el software.

Al negociar contratos, vale la pena presionar para que se incluya algo básico como SAML a un precio más bajo, especialmente si no necesita otras características incluidas en un plan premium. Para los proveedores que lean esto, considere que facilitar el acceso probablemente aumentará el uso de sus productos: ofrecer SAML listo para usar podría ser un movimiento comercial inteligente.

Publicar un comentario

0 Comentarios