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

Este artigo orientará você pelas noções básicas de proteção do pool de SQL dedicado (antigo SQL DW). Em particular, este artigo permite que você comece a usar recursos para limitar o acesso, proteger dados e monitorar atividades usando o pool de SQL dedicado (antigo SQL DW).

Segurança de conexão

A Segurança de Conexão refere-se a como você restringe e protege conexões ao banco de dados usando regras de firewall e criptografia de conexão.

As regras de firewall são usadas pelo SQL Server 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 aplicativo ou do computador cliente, primeiro você deve 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 os intervalos de endereços IP permitidos por meio do firewall no nível do servidor o máximo possível. Para acessar o pool de SQL dedicado (antigo SQL DW) de seu computador local, verifique se o firewall em sua rede e computador local permite a comunicação de saída na porta TCP 1433.

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

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

Authentication

A autenticação refere-se à forma como você prova sua identidade ao se conectar ao banco de dados. Atualmente, o pool de SQL dedicado (antigo SQL DW) dá suporte à Autenticação do SQL Server com um nome de usuário e senha e com a ID do Microsoft Entra.

Ao criar o servidor para seu banco de dados, você especificou um logon de "administrador do servidor" com um nome de usuário e uma senha. Usando essas credenciais, você pode autenticar-se 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 atividade mal-intencionada 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 em seu servidor com o logon do administrador do servidor e crie um novo logon do 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 logon usando ferramentas como o SSMS sem especificar um nome de banco de dados. Ele também permite que eles usem o pesquisador 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 de SQL dedicado (antigo SQL DW) com o logon do 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 a um usuário permissão para executar operações adicionais, como criar logons ou criar novos bancos de dados, atribua o usuário às funções Loginmanager e dbmanager no banco de dados mestre.

Para obter mais informações sobre essas funções adicionais e autenticar 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 Conectar usando a autenticação do Microsoft Entra.

Authorization

A autorização refere-se ao que você pode fazer em um banco de dados depois de autenticado e conectado. Privilégios de autorização são determinados pelas permissões e associações de função. Como prática recomendada, você deve conceder aos usuários os privilégios mínimos 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 é 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 aplicativo ao banco de dados com os privilégios mínimos necessários para seu aplicativo.

Há maneiras de limitar ainda mais o que um usuário pode fazer no 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 mais 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

O gerenciamento de bancos de dados e servidores do portal do Azure ou do uso da API do Azure Resource Manager é controlado pelas atribuições de função da sua conta de usuário do portal. Para obter mais informações, confira Atribuir funções do Azure usando o portal do Azure.

Encryption

A TDE (Transparent Data Encryption) ajuda a proteger contra a ameaça de atividades mal-intencionadas criptografando e descriptografando seus dados em repouso. Quando você criptografa seu banco de dados, backups associados e arquivos de log de transações são criptografados sem a necessidade de alterações em seus aplicativos. A TDE criptografa o armazenamento de um banco de dados inteiro usando uma chave simétrica chamada de chave de criptografia de 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 gira automaticamente esses certificados pelo menos a cada 90 dias. O algoritmo de criptografia usado é AES-256. Para obter uma descrição geral do TDE, consulte Transparent Data Encryption.

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

Próximas etapas

Para obter detalhes e exemplos sobre como se conectar ao seu warehouse com protocolos diferentes, consulte Conectar-se ao pool de SQL dedicado (antigo SQL DW).