Cenários de segurança de aplicações no SQL Server

Baixar ADO.NET

Não existe uma única forma correta de criar uma aplicação cliente SQL Server segura. Cada aplicação é única nos seus requisitos, ambiente de implementação e população de utilizadores. Uma aplicação que é razoavelmente segura quando é inicialmente implementada pode tornar-se menos segura com o tempo. É impossível prever com precisão que ameaças poderão surgir no futuro.

O SQL Server, enquanto produto, evoluiu ao longo de muitas versões para incorporar as mais recentes funcionalidades de segurança que permitem aos programadores criar aplicações de base de dados seguras. No entanto, a segurança não vem na caixa; Requer monitorização e atualização contínuas.

Ameaças comuns

Os programadores precisam de compreender as ameaças à segurança, as ferramentas fornecidas para as contrariar e como evitar falhas de segurança auto-infligidas. A segurança pode ser melhor encarada como uma cadeia, onde uma quebra em qualquer elo compromete a força do todo. A lista seguinte inclui algumas ameaças de segurança comuns que são discutidas com mais detalhe nos tópicos desta secção.

Injeção de SQL

SQL Injection é o processo pelo qual um utilizador malicioso insere Transact-SQL instruções em vez de entradas válidas. Se a entrada for passada diretamente para o servidor sem ser validada e se a aplicação executar inadvertidamente o código injetado, então o ataque pode danificar ou destruir dados. Pode frustrar ataques de injeção SQL Server usando procedimentos armazenados e comandos parametrizados, evitando SQL dinâmico e restringindo permissões a todos os utilizadores.

Elevação de privilégios

Os ataques de elevação de privilégios ocorrem quando um utilizador consegue assumir os privilégios de uma conta de confiança, como um proprietário ou administrador. Sempre execute em contas de usuário com privilégios mínimos e atribua apenas as permissões necessárias. Evite usar contas administrativas ou de proprietário para executar código. Isso limita a quantidade de dano que pode ocorrer se um ataque for bem-sucedido. Ao executar tarefas que exigem permissões adicionais, use a assinatura de procedimento ou representação apenas durante a execução da tarefa. Pode assinar procedimentos armazenados com certificados ou usar a impersonação para atribuir permissões temporariamente.

Sondagem e observação inteligente

Um ataque de sondagem pode usar mensagens de erro geradas por uma aplicação para procurar vulnerabilidades de segurança. Implementar o tratamento de erros em todo o código procedural para evitar que a informação de erro do SQL Server seja devolvida ao utilizador final.

Authentication

Um ataque de injeção de cadeia de ligação pode ocorrer ao usar logins do SQL Server se uma cadeia de ligação baseada na entrada do utilizador for construída durante a execução. Se a cadeia de ligação não for verificada para pares de palavras-chave válidos, um atacante pode inserir caracteres extra, potencialmente acedendo a dados sensíveis ou outros recursos no servidor. Use autenticação do Windows sempre que possível. Se tiver de usar logins no SQL Server, use o SqlConnectionStringBuilder para criar e validar cadeias de ligação em tempo de execução.

Passwords

Muitos ataques têm sucesso porque um intruso conseguiu obter ou adivinhar uma palavra-passe para um utilizador privilegiado. As palavras-passe são a sua primeira linha de defesa contra intrusos, por isso definir palavras-passe fortes é essencial para a segurança do seu sistema. Crie e faça cumprir políticas de palavras-passe para autenticação em modo misto.

Atribua sempre uma palavra-passe forte à sa conta, mesmo ao usar a Autenticação Windows.

Nesta secção

Escrever SQL dinâmico seguro no SQL Server
Descreve técnicas para escrever SQL dinâmico seguro usando procedimentos armazenados.

Próximos passos

• Segurança do SQL Server