Solução do Cenário 1 – Arquitetar escala global e acesso seguro
Na unidade anterior, você trabalhou em um cenário que envolve a escala global de uma rede de distribuição de conteúdo. Nesta unidade, você examinará uma solução em potencial e alguns itens a serem considerados.
Ao examinar, você deverá comparar a solução fornecida com aquela que você desenvolveu na unidade anterior. Com frequência, há mais de uma solução correta para qualquer problema, mas sempre há prós e contras. Quais itens na sua solução são diferentes do proposto? Há algo na sua solução que você pode reconsiderar? Há algo na solução fornecida que você acredita que seja abordado mais detalhadamente na sua solução?
Configuração e opção de implantação
A primeira decisão a se considerar é qual opção de implantação do SQL do Azure deve ser selecionada. Embora o SQL Server funcione em uma VM (máquina virtual) do Azure, uma oferta de PaaS (plataforma como serviço) pode fornecer uma opção mais adequada com menos sobrecarga de gerenciamento.
O cliente está usando o CLR (Common Language Runtime), que é um recurso com escopo de instância. A Instância Gerenciada de SQL do Azure é a única opção de implantação de PaaS que dá suporte a recursos com escopo de instância, como o CLR, o Service Broker e o Database Mail. Por esse motivo, a Instância Gerenciada de SQL do Azure pode permitir que o cliente faça a migração para uma oferta de PaaS sem precisar reescrever os aplicativos CLR dele em uma solução compatível com o Banco de Dados SQL do Azure (como trabalhos de banco de dados elástico).
A próxima decisão a ser tomada envolve a camada de serviço. Como o cliente deseja isolar as cargas de trabalho de leitura e gravação dele, o uso da camada de serviço Comercialmente Crítica será a maneira mais simples de conseguir isso. A camada de serviço Comercialmente Crítica tem um grupo de disponibilidade Always On em execução em segundo plano. Uma dessas réplicas secundárias pode ser usada para cargas de trabalho somente leitura.
Ser Comercialmente Crítico é apenas metade da configuração para separar cargas de trabalho de leitura e de gravação. O cenário indica que é necessário que o cliente possa ajustar a escala em várias regiões com várias consultas simultâneas, enquanto isola cargas de trabalho de leitura e de gravação.
As duas opções que podem potencialmente enfrentar esse desafio são a replicação geográfica e os grupos de failover automático. No entanto, a replicação geográfica não tem suporte no momento na Instância Gerenciada de SQL do Azure. O uso de um grupo de failover automático é, portanto, a única opção que pode ajudar esse cenário na obtenção da escala global de leitura.
Agora, como o cliente está usando grupos de failover automático, a necessidade ou não da camada de serviço Comercialmente Crítica dependerá de quantos pontos de extremidade somente leitura a carga de trabalho de análise desse cliente requer. Com um grupo de failover automático na camada de serviço Comercialmente Crítica, o cliente obteria três pontos de extremidade legíveis:
- Uma réplica secundária do grupo de disponibilidade da região primária
- O secundário do grupo de failover (que é a réplica primária do banco de dados na região secundária)
- A réplica secundária do grupo de disponibilidade da região secundária
Se a carga de trabalho de análise não precisar de todas essas réplicas legíveis, o Uso Geral poderá ser uma solução mais econômica.
Selecionar os métodos de autenticação mais apropriados
A outra parte desse cenário envolve determinar a melhor maneira para cada aplicativo/pessoa se conectar à solução, devido à necessidade de criar e usar as tecnologias mais seguras possíveis. Se você dividir o cenário, haverá quatro clientes separados que precisarão de acesso à Instância Gerenciada de SQL do Azure:
- Aplicativo em execução em uma VM do Azure
- Um aplicativo em execução em um computador não Azure conectado ao domínio
- DBAs ou outros usuários de ferramentas de administração do SQL (SQL Server Management Studio, Azure Data Studio, PowerShell) de um computador não Azure não conectado ao domínio
- Aplicativos mais antigos em execução em um computador não Azure no qual você não pode alterar o driver ou a cadeia de conexão
Vamos observar esses clientes em termos de como você pode escolher o método de autenticação e algumas considerações e restrições adicionais em cada um deles.
Aplicativo em execução em uma VM do Azure
Identidades gerenciadas para recursos do Azure são, em geral, a forma recomendada de autenticação sem senha para aplicativos em execução em máquinas virtuais do Azure.
Um aplicativo em execução em um computador não Azure conectado ao domínio
Para computadores não Azure, o uso de identidades gerenciadas não é uma opção. A autenticação integrada por meio do Microsoft Entra ID é o método de autenticação recomendado para aplicativos em execução em computadores ingressados no domínio fora do Azure, supondo que o domínio tenha sido federado com o Microsoft Entra ID.
Se o computador não Azure não estiver conectado ao domínio, você pode:
- Crie uma identidade de aplicativo para seu aplicativo no Microsoft Entra ID.
- Associar um certificado à identidade do aplicativo.
- Modificar o aplicativo para adquirir um token para o Banco de Dados SQL do Azure fornecendo uma ID do cliente e um certificado.
Embora o certificado precise conter uma chave privada e precise ser implantado no computador que hospeda o seu aplicativo, pelo menos evite codificar um segredo de aplicativo na configuração ou no código do aplicativo. (Você precisará configurar o aplicativo com a impressão digital do certificado.)
DBAs ou outros usuários de ferramentas de administração do SQL de um computador não Azure não conectado ao domínio
Para usuários fora do Azure, é recomendável eliminar o uso de senhas, se possível. Você pode eliminar o uso de senhas com ferramentas SQL usando a autenticação integrada do Microsoft Entra. No entanto, as ferramentas precisam ser executadas em um computador conectado ao domínio, e o domínio precisa ter sido federado com o Microsoft Entra ID, o que não é o caso neste cenário.
Como o seu ambiente não atende aos pré-requisitos acima para a autenticação integrada, é recomendável usar a autenticação interativa do Microsoft Entra com a autenticação multifator, à qual a maioria das ferramentas do SQL dá suporte.
Aplicativos mais antigos em execução em um computador não Azure no qual você não pode alterar o driver ou a cadeia de conexão
Em cenários em que a cadeia de conexão ou o driver não podem ser alterados, atualmente não há uma opção para eliminar senhas. Esses aplicativos mais antigos precisam continuar usando a autenticação do SQL. Considere aprofundar-se nas restrições e em como elas podem ser removidas para usar uma abordagem mais segura e protegida para a autenticação de aplicativos.