Azure Private Endpoint
Sempre posto artigos de dados, mas acredite, você que é de dados precisa saber o que essa parada faz e vou explicar porque.
O cenário
Imagina o seguinte cenário, você tem sua rede cloud e dados na sua rede cloud, você também tem um datacenter da sua empresa, onde seus servidores de dados estão hospedados. Esse banco de dados não tem saída pra internet e nem deve (estamos falando de uma ambiente corporativo de larga escala).
Imagina também que na sua cloud (nesse exemplo Azure) você está criando um banco de dados SQL pra ser bem simplista. Agora um último, exemplo você tem uma aplicação que pega parte dos dados dos seu banco no Datacenter (modelo On premises) e parte do seu SQL (modelo Cloud).
Uma das principais e mais simples criações de recursos de dados na cloud é fazer a criação desse recurso de forma pública, o que seria isso? Trata-se de ao criar um banco SQL por exemplo, a Azure te dá um endereço (endpoint) e por traz dele um endereço IP Público que dá acesso a qualquer um em qualquer lugar do mundo desde que tenha regras atribuídas para acessa-lo (podemos criar regras restritivas de acesso por IPs e outras).
Isso funciona? SIM! Funciona e é a solução simplista mesmo, porém é uma solução CARISSIMA a longo prazo, caso você use muitos dados desse banco.
E qual seria o motivo?
As clouds geralmente não cobram INGRESS (entrada de dados), então tudo que você movimentar pra lá não tem custo, porém o EGRESS é pago e cada consulta que você fizer nesse banco tem um custo além do próprio funcionamento dele, isso também serve para qualquer outra cloud como GCP ou AWS.
Esse cara é o pior vilão da Cloud, o que o povo chama de Data Transfer, que nada mais é que essa transferencia de dados citada acima. Dependendo da frequência e volumetria dessas consultas, o Data transfer sai mais caro que o banco e talvez o custo de operação (quanto sua aplicação vale, somado aos bancos) que você mediu não seja exatamente o que você previa.
Se você me acompanha sabe que eu sempre preso que o engenheiro de dados ou arquiteto tenha uma noção básica de cloud, infra e redes, assim você não é pego de surpresa numa dessas.
Como solucionar esse problema?
Primeiramente preciso fazer uma integração entre a rede on premises e a rede (VNET) cloud. Existem várias formas de fazer isso, desde a solução barata até onde a empresa contrata um link dedicado entre os pontos (as empresonas geralmente contratam).
VPN e Site to Site
Existem soluções mais baratas que o link dedicado e que cabem no bolso dependendo do seu trafego entre as redes, a mais em conta é configurar uma VPN entre sua rede e a rede Cloud, criando assim uma conectividade entre ambas, um ponto fraco dessa solução é que se caiu seu link com internet da rede on premises ja era a conectividade.
Um exemplo de como fazer isso segue no link abaixo:
A solução ponto a ponto é um pouco mais robusta, falando de um lugar onde trabalhei, basicamente era uma conexão entre um serviço cloud e um firewall da empresa e nela temos que criar as rotas, fazendo ambos se falarem, é um pouco mais elaborada que a anterior e pode se adequar ao seu cenário, de acordo com o size da sua empresa.
Link dedicado (Express Route)
Esse é o modelo usado pelas empresas endinheiradas onde elas contratam um link com SLA, redundância e etc., pagam uma quantidade de trafego definido, como link de 1GB por exemplo e boa, nem vou entrar muito no detalhe, mas caso queira ver mais sobre segue link abaixo.
Agora que falei das possíveis conectividades entre o mundo on premises e cloud vamos ao assunto principal, o private endpoint.
O que faz o private endpoint?
Esse primeiro exemplo que vou dar, esqueça a conectividade entre clou e on premises, imagina o cenário que você tem uma aplicação na rede interna, por exemplo 192.168.0.10. Agora você cria um banco SQL e precisa fazer esse cara falar com seu banco. Lembre o SQL criado é um PaaS (Plataform as a service) e não tem uma infra na sua rede, tudo que ele vai te dar por padrão é um endpoint publico, não dar nenhum acesso ao banco ou criar um private endpoint, não aparece como vincular ele em nenhuma rede por padrão, lembra que ele é um serviço microsoft e não uma maquina ou algo do tipo (usei o exemplo com Azure SQL mas esse conceito é o mesmo para Data Factory, Databricks e outros).
Em resumo, o private endpoint me daria a possibilidade de ter um IP na mesma rede da aplicação no exemplo (192.168.0.0/24), eu poderia criar um 192.168.0.20 e conseguir que aplicação e banco se fale de forma interna, sem a necessidade de meu banco ter acesso público (o que numa necessidade posso ter também).
Onde o private endpoint entra no exemplo entre clouds e cloud/on premises? Na mesmíssima idéia, preciso dar um IP da rede on premises pra ele!
HUB/Spoke
Pra te deixar bom nisso aqui de uma vez por todas, tenho que te falar sobre HUB/Spoke, é uma metodologia onde centralizo meus recursos como saida pra internet, acessos, regras e rotas em uma VNET e todas as demais que precisarem sair vão usar a VNET centralizada, de uma forma bem resumida é isso. Se liga no desenho.
Nesse desenho a VNET HUB se encarrega da conexão do mundo on premises com o mundo cloud, usando o link dedicado e o Express Route, tentei jogar uns IPs parecidos só pra exemplificar que os IPs na Cloud são extensão dos IPs do On Premises (se você é de rede não julgue, é para um bem maior, rs).
A VNET SPOKE nem tem além de um peering com a rede HUB, pode se comunicar com o outro lado através das regras de rotas atribuídas e tal, mais uma vez é uma ideia simplista que estou mostrando.
Note que o SQL tá la como PaaS, preciso atribuir um IP pra ele pra que a aplicação do desenho consiga falar com ele na mesma rede e eu não precise que ela fale pela internet, assim como expliquei no começo do post. Agora entra o Private endpoint que me dá esse IP necessário nessa rede e cria toda a comunicação. Se liga no desenho agora.
Levando em consideração que tenho todas as regras de conectividade entre os 2 mundos, consigo falar de forma privada da minha aplicação para o meu Banco SQL. Bonito né? Mas calma que o problema ainda não está resolvido.
Como na Azure toda conexão é HTTPS com os endpoints, eu não consigo fechar uma conexão via IP, pois o certificado TLS está atrelado ao nome do Banco SQL e não ao IP, se eu for na minha aplicação e falar pra ir no endpoint "xyz.database.azure.net" ele vai resolver um IP público, apesar de não deixar comunicar (suponhamos que a aplicação não saia pra internet), não vai chegar no banco via host, ai que entram os DNSs privados e públicos.
DNS Privado
Quando você cria um private endpoint para o recurso ele automaticamente cria um private DNS pra você, criando um novo endpoint "xyz.privatelink.database.azure.net" e resolvendo o IP 192.168.1.10, porém se usar esse endereço ainda não vai rolar, por que o certificado está atribuído ao “xyz.database.azure.net” e não a esse, ai ele cria uma referencia CNAME no private DNS e o ALIAS. Em resumo se você jogar o endereço “xyz.database.azure.net” ele vai saber que é o 192.168.1.10 também, mas isso só dentro do ambiente microsoft Azure, fora desse mundinho ele ainda não sabe disso.
Você precisa de uma forma de replicar essa informação para o seu servidor DNS On premises, ou ir lá e inserir esse registro manualmente nele (o que é bem zuado). Se liga no desenho atualizado agora.
O desenho acima mostra resolvido do lado da Azure, mas o lado On premises não sabe resolver ainda. Antigamente, a galera criava regras no DNS apontando para maquinas na cloud Azure que faziam a resolução dos privates, isso tinha um custo e não era tão dinâmico. Hoje existe um serviço da Azure que se chama private DNS Resolver, que faz um link entre os privates DNSs da Azure com o seu DNS on premises, assim, quando nascer um private endpoint na sua cloud, seu DNS on premises já sabe, bem mais simples que ter que fazer uma entrada na mão sempre quando precisar criar um.
Inclusive já fiz um post aqui falando sobre ele, se liga ai em baixo.
Sendo assim com esse cara em cima em funcionamento ficaria o seguinte:
Com esse cenário bonito tenho minha aplicação on premises conversando com meu banco de dados na Azure e até se eu precisar do inverso eu consigo. Tudo de forma interna, sem exposição de dados na internet, sem pagar Data transfer ou soluções de WAF (Web application Firewall), acredite sai bem caro ir por fora.
Private endpoint é um recurso Microsoft Azure, porém em outras clouds existem o mesmo recurso, por exemplo no GCP se chama "Private Service Connect" e na AWS se chama "AWS Private Link", lembrando que em ambas ainda preciso resolver os private DNSs entre elas pra que funcione.
Espero que não tenha ficado confuso, esse é um assunto que venho estressando bastante nos últimos anos e acho que consegui abranger tudo que precisa pra você sair do outro lado.
Espero que ajude, não esquece de deixar a palminha ae!
Abraço!
Anselmo Borges.
