Acesso seguro aos dados
Para escrever código de ADO.NET seguro, você precisa entender os mecanismos de segurança disponíveis no armazenamento de dados subjacente ou no banco de dados. Você também precisa considerar as implicações de segurança de outros recursos ou componentes que seu aplicativo pode conter.
Autenticação, Autorização e Permissões
Ao se conectar ao Microsoft SQL Server, você pode 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 passar uma ID de usuário e 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 você não puder usar a Autenticação do Windows para se conectar ao SQL Server, considere a criação de cadeias de conexão em tempo de execução usando o SqlConnectionStringBuilder.
As credenciais usadas para autenticação precisam ser tratadas de forma diferente com base no tipo de aplicativo. Por exemplo, em um aplicativo do Windows Forms, o usuário pode ser solicitado a fornecer informações de autenticação ou as credenciais do Windows do usuário podem ser usadas. No entanto, um aplicativo Web geralmente acessa dados usando credenciais fornecidas pelo próprio aplicativo em vez de pelo usuário.
Depois que os usuários forem autenticados, o escopo de suas ações dependerá das permissões que lhes foram concedidas. Siga sempre o princípio do menor privilégio e conceda apenas permissões que sejam absolutamente necessárias.
Para obter mais informações, consulte os seguintes recursos.
| Recurso | Description |
|---|---|
| Protegendo informações de conexão | Descreve as práticas recomendadas de segurança e técnicas 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 executar operações de banco de dados. |
| Construtores de cadeias de conexão | Descreve como criar cadeias de conexão a partir da entrada do usuário em tempo de execução. |
| Visão geral da 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 contra ataques de injeção de SQL, nos quais um invasor "injeta" um comando em uma instrução SQL que compromete a segurança no servidor. Os comandos parametrizados protegem contra um ataque de injeção de SQL, garantindo que os valores recebidos de uma fonte externa sejam passados apenas como valores e 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 apenas 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 passados com uma instrução Transact-SQL ou para um procedimento armazenado.
Para obter mais informações sobre como usar comandos parametrizados, consulte os seguintes recursos.
| Recurso | Description |
|---|---|
| Parâmetros DataAdapter | Descreve como usar parâmetros com um DataAdapterarquivo . |
| 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. |
Explorações de script
Uma exploração de script é outra forma de injeção que usa caracteres mal-intencionados inseridos em uma página da Web. O navegador não valida os caracteres inseridos e irá processá-los como parte da página.
Para obter mais informações, consulte os seguintes recursos.
| Recurso | Description |
|---|---|
| Visão geral das explorações de script | Descreve como se proteger contra scripts e explorações de instrução SQL. |
Ataques de sondagem
Os invasores geralmente usam informações de uma exceção, como o nome do servidor, banco de dados ou tabela, para montar um ataque ao sistema. Como as exceções podem conter informações específicas sobre seu aplicativo ou fonte de dados, você pode ajudar a manter seu aplicativo e fonte de dados melhor protegidos expondo apenas informações essenciais ao cliente.
Para obter mais informações, consulte os seguintes recursos.
| Recurso | Description |
|---|---|
| Manipulando e lançando exceções no .NET | Descreve as formas básicas de tratamento de exceções estruturadas try/catch/finally structured exception. |
| Práticas recomendadas para exceções | Descreve as práticas recomendadas para lidar com exceções. |
Protegendo 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. Os seus elementos de segurança são eficazes para dissuadir, mas não devem ser utilizados para mais do que desencorajar a interferência de utilizadores não informados. Os arquivos de dados físicos do Access e do Excel existem no sistema de arquivos e devem estar acessíveis a todos os usuários. Isso os torna vulneráveis a ataques que podem resultar em roubo ou perda de dados, uma vez que os arquivos podem ser facilmente copiados ou alterados. Quando for necessária uma segurança robusta, use o SQL Server ou outro banco de dados baseado em servidor em que os arquivos de dados físicos não sejam legíveis do sistema de arquivos.
Para obter mais informações sobre como proteger dados do Access e do Excel, consulte os recursos a seguir.
| Recurso | Description |
|---|---|
| Considerações e orientações de segurança 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 Empresariais
COM+ contém seu próprio modelo de segurança que depende de contas do Windows e representação de processo/thread. O System.EnterpriseServices namespace fornece wrappers que permitem que aplicativos .NET integrem código gerenciado com serviços de segurança COM+ por meio da ServicedComponent classe.
Para obter mais informações, consulte os recursos seguintes.
| Recurso | Description |
|---|---|
| Segurança baseada em funções | Discute como integrar código gerenciado com serviços de segurança COM+. |
Interoperando com código não gerenciado
O .NET Framework fornece 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ódigo não gerenciado envolve sair do perímetro de segurança para código gerenciado. Tanto o seu código como qualquer código que o chame deve ter permissão de código não gerenciado (SecurityPermission com o sinalizador UnmanagedCode especificado). O código não gerenciado pode introduzir vulnerabilidades de segurança não intencionais em seu aplicativo. Portanto, você deve evitar interoperar com código não gerenciado, a menos que seja absolutamente necessário.
Para obter mais informações, consulte os seguintes recursos.
| Recurso | Description |
|---|---|
| Interoperando com código não gerenciado | Contém tópicos que descrevem como expor componentes COM para o .NET Framework e como expor componentes do .NET Framework para COM. |
| Interoperabilidade COM avançada | Contém tópicos avançados, como assemblies de interoperabilidade primária, threading e empacotamento personalizado. |