A sua VPN não torna o Cosmos DB privado sozinha

Liga o portátil à VNet através de uma VPN, abre o URL da conta Cosmos DB, e o pedido continua a sair pela internet pública. O túnel fez o seu trabalho. O que não fez foi criar um endpoint privado, publicar o registo DNS privado ou desativar o acesso público, porque são três alterações separadas na conta e não propriedades da sua ligação de rede. Este exemplo usa o Azure Cosmos DB para NoSQL, um endpoint privado numa VNet e um portátil ligado a essa VNet por VPN, e mantém o endereço da aplicação inalterado.

O mito: estar na VPN torna a base de dados privada

Estar na VNet significa apenas que os seus pacotes podem alcançar endereços privados nessa VNet. Não diz nada sobre onde o nome da conta é resolvido, e não diz nada sobre se a conta ainda aceita tráfego público.

Um endpoint privado é um recurso separado com o seu próprio endereço, o seu próprio passo de aprovação e a sua própria cablagem DNS. Até existir e ser aprovado, o nome é resolvido para o endpoint público e o seu tráfego vai para lá independentemente do túnel.

O que realmente faz o nome ser resolvido de forma privada

Mantenha o endpoint normal da conta do SDK, algo como https://ACCOUNT.documents.azure.com. O DNS privado deve resolver esse nome através da cadeia Private Link para os endereços privados do endpoint. Não o substitua por um URL numérico nem desative as verificações de certificados, porque isso troca um problema de DNS por um problema de segurança.

Esses valores são específicos da API NoSQL. As outras APIs Cosmos não são entradas intermutáveis no mesmo exemplo, e copiar o nome do subrecurso de outra API produz um endpoint que nunca é resolvido.

Crie e aprove o endpoint através do fluxo de trabalho autorizado do Azure e, em seguida, utilize a sua integração com o grupo de zonas DNS privadas. O portátil precisa de um resolvedor que consiga responder por essa zona, diretamente ou através de reencaminhamento aprovado, e de uma rota de cliente VPN para cada endereço de endpoint relevante.

Um endpoint privado pode ter mais do que um endereço, incluindo entradas globais e regionais. Mantenha a integração DNS quando as regiões da conta mudam, em vez de fixar um único endereço num ficheiro hosts, e lembre-se de que uma resposta de um resolvedor público não relacionado não prova nada sobre o caminho privado. Se reencaminhar DNS através de um hub, confirme que o reencaminhador responde antes de depurar o cliente. Um reencaminhador desatualizado devolve a resposta pública, que se parece exatamente com um endpoint em falta.

O modo Gateway e o modo Direct não são intermutáveis

O modo Gateway envia pedidos de serviço por HTTPS sobre TCP 443. É por isso que uma política de firewall apenas para a 443 funciona com ele e é por isso que este exemplo o escolhe deliberadamente.

O modo Direct sobre Private Link tem requisitos de conetividade diferentes, incluindo um intervalo de portas TCP mais amplo que a documentação da conta enumera. Uma política escrita para o modo Gateway não deve ser reutilizada silenciosamente para um cliente em modo Direct, ou o SDK liga-se e depois fica pendurado na primeira operação de dados.

Escolha um modo, registe-o com a conta e faça a política de rede corresponder. As equipas que mudam de modo durante a resolução de problemas acabam normalmente com um conjunto de regras de firewall que não satisfaz nenhum dos dois.

Desativar o acesso público é um interruptor separado

Se a conta deve ser apenas privada, desative o acesso à rede pública através da definição suportada da conta e verifique o resultado. Não trate a existência de um endpoint privado como a decisão completa de acesso, porque uma conta com um endpoint privado e acesso público ativado continua a responder na internet.

Verifique de fora da VPN e também de dentro. Um pedido de uma rede que deveria estar excluída é o teste que prova que a definição entrou em vigor, e é o teste que a maioria das janelas de alteração salta.

A acessibilidade não é permissão

Uma operação SDK permitida a partir do portátil da VPN é o teste de aceitação, usando o URL normal da conta e a identidade pretendida. A acessibilidade por VPN não concede permissões de dados do Cosmos; o plano de dados verifica as suas próprias funções ou chaves.

Depois execute as recusas: uma identidade diferente e um caminho de rede que já não deve alcançar a conta. Se qualquer um tiver sucesso, o limite que documentou não é o limite que construiu.

Anote quatro factos ao terminar: os endereços privados do endpoint, a zona DNS que responde pelo nome da conta, o modo de ligação com os seus requisitos de portas e se o acesso público está desativado. Esses quatro explicam a configuração à pessoa seguinte, e cada um falha de forma independente.