IIS 7.5 ApplicationPoolidentity quando o SQL Server está em outro servidor

Question

Alguém poderia aconselhar sobre as práticas recomendadas para configurar a identidade do pool de aplicativos para o serviço da Web no cenário a seguir

IIS7.5

1. O serviço da Web requer permissão de leitura / gravação para o banco de dados SQL
2. IIS e SQL estão em servidores diferentes, mas no mesmo domínio

Se ApplicationPoolIdentity for usado \ $, é adicionado como o usuário SQL, isso expõe nossos servidores a quaisquer riscos de segurança em particular ao contrário de adicionar um novo usuário de domínio e atribuir esse usuário como a identidade do pool de aplicativos e dar ao usuário permissão o banco de dados SQL?

IIS6

O mesmo cenário, mas usando o usuário interno NetworkService como a identidade do pool de aplicativos. Novamente, isso expõe nossos servidores a quaisquer riscos de segurança específicos, em vez de adicionar um novo usuário de domínio?

Obrigado

    

Answer 1

Usar a Identidade do AppPool para um servidor SQL remoto essencialmente significa que você está concedendo à conta do computador do AD o acesso do servidor da Web ao banco de dados SQL. Por causa disso, qualquer outra coisa em execução no servidor da web no contexto da conta do computador também tem acesso ao servidor SQL. Você poderia fazer muito pior em termos de segurança, mas uma conta de domínio explicitamente definida é definitivamente melhor, já que você pode ter certeza de que o único código que a utiliza é o seu site.

Se o gerenciamento de uma conta baseada em domínio (e sua senha exigida) for muito trabalhoso e seu servidor da Web estiver sendo executado no 2008 R2 ou Win7, talvez você possa usar um Conta de Serviço Gerenciado que basicamente oferece os benefícios de gerenciamento da Identidade do AppPool com a segurança de uma conta de domínio.

Eu ainda não tive a chance de jogar com contas de serviço gerenciadas ainda. Portanto, não tenho certeza se a documentação do TechNet apresenta lacunas ou limitações. Mas vale a pena tentar se você tiver tempo e seu ambiente atender a todos os requisitos. Eles definitivamente não funcionarão na sua caixa do IIS6.

    

Answer 2

usando a identidade do pool de aplicativos é mais segura: -

1-Limita a capacidade do usuário apenas a rede ou domínio local, portanto, qualquer processo executado por esse usuário não pode ser executado em nenhum recurso da rede, pois não é Domínio \ nome de usuário. (mais domínio seguro)

2-Permitir permissão NTFS para esta pasta de aplicativo, permitindo apenas mais segurança para o aplicativo da Web (mais seguro localmente)

3-eu discordo de Ryan: conta de usuário = computador \ conta de máquina = grupo é apenas SID autenticado e autorizado = > Os computadores membros do domínio também são os principais do Kerberos no AD, o que significa que os controladores de domínio têm um hash de senha de conta associada que podem ser usados para autenticar o computador quando ele fica on-line. Esta senha está associada ao objeto de conta do computador

A Microsoft diz: um problema surgiu ao longo do tempo à medida que mais e mais serviços de sistema do Windows começaram a ser executados como Serviço de Rede. Isso ocorre porque serviços executados como Serviço de Rede podem adulterar outros serviços que são executados sob a mesma identidade. Como os processos de trabalho do IIS executam código de terceiros por padrão (ASP clássico, ASP.NET, código PHP), era hora de isolar os processos de trabalho do IIS de outros serviços do sistema Windows e executar processos de trabalho do IIS sob identidades exclusivas. O sistema operacional Windows fornece um recurso chamado "contas virtuais" que permite ao IIS criar uma identidade exclusiva para cada um dos seus pools de aplicativos.