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

Este artigo explicará as noções básicas de como proteger seu pool de SQL dedicado (antes SQL DW). Especificamente, este artigo apresenta a você recursos para limitar acesso, proteger dados e monitorar atividades usando o pool de SQL dedicado (antigo SQL DW).

Segurança da conexão

A Segurança da Conexão refere-se a como você restringe e protege as conexões com o 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 seu banco 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 computador cliente, você deve primeiro criar uma regra de firewall no nível de 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 por meio do firewall no nível do servidor. 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 oferece suporte a regras de firewall de IP de 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 de SQL dedicado (antes 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 refere-se a como você comprova sua identidade durante a conexão com o 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.

Quando você criou o servidor do banco de dados, especificou um logon de "administrador de servidor" com um nome de usuário e uma senha. Usando essas credenciais, é possível se 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 uma melhor prática, os usuários de sua organização devem usar uma conta diferente para a autenticação. Dessa forma, você pode limitar as permissões concedidas ao aplicativo e reduzir os riscos de atividades mal-intencionadas, caso o código do aplicativo seja vulnerável a um ataque de injeção de SQL.

Para criar um usuário Autenticado do SQL Server, conecte o banco de dados mestre no servidor com o logon de administrador do servidor e crie um novo logon do servidor. Também é uma boa ideia criar um usuário no banco de dados mestre. A criação de um usuário mestre permite que um usuário faça logon usando ferramentas, como o SSMS, sem especificar um nome de banco de dados. Ela também permite que o usuário utilize 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 o pool de SQL dedicado (antigo SQL DW) com seu logon de administrador do servidor e crie um usuário do 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 um permissão de usuário para realizar operações adicionais, como criar logons ou 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 como fazer a autenticação em um Banco de Dados SQL, confira 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.

Autorização

A autorização refere-se ao que você pode fazer em um banco de dados quando está autenticado e conectado. Privilégios de autorização são determinados pelas permissões e associações de função. Como uma 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 é um membro de db_owner, que tem autoridade para realizar qualquer tarefa no 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.

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

• Permissões granulares permitem controlar quais operações você pode fazer em colunas, tabelas, exibições, esquemas, procedimentos e outros objetos individuais no banco de dados. Use permissões granulares para ter maior 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 potentes ou contas de gerenciamento menos potentes. As funções internas de banco de dados fixo fornecem uma maneira fácil para conceder permissões, mas podem resultar na concessão de mais permissões do que o necessário.
• 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 de servidores pelo portal do Azure ou usando a API do Azure Resource Manager é controlado pelas atribuições de função da sua conta de usuário. Para obter mais informações, confira Atribuir funções do Azure usando o portal do Azure.

Criptografia

A TDE (Transparent Data Encryption) ajuda a proteger contra a ameaça de atividades mal-intencionadas por meio da execução de criptografia e descriptografia de seus dados em repouso. Quando você criptografa seus banco de dados, os arquivos de log de transações e backups associados são criptografados sem exigir nenhuma alteração 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 do servidor interno. O certificado do servidor interno é exclusivo para cada servidor do Azure. A Microsoft gira automaticamente esses certificados pelo menos a cada 90 dias. O algoritmo de criptografia é AES-256. Para obter uma descrição geral da TDE, consulte Transparent Data Encryption.

Você pode criptografar o 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 warehouse com protocolos diferentes, consulte Conectar-se ao pool de SQL dedicado (antigo SQL DW).