Redes em Cloud: projete e proteja VPCs e subnets

Fundamentos de redes em Cloud - Apresentação​

Apresentando a instrutora e o curso

Olá! Meu nome é Valéria Baptista e sejam muito bem-vindos à aula de Segurança de Redes na Nuvem, aqui na Alura.

Audiodescrição: Valéria é uma mulher de pele clara, com cabelo castanho escuro e olhos castanhos. Ela veste uma blusa azul e está em um ambiente de escritório com uma parede clara ao fundo.

Neste vídeo, vamos nos concentrar nos fundamentos de rede na computação em nuvem e em como podemos nos preparar para avançar no mercado de trabalho. Seja para mudar de emprego, ser promovido ou se especializar neste campo que cresce a cada dia.

Compartilhando experiência profissional

Trabalho na área de tecnologia há mais de 15 anos. Comecei no início, trabalhando com a parte local, configurando máquinas e fazendo backups, atividades sem muito glamour. Com o passar dos anos, fui me especializando, principalmente em Cloud (nuvem), onde tenho a maioria das minhas certificações em Microsoft Azure, mas também possuo certificações em OCA, AWS, na parte de gestão de custos, o famoso FinOps, e sou instrutora oficial da Microsoft.

Atualmente, trabalho como gerente de produto na Magalu Cloud, um provedor de nuvem brasileiro que está se destacando para competir em um grande mercado com AWS, Azure, GCP e outros. Dedico muita da minha experiência acumulada ao longo dos anos para entender as necessidades do mercado e, claro, como criar um produto valioso no mercado de Cloud para aquisição de empresas.

Introduzindo redes virtuais na nuvem

Este vídeo, no entanto, não é para falar sobre mim, mas sim sobre o que são as redes virtuais na nuvem e os desafios para que nós, profissionais da área, possamos nos especializar e no que devemos nos atentar para nos destacarmos.

Falando de desafios, criar e gerenciar redes na nuvem pública é, de fato, um grande desafio. Devemos considerar que a nuvem tem se difundido no Brasil há cerca de 10 anos. Muitas empresas começaram a adotá-la nos últimos 5 anos, e ainda há aquelas que estão ponderando se devem migrar ou não, avaliando o que faz sentido. É um mercado em expansão crescente, o que é ótimo para nós que trabalhamos na área, mas ainda há muitas empresas e pessoas que não possuem o conhecimento necessário e precisam de ajuda. E nós estamos aqui para ajudá-los.

Explorando desafios de redes em nuvem pública

O desafio das redes em uma nuvem pública surge porque a maioria das empresas já existia há 10, 20 anos. São empresas consolidadas, com seus próprios centros de dados, e, em muitos casos, mais de um centro de dados, caso tenham filiais. Quando falamos de nuvem, é como adicionar outro centro de dados à conta, mas sem a responsabilidade pela parte física, apenas pelas configurações.

Quando falamos de serviços de rede, toda a comunicação depende da parte de networking (rede). Se não houver uma configuração correta, algo deixará de funcionar. Assim, quando uma empresa decide migrar para a nuvem e consumir esses serviços, é essencial que tenhamos uma comunicação segura. Todos os recursos na nuvem, em algum momento, se comunicarão com o que está no ambiente on-premise (local).

Compreendendo redes virtuais e segurança

Nosso grande desafio começa aqui. Precisamos entender o funcionamento de uma rede virtual, pois é comum fazermos comparações. No ambiente on-premise, trabalhamos com redes virtuais, LANs, e temos um ambiente no datacenter onde parte dos recursos está separada e não se comunica com o restante da rede da empresa. Na nuvem, também é assim. Existe uma crença de que a segurança na nuvem é responsabilidade do próprio provedor, mas não é exatamente assim. O provedor nos oferece ferramentas, mas nós devemos aplicar as configurações necessárias.

Quando olhamos para uma rede virtual, por exemplo, temos nosso edifício da empresa, nosso ambiente local com redes virtuais, e máquinas virtuais no ambiente na nuvem. A rede virtual na nuvem tem um comportamento muito semelhante ao de uma rede on-premise. Teremos regras, faixas de IP determinadas, e, a partir disso, conectaremos nossos recursos, que se comunicarão entre si. A rede virtual na nuvem é, na verdade, uma representação da própria rede que temos em nosso ambiente local.

Criando e gerenciando redes virtuais

Criar uma rede virtual no ambiente de nuvem, seja na AWS, Azure ou GCP, é como ter uma extensão dos recursos que possuímos em nosso ambiente local. Não será algo isolado, sem comunicação; pelo contrário, a rede no ambiente público se comunicará com nosso ambiente local, funcionando como se tivéssemos outro centro de dados, mas sem a responsabilidade de gerenciar os recursos físicos. Quando temos nosso ambiente local e, pelo menos, alguns serviços na nuvem, chamamos isso de ambiente híbrido. Também ouvimos a expressão multicloud. Multicloud é quando nossos serviços estão distribuídos em mais de uma nuvem. Atualmente, o mais comum para as empresas é trabalhar em um modelo híbrido, ou seja, ter um centro de dados local e recursos em, pelo menos, uma nuvem. Quando começamos a expandir isso para outras nuvens, nosso ambiente se torna multicloud. Claro que a complexidade também aumenta. Precisamos ter pessoas em nossa equipe ou contratar uma empresa externa que forneça algum tipo de suporte para evitar problemas com a criação, administração ou gestão de recursos em geral.

Administrando redes virtuais e conectividade

Falando mais especificamente sobre a rede virtual, ela é uma unidade lógica. Dentro da infraestrutura do provedor de nuvem que estamos utilizando, teremos essa porção que vamos administrar. Quando falamos em administração, estamos nos referindo ao trabalho com endereçamento, segmentação de IPs, roteamento, ou seja, quem queremos que se comunique com essa rede, políticas de segurança, quem poderá fazer essa administração, além da conectividade híbrida, ou seja, do nosso ambiente local para o ambiente na nuvem. Essa comunicação pode ser feita de diversas formas. Podemos trabalhar com VPN, que é uma configuração lógica, onde forçamos a comunicação de um extremo ao outro. Também podemos utilizar modelos conhecidos como ExpressRoute ou Direct Connect, que envolvem contratar uma empresa autorizada para literalmente levar uma fibra óptica do nosso centro de dados até o centro de dados do provedor. No entanto, esse é um processo relativamente caro, e como os provedores de nuvem estão localizados em São Paulo, nem todas as empresas conseguem fazê-lo de forma viável. Imagine uma empresa no Amazonas querendo implementar uma comunicação como ExpressRoute; seria praticamente inviável e muito custoso. Nesse caso, uma VPN faria mais sentido, permitindo oferecer um serviço totalmente criptografado e seguro.

Considerando fatores para comunicação segura

Ao pensarmos nas redes e na comunicação do nosso ambiente local com a nuvem, devemos considerar muitos fatores: o tempo disponível, o investimento que a empresa pode fazer e o objetivo. Ir para a nuvem é uma forma de resolver problemas que o ambiente local não está solucionando. Para resolver esses problemas, não devemos criar outros; devemos criar soluções. Quando criamos uma rede na nuvem, de forma nativa, ela está lá, mas não se comunicará com ninguém. Precisamos definir: quando houver uma comunicação externa para essa rede, quem pode acessar e para onde? E quando recursos dentro dessa rede buscarem comunicação externa, quais portas poderão usar? Por isso, a segurança relacionada aos serviços que utilizamos é importante. Por exemplo, ao criar uma rede e configurar um servidor para um e-commerce, esse e-commerce precisa receber informações da web, pois é por lá que os clientes virão. Dizemos que ele precisa "ouvir" da rua. Se não liberarmos isso, o e-commerce não funcionará. Agora, se configurarmos um banco de dados usado apenas por uma plataforma interna, não há razão para aceitar comunicações externas. Na sub-rede onde esse recurso está, configuramos para que não haja comunicação com o mundo exterior, apenas com outras redes dentro da nuvem, garantindo segurança ao isolar essa comunicação, sem afetar nossos serviços.

Enfatizando a importância da gestão de redes

A configuração das redes virtuais é feita pelo cliente que adquire o serviço, e o provedor de nuvem deve nos oferecer opções para manter tudo seguro dentro do nosso ambiente e permitir monitoramento. Uma má gestão não é penalizada pelo provedor de nuvem, mas pode resultar em graves falhas de segurança na empresa, por isso devemos ter cuidado.

Fundamentos de redes em Cloud - Redes em provedores Cloud

Explicando a configuração de redes na AWS

Aqui, trazemos um exemplo da Amazon com a Virtual Private Cloud. Este é um modelo de configuração de uma rede virtual na nuvem da AWS. Primeiramente, temos a região. A região é uma localidade onde estão os centros de dados desse cloud provider (provedor de nuvem). Por exemplo, temos a região de São Paulo. Fisicamente, uma região compreende três centros de dados, que estão a certa distância entre si, formando um triângulo. Em cada vértice desse triângulo, há um centro de dados, totalizando três. Esses centros de dados se comunicam rapidamente entre si, pois existem serviços configurados para replicação. Assim, quando algo é criado em um local, é simultaneamente criado nos outros dois.

Na AWS, temos a Virtual Private Cloud, ou seja, a rede em si, e as subnets (sub-redes), como trabalhamos em um ambiente on-premises (local). Ao configurar a rede virtual, determinamos o prefixo, como /16 ou /24, para definir a quantidade de IPs dentro desse intervalo. Com base nisso, criamos as sub-redes, ou subnets, e dentro delas, criamos nossos recursos.

Discutindo a comunicação entre redes e sub-redes

Os cloud providers geralmente aplicam a estratégia de que, por padrão, as sub-redes, sendo filhas da rede virtual, se comunicam entre si. No entanto, as redes virtuais não se comunicam automaticamente. Elas são como elementos isolados, que só se comunicam com suas sub-redes, a menos que configuremos para que se conectem entre si. Isso é uma medida de segurança. Se uma rede for invadida, a intrusão não se espalhará para outras redes, limitando o impacto.

As sub-redes se comunicam por padrão porque pertencem à mesma rede virtual. A comunicação entre redes virtuais não é padrão, mas pode ser ativada quando necessário. Criar várias redes virtuais sem comunicação entre elas não é um erro, mas uma estratégia de segurança. É importante separar as redes para diferentes categorias de serviço. Por exemplo, em um e-commerce, a comunicação com a internet deve ser feita apenas pela rede virtual específica para essa plataforma, enquanto outros serviços devem estar em redes separadas.

Comparando estratégias de rede entre AWS e Microsoft Azure

Ao trabalhar com uma rede virtual, ela pertence a uma única região, que é composta por, no mínimo, três centros de dados que se comunicam entre si. Quando criamos uma rede virtual, ela está ligada a uma região específica. Se precisarmos comunicar recursos em outra região, criamos uma nova rede virtual nessa região. Recursos como redes virtuais são regionais, não globais.

Comparando com as redes na Microsoft Azure, a Virtual Private Cloud tem uma estratégia semelhante. Quando entendemos a estratégia de um cloud provider, começamos a entender como os outros funcionam. Embora a nomenclatura, o custo e a interface mudem, a lógica e a estratégia são parecidas.

Explorando a importância do Resource Group na Azure

No cenário da Microsoft, temos um modelo onde o Resource Group (grupo de recursos) é essencial. Nada é criado na nuvem da Microsoft sem um Resource Group associado. Esse grupo de recursos é como uma caixa organizadora, sem custo, onde colocamos todos os elementos relacionados a um projeto específico, como um e-commerce. Primeiro, criamos o Resource Group, depois a rede virtual, a subnet, e, por fim, a máquina virtual.

O acesso à máquina virtual pode ser configurado com um IP público para ser acessível externamente. Não podemos esquecer das regras de segurança, os Network Security Groups, que determinam como a comunicação funciona, quais portas serão usadas e quais conexões serão aceitas.

Configurando regras de segurança na Azure

Quando configuramos um ambiente no Microsoft, podemos determinar regras específicas para um recurso, como a NIC, que é a placa de rede da máquina, ou para toda a sub-rede. Assim, todos os recursos nessa sub-rede receberão a mesma regra. Se configurarmos na sub-rede, a regra se aplicará a todos os recursos nela; se configurarmos na placa de rede, a regra será associada apenas à máquina virtual.

Não existe necessariamente um certo ou errado, tudo depende do ambiente e de como foi acordado mantê-lo funcional. Um problema pode surgir se as regras de acesso forem colocadas diretamente na placa de rede da máquina ou na sub-rede associando o Network Security Group. Por exemplo, se configurarmos diretamente na máquina virtual e depois formos transferidos para outro departamento, a nova pessoa responsável pode não perceber essa configuração e criar regras no Network Security Group sem replicar a regra manual da placa de rede. Isso pode fazer com que a aplicação na máquina deixe de responder.

Destacando a importância da comunicação e governança

A comunicação é essencial. Se tivermos configurado regras específicas diretamente na placa de rede, devemos informar isso para que a nova pessoa possa replicar a regra no Network Security Group, removê-la da máquina e garantir que tudo funcione corretamente. Já vivenciamos situações assim, como em um cliente com um grande ambiente de máquinas virtuais que criava todas as regras nas placas de rede. Embora permitido pelo provedor, isso pode se tornar problemático em um ambiente com muitas máquinas, pois qualquer alteração exigiria um trabalho manual tedioso. Se a configuração estivesse apenas no Network Security Group, bastaria remover uma linha e salvar.

Em ambientes grandes, ajustes manuais na configuração específica do recurso não são recomendados. Embora o cliente possa fazê-lo, não é a melhor estratégia. Cada caso é único, e é importante considerar todas as possibilidades antes de enfrentar um grande trabalho posteriormente.

Comparando a segurança e conectividade entre AWS e Azure

Comparando Microsoft Azure com AWS, as redes se comportam de forma semelhante. Temos a definição do intervalo de IP, as sub-redes se comunicam nativamente, mas redes virtuais não se comunicam entre si sem configuração. Podemos configurar regras de segurança diretamente na placa de rede ou na sub-rede, mantendo a comunicação por ExpressRoute ou VPN. Isso é essencial para a conectividade dos recursos na nuvem.

As redes são isoladas por padrão, principalmente por questões de segurança. Podemos configurar o peering para permitir a comunicação entre redes, mas é possível definir que a comunicação seja unidirecional. Isso pode ser útil, mas devemos considerar que, em testes de comunicação, a falta de retorno pode tornar a prova inútil.

Concluindo com a importância da segurança e auditoria na nuvem

A segurança nativa não significa que o ambiente já está seguro. O provedor de nuvem oferece ferramentas de segurança, como os Network Security Groups, controle de rotas e monitoramento, para proteger as redes. Estar na nuvem não garante segurança, e é necessário especializar-se na área para entender os desafios e lacunas.

As redes na nuvem são a base de toda a arquitetura. Não podemos criar servidores ou clusters Kubernetes sem associar IPs ou redes virtuais. Temos isolamento de workloads nas redes virtuais, mas podemos configurar a comunicação e controlar o tráfego com regras de segurança. A arquitetura na nuvem é mais escalável e rápida, com menos complexidade, mas exige governança e entendimento das ferramentas disponíveis no provedor de nuvem.

Devemos sempre questionar: onde os dados vão? Onde buscar os logs? Como auditar? Se não fizermos isso, é provável que enfrentemos falhas de segurança no futuro. Espero que essas dicas tenham sido úteis e nos vemos no próximo vídeo. Até então!

Fundamentos de redes em Cloud - Componentes de redes em Cloud​

Introduzindo o tema de redes em computação em nuvem

Olá, como estamos? Neste vídeo, vamos discutir os componentes essenciais de rede no ambiente de Computação em Nuvem.

Ao apresentar o primeiro compêndio de arquitetura de redes em ambiente Cloud (nuvem), é importante destacar que nem todos os componentes ou recursos residem necessariamente na própria nuvem. Podemos estar falando de uma comunicação entre nosso ambiente on-premises (local) e a nuvem, e nem todos os recursos oferecidos podem ser vantajosos ou necessários em algum momento. Geralmente, as empresas começam com pequenas cargas de trabalho e, à medida que crescem, adaptam-se a novos produtos e serviços, seja por configuração ou por custos. É crucial conhecer os componentes padrão de uma rede na nuvem para justificar, em um projeto, para um cliente ou para nossa própria empresa, o uso ou não de um determinado serviço. É sobre isso que vamos falar neste vídeo.

Explorando componentes fundamentais de redes na nuvem

Ao abordar os componentes fundamentais, a base famosa quando falamos de nuvem, temos as redes virtuais, que serão nosso núcleo. Elas são formadas, por exemplo, por sub-redes, uma segmentação lógica dentro do barramento da rede virtual criada, onde os recursos e serviços incluídos podem se comunicar de forma padrão. Também precisamos considerar o modelo de roteamento, ou seja, quando nosso recurso está na nuvem, com quem ele precisa se comunicar? E esse recurso final com o qual precisa se comunicar, onde está? Está dentro da própria nuvem? Está em um ambiente externo? Está dentro do nosso centro de dados, na nossa parte on-premises? Isso determinará as rotas de comunicação.

Devemos também pensar nos gateways. Os gateways são responsáveis pelo controle de entrada e saída, pela comunicação entre nossos recursos que estão na nuvem. Além disso, falamos sobre o peering, que é a comunicação entre redes virtuais. Temos ainda uma segurança integrada, que podemos ou não utilizar, mas está disponível, com controle de tráfego nas sub-redes, e também a conectividade híbrida, que será o grande núcleo de comunicação entre nossos recursos.

Considerando segurança e conectividade na nuvem

É importante mencionar que, ao criar nossos recursos na nuvem, as empresas geralmente pensam: precisamos de uma comunicação segura de origem a destino. Precisamos que essa comunicação seja rápida e criptografada, para evitar problemas de intrusão e roubo de informações da empresa. Podemos considerar uma VPN, ExpressRoute, Direct Connect, dependendo da localização e do investimento disponível, entre outros fatores. No entanto, ao estabelecer uma comunicação fluida entre nosso ambiente on-premises e a nuvem, e ao começar a criar recursos, percebemos que há muitos mais detalhes envolvidos.

Por exemplo, ao criar uma rede virtual, ela já nasce com pelo menos uma sub-rede. Essa sub-rede terá um barramento padrão, são divisões lógicas da nossa rede virtual, e a estratégia é agrupar cargas de trabalho e recursos com base na função, para que uma regra de abertura não prejudique outro produto ou serviço, ou não torne o sistema muito complexo ou confuso. Por exemplo, podemos agrupar na mesma sub-rede recursos que não queremos que sejam acessados pela internet. Assim, sabemos que para essa sub-rede não precisamos abrir nada externo. Já outros recursos que precisam acessar a internet ou que serão acessados, colocamos em outra sub-rede, para melhor administração. Tudo isso é uma questão de organização, separando cargas de trabalho por funções.

Implementando políticas de segurança e roteamento

Quando falamos de políticas, não nos referimos necessariamente à padronização de recursos, mas sim a políticas de segurança, padrões de segurança específicos, para evitar problemas como perda de pacotes, falhas de roteamento ou aberturas que afetem outros produtos dentro do mesmo grupo. Ao conseguir fazer essa separação lógica, facilitamos muito mais do que simplesmente adicionar uma regra e esperar que funcione sem problemas. No entanto, chega um ponto em que o crescimento é tanto que se torna um problema muito grande.

Comparando Cloud Providers (provedores de nuvem), as sub-redes, tanto na AWS quanto no Azure, seguem estratégias muito semelhantes. Podem ser públicas, no caso da AWS, enquanto no Azure são privadas por padrão, o que já representa um cenário de segurança mais agressivo. Associamos também as zonas de disponibilidade, no caso da AWS, que podem ser usadas para separar serviços. Embora não tenhamos mencionado isso para o Azure, também pode ser usado para suportar e separar serviços. A partir do momento em que determinamos as regras associadas, isso facilita bastante.

Analisando ferramentas de segurança e roteamento em provedores de nuvem

No caso do Microsoft Azure, temos os Network Security Groups, que podem ser associados à interface de rede de uma máquina ou até mesmo às sub-redes. Isso nos garante que a comunicação para essa sub-rede passará por essa regra, eliminando a possibilidade de comunicações não mapeadas previamente. Além disso, na AWS, temos as tabelas de rotas. Essas tabelas de rotas são associadas às sub-redes, controlando quem entra e quem sai. Para tornar isso mais visível, podemos imaginar uma tabela de Excel, onde determinamos a comunicação de X para Y, utilizando as portas A, B ou C. Podemos permitir modelos de rotas estáticas, roteamento de pacotes dentro dos nossos recursos, tudo isso através das tabelas de rotas.

No Azure, não é muito diferente. Temos as User Defined Routes (UDRs). Para que serve uma tabela de rotas? Substitui um roteamento padrão. Podemos forçar nosso tráfego a passar por um Firewall, Appliance, um NVA, controlando rotas internas e para a Internet. Muitas vezes, colocamos um modelo de rota onde chegamos a uma determinada rede virtual e, a partir dessa rede virtual, podemos acessar nosso datacenter. Isso cria o que chamamos de Gateway de transitividade, ou seja, faz um roteamento de pacotes. São aspectos que podemos administrar.

Garantindo segurança na exposição à Internet

Devemos prestar atenção especial a tudo que se expõe à Internet e à comunicação que vem de fora, para garantir que, assim como todos os pontos de segurança, não abramos mais do que o necessário. Qualquer brecha, por menor que pareça, pode ser usada para um ataque externo ou fuga de informações.

No contexto dos Gateways, temos esse modelo de solução na nuvem que funciona como uma ponte. O Gateway sempre aponta para a comunicação. Assim, temos uma gestão de segurança entre diferentes redes, nosso ambiente on-premises, por exemplo, e nossos serviços na nuvem, com o objetivo de facilitar o intercâmbio de dados. Mesmo que esses ambientes usem padrões de comunicação totalmente diferentes, podemos manter esse intercâmbio de informações de um lado para o outro.

Estruturando redes na nuvem para comunicação eficiente

Geralmente, o que escolhemos? Ao criar nossos recursos na nuvem, levantamos uma estrutura semelhante. A própria Microsoft indica que criemos um modelo onde teremos uma rede virtual específica, que não ficará isolada, mas será a porta de entrada de comunicação do nosso on-premises com ela. Essa rede centralizada se comunica com as outras redes que criamos, por cargas de trabalho A, B ou C. Essa rede central será responsável por se comunicar com nosso on-premises, funcionando como o primeiro salto. Nosso on-premises se comunica com essa rede, e se houver algo mais distribuído em outras redes, faremos o roteamento e vice-versa. Essa rede principal, essa rede de entrada, servirá como nossa primeira comunicação. Se tivermos algum recurso ou serviço que esteja no segundo salto para chegar ao nosso ambiente on-premises, ele não irá direto. Chegará a essa rede primeiro e, por meio de um roteamento, poderá reenviar o pacote para nosso ambiente on-premises. Dessa forma, conseguimos ter rastreabilidade de toda a comunicação, por onde ela passa. Lembre-se, o ambiente on-premises segue um padrão, mas o ambiente de nuvem também tem o seu. É um padrão mais moderno, mas muitas coisas são extremamente semelhantes.

O que precisamos saber, com base na rastreabilidade, é com quem nossos recursos se comunicam e qual é o próximo salto. Isso deve ser determinado de forma eficiente para não perdermos essa informação. Assim como a estratégia de peering, onde teremos comunicação entre duas redes virtuais. Lembremos que a rede virtual nasce independente e suas sub-redes, suas filhas, se comunicam entre si. Quando criamos uma nova rede virtual, elas não se conhecem, é como se cada uma falasse um idioma diferente, nem sequer sabem da existência uma da outra. Se há uma solicitação de um recurso de uma rede virtual para outra, sem peering, elas nem sabem onde estão, é como se estivessem no escuro, sem comunicação.

Facilitando comunicação entre redes virtuais com peering

O peering nada mais é do que forçar uma comunicação entre duas redes virtuais na nuvem, para que todos os seus recursos se comuniquem automaticamente. Essa funcionalidade está presente tanto na AWS quanto na Azure, e a estratégia é a mesma. Por segurança, as redes virtuais nascem sem se comunicar; quem se comunica são seus recursos filhos. Se precisarmos de comunicação, unilateral ou bilateral, devemos criar um peering, caso contrário, não funcionará.

No contexto do peering, podemos conectar redes que estão na mesma região ou em regiões diferentes. No caso do Microsoft Azure, podemos fazer o peering global. Por exemplo, temos uma rede em São Paulo, mas recursos na rede dos Estados Unidos. Podemos criar um peering de um extremo ao outro, chamado de peering global, e todos os recursos começarão a se comunicar. Se fizermos a mesma configuração para uma rede na mesma região, torna-se um peering regional. Assim, podemos fazer tanto uma coisa quanto a outra.

Explorando gateways e comunicação na AWS

Na AWS, além da configuração de peering por rede, temos modelos de gateway de comunicação, onde podemos permitir a comunicação entre as redes virtuais e a Internet pública, além da criação de conexão entre VPN e as redes virtuais da AWS, roteamento de pacotes entre redes virtuais. No Internet Gateway, permitimos a comunicação entre nossa rede virtual e a Internet pública, expondo-a. O NAT Gateway permite que nossa instância privada se conecte à Internet, mas bloqueia o tráfego de entrada. Isso é importante para instâncias que não queremos que acessem a Internet, mas que precisam fazer consultas ou atualizações.

Para cada uma dessas situações, teremos um modelo de gateway associado. Claro que, dependendo do provedor, pode haver variações na nomenclatura, mas é importante entender que no modelo de nuvem, geralmente encontramos padrões e funcionalidades muito semelhantes, pois a usabilidade do cliente final é parecida. Estamos criando recursos, já temos um ambiente on-premises, e na maioria dos casos, precisamos que isso se comunique e, conforme o ambiente cresce, deve-se adaptar.

Desafios e soluções para comunicação em nuvem

Esse é um grande desafio: quando precisamos testar nossa comunicação, garantir essa comunicação de ponta a ponta. Essas são as ferramentas que nos ajudarão. Na Microsoft, também temos a parte de funcionamento de gateway, onde o trânsito do nosso gateway permitirá que redes emparelhadas compartilhem esse gateway, tenham acesso a recursos e possamos garantir uma conectividade padrão.

Por exemplo, em um diagrama, temos a rede virtual A com sua sub-rede e a rede B com sua sub-rede. Existe um emparelhamento, ou seja, uma comunicação tanto de A quanto de B para essa vnet hub. A vnet hub geralmente recebe esse nome quando é a rede virtual central, semelhante às DMZs do ambiente on-premises, ou zona desmilitarizada, que é nossa porta de entrada. Na estratégia que a Microsoft indica, é chamada de rede hub, por isso existe uma estratégia conhecida de comunicação na nuvem chamada hub-and-spoke, que a própria Microsoft recomenda.

Nesse modelo, a rede A tem um emparelhamento com a rede hub, mas a vnet B também o tem. Isso significa que a vnet A se comunica com a vnet hub, a vnet B se comunica com a vnet hub, mas uma não se comunica com a outra. Não há roteamento de pacotes entre elas. Se ambas se comunicam com a hub, o pacote não simplesmente sai de uma e chega à outra. O que acontece é que na vnet hub temos uma sub-rede de gateway que se conecta a uma VPN. Isso significa que o pacote que vem da vnet B chega a esse gateway VPN e pode ir ao ambiente local, pois estamos fazendo esse roteamento. Chamamos isso de gateway de transitividade.

Concluindo sobre estratégias de comunicação e segurança

A rede aqui não alcança diretamente o ambiente on-premises, mas usamos essa conexão de gateway quando precisamos enviar um pacote para o on-premises. Assim, todas as redes que conectarmos aqui e permitirmos esse reenvio podem enviar um pacote para o ambiente on-premises. Concluímos que nossa sub-rede sempre será uma estrutura lógica, como as que temos no ambiente on-premises, onde a estratégia a ser usada é a separação por funcionalidades, workloads, pois isso facilitará a administração, criação de regras, permissões, e tudo isso se reflete em estratégias de Zero Trust, que é um elemento dentro da segurança da informação que diz: desconfie de todos, não confie em ninguém. Isso nos ajuda a fechar todas as possibilidades e dificultar ao máximo para quem queira nos incomodar.

O roteamento definirá o caminho do tráfego, ou seja, para onde pode ir nosso próximo pacote, em termos de controle, segurança, roteamento, até mesmo para ter previsibilidade. Por exemplo, ao criar uma nova aplicação que precisa buscar informações no on-premises, em um recurso que ainda não migramos para a nuvem, precisaremos de um roteamento para que, a partir desse salto, chegue ao on-premises e retorne.

Os gateways permitirão a maioria dessas comunicações, pois fazem a ponte entre a nuvem e outros ambientes, no contexto de cenários híbridos, tornando essa comunicação fluida e mais segura. Para termos essa fluidez na comunicação, em muitos casos, precisaremos implementar o peering de comunicação entre redes virtuais. Em alguns cenários, não há muito o que fazer, mesmo que não seja o ideal, o peering está lá para isso. A segurança, que em muitos casos está integrada, não se ativa automaticamente, mas temos as ferramentas para isso.

Quando falamos de segurança, ao traçar essas rotas e definir quem se comunica com quem, delimitamos as regras e controlamos nossas sub-redes para saber de onde parte cada comunicação. Isso não é algo que configuramos uma vez e deixamos para sempre; deve ser revisado constantemente. A conectividade híbrida é uma necessidade. Integrar o on-premises com a nuvem pública, ou mais de uma nuvem pública, permite dar continuidade à nossa empresa, manter o que já existe, replicar recursos, levar recursos para a nuvem. Muitas vezes, retiramos coisas que temos on-premises e as substituímos por recursos na nuvem. Todo esse cenário de comunicação é o que nos ajuda a tornar esse processo possível.

Conhecer a estratégia, os casos de uso e quando usar cada um desses pontos, independentemente da cloud que estamos usando, garantirá o sucesso, ou não, do nosso projeto. Esperamos que tenham gostado deste vídeo e aguardamos vocês na próxima aula. Até então!

Sobre o curso Redes em Cloud: projete e proteja VPCs e subnets

O curso Redes em Cloud: projete e proteja VPCs e subnets possui 299 minutos de vídeos, em um total de 42 atividades. Gostou? Conheça nossos outros cursos de Segurança em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Fundamentos de redes em Cloud