Conceitos essenciais

Capítulo 6: Gerenciamento de acesso

Publicado em: maio 11, 2004 | Atualizado em: 26 de junho de 2006

O gerenciamento de acesso consiste em processos e tecnologias destinados a controlar e monitorar o acesso a recursos de forma consistente com as diretivas reguladoras. O gerenciamento de acesso inclui:

• Autenticação

• Autorização

• Relação de confiança

• Auditoria de segurança

Nesta página

Autenticação
Autorização
Relações de confiança e federação
Auditoria de segurança

Autenticação

Na plataforma de Gerenciamento de acesso e identidades da Microsoft, o serviço de diretório Microsoft® Active Directory® é a tecnologia recomendada para armazenar informações de identidades, incluindo as chaves criptográficas que validam as credenciais de usuários durante o processo de autenticação.

Aplicativos integrados com o Microsoft Windows Server™ 2003, o Microsoft Windows® XP Professional e os Serviços de segurança do Windows usam os recursos internos do sistema operacional para executar a autenticação.

Serviços de autenticação do Windows

A implementação de protocolos de autenticação aplicativo por aplicativo é muito ineficiente e, provavelmente, introduzirá falhas de segurança na organização. Uma abordagem melhor é a criação de aplicativos usando os mecanismos de autenticação na plataforma Windows.

Para obter resultados melhores, os desenvolvedores precisam compreender os diferentes tipos de autenticação e as ramificações do uso de diferentes protocolos e as interfaces para as quais eles oferecem suporte antes de iniciar o processo de design do aplicativo.

Arquitetura dos serviços de autenticação do Windows

O Windows Server 2003 e o Microsoft Windows XP implementam um conjunto completo de métodos de autenticação e protocolos de segurança que atendem aos requisitos de autenticação de vários aplicativos. O Microsoft .NET Passport, a autenticação de chaves públicas por meio de certificados ou cartões inteligentes e as combinações de nome de usuário/senha oferecem diferentes experiências ao usuário, devido aos diferentes requisitos de credenciais, e cada opção possui características de segurança distintas. O mecanismo de transporte de dados também pode definir os protocolos de autenticação que você pode usar.

O sistema de segurança para os serviços de autenticação na plataforma de Gerenciamento de acesso e identidades da Microsoft é organizado em camadas: ele se estende das interfaces de nível inferior, que oferecem maior flexibilidade e controle, até as interfaces de nível superior, com menos flexibilidade e interfaces de programação de aplicativo (APIs) mais simples. A figura a seguir mostra como os protocolos de autenticação e as APIs são organizadas em camadas.

Figura 6.1. A hierarquia de protocolos e APIs de autenticação no sistema operacional Windows

Na parte superior da pilha de autenticação, na figura anterior, os serviços e as APIs de nível superior fornecem mecanismos de comunicação entre processos (IPC) que oferecem um canal autenticado seguro para a transmissão de dados de aplicativos. Exemplos desses serviços e APIs incluem o DCOM (Distributed Component Object Model), chamadas de procedimento remoto (RPC), o Microsoft ASP.NET, o ASP, o WinInet, entre outros.

O RPC da Microsoft é um mecanismo de IPC sofisticado, eficiente e seguro que permite a troca de dados e a invocação de funcionalidades que residem em outro processo. Esse processo pode estar na mesma máquina, na rede local ou na Internet.

O WinInet é uma interface de protocolo de aplicativo criada para dar suporte a protocolos de segurança da Internet, como o SSL sobre IP. A implementação do suporte de segurança do WinInet usa a interface SSPI para o provedor de segurança do canal de segurança (implementação de SSL do Windows NT®).

Em alguns casos, as APIs que esses serviços expõem oferecem ao desenvolvedor de aplicativos o controle completo sobre como a autenticação é executada e os dados são protegidos. Por exemplo, as APIs do DCOM permitem que o desenvolvedor selecione um protocolo de autenticação específico como o protocolo Kerberos ou o desafio/resposta do protocolo NTLM. Especifica também se os dados devem ser assinados (protegendo contra a alteração dos dados por um invasor) ou criptografados (protegendo contra a visualização dos dados por um interceptador). Outros serviços e APIs são afetados somente pela configuração do sistema. O ASP.NET, que melhor exemplifica isso, fica hospedado em um servidor que executa o Microsoft IIS (Serviços de Informações da Internet) 6.0, que pode ser configurado para usar o mecanismo de autenticação apropriado para um determinado cenário.

Interface SSPI

A interface de aplicativo para autenticação de nível mais baixo é a SSPI, que é a versão da Microsoft da GSS-API. Para obter mais informações sobre a GSS-API, consulte os RFC 1508 e 1509 no site Request for Comments (em inglês) da ITEF (Internet Engineering Task Force).

Para obter mais informações sobre a SSPI, consulte o artigo The Security Support Provider Interface Revisited (em inglês) no site do MSDN.

A idéia por trás da SSPI e da GSS-API é que a autenticação de rede entre duas partes geralmente segue um padrão comum. As partes precisam trocar uma ou mais informações em uma seqüência ordenada. Como elas podem estar se comunicando através de um entre vários protocolos de rede diferentes — HTTP, RPC, SMB, IIOP (Internet Inter-ORB Protocol), DCOM, RMI Java (Java Remote Method Invocation) e assim por diante — é importante não codificar um único handshake de autenticação no próprio protocolo de rede. É melhor simplesmente fornecer uma interface genérica que produza "tokens de autenticação", que são, na verdade, apenas construções de dados binários que representam algum aspecto de uma seqüência de autenticação. Esses tokens são trocados por meio do protocolo de aplicativo em uso.

Por exemplo, no RPC, um handshake já é usado para sincronizar os protocolos entre o cliente e o servidor. O RPC simplesmente fornece espaço nesse handshake para tokens de autenticação opacos dimensionados arbitrariamente. Uma grande parte do trabalho que a SSPI e a GSS-API executam diz respeito à geração e avaliação desses tokens.

Como mencionado anteriormente, o Windows Server e sistemas operacionais cliente implementam uma ampla variedade de protocolos de autenticação. Esses protocolos são "pacotes de segurança" (às vezes chamados de pacotes de autenticação), que consistem em DLLs carregadas pelo serviço da autoridade de segurança local. A SSPI é a interface de todos os pacotes de segurança fornecidos com o Windows Server e sistemas operacionais cliente. Normalmente, esses pacotes de segurança implementam um protocolo de autenticação de rede, como o protocolo de autenticação Kerberos versão 5, o desafio/resposta do NTLM, a autenticação Digest, o SSL ou o TLS. Os aplicativos podem usar esses protocolos para integrar-se de maneira segura e transparente com o Active Directory para autenticação e, além disso, usar os recursos dos protocolos para proteger dados de aplicativos.

O SPNEGO (Secure Protocol Negotiation) é um tipo especial de pacote de segurança que faz a negociação entre protocolos de autenticação, conforme necessário. A prática recomendada para aplicativos que usam a SSPI e o protocolo Kerberos versão 5 ou o NTLM é a utilização do pacote SPNEGO, em vez de utilizar diretamente esses protocolos. Para obter mais informações sobre o SPNEGO, consulte a página Windows Security (em inglês) no MSDN.

Autenticação Kerberos

O protocolo de autenticação Kerberos versão 5 está especificado na página IETF RFC 1510, no site Request for Comments (em inglês). O protocolo é extremamente seguro e escalonável, sendo ideal para a autenticação em um ambiente de rede integrado.

Em clientes e servidores Windows que executam o Microsoft Windows 2000 Server ou posterior, o protocolo de autenticação Kerberos versão 5 é a base da autenticação para o Active Directory. Ele também está integrado ao SMB, HTTP e RPC, além dos aplicativos cliente e servidor que usam esses protocolos. A plataforma Windows oferece ao usuário uma experiência transparente e integrada para essa sofisticada ferramenta de segurança.

O protocolo Kerberos versão 5 é muito importante para a plataforma de Gerenciamento de acesso e identidades da Microsoft, pois ele se baseia em um padrão aberto. Vários outros fornecedores também implementaram o protocolo Kerberos versão 5 com base na implementação do protocolo feita pelo MIT (Massachusetts Institute of Technology), preparando, assim, o terreno para a interoperabilidade da autenticação entre plataformas e aplicativos da Microsoft e que não são da Microsoft.

O Windows oferece suporte a duas formas de configuração do protocolo Kerberos versão 5 para conseguir a interoperabilidade:

• Você pode estabelecer uma relação de confiança entre um domínio do Windows e um território do protocolo Kerberos versão 5 baseado no MIT. Essa relação permite que clientes desse território se autentiquem através do mecanismo de confiança em recursos de rede no domínio do Windows.

• Clientes e servidores que não são do Windows podem usar contas do Active Directory para obter a autenticação de um controlador de domínio.

Em uma intranet, as implementações do protocolo Kerberos versão 5 na plataforma Windows oferecem o SSO do usuário, por conta das características básicas do protocolo de autenticação e da maneira como o protocolo é implementado nos sistemas operacionais cliente e servidor do Windows.

Uma limitação importante do protocolo Kerberos versão 5 que impede que ele seja uma solução universal para a segurança e autenticação de aplicativos é que a configuração da autenticação Kerberos para uso na Internet não é prática. Os motivos para isso são discutidos em mais detalhes na seção "Logon único da Web", mais adiante neste capítulo.

Para obter mais informações sobre o protocolo de autenticação Kerberos versão 5, consulte a página Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability (em inglês) no Microsoft TechNet.

SSL 3.0 e TLS 1.0

O SSL 3.0 e o TLS 1.0 são protocolos intimamente relacionados que podem ser usados para resolver o problema geral de como proteger um canal de comunicação entre dois aplicativos. O SSL 3.0 é um protocolo proprietário da Netscape Communications e o TLS 1.0 é a definição RFC 2246 do padrão da IETF no site Request for Comments (em inglês). Os dois protocolos são semelhantes, mas o TLS possui alguns aprimoramentos importantes, e a Microsoft recomenda sua utilização sempre que possível. O TLS e o SSL oferecem a oportunidade de autenticação do servidor durante o estabelecimento do canal de dados seguro, com a autenticação do cliente como uma opção.

Os protocolos SSL e TLS são usados com mais freqüência para fornecer proteção e integridade (criptografia) dos dados sobre o protocolo HTTP. Outros protocolos também dão suporte a SSL ou TLS. Por exemplo, o LDAP incorpora o SSL, produzindo o LDAP sobre SSL ou LDAPS. Além disso, os aplicativos personalizados ou de terceiros podem usar o SSL ou o TLS diretamente, através da SSPI, e especificar o pacote de segurança SChannel.

O SSL e o TLS oferecem uma autenticação baseada em certificados e transferências de dados seguras usando chaves de criptografia simétricas. Na Internet, é comum as organizações usarem o SSL e o TLS para autenticação de servidor. Os clientes verificam as seguintes condições para autenticar servidores no SSL e no TLS:

• O certificado do servidor é válido.

• O servidor comprovou possuir a chave particular apropriada associada ao certificado X.509 do servidor.

• O servidor que está sendo autenticado é o mesmo especificado no certificado.

O SSL e o TLS também dão suporte e integram a autenticação do cliente com a plataforma Windows Server 2003 através de certificados de cliente X.509. Geralmente, chama-se a autenticação simultânea de cliente e servidor de autenticação mútua. Para concluir a autenticação do cliente, o cliente apresenta um certificado de cliente válido, medido pelo servidor com relação aos mesmos critérios descritos para a autenticação do servidor. Depois de validar o certificado do cliente, o Windows Server inclui a capacidade de mapeá-lo em uma conta do Active Directory. O Active Directory oferece flexibilidade na maneira como os certificados podem ser mapeados, permitindo mapeamentos do tipo um para um ou vários para um.

Em relação a outros protocolos de autenticação, o SSL e o TLS possuem recursos de segurança muito bons ao usarem certificados digitais X.509 para a autenticação.

Observação O SSL e o TLS oferecem SSO da Web para os usuários através do Gerenciador de Credenciais do Windows no cliente com o Windows XP, descrito posteriormente neste capítulo.

Autenticação do Passport

O Microsoft Passport é um serviço da Web que autentica os usuários em um enorme banco de dados de identidades digitais. Os indivíduos mantêm sua identidade do Passport por meio de um site seguro. O Passport permite recursos de SSO da Web e autenticação em vários sites e é utilizado em vários sites da Microsoft, além de alguns sites não pertencentes à Microsoft.

Os desenvolvedores podem criar aplicativos com links para o Passport, de forma que os aplicativos aceitem apenas conexões de usuários registrados do Passport. Se o Passport determinar que as credenciais de um usuário são válidas, ele retornará um tíquete de autenticação que o aplicativo poderá descriptografar para determinar a identidade do usuário. Devido a requisitos de privacidade, uma autenticação típica do Passport fornecerá apenas uma identificação exclusiva do Passport (PUID) ao aplicativo afiliado.

Normalmente, o aplicativo mapeia então o PUID para uma conta de usuário mantida localmente, para derivar uma identidade digital que seja válida na organização. O Windows Server 2003 se integra totalmente com o Passport quando a opção de configuração de autenticação do Passport no IIS 6.0 é selecionada. Além disso, você pode mapear usuários do Passport para contas do Active Directory a fim de permitir a integração total da autenticação do Passport com o modelo de segurança do Windows.

A autenticação do Passport fornece uma experiência do usuário de SSO para aplicativos da Internet. O Passport faz isso fornecendo um tíquete de autenticação codificado em um cookie HTTP. A presença do cookie, mantido durante a sessão do navegador, permite a autenticação em vários aplicativos sem exigir que o usuário faça logon repetidamente no serviço de autenticação do Passport.

Para obter mais informações sobre o Passport, consulte o .NET Passport Service Guide Kit (em inglês) no MSDN.

Autenticação Digest

A autenticação Digest é outro protocolo de autenticação baseado em padrões descrito no RFC 2617, no site Request for Comments (em inglês), que está incluído como um pacote de autenticação no Windows Server 2003. A autenticação Digest fornece principalmente a interoperabilidade entre plataformas Windows ou não para a autenticação na Internet.

O Windows Server 2003 também implementa a autenticação Digest como um mecanismo SASL (Simple Authentication and Security Layer), como descrito no RFC 2831, no site Request for Comments (em inglês). O SASL é outra camada de abstração entre o aplicativo e o protocolo subjacente, que facilita a inclusão de diferentes mecanismos de autenticação sem alterar o aplicativo. Sob alguns pontos de vista, ele é semelhante ao mecanismo SPNEGO descrito anteriormente. O SASL é usado principalmente para a autenticação LDAP.

A autenticação Digest possui características de segurança semelhantes ao protocolo NTLM proprietário. A autenticação Digest e o NTLM são protocolos de desafio/resposta, que exigem que o servidor que está autenticando gere um desafio contendo algum volume de dados imprevisíveis. Em seguida, o cliente forma a resposta, criptografando o desafio através de uma chave derivada da senha do usuário. O servidor ou um serviço de terceira parte confiável, como o Active Directory, pode verificar se o usuário possui a senha correta, comparando a resposta do cliente a um valor computado com base na credencial associada com o usuário no armazenamento de identidades. Se a resposta corresponder ao valor computado, supõe-se que o usuário saiba a senha secreta, e ele será autenticado.

Em geral, a autenticação Digest não é tão segura quanto o protocolo Kerberos versão 5, porque ela depende de senhas fortes para proteger contra ataques no mecanismo de desafio/resposta. Contudo, como a senha em texto não criptografado não é apresentada ao servidor durante a autenticação, é melhor que a autenticação Básica ou baseada em formulários. O SSL e o TLS são usados freqüentemente para proteger a autenticação Digest contra ataques.

A autenticação Digest não é tão bem dimensionada quanto o protocolo Kerberos versão 5 na maioria dos cenários, mas ela funcionará em cenários nos quais o protocolo Kerberos não funcionará. Um exemplo é a autenticação em sites externos.

A autenticação Digest oferece SSO somente para proteger informações que estão disponíveis por meio de uma única URL da Web. Se os usuários navegarem para outro site ou mesmo para outro servidor no mesmo site, normalmente eles precisarão inserir suas credenciais novamente.

Autenticação baseada em formulários

A autenticação baseada em formulários depende de formulários de logon em páginas da Web para coletar credenciais de usuários, quase sempre na forma de um nome de usuário e uma senha em texto não criptografado. Por isso, este tipo de autenticação não é um protocolo de autenticação entre um cliente e um servidor no mesmo sentido que o protocolo Kerberos versão 5 ou a autenticação Digest, descritos na seção anterior.

A autenticação baseada em formulários exige extremo cuidado para que um aplicativo que ofereça suporte a ela seja protegido de forma adequada, e a Microsoft não recomenda utilizá-la sem SSL. Uma vulnerabilidade explorada em um aplicativo que usa a autenticação baseada em formulários pode permitir que o invasor colete dados de senhas em texto não criptografado, o que seria um grave risco de segurança para os dados de aplicativos de toda a organização e para a própria rede.

Como o aplicativo que executa a autenticação baseada em formulários recebe credenciais de usuários em texto não criptografado, ele pode optar pela autenticação em armazenamentos de usuários diferentes do Active Directory. A Microsoft não recomenda essa abordagem na maioria dos casos, pois armazenamentos de identidades adicionais podem comprometer a solução de gerenciamento de acesso e identidades.

Os desenvolvedores de aplicativos que implementam a autenticação baseada em formulários são incentivados a autenticar usuários no Active Directory usando a ligação LDAP ou uma API do Windows, como LogonUser(), para validar as credenciais dos usuários e, opcionalmente, gerar um contexto de segurança como descrito na seção "Autorização", mais adiante neste capítulo.

Os aplicativos que implementam a autenticação baseada em formulários normalmente usam cookies HTTP ou modificações de URLs para fornecer o SSO para o usuário. O ASP.NET oferece funcionalidade para proteger os cookies contra leitura não autorizada usando criptografia e contra alterações usando assinaturas digitais.

O documento "Desenvolvendo aplicativos ASP.NET com reconhecimento de identidades", desta série, fornece mais detalhes sobre como os desenvolvedores podem usar a autenticação baseada em formulários na plataforma Windows.

Autenticação básica

Da mesma forma que a autenticação baseada em formulários, a autenticação básica não é realmente um protocolo de autenticação de rede, pois ela não protege criptograficamente as credenciais do usuário ao fazer a autenticação em um recurso de rede. Como na autenticação baseada em formulários, o servidor que realiza a autenticação recebe as credenciais do usuário em texto sem criptografia e usa APIs do Windows para autenticar o usuário. Como na autenticação baseada em formulários, o desenvolvedor e o administrador do sistema que estiverem implantando essa técnica de autenticação deverão se esforçar ao máximo para proteger o aplicativo ou o servidor contra qualquer tipo de comprometimento. Por esse motivo, a Microsoft recomenda que você não use a autenticação básica sem SSL. A autenticação básica possui as mesmas características de SSO que a autenticação Digest.

Logon único

Uma parte importante de qualquer discussão sobre autenticação é o conceito de SSO (Logon único). Existem várias abordagens disponíveis para implantar o SSO como parte do processo de autenticação:

• SSO integrado à área de trabalho.

• SSO da Web.

• Mapeamento de credenciais ou SSO corporativo.

O único objetivo do SSO é eliminar a necessidade de entradas adicionais de credenciais de usuários e não julgar o nível de segurança da autenticação envolvida. Alguns tipos de SSO podem ser preferíveis em relação a outros por motivos de segurança.

Além disso, SSO de Extranet e SSO de Intranet são termos usados para fazer referência às técnicas de utilização do SSO em cenários de extranet ou de intranet. Geralmente, o SSO de Extranet é baseado na Web, enquanto o SSO de Intranet pode envolver vários tipos de aplicativos e serviços, incluindo aplicativos Web, aplicativos de cliente espesso e sessões de terminais.

Logon único integrado à área de trabalho

O logon seguro exige que o usuário comprove sua identidade em uma rede, mas ter que digitar uma senha diversas vezes para acessar vários recursos é uma experiência indesejável para o usuário. A plataforma Microsoft Windows aproveita a capacidade de usar uma única identidade de usuário (mantida no Active Directory) em toda a rede. Como as credenciais usadas para fazer logon na estação de trabalho normalmente serão as mesmas usadas para acessar recursos de rede, as credenciais de logon do usuário (a combinação de nome de usuário e senha) são armazenadas em cache localmente, pela autoridade de segurança local (LSA) no sistema operacional cliente. Quando um usuário faz logon no domínio, a autenticação do Windows usa as credenciais em cache para fornecer SSO ao fazer a autenticação em recursos da rede.

Uma boa segurança exige que um usuário forneça uma identidade autenticada para acessar um recurso da rede. O SSO permite que os usuários se autentiquem uma vez no sistema para acessar todos os aplicativos e fontes de dados que estão aptos a usar, sem precisar inserir outra identificação de conta ou senha.

O protocolo de autenticação Kerberos versão 5, o NTLM e técnicas de autenticação de cartão inteligente são integrados ao processo de logon da área de trabalho nos sistemas operacionais cliente e servidor da Microsoft para fornecer uma experiência de SSO aos usuários em um domínio ou floresta do Windows na intranet de uma organização. O Active Directory fornece a terceira parte confiável que permite que os servidores validem usuários sem precisar armazenar informações sobre cada usuário localmente.

Mecanismos de confiança avançados, como relações de confiança entre florestas no Windows Server 2003, permitem que as identidades de uma floresta aproveitem o SSO ao acessar recursos em outras florestas.

Logon único da Web

À medida que mais empresas implantam aplicativos Web baseados em extranets e intranets que são usados por funcionários, parceiros e clientes, a capacidade de fornecer ao usuário uma experiência de SSO torna-se muito importante.

Os aplicativos Web são diferentes dos aplicativos cliente/servidor "espessos" tradicionais, pois freqüentemente eles dependem do servidor Web para implementar a autenticação. Essa dependência permite uma abordagem comum para adicionar mecanismos de autenticação em um único aplicativo (o servidor Web), resolvendo o problema de autenticação em um grande número de aplicativos hospedados pelo servidor. Em um ambiente de intranet, os produtos de servidor e cliente da Microsoft fornecem Logon único da Web ou SSO da Web, implementando o protocolo de autenticação Kerberos versão 5 no Internet Explorer e no IIS 6.0, conforme descrito no documento "Gerenciamento de acesso à intranet", nesta série.

Infelizmente, a implementação do Kerberos que funciona bem no cenário de intranet não funciona bem para aplicativos da Internet na extranet de uma organização. A distinção entre o SSO da Web para intranets e extranets resulta de uma combinação de três fatores:

• As dificuldades inerentes da implantação de um KDC (centro de distribuição de chaves) da Internet, como um controlador de domínio do Active Directory.

• O fato de vários navegadores não oferecerem suporte à autenticação Kerberos sobre HTTP.

• Vulnerabilidades inerentes do protocolo KDC.

Uma discussão detalhada sobre as dificuldades inerentes da implantação de um KDC da Internet está além do escopo deste documento, mas o problema representa uma barreira importante à implantação.

Geralmente, o segundo problema é o de mais importância em implantações de extranets. Ao contrário das implantações internas, nas quais os padrões de software podem ser impostos, poucas organizações podem determinar o tipo e a versão do software de navegador usado por clientes externos e parceiros comerciais para acessar aplicativos externos. O Microsoft Internet Explorer versão 6.0 ou superior é o único navegador disponível comercialmente que oferece suporte à autenticação Kerberos sobre HTTP.

A abordagem padrão para resolver o problema do SSO em vários aplicativos Web é usar "cookies" de sessão, como descrito no mecanismo de gerenciamento de estado do HTTP, definido pelo IETF RFC 2109 no site Request for Comments (em inglês). Vários ISVs (fornecedores independentes de software) oferecem soluções que permitem a implantação do SSO da Web nos aplicativos Web de extranet.

Os serviços do Microsoft Passport, descritos detalhadamente em uma seção anterior, também fornecem ao usuário uma experiência de SSO em sites que oferecem suporte à autenticação do Passport.

Você pode combinar técnicas de SSO da Web com técnicas de SSO corporativo, como um site do SharePoint Portal Server que inclui uma parte da Web para acessar dados de aplicativos herdados dentro de um diretório de autenticação exclusivo. Neste exemplo, uma técnica de SSO da Web oferece acesso ao site e uma técnica de SSO corporativo oferece acesso aos dados de aplicativos herdados.

Mapeamento de credenciais e logon único corporativo

O SSO corporativo define qualquer técnica que use uma forma de mapeamento de credenciais para proporcionar uma experiência de SSO. O mapeamento de credenciais é necessário, pois diferentes armazenamentos de identidades ou diretórios estão envolvidos na autenticação. Um serviço (que pode ser executado no cliente ou em um servidor) faz logon no aplicativo de destino em nome da conta, simulando a experiência do SSO. Esse serviço deve examinar as credenciais apropriadas (contas, senhas e assim por diante) de um armazenamento ou banco de dados de mapeamentos de credenciais.

O Microsoft BizTalk® Server, o Host Integration Server, o SharePoint® Portal Server, o Gerenciador de Credenciais do Windows e produtos de ISVs como o PassLogix, o Protocom e o Version3 usam várias técnicas de SSO corporativo com sistemas herdados, aplicativos que usam seus próprios diretórios para autenticação e até mesmo para acessar recursos em domínios não confiáveis do Windows.

O SSO corporativo fornece uma experiência de usuário melhor do que nenhum SSO com vários armazenamentos de identidades não confiáveis, como acontece em várias organizações. A abordagem de SSO corporativo deve ser integrada com as abordagens de gerenciamento de senhas e configuração, para assegurar uma experiência transparente e minimizar as chamadas à assistência técnica. Essa abordagem também fornecerá a melhor experiência do usuário e, ao mesmo tempo, minimizará o custo total de propriedade.

Observação O SSO integrado à área de trabalho é preferível ao SSO corporativo, pois está fortemente integrado ao diretório escolhido e não exige a configuração e administração adicionais de diretórios redundantes nem um banco de dados de mapeamento de credenciais.

Para obter mais informações sobre o mapeamento de credenciais através do SSO corporativo, consulte o documento "Gerenciamento de acesso à intranet", nesta série.

Gerenciador de Credenciais do Windows

O Windows XP Professional e o Windows Server 2003 incluem um recurso de Nomes de usuário e senhas armazenados que também fornece a funcionalidade de gerenciamento de credenciais. Dependendo do tipo de autenticação tentada, esse componente pode salvar credenciais do usuário e reutilizá-las durante tentativas de acesso futuras.

Figura 6.2. Os Nomes de usuário e senhas armazenados permitem o SSO para vários conjuntos de credenciais

Se o aplicativo não permitir que o usuário salve credenciais, ele deverá acessar os Nomes de usuário e senhas armazenados manualmente para configurar uma credencial para esse recurso. O Gerenciador de Credenciais oferece suporte aos seguintes tipos de credenciais:

• Combinações de nome de usuário/senha para o protocolo Kerberos versão 5 e a autenticação NTLM.

• Certificados digitais X.509 para autenticação de clientes usando SSL/TLS.

• Credenciais do Microsoft Passport para autenticação da Web.

Observação Você pode usar o Gerenciador de Credenciais do Windows para fornecer uma experiência de SSO da Web com autenticação de certificados de cliente X.509 usando SSL/TLS. Por padrão, os usuários verão um prompt solicitando a escolha de um certificado para autenticação, sempre que tiverem mais de um certificado válido. O Gerenciador de Credenciais pode fazer com que o certificado correto seja apresentado automaticamente na autenticação em um recurso específico.

Para obter mais informações sobre o Gerenciador de Credenciais do Windows, consulte o documento "Gerenciamento de acesso à intranet", nesta série.

Autorização

Autorização é o processo de um aplicativo ou plataforma determinar o acesso a um recurso através da comparação dos direitos do usuário com a configuração de segurança do recurso. Por exemplo, um usuário pode se autenticar em um servidor de arquivos e, em seguida, o servidor pode determinar se o usuário pode ler, gravar ou excluir um arquivo.

Aplicativos integrados com o sistema Windows Server 2003 e o Active Directory usam os recursos internos do sistema operacional para executar a autorização.

O Windows Server 2003 oferece suporte a dois mecanismos de autorização: o modelo de representação baseado em ACLs (listas de controle de acesso) do Windows e o novo Gerenciador de Autorização baseado em funções. Além disso, os aplicativos Microsoft ASP.NET podem usar as funções do ASP.NET para autorização. Os dois mecanismos são discutidos detalhadamente nas seções seguintes.

Representação do Windows e listas de controle de acesso

O Microsoft Windows NT 3.1 introduziu o modelo de representação e ACL para fornecer autorização a serviços e aplicativos. A representação é o resultado de se combinar intimamente os mecanismos de autenticação e autorização a fim de obter uma experiência transparente para o usuário e um fácil gerenciamento.

Um pacote de autenticação faz a autenticação do usuário e, em seguida, cria um "contexto de segurança" para esse usuário. O contexto de segurança representa a identidade e os grupos aos quais o usuário pertence, além dos direitos do usuário. Depois que o pacote de autenticação gera o contexto de segurança, o aplicativo ou serviço o recebe e o utiliza para permitir acesso aos recursos. Em outras palavras, o serviço pode representar o usuário localmente ao tentar acessar recursos usando o contexto de segurança do usuário para obter acesso, em vez de usar o próprio contexto do serviço.

Este é um conceito importante, pois a maioria dos serviços possui privilégios amplos em um computador. Por exemplo, o serviço SMB (bloco de mensagens de servidor), que oferece serviços de arquivo e impressão em servidores que executam o Windows, opera como sistema local e tem acesso a qualquer recurso. Para limitar o acesso de usuários a arquivos de acordo com regras estabelecidas pelo proprietário do arquivo ou administrador do sistema, o serviço SMB representa o usuário remoto.

A outra parte do modelo de autorização do Windows é a ACL baseada em objetos. A ACL de um objeto define o nível de acesso que as entidades de segurança (usuários ou grupos) têm em relação ao objeto. Por exemplo, a ACL em um arquivo poderia definir que um usuário tem o direito de ler um arquivo, enquanto outro usuário tem o direito de ler e excluir o arquivo.

O sistema operacional, mais especificamente o Gerenciador de Objetos do NT, tem a decisão final sobre o acesso aos objetos que usam esse modelo. O Gerenciador de Objetos do NT faz isso através da comparação do contexto de segurança do usuário com a ACL no objeto. Como o sistema operacional tem a decisão final, o modelo de representação/ACL possui características de segurança boas para cenários nos quais vários aplicativos podem acessar um recurso do sistema.

Contudo, é possível melhorar o modelo de representação/ACL em algumas áreas, incluindo:

• Desempenho. Para serviços que entregam conteúdo a vários usuários diferentes de uma vez, o custo de usar a representação para alternar entre contextos pode gerar uma carga adicional do servidor, o que pode afetar a escalabilidade dos aplicativos.

• Flexibilidade. Usando o modelo de representação, não é possível para o desenvolvedor de aplicativos ou administrador do serviço criar novos grupos ou funções para usuários sem alterar as associações em grupos no nível de domínio. Os administradores de domínios evitam criar muitos grupos para um único aplicativo a ser usado, o que resulta na necessidade de os desenvolvedores de aplicativos trabalharem com o que já existe.

• Regras comerciais. O modelo de representação/ACL expressa a autorização para objetos de maneira adequada, mas é difícil descrever a lógica das regras comerciais, como a hora do dia ou outra lógica de tempo de execução. Por exemplo, você pode impor uma diretiva de autorização que permita que apenas determinados indivíduos executem uma determinada ação durante horários específicos.

Para superar esses problemas, o Windows Server 2003 inclui o Gerenciador de Autorização para administradores de sistemas e desenvolvedores de aplicativos. A versão do Windows 2000 do Gerenciador de Autorização está disponível na página de download do Windows 2000 Authorization Manager Runtime (em inglês) no Microsoft.com.

Gerenciador de Autorização do Windows Server 2003

O Gerenciador de Autorização do Windows Server 2003 é uma nova interface de controle de acesso baseada em funções (RBAC). O Gerenciador de Autorização fornece aos desenvolvedores a capacidade de:

• Simplificar a administração do controle de acesso de aplicativos.

• Fornecer um modelo de desenvolvimento simplificado e natural.

• Permitir decisões de autorização flexíveis e dinâmicas.

Para uma determinada tarefa, a interface do Gerenciador de Autorização organiza os usuários em várias funções dentro do aplicativo e lhes concede acesso à medida que representam essas funções. A figura a seguir mostra três usuários diferentes acessando um aplicativo. O Gerenciador de Autorização mapeia cada usuário em uma função definida no armazenamento da diretiva de autorização.

Figura 6.3. Como o Gerenciador de Autorização define e aplica funções

O Gerenciador de Autorização proporciona a capacidade de definir e manter tarefas e funções lógicas de acordo com as necessidades de cada aplicativo. A representação do modelo de segurança de acordo com uma estrutura organizacional simplifica a administração do controle de acesso. Além disso, as definições de tarefa e função são úteis para a modelagem de fluxos de trabalho de aplicativos e para fornecer aos desenvolvedores um ambiente natural focado em aplicativos através do Gerenciador de Autorização.

O Gerenciador de Autorização também qualifica dinamicamente os direitos concedidos em tempo de execução. Este recurso resolve o problema de autorização distinta que existe para aplicativos Web de linha de negócios (LOB), como aplicativos de relatórios de despesas ou aplicativos de compras baseados na Web.

Para esses aplicativos, com freqüência o acesso a objetos persistentes bem definidos não determina as decisões de autorização. Em vez disso, eles exigem a verificação de um fluxo de trabalho ou um conjunto de várias operações distintas, como a consulta a um banco de dados e o envio de uma mensagem de email. Essas decisões de acesso não se baseiam apenas na associação a grupos de tokens, mas também na lógica comercial, como o valor enviado em um aplicativo de despesas ou a verificação da conclusão do fluxo de trabalho. Aplicativos como esses, que não possuem objetos persistentes bem definidos, não têm onde colocar uma ACL. Estas decisões de acesso dinâmico estão imediatamente disponíveis na forma de regras comerciais dinâmicas (chamadas BizRules) fornecidas pelo Gerenciador de Autorização.

As BizRules são implementadas normalmente usando um script do Microsoft Visual Basic® Scripting Edition ou uma rotina JScript® executada quando os direitos de acesso são verificados durante a execução do aplicativo. Se as BizRules tiverem êxito, o aplicativo executará as operações solicitadas.

A diretiva do gerenciador de autorização que define as tarefas e funções lógicas usadas por um aplicativo pode ser armazenada em uma partição do aplicativo no Active Directory ou no Modo de Aplicativo do Active Directory, ou ainda em um arquivo XML no servidor ou na rede.

Para obter mais informações sobre o RBAC usando o Gerenciador de Autorização do Windows Server 2003, consulte a página Conceitos referentes ao Gerenciador de autorizações no TechNet.

O IIS 6.0 fornece um exemplo de como um aplicativo pode usar a estrutura baseada em funções do Gerenciador de Autorização. O IIS 6.0, fornecido com o Windows Server 2003, se integra ao Gerenciador de Autorização para implementar a autorização de URLs. Essa integração permite que os administradores de aplicativos Web controlem o acesso a URLs com base em funções personalizadas de usuários, consultas LDAP e BizRules.

A autorização do acesso de usuários a páginas da Web no IIS 6.0 pode exigir o gerenciamento de várias DACLs (listas de controle de acesso condicionais) nos recursos usados pelos aplicativos Web. Os recursos de aplicativos Web podem incluir arquivos de páginas da Web, registros de bancos de dados e chaves do Registro. A manutenção de DACLs exige que os administradores saibam precisamente os requisitos de permissão back-end necessários para cada objeto, para executar tarefas relevantes no aplicativo Web.

A autorização de URL do IIS 6.0 permite que os administradores simplifiquem o gerenciamento de acesso através da autorização de acesso de usuários às URLs que formam um aplicativo Web. Quando um cliente solicita uma URL, a autorização de URL do IIS 6.0 valida o acesso do usuário com base em suas funções. Se necessário, o aplicativo Web pode restringir ainda mais o acesso a recursos e operações, usando a estrutura baseada em funções do Gerenciador de Autorização.

Autorização do ASP.NET

O ASP.NET oferece um modelo de autorização baseado em funções que usa grupos do Active Directory, bem como funções derivadas de aplicativos. Existem algumas semelhanças entre o RBAC do Gerenciador de Autorização e a autorização baseada em funções do ASP.NET, mas eles são implementados por meio de mecanismos separados. As funções do ASP.NET são mais úteis para aplicativos autônomos que provavelmente não pertencem a um conjunto maior de aplicativos.

Relações de confiança e federação

Existem situações nas quais pode ser necessário vincular dois ou mais armazenamentos de identidades separados, como quando é necessário implementar uma organização de parceria ou usar estruturas separadas de diretórios internos e externos. O link permite que os usuários que podem se autenticar em um armazenamento de identidades se autentiquem em um segundo, apesar de não possuírem identidades digitais no segundo armazenamento de identidades. Essa organização é chamada de relação de confiança.

As relações de confiança existem entre territórios separados, nas quais um território define um limite de segurança. Em ambientes do Windows NT e do Active Directory, você pode estabelecer relações de confiança entre domínios. No Windows Server 2003, é possível estabelecer níveis de confiança mais altos entre florestas. Contudo, os domínios em uma floresta possuem uma relação de confiança implícita entre si.

Os aplicativos integrados com o Windows Server 2003 e o Active Directory usam os recursos internos do sistema operacional para estabelecer e manter a confiança.

Gerenciando relações de confiança

Em um nível alto, as relações de confiança simplesmente fornecem uma forma de autenticação entre territórios. Os mecanismos de confiança, contudo, se tornam complicados porque há várias tarefas que devem ocorrer entre territórios para tornar a autenticação e a autorização subseqüente realmente úteis.

O restante desta seção discute os tipos de confiança disponíveis na plataforma Windows e como usá-los para resolver problemas de gerenciamento de acesso e identidades.

Relações de confiança externas

O Microsoft Windows NT Server apresentou o conceito de relação de confiança entre domínios. A relação de confiança de domínio do Windows NT ou relação de confiança externa, como é chamada atualmente, permitiu que um domínio do Windows NT confiasse em outro domínio do Windows NT, como uma autoridade para autenticar usuários pertencentes a esse domínio. As relações de confiança externas podem ser uni ou bidirecionais, e a direção da confiança determina a direção na qual a autenticação e o acesso podem ocorrer, como mostrado na figura a seguir.

Figura 6.4. A relação entre domínios confiantes e confiáveis

O modelo do Windows NT Server 4.0 era muito flexível e permitia que os departamentos implementassem domínios do Windows NT 4.0 conforme o necessário, em um padrão de implantação local de baixo para cima. O problema era que, conforme as empresas muito grandes colocavam mais e mais domínios online, o gerenciamento das relações de confiança externas se tornou um problema grave. Como cada domínio implantado pode ter n relações de confiança, o número total de relações de confiança a serem gerenciadas cresce rapidamente à medida que o número de domínios é expandido. Uma pequena empresa com quatro domínios pode ter que gerenciar apenas 12 relações de confiança diferentes, mas uma empresa maior, com 10 domínios, poderia ter que gerenciar 90 relações de confiança. Uma empresa com 100 domínios teria que gerenciar um número muito maior de relações de confiança.

Florestas do Windows 2000 Server

Para simplificar o gerenciamento de relações de confiança em organizações maiores, o Microsoft Windows 2000 Server introduziu o conceito de floresta do Active Directory. A floresta do Active Directory preserva a flexibilidade do modelo de confiança de baixo para cima do Windows NT Server 4.0 quando necessário, mas torna o problema de como realizar o gerenciamento de relações de confiança de cima para baixo muito mais fácil, como mostrado na figura a seguir.

Figura 6.5. Uma única floresta do Windows 2000 Server

Esta figura representa uma organização com uma única floresta do Windows 2000 Server. As relações de confiança em uma floresta são implícitas, fornecendo a mesma funcionalidade que relações de confiança externas bidirecionais, mas são criadas automaticamente quando domínios (imaginados como árvores em uma floresta) são adicionados à mesma floresta. Os domínios em uma floresta têm uma hierarquia, que permite que a rede de uma organização espelhe os negócios da organização.

Infelizmente, o Windows 2000 Server não fornecia a resposta final para as relações de confiança. Presumia-se que a maioria das empresa implantaria uma única floresta compreendendo toda sua rede e seus recursos. Contudo, por vários motivos, não foi isso que aconteceu.

Por exemplo, algumas organizações muito grandes não possuem um grupo administrativo confiável central com a responsabilidade de gerenciar todos os recursos da organização. Nessas organizações, portanto, existem limites de segurança naturais entre as diferentes partes da organização que a arquitetura do serviço de diretório deve implementar. Outro exemplo comum é a necessidade de se manter florestas de intranet e extranet separadas. É possível criar a extranet como um domínio da floresta de intranet, mas várias organizações gostariam de isolar melhor a extranet e a intranet, por motivos de segurança.

Para obter mais informações sobre as características dos limites de segurança de domínios e florestas do Windows, consulte "Creating and Enhancing Security Boundaries" (em inglês), no Microsoft.com.

Para uma organização que possui várias florestas com o Active Directory do Windows 2000, mas que deseja usar a relação de confiança entre os domínios de diferentes florestas, é necessário estabelecer relações de confiança explícitas entre cada domínio de uma floresta e cada domínio da outra floresta. Conseguir essa configuração é apenas um pouco menos complexo do que estabelecer relações de confiança entre cada domínio do Windows NT Server 4.0; então, uma solução melhor para esse problema tornou-se claramente necessária.

Relação de confiança entre florestas do Windows Server 2003

Para facilitar a implantação de várias florestas, o Windows Server 2003 estabeleceu o conceito de relação de confiança entre florestas. Uma relação de confiança entre florestas permite que os administradores estabeleçam uma federação entre duas florestas do Active Directory com uma única relação de confiança para fornecer uma experiência transparente de autenticação e autorização entre elas. Uma relação de confiança entre florestas é um único link de confiança entre os domínios raiz de duas florestas; ela estabelece uma confiança transitiva entre todos os domínios de cada floresta. Por exemplo, se a Floresta A confiar na Floresta B, todos os domínios da Floresta A confiarão em todos os domínios da Floresta B por meio da relação de confiança entre florestas. A figura a seguir ilustra esse conceito:

Figura 6.6. Relações de confiança entre florestas do Windows Server 2003

Contudo, as relações de confiança entre florestas não são transitivas entre as florestas. Ou seja, se a Floresta A confia na Floresta B e a Floresta B confia na Floresta C, a Floresta A não confia automaticamente na Floresta C.

Para obter mais informações sobre como usar e configurar as relações de confiança entre florestas do Windows Server 2003, consulte a página Planning and Implementing Federated Forests in Windows Server 2003 (em inglês) no Microsoft TechNet.

Usando relações de confiança entre florestas

As relações de confiança entre florestas tornam o conceito de florestas federadas possível no Windows Server 2003. Como mencionado, uma relação de confiança entre florestas habilita uma confiança transitiva entre todos os domínios de duas florestas; a confiança é estabelecida entre os domínios raiz das duas florestas.

As relações de confiança entre florestas podem ser uni ou bidirecionais. Na figura anterior, a Floresta A e a Floresta B possuem uma relação de confiança bidirecional. Por causa disso, os usuários da Floresta A podem se autenticar em recursos da Floresta B e os usuários da Floresta B podem se autenticar em recursos da Floresta A. Além da autenticação, a relação de confiança entre florestas permite a autorização, de forma que os proprietários de recursos de cada floresta possam adicionar entidades da outra floresta a DACLs e grupos, ou criar funções com base nesses grupos.

Usando contas de sombra em vez de relações de confiança

Às vezes, os requisitos de segurança impedirão o uso de mecanismos de confiança do Windows entre florestas. Nesses casos, você pode criar contas de sombra em um dos diretórios para espelhar as contas do outro. A conta de sombra normalmente espelha somente as informações de identidades do território de origem conforme o necessário para o aplicativo ou cenário específico. Para atender aos requisitos de segurança, os atributos de identidades que são particularmente confidenciais não são representados. As informações confidenciais podem incluir dados como o cadastro de pessoa física ou uma senha do usuário.

O conceito de usar contas de sombra para funcionários talvez não seja intuitivo, mas considere o caso no qual uma organização esteja usando uma instância de intranet do Active Directory para autenticação de funcionários, mas também deseje ter uma extranet para uso dos funcionários. As duas opções para a autenticação dos funcionários na extranet são:

• Usar uma relação de confiança de domínio ou entre florestas da rede de perímetro (também conhecida como DMZ, zona desmilitarizada ou sub-rede filtrada) para a intranet.

• Criar contas de sombra na rede de perímetro.

A primeira opção envolve a abertura de várias portas para permitir um caminho através do firewall que separa a rede de perímetro da intranet. Essa opção é aceitável para várias organizações, mas outras exigem o isolamento completo entre suas redes de perímetro e as intranets.

Em organizações que exigem um isolamento rígido entre redes, a utilização de uma conta de sombra pode ser a melhor opção. A Microsoft recomenda a criação de contas de sombra com um mecanismo automatizado, como os disponíveis no Microsoft Identity Integration Server 2003, Enterprise Edition (MIIS 2003 SP1). As contas de sombra podem até aumentar a segurança da rede em determinados cenários, se permitirem mecanismos de autenticação que não sejam baseados em senhas para servidores menos seguros, como os encontrados na extranet. Exemplos disso incluem a autenticação baseada na autenticação de certificados de cliente do SSL 3.0 e do TLS 1.0 ou os mecanismos de autenticação de senha de uso único, como o produto de autenticação de dois fatores SecurID da RSA Security Inc.

Relações de confiança da infra-estrutura de chave pública

Uma PKI (infra-estrutura de chave pública) é um sistema de certificados digitais, CAs (autoridades de certificação) e outras autoridades de registro que verificam e autenticam a validade de cada parte envolvida em uma transação eletrônica através da utilização da criptografia de chaves públicas. Para que isso ocorra, contudo, cada parte deve confiar no emissor do certificado, geralmente uma autoridade de certificação.

Para usuários, computadores e serviços do Windows, a confiança em uma autoridade de certificação será estabelecida quando houver uma cópia do certificado raiz no armazenamento da autoridade de certificação raiz confiável, além de um caminho de certificação válido. Um caminho de certificação válido significa que nenhum dos certificados no caminho de certificação foram revogados ou expiraram. O caminho de certificação inclui todos os certificados emitidos para cada autoridade de certificação na hierarquia de certificação, que vai de uma autoridade de certificação subordinada à autoridade de certificação raiz.

Por exemplo, para uma autoridade de certificação raiz, o caminho de certificação consiste em um certificado, seu próprio certificado auto-assinado. Para uma autoridade de certificação subordinada que está bem abaixo da autoridade de certificação raiz na hierarquia, seu caminho de certificação usa dois certificados: seu próprio certificado e o certificado da autoridade de certificação raiz.

O processo de importação de um certificado raiz no armazenamento da autoridade de certificação raiz confiável é a maneira mais direta de estabelecer uma relação de confiança de PKI entre um computador e os aplicativos hospedados nele. Por exemplo, se um servidor Web da Contoso Pharmaceuticals (uma organização fictícia) possui a autoridade de certificação do certificado raiz da Fabrikam Inc. (outra organização fictícia) instalada no armazenamento da autoridade de certificação raiz, o servidor Web da Contoso confiará em qualquer certificado válido que a autoridade de certificação da Fabrikam emitir. No entanto, esse processo estabelece somente a parte de confiança da transação e não estabelece uma identidade ou um contexto no servidor Web. A criação de um mapeamento de identidade para contexto exige outras ações, como mapear algumas informações no certificado para uma entidade de segurança no Active Directory.

Para obter mais informações sobre a autenticação mútua usando o mapeamento de certificados do Active Directory, consulte a página Step-by-Step Guide to Mapping Certificates to User Accounts (em inglês) no site do Microsoft Windows 2000 Server.

O mecanismo de armazenamento da autoridade de certificação raiz confiável é bastante fácil de implementar, mas ele pode não atender aos requisitos de segurança em cenários complexos a fim de estabelecer uma relação de confiança federada entre duas organizações, como a Contoso e a Fabrikam. Considere um cenário no qual os usuários da Contoso e da Fabrikam podem apresentar certificados válidos para acessar o site da Contoso. O Active Directory externo, nesse caso, conteria mapeamentos de certificados das autoridades de certificação da Contoso e da Fabrikam.

Uma prática poderia ser estabelecer um mapeamento com base no assunto do certificado, por exemplo: E=fred@fabrikam.com. O problema dessa abordagem é que a relação de confiança fica desacoplada. A relação de confiança desacoplada significa que a Contoso deseja confiar totalmente na Fabrikam sem emitir um certificado com o assunto E=fred@contoso.com, onde fred@contoso.com é um usuário da organização Contoso e não um usuário da Fabrikam. Nesse caso, o detentor do certificado poderia obter acesso a dados confidenciais no site da Contoso. Esse problema existe não devido à relação de confiança de PKI ser inerentemente fraca, mas porque as definições do certificado são amplas demais. A resposta para essa questão é um mecanismo de confiança de PKI que possa ser controlado de forma mais precisa, o que permitiria que a Fabrikam emitisse certificados para o domínio @fabrikam.com, mas não para o domínio @contoso.com.

Subordinação qualificada

A certificação cruzada real de hierarquias de autoridades de certificação em uma rede do Windows 2000 não foi possível. A única alternativa disponível era definir CTLs (listas de certificados confiáveis) que confiassem em autoridades de certificação específicas e restringissem o uso de certificados.

A subordinação qualificada, introduzida no Windows 2003 Server, é o processo de certificação cruzada de hierarquias de autoridades de certificação usando restrições básicas de diretivas, nomes e aplicativos para limitar os certificados que são aceitos de hierarquias de autoridades de certificação de parceiros ou de uma segunda hierarquia na mesma organização. Usando a subordinação qualificada, um administrador de autoridade de certificação pode definir claramente quais certificados emitidos pelo PKI de um parceiro são confiáveis para a organização do administrador da autoridade de certificação. A subordinação qualificada também fornece métodos para compartimentalizar e controlar a emissão de certificados em uma organização, de acordo com as orientações das diretivas.

A subordinação qualificada também permite que você estabeleça relações de confiança entre autoridades de certificação em hierarquias de confiança separadas. Esse tipo de relação de confiança também é chamada de certificação cruzada. Com essa relação de confiança, a subordinação qualificada não se limita a autoridades de certificação subordinadas. A confiança entre hierarquias pode ser estabelecida por uma autoridade de certificação subordinada de uma hierarquia e a autoridade de certificação raiz de outra hierarquia.

A subordinação qualificada permite que você estabeleça condições de confiança adicionais dentro e entre os domínios de seu PKI para estender a hierarquia de confiança. Com a subordinação qualificada, as autoridades de certificação subordinadas qualificadas da sua hierarquia de confiança podem ter diferentes regras determinando a forma como elas emitem certificados e como seus certificados podem ser usados.

Um exemplo de como as condições de confiança podem ser usadas para resolver o problema descrito anteriormente, de definições de certificados excessivamente amplas, é usar restrições de espaços para nome ao estabelecer a certificação cruzada entre as hierarquias da Contoso e da Fabrikam. Dessa maneira, a Contoso aceitaria somente certificados de autoridades de certificação da Fabrikam que especificassem um domínio fabrikam.com.

Para obter mais informações sobre a subordinação qualificada, consulte a página sobre Subordinação qualificada no Microsoft TechNet.

Implementando a federação

O gerenciamento de identidades federadas é um processo de tecnologia da informação baseada em padrões que permite a identificação, autenticação e autorização distribuídas através dos limites de plataformas e organizacionais. Os sistemas federados interoperam além dos limites organizacionais e conectam processos que usam diferentes tecnologias, armazenamentos de identidades, abordagens de segurança e modelos de programação. Em um sistema federado, uma organização precisa de uma maneira padronizada e segura de expressar os serviços que estão disponíveis para parceiros e clientes confiáveis. Uma organização também deve implementar as diretivas segundo as quais seus negócios são realizados, como:

• Em que outras organizações e outros usuários ela confia.

• Os tipos de credenciais e solicitações que ela aceita.

• Quais diretivas de privacidade ela impõe.

O Microsoft Windows Server 2003 R2 apresenta o ADFS (Serviços de Federação do Active Directory), que permite que as organizações compartilhem as informações de identidades de um usuário com segurança. O ADFS fornece tecnologias de logon único da Web para autenticar um usuário em vários aplicativos Web durante uma única sessão online. O ADFS faz isso compartilhando seguramente a identidade digital e os direitos, ou ""declarações", além dos limites corporativos e de segurança.

O ADFS funciona com o Active Directory e o ADAM (Modo de Aplicativo do Active Directory). Especificamente, o ADFS funciona com implantações do Active Directory em toda a empresa ou de instâncias do ADAM. Ao trabalhar com o Active Directory, o ADFS pode tirar proveito das tecnologias de autenticação forte do Active Directory, incluindo Kerberos, certificados digitais X.509 e cartões inteligentes. Ao trabalhar com o ADAM, o ADFS usa a Ligação LDAP para autenticar usuários.

O ADFS dá suporte à autenticação e autorização distribuídas pela Internet. O ADFS pode ser integrado à solução de gerenciamento de acesso existente em uma organização ou departamento para traduzir os termos usados na organização em declarações que estejam de acordo como parte de uma federação. O ADFS pode criar, proteger e verificar as declarações que se movem entre as organizações. Ele também pode auditar e monitorar a atividade entre organizações e departamentos para ajudar a garantir a realização de transações seguras.

Para obter mais informações sobre o ADFS, consulte Overview of Active Directory Federation Services (ADFS) in Windows Server 2003 R2 (em inglês) no Microsoft.com.

Auditoria de segurança

A auditoria fornece um meio de monitorar eventos do gerenciamento de acesso e alterações em objetos de identidade. Normalmente, a auditoria de segurança é usada para monitorar a ocorrência de problemas e violações de segurança. Tecnologias como o log de eventos de segurança do Windows, a interface WMI e produtos como o MOM 2005 SP1 podem fornecer auditoria e relatórios de segurança abrangentes.

Auditoria dos serviços de diretório

O Active Directory e o ADAM estão totalmente integrados à auditoria do Windows Server 2003. O log de eventos de segurança do Windows reflete as alterações em objetos e atributos de diretório, bem como a diretiva de autorização de objetos e atributos de diretório, de esquema e da Diretiva de Grupo. Você controla totalmente a configuração de eventos passíveis de auditoria que podem ser baseados no êxito, na falha ou na ação tentada.

Auditoria da autenticação

Os mecanismos de autenticação do Windows descritos acima geram auditorias no log de eventos de segurança do Windows. Você pode configurar as auditorias que serão geradas (como a falha ou êxito da autenticação) usando a Diretiva de Grupo ou pode configurar cada servidor manualmente.

O Windows Server 2003 também fornece controle preciso sobre eventos de autenticação através de sua categorização de acordo com o tipo de autenticação. Por exemplo, um tipo de auditoria controla logons de console, enquanto outro controla tentativas de autenticação em recursos da rede. As auditorias de autenticação sempre podem ser rastreadas em uma entidade de segurança exclusiva.

Depois que o usuário tiver se autenticado no armazenamento de identidades, a próxima etapa será especificar o que ele pode acessar. A autorização é o processo que controla o acesso a recursos.

Auditoria da autorização

A plataforma Windows Server oferece suporte completo à auditoria de ações de autorização. Para o modelo de representação/ACL, o Gerenciador de Objetos do NT gera relatórios de auditoria do acesso a recursos de acordo com a configuração da auditoria. Você pode impor essa configuração através da Diretiva de Grupo ou manualmente em cada servidor. Como o sistema gera essas auditorias, o evento de auditoria aparecerá no log de eventos de segurança do sistema.

Os recursos de configuração de auditoria são precisos, permitindo que você especifique, por exemplo, que deseja auditar somente as tentativas de acesso a arquivos que falharam. Como os mecanismos de autenticação e autorização estão fortemente integrados, a auditoria da autorização especifica a entidade de segurança que acessa o recurso de acordo com seu identificador de segurança (SID) exclusivo.

O Gerenciador de Autorização oferece suporte à auditoria em tempo de execução e à auditoria de alterações de diretiva do Gerenciador de Autorização. A auditoria em tempo de execução usa auditorias de falhas ou êxitos para relatar a inicialização de aplicativos, a criação e exclusão de contexto e o acesso a objetos. A auditoria de alterações de diretiva do Gerenciador de Autorização pode relatar qualquer alteração ao armazenamento de diretivas, incluindo auditorias sobre a diretiva e a definição da diretiva.

A autenticação e a autorização em um único território de segurança ou floresta do Active Directory compõem um processo relativamente direto. Contudo, o gerenciamento de acesso e identidades freqüentemente precisa lidar com a necessidade de vincular dois territórios de segurança separados, o que exige a implementação de alguma forma de relação de confiança, entre serviços de diretório ou organizações. O próximo capítulo aborda esse requisito.

Auditoria de relações de confiança

O Windows Server 2003 faz a auditoria completa da configuração de confiança em um nível detalhado. Você pode auditar eventos para a criação, exclusão e modificação de relações de confiança. Os eventos de auditoria de relações de confiança aparecem no log de eventos de segurança.

Neste artigo

• Capítulo 1: Introdução ao documento de conceitos essenciais
• Capítulo 2: Terminologia e iniciativas
• Capítulo 3: Tecnologias de gerenciamento de acesso e identidades da Microsoft
• Capítulo 4: Serviços de diretório
• Capítulo 5: Gerenciamento do ciclo de vida de identidades
• Capítulo 6: Gerenciamento de acesso
• Capítulo 7: Aplicativos
• Links
• Agradecimentos

Download

Obtenha a Série de gerenciamento de acesso e identidades da Microsoft

Notificações de atualização

Inscreva-se para receber informações sobre atualizações e novas versões

Comentários

Envie seus comentários ou suas sugestões

6 de 9