Acesso seguro a dados
Para escrever códigos de ADO.NET seguros, é necessário compreender os mecanismos de segurança disponíveis no banco de dados ou no armazenamento de dados subjacente. Você também precisa considerar as implicações de segurança de outros recursos ou componentes que seu aplicativo talvez contenha.
Autenticação, autorização e permissões
Ao se conectar ao Microsoft SQL Server, é possível usar a Autenticação do Windows, também conhecida como Segurança Integrada, que usa a identidade do usuário ativo atual do Windows em vez de transmitir uma ID de usuário e uma senha. O uso da autenticação do Windows é recomendado para bancos de dados locais porque as credenciais do usuário não são expostas na cadeia de conexão. Se não for possível usar a autenticação do Windows para se conectar ao SQL Server, considere a possibilidade de criar cadeias de conexão em tempo de execução usando o SqlConnectionStringBuilder.
Importante
A Microsoft recomenda usar o fluxo de autenticação mais seguro disponível. Se você estiver se conectando ao SQL do Azure, as Identidades gerenciadas para recursos do Azure é o método de autenticação recomendado.
As credenciais usadas para a autenticação precisam ser tratadas de maneira diferente com base no tipo de aplicativo. Por exemplo, em um aplicativo do Windows Forms, pode ser solicitado ao usuário que ele forneça informações de autenticação ou pode ser possível utilizar as credenciais do Windows do usuário. No entanto, um aplicativo Web geralmente acessa dados usando credenciais fornecidas pelo próprio aplicativo, não pelo usuário.
Depois que os usuários são autenticados, o escopo de suas ações depende das permissões que foram concedidas a eles. Sempre siga o princípio de privilégio mínimo e conceda somente permissões que sejam absolutamente necessárias.
Para obter mais informações, consulte os recursos a seguir.
| Recurso | Descrição |
|---|---|
| Protegendo informações de conexão | Descreve as práticas recomendadas e técnicas de segurança para proteger informações de conexão, como o uso de configuração protegida para criptografar cadeias de conexão. |
| Construtores de cadeia de conexão | Descreve como criar cadeias de conexão no runtime com base na entrada do usuário. |
| Segurança do Mecanismo de Banco de Dados do SQL Server e Banco de Dados SQL do Azure | Fornece links para ajudá-lo a localizar informações sobre segurança e proteção no mecanismo de banco de dados do SQL Server e no banco de dados SQL do Azure. |
Comandos parametrizados e injeção de SQL
O uso de comandos parametrizados ajuda a proteger você contra ataques de injeção de SQL, nos quais um invasor "injeta" um comando em uma instrução SQL que compromete a segurança do servidor. Esses comandos evitam ataques de injeção de SQL, garantindo que os valores recebidos de uma fonte externa sejam transmitidos apenas como valores, não como parte da instrução Transact-SQL. Como resultado, os comandos Transact-SQL inseridos em um valor não são executados na fonte de dados. Em vez disso, eles são avaliados somente como um valor de parâmetro. Além dos benefícios de segurança, os comandos parametrizados fornecem um método conveniente para organizar valores transmitidos com uma instrução Transact-SQL ou para um procedimento armazenado.
Para saber como usar comandos parametrizados, confira os recursos a seguir.
| Recurso | Descrição |
|---|---|
| Parâmetros DataAdapter | Descreve como usar parâmetros com um DataAdapter. |
| Modificando dados com procedimentos armazenados | Descreve como especificar parâmetros e obter um valor de retorno. |
| Procedimento armazenados (Mecanismo de banco de dados) | Descreve os benefícios do uso de procedimentos armazenados e os diferentes tipos de procedimentos armazenados. |
Ataques de sondagem
Os invasores geralmente usam informações de uma exceção, como o nome do seu servidor, banco de dados ou tabela, para elaborar um ataque ao seu sistema. Como as exceções podem conter informações específicas sobre seu aplicativo ou fonte de dados, é possível ajudar a mantê-lo mais bem protegido expondo apenas informações essenciais ao cliente.
Para obter mais informações, consulte os recursos a seguir.
| Recurso | Descrição |
|---|---|
| Tratando e gerando exceções no .NET | Descreve as formas básicas de tratamento de exceção estruturado “try/catch/finally”. |
| Práticas recomendadas para exceções | Descreve as práticas recomendadas para lidar com exceções. |
Protege as fontes de dados do Microsoft Access e do Excel
O Microsoft Access e o Microsoft Excel podem atuar como um armazenamento de dados para um aplicativo ADO.NET quando os requisitos de segurança são mínimos ou inexistentes. Seus recursos de segurança são eficazes para intimidação, mas não considere que eles façam mais do que desencorajar a interferência de usuários desinformados. Os arquivos de dados físicos para Access e Excel existem no sistema de arquivos e devem ser acessíveis a todos os usuários. Isso os torna vulneráveis a ataques que podem resultar em roubo ou perda de dados, pois os arquivos podem ser facilmente copiados ou alterados. Quando uma segurança robusta for necessária, use o SQL Server ou outro banco de dados baseado em servidor no qual os arquivos de dados físicos não possam ser lidos no sistema de arquivos.
Serviços Corporativos
O COM+ contém o próprio modelo de segurança que depende de contas do Windows e da representação de processos/threads. O namespace System.EnterpriseServices fornece wrappers que permitem que aplicativos .NET integrem códigos gerenciados com serviços de segurança COM+ por meio da classe ServicedComponent.
Interoperar com código não gerenciado
O .NET Framework permite a interação com código não gerenciado, incluindo componentes COM, serviços COM+, bibliotecas de tipos externos e muitos serviços do sistema operacional. Trabalhar com códigos não gerenciados envolve sair do perímetro de segurança dos códigos gerenciados. Seu código e qualquer outro que o chame devem ter permissão de código não gerenciado (SecurityPermission com o sinalizador UnmanagedCode especificado). Códigos não gerenciados podem introduzir vulnerabilidades de segurança não intencionais em seu aplicativo. Portanto, evite interoperar com códigos não gerenciados, a menos que seja absolutamente necessário.
Para mais informações, confira Interoperar com código não gerenciado.