Riscos da delegação Kerberos


8

Passei horas e horas tentando aprender e entender a autenticação do Windows, Kerberos, SPNs e delegação restrita no IIS 7.5. Uma coisa que simplesmente não entendo é por que é "arriscado" deixar a delegação ativada (por exemplo, não desativar a delegação para contas confidenciais) para administradores, CEOs, etc. Alguém pode me explicar isso em termos simples? Enquadre sua resposta em relação a um ambiente da intranet.

Meu raciocínio é que isso não deveria ser uma preocupação, porque a delegação simplesmente permite que um servidor Web front-end, por exemplo, atue em nome da pessoa autenticada pelo Windows ao se comunicar com outros servidores. Se a pessoa tem acesso, ela tem acesso, não entendo por que isso deve ser uma preocupação.

Por favor, perdoe minha ignorância. Eu sou principalmente um desenvolvedor, mas minha empresa está funcionando muito lentamente hoje em dia e sou forçado a usar o chapéu de administrador do servidor também ... infelizmente, ele ainda não se encaixa muito bem, lol.

Respostas:


7

Dois exemplos:

  1. A delegação restrita permite a representação sem ter credenciais ou token de autenticação do usuário. Para um exemplo, veja esta resposta .

  2. Em um cenário de delegação sem restrição mais comum, seja de autenticação integrada do Windows ou de autenticação de formulários, o acesso de delegação ao token de autenticação de um usuário é muito poderoso. Isso significa literalmente que o token pode ser usado para representar esse usuário para acessar qualquer recurso de rede. Qualquer pessoa envolvida nesse processo, como um desenvolvedor, pode usá-lo de maneira nefasta para obter acesso não autorizado.

Nos dois exemplos, se a caixa estiver marcada como "a conta é sensível e não pode ser delegada", esses não são problemas de segurança. Também é possível arquitetar um sistema / recurso onde esses recursos existem, mas são rigorosamente controlados.

Essa caixa deve ser marcada para contas administrativas, como membros do grupo Administradores Corporativos, porque (espero) essas contas raramente precisam usar aplicativos que exijam representação. Também é uma boa ideia para executivos seniores que tenham acesso a informações confidenciais, como CIO, COO, chefe de Finanças / Tesouraria etc.

Portanto, a questão é que a Microsoft forneceu a caixa de seleção e o aviso associado por um motivo muito bom e não deve ser descartada ou tomada de ânimo leve, a menos que seja demonstrado que um cenário em particular não possui exposição a riscos indesejáveis ​​ou algum controle compensatório. Isso geralmente envolve a verificação de algumas pessoas qualificadas que não estão envolvidas na implementação ou no desenvolvimento real de um aplicativo ou sistema.


Primeiro, resposta incrivelmente útil e aprofundada. Não posso te dizer o quanto eu aprecio isso. :) Ainda me pergunto, o que é necessário para que isso seja explorado porque as pessoas certamente não terão acesso às credenciais de nossos executivos. Também deve-se observar que os sistemas aos quais estamos permitindo delegação restrita são acessíveis a todos os funcionários da rede. Além disso, estou tentando fazer isso com o modo de pipeline integrado e sem representação do ASP.NET.
Chiramisu

1
Mesmo se estiver usando o modo de pipeline integrado, se o token de autenticação estiver presente, ele poderá ser aproveitado pelo IIS e por qualquer aplicativo que esteja sendo executado. Ao usar a autenticação integrada do Windows, o token de autenticação faz parte do cabeçalho http. Pode ser útil tentar executar um teste de penetração na configuração proposta para determinar se o que você acha correto.
Greg Askew

Puta merda! Parte do cabeçalho HTTP? Deve pelo menos ser criptografado, certo? Caso contrário, isso é loucura! Por que a Microsoft faria uma recomendação tão ridícula? Receio não ter a primeira pista sobre o teste com caneta, por isso vou ter que aceitar sua palavra. Ainda assim, nenhum dos aplicativos nesse servidor de intranet específico é restrito internamente, então acho que seria seguro. Os tokens são de tempo limitado e gerados dinamicamente, certo? Nós só restringir determinadas páginas usando allow/ denyetiquetas de autorização.
Chiramisu

2

Eu configurei milhares de clientes com delegação a maioria dos sem restrições. Eu acho importante observar que, se você não confia no seu aplicativo (digamos, implantado no IIS) ou está fornecendo credenciais à sua conta de serviço delegada para que outros usem livremente, a delegação restrita provavelmente é uma boa idéia. No entanto, se você não espera que alguém tenha a capacidade de reescrever seu aplicativo, mantenha as credenciais da sua conta de serviço seguras e confia que seus aplicativos delegarão apenas os serviços para os quais foram projetados. geralmente não é nada para se preocupar. Eu já vi alguns clientes "conscientes da segurança" se concentrarem muito em questões como essa, enquanto seus recursos poderiam ser melhor gastos trabalhando em ameaças reais à segurança ...


Eu aprecio muito suas idéias; muito útil. Há muito tempo, desisti de configurar a delegação em nossa Intranet e voltei a executar o AppPool no IIS em uma conta especial com acesso ao recurso necessário, conforme configurado anteriormente. Espero revisitar esse problema e obter uma solução real, mas a falta de tempo e experiência com a delegação exclui essa esperança no momento. :(
Chiramisu
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.