Segurança do SQL Server do banco de dados ASP.NET2.0

Autor：Eve Cole Data da Última Atualização：2009-06-30 16:43:56

Existem duas opções de modo de segurança ao instalar o SQL Server. A diferença entre eles é qual software realiza o processo de autenticação. Autenticação é o processo de confirmação da identidade de um usuário que está se conectando ao SQL Server. Depois que a autenticação for executada, o SQL Server poderá verificar se o usuário tem permissão para se conectar a um recurso solicitado, como um banco de dados. Se o usuário tiver permissão para se conectar ao banco de dados, o SQL Server permitirá que a solicitação de conexão seja bem-sucedida, caso contrário, a conexão falhará. Este processo de verificação da permissão do usuário também é chamado de autorização.

· A Autenticação do Windows (também conhecida como Autenticação Confiável ou Segurança Integrada) utiliza a identidade do usuário do Windows que faz a solicitação de conexão para realizar a autorização ao banco de dados. Nesse caso, a cadeia de conexão não precisa fornecer um nome de usuário e uma senha explícitos. O ASP.NET é executado como um usuário local chamado "ASPNET" (ou "Serviço de Rede" no IIS 6.0), portanto, ao usar a Autenticação do Windows, o SQL verificará se esse usuário tem permissão para usar o banco de dados. Neste ponto, todos os aplicativos ASP.NET estão sendo executados com esse mesmo usuário, portanto o modo de segurança os trata igualmente. Embora seja possível executar cada aplicativo em um processo ASP.NET separado (um usuário separado executando cada aplicativo) ou representar a identidade do usuário Windows do cliente navegador que faz a solicitação de conexão, isso está além do escopo deste livro. . No entanto, a representação do cliente é o uso mais comum da Autenticação do Windows em aplicativos Web.

· A Autenticação SQL verifica nomes de usuário e senhas fornecidos explicitamente em relação aos usuários configurados no SQL Server (sem envolver o sistema operacional). Nesse caso, cada aplicativo em execução no processo ASP.NET pode se conectar ao banco de dados com um certificado separado, isolando razoavelmente os aplicativos (o aplicativo A não conseguirá se conectar ao banco de dados se não tiver o nome de usuário e a senha de B) . Não é possível conectar-se ao banco de dados de B). Este é o modo de autenticação mais comum usado para aplicações web implantadas, especialmente no caso de hospedagem compartilhada. Uma pequena desvantagem é que exige que o aplicativo retenha a senha da conta do usuário usada para se conectar e, se essa senha for obtida por um usuário mal-intencionado, a segurança do banco de dados será comprometida. Entretanto, como você verá mais adiante neste livro, o ASP.NET fornece uma maneira segura de armazenar a senha de Autenticação SQL em um formato criptografado no arquivo Web.config, reduzindo assim o risco de a senha ser obtida.

· Modo Misto é uma configuração do SQL Server que permite a Autenticação do Windows e a Autenticação do SQL.

Ao instalar o SQL Server ou SSE, você deve escolher um modo de autenticação. No SQL Server, existe um assistente para ajudá-lo a escolher durante as etapas de segurança, enquanto no SSE a opção padrão é Autenticação do Windows. Se desejar instalar a Autenticação SQL, você deverá configurá-la explicitamente. Este artigo usa a autenticação do Windows.

Se você instalou o SQL Server ou SSE, você pode visualizar o modo de autenticação especificado abrindo o RegEdit (é claro que você precisa fazer backup dele primeiro), encontrar HKey_Local_Machine/Software/Microsoft/Microsoft SQL Server e procurar LoginMode. Uma subchave de registro com valor 1 representa a autenticação do Windows, enquanto o valor 2 representa o modo de autenticação mista.

A Tabela 3-1 resume as diferenças entre esses modos.

Tabela 3-1

Autenticação do Windows Autenticação Confiável de usuários de melhor segurança podem


Nome	substituível
da	Autenticação SQL
Segurança Integrada	Não, mas a Autenticação de Modo Misto permite o uso da Autenticação do Windows ou do SQL.
Local	da
lista	da	Internet
e dos processos de autenticação	do	Windows
SQL	Server	.
=usuário verdadeiro	=nome de usuário; senha = senha
Usuários de aplicativos da Web ASP.NET	Processo ASP.NET, ASPNET (IIS 5.x) ou Serviço de Rede (IIS 6)	Os usuários de SQL
têm a vantagem	controlar	os eventos SQL do usuário e o rastreamento de atividades do Windows;	ser implantado na máquina host sem criar uma nova conta independente do sistema operacional; O site de intranet hospedado requer apenas habilidades moderadas Fornece uma maneira mais flexível para os aplicativos se conectarem a cada banco de dados com certificados diferentes
Desvantagens	Fornecer um certificado do Windows para um aplicativo da web tem o potencial de definir o escopo de permissões no sistema operacional muito grande	As senhas são armazenadas no aplicativo da web (o que não é o caso na autenticação do Windows). Confirme se a senha está salva no arquivo Web.config e criptografada. Permite operações de baixo nível para aplicações web usando certificados sa. Sempre crie novos certificados para aplicativos Web ASP.NET e conceda apenas as permissões necessárias

Agora que sabemos a maneira segura de usar SQL, vamos considerar como o consumidor de dados (controle DataSource) atenderá aos requisitos. Primeiro, use dados obtidos do VWD e do VWD Web Server (Cassini), principalmente durante o projeto e os testes. Segundo, os dados devem ser acessados no IIS após a implantação. Os dois consumidores de dados têm nomes de usuário diferentes. O VWD e o VWD Web Server usam o nome da pessoa conectada ao Windows, enquanto o programa IIS usa o nome ASPNET.

Se o SQL Server usar a autenticação do Windows, o controle SqlDataSource precisará incluir o seguinte código na cadeia de conexão: Integrated Security=true (ou Trusted_connection=true). Este parâmetro instruirá o SQL Server a autenticar solicitações de dados com base na conta de logon do Windows do solicitante. Se você estiver conectado como o usuário que instalou o SSE, o certificado concederá acesso ao SSE. Tudo correrá bem usando o VWD e o VWD Web Server, pois os usuários do VW Web Server são considerados programadores logados no Windows e, portanto, possuem contas no SSE. No entanto, mesmo que o aplicativo funcione bem fora do VWD, ele não funcionará corretamente quando o site for migrado para o IIS. O IIS é executado em uma conta de usuário chamada ASPNET (ou Serviço de Rede no IIS6/Windows 2003 Server). Portanto, o administrador da máquina que executa o IIS deve adicionar o usuário ASP.NET e conceder suas permissões. Esse processo está além do escopo deste livro, mas é descrito detalhadamente em muitos manuais de administradores do IIS. Em resumo, se o SQL Server usar a autenticação do Windows, você poderá usar o VWD e o VWD Web Server para realizar os exercícios deste livro. Sua página poderá ser executada no IIS somente após conceder permissão à conta do processo ASP.NET que acessa o banco de dados.

Se o SQL Server estiver usando a autenticação SQL, o SQL conduzirá seu próprio processo de autenticação. Este processo não dependerá da lista de usuários do Windows. A cadeia de conexão contém dois parâmetros: usuário=nome de usuário, senha=senha. A página agora pode ser usada no VWD, no VWD Web Server ou no IIS, pois não há necessidade de criar uma conta de usuário no Windows. No entanto, também precisamos usar uma conta no SQL Server. A única conta padrão é sa. Antes da implantação, outra conta deve ser criada no SQL Server que tenha permissão apenas para executar páginas ASPX. A falha em criar uma conta alternativa diferente do sa (e uma senha para proteger o sa) deixa o site aberto a uma das vulnerabilidades de segurança mais conhecidas e facilmente exploráveis. Qualquer hacker sabe fazer login usando userID='sa' com uma senha vazia.

Para ambos os modos de autenticação, ao utilizar a string de conexão descrita anteriormente, o usuário efetuará login no SQL Server com a conta inicial. Esta conta é sa, o que significa administrador do sistema. Como pode ser visto pelo nome, ela possui todas as permissões em todos os objetos. Na versão atual do SQL Server, o serviço não pode ser instalado com sa com senha NULL. No SSE, deve ser instalado com o parâmetro SAPWD="MyStrongPassword". Uma senha forte aqui significa pelo menos não NULL. É melhor usar pelo menos sete caracteres e combinar letras, números e símbolos. Na maioria dos casos, fora dos exercícios do aluno, será necessário atribuir uma conta a cada banco de dados e aplicativo. Deve-se evitar conceder permissão a um aplicativo para acessar dados de outros aplicativos.