Está usando segurança integrada (SSPI) para acessar melhor o SQL Server para aplicativos da web?

Question

Ao implantar aplicativos da Web (.net) em um ambiente de produção, é melhor usar segurança integrada ou importa?

Parece-me que, se um hacker interromper o servidor da Web, isso não será realmente importante, já que ele pode facilmente personificar a máquina.

Pensamentos?

    

Answer 1

Eu diria que há apenas dois motivos válidos para usar a autenticação do SQL:

1. Você está se conectando de fora do domínio, de modo que a autenticação integrada
2. Você está executando um benchmark TPC-C e todo ciclo conta. A autenticação do SQL é um pouco mais rápida.

Para o cenário que você está propondo (o host do servidor da Web está completamente comprometido), nada pode protegê-lo. O hacker pode fazer no servidor de banco de dados pelo menos tudo o que o servidor web pode fazer . E eu diria que a defesa em profundidade pode ensiná-lo a minimizar a perda em tal caso: reduzir os direitos de banco de dados da conta usada pelo servidor web para o mínimo absolutamente necessário e nada mais. Segundo, certifique-se de que o host do servidor web está comprometido e não pode ser usado para elevar privilégios superiores à conta do servidor web (ou seja, não há outro serviço no host WWW que use credenciais com privilégios mais altos no banco de dados do que na conta WWW). Esses são princípios básicos de segurança e não têm nada a ver com o esquema de autenticação usado.

Embora a autenticação sql auth vs. windows não ofereça uma vantagem clara em seu cenário, há outros problemas a serem considerados:

1. Aplicação de políticas centralizadas: você tem um local para configurar suas políticas de senha, incluindo validade e expiração da senha, encerramento da conta, etc.
2. Controle sobre representação e delegação de confiança. Uma vez que a autenticação sql é usada em uma cadeia de delegação de confiança, todas as apostas são desativadas, já que isso não é uma 'delegação' real e, portanto, não está mais sob as restrições impostas pelas políticas
3. Auditoria: o sql auth nem é visto pelo seu LSA, portanto, toda a sua infraestrutura de auditoria é simplesmente ignorada. Você precisa adicionar explicitamente os registros que o SQL produz sobre os eventos auth do sql, mas está misturando maçãs e laranjas, já que esses eventos possuem origem, provedor e esquema diferentes no log de eventos

Uma última nota: o protocolo TDS expõe a senha de autenticação sql em texto não criptografado sobre o tráfego, mas isso geralmente é mitigado solicitando-se a criptografia SSL do tráfego.

Então, por que você vê os hosts sql auth WWW que armazenam a senha em clear no arquivo web.config? Esses são os bad desenvolvedores / administradores, não seja um deles.

msdn.microsoft.com/pt-br/library/aa378326 (VS.85) .aspx

technet.microsoft.com/pt-br/library/ms189067.aspx

    

Answer 2

Se você não usar o SSPI, estará codificando o nome de usuário e a senha nos arquivos de origem.

Se você estiver codificando o nome de usuário e a senha nos arquivos de origem, todos os seus funcionários terão acesso a ele.

Isso é relativamente inseguro. Um ex-funcionário insatisfeito poderia usar as informações maliciosamente. Um visitante pode ver o código em uma tela em algum lugar. Ou o código-fonte pode sair acidentalmente em estado selvagem.

A vantagem do SSPI é que a senha nunca é armazenada em lugar nenhum.

    

Answer 3

As outras respostas até agora têm sido boas, mas vou incluir outra: gestão.

Mais cedo ou mais tarde, você provavelmente terminará com vários SQL Servers. Gerenciar a autenticação do SQL entre seu aplicativo e vários SQL Servers pode ser um pouco doloroso, especialmente quando você se depara com problemas de segurança. Se você alterar uma senha de autenticação do Windows uma vez, ela será alterada imediatamente em todos os seus servidores. Se você precisa rodar suas senhas de autenticação SQL, é mais doloroso - a ponto de você provavelmente não fazer nada. Isso é um risco de segurança.

    

Answer 4

Não tenho 100% de certeza aqui, mas acho que o ponto principal é que a autenticação do SQL é insegura, por isso é melhor usar a autenticação do Windows. Dependendo de como seu aplicativo está configurado, você também pode armazenar as credenciais adequadas em um formulário criptografado na máquina usando a autenticação do Windows. Eu não acho que isso seja realmente possível com a autenticação do SQL. Você pode ofuscá-lo, mas, no final, ele deve ficar claro.

Além disso, só porque um hacker pode entrar em um servidor não significa que o jogo acabou. Um hacker pode ganhar o controle de um processo sem privilégios, mas não fazer mais nada no servidor. É por isso que é importante não executar tudo como administrador ou sistema, mas usar contas mínimas de serviço de privilégio.

    

Answer 5

A melhor coisa a fazer é limitar o que eles podem fazer se / quando eles invadirem o servidor web. Isso significa conceder apenas os direitos de SQL necessários para o aplicativo funcionar. É muito mais fácil conceder os direitos de DBO do aplicativo, mas ele torna o banco de dados muito mais vulnerável no caso de um ataque bem-sucedido ao servidor da Web.

    

Answer 6

Vou começar tudo isso dizendo que estou assumindo que você está falando de um servidor da Web interno na rede privada interna.

Vamos começar com a representação da máquina. Se a identidade do pool de aplicativos for Serviço de Rede e não houver representação no aplicativo .NET, então sim, o aplicativo da Web se conectará ao SQL Server de back-end usando a conta de computador da máquina. E isso significaria que você concedeu acesso à conta da referida máquina. O CRM da Microsoft funciona dessa maneira.

No entanto, se você especificou uma identidade, essa conta de usuário precisará acessar o SQL Server. Enquanto você está certo de que, se um invasor comprometeu o servidor da Web, ele efetivamente tem o mesmo acesso que a conta de identidade, a verdade é que o uso do logon do SQL Server não altera nada aqui. Uma vez que eu tenha acesso, posso modificar o aplicativo da web para fazer o que eu quiser e, ao máximo, sua segurança permite no SQL Server de back-end.

Agora, por que usar o SSPI. Em primeiro lugar, você não está usando um login baseado no SQL Server. Isso significa que o Active Directory é a única fonte de segurança. Isso significa que você tem os meios normais de auditoria para determinar o acesso inválido. Em segundo lugar, isso significa que, a menos que haja outros aplicativos que exijam isso, você pode deixar seu SQL Server no modo somente autenticação do Windows. Isso significa que nenhum logins do SQL Server é permitido. Isso significa que quaisquer ataques contra sa são interrompidos antes mesmo de começarem. E, finalmente, facilita a recuperação. Se você usar um login baseado no SQL Server, precisará extrair o login com o SID e a senha criptografada. Se você estiver usando uma conta de usuário com base no Windows como uma "conta de serviço", ao acessar um novo SQL Server, ao criar o logon, tudo será reconectado depois que você restaurar o banco de dados porque os SIDs corresponderão entre o usuário do login e do banco de dados. .

    

Answer 7

A questão é qual é "melhor"? O que é difícil de responder, pois depende do contexto, valores e prioridades do questionador.

Pessoalmente, gosto da autenticação do SQL.

O
• AD é outra coisa para executar e suportar e gerenciar contas de serviço.
• O AD precisa estar disponível em seu ambiente de hospedagem.
O
• AD dificultaria a migração para a nuvem ou nuvem híbrida.
O
• AD facilita a adição de contas de serviço em grupos nos quais eles não devem estar em administradores em outra parte da sua organização.
• O SSPI não ignora o problema de criptografar sua string de conexão, pois você deve criptografar seu nome de host do SQL na configuração.
• A autenticação do SQL é simples e apenas uma configuração de texto, fácil de implantar.
• Configurar as identidades do App Pool é outra coisa para automatizar e ocultar o nome de usuário e a senha nesses scripts de automação para cada ambiente.
• O uso de duas sequências de conexão facilita o uso de senhas contínuas, para que você possa atualizar a senha sem tempo de inatividade.

Último ponto: você codifica sua classe do gerenciador de conexões para testar cada cadeia de conexão, assim você pode alterar a senha no primeiro na configuração, enviar a mudança para fora e fazer o failover para a segunda conexão, depois atualizar o senha no MSQL e o primeiro será usado novamente. Uma alteração final de configuração é necessária para definir a segunda senha da mesma forma que a primeira, pronta para a próxima vez.

    

Answer 8

Se os usuários não estiverem manipulando o banco de dados diretamente (por meio de outras ferramentas clientes, como o SQL Server Management Studio), normalmente, apenas criarei um único logon do SQL para o aplicativo e concedo a ele o acesso necessário. Nesse momento, o usuário fica restrito ao que pode fazer conforme permitido pela interface do aplicativo da Web.