Como implementar o Fortigate com alta disponibilidade na AWS

Por Maurício Hollanda, arquiteto de soluções, AWS;

Karlos Correia, arquiteto de soluções, AWS

e Leandro Momesso , consultor de soluções, Fortinet

Visão geral

Muitas organizações buscam o uso de soluções de segurança para ter um maior controle de tráfego em sua rede com objetivo de aumentar a segurança do seu ambiente na nuvem AWS. Empresas com maiores necessidades de controle, realizam também a inspeção do tráfego externo (norte-sul) e interno (leste-oeste).

Utilizar uma arquitetura com alta disponibilidade e resiliente é crucial para a continuidade dos negócios e a construção de uma arquitetura com o controle dessa comunicação de forma centralizada em um cenário de múltiplas contas é um grande desafio na etapa de planejamento e desenho da arquitetura.

Nesse artigo, iremos apresentar como construir uma arquitetura com controle de comunicação de forma centralizada com alta disponibilidade e resiliente, utilizando a solução de firewall Fortinet FortiGate.

Arquitetura

A arquitetura proposta nesse artigo foi elaborada com base no desenho abaixo.

Nessa seção apresentaremos alguns detalhes da arquitetura elaborada. Seguindo as recomendações de segurança de segmentação de workloads, estamos trabalhando com um cenário multi-account dentro de uma mesma AWS Organizations, utilizando as seguintes contas:

• Network – Conta que irá concentrar todas as conexões que serão inspecionadas pelo firewall, contendo serviços necessários para essa análise como Firewalls Fortigate, Gateway Load Balancer, VPC Endpoints, AWS Transit Gateway, NAT Gateway e Internet Gateway;
• Spoke1 – Conta com os workloads da aplicação 1 da organização e também a conta que receberá o tráfego externo em sua rede interna na AWS;
• Spoke2 – Conta com os workloads da aplicação 2 da organização.

Entrando em mais detalhes de como funcionarão os tráfegos de comunicação nessa arquitetura:

• Toda a comunicação externa para a rede interna, será recebida no Internet Gateway da rede Spoke 1 e através do roteamento Ingress configurado na VPC Spoke 1, a conexão será direcionada para o firewall na VPC de Network para inspeção e validação da comunicação;
• Toda a comunicação em que uma VPC (Ex.: Spoke1 ou Spoke2) precisar se comunicar com a internet, a mesma será encaminhada para os firewalls na VPC Network para que o tráfego seja inspecionado e validado e a saída dessa conexão será pelo Internet Gateway da VPC de Network.  Esse fluxo ocorrerá dessa forma, mesmo que exista um Internet Gateway na conta Spoke, onde em nosso cenário, está sendo utilizado apenas para Inbound e não para Outbound;
• Toda a comunicação em que uma VPC (Ex.: Spoke1) precisar estabelecer uma comunicação com um workload de uma outra VPC (Ex.: Spoke2), a mesma será encaminhada para os firewalls da VPC Network para que o tráfego seja inspecionado e validado;

Para que essas comunicações funcionem adequadamente, utilizaremos as seguintes VPCs e Subnets:

Nota: A arquitetura de redes precisa ser planejada e desenhada de acordo com a situação atual da organização. Ajuste as VPCs, subnets, roteamentos e demais recursos, baseados nas necessidades de sua organização.

Etapas

Nessa seção entraremos nos detalhes de cada etapa percorrida para realizar as configurações dessa arquitetura. Teremos 03 etapas macros que serão abordadas:

1. Preparação das configurações básicas de redes;
2. Instalação e configuração dos firewalls;
3. Testes de comunicação.

Importante reforçar que para iniciar as próximas etapas, as 03 contas (Network, Spoke 1 e Spoke 2) já devem estar criadas dentro de sua Organização. Caso precise de apoio para criação das contas utilize o procedimento nesse link.

1.Preparação das configurações básicas de redes

1.1 Criação de VPCs

Nessa etapa, foi realizado a criação das 03 VPCs listadas abaixo:

Caso precise de apoio na criação das VPCs, utilize a documentação disponível no link Trabalhar com VPCs – Amazon Virtual Private Cloud.

Importante avaliar o plano de endereçamento e adequá-los a necessidade de sua organização.

1.2. Criação das subnets

Nessa etapa, realizaremos a criação das subnets. Essa configuração será realizada nas contas Network, Spoke1 e Spoke2. Verifique na tabela abaixo quais as contas, VPCs e Subnets que devem ser criadas:

Nota: Nessa arquitetura estamos utilizando as zonas de disponibilidade da região norte da Virginia (EUA). Utilize a zona de disponibilidade e região que melhor se adeque a necessidade de sua organização, lembrando que nesse cenário estamos trabalhando com uma única região.

Caso precise de apoio na criação das subnets, utilize a documentação disponível no link Trabalhar com sub-redes – Amazon Virtual Private Cloud.

1.3. Criação do Transit Gateway

Nessa etapa detalharemos as etapas para criação do Transit Gateway. O Transit gateway será criado na conta Network. Para criação do Transit Gateway, utilize o procedimento descrito no link Conceitos básicos dos gateways de trânsito – Amazon VPC, considerando as seguintes informações durante a configuração:

• Desmarque a opções “Default route table association” e “Default route table propagation”, pois iremos customizar a tabela de roteamento do Transit Gateway;
• Marque a opção “Auto accept shared attachments” para que possamos utilizar esse Transit Gateway nas demais contas (Spoke1 e Sploke2). Uma informação importante, o Transit Gateway é um serviço regional, logo, o mesmo só pode ser compartilhado com contas dentro da mesma região, portanto, mantenha o uso da região us-east-1 em suas configurações ou na região que utilizar em seu ambiente.

1.4. Compartilhamento do Transit Gateway entre as contas na mesma região

Nessa etapa realizaremos a configuração do compartilhamento do Transit Gateway para possibilitar com que outras contas possam utilizar o Transit Gateway para encaminhamento de pacotes. Para realizar o compartilhamento, utilize o procedimento descrito no link Sharing a transit gateway with an account or Organization.

1.5. Criação dos attachments das VPCs com o Transit Gateway

Após o compartilhamento do Transit Gateway com as VPCs, realize a criação do attachment das VPCs no Transit Gateway. Esse procedimento deve ser realizado em todas as contas da arquitetura, conforme tabela abaixo:

Atenção a ativação do Appliance mode Support no attachment da conta de Network.

Caso precise de apoio na configuração dos attachments, utilize o procedimento disponível no link Getting started with transit gateways – Amazon VPC utilizando as configurações descritas na tabela acima.

1.6. Criação das tabelas de roteamento do Transit Gateway

Nessa etapa, serão criadas 02 tabelas de roteamento no Transit Gateway seguindo as configurações da tabela abaixo. Esse procedimento deve ser realizado na conta Network.

Caso precise de apoio para configuração das tabelas de roteamento no Transit gateway, utilize o procedimento disponível no link Transit gateway route tables – Amazon VPC.

1.7. Criação dos NAT Gateways

Nessa etapa realize a criação de 02 NAT Gateways, sendo um em cada zona de disponibilidade para envio do tráfego da rede interna para a internet. Essa configuração deve ser realizada na conta de Network. Utilize a tabela abaixo como referência para as configurações.

Caso precise de apoio na criação do NAT Gateway, utilize o procedimento disponível no link NAT gateways – Amazon Virtual Private Cloud.

1.8. Criação do Internet Gateway

Nessa etapa realize a criação de 02 Internet Gateway, sendo 01 IGW na conta Network associado a Network-VPC e outro IGW na conta Spoke1 associado a Spoke1-VPC.
Caso precise de apoio, utilize o procedimento disponível no link  Connect to the internet using an internet gateway – Amazon Virtual Pri… na etapa “Create and attach an internet gateway”.

1.9 Configuração das tabelas de roteamento

Nessa etapa, realize a criação, configuração e associação das tabelas de roteamento customizadas conforme tabela abaixo.

Caso precise de apoio nessa etapa, utilize o procedimento disponível no link Trabalhar com tabelas de rotas – Amazon Virtual Private Cloud.

Após esse passo do procedimento, finalizamos a preparação da infraestrutura básica de redes para suportar a criação dos firewalls na arquitetura. Nas próximas etapas, daremos sequência na configuração do ambiente para o correto funcionamento dos firewalls.

2. Instalação e configuração dos firewalls

2.1 Criação dos firewalls

Nessa etapa realize a criação das 02 instâncias de firewall na conta de Network (Fortigate-Az1 e Fortigate-Az2) com o objetivo de mantermos de forma centralizada nessa conta a análise do tráfego.

Cada instância deve ficar em zonas de disponibilidade distintas e cada firewall deve ser configurado com 02 interfaces de rede na VPC de Network, sendo uma interface de rede para gerenciamento do firewall conectado a subnet de gerenciamento do firewall (Net-FW-Mgmt-AZ1-Subnet ou Net-FW-Mgmt-AZ2-Subnet) e a outra interface de rede que receberá o tráfego para a inspeção, conectado a subnet de inspeção do firewall (Net-FW-Private-AZ1-Subnet ou Net-FW-Private-AZ2-Subnet).

Existem algumas formas para criação dos firewalls na AWS, sendo uma delas através do AWS Marketplace. Nele, você pode utilizar as imagens disponibilizadas pela própria Fortinet. Nesse momento, é importante avaliar a imagem e o tipo de instância que melhor se adeque as necessidades de sua organização.

Durante a criação das instâncias é importante seguir com as recomendações da Fortinet documentadas nesse link. Importante que o Security Group associado a interface de rede de inspeção de tráfego, tenha as portas UDP 6081 (GENEVE) e TCP 8008 (Detecção de status) liberadas.

Grave o endereço IP privado concedido para as interfaces nas subnets “Net-FW-Private-AZ1-Subnet” e “Net-FW-Private-AZ2-Subnet”. Eles serão utilizados na configuração do Gateway Load Balancer.

2.2 Configuração dos firewalls

Nessa etapa daremos início ao processo de configuração dos firewalls. Para acesso a console você pode criar ou utilizar uma instância EC2 existente, conectada a subnet de gerenciamento do firewall, utilizando o sistema operacional e o browser de sua preferência para acesso ao endereço da interface de gerenciamento do firewall. Complete as etapas descritas abaixo na console CLI de cada firewall instalado.

A configuração abaixo será a mesma para ambos os firewalls.

1. Ativação do modo VDOM (Virtual Domain) – Nessa arquitetura utilizaremos o Root VDOM para gerenciamento e o FG-Traffic VDOM para inspeção do tráfego.

config system global

 set vdom-mode multi-vdom

end

config vdom

 edit FG-Traffic

 next
 end
end

2. Configuração VDOM– Nessa arquitetura, utilizaremos a porta 1 para o Root VDOM e a porta 2 para o FG-Traffic VDOM.

config global

config system interface

edit "port1"

     set vdom "root"

     set mode dhcp

     set allowaccess ping https ssh http fgfm

     set type physical

     set snmp-index 1

     set mtu-override enable

     set mtu 9001

  next
  edit "port2"

     set vdom "FG-Traffic"

     set mode dhcp

     set allowaccess ping probe-response

     set type physical

     set snmp-index 2

     set defaultgw disable

     set mtu-override enable

     set mtu 9001

   next
end

3. Configuração do detection response

config system probe-response

    set mode http-probe

end

2.3 Criação e configuração do GWLB

Agora que temos os endereços associados as interfaces dos firewalls, realizaremos a criação e configuração do Gateway Load Balancer que encaminhará o tráfego para os 02 firewalls Fortigate na conta Network. Para isso, execute os passos listados abaixo:

1. Na console AWS, navegue até a opção Load Balancers no menu do serviço EC2 e clique em “Create Load Balancer”
2. Clique em Create, abaixo da opção Gateway Load Balancer;
3. Forneça um nome para o GWLB;
4. Em Network Mapping, selecione a VPC “Network-VPC” e em subnets selecione as subnets “Net-FW-Private-AZ1-Subnet”e “Net-FW-Private-AZ2-Subnet”;
5. Em IP listener routing, criaremos um novo target group com as seguintes configurações:
   1. Target type: IP addresses
   2. Name: Forneça um nome desejado. Ex.: Target-Group-GWLB
   3. Protocol: Geneve
   4. VPC: Network-VPC
   5. Health checks: TCP
   6. Health Check Port: 8008
   7. IP: Forneça o IP das interfaces (porta 2) dos 02 firewalls e inclua na lista.
6. Após a criação do Target Group, volte ao setup do Gateway Load Balancer e selecione o Target Group criado;
7. Após a criação do GWLB, para garantir a alta disponibilidade do mesmo em múltiplas zonas, ative a opção “Cross-zone load balancing”. Para isso selecione a opção “Edit Attributes” do GWLB e salve a configuração após ativação.
8. Após a criação, salve os IPs associados a cada interface do Gateway Load balancer de cada Availability Zone, pois utilizaremos esses endereços na configuração do túnel Geneve no firewall.

2.4 Configuração do túnel Geneve

Nessa etapa, voltaremos aos firewalls para realizar a configuração do túnel Geneve nos 02 firewalls no VDOM FG-Traffic. Veja que na linha de comando “set remote-ip” você deve inserir o IP de cada zona de disponibilidade do GWLB coletado no passo anterior.

A configuração abaixo será a mesma para ambos os firewalls.

config system geneve

    edit "geneve-az1"

         set interface "port2"

         set type ppp

         set remote-ip <GWLB IP AZ US-EAST-1A>

     next
     edit "geneve-az2"

        set interface "port2"

        set type ppp

        set remote-ip <GWLB IP AZ US-EAST-1B>

      next
end

2.5 Configuração das rotas estáticas

Nessa etapa, realizaremos a configuração das rotas estáticas nos 02 firewalls, utilizando a CLI Console de cada firewall. Acompanhe os passos abaixo:

Atenção: Nessa configuração cada firewall terá sua própria configuração.

1. No firewall 01, localizado na zona de disponibilidade “us-east-1a” realize a seguinte configuração:

config router static

     edit 1

          set device "geneve-az1"

     next
     edit 2

          set device "geneve-az2"

     next
     edit 3

          set dst 10.0.2.0 255.255.255.0

          set gateway 10.0.1.1

          set device "port2"

      next
end

Veja que apontamos para a Subnet do firewall da zona de disponibilidade “us-east-1b” (10.0.2.0/24) e utilizamos o gateway da zona de disponibilidade “us-east-1a” (10.0.1.1).  Veja na documentação desse link que o IP final .1 é reservado pela AWS para o VPC router.

2. No firewall 02, localizado na zona de disponibilidade “us-east-1b” realize a seguinte configuração:

config router static

    edit 1

        set device "geneve-az1"

    next
    edit 2

        set device "geneve-az2"

    next
    edit 3

        set dst 10.0.1.0 255.255.255.0

        set gateway 10.0.2.1

        set device "port2"

     next
end

Essa configuração já é diferente da anterior, onde o comando aponta para a Subnet do firewall da zona de disponibilidade “us-east-1a” (10.0.1.0/24) e utiliza o gateway da zona de disponibilidade “us-east-1b” (10.0.2.1).

2.6 Configuração das policies de roteamento

Nessa etapa, realizaremos a configuração das policies de roteamento nos 02 firewalls utilizando a CLI Console de cada firewall instalado.  A configuração abaixo será a mesma para ambos os firewalls.

config router policy

     edit 1

         set input-device "geneve-az1"

         set output-device "geneve-az1"

      next
      edit 2

        set input-device "geneve-az2"

        set output-device "geneve-az2"

      next
end

2.7 Configuração da policy de proteção do Fortigate

Nessa etapa, realizaremos a configuração da policy de proteção nos 02 firewalls utilizando a CLI Console de cada firewall instalado.

Com objetivo de facilitar a configuração, adotaremos nessa policy uma configuração básica de segurança. Nesse ponto é importante adequar as policies mediante a necessidade e as características de proteção de sua organização.

A configuração abaixo será a mesma para ambos os firewalls.

config system zone

    edit FG-Traffic

        set interface geneve-az1 geneve-az2

    next
end

config firewall policy

    edit 1

        set name "FG-Traffic"

        set srcintf "FG-Traffic"

        set dstintf "FG-Traffic"

        set action accept

        set srcaddr "all"

        set dstaddr "all"

        set schedule "always"

        set service "ALL"

        set utm-status enable

        set ssl-ssh-profile "certificate-inspection"

        set av-profile "g-default"

        set ips-sensor "g-default"

        set application-list "g-default"

        set logtraffic all

    next
end

2.8 FortiGate SDN Connector

A policy de firewall tradicionais baseadas em endereços IP, se torna muito complexa, uma vez que os endereços IPs dos recursos AWS são dinâmicos e efêmeros. Os firewalls precisam de novos atributos para operarem em um ambiente dinâmico como na AWS. A Fortinet possui uma integração nativa com a AWS através do serviço Fabric Connector, que possibilita o mapeamento dinâmico dos recursos AWS baseado em tags para aplicação de policies de segurança. Não importa como os recursos mudem seus locais ou formatos, o FortiGate será capaz de identifica-los como objetos e utilizá-los nas policies de firewall sem atualização manual pelo administrador. Veja os passos para realizar essa configuração em ambos os firewalls.

1. Criação de uma IAM role para possibilitar com que as instâncias do firewall configurem o AWS SDN Connector. A IAM role deve estar associada a seguinte policy:

{

"Version": "2012-10-17",

    "Statement": [

          {

          "Action": ["ec2:Describe*"],

          "Resource": "*",

          "Effect": "Allow"

           }

     ]

}

2. Após a criação da role associe a IAM role acima na instância EC2 dos FortiGates. Caso precise de apoio nessa configuração utilize esse link.

3. Configuração do FortiGate SDN Connector.

1. 1. Acesse a console do firewall e no menu esquerdo clique em Security Fabric -> External Connectors
   2. Clique em Create New -> Amazon Web Services (AWS)
   3. Enable Use metadata IAM
   4. Clique OK

4. Criação de objetos dinâmicos utilizando o AWS SDN Connector.

1. 1. No menu esquerdo clique em Policy & Objects -> Address
   2. Clique em Create New -> Address
   3. Configure o endereço:
      1. Escolha um nome para o objeto
      2. No campo Type selecione Dynamic
      3. No campo Sub Type escolha Fabric Connector Address
      4. No campo SDN Connector selecione o conector criado no passo anterior
      5. No campo filter, configure o filtro desejado, como por exemplo, selecionar todos os recursos que estão no VPC: VpcId=vpc-xxxxxxxxxxx
      6. Em interface selecione any
      7. Clique em OK

5. Verifique que o AWS SDN Connector pode mapear dinamicamente todos os endereços IP de acordo com o filtro especificado.

1. 1. No menu esquerdo clique em Policy & Objects-> Address
   2. Passe o mouse sobre o objeto VPC_ADDRESS criado no passo anterior e veja a lista de endereços IPs encontrados.

2.9 Criação do serviço de endpoint

Nessa etapa, voltaremos a console da AWS para realizar a criação do serviço de endpoint em que os endpoints do GWLB serão associados. Todas configurações serão realizadas na conta de Network.

1. Na console AWS, navegue até a opção Endpoint services no menu do serviço VPC e clique em “Create endpoint service”
2. Forneça um nome para o endpoint service;
3. Em Load balancer type, selecione a opção “Gateway”
4. Em Available load balancers, selecione o GWLB criado.
5. Após a criação do serviço de endpoint, conceda permissão para a conta Spoke1 na aba “Allow Principals” para que possamos criar o endpoint na conta Spoke1. Nesse passo, daremos permissão para a conta <arn:aws:iam::<accountnumber>:root> fazendo referência a conta Spoke1. Importante avaliar a permissão que se adeque as necessidades de sua organização.
6. Grave o campo “Service name” do Endpoint Service, pois utilizaremos no próximo passo.

2.10 Criação dos endpoints

Nessa etapa, realizaremos a criação dos 03 endpoints, sendo 02 na conta de Network e um na conta Spoke1.

Criação dos endpoints na conta de Network (01 em cada zona de disponibilidade):

1. Na console AWS da conta Network, navegue até a opção Endpoint no menu do serviço VPC e clique em “Create endpoint”;
2. Forneça um nome para o endpoint. Ex.: gwlbe-endpoint-az1;
3. Em Service Category, selecione a opção “Other endpoint services”, insira o Service Name do endpoint service copiado na etapa anterior e clique em “Verify Service”.
4. Em VPC, selecione a “Network-VPC” e marque a subnet “Net-GLWBE-AZ1-Subnet” na zona de disponibilidade “us-east-1a.
5. Clique em Create endpoint.
6. Repita os passos acima para criação do endpoint na zona de disponibilidade “us-east-1b”. Caso você tenha marcado a opção de aprovação dos endpoints, não esqueça de aprová-los no endpoint service.

Criação do endpoint na conta Spoke1:

1. Na console AWS da conta Spoke1, navegue até a opção Endpoint no menu do serviço VPC e clique em “Create endpoint”;
2. Forneça um nome para o endpoint. Ex.: gwlbe-endpoint-spoke1;
3. Em Service Category, selecione a opção “Other endpoint services”, insira o Service Name do endpoint service copiado na etapa anterior e clique em “Verify Service”.
4. Em VPC, selecione a “Spoke1-VPC” e marque a subnet “Spoke1-GLWBE-Subnet”.
5. Clique em Create endpoint. Caso você tenha marcado a opção de aprovação dos endpoints, não esqueça de aprová-los no endpoint service.

2.11 Inclusão do Gateway Load Balancer Endpoint nas tabelas de roteamento

Após a criação dos endpoints, realizaremos nessa etapa a criação, configuração e associação das tabelas de roteamento customizadas conforme tabela abaixo.

Você também criará uma tabela de roteamento do tipo Ingress que será associado ao Internet Gateway na conta Spoke1.

Caso precise se apoio nessa etapa, utilize o procedimento disponível no link Create route tables.

Nas tabelas de roteamento já existentes abaixo, inclua as seguintes rota.

Caso precise de apoio nessa etapa, utilize o procedimento disponível no link Trabalhar com tabelas de rotas – Amazon Virtual Private Cloud.

3. Testes de comunicação

Após a conclusão das configurações acima, com objetivo de testar a comunicação entre workloads em diferentes segmentos de rede e com a internet, realize a criação de uma instância EC2 nas subnets privadas das contas Spoke1 e Spoke2 e uma instância na subnet pública com IP público na conta Spoke1. Vamos realizar 04 testes de comunicação:

1. Comunicação entre as instâncias sem regra de bloqueio;
2. Comunicação entre as instâncias com regra de bloqueio;
3. Comunicação da instância com internet;
4. Comunicação da internet com a instância pública.

1. Comunicação entre as instâncias sem regra de bloqueio
   Conecte na instância da rede privada na conta Spoke 1 e faça um PING para a instância da conta Spoke 2. Após a execução do PING, você deve visualizar o log no Fortigate similar ao da imagem abaixo.

2. Comunicação entre as instâncias com regra de bloqueio
   Primeiramente você deve criar uma policy de firewall para bloqueio de ICMP em ambos os firewalls como a imagem abaixo.

Após a criação da regra, tente estabelecer a comunicação ICMP entre as instâncias e visualize o log do Fortigate. Você verá um bloqueio similar ao da imagem abaixo.

3. Comunicação da instância com internet
   Agora dentro da instância da rede privada na conta Spoke1, tente estabelecer uma comunicação com um site público e visualize se o tráfego está sendo detectado pelo firewall. Como exemplo, realizamos uma simulação de acesso ao site www.fortinet.com e tivemos o resultado do log conforme a imagem abaixo.

4. Comunicação da internet com a instância pública
   Nesse teste realizamos a instalação de um Apache no servidor da subnet pública e liberamos a porta 80 no Security Group da instância apenas para testes. Estabelecemos uma comunicação com o servidor através de seu IP público na internet e tivemos o resultado do log conforme imagem abaixo, evidenciando a inspeção do tráfego externo no firewall antes de chegar na instância.

Conclusão

Nesse artigo realizamos a criação de uma arquitetura de segurança de tráfego centralizada, utilizando a solução de firewall Fortinet Fortigate, implantada em um cenário com alta disponibilidade em multi-zona, utilizando o serviço de Gateway Load Balancer da AWS, garantindo a continuidade da inspeção, mesmo diante de um cenário de indisponibilidade de uma das zonas. Você poderá utilizar essa arquitetura como referência para implantação em sua organização.

Sobre o autor

Mauricio Hollanda é arquiteto de Soluções da Amazon Web Services para o setor público, atua no segmento de Educação e ingressou na AWS em 2022. Trabalha há mais de 17 anos com tecnologia da informação atuando na gestão de ambientes de nuvem, infraestrutura de data center e segurança.

Karlos Correia é Arquiteto de Soluções da Amazon Web Services para o setor público e atua especificamente com Governo Federal. Trabalhou anteriormente com arquitetura e planejamento de infraestrutura em empresas do setor de telecomunicações e um é apaixonado por aviação.

Leandro Momesso é consultor de soluções de nuvem na Fortinet para América Latina, atua no desenvolvimento de arquiteturas de segurança e suporte a clientes na estratégia de segurança em nuvem. Trabalhou anteriormente com arquitetura de soluções de data center, segurança e network para grandes clientes.