Private Endpoints

Private Endpoints

Fazendo referência ao modelo de defesa em profundidade (defense in-depth), uma das camadas que devemos considerar quando estivermos montando nossa arquitetura é a camada de rede (networking). É nessa camada que todos os nossos dados passarão, então é essencial que no momento de projeção da solução, sua segurança seja levada em conta e tratada com cautela. Hoje vamos falar sobre os Private Endpoints, solução do Azure que nos permite manter a comunicação com os recursos da plataforma segura.


O que são?

Manter as comunicações entre recursos privadas é um desejo de quase todas as empresas em praticamente todos os cenários, porém isso nem sempre é possível devido a uma série de fatores - o recurso utilizado não suporta comunicação 100% privada, o custo de utilização e implementação é muito alto e não irá gerar ganhos substanciais ao projeto.

Nos casos onde as necessidades de negócio permitem e justificam esse modelo de comunicação, podemos sugerir o uso dos private endpoints (quando técnicamente possível/viável).

Um Private Endpoint é um tipo de recurso do Azure que permite que suas soluções se comuniquem com recursos da plataforma de maneira segura e privada, não passando pela internet.

São usados em larga escala em ambientes empresariais, que precisam manter suas comunicações privadas por motivos de segurança, performance e até mesmo de compliance.

💡
Os private endpoints estão disponíveis de maneira nativa apenas para soluções PaaS (Platform as a Service) disponíveis no Azure.

É importante compreendermos essas "limitações", pois no momento de montagem da sua arquitetura, em que estivermos estudando os recursos que deverão ser utilizados, nos depararemos com cenários como esses.


Como funcionam?

Como mencionado anteriormente, os private endpoints funcionam na camada de networking do nosso ambiente Azure, devendo ser implementados dentro das nossas estruturas de VNet (Virtual Network - Rede Virtual).

Por trás dos panos, esse recurso funciona sob o Azure Private Link, serviço que permite estabeler uma comunicação segura com qualquer recurso da plataforma. A diferença é que com os private endpoints a configuração dos recursos já vem pronta, não havendo a necessidade de se entrar em tantos detalhes como é feito com o private link.

Ao criar um private endpoint o que está sendo criado é um IP privado para aquele recurso dentro da sua subnet. Como sabemos, os recursos PaaS não requerem a seleção de uma VNet para serem criados, portanto a criação de um private endpoint para aquele recurso em questão, faz com que ele seja representado dentro da sua própria VPC, podendo então ser referenciado internamente.

Quando uma solução é configurada para utilizar os private endpoints todos os acessos a esses recursos serão roteados através do backbone global da Microsoft, não passando em momento algum pela internet. Isso garante à solução velocidade, segurança e privacidade, alcançando os objetivos anteriormente listados.

Após o estabelecimento de um IP privado para o seu recurso PaaS, um passo importante é termos a configuração da zona de DNS privado para o seu recurso, criando um endpoint legível, compreensível e que faça muito mais sentido do que se especificar um IP dentro da sua aplicação.


Arquitetura

Pensando na simples implementação de um Azure Key Vault com private endpoints, teremos uma arquitetura parecida com a representada abaixo:

Nossos workloads (aplicações) estão sendo executadas na VNet representada, que também contém uma subnet dedicada para os private endpoints. A aplicação executada consome o key vault pelo seu endpoint privado, ou seja, o endpoint configurado utilizando a zona privada de DNS, que faz uma referência ao IP privado do recurso (representado pelo NIC - Network Interface Card).

Com essa arquitetura montada, tods os workloads que estiverem sendo executado na VNet em questão e nas VNets conectadas poderão consumir o key vault através do seu private endpoint.


Quando usar?

Pergunta frequente no dia a dia de um arquiteto, "quando devemos utilizar esse recurso?".

Os principais motivos foram mencionados ao longo do texto, esses sendo:

  • Privacidade;

  • Segurança;

  • Velocidade/Performance;

  • Compliance.

Manter uma comunicação entre recursos privada gera benefícios de pequena e de larga escala nas soluções. Para grandes organizações, é provavel a definição de uso dos private endpoints seja à nível corporativo, devido a redução da superfície de ataque (já que os recursos não estarão expostos à internet) gerada pela implementação desse recurso e também pela simplificação das análises dos projetos.

Como não só de segurança e performance vivem as empresas, uma outra preocupação para uso de novos recursos são os custos.

Pricing

A imagem acima (retirada da documentação oficial da Microsoft) representa o modelo de cobrança e pricing dos private endpoints.

Note que temos 3 pontos de preocupação:

  • Custo base - custo gerado pela solução apenas por ser implementada, nesse caso, $0.01/hora;

  • Inbound Data Processed - ingestão de dados através dos private endpoints, sendo cobrada de acordo com a quantidade de dados transmitida;

  • Outbound Data Processed - saída de dados através dos private endpoints, como o modelo anterior, cobrada de acordo com a quantidade de dados trafegados através do recurso.

Essas serão as cobranças realizadas quando seus private endpoints estiverem implementados. Não esqueça de levar esses valores em conta quando for apresentar aos stakeholders do projeto os custos referentes à solução.

💡
Os preços irão variar de acordo com a região que estiver sendo utilizada e também com a cotação da moeda referênciada.

Por hoje é isso, espero que tenha gostado do texto e que eu tenha conseguido contribuir para o seu entendimento de como esse recurso funciona e os motivos que levam os arquitetos a recomendar seu uso.

Estou à disposição para responder quaisquer dúvidas pelo meu Linkedin ou pelo próprio blog.

Até logo!