Proteger um pool SQL dedicado (anteriormente SQL DW) no Azure Synapse Analytics

Este artigo irá orientá-lo através das noções básicas de proteção do seu pool SQL dedicado (anteriormente SQL DW). Em particular, este artigo apresenta recursos para limitar o acesso, proteger dados e monitorar atividades usando o pool SQL dedicado (anteriormente SQL DW).

Segurança da Ligação

A Segurança da Ligação diz respeito à forma como restringe e protege as ligações à sua base de dados através de regras de firewall e de encriptação da ligação.

As regras de firewall são usadas pelo servidor SQL lógico e seus bancos de dados para rejeitar tentativas de conexão de endereços IP que não foram explicitamente aprovados. Para permitir conexões do endereço IP público do seu aplicativo ou máquina cliente, você deve primeiro criar uma regra de firewall no nível do servidor usando o portal do Azure, a API REST ou o PowerShell.

Como prática recomendada, você deve restringir ao máximo os intervalos de endereços IP permitidos pelo firewall no nível do servidor. Para aceder ao conjunto SQL dedicado (anteriormente SQL DW) a partir do computador local, certifique-se de que a firewall na rede e no computador local permite a comunicação de saída na porta TCP 1433.

O pool SQL dedicado (anteriormente SQL DW) usa regras de firewall IP no nível do servidor. Ele não suporta regras de firewall IP no nível de banco de dados. Para obter mais informações, consulte Regras de firewall do Banco de Dados SQL do Azure

As conexões com seu pool SQL dedicado (anteriormente SQL DW) são criptografadas por padrão. A modificação das configurações de conexão para desabilitar a criptografia é ignorada.

Autenticação

A autenticação diz respeito à forma como prova a sua identidade quando se liga à base de dados. O pool SQL dedicado (anteriormente SQL DW) atualmente oferece suporte à Autenticação do SQL Server com um nome de usuário e senha e com a ID do Microsoft Entra.

Quando você criou o servidor para seu banco de dados, você especificou um login "administrador do servidor" com um nome de usuário e senha. Usando essas credenciais, você pode autenticar em qualquer banco de dados nesse servidor como o proprietário do banco de dados, ou "dbo" por meio da Autenticação do SQL Server.

No entanto, como prática recomendada, os usuários da sua organização devem usar uma conta diferente para autenticar. Dessa forma, você pode limitar as permissões concedidas ao aplicativo e reduzir os riscos de atividades maliciosas caso o código do aplicativo esteja vulnerável a um ataque de injeção de SQL.

Para criar um usuário autenticado do SQL Server, conecte-se ao banco de dados mestre no servidor com o logon de administrador do servidor e crie um novo logon de servidor. É uma boa ideia também criar um usuário no banco de dados mestre. A criação de um usuário no mestre permite que um usuário faça login usando ferramentas como o SSMS sem especificar um nome de banco de dados. Ele também permite que eles usem o explorador de objetos para exibir todos os bancos de dados em um servidor.

-- Connect to master database and create a login
CREATE LOGIN ApplicationLogin WITH PASSWORD = 'Str0ng_password';
CREATE USER ApplicationUser FOR LOGIN ApplicationLogin;

Em seguida, conecte-se ao pool SQL dedicado (anteriormente SQL DW) com o login de administrador do servidor e crie um usuário de banco de dados com base no logon do servidor que você criou.

-- Connect to the database and create a database user
CREATE USER ApplicationUser FOR LOGIN ApplicationLogin;

Para conceder permissão a um usuário para executar operações adicionais, como criar logons ou criar novos bancos de dados, atribua o usuário às Loginmanager funções e dbmanager no banco de dados mestre.

Para obter mais informações sobre essas funções adicionais e autenticação em um Banco de Dados SQL, consulte Gerenciando bancos de dados e logons no Banco de Dados SQL do Azure. Para obter mais informações sobre como se conectar usando a ID do Microsoft Entra, consulte Conectando-se usando a autenticação do Microsoft Entra.

Autorização

Autorização refere-se ao que você pode fazer dentro de um banco de dados depois de autenticado e conectado. Os privilégios de autorização são determinados por associações de função e permissões. Como melhor prática, deverá conceder aos utilizadores o mínimo de privilégios necessários. Para gerenciar funções, você pode usar os seguintes procedimentos armazenados:

EXEC sp_addrolemember 'db_datareader', 'ApplicationUser'; -- allows ApplicationUser to read data
EXEC sp_addrolemember 'db_datawriter', 'ApplicationUser'; -- allows ApplicationUser to write data

A conta de administrador do servidor que está a ligar é membro de db_owner, que tem autoridade para fazer todas as operações na base de dados. Guarde esta conta para a implementação de atualizações de esquema e outras operações de gestão. Utilize a conta "ApplicationUser" com permissões mais limitadas para se ligar da sua aplicação à base de dados com o mínimo de privilégios necessários para a sua aplicação.

Há maneiras de limitar ainda mais o que um usuário pode fazer dentro do banco de dados:

• As permissões granulares permitem controlar quais operações você pode fazer em colunas individuais, tabelas, exibições, esquemas, procedimentos e outros objetos no banco de dados. Use permissões granulares para ter o máximo de controle e conceder as permissões mínimas necessárias.
• Funções de banco de dados diferentes de db_datareader e db_datawriter podem ser usadas para criar contas de usuário de aplicativo mais poderosas ou contas de gerenciamento menos poderosas. As funções de banco de dados fixas internas fornecem uma maneira fácil de conceder permissões, mas podem resultar na concessão de mais permissões do que as necessárias.
• Os Procedimentos armazenados podem ser utilizados para limitar as ações que podem ser realizadas na base de dados.

O exemplo a seguir concede acesso de leitura a um esquema definido pelo usuário.

--CREATE SCHEMA Test
GRANT SELECT ON SCHEMA::Test to ApplicationUser

A gestão de bases de dados e servidores a partir do portal do Azure ou utilizando a API do Azure Resource Manager é controlada pelas atribuições de função da sua conta de utilizador do portal. Para obter mais informações, consulte Atribuir funções do Azure utilizando o portal do Azure.

Encriptação

A Criptografia de Dados Transparente (TDE) ajuda a proteger contra a ameaça de atividades maliciosas, criptografando e descriptografando seus dados em repouso. Quando encripta a sua base de dados, as cópias de segurança associadas e os ficheiros de registo de transações são encriptados sem exigir quaisquer alterações às suas aplicações. A Encriptação de Dados Transparente encripta o armazenamento de uma base de dados completa ao utilizar uma chave simétrica chamada chave de encriptação de base de dados.

No Banco de dados SQL, a chave de criptografia do banco de dados é protegida por um certificado de servidor interno. O certificado de servidor interno é exclusivo para cada servidor. A Microsoft alterna automaticamente esses certificados pelo menos a cada 90 dias. O algoritmo de encriptação usado é AES-256. Para obter uma descrição geral da TDE, consulte Criptografia de dados transparente.

Você pode criptografar seu banco de dados usando o portal do Azure ou o T-SQL.

Próximos passos

Para obter detalhes e exemplos sobre como se conectar ao seu armazém com protocolos diferentes, consulte Conectar-se ao pool SQL dedicado (anteriormente SQL DW).