Header Ads Widget

Ticker

6/recent/ticker-posts

Diseño de pautas de uso de API para clientes bot


 En la primavera de 2017, Twitter publicó una serie de pautas para los usuarios de API automatizados que utilizan bots . Estas pautas se crearon para ayudar a controlar la intención, las acciones y el resultado de los bots en el servicio. En consecuencia, hubo un debate sobre lo que hacían y no hacían estas directrices, y lo valioso que era ese conjunto de directrices.

Los bots son extremadamente poderosos, y es por eso que se utilizan tanto en la administración de servicios moderna. Los bots pueden realizar cientos de acciones que de otro modo serían monótonas y que requieren mucho tiempo, y resolver estas acciones en una única interfaz de estilo "hacer clic para ejecutar". Son desarrollados por consumidores de API que desean llevar a cabo funciones de rutina, proveedores que desean permitir ciertos rangos de actividades o por otros desarrolladores de API que desean interactuar con sistemas externos.

Si bien los bots tienen un gran poder para completar tareas, si no se controlan, pueden abusar de una API. Por supuesto, con habilidades tan poderosas, la necesidad de proteger estos bots y garantizar que sus acciones estén permitidas es muy importante.

En este artículo, discutimos las responsabilidades que deben tener los bots y las pautas que deben regir su uso. Si bien identificamos algunas pautas de uso específicas, tenga en cuenta que estas son simplemente pautas sugeridas: cada red es diferente con sus propias complejidades únicas.

¿Por qué preocuparse por los bots?

¿Son los bots realmente tan peligrosos? Después de todo, las únicas personas que necesitan bots son los administradores , y se debe confiar en ellos, ¿verdad?

Primero, una nota sobre la confianza dentro de los equipos de administración: todas las interacciones en la red deben tratarse con el mismo nivel de precaución. Poner demasiada confianza en la buena voluntad de los demás puede tener consecuencias perjudiciales y, como tal, incluso los bots de administración deberían estar fuertemente regulados y controlados.

En segundo lugar, los bots no son solo para la administración , pueden extender la funcionalidad de su API para desarrolladores y consumidores finales por igual sin requerirles que desarrollen herramientas adicionales. Sin bots, si un usuario desea eliminar todas sus publicaciones en su servicio, descargar una gran cantidad de imágenes o recuperar todas las entradas de una fecha determinada, debe vincularse a su API o utilizar un bot prediseñado.

Como tal, el valor de los bots no se puede ignorar. Dicho esto, algunos informes sugieren que el 52% de todo el tráfico de Internet se debe a los bots , y sin las pautas adecuadas, este ejército masivo de bots puede hacer cosas bastante horribles con extrema rapidez. Por lo tanto, los bots deben ser tratados con el respeto que merecen, y deben estar fuertemente regulados , monitoreados y controlados si se les permite existir dentro de un ecosistema API.

Directrices para el diseño de bots

Estas son pautas muy generales para el uso de API por parte de los bots: sus necesidades y requisitos específicos pueden dictar excepciones y derechos especiales que no se tratan a continuación. Dicho esto, estas pautas son un sólido punto de partida.

Si bien algunas son recomendaciones de estilo, otras son requisitos para cualquier bot, que nacen de consideraciones de seguridad, experiencia del usuario y seguridad del sistema y, como tales, deberían ser requisitos de facto para cualquier sistema automatizado en una API.

1: Establezca claramente los casos de uso aceptados

Como se dijo anteriormente, un bot es extremadamente poderoso, pero ese poder no surge de forma natural, sino que se basa en un mandato que se transfiere del propietario del sistema al propietario del bot . Establecer lo que este mandato permite específicamente es una guía clave para el uso de bots.

Una de esas pautas consiste en limitar las altas tasas de uso . Posiblemente, esto podría implementarse utilizando un límite de frecuencia diaria , un límite de frecuencia de usuario específico y otros sistemas similares. Una forma de determinar este límite es considerar lo que podría realizar un usuario promedio, con suficiente tiempo y mano de obra.

Los bots también deben limitarse a las mismas habilidades que sus usuarios correspondientes . Al establecer lo que puede hacer un bot, estos privilegios deben estar limitados por los derechos de usuario que solicitan el bot. Los bots están destinados a la automatización, no a la elusión de clases.

Las pautas para los casos de uso de bot también deben restringir el punto de acceso . Un bot debe ceñirse al código base en todo momento. El uso de terminales o llamadas indocumentados crea importantes problemas de seguridad, y los bots pueden tomar lo que de otro modo podría ser una falla de seguridad única y propagarla en cientos o miles de llamadas en un minuto. Por lo tanto, a los bots solo se les debe permitir llevar a cabo acciones utilizando terminales , verborrea y comandos bien documentados y seguros .

Muy relacionado: una guía humana para redactar la política de la plataforma API

2: Permita una prueba de fallas

Según Isaac Asimov, hay tres reglas de la robótica. Uno de ellos dice simplemente que “ un robot debe obedecer las órdenes que le den los seres humanos […] ”. Este es un requisito tan válido de los bots en una API como lo es en la inteligencia artificial, y es un componente clave para proteger los bots que utilizan API.

Al diseñar un bot, se debe exigir e incluir un sistema de seguridad para permitir que el bot sea anulado y excluido del sistema en general. Si bien esto es ciertamente útil en los casos en que el bot está haciendo algo que no está permitido, también es muy útil para un bot deshonesto o un bot que recibe un comando mal formado y, como resultado, lleva a cabo funciones dañinas.

Un bot no es más que una herramienta , y con cualquier herramienta, debe haber un botón de encendido / apagado. Tenga en cuenta que esto tampoco tiene que ser obligatorio solo a través del bot en sí: puede identificar bots potenciales utilizando heurística y obligarlos a usar un servidor específico, filtrar el tráfico o incluso deshabilitar su funcionalidad por completo. Dicho esto, es mucho más fácil dictar que esta funcionalidad se incluya en lugar de llevarla a cabo de forma terciaria al bot.

Lea también: ¿Qué significa el auge de los bots para las API?

3: documenta el bot

Cada bot debe estar bien documentado y, lo que es más importante, bien declarado . Saber qué hay en una red conduce a una mayor seguridad y soluciones más fáciles cuando surgen problemas; por el contrario, no saber que un bot está en la red es una receta para el desastre. No documentar un bot causa grandes problemas de seguridad y puede resultar en un mayor tiempo para resolver problemas clave.

Este punto se puede resumir fácil y rápidamente así: no se haga pasar por un ser humano . Un bot es un bot y tiene instrucciones, restricciones y funciones específicas. Fingir ser humano o no anunciar el estado de un bot debería ser castigado con la exclusión del servicio y debería ser un requisito clave para permitir el tráfico en la red.

4: Cumplir con las reglas y regulaciones

Un bot es una herramienta; en consecuencia, como con cualquier herramienta, un bot es una extensión del usuario que lo ha creado. Por lo tanto, un bot está sujeto a las mismas reglas exactas que el usuario que lo crea. Todos los bots deben seguir estrictamente los términos de servicio y las pautas específicas establecidas por el propietario de la API, y deben cumplir con las reglas con las que el usuario que crea el bot ya trabaja, ya sean legales , de uso de datos o de privacidad .

Eludir estas reglas, que discutiremos más adelante, es un gran problema de seguridad: esto debe ser monitoreado, monitoreado y aplicado en gran medida.

5: Recuerde la experiencia del usuario

Este concepto es algo así como un "catch-all", pero es enormemente importante; un bot debería ofrecer una gran experiencia de usuario . Un bot no debe ser intrusivo y debe respetar la privacidad de todos los usuarios del sistema. Un bot debe tener informes de errores si interactúa con otros usuarios, así como una amplia documentación para mostrar lo que significan estos errores. Un bot debe declarar lo que es y ceñirse a las convenciones de declaración y entrega de información.

Un bot debe diseñarse esencialmente como si fuera su propia API, en gran parte porque, en muchos sentidos, es un vínculo entre el usuario y el sistema en el que se trabaja. Por lo tanto, la experiencia del usuario es una consideración muy importante.

Consulte también: Más de 12 marcos para crear bots de ChatOps

6: Cree un control y una segregación de identidad adecuados

Un bot no es un usuario. No importa cuánto se comporte el bot como un usuario, use las mismas herramientas que un usuario y participe en el mismo tipo de recursos que los usuarios, los bots son un tipo de rol único y diferente. En consecuencia, deben diferenciarse de la base de usuarios típica, tanto en capacidad como en función establecida.

Como parte de esto, el control de identidad puede ayudar a establecer dicha segregación entre "usuarios" y "bots". Si bien esto no significa necesariamente tener su propio sistema de autenticación único, deben estar demarcados como tales. Esto se puede lograr de varias maneras, desde requerir una nueva autenticación en intervalos regulares hasta delegar derechos del usuario a su bot. Independientemente de cómo se haga esto, el método de control de identidad empleado debe dar como resultado una clase definida como "usuarios" separada de una clase definida como "bots".

Obtenga más información sobre el control de identidad : cómo controlar la identidad del usuario dentro de microservicios

7: No eluda los límites de tarifas

Los límites de tarifas son como límites de velocidad: independientemente de si está de acuerdo con ellos o no, son ley y aparentemente existen para el mejoramiento de toda la red. En consecuencia, debería prohibirse y castigarse severamente eludir estos límites de tarifas. Eludir los límites rompe los términos de servicio y, objetivamente, empeora la experiencia de todos los demás en la red. Eludir los límites de velocidad también puede provocar spam , desbordamiento de la memoria y problemas de autenticación en los servidores que no abordan adecuadamente cargas de tráfico tan elevadas.

8: No utilice un bot para spam o abuso

Esto parece que no debería decirse, pero los bots nunca deberían usarse para spam o abuso . Un bot es poderoso y este poder, cuando se usa para siempre, puede hacer que la administración sea más fácil, rápida, eficiente y precisa. Sin embargo, cuando se usa mal, un bot puede causar dolores de cabeza y dolores importantes.

Un bot que se utiliza para enviar spam o abusos debe ser eliminado de forma inmediata y permanente. Es malo para la experiencia del usuario , malo para la marca de su API y malo para todos los involucrados.

Conclusión: sistemas automatizados seguros que utilizan su API

Los bots son excelentes herramientas, pero como ocurre con cualquier herramienta en las manos equivocadas, pueden convertirse rápidamente en un arma . Comprender los bots en su plataforma, lo que hacen, cómo hacen lo que hacen y por qué lo hacen, es un primer paso importante para asegurar los sistemas automatizados que utilizan su API.

Establecer las pautas adecuadas y hacerlas cumplir como un conjunto de reglas y regulaciones puede resultar en una red más fuerte, un sistema más seguro y una mejor experiencia de usuario en todos los aspectos. ¿Qué crees que depara el futuro de los bots para el espacio API? Háganos saber en la sección a continuación.

Publicar un comentario

0 Comentarios