Pomoc w zabezpieczaniu bota kanału usługi Microsoft Teams i aplikacji internetowej za zaporą

Azure App Service
Azure Web Application Firewall

Ten przykładowy scenariusz pomaga zabezpieczyć połączenie z aplikacją internetową bota kanału usługi Microsoft Teams przy użyciu usługi Azure Private Link i prywatnego punktu końcowego platformy Azure. Jednocześnie umożliwia kanałom w kliencie usługi Teams komunikowanie się z botem za pośrednictwem adresu IP uwidocznionego za pośrednictwem wystąpienia usługi Azure Firewall.

Architektura

Diagram przedstawiający schemat blokowy usługi Teams-to-Azure Firewall.

Pobierz plik programu Visio z tą architekturą.

Przepływ danych

  • Usługa Azure Virtual Network umożliwia komunikację między zasobami platformy Azure. Sieć wirtualna w tym przykładzie używa przestrzeni adresowej 10.0.0.0/16 i zawiera trzy podsieci do użycia przez wymagane składniki scenariusza:

    • Podsieć usługi Azure Firewall (10.0.1.0/26).

    • Podsieć integracji sieci wirtualnej (10.0.2.0/24), która służy do kierowania ruchu z prywatnego punktu końcowego bota do zapory.

    • Podsieć prywatnego punktu końcowego (10.0.3.0/24), która służy do kierowania ruchu z zapory do prywatnego punktu końcowego bota.

  • Usługa Azure Firewall uwidacznia pojedynczy publiczny adres IP, którego klienci mogą używać do komunikowania się z podstawowymi usługami bota. Zazwyczaj zapora jest umieszczana we własnej sieci wirtualnej, która jest typowym wzorcem architektur piasty i szprych , ale ten uproszczony przykład wdraża wszystkie usługi i zasoby w jednej sieci wirtualnej. Wystąpienie usługi Azure Firewall jest umieszczane we własnej podsieci.

  • Tabela tras definiuje trasy, które są kierowane do sieci wirtualnej. Gwarantuje to, że ruch przychodzący do i z bota przechodzi przez zaporę.

    • Trasa domyślna z prefiksem adresu 0.0.0.0/0 nakazuje platformie Azure kierowanie ruchu, który nie znajduje się w prefiksie adresu żadnej innej trasy do podsieci, w której wdrożono wystąpienie usługi Azure Firewall. W tym przykładzie jest to jedyna trasa.

    • Podsieć integracji sieci wirtualnej i podsieć prywatnego punktu końcowego są skojarzone z tabelą tras, zapewniając, że ruch przechodzący przez nie jest kierowany przez zaporę.

  • Usługa Bot Service składa się z planu usługi app service bota, usługi app service i rejestracji kanałów bota.

    • Usługa App Service ma zarejestrowaną domenę niestandardową wskazującą adres IP zapory. W ten sposób dostęp do usługi App Service można uzyskać tylko za pośrednictwem zapory.
  • Usługa Azure Private Link na potrzeby dostępu przychodzącego do usługi aplikacji bota za pośrednictwem prywatnego punktu końcowego platformy Azure.

  • Integracja sieci wirtualnej łączy usługę app service z siecią wirtualną, zapewniając, że ruch wychodzący z usługi aplikacji bota przechodzi przez zaporę.

Składniki

Alternatywy

  • Środowisko App Service Environment może zapewnić w pełni izolowane i dedykowane środowisko do bezpiecznego uruchamiania aplikacji usługi App Service na dużą skalę. W tym przykładzie nie jest używane środowisko App Service Environment w celu zmniejszenia kosztów, ale przykładowa architektura może ją obsługiwać z modyfikacjami.

Szczegóły scenariusza

Boty umożliwiają użytkownikom usługi Teams interakcję z usługami internetowymi za pośrednictwem tekstu, kart interaktywnych i modułów zadań. Platforma Microsoft Bot Framework i usługi Azure Bot Services udostępniają łatwy w użyciu zestaw narzędzi do tworzenia tych botów i zarządzania nimi.

Boty można opracowywać przy użyciu różnych języków, takich jak C#, JavaScript i Python. Po ich opracowaniu możesz wdrożyć je na platformie Azure. Kluczowym składnikiem bota jest aplikacja internetowa zawierająca podstawową logikę i interfejs, z którym użytkownicy komunikują się. Jednym z kluczowych wymagań bota do pracy jest to, że musi uwidocznić publicznie dostępny punkt końcowy HTTPS.

Zasady protokołu InfoSec często wymagają, aby cały ruch przychodzący do aplikacji internetowych przechodził przez zaporę firmową. Oznacza to, że cały ruch, który przechodzi do bota, i odpowiedzi z bota, musi kierować przez zaporę firmową, tak jak w przypadku każdej innej aplikacji internetowej.

Potencjalne przypadki użycia

Organizacje mogą korzystać z botów dla użytkowników mobilnych i stacjonarnych. Przykłady obejmują:

  • Proste zapytania. Boty mogą dostarczać dokładne dopasowanie do zapytania lub grupy powiązanych dopasowań, aby ułatwić uściślanie.
  • Interakcje obejmujące wiele obrotu. Ułatwiając przewidywanie możliwych następnych kroków, boty znacznie ułatwiają użytkownikom ukończenie przepływu zadań.
  • Dotarcie do użytkowników. Boty mogą wysyłać komunikat, gdy coś się zmieniło w dokumencie lub element roboczy jest zamknięty.

Kwestie wymagające rozważenia

Monitorowanie

Chociaż monitorowanie nie jest implementowane w tym przykładowym scenariuszu, usługa app service bota może używać usług Azure Monitor do monitorowania jego dostępności i wydajności.

Skalowalność

Boty używane w tym scenariuszu są hostowane w usłudze aplikacja systemu Azure Service. W związku z tym możesz użyć standardowych funkcji automatycznego skalowania usługi App Service, aby automatycznie skalować liczbę wystąpień uruchamiających bota, co pozwala botowi na nadążyć za zapotrzebowaniem. Aby uzyskać więcej informacji na temat skalowania automatycznego, zobacz Najlepsze rozwiązania dotyczące skalowania automatycznego.

Aby zapoznać się z innymi tematami dotyczącymi skalowalności, zobacz listę kontrolną wydajności centrum architektury platformy Azure.

DevOps

Typowym rozwiązaniem jest wdrażanie aplikacji internetowych, aplikacji interfejsu API i aplikacji mobilnych w planie usługi aplikacja systemu Azure Service przy użyciu potoków ciągłego wdrażania. Ponieważ usługa aplikacji zabezpieczonego bota jest chroniona za pomocą prywatnego punktu końcowego, zewnętrznie hostowani agenci kompilacji nie mają dostępu wymaganego do wdrożenia aktualizacji. Aby obejść ten problem, może być konieczne użycie rozwiązania, takiego jak samodzielnie hostowani agenci devOps usługi Azure Pipeline.

Zabezpieczenia

Usługa Azure DDoS Protection w połączeniu z najlepszymi rozwiązaniami dotyczącymi projektowania aplikacji zapewnia ulepszone funkcje ograniczania ryzyka ataków DDoS w celu zapewnienia większej ochrony przed atakami DDoS. Należy włączyć usługę Azure DDOS Protection w dowolnej sieci wirtualnej obwodowej.

Wdrażanie tego scenariusza

Wymagania wstępne

Musisz mieć istniejące konto platformy Azure. Jeśli nie masz subskrypcji platformy Azure, przed rozpoczęciem utwórz bezpłatne konto.

Przewodnik

  1. Uruchom następujące polecenia interfejsu wiersza polecenia platformy Azure w usłudze Azure Cloud Shell lub preferowaną powłokę wdrażania.

    Ten zestaw poleceń tworzy niezbędną grupę zasobów, sieć wirtualną i podsieci wymagane w tym przewodniku. Zakres adresów IP używany przez usługę Teams to 52.112.0.0/14,52.122.0.0/15.

    # Declare variables (bash syntax)
    export PREFIX='SecureBot'
    export RG_NAME='rg-'${PREFIX}
    export VNET_NAME='vnet-'${PREFIX}
    export SUBNET_INT_NAME='VnetIntegrationSubnet'
    export SUBNET_PVT_NAME='PrivateEndpointSubnet'
    export LOCATION='eastus'
    export TEAMS_IP_RANGE='52.112.0.0/14 52.122.0.0/15'
    export FIREWALL_NAME='afw-'${LOCATION}'-'${PREFIX}
    
    # Create a resource group
    az group create --name ${RG_NAME} --location ${LOCATION}
    
    # Create a virtual network with a subnet for the firewall
    az network vnet create \
    --name ${VNET_NAME} \
    --resource-group ${RG_NAME} \
    --location ${LOCATION} \
    --address-prefix 10.0.0.0/16 \
    --subnet-name AzureFirewallSubnet \
    --subnet-prefix 10.0.1.0/26
    
    # Add a subnet for the Virtual network integration
    az network vnet subnet create \
    --name ${SUBNET_INT_NAME} \
    --resource-group ${RG_NAME} \
    --vnet-name ${VNET_NAME} \
    --address-prefix 10.0.2.0/24
    
    # Add a subnet where the private endpoint will be deployed for the app service
    az network vnet subnet create \
    --name ${SUBNET_PVT_NAME} \
    --resource-group ${RG_NAME} \
    --vnet-name ${VNET_NAME} \
    --address-prefix 10.0.3.0/24
    

    Podczas tworzenia podsieci prywatnego punktu końcowego zasady prywatnego punktu końcowego są domyślnie wyłączone.

    Po zakończeniu wdrażania powinny zostać wyświetlone następujące podsieci w sieci wirtualnej:

    Zrzut ekranu przedstawiający okienko

  2. Wdróż wystąpienie usługi Azure Firewall w podsieci zapory utworzonej w kroku 1, uruchamiając następujące polecenia interfejsu wiersza polecenia:

    # Create a firewall
    az network firewall create \
        --name ${FIREWALL_NAME} \
        --resource-group ${RG_NAME} \
        --location ${LOCATION}
    
    # Create a public IP for the firewall
    az network public-ip create \
        --name ${FIREWALL_NAME}-pip \
        --resource-group ${RG_NAME} \
        --location ${LOCATION} \
        --allocation-method static \
        --sku standard
    
    # Associate the IP with the firewall
    az network firewall ip-config create \
        --firewall-name ${FIREWALL_NAME} \
        --name ${FIREWALL_NAME}-Config \
        --public-ip-address ${FIREWALL_NAME}-pip \
        --resource-group ${RG_NAME} \
        --vnet-name ${VNET_NAME}
    
    # Update the firewall
    az network firewall update \
        --name ${FIREWALL_NAME} \
        --resource-group ${RG_NAME}
    
    # Get the public IP address for the firewall and take note of it for later use
    az network public-ip show \
        --name ${FIREWALL_NAME}-pip \
        --resource-group ${RG_NAME}
    

    Konfiguracja zapory powinna wyglądać mniej więcej tak:

    Zrzut ekranu przedstawiający konfigurację zapory fw-SecureBot.

  3. Utwórz podstawowego bota.

  4. Wdróż podstawowego bota w grupie zasobów utworzonej w kroku 1.

    W ramach tego procesu utworzysz rejestrację aplikacji, która będzie potrzebna do interakcji z botem za pośrednictwem kanałów. Podczas tego procesu wdrożysz również niezbędny plan usługi App Service, usługę App Service i bota aplikacji internetowej.

    Uwaga

    Wybierz plan usługi App Service, który obsługuje usługę Azure Private Link.

  5. Zamapuj domenę niestandardową na usługę aplikacji wdrożona w grupie zasobów w kroku 3.

    Ten krok wymaga dostępu do rejestratora domen i wymaga dodania rekordu A do domeny niestandardowej, która wskazuje publiczny adres IP zapory utworzonej w kroku 2.

  6. Zabezpiecz zamapowany domenę niestandardową, przekazując istniejący certyfikat dla domeny lub kupując certyfikat usługi App Service na platformie Azure i importując go. Możesz to zrobić, wykonując kroki opisane w temacie Zabezpieczanie niestandardowej nazwy DNS z powiązaniem TLS/SSL w usłudze aplikacja systemu Azure Service.

    Teraz powinien istnieć w pełni funkcjonalny bot, który można dodać do kanału w usłudze Teams lub przetestować za pomocą czat internetowy, korzystając z wskazówek znalezionych w dokumentacji zestawu Bot Framework SDK.

    Uwaga

    W tym momencie usługa aplikacji bota jest nadal publicznie dostępna za pośrednictwem adresu azurewebsites.net URL i za pośrednictwem skonfigurowanego niestandardowego adresu URL. W następnych krokach użyjesz prywatnych punktów końcowych, aby wyłączyć dostęp publiczny. Skonfigurujesz również zaporę, aby umożliwić usłudze bota komunikację tylko z klientami usługi Teams.

  7. Uruchom następujący skrypt interfejsu wiersza polecenia platformy Azure, aby wdrożyć i skonfigurować prywatny punkt końcowy. Ten krok implementuje również integrację sieci wirtualnej dla usługi app service bota, która łączy ją z podsiecią integracji sieci wirtualnej.

    # Disable private endpoint network policies (this step is not required if you're using the Azure portal)
    az network vnet subnet update \
      --name ${SUBNET_PVT_NAME} \
      --resource-group ${RG_NAME} \
      --vnet-name ${VNET_NAME} \
      --disable-private-endpoint-network-policies true
    
    # Create the private endpoint, being sure to copy the correct resource ID from your deployment of the bot app service
    # The ID can be viewed by using the following CLI command:
    # az resource show --name wapp-securebot --resource-group rg-securebot --resource-type Microsoft.web/sites --query "id" 
    az network private-endpoint create \
      --name pvt-${PREFIX}Endpoint \
      --resource-group ${RG_NAME} \
      --location ${LOCATION} \
      --vnet-name ${VNET_NAME} \
      --subnet ${SUBNET_PVT_NAME} \
      --connection-name conn-${PREFIX} \
      --private-connection-resource-id /subscriptions/cad87d9e-c941-4519-a638-c9804a0577b9/resourceGroups/rg-securebot/providers/Microsoft.Web/sites/wapp-securebot \
      --group-id sites
    
    # Create a private DNS zone to resolve the name of the app service
    az network private-dns zone create \
      --name ${PREFIX}privatelink.azurewebsites.net \
      --resource-group ${RG_NAME}
    
    az network private-dns link vnet create \
      --name ${PREFIX}-DNSLink \
      --resource-group ${RG_NAME} \
      --registration-enabled false \
      --virtual-network ${VNET_NAME} \
      --zone-name ${PREFIX}privatelink.azurewebsites.net
    
    az network private-endpoint dns-zone-group create \
      --name chatBotZoneGroup \
      --resource-group ${RG_NAME} \
      --endpoint-name pvt-${PREFIX}Endpoint \
      --private-dns-zone ${PREFIX}privatelink.azurewebsites.net \
      --zone-name ${PREFIX}privatelink.azurewebsites.net
    
    # Establish virtual network integration for outbound traffic
    az webapp vnet-integration add \
      -g ${RG_NAME} \
      -n wapp-${PREFIX} \
      --vnet ${VNET_NAME} \
      --subnet ${SUBNET_INT_NAME}
    

    Po uruchomieniu tych poleceń w grupie zasobów powinny zostać wyświetlone następujące zasoby:

    Zrzut ekranu przedstawiający listę zasobów w grupie zasobów.

    Opcja Integracja z siecią wirtualną w sekcji Sieć usługi aplikacji powinna wyglądać następująco:

    Zrzut ekranu przedstawiający opcje

    Zrzut ekranu przedstawiający opcję

    Zrzut ekranu przedstawiający okienko

  8. Następnie utworzysz tabelę tras, aby upewnić się, że ruch do i z każdej podsieci przechodzi przez zaporę. Będziesz potrzebować prywatnego adresu IP zapory utworzonej w poprzednim kroku.

    # Create a route table
    az network route-table create \
      -g ${RG_NAME} \
      -n rt-${PREFIX}RouteTable
    
    # Create a default route with 0.0.0.0/0 prefix and the next hop as the Azure firewall virtual appliance to inspect all traffic. Make sure you use your firewall's internal IP address instead of 10.0.1.4
    az network route-table route create -g ${RG_NAME} \
      --route-table-name rt-${PREFIX}RouteTable -n default \
      --next-hop-type VirtualAppliance \
      --address-prefix 0.0.0.0/0 \
      --next-hop-ip-address 10.0.1.4
    
    # Associate the two subnets with the route table
    az network vnet subnet update -g ${RG_NAME} \
      -n ${SUBNET_INT_NAME} --vnet-name ${VNET_NAME} \
      --route-table rt-${PREFIX}RouteTable
    
    az network vnet subnet update -g ${RG_NAME} \
      -n ${SUBNET_PVT_NAME} \
      --vnet-name ${VNET_NAME} \
      --route-table rt-${PREFIX}RouteTable
    

    Po uruchomieniu poleceń zasób tabeli tras powinien wyglądać następująco:

    Zrzut ekranu przedstawiający okienko rt-SecureBotRouteTable.

    Po utworzeniu tabeli tras dodajesz reguły do zapory, aby dostarczać ruch z publicznego adresu IP do usługi aplikacji bota i ograniczać ruch z dowolnego punktu końcowego innego niż usługa Microsoft Teams. Ponadto zezwolisz na ruch między siecią wirtualną a usługami Azure Bot Services lub Microsoft Entra ID przy użyciu tagów usługi.

  9. Uruchom następujące polecenia:

    # Create a NAT rule collection and a single rule. The source address is the public IP range of Microsoft Teams
    # Destination address is that of the firewall. 
    # The translated address is that of the app service's private link.
    az network firewall nat-rule create \
      --resource-group ${RG_NAME} \
      --collection-name coll-${PREFIX}-nat-rules \
      --priority 200 \
      --action DNAT \
      --source-addresses ${TEAMS_IP_RANGE} \
      --dest-addr 23.100.26.84 \
      --destination-ports 443 \
      --firewall-name ${FIREWALL_NAME} \
      --name rl-ip2appservice \
      --protocols TCP \
      --translated-address 10.0.3.4 \
      --translated-port 443
    
    # Create a network rule collection and add three rules to it. 
    # The first one is an outbound network rule to only allow traffic to the Teams IP range.
    # The source address is that of the virtual network address space, destination is the Teams IP range.
    az network firewall network-rule create \
      --resource-group ${RG_NAME} \
      --collection-name coll-${PREFIX}-network-rules \
      --priority 200 \
      --action Allow \
      --source-addresses 10.0.0.0/16 \
      --dest-addr ${TEAMS_IP_RANGE} \
      --destination-ports 443 \
      --firewall-name ${FIREWALL_NAME} \
      --name rl-OutboundTeamsTraffic \
      --protocols TCP
    
    # This rule will enable traffic to all IP addresses associated with Azure AD service tag
    az network firewall network-rule create \
      --resource-group ${RG_NAME} \
      --collection-name coll-${PREFIX}-network-rules \
      --source-addresses 10.0.0.0/16 \
      --dest-addr AzureActiveDirectory \
      --destination-ports '*' \
      --firewall-name ${FIREWALL_NAME} \
      --name rl-AzureAD \
      --protocols TCP
    
    # This rule will enable traffic to all IP addresses associated with Azure Bot Services service tag
    az network firewall network-rule create \
      --resource-group ${RG_NAME} \
      --collection-name coll-${PREFIX}-network-rules \
      --source-addresses 10.0.0.0/16 \
      --dest-addr AzureBotService \
      --destination-ports '*' \
      --firewall-name ${FIREWALL_NAME} \
      --name rl-AzureBotService \
      --protocols TCP
    

    Po uruchomieniu poleceń reguły zapory będą wyglądać mniej więcej tak:

    Zrzut ekranu przedstawiający okienko

    Zrzut ekranu przedstawiający okienko

  10. Upewnij się, że bot jest dostępny tylko z kanału w usłudze Teams i że cały ruch do i z usługi aplikacji bota przechodzi przez zaporę.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

  • Ali Jafry | Architekt rozwiązań w chmurze

Następne kroki