Vanliga frågor och svar om Säkerhet och sekretess för Bot Framework

Varje robot är en egen tjänst och utvecklare av dessa tjänster måste tillhandahålla användningsvillkor och sekretesspolicyer enligt deras organisations uppförandekod för utvecklare. Mer information finns i riktlinjer för robotgranskning.

Ja. Roboten kan finnas var som helst på Internet. På dina egna servrar, i Azure eller i något annat datacenter. Det enda kravet är att roboten måste exponera en offentligt tillgänglig HTTPS-slutpunkt.

Användare kan rapportera en felaktig robot via robotens kontaktkort i katalogen. Utvecklare måste följa Microsofts tjänstvillkor för att delta i tjänsten.

Om du har en utgående brandvägg som blockerar trafik från din robot till Internet måste du tillåtalistning av följande URL:er i brandväggen:

• login.botframework.com (Robotautentisering)
• login.microsoftonline.com (Robotautentisering)
• westus.api.cognitive.microsoft.com (för Luis.ai NLP-integrering)
• *.botframework.com (kanaler)
• state.botframework.com (bakåtkompatibilitet)
• login.windows.net (Windows-inloggning)
• login.windows.com (Windows-inloggning)
• sts.windows.net (Windows-inloggning)
• Andra URL:er för specifika Bot Framework-kanaler

Bot Framework Services finns i Azure-datacenter över hela världen och listan över Azure-IP-adresser ändras ständigt. Det innebär att tillåt-listning av vissa IP-adresser kan fungera en dag och bryta nästa när Azures IP-adresser ändras.

För att skapa en robot på Azure-portalen krävs deltagaråtkomst antingen i prenumerationen eller i en specifik resursgrupp. En användare med rollen Deltagare i en resursgrupp kan skapa en ny robot i den specifika resursgruppen. En användare i deltagarrollen för en prenumeration kan skapa en robot i en ny eller befintlig resursgrupp.

Med hjälp av Azure CLI kan en rollbaserad åtkomstkontrollsmetod stödja anpassade roller. Om du vill skapa en anpassad roll med mer begränsade behörigheter gör uppsättningen nedan att användaren kan skapa och distribuera en robot som också stöder LUIS, QnA Maker och Application Insights.

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

1. Alla autentiska Bot Framework-begäranden åtföljs av en JWT-token vars kryptografiska signatur kan verifieras genom att följa autentiseringsguiden. Token är utformad så att angripare inte kan personifiera betrodda tjänster.
2. Säkerhetstoken som medföljer varje begäran till din robot har ServiceUrl-kodad i den, vilket innebär att även om en angripare får åtkomst till token kan de inte omdirigera konversationen till en ny ServiceUrl. Detta framtvingas av alla implementeringar av SDK:et och dokumenteras i vårt referensmaterial för autentisering.
3. Om den inkommande token saknas eller är felaktigt formaterad genererar Bot Framework SDK inte någon token som svar. Detta begränsar hur mycket skada som kan göras om roboten är felaktigt konfigurerad.
4. I roboten kan du manuellt kontrollera ServiceUrl som anges i token. Detta gör roboten mer bräcklig om tjänsttopologin ändras, så även om detta är möjligt rekommenderas det inte.

I den Webbchatt kontrollen finns det två mekanismer för att säkerställa att rätt användare är inloggad.

1. Magisk kod. I slutet av inloggningsprocessen visas användaren med en slumpmässigt genererad 6-siffrig kod (magisk kod). Användaren måste skriva den här koden i konversationen för att slutföra inloggningsprocessen. Detta tenderar att resultera i en felaktig användarupplevelse. Dessutom är den fortfarande känslig för nätfiskeattacker. En obehörig användare kan lura en annan användare att logga in och hämta den magiska koden via nätfiske.

   Varning

   Användningen av den magiska koden är inaktuell. I stället bör du använda förbättrad direktradsautentisering, som beskrivs nedan.

2. Förbättrad direktlinjeautentisering. På grund av problemen med den magiska kodmetoden har Azure AI Bot Service tagit bort sitt behov. Azure AI Bot Service garanterar att inloggningsprocessen endast kan slutföras i samma webbläsarsession som själva Webbchatt. Om du vill aktivera det här skyddet måste du börja Webbchatt med en direktradstoken som innehåller en lista över betrodda ursprung, även kända som betrodda domäner, som kan vara värd för robotens Webbchatt-klient. Med förbättrade autentiseringsalternativ kan du statiskt ange listan över betrodda ursprung på direktradskonfigurationssidan. Mer information finns i Utökad direktlinjeautentisering.

Identitets- och åtkomsthantering (IAM) är ett ramverk (principer och tekniker) som ger rätt personer lämplig åtkomst till teknikresurser. Mer information finns i Identitetshantering.

Bot Framework tillhandahåller följande identifieringsmekanismer:

• Robotautentisering. Avgör om en begäran kom från en legitim källa. Den styrs av robotanslutningstjänsten och möjliggör säker kommunikation mellan en robot och en kanal. Mer information finns i Robotautentisering.

• Användarautentisering. Det gör det möjligt för roboten att komma åt skyddade onlineresurser för användarens räkning. Branschstandarden OAuth används för att autentisera användaren och ge roboten åtkomst till resurserna. Mer information finns i Användarautentisering.

Sammanfattningsvis hanterar Bot Framework tjänst-till-tjänst-autentisering (robotautentisering), vilket i huvudsak verifierar att en begäran verkligen kom från en korrekt kanal. Roboten ansvarar för att hantera lägre autentiseringsnivåer. Du kan använda ett filter så att roboten endast accepterar begäranden från ett visst klient-ID, eller så kan du kräva att användarna autentiserar med någon OAuth-tjänst (användarautentisering).

Du har två olika alternativ för att begränsa inkommande meddelanden som roboten bearbetar.

• Om du hanterar säkra data rekommenderar vi definitivt att du använder OAuth för att autentisera användarna.

• Att använda mellanprogram är ett annat bra alternativ. I Teams-kanalen kan du till exempel skapa mellanprogram för att hämta klientorganisations-ID:t från Teams-kanaldata. Mellanprogrammet kan sedan bestämma om den inkommande aktiviteten ska fortsätta till robotlogik eller i stället returnera ett felmeddelande.

  Varning

  Du kan inte hindra Teams från att skicka meddelanden från olika klienter och du kan inte heller hindra någon från att installera din robot om de har ditt appmanifest. Allt du kan göra är att förhindra att roboten bearbetar oönskade meddelanden.