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 é recomendado para bancos de dados locais 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 criar cadeias de conexão em tempo de execução usando o SqlConnectionStringBuilder.
Importante
A Microsoft recomenda que você use 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 serão o método de autenticação recomendado.
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. |
| 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. |
| Segurança para o Mecanismo de Banco de Dados do SQL Server e o 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 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. |
| Procedimentos 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 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. |
Proteja 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. 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.
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.
Interopere 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 Interoperando com código não gerenciado.