Tarefas e capacidades de segurança

  • 10 minutos

Os serviços SQL Server e SQL do Azure são conhecidos pela importância que atribuem à segurança, especificamente como sendo de classe empresarial. Nesta unidade, você aprenderá sobre os vários recursos de segurança relacionados à segurança de rede e gerenciamento de acesso. Nas unidades que se seguem, você terá experiência prática com alguns desses recursos.

Diagrama de segurança de classe empresarial.

Segurança da rede

A primeira camada de segurança envolve a rede. Os recursos e tarefas de rede diferem entre o Banco de Dados SQL do Azure e a Instância Gerenciada SQL do Azure. Para obter informações sobre os recursos de rede da Instância Gerenciada SQL do Azure, consulte Arquitetura de conectividade para a Instância Gerenciada SQL do Azure.

Segurança de rede do Banco de Dados SQL do Azure

Ao proteger a sua rede da Base de Dados SQL do Azure, tem quatro opções principais:

  • Permitir acesso aos serviços do Azure
  • Utilizar regras de firewall
  • Utilizar regras de rede virtual
  • Utilizar o Azure Private Link

Além dessas opções principais, você tem a oportunidade de bloquear todo o acesso público (somente com o Azure Private Link) e a opção de forçar uma versão mínima de TLS (Transport Layer Security). 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 é utilizar o Private Link. As secções seguintes vão abordar as capacidades, a configuração e manutenção de cada opção.

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 acesso de serviços e recursos do Azure a este servidor como Sim. Se escolher esta opção, estará a fornecer a qualquer recurso de qualquer região ou subscrição a possibilidade de aceder ao seu recurso. Esta opção torna mais fácil começar a utilizar e ligar a Base de Dados SQL do Azure a outros serviços, como as Máquinas Virtuais do Azure, o Serviço de Aplicações do Azure ou até mesmo o Azure Cloud Shell, uma vez que está a permitir que todos os conteúdos que passem pelo Azure tenham potencial para se ligarem.

Diagrama de permissão de acesso aos serviços do Azure.

No entanto, permitir o acesso aos serviços do Azure não permite que quaisquer conteúdos fora do Azure (por exemplo, o seu ambiente no local) tenham acesso.

A configuração mais segura é definir Permitir acesso aos serviços e recursos do Azure a este servidor como Não, que bloqueia todas as conexões e redes, exceto aquelas que você adicionou explicitamente com as várias opções a seguir nas próximas seções.

Regras da firewall

A opção seguinte é aplicar as regras da firewall. Seus resultados podem ser semelhantes aos de Permitir o acesso de serviços e recursos do Azure a este servidor, exceto que, para cada serviço (na imagem a seguir, uma máquina virtual (VM)), 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, porque você pode adicionar as regras para máquinas e aplicativos em seu ambiente local.

Diagrama de regras de firewall.

Para obter conectividade no Azure, também pode permitir o acesso a serviços do Azure e, em seguida, adicionar regras de firewall apenas para a conetividade no local. Como mencionado anteriormente, permitir o acesso de serviços e recursos do Azure a este servidor não é tão seguro, porque permite todo o tráfego do Azure. Recomendamos que você use regras de firewall exclusivamente.

Vejamos o exemplo anterior com as regras de firewall configuradas. A partir de uma ferramenta que ofereça suporte ao Transact-SQL (T-SQL), como o SQL Server Management Studio (SSMS), você pode executar a seguinte 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 seria 203.0.113.1. Este é o endereço IP público da VM do Azure. Apesar de estarmos a utilizar regras da firewall, todas as ligações a serem efetuadas são públicas.

Regras de rede virtual

Se você quiser usar apenas regras de firewall, pode ser complicado configurá-lo. 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 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 configurar o acesso de uma rede virtual com uma regra de rede virtual, todos os recursos dessa rede virtual poderão aceder ao servidor lógico da Base de Dados SQL do Azure. Tal pode simplificar o desafio de configurar o acesso a todos os endereços IP estáticos e dinâmicos que precisam de aceder aos dados. As regras de rede virtual permitem-lhe especificar uma ou mais redes virtuais, ao abranger todos os recursos nas mesmas. Também pode começar a aplicar tecnologias de rede virtual para ligar redes entre regiões no Azure e no local.

Diagrama de regras de rede virtual.

Neste exemplo, tal como na secção anterior, pode executar a mesma consulta a partir 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 seria agora 10.0.0.2, o endereço IP privado da VM do Azure. Este resultado aproxima-o de efetuar ligações privadas ao seu servidor lógico da Base de Dados SQL do Azure, pois agora os recursos são ligados através da rede virtual.

Outra estratégia comum para analisar a sua ligação é examinar a hierarquia DNS (Sistema de Nomes de Domínio). Na mesma VM do Azure, pode executar o seguinte comando numa linha de comandos:

nslookup aw-server.database.windows.net

Ao utilizar este comando, pode obter detalhes relacionados com a infraestrutura de DNS. Os 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:    203.0.113.1
Aliases:    aw-server.database.windows.net
            dataslice2.eastus.database.windows.net

Sob a resposta não autorizada, há algumas coisas importantes a serem observadas:

  • Nome: O ponto de extremidade que começa com cr2 faz parte da hierarquia DNS pública. Sem entrar muito na hierarquia, digamos que cr2 é 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 através do endereço IP privado da sua VM, o endereço IP público da sua VM ainda está sendo usado para se conectar em alguma capacidade.
  • Aliases: Aliases são vários pontos dentro da hierarquia DNS, neste caso, os dados específicos "fatia" e ponto de extremidade ao qual você se conecta.

Nota

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 com os recursos da plataforma Azure. Este aplica-se a todas as regiões e todas as clouds nacionais e permanecerá assim.

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.

Você viu como configurar a rede mais segura usando seu banco de dados no Banco de Dados SQL do Azure com o ponto de extremidade público. Este método para proteger uma base de dados na Base de Dados SQL é utilizado há anos. No entanto, em 2019, o Azure começou a avançar para um conceito de ligação privada, que é mais semelhante à forma como o Azure SQL Managed Instance é implementado. Com o Azure Private Link, você pode se conectar ao seu banco de dados no Banco de Dados SQL e em várias outras ofertas de plataforma como serviço (PaaS) usando um ponto de extremidade privado. Isto significa que tem um endereço IP privado numa rede virtual específica.

Diagrama de ligação de um ponto final privado.

No exemplo anterior, você notará que a infraestrutura de rede geral não foi alterada e ainda pode aplicar as estratégias de conectividade de rede virtual das regras de rede virtual. No entanto, não terá de criar regras de rede virtual. Os recursos que precisam de se ligar ao servidor de bases de dados têm de ter acesso à rede virtual onde reside o ponto final. No exemplo, o ponto de extremidade é SQLDBVNet-EUS. Apenas as ligações que passam pelo ponto final privado têm acesso e todas as outras ligações (por exemplo, a partir da Internet) são negadas.

Ao continuar com este exemplo, na VM do Azure na rede SQLDBVNet-EUSvirtual, 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 da sua rede virtual, as ligações à Base de Dados SQL do Azure a partir da sua VM parecerão vir através do endereço IP privado da sua VM. Este é o mesmo resultado que viu com as regras de rede virtual.

No entanto, poderá querer utilizar a linha de comandos para analisar a hierarquia DNS, ao utilizar o seguinte comando:

nslookup aw-server.database.windows.net

Se utilizar o comando anterior, os seus resultados serão ligeiramente diferentes com o ponto final privado 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

Sob a resposta não autorizada, há algumas coisas importantes a serem observadas:

  • Nome: Observe que você não está mais apontando para a hierarquia de DNS pública, apenas para o DNS de Link Privado. Tal significa que são reveladas menos informações sobre o seu servidor de bases de dados.
  • Endereços: para regras de rede virtual, o endereço retornado é o endereço IP público da sua VM, mas agora deve ser um ou mais endereços IP privados dentro da hierarquia de Link Privado (um é o ponto de extremidade privado do Banco de Dados SQL do Azure).
  • Aliases: Como no campo Nome, nada está relacionado à hierarquia 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 estiver 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 Private Link de conexão com o Banco de Dados SQL do Azure (ou seja, sem firewall ou regras de rede virtual), as informações são processadas da seguinte maneira:

  • aw-server.database.windows.net
    • Resolvido por serviço a aw-server.privatelink.database.net
      • Resolvido por serviço a 10.0.0.5 (o endereço IP do seu ponto final privado)

Além disso, o serviço irá impedi-lo de se ligar diretamente ao utilizar algo que não aw-server.database.windows.net.

Gestão de acesso

Depois de definir o acesso à rede, a próxima camada a ser considerada é o gerenciamento de acesso.

Controlo 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). O RBAC está atualmente dissociado da segurança SQL do Azure, mas você pode pensar nele como direitos de segurança fora do seu banco de dados no Banco de Dados SQL, com um escopo que inclui assinatura, grupo de recursos e recurso. Estes direitos aplicam-se a operações no portal do Azure, na CLI do Azure e no Azure PowerShell. O RBAC permite a separação de deveres entre implementação, gestão e utilização.

As funções internas estão disponíveis para reduzir a necessidade de funções RBAC de nível superior, como Proprietário ou Colaborador. Efetivamente, você pode usar essas funções para que determinadas pessoas implantem recursos SQL do Azure (ou gerenciem políticas de segurança), mas concedam a outros usuários acesso real para usar ou gerenciar o banco de dados. Por exemplo, um Colaborador do SQL Server pode implantar um servidor e atribuir um usuário para ser o administrador do servidor e dos bancos de dados. As funções internas do Banco de Dados SQL do Azure incluem:

  • Colaborador do Banco de Dados SQL: pode criar e gerenciar bancos de dados, mas não pode acessar o banco de dados (por exemplo, não pode se conectar e ler dados)
  • SQL Security Manager: pode gerenciar políticas de segurança para bancos de dados e instâncias (como auditoria), mas não pode acessá-las
  • Colaborador do SQL Server: pode gerenciar servidores e bancos de dados, mas não pode acessá-los.

Autenticação

Durante uma implantação de servidor lógico do Banco de Dados SQL do Azure, você pode especificar o seguinte método de autenticação:

  • Usar somente a autenticação do Microsoft Entra
  • Usar autenticação SQL e Microsoft Entra
  • Usar autenticação 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 de servidor para o servidor lógico do Banco de Dados SQL do Azure.

Se estiver a migrar uma carga de trabalho que necessite de autenticação do Windows ou se a sua organização utilizar o Microsoft Entra ID, pode utilizar o Microsoft Entra ID. Você pode atribuir um administrador de servidor do Microsoft Entra usando o portal ou as ferramentas de linha de comando.

A autenticação somente Microsoft Entra-é a opção padrão ao configurar um novo servidor. Os logons de servidor foram introduzidos para permitir entidades de servidor 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 a partir de usuários, grupos e entidades de serviço do Microsoft Entra. Ao usar a autenticação somente Microsoft Entra, você pode criar logons de autenticação SQL e os logons existentes permanecerão. No entanto, apenas os logins e usuários de autenticação do Microsoft Entra podem se conectar ao servidor lógico. Para saber mais sobre a autenticação somente Microsoft Entra, consulte Autenticação somente Microsoft Entra-only com Azure SQL.

Captura de ecrã a mostrar a definição do administrador do Microsoft Entra.

Dependendo de como sua organização configurou a instância do Microsoft Entra, você pode se conectar a ela usando qualquer um dos três métodos a seguir (por exemplo, no SSMS):

  • Microsoft Entra ID - Integrado: um método não interativo que você pode usar se estiver conectado ao Windows com 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 com um nome principal do Microsoft Entra usando o domínio gerenciado pelo Microsoft Entra ID. A partir da documentação:

    Isso pode se aplicar a usuários nativos ou federados do Microsoft Entra. Um usuário nativo é aquele criado explicitamente no Microsoft Entra ID e sendo autenticado usando nome de usuário e 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 usado quando um usuário deseja usar sua credencial do Windows, mas sua máquina local não está associada ao domínio (por exemplo, usando um acesso remoto). Nesse caso, um usuário do Windows pode indicar sua conta de domínio e senha e pode se autenticar no Banco de Dados SQL ou no Azure Synapse Analytics (anteriormente SQL DW) usando credenciais federadas.

  • Microsoft Entra ID - Universal with multifactor authentication (MFA): Um método interativo que protege o acesso aos dados enquanto atende à demanda de uma organização por um processo de logon único com a autenticação multifator Microsoft Entra.

Para o Banco de Dados SQL do Azure, há algumas nuances. Você pode ter logins que existem no banco de dados virtual master , usuários de banco de dados e até mesmo usuários de banco de dados contidos para contas do Microsoft Entra (recomendado). Embora o administrador do servidor do Banco de Dados SQL do Azure essencialmente tenha sysadmin direitos, você pode criar administradores mais limitados usando funções de nível de servidor ou banco de dados. Duas funções de nível de banco de dados estão disponíveis para o Banco de dados SQL que só existem no banco de dados virtual master :

  • loginmanager: uma função no nível de banco de dados que permite que os membros criem logons para o servidor de banco de dados
  • dbmanager: uma função no nível de banco de dados que permite aos membros criar e excluir 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, quando configurar a autenticação e autorização, tem de seguir quatro diretrizes:

  • Implementar com um administrador de servidor
  • Criar outros administradores conforme seja necessário
  • Os administradores podem criar utilizadores
  • Conceder acesso tal como o faria no SQL Server

Outras capacidades

Depois de experimentar algumas das funcionalidades de rede e autenticação, mais adiante no módulo irá examinar outras funcionalidades (e respetivas tarefas relacionadas) de proteção de dados, monitorização, registo e auditoria.

Verificação de conhecimento

1.

Qual é a forma recomendada e mais segura de proteger a sua rede da Base de Dados SQL do Azure?

2.

Considere o exemplo da unidade em que o endereço IP público da VM do Azure é 203.0.113.1 e o endereço IP privado da VM do Azure é 10.0.0.2. Quando utiliza as regras de rede virtual para configurar o acesso de rede à Base de Dados SQL do Azure, o que será devolvido a partir de SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;?