Bot Framework preguntas más frecuentes sobre seguridad y privacidad

En este artículo se responden las preguntas más frecuentes sobre seguridad y privacidad.

se aplica a: SDK V4APPLIES TO: SDK v4

¿Los bots registrados con Bot Framework recopilan información personal? En caso afirmativo, ¿cómo puedo estar seguro de que los datos están a salvo y protegidos? ¿Qué pasa con la privacidad?

Cada bot es su propio servicio y los desarrolladores de esos servicios tienen que proporcionar los Términos del servicio y la Declaración de privacidad según su Código de conducta. Para más información, consulte Instrucciones de revisión de bots.

¿Puedo hospedar el bot en mis propios servidores?

Sí. El bot puede hospedarse en cualquier lugar de Internet. En sus propios servidores, en Azure o en cualquier otro centro de datos. El único requisito es que el bot debe exponer un punto de conexión HTTPS accesible públicamente.

¿Cómo prohibir o quitar bots del servicio?

Los usuarios tienen una manera de notificar un bot que presenta un comportamiento incorrecto mediante la tarjeta de contacto del bot en el directorio. Los desarrolladores deben atenerse a los términos del servicio de Microsoft para participar en el servicio.

¿Qué direcciones URL específicas necesito para permitir la lista en el firewall corporativo para acceder a Bot Framework servicios?

Si tiene un firewall de salida que bloquea el tráfico desde el bot a Internet, deberá permitir enumerar las direcciones URL siguientes en ese firewall:

  • login.botframework.com (Autenticación del bot)
  • login.microsoftonline.com (Autenticación del bot)
  • westus.api.cognitive.microsoft.com (para la integración de NLP de Luis.ai)
  • *.botframework.com (canales)
  • state.botframework.com (compatibilidad con versiones anteriores)
  • login.windows.net (inicio de sesión de Windows)
  • login.windows.com (inicio de sesión de Windows)
  • sts.windows.net (inicio de sesión de Windows)
  • Direcciones URL adicionales para canales específicos de Bot Framework

Nota

Puede usar si prefiere no permitir la enumeración de una <channel>.botframework.com dirección URL con un asterisco. <channel> es igual en todos los canales que usa el bot, como directline.botframework.com, webchat.botframework.com y slack.botframework.com. También merece la pena observar el tráfico del firewall mientras prueba el bot para asegurarse de que no se está bloqueando nada más.

¿Puedo bloquear todo el tráfico al bot excepto el tráfico procedente de Bot Framework Service?

Bot Framework Services se hospedan en centros de datos de Azure de todo el mundo y la lista de direcciones IP de Azure cambia constantemente. Esto significa que permitir la enumeración de determinadas direcciones IP puede funcionar un día y interrumpir el siguiente a medida que cambian las direcciones IP de Azure.

¿Qué rol de RBAC es necesario para crear e implementar un bot?

La creación de un bot en Azure Portal requiere el acceso de colaborador en la suscripción o en un grupo de recursos específico. Un usuario con el rol de Colaborador en un grupo de recursos puede crear un nuevo bot en ese grupo de recursos específico. Un usuario del rol Colaborador en una suscripción puede crear un bot en un grupo de recursos nuevo o existente.

Con la CLI de Azure, un enfoque de control de acceso basado en roles puede admitir roles personalizados. Si desea crear un rol personalizado con permisos más restringidos, el conjunto siguiente permite al usuario crear e implementar un bot que también admite LUIS, QnA Maker y Application Insights.

"Microsoft.Web/ ", "Microsoft.BotService/ ", "Microsoft.Storage/ ", "Microsoft.Resources/deployments/ ", "Microsoft.CognitiveServices/ ", "Microsoft.Search/searchServices/ ", "Microsoft.Insights/ ", "Microsoft.Insights/components/ "

Nota

LUIS y QnA Maker requieren permisos de Cognitive Services. QnA Maker también requiere permisos de búsqueda. Al crear un rol personalizado, recuerde que los permisos de denegación heredados reemplazarán a estos permisos de permiso.

¿Qué protege al bot de los clientes que suplanten Bot Framework Service?

  1. Todas las solicitudes Bot Framework autenticación van acompañadas de un token JWT cuya firma criptográfica se puede comprobar siguiendo la guía de autenticación. El token está diseñado para que los atacantes no puedan suplantar los servicios de confianza.
  2. El token de seguridad que acompaña a cada solicitud para el bot incluye la dirección URL de servicio codificada, lo que significa que aunque un atacante obtenga acceso al token, no podrá redirigir la conversación a una nueva dirección URL de servicio. Esto se aplica en todas las implementaciones del SDK y está documentado en los materiales de referencia de autenticación.
  3. Si el token entrante es incorrecto o falta, el SDK de Bot Framework no generará un token en la respuesta. Esto limita los posibles daños si el bot se configura incorrectamente.
  4. En el bot, puede comprobar manualmente la dirección URL de servicio proporcionada en el token. Esto hace que el bot sea más frágil en caso de cambios en la topología del servicio por lo que, aunque es posible, no se recomienda.

Nota

Se trata de conexiones salientes desde el bot a Internet. No hay una lista de los nombres DNS o las direcciones IP que el servicio Bot Framework Connector utiliza para comunicarse con el bot. No se admite la lista de permitidos de direcciones IP de entrada.

¿Cuál es el propósito del código mágico durante la autenticación?

En el Chat en web, hay dos mecanismos para garantizar que el usuario adecuado ha iniciado sesión.

  1. Código mágico. Al final del proceso de inicio de sesión, se presenta al usuario un código de 6 dígitos generado aleatoriamente (código mágico). El usuario debe escribir este código en la conversación para completar el proceso de inicio de sesión. Esto tiende a dar lugar a una mala experiencia del usuario. Además, aún así se corría el riesgo de sufrir ataques de suplantación de identidad (phishing). Un usuario malintencionado puede engañar a otro usuario para que inicie sesión y obtenga el código mágico mediante la suplantación de identidad (phishing).

    Advertencia

    El uso del código mágico está en desuso. En su lugar, debe usar Direct Line autenticación mejorada, que se describe a continuación.

  2. Direct Line autenticación mejorada. Debido a los problemas con el enfoque de código mágico, Azure Bot Service su necesidad. Azure Bot Service garantiza que el proceso de inicio de sesión solo se puede completar en la misma sesión del explorador que el propio Web Chat. Para habilitar esta protección, debe iniciar Chat en web con un token de Direct Line que contenga una lista de orígenes de confianza , también conocidos como dominios de confianza, que pueden hospedar el cliente de Chat en web del bot. Con las opciones de autenticación mejoradas, puede especificar estáticamente la lista de orígenes de confianza en la Direct Line configuración. Para obtener más información, vea Direct Line autenticación mejorada.

¿Cómo controla el Bot Framework administración de identidades y acceso?

La administración de identidades y acceso (IAM) es un marco (directivas y tecnologías) que permite a las personas adecuadas tener acceso adecuado a los recursos tecnológicos. Para obtener más información, vea Administración de identidades.

El Bot Framework proporciona los siguientes mecanismos de identificación:

  • Autenticación de bot. Determina si una solicitud provenía de un origen legítimo. Se controla mediante el servicio bot connector y permite una comunicación segura entre un bot y un canal. Para más información, consulte Autenticación de bot.

  • Autenticación de usuario. Permite que el bot acceda a recursos en línea protegidos en nombre del usuario. OAuth estándar del sector se usa para autenticar al usuario y autorizar al bot a acceder a los recursos. Para obtener más información, vea Autenticación de usuario.

En resumen, el Bot Framework controla la autenticación de servicio a servicio (autenticación de bot), lo que básicamente valida que una solicitud realmente procede de un canal adecuado. El bot es responsable de controlar los niveles inferiores de autenticación. Puede aplicar un filtro para que el bot solo acepte solicitudes de un identificador de inquilino determinado, o bien puede requerir que los usuarios se autentiquen con algún servicio de OAuth (autenticación de usuario).

Cómo restringir el uso de mi bot solo a los usuarios que pertenecen a mi inquilino?

Tiene dos opciones diferentes para restringir los mensajes entrantes que procesa el bot.

  • Si trabaja con datos seguros, se recomienda usar OAuth para autenticar a los usuarios.

  • El uso de middleware es otra buena opción. Por ejemplo, en el caso del canal de Teams, agregue la clase al bot y TeamsTenantFilteringMiddleware conéctela en el método de inicio. Vea estos ejemplos: versión de C#, versión de JavaScript.

    Advertencia

    No puede impedir que Teams le envíe mensajes desde varios inquilinos, ni puede impedir que alguien instale el bot si tiene el manifiesto de aplicación. Todo lo que puede hacer es evitar que el bot procese los mensajes no deseados.