Eventos
31 de mar., 23 - 2 de abr., 23
O maior evento de aprendizado de SQL, Fabric e Power BI. 31 de março a 2 de abril. Use o código FABINSIDER para economizar $ 400.
Registre-se hoje mesmoNão há mais suporte para esse navegador.
Atualize o Microsoft Edge para aproveitar os recursos, o suporte técnico e as atualizações de segurança mais recentes.
Aplica-se a: SQL Server
Banco de Dados SQL do Azure
Instância Gerenciada de SQL do Azure
Este artigo fornece informações sobre as melhores práticas e diretrizes que ajudam a estabelecer a segurança para o SQL Server. Para ver uma análise abrangente dos recursos de segurança do SQL Server, confira Proteger o SQL Server.
Para as melhores práticas de segurança específicas do produto, confira Banco de Dados SQL do Azure e Instância Gerenciada de SQL e SQL Server em VMs do Azure.
Uma metodologia de segurança em camadas fornece uma solução de defesa em profundidade usando vários recursos de segurança direcionados a escopos de segurança diferentes. Os recursos de segurança disponibilizados no SQL Server 2016 e aprimorados nas versões subsequentes ajudam a antecipar ameaças à segurança e fornecem aplicativos de banco de dados bem protegidos.
O Azure está em conformidade com vários padrões e regulamentações do setor que podem permitir o build de uma solução em conformidade com o SQL Server em execução em uma máquina virtual. Para obter informações sobre conformidade regulamentar com o Azure, consulte a Central de Confiabilidade do Azure.
As organizações geralmente precisam proteger dados no nível da coluna, uma vez que dados sobre clientes, funcionários, segredos comerciais, dados de produtos, serviços de saúde, financeiros e outros dados confidenciais geralmente são armazenados em bancos de dados do SQL Server. As colunas confidenciais geralmente incluem números de identificação pessoal/do seguro social, números de telefone celular, nome, sobrenome, identificação de conta financeira e quaisquer outros dados que podem ser considerados dados pessoais.
Os métodos e recursos mencionados nesta seção elevam o nível de proteção no nível da coluna com sobrecarga mínima e sem exigir alterações extensivas no código do aplicativo.
Use Always Encrypted para criptografar dados inativos e durante a transmissão por cabo. Os dados criptografados só são descriptografados por bibliotecas de cliente no nível do cliente do aplicativo. Use a criptografia aleatória em vez da determinística sempre que possível. Always Encrypted com enclaves seguros pode melhorar o desempenho de operações de comparação, como BETWEEN, IN, LIKE, DISTINCT, Joins e muito mais para cenários de criptografia aleatória.
Use DDM (Máscara Dinâmica de Dados) para ofuscar dados no nível da coluna quando Always Encrypted não for uma opção disponível. DDM (Máscara Dinâmica de Dados) não é compatível com Always Encrypted. Use o Always Encrypted em relação ao mascaramento dinâmico de dados sempre que possível.
Você também pode CONCEDER permissões no nível da coluna para uma tabela, exibição ou função com valor de tabela. Considere o seguinte: - apenas permissões SELECT
, REFERENCES
e UPDATE
podem ser concedidas em uma coluna.
- Um DENY
em nível de tabela não tem precedência sobre um GRANT
em nível de coluna.
A RLS (Segurança em Nível de Linha) permite aproveitar o contexto de execução do usuário para controlar o acesso a linhas em uma tabela de banco de dados. A RLS garante que os usuários só possam ver o registro que pertence a eles. Isso fornece ao seu aplicativo segurança de "nível de registro" sem precisar fazer alterações significativas em seu aplicativo.
A lógica de negócios é encapsulada dentro de funções com valor de tabela controladas por uma política de segurança que ativa e desativa a funcionalidade RLS. A política de segurança também controla os predicados FILTER
e BLOCK
que estão vinculados às tabelas contra as quais a RLS trabalha. Use a RLS para limitar os registros retornados ao usuário que está fazendo a chamada. Use SESSION_CONTEXT (T-SQL) para usuários que se conectam ao banco de dados por meio de um aplicativo de camada intermediária em que os usuários do aplicativo compartilham a mesma conta de usuário do SQL Server. Para obter o desempenho ideal e a capacidade de gerenciamento, siga as Melhores práticas de Segurança em Nível de Linha.
Dica
Use a RLS junto com Always Encrypted ou com a DDM (Máscara Dinâmica de Dados) para maximizar a postura de segurança da sua organização.
A TDE (Transparent Data Encryption) protege os dados no nível do arquivo fornecendo criptografia inativa para os arquivos de banco de dados. A TDE garante que arquivos de banco de dados, arquivos de backup e arquivos tempdb
não possam ser anexados e lidos sem certificados adequados que descriptografam arquivos de banco de dados. Sem a TDE (Transparent Data Encryption), é possível que um invasor use a mídia física (unidades ou fitas de backup) e restaure ou anexe o banco de dados para ler o conteúdo. A TDE tem suporte para trabalhar com todos os outros recursos de segurança no SQL Server. A TDE fornece criptografia de E/S em tempo real e descriptografia dos dados e arquivos de log. A criptografia de TDE aproveita uma DEK (chave de criptografia de banco de dados) armazenada no banco de dados do usuário. A chave de criptografia do banco de dados também pode ser protegida usando um certificado, protegido pela chave mestra do banco de dados master
.
Use a TDE para proteger dados inativos, backups e tempdb
.
Para auditar o SQL Server, crie uma política de auditoria no nível do servidor ou do banco de dados. Políticas de servidor se aplicam a todos os bancos de dados existentes e recém-criados no servidor. Para simplificar, habilita a auditoria no nível do servidor e permite que a auditoria no nível do banco de dados herde a propriedade no nível do servidor para todos os bancos de dados.
Audite tabelas e colunas com dados confidenciais que têm medidas de segurança aplicadas a elas. Se uma tabela ou coluna for importante o suficiente para precisar de proteção de uma capacidade de segurança, ela deverá ser considerada importante o suficiente para a auditoria. É especialmente importante auditar e revisar regularmente tabelas que contêm informações confidenciais, mas onde não é possível aplicar as medidas de segurança desejadas devido a algum tipo de limitação de aplicativo ou arquitetura.
O SQL Server dá suporte a dois modos de autenticação, modo de autenticação do Windows e "modo de autenticação SQL Server e Windows" (modo misto).
Os logons são diferentes dos usuários de banco de dados. Primeiro, você precisa mapear logons ou grupos do Windows para usuários ou funções de banco de dados separadamente. Em seguida, conceda permissões a usuários, funções de servidor e/ou funções de banco de dados para acessar objetos de banco de dados.
O SQL Server dá suporte aos seguintes tipos de logon:
master
.master
) que hospeda o banco de dados. O SQL Server dá suporte a usuários de bancos de dados independentes para autenticação no Windows e SQL Server.As seguintes recomendações e melhores práticas ajudam a proteger suas identidades e métodos de autenticação:
Use estratégias de segurança baseadas em função com privilégios mínimos para melhorar o gerenciamento de segurança.
No Azure, aproveite a segurança de privilégios mínimos usando controles de RBAC (acesso baseado em função)
Escolha Active Directory, em vez de autenticação do SQL Server, sempre que possível e, especialmente, escolha Active Directory em vez de armazenar a segurança no nível do aplicativo ou do banco de dados.
Use a autenticação multifator para contas que têm acesso no nível do computador, incluindo contas que usam RDP para fazer logon no computador. Isso ajuda a proteger contra roubos ou vazamentos de credenciais, pois a autenticação baseada em senha de fator único é uma forma mais fraca de autenticação com credenciais em risco de serem comprometidas ou entregues por engano.
Exigir senhas fortes e complexas que não podem ser adivinhadas facilmente e não são usadas para nenhuma outra conta ou finalidade. Atualizar regularmente senhas e impor políticas do Active Directory.
As gMSA (Contas de serviço gerenciadas por grupo) oferecem gerenciamento automático de senhas, gerenciamento de SPN (nome da entidade de serviço simplificado) e delegam o gerenciamento a outros administradores.
Minimizar os direitos concedidos à conta do AD do DBA. Considere uma separação de tarefas que limitam o acesso à máquina virtual, a capacidade de fazer logon no sistema operacional, a capacidade de modificar logs de erros e auditoria e a capacidade de instalar aplicativos e/ou recursos.
Considerar remover contas DBA da função sysadmin e conceder CONTROL SERVER a contas DBA, em vez de fazer delas um membro da função sysadmin. A função de administrador do sistema não respeita DENY
enquanto CONTROL SERVER respeita.
Manter registros históricos de alterações de dados ao longo do tempo pode ser útil para resolver alterações acidentais nos dados. Isso também pode ser útil para auditoria de alteração de aplicativo e pode recuperar elementos de dados quando um ator ruim introduziu alterações de dados que não foram autorizadas.
As ferramentas de configuração e avaliação a seguir lidam com a segurança da área de superfície, identificar oportunidades de segurança de dados e fornecer uma avaliação de melhor prática da segurança do seu ambiente SQL Server no nível da instância.
Ajuda saber quais são algumas ameaças comuns que arriscam o SQL Server:
--
.Para minimizar o risco de uma injeção de SQL, considere os itens a seguir:
EXECUTE
, EXEC
ou sp_executesql
.;
: Delimitador de consulta'
: Delimitador de cadeia de dados de caractere--
: Delimitador de comentário de linha única./* ... */
: Delimitadores de comentário.xp_
: Procedimentos armazenados estendidos do catálogo, como xp_cmdshell
.
xp_cmdshell
em nenhum ambiente do SQL Server. Em vez disso, use SQLCLR ou procure outras alternativas devido aos riscos que xp_cmdshell
pode introduzir.Para minimizar o risco de um ataque de canal lateral, considere o seguinte:
Considere as seguintes ameaças comuns à infraestrutura:
Como você não deseja que os invasores adivinhem facilmente nomes de conta ou senhas, as etapas a seguir ajudam a reduzir o risco de descoberta de senhas:
Crie uma conta do SQL com um nome exclusivo que tem a associação sysadmin. Faça isso no portal habilitando a Autenticação SQL durante o provisionamento.
Dica
Se você não habilitar a Autenticação SQL durante o provisionamento, deverá alterar manualmente o modo de autenticação para Modo de Autenticação do SQL Server e do Windows. Para obter mais informações, consulte Alterar Modo de Autenticação do Servidor.
Se precisar usar o logon SA, habilite o logon depois de provisionar e atribuir uma nova senha forte.
Considere o seguinte para minimizar os riscos de ransomware:
Eventos
31 de mar., 23 - 2 de abr., 23
O maior evento de aprendizado de SQL, Fabric e Power BI. 31 de março a 2 de abril. Use o código FABINSIDER para economizar $ 400.
Registre-se hoje mesmoTreinamento
Módulo
Você aprenderá sobre ameaças cibernéticas comuns, como ransomware e para quais tipos de padrões de ataque uma organização deve estar preparada.
Certificação
Microsoft Certified: Azure Database Administrator Associate - Certifications
Administrar uma infraestrutura de banco de dados do SQL Server para bancos de dados relacionais de nuvem, locais e híbridos usando as ofertas de banco de dados relacional do Microsoft PaaS.
Documentação
Protegendo o SQL Server - SQL Server
Use estes artigos para criar e implementar um plano de segurança eficaz no SQL Server. Saiba mais sobre a plataforma, a autenticação, os objetos e os aplicativos.
Documentação sobre segurança do SQL Server e do Banco de Dados SQL do Azure - SQL Server
Uma referência do conteúdo relacionado à segurança e à proteção do SQL Server e do Banco de Dados SQL do Azure.
Funções no nível do servidor - SQL Server
O SQL Server fornece funções de nível de servidor. Essas entidades de segurança agrupam outras entidades para gerenciar as permissões de todo o servidor.