Domande frequenti sulla sicurezza e la privacy di Bot Framework

Ogni bot è un servizio a sé e gli sviluppatori di questi servizi sono tenuti a fornire condizioni per l'utilizzo del servizio e informative sulla privacy in base al proprio codice di condotta. Per altre informazioni, vedere Indicazioni sulla verifica di bot.

Sì. Il bot può essere ospitato ovunque in Internet, Nei propri server, in Azure o in qualsiasi altro data center. L'unico requisito è che il bot deve esporre un endpoint HTTPS accessibile pubblicamente.

Gli utenti possono segnalare un bot che ha un comportamento errato tramite la scheda di contatto del bot nell'elenco. Per partecipare al servizio, gli sviluppatori devono rispettare le condizioni Microsoft per l'utilizzo del servizio.

Se si dispone di un firewall in uscita che blocca il traffico dal bot a Internet, sarà necessario consentire gli URL seguenti in tale firewall:

• login.botframework.com (Autenticazione del bot)
• login.microsoftonline.com (Autenticazione del bot)
• westus.api.cognitive.microsoft.com (per l'integrazione NLP di Luis.ai)
• *.botframework.com (canali)
• state.botframework.com (compatibilità con versioni precedenti)
• login.windows.net (account di accesso Windows)
• login.windows.com (account di accesso Windows)
• sts.windows.net (account di accesso Windows)
• Altri URL per canali di Bot Framework specifici

Bot Framework Services è ospitato in data center di Azure a livello mondiale e l'elenco di indirizzi IP di Azure cambia costantemente. Ciò significa che l'inserimento di determinati indirizzi IP nell'elenco può funzionare un giorno e interrompere l'operazione successiva quando cambiano gli indirizzi IP di Azure.

Per creare un bot nel portale di Azure è necessario l'accesso come collaboratore nella sottoscrizione o in un gruppo di risorse specifico. Un utente con il ruolo Collaboratore in un gruppo di risorse può creare un nuovo bot in quel gruppo di risorse specifico. Un utente con il ruolo Collaboratore per una sottoscrizione può creare un bot in un gruppo di risorse nuovo o esistente.

Usando l'interfaccia della riga di comando di Azure, un approccio basato sul controllo degli accessi in base al ruolo può supportare i ruoli personalizzati. Se si vuole creare un ruolo personalizzato con autorizzazioni più limitate, il set seguente consente all'utente di creare e distribuire un bot che supporta anche LUIS, QnA Maker e Application Insights.

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

1. Tutte le richieste di Bot Framework autentica sono accompagnate da un token JWT la cui firma crittografica può essere verificata seguendo la guida all'autenticazione. Il token è progettato in modo che gli utenti malintenzionati non possano rappresentare servizi attendibili.
2. Il token di sicurezza che accompagna ogni richiesta al bot ha la codifica ServiceUrl, il che significa che, anche se un utente malintenzionato ottiene l'accesso al token, non può reindirizzare la conversazione a un nuovo ServiceUrl. Questo comportamento viene applicato da tutte le implementazioni dell'SDK e documentato nel materiale di riferimento relativo all'autenticazione.
3. Se il token in ingresso è mancante o in formato non valido, Bot Framework SDK non genererà un token in risposta. In questo modo l'eventuale danno causato dall'errata configurazione del bot risulta limitato.
4. All'interno del bot è possibile verificare manualmente l'attestazione ServiceUrl fornita nel token. Questo rende il bot più fragile se la topologia del servizio cambia, quindi, anche se è possibile, non è consigliabile.

Nel controllo chat Web sono disponibili due meccanismi per garantire che l'utente appropriato sia connesso.

1. Codice magic. Al termine del processo di accesso, l'utente viene presentato con un codice a 6 cifre generato in modo casuale (codice magic). L'utente deve digitare questo codice nella conversazione per completare il processo di accesso. Ciò tende a produrre un'esperienza utente non valida. Inoltre, è ancora soggetto ad attacchi di phishing. Un utente malintenzionato può ingannare un altro utente per accedere e ottenere il codice fittizio tramite phishing.

   Avviso

   L'uso del codice magic è deprecato. È invece consigliabile usare l'autenticazione avanzata Direct Line, descritta di seguito.

2. Autenticazione avanzata direct Line. A causa dei problemi relativi all'approccio al codice magic, Azure AI servizio Bot ha rimosso la necessità. Azure AI servizio Bot garantisce che il processo di accesso possa essere completato solo nella stessa sessione del browser della chat Web stessa. Per abilitare questa protezione, è necessario avviare chat Web con un token Direct Line che contiene un elenco di origini attendibili, noto anche come domini attendibili, in grado di ospitare il client di chat Web del bot. Con le opzioni di autenticazione avanzate, è possibile specificare in modo statico l'elenco di origini attendibili nella pagina di configurazione di Direct Line. Per altre informazioni, vedere Autenticazione avanzata direct Line.

La gestione delle identità e degli accessi (IAM) è un framework (criteri e tecnologie) per consentire alle persone appropriate di avere l'accesso appropriato alle risorse tecnologico. Per altre informazioni, vedere Gestione delle identità.

Bot Framework offre i meccanismi di identificazione seguenti:

• Autenticazione bot. Determina se una richiesta proviene da un'origine legittima. È controllato dal servizio bot connector e consente la comunicazione sicura tra un bot e un canale. Per altre informazioni, vedere Autenticazione bot.

• Autenticazione utente. Consente al bot di accedere alle risorse online protette per conto dell'utente. L'OAuth standard di settore viene usato per autenticare l'utente e autorizzare il bot ad accedere alle risorse. Per altre informazioni, vedere Autenticazione utente.

In sintesi, Bot Framework gestisce l'autenticazione da servizio a servizio (autenticazione bot), essenzialmente convalidando che una richiesta proveniva effettivamente da un canale appropriato. Il bot è responsabile della gestione dei livelli di autenticazione inferiori. È possibile applicare un filtro in modo che il bot accetti solo le richieste da un ID tenant specifico oppure è possibile richiedere agli utenti di eseguire l'autenticazione con un servizio OAuth (autenticazione utente).

Sono disponibili due opzioni diverse per limitare i messaggi in ingresso elaborati dal bot.

• Se si gestiscono dati sicuri, è sicuramente consigliabile usare OAuth per autenticare gli utenti.

• L'uso del middleware è un'altra buona opzione. Nel canale di Teams, ad esempio, è possibile creare middleware per ottenere l'ID tenant dai dati del canale di Teams. Il middleware può quindi decidere se consentire all'attività in ingresso di continuare con la logica del bot o di restituire invece un messaggio di errore.

  Avviso

  Non è possibile impedire a Teams di inviare messaggi da diversi tenant, né impedire a un utente di installare il bot se ha il manifesto dell'app. Tutto ciò che è possibile fare è impedire al bot di elaborare i messaggi indesiderati.