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

Segurança de Conexão refere-se a como você restringe e protege conexões com seu banco de dados usando regras de firewall e criptografia de conexã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 seu pool SQL dedicado (anteriormente SQL DW) a partir do computador local, certifique-se de que a firewall na sua rede e no computador local permite 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

Autenticação refere-se a como você prova sua identidade ao se conectar ao banco 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 estas credenciais, podes autenticar-te em qualquer base de dados nesse servidor como o proprietário da base de dados, ou "dbo" através 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 prática recomendada, você deve conceder aos usuários 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 com a qual você está se conectando é um membro do db_owner, que tem autoridade para fazer qualquer coisa dentro do banco de dados. Salve essa conta para implantar atualizações de esquema e outras operações de gerenciamento. Use a conta "ApplicationUser" com permissões mais limitadas para se conectar do seu aplicativo ao banco de dados com o mínimo de privilégios necessários para seu aplicativo.

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 usados para limitar as ações que podem ser executadas no banco 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 Utilizar o portal do Azure para atribuir funções 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 TDE criptografa o armazenamento de um banco de dados inteiro usando uma chave simétrica chamada chave de criptografia do banco 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).