Solução do Cenário 2 – Aplicativo crítico
Na unidade anterior, você trabalhou em um cenário que envolvia alta disponibilidade em um sistema de despacho de emergência. Nesta unidade, você examinará uma solução em potencial e alguns outros 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 seleção no endereçamento de um cenário geralmente identifica qual opção de implantação do SQL do Azure será mais adequada. Se você considerar o SLA (contrato de nível de serviço) sozinho, o requisito será de um SLA de 99,995%, que somente o banco de dados SQL do Azure pode fornecer. Para obter esse SLA, você precisa implantar a camada de serviço Comercialmente Crítica e habilitar o uso de zonas de disponibilidade.
Outro conjunto de decisões está relacionado a como habilitar a redundância geográfica e manter a alta disponibilidade em desastres. Embora a replicação geográfica e os grupos de failover automático sejam opções nesse caso, os grupos de failover automático habilitarão o failover do cliente se for necessário, sem alterar nenhuma cadeia de conexão. Essa configuração potencialmente pode ajudar a reduzir o tempo de inatividade para a atualização das cadeias de conexão dos aplicativos, pois ela não será necessária. Você também pode configurar consultas de monitoramento para verificar o status. Dessa forma, se algo der errado, você poderá até mesmo forçar um failover.
Nessa configuração, também é importante considerar a função da colocação. Para manter a alta disponibilidade, o seu aplicativo precisa estar o mais próximo possível do seu banco de dados, certamente na mesma região. Verifique se o seu aplicativo está implantado em ambas as regiões do grupo de failover automático, de modo que exista uma cópia redundante do aplicativo (por exemplo, um aplicativo Web). Se houver um failover, você poderá usar o Gerenciador de Tráfego do Azure para redirecionar o tráfego para o aplicativo na região secundária.
DBAs e dados confidenciais
Os coordenadores do sistema de despacho de emergência expressaram preocupação em proteger dados confidenciais (como histórico de saúde e outras informações pessoais), ao mesmo tempo que permitem que os DBAs façam o trabalho deles.
Para garantir que os DBAs não possam ver dados confidenciais armazenados em colunas específicas e que todo o acesso a tabelas que contêm dados confidenciais seja monitorado, algumas tecnologias do SQL do Azure podem ser aproveitadas. Usar a Auditoria do SQL é uma prática recomendada para monitorar o acesso, mas os DBAs ainda poderão ver os dados. É útil classificar os dados confidenciais usando a Classificação de Dados, pois eles serão rotulados e você poderá rastreá-los com a Auditoria do SQL. No entanto, quando eles estiverem implementados, os DBAs ainda poderão ver dados confidenciais. A máscara dinâmica de dados pode ser usada para ajudar a mascarar dados confidenciais, mas não é possível impedir que o db_owner exiba dados do usuário somente com permissões.
Se houver dados altamente confidenciais em um banco de dados, o Always Encrypted poderá ser usado para impedir com segurança até mesmo os db_owners de exibi-los. Você pode gerenciar as chaves Always Encrypted com separação de função, para que o administrador de segurança não acesse o banco de dados e o DBA não acesse as chaves físicas em um texto não criptografado. Ao usar essa estratégia em combinação com o monitoramento por meio da Auditoria do SQL, você pode monitorar, mascarar e rastrear o acesso a dados confidenciais, mesmo em DBAs com direitos de db_owner.
Os DBAs precisam que os dados confidenciais sejam mascarados, mas, ao mesmo tempo, é necessário que eles possam solucionar problemas de desempenho usando o portal do Azure e o SQL Server Management Studio ou Azure Data Studio. Eles também precisam da capacidade de criar usuários de banco de dados independente que precisam ser mapeados para entidades de segurança do Microsoft Entra.
Uma solução é criar um grupo do Microsoft Entra chamado DBA do SQL do para os DBAs em cada instância. Em seguida, atribua o grupo à função Colaborador do SQL Server do RBAC (controle de acesso baseado em função) do Azure. Por fim, você pode definir o grupo como o administrador do Microsoft Entra no servidor lógico.