Solução do cenário 1 – Arquitetar o dimensionamento global e o acesso seguro

  • 10 minutos

Na unidade anterior, trabalhou num cenário acerca do dimensionamento global de uma rede de entrega de conteúdos. Nesta unidade, vai rever uma solução potencial e alguns fatores a ter em conta.

Ao rever, deve comparar a solução disponibilizada com a que desenvolveu na unidade anterior. Muitas vezes, existe mais do que uma solução correta para qualquer problema, mas há sempre vantagens e desvantagens. Que itens na sua solução diferem dos propostos? Existe algo na sua solução que possa repensar? Existe algo na solução disponibilizada que considere que a sua solução aborda melhor?

Opção e configuração da implementação

A primeira decisão a considerar é a opção de implementação do Azure SQL que deve selecionar. Apesar de o SQL Server funcionar numa máquina virtual (VM) do Azure, uma oferta de plataforma como serviço (PaaS) poderá ser mais adequada e com menos sobrecarga de gestão.

O cliente está a utilizar o common language runtime (CLR), que é uma funcionalidade no âmbito de instâncias. O Azure SQL Managed Instance é a única opção de implementação PaaS que suporta funcionalidades com âmbito de instâncias, como o CLR, o Service Broker e o Correio de Base de Dados. Por esta razão, o Azure SQL Managed Instance pode permitir ao cliente migrar para uma oferta PaaS sem ter de reescrever as aplicações CLR para uma solução compatível com a Base de Dados SQL do Azure (como tarefas de base de dados elásticas).

A próxima decisão a tomar envolve o escalão de serviço. Uma vez que o cliente pretende isolar as cargas de trabalho de leitura e escrita, a utilização do escalão de serviço Crítico para a Empresa será a forma mais simples de o conseguir. O escalão de serviço Crítico para a Empresa tem um grupo de disponibilidade AlwaysOn a ser executado em segundo plano. Uma dessas réplicas secundárias pode ser utilizada para cargas de trabalho só de leitura.

O escalão Crítico para a Empresa é apenas metade da configuração necessária para separar cargas de trabalho de leitura e escrita. O cenário afirma que o cliente tem de conseguir dimensionar em múltiplas regiões com múltiplas consultas em simultâneo, enquanto isola as cargas de trabalho de leitura e escrita.

As duas opções que podem potencialmente enfrentar este desafio são os grupos de georreplicação e de ativação pós-falha automática. No entanto, a georreplicação não é atualmente suportada no Azure SQL Managed Instance. Assim, a utilização de um grupo de ativação pós-falha automática é a única opção que pode ajudar este cenário a obter um dimensionamento de leitura global.

Uma vez que o cliente está a utilizar grupos de ativação pós-falha automática, se precisa ou não do escalão de serviço Crítico para a Empresa dependerá do número de pontos finais só de leitura que a carga de trabalho analítica requer. Com um grupo de ativação pós-falha automática no escalão de serviço Crítico para a Empresa, o cliente obteria três pontos finais legíveis:

  • Uma réplica secundária do grupo de disponibilidade da região primária
  • O secundário do grupo de ativação pós-falha (que é a réplica primária da base 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 analítica não precisar de todas estas réplicas legíveis, a utilização do escalão Fins Gerais pode ser uma solução mais rentável.

Selecionar os métodos de autenticação mais adequados

A outra parte deste cenário envolve a determinação da melhor forma de cada aplicação ou pessoa se ligar à solução, dada a necessidade de criar e tirar partido das tecnologias mais seguras possíveis. Se dividir o cenário, existem quatro clientes separados que precisarão de acesso ao Azure SQL Managed Instance:

  • Aplicação em execução numa VM do Azure
  • Aplicação em execução numa máquina virtual não pertencente ao Azure que esteja associada ao domínio
  • Os DBAs ou outros utilizadores de ferramentas de administração SQL (SQL Server Management Studio, Azure Data Studio, PowerShell) em máquinas virtuais não pertencentes ao Azure que não estejam associadas ao domínio
  • Aplicações mais antigas em execução numa máquina virtual não pertencente ao Azure onde não pode alterar o controlador ou a cadeia de ligação

Vamos analisar estes clientes em termos de como pode escolher o método de autenticação e conhecer algumas considerações e restrições adicionais.

Aplicação em execução numa VM do Azure

As identidades geridas dos recursos do Azure são, em geral, a forma recomendada de autenticação sem palavra-passe para aplicações em execução em máquinas virtuais do Azure.

Aplicação em execução numa máquina virtual não pertencente ao Azure que esteja associada ao domínio

Para máquinas virtuais não Azure, a utilização de identidades geridas não é uma opção. A autenticação integrada via ID do Microsoft Entra é o método de autenticação recomendado para aplicativos executados em máquinas ingressadas no domínio fora do Azure, supondo que o domínio tenha sido federado com a ID do Microsoft Entra.

Se a máquina virtual não pertencente ao Azure não estiver associada ao domínio, poderá:

  1. Crie uma identidade de aplicativo para seu aplicativo no Microsoft Entra ID.
  2. Associar um certificado à identidade da aplicação.
  3. Modificar a sua aplicação para adquirir um token para a Base de Dados SQL do Azure, ao fornecer um ID de cliente e um certificado.

Embora o certificado tenha de conter uma chave privada e esta tenha de ser implementada na máquina que aloja a aplicação, pelo menos evita a codificação de um segredo de aplicação no código ou configuração da aplicação. (Terá de configurar a aplicação com o thumbprint do certificado).

DBAs ou outros utilizadores das ferramentas de administrador SQL de uma máquina virtual não pertencente ao Azure que não esteja associada ao domínio

Para utilizadores fora do Azure, é melhor eliminar a utilização de palavras-passe, 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 devem ser executadas em uma máquina associada ao domínio e o domínio deve ter sido federado com o ID do Microsoft Entra, o que não é o caso para este cenário.

Como o ambiente não atende aos pré-requisitos para autenticação integrada, recomendamos que você use a autenticação interativa do Microsoft Entra com autenticação multifator, que a maioria das ferramentas SQL suporta.

Aplicações mais antigas em execução numa máquina virtual não pertencente ao Azure onde não pode alterar o controlador ou a cadeia de ligação

Em cenários em que o controlador ou a cadeia de ligação não possam ser alterados, não existe atualmente uma opção para eliminar as palavras-passe. Estas aplicações mais antigas têm de continuar a utilizar a autenticação SQL. Pode considerar analisar mais aprofundadamente as restrições e como podem ser levantadas de forma a implementar uma abordagem mais segura para a autenticação das aplicações.