Preguntas más frecuentes sobre privacidad y seguridad de Bot Framework

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.

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.

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.

Si tiene un servidor de seguridad de salida que bloquea el tráfico procedente del bot hacia Internet, necesitará incluir en la lista de direcciones permitidas de dicho servidor de seguridad las direcciones URL siguientes:

• 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

Las instancias de Bot Framework Services se hospedan en centros de datos de Azure en todo el mundo y la lista de direcciones IP de Azure cambia constantemente. Esto significa que la creación de listas de direcciones permitidas con direcciones IP determinadas puede funcionar un día y al siguiente no, cuando cambien las direcciones IP de Azure.

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 permitirá al usuario crear e implementar un bot que también admita 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/*"

1. Todas las solicitudes de Bot Framework auténticas van acompañadas de un token JWT cuya firma criptográfica se puede comprobar como se indica en la guía de autenticación siguiente. 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.

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

1. Código mágico. Al final del 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. Este mecanismo solía producir 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 la autenticación mejorada de Direct Line, que se describe a continuación.

2. Autenticación mejorada de Direct Line. Debido a los problemas con el enfoque de código mágico, el Servicio de Bot de Azure AI eliminó su necesidad. El Servicio de Bot de Azure AI 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 contiene 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 página de configuración de Direct Line. Para obtener más información, consulte Autenticación mejorada de Direct Line.

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

Bot Framework proporciona los siguientes mecanismos de identificación:

• Autenticación del bot. Determina si una solicitud procede de un origen legítimo. Se controla mediante el servicio de 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 al bot acceder 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 más información, consulte Autenticación de usuario.

En resumen, Bot Framework controla la autenticación entre servicios (autenticación de bot), lo que básicamente valida que una solicitud provenía 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 puede requerir que los usuarios se autentiquen con algún servicio de OAuth (autenticación de usuario).

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

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

• Otra buena opción es utilizar middleware. En el canal de Teams, por ejemplo, puede crear middleware para obtener el id. de inquilino de los datos del canal de Teams. Después, el middleware puede decidir si se permite que la actividad entrante continúe con la lógica del bot o, en su lugar, devuelva un mensaje de error.

  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 la aplicación. Todo lo que puede hacer es evitar que el bot procese los mensajes no deseados.