Tarefas e funcionalidades de segurança
O SQL Server e os serviços do SQL do Azure são conhecidos pela importância que dão para a segurança, especialmente a de classe corporativa. Nesta unidade, você aprenderá sobre os vários recursos de segurança relacionados à segurança de rede e ao gerenciamento de acesso. Nas unidades a seguir, você terá uma experiência prática com alguns desses recursos.
Segurança de rede
A primeira camada de segurança envolve a rede. As tarefas e os recursos de rede são diferentes no Banco de Dados SQL do Azure e na Instância Gerenciada de SQL do Azure. Para obter informações sobre os recursos de rede da Instância Gerenciada de SQL do Azure, consulte Arquitetura de conectividade para Instância Gerenciada de SQL do Azure.
Segurança de rede do Banco de dados do SQL do Azure
Quando estiver protegendo a sua rede do Banco de Dados SQL do Azure, você terá quatro opções principais:
- Permitir acesso aos serviços do Azure
- Usar regras de firewall
- Usar regras de rede virtual
- Usar o Link Privado do Azure
Além dessas opções principais, você pode bloquear todo o acesso público (somente com o Link Privado do Azure) e tem a opção de forçar uma versão mínima de protocolo TLS. O método menos seguro, mas o mais fácil de configurar, é permitir o acesso aos serviços do Azure. O método mais seguro é usar um Link Privado. As seções a seguir abordarão os recursos para cada opção e como configurar e manter cada uma.
Permitir acesso aos serviços do Azure
Durante a implantação do Banco de Dados SQL do Azure, você tem a opção de definir Permitir que os serviços e recursos do Azure acessem esse servidor como Sim. Se escolher essa opção, você permitirá que qualquer recurso de qualquer região ou assinatura consiga acessar o seu recurso. Essa opção torna mais fácil colocar em funcionamento e conectar o Banco de Dados SQL do Azure a outros serviços, como às Máquinas Virtuais do Azure, ao Serviço de Aplicativo do Azure ou até mesmo ao Azure Cloud Shell, pois você está permitindo que qualquer item proveniente do Azure tenha o potencial de se conectar.
No entanto, permitir o acesso aos serviços do Azure não permite que nada fora do Azure (por exemplo, o seu ambiente local) tenha acesso.
A configuração mais segura é definir Permitir que os serviços e recursos do Azure acessem esse servidor como Não, o que bloqueia todas as conexões e redes, exceto as que você adicionou explicitamente com as várias opções a seguir nas próximas seções.
Regras de firewall
A sua próxima opção é aplicar regras de firewall. Seus resultados podem ser semelhantes aos de Permitir acesso a serviços e recursos do Azure a esse servidor, exceto que, para cada serviço (na imagem a seguir, uma VM (máquina virtual)), você precisará adicionar uma regra de firewall exclusiva para permitir que ele se conecte. As regras de firewall também permitem que seu ambiente local se conecte ao recurso do Banco de Dados SQL do Azure, pois você pode adicionar as regras para computadores e aplicativos em seu ambiente local.
Para obter conectividade no Azure, você também pode permitir o acesso aos serviços do Azure e, em seguida, adicionar as regras de firewall apenas para a sua conectividade local. Como mencionado anteriormente, Permitir que os serviços e recursos do Azure acessem este servidor não é tão seguro, pois permite todo o tráfego do Azure. Recomendamos que você use as regras de firewall exclusivamente.
Vejamos o exemplo anterior com as regras de firewall configuradas. Em uma ferramenta com suporte a T-SQL (Transact-SQL), como SSMS (SQL Server Management Studio), você pode executar a seguinte consulta na sua VM do Azure na rede virtual SQLDBVNET-EUS:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
O resultado deve ser 174.17.218.16. Esse é o endereço IP público da VM do Azure. Mesmo que estejamos usando regras de firewall, todas as conexões que estão sendo feitas são públicas.
Regras de rede virtual
Se você quiser usar apenas regras de firewall, isso pode ser complicado de configurar. Usar apenas regras de firewall significa que você precisa especificar um intervalo de endereços IP para todas as suas conexões, que às vezes podem ter endereços IP dinâmicos. Uma alternativa muito mais fácil é usar as regras de rede virtual para estabelecer e gerenciar o acesso de redes específicas que contêm VMs ou outros serviços que precisam acessar os dados.
Se você configurar o acesso de uma rede virtual com uma regra da rede virtual, todos os recursos nessa rede virtual poderão acessar o servidor lógico do Banco de Dados SQL do Azure. Isso pode simplificar o desafio de configurar o acesso a todos os endereços IP estáticos e dinâmicos que precisam acessar os dados. Usando as regras de rede virtual, você pode especificar uma ou várias redes virtuais, que abrangem todos os recursos dentro delas. Você também pode começar a aplicar as tecnologias de rede virtual para conectar redes nas regiões locais e do Azure.
Neste exemplo, assim como na consulta anterior, você pode executar a mesma consulta da sua VM do Azure na rede virtual SQLDBVNET-EUS:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
O resultado agora seria 10.0.0.2, que é o endereço IP privado da VM do Azure. Esse resultado faz com que você esteja uma etapa mais perto de fazer conexões privadas ao servidor lógico do Banco de Dados SQL do Azure, já que agora os recursos estão se conectando por meio da rede virtual.
Outra estratégia comum para analisar a sua conexão é examinar a hierarquia de DNS (Sistema de Nomes de Domínio). Na mesma VM do Azure, em um prompt de comando, você pode executar o seguinte comando:
nslookup aw-server.database.windows.net
Usando esse comando, você pode obter detalhes relacionados à infraestrutura de DNS. Seus resultados seriam semelhantes aos seguintes:
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: cr2.eastus1-a.control.database.windows.net
Address: 174.17.218.16
Aliases: aw-server.database.windows.net
dataslice2.eastus.database.windows.net
Na resposta não autoritativa, há algumas coisas importantes a se observar:
- Nome: O ponto de extremidade que começa com
cr2faz parte da hierarquia de DNS público. Sem nos estendermos sobre o tópico da hierarquia, vamos supor quecr2é o anel de controle 2 e que há várias "fatias" de dados abaixo dele. - Endereço: O endereço IP retornado aqui deve corresponder ao endereço IP público da sua VM do Azure. Embora uma ferramenta como o salto final do SSMS possa ser executada por meio do endereço IP privado da VM, o endereço IP público da VM ainda está sendo usado para se conectar em alguma capacidade.
- Aliases: Os aliases são vários pontos dentro da hierarquia DNS; nesse caso, a "fatia" e o ponto de extremidade específicos ao qual você se conecta.
Observação
No bloco de saída anterior, Endereço: 168.63.129.16 é um endereço IP público virtual usado para facilitar um canal de comunicação para os recursos da plataforma do Azure. Ele se aplica a todas as regiões e em todas as nuvens nacionais e não será alterado.
Embora a conexão por meio do SSMS venha por meio do endereço IP privado da VM do Azure, você ainda está se conectando por meio de um ponto de extremidade público.
Link Privado para um Banco de Dados SQL do Azure
Você viu como configurar a rede mais segura usando o seu banco de dados no Banco de Dados SQL do Azure com o ponto de extremidade público. Esse método de proteção do banco de dados no Banco de Dados SQL é usado há anos. No entanto, em 2019, o Azure começou a migrar para um conceito de link privado, que é mais semelhante ao modo como a Instância Gerenciada de SQL do Azure é implantada. Com o Link Privado do Azure, você pode se conectar ao banco de dados no Banco de Dados SQL e a várias outras ofertas de plataforma como serviço (SaaS) usando um ponto de extremidade privado. Isso significa que ele tem um endereço IP privado em uma rede virtual específica.
No exemplo acima, você observará que a infraestrutura de rede geral não foi alterada e você ainda pode aplicar as estratégias de conectividade de rede virtual nas regras de rede virtual. No entanto, você não precisará criar regras de rede virtual. Os recursos que precisam se conectar ao servidor de banco de dados precisam ter acesso à rede virtual em que reside o ponto de extremidade. No exemplo, o ponto de extremidade é SQLDBVNet-EUS. Somente as conexões que passam pelo ponto de extremidade privado têm acesso e todas as outras conexões (por exemplo, da Internet) são negadas.
Ainda nesse exemplo, na VM do Azure na rede virtual SQLDBVNet-EUS, você pode executar novamente o seguinte comando T-SQL:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
O resultado agora seria 10.0.0.2, que é o endereço IP privado da VM do Azure neste exemplo. Ao adicionar acesso de sua rede virtual, as conexões com o Banco de Dados SQL do Azure da VM aparecerão por meio do endereço IP privado da VM. Esse é o mesmo resultado que você viu nas regras de rede virtual.
No entanto, você pode querer usar o prompt de comando para examinar a hierarquia de DNS com o seguinte comando:
nslookup aw-server.database.windows.net
Se você usar o comando anterior, os seus resultados serão um pouco diferentes quando o ponto de extremidade privado estiver configurado:
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: aw-server.privatelink.database.windows.net
Address: 10.0.0.5
Aliases: aw-server.database.windows.net
Na resposta não autoritativa, há algumas coisas importantes a se observar:
- Nome: Observe que você não está mais apontando para a hierarquia de DNS público, somente para o DNS de Link Privado. Isso significa que menos informações são reveladas sobre o seu servidor de banco de dados.
- Endereços: Para regras de rede virtual, o endereço retornado é o endereço IP público da VM, mas agora deve ser um ou mais endereços IP privados dentro da hierarquia do Link Privado (um é o ponto de extremidade privado do Banco de Dados SQL do Azure).
- Aliases: Semelhante ao campo Nome, nada é relacionado à hierarquia de DNS, exceto que você ainda pode se conectar ao nome do servidor (por exemplo,
aw-server.database.windows.net).
Uma coisa que você pode estar se perguntando se você está se conectando ao ponto de extremidade privado é por que você ainda está usando o mesmo nome de servidor? No back-end, quando você usa apenas o método de Link Privado de conexão com o Banco de Dados SQL do Azure (ou seja, sem regras de rede virtual ou firewall), as informações são processadas da seguinte maneira:
aw-server.database.windows.net- Resolvido pelo serviço para
aw-server.privatelink.database.net- Resolvido pelo serviço para
10.0.0.5(o endereço IP do ponto de extremidade privado)
- Resolvido pelo serviço para
- Resolvido pelo serviço para
Além disso, o serviço impedirá que você se conecte diretamente se usar um método diferente de aw-server.database.windows.net.
Gerenciamento de acesso
Depois de ter resolvido o acesso à rede, a próxima camada a ser considerada é o gerenciamento de acesso.
Controle de acesso baseado em funções
Todos os tipos de operações do Azure para o Banco de Dados SQL do Azure são controlados por meio do RBAC (controle de acesso baseado em função). Atualmente, o RBAC é dissociado da Segurança do SQL do Azure, mas você pode considerá-lo como direitos de segurança fora do seu banco de dados no Banco de Dados SQL ou da instância gerenciada de SQL com um escopo que inclui assinatura, recurso e grupo de recursos. Os direitos se aplicam às operações no portal do Azure, na CLI do Azure e no Azure PowerShell. O RBAC permite a separação de tarefas entre implantação, gerenciamento e uso.
Funções internas estão disponíveis para reduzir a necessidade de funções de RBAC de nível superior, como Proprietário ou Colaborador. Efetivamente, você pode usar essas funções para que determinados indivíduos implantem recursos do SQL do Azure (ou gerenciem políticas de segurança), mas permitam a outros usuários acesso real ao usuário ou gerenciem o banco de dados. Por exemplo, um colaborador do SQL Server pode implantar um servidor e designar um usuário como o administrador do servidor e dos bancos de dados. As funções internas do Banco de Dados SQL do Azure incluem:
- Colaborador do DB SQL: Pode criar e gerenciar bancos de dados, mas não acessar o banco de dados (por exemplo, não pode se conectar a dados e lê-los)
- Gerenciador de Segurança do SQL: pode gerenciar políticas de segurança para bancos de dados e instâncias (como auditoria), mas não acessá-las
- Colaborador do SQL Server: Pode gerenciar servidores e bancos de dados, mas não acessá-los.
Autenticação
Durante uma implantação do servidor lógico do Banco de Dados SQL do Azure, você pode especificar o seguinte Método de autenticação:
- Usar apenas a autenticação do Microsoft Entra
- Usar a autenticação do SQL e do Microsoft Entra
- Usar a autenticação do SQL
O administrador do servidor precisa ser definido durante a implantação. Para bancos de dados no Banco de Dados SQL do Azure, o administrador do servidor é uma entidade de segurança no nível do servidor para o servidor lógico do Banco de Dados SQL do Azure.
Se você estiver migrando uma carga de trabalho que precisa de autenticação do Windows ou se sua organização usar o Microsoft Entra ID, você pode usar o Microsoft Entra ID. Você pode designar um administrador de servidor do Microsoft Entra usando o portal ou as ferramentas de linha de comando.
A autenticação somente do Microsoft Entra é a opção padrão ao configurar um novo servidor. Os logons de servidor foram introduzidos para permitir entidades de segurança do servidor do Microsoft Entra, que são logons no banco de dados virtual master de um Banco de Dados SQL. Você pode criar logons do Microsoft Entra de usuários, grupos e entidades de serviço do Microsoft Entra. Ao usar a autenticação somente do Microsoft Entra, você pode criar logons de autenticação SQL e os logons existentes permanecerão. No entanto, os usuários e logons de autenticação somente do Microsoft Entra podem se conectar ao servidor lógico. Para saber mais sobre a autenticação somente do Microsoft Entra, confira Autenticação somente do Microsoft Entra com o SQL do Azure.
Dependendo de como a sua organização configurou a instância do Microsoft Entra, você poderá se conectar a ela usando qualquer um dos seguintes três métodos (por exemplo, no SSMS):
Microsoft Entra – integrado: Um método não interativo, que poderá ser usado se você estiver conectado ao Windows usando as suas credenciais do Microsoft Entra de um domínio federado.
Microsoft Entra ID – Senha: Um método não interativo que permite que você se conecte a um nome de entidade de segurança do Microsoft Entra usando o domínio gerenciado pelo Microsoft Entra ID. Na documentação:
Isso pode se aplicar aos usuários nativos ou federados do Microsoft Entra. Um usuário nativo é criado explicitamente no Microsoft Entra ID e é autenticado usando o nome de usuário e a senha, enquanto um usuário federado é um usuário do Windows cujo domínio é federado com o Microsoft Entra ID. O último método (usando nome de usuário e senha) pode ser utilizado quando um usuário deseja usar sua credencial do Windows, mas seu computador local não está associada ao domínio (por exemplo, usando um acesso remoto). Nesse caso, um usuário do Windows pode indicar a conta e a senha de domínio e pode autenticar no Banco de Dados SQL ou Azure Synapse Analytics (anteriormente SQL DW) usando credenciais federadas.
Microsoft Entra ID – universal com a autenticação multifator (MFA): Um método interativo que protegerá o acesso aos dados enquanto atende à demanda da organização por um processo de conexão única com a autenticação multifator do Microsoft Entra.
Para o Banco de Dados SQL do Azure, há algumas nuances. Você pode ter logons que existem no banco de dados virtual master, usuários de banco de dados e até mesmo usuários de banco de dados independentes para contas do Microsoft Entra (recomendado). Embora o administrador do servidor do Banco de Dados SQL do Azure tenha, essencialmente, direitos de sysadmin, você pode criar administradores mais limitados usando funções de nível de banco de dados ou servidor. Duas funções de nível de banco de dados estão disponíveis para Banco de Dados SQL que existem apenas no banco de dados virtual master:
- loginmanager: Uma função no nível do banco de dados que permite que os membros criem logons para o servidor de banco de dados
- dbmanager: Uma função no nível do banco de dados que permite que os membros criem e excluam bancos de dados para o servidor de banco de dados
Aqui está uma lista de funções de nível de servidor no Banco de Dados SQL do Azure:
- ##MS_DatabaseConnector##
- ##MS_DatabaseManager##
- ##MS_DefinitionReader##
- ##MS_LoginManager##
- ##MS_SecurityDefinitionReader##
- ##MS_ServerStateReader##
- ##MS_ServerStateManager##
Por fim, ao instalar e configurar a autenticação e a autorização, há quatro diretrizes que você pode seguir:
- Implantar com um administrador de servidor
- Criar outros administradores conforme necessário
- Os administradores podem criar usuários
- Conceder acesso exatamente como você faria no SQL Server
Outras funcionalidades
Depois praticar algumas das funcionalidades de rede e de autenticação, posteriormente no módulo você examinará outras funcionalidades (e as tarefas relacionadas) para proteção de dados, monitoramento, registro em log e auditoria.