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. Também é necessário considerar as implicações de segurança de outros recursos ou componentes possivelmente contidos no aplicativo.
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 é altamente recomendado 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 criar cadeias de conexão no runtime usando o SqlConnectionStringBuilder.
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. |
| Recomendações para estratégias de acesso a dados | Fornece recomendações para acessar dados e realizar operações de banco de dados. |
| Construtores de cadeia de conexão | Descreve como criar cadeias de conexão no runtime com base na entrada do usuário. |
| Visão geral de segurança do SQL Server | Descreve a arquitetura de segurança do SQL Server. |
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. |
| Gerenciando permissões com procedimentos armazenados no SQL Server | Descreve como usar procedimentos armazenados do SQL Server para encapsular o acesso a dados. |
Exploits de script
Um exploit de script é outra forma de injeção que usa caracteres maliciosos inseridos em uma página da Web. O navegador não valida os caracteres inseridos e os processará como parte da página.
Para obter mais informações, consulte os recursos a seguir.
| Recurso | Descrição |
|---|---|
| Visão geral de exploits de script | Descreve como se proteger contra exploits de scripts e de instruções SQL. |
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. |
Proteção de fontes de dados do Excel e do Microsoft Access
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.
Para saber como proteger os dados do Access e do Excel, confira os recursos a seguir.
| Recurso | Descrição |
|---|---|
| Considerações de segurança e diretrizes para o Access 2007 | Descreve técnicas de segurança para o Access 2007, como criptografar arquivos, administrar senhas, converter bancos de dados para os novos formatos ACCDB e ACCDE e usar outras opções de segurança. |
| Introdução à segurança do Access 2010 | Fornece uma visão geral dos recursos de segurança oferecidos pelo Access 2010. |
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.
Para saber mais, confira o recurso a seguir.
| Recurso | Descrição |
|---|---|
| Segurança baseada em Função | Discute como integrar códigos gerenciados com serviços de segurança COM+. |
Interoperação com código não gerenciado
O .NET Framework oferece interação com códigos não gerenciados, incluindo componentes COM, serviços COM+, bibliotecas de tipos externas 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 obter mais informações, consulte os recursos a seguir.
| Recurso | Descrição |
|---|---|
| Interoperação com código não gerenciado | Contém tópicos que descrevem como expor componentes COM ao .NET Framework e componentes do .NET Framework ao COM. |
| Interoperabilidade COM avançada | Contém tópicos avançados, como assemblies de interoperabilidade primários, threading e marshalling personalizado. |