Introdução
Este documento descreve como implantar o Cisco Firepower Threat Defense Virtual (FTDv) em autoescala no Azure em um ambiente de alta confiança.
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
- O NGFW e o Firepower Management Center devem se comunicar por IP privado
- O Balanceador de Carga Externo não deve ter um IP público
- O aplicativo da função deve ser capaz de se comunicar com o IP privado
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
- Azure
- Firepower Management Center
- Conjunto de Escala de Máquina Virtual
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Informações de Apoio
O FTDv traz a funcionalidade do firewall de próxima geração Firepower da Cisco para ambientes virtualizados, permitindo que políticas de segurança consistentes sigam cargas de trabalho em ambientes físicos, virtuais e em nuvem e entre nuvens.
Com essas implantações disponíveis em um ambiente virtualizado, atualmente o suporte para HA não está disponível para NGFW. Portanto, para fornecer uma solução altamente disponível, o Cisco Next-Generation Firewall (NGFW) utiliza os recursos nativos do Azure, como Conjuntos de Disponibilidade e Virtual Machine Scale Set (VMSS), para tornar o NGFW altamente disponível e atender ao aumento de tráfego sob demanda.
Este documento concentra-se em configurar o Cisco NGFW para AutoScale com base em diferentes parâmetros em que o NGFW é escalado ou dimensionado sob demanda. Isso abrange o caso de uso em que o cliente precisa usar o Firepower Management Center (FMC), que está disponível no data center de localização e é necessário para gerenciar centralmente todo o NGFW. Além disso, os clientes não querem que o FMC e o FTD se comuniquem pelo IP público para o tráfego de gerenciamento.
Antes de aprofundar-se na configuração e na consideração de design, estes são os poucos conceitos que devem ser bem compreendidos e enviados ao Azure:
Zona de Disponibilidade: Uma zona de disponibilidade é uma oferta de alta disponibilidade que protege seus aplicativos e dados contra falhas do data center. As Zonas de Disponibilidade são locais físicos exclusivos dentro de uma região do Azure. Cada zona é composta por um ou mais data centers equipados com energia, resfriamento e rede independentes.
VNET: A Rede Virtual do Azure (VNet) é o bloco de construção fundamental para sua rede privada no Azure. A Rede Virtual permite que muitos tipos de recursos do Azure, como Máquinas Virtuais (VM) do Azure, se comuniquem com segurança entre si, com a Internet e com as redes locais. A Vnet é semelhante a uma rede tradicional, pois você operaria em seu próprio data center, mas traz consigo benefícios adicionais da infraestrutura do Azure, como escala, disponibilidade e isolamento. Cada sub-rede dentro de uma VNET é alcançável entre si por padrão, mas o mesmo não é verdadeiro para sub-redes em diferentes VNETs.
Conjunto de Disponibilidade: Os conjuntos de disponibilidade são outra configuração de data center para fornecer redundância e disponibilidade de VM. Essa configuração em um data center garante que, durante um evento de manutenção planejado ou não planejado, pelo menos uma máquina virtual esteja disponível e atenda ao SLA do Azure de 99,95%.
VMSS: Os conjuntos de escala de máquina virtual do Azure permitem criar e gerenciar um grupo de VMs com balanceamento de carga. O número de instâncias de VM pode aumentar ou diminuir automaticamente em resposta à demanda ou a um agendamento definido. Os conjuntos de escalabilidade fornecem alta disponibilidade para seus aplicativos e permitem que você gerencie, configure e atualize centralmente um grande número de VMs. Com conjuntos de escala de máquina virtual, você pode criar serviços em grande escala para áreas como computação, Big Data e cargas de trabalho de contêineres.
Aplicativo de Funções: o Azure Functions é um serviço de nuvem disponível sob demanda que fornece toda a infraestrutura e recursos continuamente atualizados necessários para executar seus aplicativos. Você se concentra nas partes do código que mais importam para você, e o Azure Functions lida com o resto. Você pode usar as Funções do Azure para compilar APIs da Web, responder a alterações de banco de dados, processar fluxos da IoT, gerenciar filas de mensagens e muito mais. Nesta solução de Autoescala, o Azure Function são várias solicitações de API ao FMC para criar objetos, registrar/cancelar o registro de FTDv, verificar os parâmetros etc.
Aplicativo Lógico: o Azure Logic Apps é um serviço de nuvem que ajuda você a agendar, automatizar e orquestrar tarefas, processos de negócios e fluxos de trabalho quando precisar integrar aplicativos, dados, sistemas e serviços em empresas ou organizações. Os aplicativos lógicos simplificam o modo como você projeta e cria soluções escaláveis para integração de aplicativos, integração de dados, integração de sistemas, integração de aplicativos empresariais (EAI) e comunicação entre empresas (B2B), seja na nuvem, no local ou em ambos. Esta solução fornece o sequenciamento lógico das Funções a serem executadas para o funcionamento da solução de Autoescala.
Atualmente, a solução AutoScale disponível para NGFW não fornece um plano de gerenciamento para se comunicar com o IP privado local para a rede virtual e exige IP público para trocar a comunicação entre o Firepower Management Center e o NGFW.
Este artigo tem como objetivo resolver esse problema até que a solução verificada esteja disponível para comunicação do Firepower Management Center e NGFW por IP privado.
Configurar
Para criar uma solução de NGFW de dimensionamento automático, este Guia de configuração é usado com várias modificações para que os seguintes casos de uso possam ser abordados:
- O aplicativo da função deve ser capaz de se comunicar com o segmento IP interno do cliente
- O Balanceador de Carga não deve ter um IP Público
- O tráfego de gerenciamento entre NGFW e FMC deve ser trocado pelo segmento IP privado
Para criar uma solução AutoScaled NGFW, com os casos de uso mencionados anteriormente, você precisa modificá-los nas etapas mencionadas no Guia oficial da Cisco:
1. Modelo ARM do Azure
O Modelo ARM é usado para habilitar a Automação no Azure. A Cisco forneceu um Modelo ARM verificado que pode ser utilizado para criar uma solução de dimensionamento automático. Mas este modelo ARM disponível no Public Github cria um aplicativo de funções que não pode ser feito para se comunicar com a rede interna do cliente, embora eles possam ser acessados através de rotas expressas. Portanto, você precisa modificar um pouco isso para que o Aplicativo de Função possa agora usar o modo Premium em vez do Modo de Consumo. O Modelo ARM Necessário está disponível em https://github.com/Madhuri150791/FunctionApp_with_Premiium_Plan.git.
2. Função APP
O Aplicativo de Função é um conjunto de funções do Azure. A funcionalidade básica inclui:
- Comunique/sonde as métricas do Azure periodicamente.
- Monitore a carga de FTDv e acione operações de dimensionamento interno/dimensionamento horizontal.
- Registrar um novo FTDv no FMC.
- Configure um novo FTDv via FMC.
- Cancelar o registro (remover) de um FTDv escalonado do FMC.
Conforme mencionado no requisito, a várias funções que estão sendo criadas para criação ou exclusão de NGFW sob demanda é feita com base no IP público do NGFW. Portanto, precisamos ajustar o código C# para obter o IP privado em vez do IP público. Depois de ajustar o código, o arquivo zip para criar o Aplicativo de Função está disponível em https://github.com/Madhuri150791/FunctionApp_with_Premiium_Plan.git
com o nome ASM_Function.zip. Isso permite que o aplicativo Funções se comunique com Recursos Internos sem ter o IP Público.
3. Aplicativo lógico
O Aplicativo Lógico de Escala Automática é um fluxo de trabalho, ou seja, uma coleção de etapas em uma sequência. As funções do Azure são entidades independentes e não podem se comunicar entre si. Esse orquestrador sequencia a execução dessas funções e troca informações entre elas.
- O Aplicativo Lógico é usado para orquestrar e passar informações entre as funções de Dimensionamento Automático do Azure.
- Cada etapa representa uma função Auto Scale do Azure ou uma lógica padrão interna.
- O Aplicativo Lógico é entregue como um arquivo JSON.
- O Aplicativo Lógico pode ser personalizado por meio da GUI ou do arquivo JSON.
Observação: os detalhes do aplicativo Lógico disponíveis em https://github.com/Madhuri150791/FunctionApp_with_Premiium_Plan.git devem ser cuidadosamente modificados e esses itens devem ser substituídos por detalhes de implantação, Nome do APLICATIVO FUNCIONAL, Nome do GRUPO DE RECURSOS, ID DA ASSINATURA.
Diagrama de Rede
Esta imagem mostra como o tráfego de entrada e saída flui em um Ambiente do Azure por meio do NGFW.
Configurações
Agora, crie vários componentes necessários para uma solução de dimensionamento automático.
- Crie componentes da Lógica de Autoescala.
Use o Modelo ARM e crie VMSS, APLICATIVO Lógico, APLICATIVO de Função, Informações de Aplicativo e Grupo de Segurança de Rede.
Navegue até Home > Create a Resource > Search for Template
e, em seguida, selecione Template Deployment
. Agora clique em Create
e crie seu próprio modelo no editor.
- Clique em
Save
.
Faça as alterações necessárias neste modelo e clique em Review + create
.
- Isso cria todos os componentes sob o grupo de recursos mencionado.
- Faça login na URL.
Carregar o arquivo ASM_Function.zip
e ftdssh.exe
para site/wwwroot/
pasta (é obrigatório carregá-la no local especificado Função App não identifica várias funções).
Ele deve ser como esta imagem:
- Faça check-in no
Function app > Function
. Você deve ver todas as funções.
- Altere a permissão de acesso para que o VMSS possa executar as Funções dentro do Aplicativo de Função. Navegue até
-vmss> Access Control (IAM) > Add role assignement
. Fornecer a este colaborador VMSS acesso a
-function-app
.
Clique em Save
.
- Navegue até
Logic App > Logic Code
visualize e altere o código Lógico com o código disponível em https://github.com/CiscoDevNet/cisco-ftdv/tree/master/autoscale/azure/NGFWv6.6.0/Logic%20App. Aqui, a Assinatura do Azure, o Nome do Grupo de Recursos e o Nome do Aplicativo de Função precisam ser substituídos antes do uso; isso não permite que o salve com êxito.
- Clique em
Save
. Navegue até Visão Geral do Aplicativo Lógico e Habilite Logic App
.
Verificar
Quando o Aplicativo Lógico é habilitado imediatamente, ele começa a ser executado no intervalo de 5 minutos. Se tudo estiver configurado corretamente, você verá as ações de acionamento sendo bem-sucedidas.
Além disso, a VM é criada no VMSS.
Inicie sessão no FMC e verifique se o FMC e o NGFW estão conectados por IP privado FTDv:
Ao fazer login na CLI do NGFW, você verá o seguinte:
Assim, o FMC se comunica com o NGFW pela Sub-rede da Rede Virtual Privada do Azure.
Troubleshooting
Às vezes, o aplicativo lógico falha quando você cria um novo NGFW, para solucionar esses problemas, estas etapas podem ser executadas:
- Verifique se o Aplicativo Lógico está sendo executado com êxito.
- Identifique a causa da falha. Clique no acionador com falha.
Tente identificar o ponto de falha do fluxo de código. A partir dessa imagem, fica claro que a lógica do ASM falhou, pois não foi capaz de se conectar ao FMC. Em seguida, você precisa identificar por que o FMC não estava acessível conforme o fluxo no Azure.