Gerenciamento de acesso e identidades

por Fredrick Chong - Microsoft Corporation

Outros artigos do JOURNAL no MSDN

Julho de 2004

Resumo: Fredrick Chong aborda os princípios e as vantagens da SOA (Service Oriented Architecture), especificamente sobre sua relação com os desafios técnicos em gerenciamento de acesso e identidades e, secundariamente, para ajudar o leitor a obter um entendimento sobre as questões mais comuns sobre gerenciamento de identidades. (20 páginas impressas)

Nesta página

Visão geral
Introdução
Anatomia de uma identidade digital
Estrutura de gerenciamento de acesso e identidades
Desafios do gerenciamento de acesso e identidades
Gerenciamento de qualificações
Auditoria
Conclusões
Referências

Visão geral

Até o momento, muitos tomadores de decisões técnicas de grandes ambientes de TI ouviram falar dos princípios e vantagens da SOA (Service Oriented Architecture). Apesar disso, poucas organizações de TI já estão em condições de transformar as bases teóricas da SOA em ações práticas de TI.

Durante o último ano, alguns arquitetos de soluções individuais de minha equipe tentaram separar a essência prática da SOA nas seguintes áreas: Gerenciamento de acesso e identidades, Gerenciamento de serviços, Agregação de entidades e Integração de processos. Essas quatro áreas técnicas principais apresentam desafios técnicos significativos a serem vencidos, mas fornecem as bases críticas de TI para ajudar as empresas a aproveitarem as vantagens da SOA.

Observe que nossas interações freqüentes com arquitetos nas empresas nos permitem comparar, sintetizar e categorizar os desafios práticos da SOA nessas áreas. Nossa equipe organiza os Strategic Architect Forums que ocorrem várias vezes por ano em todo o mundo. Nesses eventos, administramos pequenos grupos de discussão para descobrir os pontos difíceis e a orientação técnica que os clientes estão procurando. Os comentários de nossos clientes têm sido bastante consistentes: as questões de gerenciamento de identidades, agregação de dados, gerenciamento de serviços e integração de processos comerciais foram citadas repetidamente como os principais obstáculos à realização de organizações mais ágeis e eficientes.

Além disso, nossa equipe também realiza projetos de viabilidade junto a clientes para se aprofundar nos requisitos e nas questões de implementação reais. Foi através dessas combinações de parcerias amplas e profundas com clientes que nós, da equipe de estratégia de arquitetura, tiramos nossas conclusões quanto às quatro áreas significativas para investimentos de TI.

O foco principal deste artigo é fornecer uma visão geral dos desafios técnicos em uma dessas áreas, especificamente o gerenciamento de acesso e identidades e, secundariamente, ajudar o leitor a chegar a um entendimento das questões mais comuns nesse assunto tão amplo.

Introdução

Gerenciamento de acesso e identidades (I&AM, Identity and Access Management) é um termo relativamente novo, que tem diferentes significados para cada pessoa. Freqüentemente, os profissionais de TI costumavam classificar seu significado dentro de certas áreas de problemas relacionados a identidades e à segurança que costumavam enfrentar. Por exemplo, o I&AM já foi considerado um sinônimo de início de sessão universal, sincronização de senha, metadiretório, início de sessão universal da Web, autorizações baseadas em função e idéias semelhantes.

O objetivo principal deste artigo é fornecer ao leitor uma visão geral sucinta e abrangente do significado do I&AM. Para isso, estruturamos as informações do artigo de forma a ajudar a responder as seguintes perguntas:

• O que é uma identidade digital?

• O que significa gerenciamento de acesso e identidades?

• Quais são os principais componentes de tecnologia do I&AM?

• Como os componentes do I&AM se relacionam entre si?

• Quais são os principais desafios de arquitetura no I&AM?

Anatomia de uma identidade digital

As identificações pessoais na sociedade atual podem ter várias formas diferentes. Alguns exemplos são as carteiras de motorista, passaportes, cartões funcionais e carteirinhas de clubes. Essas formas de identificação geralmente contêm informações de certa forma exclusivas do portador, por exemplo, nomes, endereços e fotos, bem como informações sobre as autoridades que emitiram os cartões, por exemplo, uma insígnia do departamento de trânsito local.

A noção de identidades no mundo físico é bem compreendida, mas não se pode dizer o mesmo sobre a definição de identidades digitais. Para ajudar a definir a base para as outras discussões neste artigo, esta seção descreve uma das noções de identidade digital, como ilustrado na Figura 1. Nossa definição de identidade digital consiste nas seguintes partes:

• Identificador Informação que identifica o sujeito da identidade de maneira exclusiva em um dado contexto.1 Exemplos de identificadores são endereços de email, nomes distintos X500 e GUIDs (identificadores globais exclusivos).

• Credenciais Dados públicos ou particulares que poderiam ser usados para provar a autenticidade de uma reivindicação de identidade. Por exemplo, Janeth insere uma senha para provar que ela é quem diz ser. Esse mecanismo funciona porque apenas o sistema de autenticação e Janeth devem saber qual sua senha. Uma chave particular e o certificado da chave pública X509 associado é outro exemplo de credenciais.

• Atributo básico Dados que ajudam a descrever a identidade. Os atributos básicos podem ser usados em vários contextos comerciais ou de aplicativos. Por exemplo, endereços e números de telefone são atributos comuns usados e referenciados por diferentes aplicativos comerciais.

• Atributos específicos de contexto Dados que ajudam a descrever a identidade, mas que são apenas referenciados e usados em contextos específicos nos quais a identidade é usada. Por exemplo, em uma empresa, as informações sobre o plano de saúde preferido do funcionário é um atributo específico de contexto interessante para o fornecedor de serviços de saúde, mas não necessariamente para o fornecedor de serviços financeiros.

Figura 1. Anatomia de uma identidade digital

O que é gerenciamento de acesso e identidades?

O Burton Group define o gerenciamento de identidades da seguinte maneira: "Gerenciamento de identidades é o conjunto de processos comerciais e uma infra-estrutura de suporte para a criação, manutenção e uso de identidades digitais."2

Neste artigo, definimos o conceito do gerenciamento de acesso e identidades (I&AM) da seguinte maneira:

"Gerenciamento de acesso e identidades se refere aos processos, tecnologias e diretivas para gerenciar identidades digitais e controlar a forma como as identidades podem ser usadas para acessar recursos."

Podemos fazer algumas observações importantes a partir das definições acima:

• O I&AM se refere ao gerenciamento do ciclo de vida ponta-a-ponta3 das identidades digitais. Uma solução de gerenciamento de identidades rápida e confiável não deve ser constituída de silos de tecnologias de segurança; deve consistir em uma base integrada de tecnologias que preencham o espectro de cenários em cada estágio do ciclo de vida da identidade. Falaremos mais sobre esses cenários em uma seção posterior deste artigo.

• O I&AM não trata apenas de tecnologia, mas compreende três elementos indispensáveis: diretivas, processos e tecnologias. As diretivas se referem aos limites e padrões que precisam ser seguidos para cumprir as normas e as práticas comerciais recomendadas; os processos descrevem as seqüências de etapas que levam à conclusão de funções ou tarefas comerciais; as tecnologias são as ferramentas automatizadas que ajudam a atingir objetivos comerciais de forma mais eficiente e precisa, ao mesmo tempo em que se respeita os limites e as orientações especificadas nas diretivas.

• As relações entre elementos do I&AM podem ser representadas como o triângulo ilustrado na Figura 2. É bastante interessante o fato de haver um loop de feedback que vincula todos os três elementos. Os comprimentos das bordas representam as proporções dos elementos com relação um ao outro em um dado sistema de I&AM. A variação da proporção de um elemento no final resulta na variação da proporção de um ou mais elementos para manter a forma de um triângulo com um ponto ótimo (mostrado como uma interseção no triângulo).

• A analogia do triângulo também é perfeita para descrever as relações e interações entre diretivas, processos e tecnologias em um sistema de I&AM saudável. Cada organização é diferente e a mistura correta de tecnologias, diretivas e processos para uma empresa pode não ser necessariamente o equilíbrio correto para outra empresa. Assim, cada organização precisa encontrar seu próprio equilíbrio, representado pela exclusividade de seu triângulo.

• O sistema de I&AM de uma organização não permanece estático ao longo do tempo. Novas tecnologias serão apresentadas e adotadas; novos limites e modelos comerciais mudarão os processos e a administração corporativa. Como mencionamos antes, quando um dos elementos é alterado, é necessário encontrar um novo equilíbrio. Conseqüentemente, é importante entender que o I&AM é um meio e não o fim.

Figura 2. Elementos essenciais de um sistema de gerenciamento de acesso e identidades

Estrutura de gerenciamento de acesso e identidades

Como subentendido nas seções anteriores, o gerenciamento de acesso e identidades é um tópico bastante amplo que abrange tanto áreas tecnológicas como não tecnológicas. O restante deste artigo estará direcionado para os aspectos tecnológicos do gerenciamento de acesso e identidades.

Para limitar o escopo técnico deste tópico, que já é suficientemente amplo, pode ser útil definir uma certa estrutura para nossas discussões. Nós usaremos a estrutura mostrada na Figura 3, que ilustra vários componentes lógicos do I&AM importantes para direcionar as discussões sobre este assunto.

Essa estrutura específica realçou três "áreas" principais de componentes tecnológicos:

• Gerenciamento do ciclo de vida de identidades

• Gerenciamento de acesso

• Serviços de diretório

Os componentes nessas áreas tecnológicas são usados para preencher um conjunto de requisitos recorrentes em soluções de gerenciamento de identidades. Nas próximas seções, descreveremos as funções que esses componentes exercem.

Serviços de diretório

Como mencionado anteriormente, uma identidade digital consiste em alguns tipos lógicos de dados — o identificador, credenciais e atributos. Esses dados precisam ser armazenados e organizados de maneira segura. Os serviços de diretório fornecem a infra-estrutura para responder a essas necessidades. As qualificações e diretivas de segurança freqüentemente controlam o acesso e o uso de aplicativos comerciais e da infra-estrutura de computação em uma organização. As qualificações são os direitos e privilégios associados a indivíduos ou grupos. As diretivas de segurança se referem aos padrões e limites sob os quais os recursos de computação de TI operam.

Uma diretiva de complexidade de senha é um exemplo de uma diretiva de segurança. Outro exemplo é a configuração da relação de confiança de um aplicativo comercial, que pode descrever os terceiros em que o aplicativo confia para ajudar a autenticar e identificar usuários de aplicativos. Como as identidades digitais, as qualificações e diretivas de segurança precisam ser armazenadas, gerenciadas e reveladas adequadamente. Em muitos casos, os serviços de diretório fornecem uma boa base para atender a esses requisitos.

Gerenciamento de acesso

O gerenciamento de acesso refere-se ao processo de controlar e conceder acesso para satisfazer às solicitações de recursos. Geralmente, esse processo é realizado através de uma seqüência de ações de autenticação, autorização e auditoria. Autenticação é o processo pelo qual as reivindicações de identidade são testadas. Autorização é a capacidade de determinar se uma identidade tem a permissão de executar uma ação ou acessar um recurso. Auditoria é o processo de contabilidade de eventos de segurança de gravação que ocorreram. Juntas, autenticação, autorização e auditoria também são conhecidas como os padrões dourados da segurança. (O motivo disso vem do fato de o símbolo químico do ouro, 'Au", ser o prefixo dos três processos.)

Existem várias questões técnicas que os arquitetos de soluções podem encontrar ao criar e integrar mecanismos de autenticação, autorização e auditoria na arquitetura do aplicativo:

• Início de sessão universal

• Confiança e federação

• Qualificações do usuário

• Auditoria

Descreveremos esses desafios e suas soluções em mais detalhes posteriormente neste documento.

Figura 3. Componentes lógicos do I&AM

Gerenciamento do ciclo de vida de identidades

O ciclo de vida de uma identidade digital pode ser enquadrado em estágios semelhantes aos ciclos de vida dos seres vivos:

• Criação

• Utilização

• Término

Cada estágio no ciclo de vida de uma identidade tem cenários que são candidatos ao gerenciamento automatizado. Por exemplo, durante a criação de uma identidade digital, os dados da identidade precisam ser propagados e inicializados em sistemas de identidades. Em outros cenários, as qualificações de uma identidade precisarão ser ampliadas quando o usuário representado pela identidade receber uma promoção no trabalho.

Finalmente, quando a identidade digital não estiver mais em utilização ativa, poderá ser necessário alterar seu status ou excluir a identidade do armazenamento de dados.

Todos os eventos durante o ciclo de vida de uma identidade digital precisam ser gerenciados de forma segura, eficiente e precisa, que é exatamente o que o gerenciamento do ciclo de vida de identidades faz.

Figura 4. Níveis dos requisitos do gerenciamento do ciclo de vida de identidades

Os requisitos do gerenciamento do ciclo de vida de identidades podem ser abordados em vários níveis, como representado na Figura 4. Os tipos de dados que precisam ser gerenciados são mostrados no nível de dados da identidade. Com base em nossas definições anteriores de identidade digital, os dados relevantes incluem credenciais, como senhas e certificados, e atributos do usuário, como nomes, endereços e números de telefone. Além das credenciais e dos atributos, também existem dados de qualificações do usuário a serem gerenciados. Essas qualificações são descritas em mais detalhes posteriormente mas, por enquanto, as qualificações devem ser consideradas como os direitos e privilégios associados às identidades.

Um nível acima na ilustração, os requisitos listados refletem os tipos de operações que podem ser executadas sobre os dados de identidades. Criação, Leitura, Atualização e Exclusão (CRUD, Create, Read, Update, Delete) são os primitivos da operação de dados moldados pela comunidade do banco de dados. Nós reutilizamos esses primitivos pois eles fornecem uma maneira bastante conveniente de classificar os tipos de operações de gerenciamento de identidades. Por exemplo, podemos classificar alterações no status da conta, em qualificações e credenciais no primitivo Atualizar dados.

O nível seguinte na ilustração mostra dois modelos de administração do ciclo de vida de identidades: auto-atendimento e delegada. Nas organizações de TI tradicionais, as tarefas de administração de computadores são executadas por um grupo centralizado de administradores de sistemas. Ao longo do tempo, as organizações perceberam que poderia haver boas razões financeiras e comerciais para permitir também outros tipos de modelos de administração. Por exemplo, normalmente é mais econômico e eficiente que cada indivíduo possa atualizar sozinho alguns de seus atributos pessoais, como endereço e número de telefone. O modelo de administração de auto-atendimento fornece essa permissão individual. O meio-termo entre os modelos de auto-atendimento e de administração centralizada é a administração delegada. No modelo delegado, as responsabilidades da administração do ciclo de vida de identidades são compartilhadas entre grupos descentralizados de administradores. Os critérios comuns usados para determinar o escopo da delegação são a estrutura da organização e as funções de administração. Um exemplo de administração delegada baseada na estrutura da organização é a hierarquia dos administradores no nível da empresa, da unidade e do departamento em uma grande organização.

Os modelos de administração do ciclo de vida acima podem ser usados para dar suporte a vários cenários comerciais, alguns dos quais estão listados na Figura 4.Por exemplo, freqüentemente novos funcionários requerem que contas sejam criadas e fornecidas a eles. Por outro lado, quando um funcionário não está mais empregado, pode ser necessário alterar o status da conta existente. Cenários de alteração de trabalho também podem ter vários impactos sobre as identidades digitais. Por exemplo, quando Carlos recebe uma promoção, pode ser necessário mudar seu cargo e ampliar suas qualificações. Agora que temos um melhor entendimento sobre os requisitos do gerenciamento do ciclo de vida de identidades, podemos nos aprofundar nos desafios para se atender a esses requisitos.

Figura 5. Situação atual: sistemas com várias identidades na empresa

A ilustração da Figura 5 refere-se ao fato de um usuário típico em uma empresa precisar lidar com várias identidades digitais que podem ser armazenadas e gerenciadas independentemente umas das outras. Essa situação atual se deve à evolução pela qual passam atualmente todas as organizações comerciais. Eventos como fusões e aquisições podem introduzir sistemas incompatíveis na infra-estrutura de TI existente e os requisitos comerciais emergentes precisam ser supridos através de aplicativos de terceiros que não estão bem integrados com os existentes.

Pode-se presumir que seria muito mais fácil se as empresas descartassem os sistemas atuais e começassem do zero. Contudo, raramente essa solução é uma opção viável. Temos que reconhecer que os sistemas de identidades existentes podem estar em uso por um longo tempo, o que nos leva a encontrar outras soluções para resolver duas questões principais quanto ao gerenciamento de dados em sistemas de identidades distintos:

1. Duplicação de informações. Freqüentemente, as informações de identidade são duplicadas em vários sistemas. Por exemplo, atributos, como endereços e números de telefone, são armazenados e gerenciados em mais de um sistema em um ambiente. Quando os dados de identidade são duplicados, podem facilmente ficar fora de sincronismo se atualizações forem executadas em um sistema mas não nos outros.

2. Falta de integração. A exibição completa dos atributos, credenciais e privilégios de um determinado usuário é freqüentemente distribuída por vários sistemas de identidade. Por exemplo, para um determinado funcionário, as informações relacionadas de recursos humanos podem estar contidas em um sistema de RH SAP, a conta de acesso à rede em um Active Directory e os privilégios de aplicativos herdados armazenados em um mainframe. Vários cenários de gerenciamento do ciclo de vida de identidades requerem que informações de identidades entrem e saiam de vários sistemas diferentes. Nos referimos às questões acima como o desafio de agregação de identidades, que descreveremos com mais detalhes em uma seção posterior.

Desafios do gerenciamento de acesso e identidades

Início de sessão universal

Um usuário empresarial típico precisa fazer logon várias vezes para obter acesso aos diversos aplicativos comerciais usados em seu trabalho. Do ponto de vista do usuário, vários logons e a necessidade de lembrar várias senhas são algumas das principais causas de experiências ruins com aplicativos. Do ponto de vista do gerenciamento, incidentes com senhas esquecidas aumentam os custos de gerenciamento e, quando combinadas com maus-hábitos de gerenciamento de senhas do usuário (como escrever as senhas em notas adesivas), podem muitas vezes levar a chances maiores de falhas de segurança. Por causa dos problemas aparentemente insolúveis que várias identidades apresentam, o conceito de início de sessão universal (SSO), a capacidade de fazer logon uma vez e obter acesso a vários sistemas, tornou-se o 'sonho dourado' dos projetos de gerenciamento de identidades.

Soluções de início de sessão universal

Genericamente falando, há cinco classes de soluções SSO. Nenhum tipo de solução é o correto para todos os cenários de aplicativos. A melhor solução depende muito de fatores como o local em que os aplicativos que requerem o SSO estão hospedados, as limitações impostas pela infra-estrutura (por exemplo, restrições de firewall) e a capacidade de modificar os aplicativos. As cinco categorias de soluções SSO são:

1. SSO da Web

2. Início de sessão integrado ao sistema operacional

3. Início de sessão federado

4. Mapeamento de credenciais e identidades

5. Sincronização de senhas

As soluções SSO da Web foram criadas para abordar os requisitos de início de sessão de aplicativos da Web. Nessas soluções, usuários de navegadores não autenticados são redirecionados para sites de logon para inserir identificações e credenciais do usuário. Quando houver êxito na autenticação, cookies HTTP são emitidos e usados por aplicativos da Web para validar sessões de usuários autenticados. O Microsoft Passport é um exemplo de solução SSO da Web.

O início de sessão integrado ao sistema operacional se refere a interfaces e módulos de autenticação incorporados ao sistema operacional. O sub-sistema de segurança do Windows oferece esse recurso através de módulos do sistema, como o LSA (autoridade de segurança local) e os SSP (Security Specific Providers). SSPI refere-se às interfaces de programação nos SSP. Os aplicativos desktop que usam as APIs SSPI para autenticação do usuário podem se 'acumular' ao logon do desktop do Windows para ajudar no SSO do aplicativo. O GSSAPI em várias implementações UNIX também fornece a mesma funcionalidade de SSO no aplicativo.

O início de sessão federado requer que as infra-estruturas de autenticação dos aplicativos compreendam relações de confiança e interoperem através de protocolos padrão. O Kerberos e o futuro Active Directory Federation Service são exemplos de tecnologias de federação. O início de sessão federado significa que a responsabilidade de autenticação é delegada a uma parte confiável. Não é necessário solicitar que os usuários de aplicativos assinem novamente se tiverem sido autenticados por um componente de infra-estrutura de autenticação federada (ou seja, confiável).

As soluções de mapeamento de credenciais e identidades geralmente usam caches de credenciais para acompanhar as identidades e credenciais a serem usadas para acessar uma lista correspondente de sites de aplicativos. O cache pode ser atualizado manual ou automaticamente quando a credencial (por exemplo, a senha) for alterada. Os aplicativos existentes podem ou não precisar ser modificados para usar soluções de mapeamento de identidades. Quando o aplicativo não pode ser modificado, um agente de software pode ser instalado para monitorar eventos de logon de aplicativos. Quando o agente detecta esses eventos, ele localiza a credencial do usuário no cache e a insere automaticamente no prompt de logon do aplicativo.

A técnica de sincronização de senhas é usada para sincronizar senhas nos bancos de dados de credenciais de aplicativos, de forma que não seja necessário que os usuários e os aplicativos gerenciem alterações de várias senhas. A sincronização de senhas como uma tecnologia em silo não fornece realmente um início de sessão universal, mas resulta em algumas facilidades das quais os aplicativos podem se beneficiar. Por exemplo, com a sincronização de senhas, um aplicativo da camada intermediária pode presumir que a senha de um usuário do aplicativo seja a mesma nos vários sistemas que precisa acessar; assim, não precisará tentar procurar por diferentes senhas ao acessar recursos nesses sistemas.

Gerenciamento de qualificações

O gerenciamento de qualificações refere-se ao conjunto de tecnologias usadas para conceder e revogar direitos e privilégios de acesso a identidades. Está intimamente associado com a autorização, que é o processo real de impor as regras, diretivas e restrições de acesso associadas com os dados e funções comerciais.

Os aplicativos empresariais atuais freqüentemente usam uma combinação de diretivas baseadas em regras comerciais e autorização baseada em funções para determinar o que uma determinada identidade pode ou não fazer.

Em um aplicativo distribuído em n camadas, as decisões de acesso podem ser feitas em qualquer camada da arquitetura do aplicativo. Por exemplo, a camada de apresentação pode apresentar apenas opções da interface do usuário que o usuário tem autorização para escolher. Na camada de serviço da arquitetura, o serviço pode verificar se o usuário atende à condição de autorização para invocar o serviço. Por exemplo, apenas usuários com a função de gerente podem invocar o serviço 'Aprovação de empréstimo'. Por trás da camada da lógica comercial, podem ser necessárias decisões refinadas sobre diretivas comerciais como 'Esta solicitação foi feita no horário comercial?'; na camada de dados, o procedimento armazenado no banco de dados deve filtrar dados retornados com base na relação entre a identidade da pessoa que invocou o serviço e os dados solicitados.

Dada a utilidade e, muitas vezes, o uso cruzado dos esquemas de autorização baseados em regras e em funções, nem sempre fica claro para os arquitetos de aplicativos como modelar uma estrutura de gerenciamento de qualificações que integre os dois esquemas de maneira clara. Várias empresas têm mecanismos personalizados separados para ambos.

Figura 6. A integração da autorização baseada em regras e em funções ilustra uma representação de como os dois esquemas podem ser combinados e integrados.

Nessa representação, podemos imaginar uma definição de função (que geralmente reflete uma responsabilidade de trabalho) com dois conjuntos de propriedades. Um conjunto de propriedades contém as identidades de pessoas ou sistemas que têm aquela função. Por exemplo, a função de Gerente pode ser atribuída a Janeth, Carlos e Victor. O segundo conjunto de propriedades contém o conjunto de direitos de uma determinada função. Os direitos podem representar funções comerciais ou ações em recursos de computação. Por exemplo, transferir fundos define uma função comercial e ler arquivo refere-se a uma operação em um recurso de computação. Além disso, podemos atribuir um conjunto de instruções condicionais (regras comerciais) para cada direito. Por exemplo, o direito transferir fundos pode ter uma instrução condicional para permitir a ação se a hora atual estiver dentro do horário comercial. Observe que a instrução condicional pode basear sua decisão em dados de entrada dinâmica que podem ser determinados apenas no tempo de execução do aplicativo.

Também é importante para que a maioria das empresas tenha uma exibição consolidada de todos os direitos que uma determinada identidade possui. Para atender a essa necessidade, geralmente os aplicativos de gerenciamento de qualificações tiram proveito de um armazenamento de diretivas centralizado para ajudar a facilitar o gerenciamento centralizado e a geração de relatórios de direitos dos usuários.

Agregação de identidades

Os sistemas de TI de uma empresa se desenvolvem naturalmente durante o curso da história de uma organização. Muitas vezes isso se deve a razões como fusões e aquisições, ou preferências e alterações das lideranças de TI. As conseqüências, freqüentemente, se manifestam através de uma mistura de sistemas de TI desconectados, com artefatos de arquitetura indesejáveis. Os sistemas relacionados a identidades não são uma exceção a tais evoluções na área de TI.

Freqüentemente, a empresa terá não apenas um sistema de identidades, mas vários, cada um servindo diferentes funções comerciais mas armazenando dados duplicados e relacionados. Os aplicativos que precisam se integrar com essas funções comerciais são forçados a reconciliar as diferenças e sincronizar as duplicações.

Por exemplo, um aplicativo de serviços bancários pode precisar obter informações do cliente de um banco de dados DB2 IBM, um banco de dados de autorização baseado em Oracle e um CRM proprietário. Nesse caso, o conceito de 'Cliente' do aplicativo é definido por três sistemas diferentes. Os atributos que descrevem um cliente, como seu nome, endereço e número da carteira de identidade, podem estar armazenados e duplicados em vários sistemas. Por outro lado, dados não duplicados, como os produtos financeiros que o cliente adquiriu e o extrato bancário do cliente, podem ser mantidos em sistemas separados. Será necessário que o aplicativo agregue esses dados de sistemas diferentes para obter a exibição necessária do cliente.

Mover os dados de identidade subjacentes para um sistema de identidades gigante pode parecer uma resposta óbvia para esse problema. Contudo, há muitos problemas reais (por exemplo, o risco de comprometer aplicativos herdados) que impedem que essa solução seja adotada de maneira ampla em curto prazo. A agregação de identidades se refere, assim, ao conjunto de tecnologias que ajuda os aplicativos a agregar informações de diversos sistemas de identidade, enquanto reduz a complexidade da reconciliação, sincronização e integração dos dados.

Existem vários desafios técnicos que as tecnologias de agregação de identidades devem ajudar a vencer:

• Manter as relações nas transformações de dados.

• Otimizar as operações de CRUD dos dados.

• Sincronizar dados.

As próximas sub-seções fornecem uma visão geral dessas questões de criação.

(a) Mantendo relações nas transformações de dados

Uma solução de agregação de identidades pode oferecer várias vantagens para aplicativos com exibições diferentes de informações de identidades que manipulam dados em diferentes sistemas. A primeira vantagem envolve o fornecimento de uma exibição consolidada ou de uma exibição agregada dos dados nos sistemas individuais para os aplicativos. Para transformar e representar dados em diferentes exibições, a solução de agregação de identidades precisa manter metadados que descrevam o esquema representando a exibição consolidada e sua relação com o esquema de dados nos vários sistemas de identidade.

Examinemos um exemplo específico de um aplicativo de gerenciamento do ciclo de vida de identidades que gerencia dados em alguns sistemas existentes. A exibição consolidada do aplicativo de gerenciamento é representada por um novo esquema que é formado de atributos de identidade novos e existentes.

Figura 7. Reconciliando esquemas de identidade

A Figura 7 ilustra um exemplo em que um novo esquema de identidades é definido para o aplicativo. O novo esquema se refere aos atributos em dois esquemas de identidade existentes e também novos, que não estão especificados no momento (número da conta, telefone celular e preferências).

Para que os aplicativos consultem e atualizem os dados nos armazenamentos existentes, é necessário manter relações de dados entre os atributos definidos no novo esquema e os atributos correspondentes nos esquemas existentes. Por exemplo, as seguintes relações precisarão ser mantidas:

• Referência Uma referência se refere a uma informação que identifica claramente uma instância de dados, como representado por um determinado esquema de dados. Por exemplo, o atributo 'Identificação do cliente' permite que uma instância de dados, conforme representada pelo esquema do aplicativo na Figura 7, localize a instância de dados correspondente como representada pelo esquema 1 existente. Esquemas diferentes podem usar referências diferentes para identificar suas próprias instâncias de dados.

• Propriedade Um atributo de dados pode ser definido em mais de um esquema existente. Usando o exemplo mostrado na Figura 7 novamente, podemos ver que os atributos 'Nome' e 'Endereço' são definidos nos dois esquemas existentes. No caso de um conflito de dados, o aplicativo precisa saber que versão tem a cópia com autorização a ser mantida. Além disso, pode haver cenários em que um atributo pode obter seu valor de uma lista priorizada de proprietários. Nesses cenários, quando o valor de um atributo não está presente na primeira fonte de autorização, o serviço de agregação deve consultar o sistema seguinte na lista priorizada de proprietários.

• Mapeamento de atributos Os atributos definidos em vários armazenamentos de dados podem ter o mesmo significado semântico, mas ter a mesma ou diferentes representações sintáticas. Ao consultar ou atualizar um atributo de dados, o serviço de agregação de identidades precisa saber quais atributos são semanticamente equivalentes. Por exemplo, apesar de a identificação do cliente ser definida nos três esquemas, ela tem um nome diferente, CustID, no esquema 2. Quando o aplicativo fizer uma atualização do número de identificação do cliente de uma identidade, o sistema também deverá atualizar o atributo CustID da instância de dados representada pelo esquema 2.

(b) Otimizando as operações de CRUD dos dados

Como identificado anteriormente, CRUD é um acrônimo que significa Criação, Leitura, Atualização e Exclusão. CRUD define as operações primitivas básicas de manipulação dos dados. O motivo de a CRUD ser considerada um desafio técnico é porque o desempenho para concluir uma atividade relacionada com agregação que envolve operações de CRUD em vários sistemas de dados de back-end podem variar significativamente dependendo das relações de dados.

No melhor cenário, as operações de CRUD podem ser colocadas em paralelo. Isso é particularmente verdadeiro em situações em que as instâncias de dados podem ser resolvidas com o uso da mesma referência, e a referência a dados é sempre resolvida em uma instância exclusiva. Por exemplo, se o número da carteira de identidade for a única chave usada para consultar e agregar dados em todos os armazenamentos de dados, essa consulta pode ser emitida em paralelo.

No pior cenário, as operações de CRUD são colocadas em série pelos armazenamentos de dados. A operação em série é comum em situações em que as referências usadas para resolver instâncias de dados têm dependências em outras instâncias de dados. Como um exemplo simples, vamos supor que precisamos agregar dados dos bancos de dados do RH e de Benefícios, e as referências de instância são a identificação do funcionário e a identificação da carteira de identidade, respectivamente. Se a única chave inicial que temos para a consulta for a identificação do funcionário, e a identificação da carteira de identidade puder ser obtida somente do banco de dados do RH, será necessário colocar a consulta em série, na seguinte ordem:

1. Consultar o banco de dados do RH usando a identificação do funcionário como chave.

2. Extrair o número da carteira de identidade dos resultados da consulta acima.

3. Consultar o banco de dados de benefícios.

4. Agregar os resultados da consulta.

A replicação é uma técnica comum usada para resolver a queda de desempenho devido a operações de CRUD nos armazenamentos de dados. Para contemplar a questão do desempenho, uma parte dos atributos de dados de back-end pode ser replicada em um armazenamento mantido pelo serviço de agregação de identidades. Além disso, a cópia local dos dados replicados pode ser desnormalizada para ajudar a melhorar o desempenho de CRUD.

(c) Sincronizando dados

A sincronização de dados será necessária em situações em que uma ou ambas as condições a seguir forem verdadeiras:

• Existem atributos de identidade duplicados em vários armazenamentos de back-end.

• Os dados são replicados em um armazenamento intermediário do agregador de identidades.

Contudo, o uso da sincronização de dados também pode introduzir outros problemas de criação:

• Resolução de conflitos de dados. Em situações em que os dados podem ser atualizados a partir de mais de uma fonte, muitas vezes é fácil introduzir dados conflitantes. Algumas práticas comuns que ajudam a atenuar essas situações são:

  • Atribuir prioridade de propriedade de dados de forma que, no caso de um conflito, a autoridade atribuída seja usada.

  • No caso de um conflito, a gravação mais recente tem precedência.

  • A sincronização é disparada. Duas abordagens comuns são as atualizações programadas e as baseadas em notificações de eventos.

Confiança e federação

Como mencionado na seção sobre início de sessão universal, a federação oferece uma forma de solução de início de sessão universal. Contudo, a federação é mais do que um simples início de sessão. A federação implica na delegação de responsabilidades honradas através de relações de confiança entre as partes federadas. A autenticação é apenas uma forma de responsabilidade delegada. Autorização, gerenciamento de perfis, serviços de pseudônimos e faturamento são outras formas de funções relacionadas a identidades que devem ser delegadas a partes confiáveis.

Existem três elementos de tecnologia que são cruciais para o conceito de federação:

• Um protocolo de federação que permita a comunicação entre as partes.

• Uma infra-estrutura de confiança flexível que dê suporte a uma variedade de modelos de confiança.

• Uma estrutura extensível de gerenciamento de diretivas que dê suporte a diferentes requisitos de administração.

Os protocolos de federação são as 'linguagens' usadas pelas partes federadas para se comunicarem entre si. Como a federação presume que uma responsabilidade é delegada a, e executada por, uma parte diferente, o protocolo deve permitir que os indivíduos obtenham 'recursos' — essencialmente reivindicações invioláveis de que uma determinada identidade concluiu uma ação ou é qualificada para uma coleção de privilégios. Por exemplo, no caso do início de sessão federado, uma identidade autenticada obtém um recurso que prova que o indivíduo se autenticou com êxito junto a um serviço de autenticação aprovado.

No complexo mundo dos negócios, é possível haver esquemas confiáveis relativamente complexos envolvendo várias partes comerciais. A tecnologia da federação deve conseguir capturar a essência dessas relações confiáveis reais em modelos de confiança fáceis de entender mas eficientes, que ajudarão a possibilitar vários cenários comerciais. Alguns modelos de confiança comuns, ilustrados na Figura 8, são:

• Radial

• Hierárquico

• Web de confiança ponto-a-ponto

Figura 8. Modelos de confiança comuns

O modelo radial é o mais simples de compreender. Nesse modelo, existe um agente central em que as partes federadas confiam diretamente. A União Européia é um exemplo desse modelo de federação, em que os países da UE confiam diretamente na entidade da UE para fornecer orientações financeiras e oportunidades de negócios comuns para as partes federadas.

No modelo hierárquico, duas partes têm uma relação de confiança indireta se as duas tiverem um caminho de confiança em suas respectivas divisões na árvore hierárquica para uma autoridade raiz comum. O sistema político norte-americano apresenta esse modelo de confiança. Esse sistema político tem entidades políticas locais municipais, da comarca, estaduais e federais, cada um existindo em vários níveis da hierarquia.

O modelo ponto-a-ponto representa uma coleção infinita de relações de confiança ad-hoc e diretas. As relações pessoais entre amigos no mundo físico são bons exemplos deste modelo de confiança. Observe que também é possível estender e formar novas redes ou federações, consistindo em diferentes modelos de confiança, ou modelos híbridos.

Uma estrutura de gerenciamento de diretivas básica deve permitir que diretivas sejam criadas, excluídas, modificadas e reveladas. Para promover sistemas federados que permitam que novas parcerias e modelos comerciais sejam integrados rapidamente, a estrutura de gerenciamento de diretivas também deve ser extensível para refletir o dinamismo do ambiente que pretende dar suporte.

Alguns exemplos de diretivas de aplicativos que são relevantes no mundo federado são:

• Emissor confiável de recursos relacionados a identidades.

• Os tipos de recursos necessários para invocar a operação de um aplicativo.

• Os tipos de informações de identidade que o aplicativo espera nos recursos.

• Os tipos de privilégios que uma identidade deve ter para invocar um serviço.

Auditoria

A auditoria, no contexto do I&AM, se refere à manutenção de registros de 'quem fez o quê e quando' na infra-estrutura de TI. Leis federais, como a Lei Sarbanes-Oxley, são direcionadores importantes dos requisitos de auditoria relacionados a identidades.

(a) Processo de auditoria de TI

Geralmente, o processo de auditoria de TI envolve as seguintes fases, como ilustrado na Figura 9:

• Geração de auditoria

• Coleta e armazenamento de dados

• Análise e feedback

Figura 9. Processo de auditoria de TI

As trilhas de auditoria podem ser geradas por vários componentes de aplicativos e da infra-estrutura para fins diferentes. Por exemplo, servidores de VPN e firewalls podem gerar eventos para ajudar a detectar invasões externas; componentes de middleware podem gerar dados de instrumentação para ajudar a detectar anomalias de desempenho; e aplicativos comerciais podem produzir dados de auditoria para ajudar a depurar ou cumprir requisitos reguladores de auditoria.

Depois que os dados de auditoria tiverem sido produzidos, eles precisarão ser coletados e armazenados. Existem dois modelos principais a serem considerados: distribuído e centralizado. No modelo distribuído, geralmente os dados de auditoria permanecem no sistema em que foram gerados. Com a abordagem centralizada, os dados são enviados para uma instalação central de armazenamento e coleta de dados.

Uma vez coletados, os dados podem ser processados e analisados de maneira automática ou manual. A análise da auditoria foi criada para levar a conclusões sobre as ações corretivas, se houver alguma, necessárias para melhorar os processos e sistemas de TI.

(b) Considerações sobre a criação de sistemas de auditoria

Dado o processo de auditoria típico descrito nas seções anteriores, existem várias considerações importantes para a criação de sistemas de auditoria:

• Localidade da geração e do armazenamento da auditoria.

• Separação da função do auditor.

• Fluxo de eventos auditados.

Uma vez gerada uma trilha de auditoria, os dados da auditoria podem ser armazenados localmente no mesmo sistema ou transferidos para outro local de armazenamento. Essa consideração é importante do ponto de vista da segurança, pois pode ser mais fácil alterar e modificar os dados de auditoria se eles estiverem armazenados no mesmo sistema que os gerou. Esse ponto pode ser ilustrado por um exemplo simples: no caso de um sistema estar comprometido, o invasor pode ser capaz de modificar a trilha de auditoria no sistema local para dissimular a tentativa de invasão. Assim, para uma maior garantia contra esses ataques, o sistema de auditoria pode armazenar os dados separadamente em uma máquina remota.

A separação de funções é uma prática recomendada comum para ajudar a minimizar a ocorrência de atividades ilegais resultantes de ações que podem burlar verificações de responsabilidade. Por exemplo, um agente de compras corporativo não deve ser capaz de aprovar solicitações de compra. No campo da auditoria de TI, é comum separar a função de administrador do sistema da função de auditor. Isso evita que o administrador do sistema, que geralmente tem um 'status de deus' nos computadores, esconda as trilhas de auditoria de atividades não autorizadas.

Em um modelo de criação distribuído, no qual os dados de auditoria são gerados e armazenados em sistemas diferentes, permitir que os dados saiam dos sistemas de geração da auditoria pode adicionar um nível extra de segurança. Essa medida preventiva reduz as chances de dados de auditoria violados substituírem trilhas reais.

Além disso, também se espera que as infra-estruturas de auditoria de identidades sejam:

• Eficientes (geralmente isso significa um canal de comunicação assíncrona baseada em mensagens).

• Disponíveis (geralmente isso significa distribuída, agrupada e tolerante a falhas).

• Precisas (manter rastros e registros precisos).

• Não repudiadas (possam ser admitidas nos tribunais como provas; geralmente isso significa que os registros precisam ser assinados digitalmente).

Conclusões

As organizações são formadas por pessoas e sistemas, representados nos sistemas de TI como identidades digitais. Tudo o que ocorre nos negócios é conseqüência das ações iniciadas por e para essas identidades. Sem identidades (mesmo identidades anônimas), não haveria atividades e os negócios seriam construções sem vida.

No nível mais alto, a SOA pode ser encarada como uma maneira de organizar a infra-estrutura de TI da empresa que executa e gerencia as atividade comerciais. Assim, empresas que buscam realizar uma SOA devem determinar como resolver os desafios de gerenciamento de acesso e identidades com que se deparam no momento. Nós fornecemos uma visão geral de algumas áreas tecnológicas importantes:

• Obtendo o início de sessão universal de aplicativos e usuários.

• Agregando, transformando, sincronizando e configurando dados de identidade de vários sistemas de identidade.

• Gerenciando acesso a dados e funções comerciais usando funções e regras.

• Estabelecendo federações com parceiros comerciais.

• Fazendo a auditoria de atividades relacionadas a identidades.

Também esperamos que as discussões técnicas sobre os desafios tenham ajudado os leitores a apreciar os produtos e soluções desta área.

Nossa conclusão final: O gerenciamento de acesso e identidades é uma etapa a vencer na realização da SOA. Mostre-me uma empresa que declare ter sucesso na implementação da SOA e mostrarei uma empresa que tem seu gerenciamento de acesso e identidades sob controle.

Referências

1. O contexto define o limite no qual uma identidade é usada. O limite pode ser relacionado ao aplicativo ou aos negócios. Por exemplo, Janeth pode usar uma identidade de trabalho com o identificador Janeth@WallStreetAce.com para se identificar na empresa Wall Street (Wall Street Ace), bem como para executar uma negociação de ações na bolsa de valores de Nova York. A empresa Wall Street e a bolsa de valores de Nova York seriam dois contextos comerciais diferentes em que o mesmo identificador é usado. SOA Challenges: Entity Aggregation, Ramkumar Kothandaraman, .NET Architecture Center, maio de 2004 (URL: https://msdn.microsoft.com/architecture/default.aspx?pull=/library/enus/dnbda/html/dngrfsoachallengesentityaggregation.asp) (em inglês)

2. Enterprise Identity Management: It's About the Business, Jamie Lewis,The Burton Group Directory and Security Strategies Report, v1, 2 de julho de 2003 (em inglês)

3. O termo "ciclo de vida", quando usado no contexto de identidades digitais, é um tanto inadequado, pois geralmente as identidades digitais não são recicladas. Contudo, como a frase "gerenciamento do ciclo de vida de identidades" está bem estabelecida na comunidade da TI, aderimos à terminologia do "ciclo de vida". Microsoft Identity and Access Management Series, Microsoft Corporation, 14 de maio de 2004 (URL: https://www.microsoft.com/downloads/details.aspx?FamilyId=794571E9-0926-4C59-BFA9-B4BFE54D8DD8&displaylang=en) (em inglês)

4. Enterprise Identity Management: Essential SOA Prerequisite Zapflash, Jason Bloomberg, Zapflash, 19 de junho de 2003 (URL: http://www.zapthink.com/report.html?id=ZapFlash-06192003) (em inglês)

Sobre o autor

Fredrick Chong é um arquiteto de soluções na equipe de estratégia de arquitetura da Microsoft, onde ele orienta a integração de aplicativos com tecnologias de gerenciamento de acesso e identidades. Ele descobriu seu interesse por segurança ao fazer o protótipo de um protocolo de caixa eletrônico no grupo de segurança de rede do IBM T J Watson Research Center. Desde então, implementou recursos de segurança e protocolos de imposição de licença nas equipes de produtos da Microsoft e colaborou com muitos clientes empresariais na arquitetura e implementação de várias soluções de segurança, incluindo início de sessão universal da Web, SSL-VPN e protocolo de segurança de serviços da Web. Ele pode ser encontrado em fredch@microsoft.com.