O Windows é sistema operacional multithreaded, e com um único processo, as threads podem rodar em diferentes contextos.
Impersonation Token ocorre quando uma thread é executada no contexto de segurança. Quando uma thread é executada no servidor no contexto de segurança do cliente, o servidor é o cliente, em até certo ponto. A thread usa o access token para representar as credenciais do cliente para obter acesso aos objetos nos quais o cliente tem acesso.
Uma das primeiras ação do impersonation “personificação” é realizar verificações de acesso contra a identidade do cliente. O Servidor usar a identidade do cliente para validar o acesso, pode fazer com que o acesso seja restrito ou livre, dependendo da permissão do cliente. Por exemplo, se o servidor de arquivos contem arquivos de classificação confidencial e que cada um destes arquivos é protegido por ACL. Para ajudar prevenir que um cliente tenha acesso não autorizado a esses arquivos, o servidor personificar “impersonation” o cliente antes de ele acessar.
Access Tokens for Impersonation
Access tokens são objetos que descreve o contexto de segurança de um processo ou uma thread. Eles provêem informação que inclui a identidade da conta do usuário e subconjunto dos privilégios da conta do usuário. Cada processo tem access token primário que descreve o contexto de segurança da conta do usuário associado com o processo. Por padrão, o sistema usa o access token primário quando uma thread do processo interagir com o objeto. Porém, quando uma thread personificar um cliente, a thread personifica ambos o access token primário e o access token de personificação. O token de personificação representa o contexto de segurança do cliente e este access token é usado para validar o acesso durante a personificação.
Se personificação tiver sucesso, significa que o cliente concordou que o servidor pode ser o cliente em até certo ponto. Há vários níveis de personificação que são chamados de impersonation level “níveis de personificação” e eles indicam quanta autoridade tem o servidor quando estiver personificando o cliente.
A lista seguinte descreve cada nível de personificação brevemente.
Anonymous level: O cliente é anônimo para o servidor. O processo do servidor pode personificar o cliente, mas o token de personificação não contém informação sobre o cliente.
Identify level: O nível de padrão do sistema. O servidor pode obter a identidade do cliente e o personificar o cliente para validar a ACL.
Impersonate level: O servidor pode personificar o contexto de segurança do cliente agindo em nome do cliente. O servidor pode acessar recursos locais do cliente. Se o servidor for local, pode acessar recursos de rede como o cliente.
Delegate level: O nível de personificação mais elevado. Quando um administrador habilitar este nível, o servidor (local ou remoto) pode personificar o contexto de segurança do cliente enquanto agindo em nome do cliente. Durante personificação, o servidor pode passar os credenciais do cliente (ambos local e rede) a qualquer número de máquinas.
Em um ambiente multicamada cliente/servidor, é comum um servidor chamar outros servidores para realizar alguma tarefa para o cliente. Esta é uma situação especial para o protocolo Kerberos, desde que o primeiro servidor tenha um ticket para o segundo.
No Windows Server 2003, o protocolo Kerberos trata essa situação por um mecanismo chamado delegation of authentication “delegação de autenticação”. Essencialmente, o cliente delega autenticação para o servidor que chama o KDC que o servidor é autorizado para representar o cliente.
Delegação de autenticação permite o cliente enviar sua identidade na forma do kerberos ticket para o front-end server. O front-end server pode personificar o cliente e pode autenticar com o back-end server como se o front-end server fosse o cliente.
Por exemplo, o Internet Explorer do cliente chama o servidor Web que tem um serviço web ASP.NET. Por sua vez, executa uma chamada de stored procedure no servidor que está rodando Microsoft SQL Server.
Neste exemplo, o serviço Web usa delegação Kerberos-constrained delegation para obter o ticket de serviço (sob a identidade do usuário delegada) para o serviço de SQL server.
Tire suas dúvidas no site abaixo. Muitos profissionais qualificados tentarão lhe ajudar da melhor forma possível:
É isso pessoal, espero que este artigo seja útil para todos. Em caso de dúvidas sobre o conteúdo deste artigo, ou para enviar sugestões sobre novos tutoriais que você gostaria de ver publicados neste site, entre com contato através do e-mail: fabiano@winsec.org ou vitor@winsec.org
Em breve novos artigos sobre segurança no Windows Vista serão publicados no site winsec.org
Vitor Nakano atua a 10 anos na área de infra-estrutura e segurança voltada à plataforma Microsoft e mentor do site www.winsec.org.
Atualmente é o coordenador do Setor de Segurança da Informação e Arquitetura do Grupo EcoRodovias, responsável pela implantação de importantes projetos de infra-estrutura e segurança e possui certificações Microsoft deste 2002. Em 2008 foi nomeado MVP na categoria Windows Security.