Melhores práticas de segurança para Microsoft. Data.SqlClient

Baixar ADO.NET

Proteja uma aplicação de banco de dados nas camadas de conexão, identidade, consulta e implantação. Uma autenticação bem-sucedida não prova que a conexão usa Segurança da Camada de Transporte (TLS) para validar o servidor ou que a identidade possui apenas as permissões necessárias pela aplicação.

Lista de verificação de segurança

Area Action
Criptografia de rede. Use Encrypt=true ou Encrypt=Strict em endpoints compatíveis, e mantenha TrustServerCertificate=false para conexões de produção remotas.
Autenticação. Prefira autenticação integrada ao Windows, identidade gerenciada ou identidade de carga de trabalho quando o destino e o host os suportam.
Autorização. Conceda apenas as permissões necessárias ao banco de dados. Use identidades separadas para implantação de esquemas e solicitações de aplicação.
Construção de consultas. Parametrize os valores dos dados. Selecione identificadores que não possam ser parâmetros de uma lista de permissão controlada pela aplicação.
Configuração da conexão. Use SqlConnectionStringBuilder e configuração confiável de pontos de extremidade. Não concatene fragmentos de string de conexão controlados pelo usuário.
Segredos. Use um repositório seguro de segredos ou a identidade do host. Nunca comprometa senhas, chaves privadas ou tokens de portador.
Agrupamento. Mantenha a seleção de identidade consistente com a chave do pool, especialmente para callbacks de token.
Erros e diagnósticos. Retorne erros seguros da aplicação e mantenha detalhes de diagnóstico restritos, sem incluir credenciais nem tokens.
Manutenção. Atualize as dependências compatíveis de drivers e bibliotecas de identidade, e exercite o comportamento de conexão e autenticação após atualizações.

Veja Criptografia e validação de certificados antes de alterar configurações em resposta a um erro de certificado. TrustServerCertificate=true remove uma verificação de identidade; não corrige uma implantação de certificado.

Ameaças comuns

Revise como a entrada não confiável chega aos comandos do banco de dados e configurações de conexão, qual identidade executa cada operação e quais informações de diagnóstico saem do seu serviço.

injeção SQL

A injeção de SQL ocorre quando uma aplicação trata uma entrada não confiável como Transact-SQL executável (T-SQL) em vez de dados. Use parâmetros de comando para valores, com tipos explícitos e tamanhos apropriados. Valide também a entrada com base nas regras de negócio.

Procedimentos armazenados não impedem a injeção se concatenarem entradas não confiáveis em SQL dinâmico. Parametrize instruções dinâmicas com sp_executesql quando apropriado. Se o nome de uma tabela, nome de coluna ou direção de ordenação for variar, selecione-o de uma lista de permissão controlada pela aplicação; parâmetros de valor ordinários não podem substituir identificadores ou sintaxe SQL.

Não confie apenas no escape de aspas, em um construtor de cadeia de conexão ou em um mapeador objeto-relacional para garantir a segurança de comandos SQL brutos arbitrários. Veja Comandos e parâmetros e Escreva SQL dinâmico seguro.

Elevação de privilégio

Execute solicitações de aplicação sob uma identidade de banco de dados com privilégio mínimo. Não conceda permissões ao administrador do servidor ou ao dono do banco de dados só para fazer um erro de aplicação desaparecer.

Separe as credenciais de migração de esquema das credenciais de runtime. Conceda acesso por meio de funções apropriadas às tabelas ou procedimentos exigidos. Use assinatura com certificado ou representação com escopo bem definido apenas quando a operação exigir permissões além das do chamador, e revise esse limite de permissões separadamente.

Autenticação não é autorização de aplicação. Se um serviço se conecta como uma identidade de banco de dados para muitos usuários, ele ainda deve impor quais registros e operações cada usuário pode acessar.

Sondagem e observação inteligente

Não retorne detalhes brutos de exceções de banco de dados, strings de conexão ou rastreios de pilha para clientes não confiáveis. Retorne um erro em nível de aplicação e um identificador de correlação quando apropriado.

Mantenha os registros de diagnóstico em um sistema de registro restrito. Registre informações como a operação, o número do erro do SqlClient, a tentativa de repetição e o identificador de correlação. Revise o texto de exceção e a configuração de rastreamento para texto de consulta, valores de parâmetros, endpoints ou dados pessoais antes de coletá-los ou exportá-los.

Trate os erros explicitamente. Não converta uma consulta ou tentativa de autenticação falhada em uma resposta de sucesso com dados vazios. Uma falha de certificado, credencial inválida ou permissão negada requer correção, e não tentativas ilimitadas.

Autenticação

Use uma identidade apropriada para o host da aplicação. A autenticação do Windows não exige armazenar uma senha SQL. Cargas de trabalho hospedadas no Azure podem usar identidade gerenciada quando suportadas; hosts federados podem usar identidade de carga de trabalho. A autenticação interativa é para usuários, não para serviços não acompanhados.

Use SqlConnectionStringBuilder para atribuir valores de string de conexão. Ele faz cotações e inclui escape de valores corretamente, mas não autoriza destinos. Mantenha o servidor, banco de dados, modo de autenticação e política TLS sob controle da aplicação ou do administrador.

Não deixe uma solicitação não confiável escolher TrustServerCertificate, Encrypt, Authentication, ou um endereço de servidor arbitrário. Para aplicações multilocatário, determine a configuração autorizada do locatário em vez de aceitar strings de conexão completas nas solicitações.

Veja a autenticação do SQL Server e do Windows e a autenticação do Microsoft Entra.

Senhas

Quando a autenticação SQL ou uma credencial com segredo do cliente for necessária, recupere o segredo na configuração protegida ou em um cofre de segredos. Restrinja o acesso de leitura, altere o segredo e remova credenciais antigas após a implantação.

Variáveis de ambiente podem carregar segredos injetados, mas não são um armazenamento secreto e podem ser expostos por diagnósticos de processos ou ferramentas de implantação. Não imprima nem inclua em relatórios de falhas. Mantenha segredos de desenvolvimento fora do controle de versão.

Deixe Persist Security Info=false, o padrão. Essa configuração limita a exposição através da propriedade de string de conexão de uma conexão aberta; ela não apaga a string de configuração original nem protege um segredo que você registrou.

Tokens de acesso e pool de conexões

Um pool de conexões reutiliza conexões físicas autenticadas. Mantenha cada pool associado ao contexto de segurança pretendido.

  • Um literal AccessToken participa da chave do pool. O SqlClient não pode renová-la nem inferir sua expiração a partir dessa propriedade. Gerencie a vida útil dos tokens e limpe os pools afetados conforme necessário.
  • Um AccessTokenCallback faz parte da chave do pool. Reutilize uma instância estável de delegado e credencial para conexões que devem compartilhar um pool.
  • Retorne a mesma identidade para as mesmas entradas de retorno. Não leia a identidade do usuário web atual dentro de um callback compartilhado, a menos que as entradas do pool isolem essa identidade de forma consistente.
  • Nunca registre tokens de acesso, segredos de clientes, chaves privadas de certificados ou todas as strings de conexão que portam credenciais.

Use as orientações de retorno de chamada do token para implementar a aquisição e a renovação. Um callback de token não personaliza a validação do certificado TLS.

Implantação e limites de serviço

Use versões suportadas da Microsoft. Data.SqlClient e a biblioteca de autenticação. Mantenha as versões do driver principal e da extensão do Azure alinhadas quando usar os modos Microsoft Entra fornecidos pelo driver. Teste as atualizações em relação à configuração de certificados do seu servidor e ao fluxo real de autenticação, não apenas à análise sintática de strings de conexão.

Mantenha os bancos de dados fora das redes públicas sempre que possível e restrinja o acesso aos endpoints exigidos pela aplicação. O TLS protege o tráfego em trânsito; ele não aplica permissões de banco de dados nem criptografa arquivos de banco de dados no disco.

LocalDB é uma ferramenta de desenvolvimento para Windows. Proteja seus arquivos e não use uma execução somente com o LocalDB como evidência do comportamento remoto do TLS ou do Microsoft Entra.

Verifique as capacidades do destino antes de adotar um recurso do SQL Server. O banco de dados SQL no Microsoft Fabric requer identidades do Microsoft Entra e não oferece suporte a logons SQL, funções de aplicativo nem tabelas Always Encrypted. Veja limitações do banco de dados Fabric SQL.

Nesta seção

Write secure dynamic SQL explica como parametrizar sentenças dinâmicas e revisar permissões de execução.

Conteúdo relacionado

  • Última atualização em