Pensando sobre Tecnologia da Informação : educativo

De volta ao básico: A federação a nosso alcance

Gebara — Wed, 19 Mar 2008 22:25:00 GMT

Bem, pretendo que este seja o último post da série De volta ao básico . Por que? Porque a partir de agora teremos que entrar um pouco mais fundo nos temas que foram abordados para entender melhor as tecnologias utilizadas. Só para relembrar, esta série...(read more)

De volta ao básico: E quando não é possível usar um diretório único?

Gebara — Mon, 10 Dec 2007 23:30:44 GMT

Continuando (muito mais tarde do que eu imaginava, peço desculpas) o blog anterior, precisamos colocar um pouco mais os pés no chão. A idéia de se ter um único diretório acessível por diversos protocolos é muito interessante, mas é um tanto quanto fora da realidade. Por que?

Quantos de vocês possuem diversos sistemas (internos ou licenciados de terceiros) que possuem um diretório próprio para os processos de autenticação e autorização, isto é, quantos deles possuem base própria de pares usuário/senha e controle de perfis de acesso? Aposto que a esmagadora maioria tem. E o que é possível fazer sobre isso?

Há, pelo menos, três soluções no horizonte:

Deixar do jeito que está, mas melhorar o que está para vir:
Muitas vezes é extremamente difícil justificar os investimentos necessários para alterar os sistemas atuais, a não ser que sua empresa esteja sendo pressionada por alguma legislação. Mas dá para melhorar o que vem por aí.
Tenho um caso interessante de um cliente que veio discutir sobre este assunto há um par de anos: eles tinham uma bem estabelecida infra-estrutura de Active Directory na empresa mas precisavam estabelecer um esquema de single sign-on para sua infra-estrutura. Analisamos durante algum tempo o impacto que isto teria, tanto em projetos, quanto em aquisição de licenças e novos procedimentos operacionais e resolvemos partir para o princípio do KISS (Keep It Simple, Sam): estabelecemos requisitos para a aquisição de novos produtos e para a atualização dos produtos atuais, usando as idéias de múltiplos protocolos como fachada para o mesmo diretório. Com isso foi possível traçar no tempo, com menos investimentos, um caminho para o diretório único;
Usar um produto de single sign-on:
Muitas empresas de grande porte partem para esta solução. Normalmente estes produtos fazem um mapeamento de contas de usuários e suas senhas, oferecendo uma API que permite fazer o controle de perfis. O usuário se loga em todos os sistemas usando um único par usuário/senha mas, por debaixo do pano, o sistema de single sign-on verifica qual usuário/senha deve ser utilizada para cada um dos sistemas, efetivamente mascarando para o usuário a parafernália de identidads do seu ambiente. É normalmente uma tecnologia complexa, de custo elevado, que nem todas as empresas têm disponibilidade para investir;
Usar um produto de sincronização e provisionamento:
É uma solução que permite a sincronização dos pares usuário/senha dos diversos sistemas/plataformas, facilitando principalmente a vida do usuário final (que não precisa se lembrar de tantos pares de usuário/senha), mas traz complexidade extra para o ambiente. As funções de provisionamento permitem que, ao se incluir ou excluir um usuário na empresa, seja possível, com regras pré-definidas, criar ou excluir o mesmo usuário em diversos sistemas com diretórios desconexos ao mesmo tempo em que, ao se trocar uma senha em um dos diretórios, esta senha seja replicada em todos os sistemas ao qual o usuário tem acesso. Idéia simples, mas que também embute mais complexidade na infra-estrutura.

Para a opção 1, temos uma técnica que é possível ser utilizada depois de uma análise mais aprofundada do ambiente: se os sistemas desenvolvidos internamente compartilharem uma API de autenticação/autorização própria, em muitos casos é possível substituir o código desta API (sem alterar as interfaces) por uma nova API que faça acesso ao diretório principal da empresa, migrando gradualmente de um cenário de múltiplos diretórios para um cenário de diretório único.

Mas aqui fica mais um pensamento: quando se utilizam as técnicas 2 e 3 acima, é provável que a força da sua senha seja em realidade, a da senha de complexidade mais baixa. Se, por exemplo, um dos sistemas aceita apenas senhas de 8 caracteres maiúsculos, para que o single sing-on funcione ou a sincronização seja efetiva, todos os sistemas ficam com os mesmos 8 caracteres maiúsculos. Assim, mesmo que um ou mais sistemas permitam uso de senhas complexas, esta características não será explorada adequadamente. Razão esta para um outro cliente que eu conheço não usar nenhum destes esquemas: eles definiram um grupo de 3 a 5 diretórios, atribuindo a cada um deles um grupo de sistemas dependentes. Sistemas críticos dependem do diretório que permite maior controle da complexidade da senha, enquanto sistemas mais simples ficam com os diretórios que oferecem menor complexidade. Para eles também há uma vantagem de se manter esse número de diretórios: caso a senha de um usuário fique comprometida, apenas aqueles sistemas dependentes do diretório que hospeda o par usuário/senha com problemas é que serão um alvo potencial de ataque, minimizando o risco de se ter um ponto único de falha no controle de acesso à informação.

A seguir (próximo blog): A federação a nosso alcance.

De volta ao básico: A idéia do diretório único

Gebara — Thu, 01 Nov 2007 22:43:40 GMT

Ou melhor dizendo, o Shangri-la?

Relendo o post anterior, o situação nos parece desanimadora. E por que será que estamos sempre voltando a este mesmo padrão?

Existem algumas razões que são apontadas mais freqüentemente por meus clientes quando debatemos este assunto (se você conhece algum outro motivo não abordado, comente conosco):

Demora na indústria de tecnologia para definir padrões que pudessem ser adotados quando os sistemas estavam em desenvolvimento;
Procura por uma independência de fornecedor de tecnologia;
Desvio da zona de conforto das equipes de TI;
Insatisfação permanente das equipes, sempre em busca de uma solução melhor para os mesmos problemas;
Plataforma tecnológicas diferentes têm difuldade em se comunicar umas com as outras, impedindo o uso de uma solução única.

O primeiro item nos remete a um problema recorrente para o qual, acredito eu, pouca esperança há para sua solução: a velocidade com que a indústria de tecnologia é capaz de chegar a um acordo sobre o que poderia ser um padrão comum, viável em diversos cenários e o fato de que um boa implementação de tecnologia pode ser, durante um bom tempo, um diferencial competitivo em relação às outras empresas do mercado. O primeiro ponto, inclusive, é similar ao assunto que estivemso debatento nesta semana em um grupo de estudos sobre infra-estrutura para web: existem diversos mecanismos de autenticação e autorização que são mais adequados a um cenário do que a outro (intranet, internet e extranet).

O segundo item é polêmico e existem posições fortes de todos os lados possíveis. O desejo de uma empresa em se tornar menos dependente de seus fornecedores de tecnologia, podendo trocá-los quando o relacionamento comercial se enfraquece, é muitas vezes fundamental para a implementação de um número muito grande de soluções desenvolvidas internamente para se chegar a uma solução similar àquelas existentes, mas que podem, potencialmente, provocar uma amarração indesejada. Mas existem outras empresas que não pensam assim; preferem direcionar seus investimentos de tecnologia a um grupo reduzido de empresas que acreditam ser competentes e com capacidade de sobreviver às acidentes de percalço do mercado. É aí que equipes de arquitetura fazem a diferença. :-)

O problema deste segundo ítem são justamente os dois itens seguintes: zona de conforto e a vontade de sempre fazer melhor (salutar em muitos casos). O que poderia ser interpretado como um bom motivo para se criar uma estrutura local que possa ser usada adequadamente por várias plataformas tecnológicas, equipes de desnvolvimento diferentes acabam criando soluções de baixo reuso, sempre pensando em resolver adequademente seu probema sem pensar em transformá-las em soluções mais genéricas.

O que muitas empresas procuram (e poucas acharam) é um diretório único para concentrar todo o conjunto de identidades, acessíveis a qualquer sistema interno. A dificuldade desta escolha está justamente em conseguir achar uma tecnologia adequada para um grande conjunto de demandas encontradas em um universo amplo de aplicativos. Uma possível solução: a separação das funcionalidades dos diretórios e seu protocolos de acesso.

O que normalmente acontece é que uma aplicação tem necessidade de encontrar um sistema de diretório para validar as identidades que precisa para seu funcionamento. Se pudermos expor um sistema de diretórios através de vários protocolos, é possível nos aproximarmos do sonho de um diretório único, que contém todo o conjunto de identidades da empresa e é capaz de responder às requisições de um grande número de aplicações, inclusive requsições provenientes de outras plataformas tecnológicas.

A seguir (próximo blog): E quando não é possível usar um único diretório?

De volta ao básico: O caos das identidades

Gebara — Thu, 18 Oct 2007 01:14:54 GMT

Em uma entrada de blog anterior, falamos sobre a Anatomia da Indentidade Digital. A leitura deste post já nos leva a crer que é possível, com um planejamento adequado, implementar um sistema de diretório central, no qual orbitam aplicações que necessitam utilizar serviços de autenticação e autorização.

Mas, infelizmente, não é o que encontramos em nosso dia a dia. É muito comum encontrarmos, dentro das empresas, um conjunto de repositórios de identidade desconectados e sem sincronismo, o que leva ao caos atual de identidades. A figura a seguir, adaptada da figura apresentada no texto anterior, nos dá uma aproximação da falta de interação entre essas identidades: é apenas um conjunto desconexo de dados sobre os quais o usuário não tem controle sobre a usar ou não deles. Se quiser usar um novo sistema, é necessário utilizar uma nova identidade, com novas credenciais.

Esse caos traz pelo menos dois tipos de exposição a risco:

1. O excesso de identidades faz com que as pessoas acabem reutilizando meios, potencialmente fáceis de "roubar", para o armazenamento de sua lista de identidades (pares de usuário e senha). Os mais comuns são: o "papelzinho" na gaveta (ou o adesivo no monitor) e o uso de arquivos eletrônicos contendo a lista de identidades utilizadas (normalmente salvos sem criptografia ou qualquer outro mecanismo de segurança de acesso).

2. Fraude no acesso aos sistemas. Quando se possui um conjunto desconectado de repositórios, a superfície de fraude aumenta assustadoramente. O que quero dizer com isso? Analisemos uma situação hipotética: eu sou um funcionário de RH e tenho uma senha para acesso à rede e uma senha para o acesso ao sistema de RH. Digamos que eu seja demitido e minha senha da rede seja bloqueada. Se hão houver um sincronismo com o sistema de RH, é possível eu, baseado em minhas amizades na empresa, pedir a algum outro colega que acesse a rede com sua própria identidade mas entre no sistema de RH com a minha identidade exclusiva deste sistema, na qual eu tenho mais direitos do que ele. Com esse acesso indevido (e não controlado), é possível então realizar operações fraudulentas no sistema, muitas vezes com dificuldades no rastreamento posterior.

É nesse caos que se baseiam as ferramentas de gestão de identidade que mencionamos no post anterior. Para poder gerenciar, sincronizar todos esses elementos e dar uma falsa impressão ao usuário de que existe um logon unificado em sua empresa, é absolutamente necessário incorporar à sua arquitetura de TI um elemento externo, que tente colocar um pouco de ordem neste caos.

Esta organização do caos é benéfica para o usuário mas traz uma carga administrativa maior para a equipe de gestão de TI. Além de ser necessário compreender cada mecanismo de autenticação e autorização de todos os aplicativos e seus repositorios de identidades, é necessário descobrir como o software de gestão de identidade pode interagir com eles para permitir a automaçõo dos processos de provisionamento. Para cada novo par sistema / repositório é necessário incluir mais um elemento no processo na gestão de identidade.

A seguir (próximo blog): A idéia do diretório único

De volta ao básico: anatomia da identidade digital

Gebara — Thu, 04 Oct 2007 13:44:06 GMT

Tem sido bastante comum sermos bombardeados com uma infinidade de ofertas de produtos para o gerenciamento de identidades. A grande maioria das grandes empresas de tecnologia tem uma ou outra oferta, sempre salvadora, para nos ajudar a gerenciar esta selva tropical que é o mundo da autenticação/autorização.

Como sempre, no meio desta verdadeira Torre de Babel, falta um elemento: compreender o que é (ou o que deveria ser) uma identidade digital. Somente a partir daí é possível descobrir: essas ferramentas podem realmente ajudar ou vão complicar ainda mais o cenário?

O que é uma identidade?

Dentro do mundo físico, uma identidade é a parte verificável de uma informação que confere a seu portador uma série de deveres, direitos e privilégios. Normalmente esta identidade é emitida por uma autoridade, reconhecida pelas partes envolvidas no processo de aceite das afirmações.

Exemplos: passaporte, carteiras de identidades, crachás, etc. Esse conjunto de exemplos me ajuda a ilustrar bem o que é uma autoridade reconhecida e também o escopo desta autoridade: um passaporte é uma identidade internacional emitida, aqui no Brasil, por um órgão do governo federal reconhecido por outras nações como um emissor confiável Já a carteira de identidade é reconhecida apenas por instituições nacionais, não as internacionais. Para o crachá, então, a cadeia de confiança é muito menor: normalmente apenas parceiros de négócio confiam em suas informações.

O que é uma identidade digital?

No mundo digital, a identidade é um conjunto de informações estruturadas contendo quatro elementos básicos:

Identificador
Elemento que identifica, inequivocamente, um determinado sujeito dentro de um namespace;
Credencial
Informação que permite validar a autenticidade e a posse de uma determinada identidade;
Perfil essencial
Informação comum, compartilhável com os sistemas consumidores da identidade, que complementam a identificação do sujeito;
Perfil de contexto
Informações sobre o sujeito que têm sentido somente dentro de um determinado contexto.

Identificador

Elemento que identifica, inequivocamente, um determinado sujeito dentro de um namespace.

Simples: um GUID ou um certificado. Serve para, em sistemas eletrônicos, subsitituir todo o conjunto de informações sobre um sujeito por um elemento único, inequívoco. Deve existir um e apenas um sujeito que possa ser representado por um identificador.

Credencial

Informação que permite validar a autenticidade e a posse de uma determinada identidade.

A credencial pode ser uma senha, um PIN, um fator biométrico que, quando aplicados os devidos algoritmos, permita garantir que o sujeito que está apresentando uma determinada identidade a um sistema, é possível validar que ele seja o proprietário desta identidade. A partir do momento em que esta posse é atestada, o identificador pode ser utilizado para representar as informações sobre o sujeito.

Perfil essencial

Informação comum, compartilhável com os sistemas consumidores da identidade, que complementam a identificação do sujeito.

Pense em homônimos: meu nome é Fernando Gebara Filho. Sei que existe mais do que um Fernando Gebara (pai) em nosso país, tornando não desprezível a probabilidade de eu ter um homônimo. O que serve para complementar a minha identificação (nome) neste caso? O parentesco (nome de pai e mãe), a cidade de nascimento, o estado natal, a data de nascimento, etc. Todos esses elementos, associados ao meu nome, ajudam na minha identificação (e, eventualmente, em sua desambigüidade). Sistemas que consomem a minha identidade podem, eventualmente, fazer uso desta informação, que será a mesma para todos esses sistemas.

Perfil de contexto

Informações sobre o sujeito que têm sentido somente dentro de um determinado contexto.

Vamos tomar como exemplo as faixas do judô. Neste esporte, o nível de um lutador é declarado explicitamente pela cor da faixa em sua cintura. Porém, existem diferenças de interpretação dependendo do país (em nosso caso, o contexto) em que você estiver. No Brasil, a graduação segue a seguinte seqüência: branca, cinza, azul, amarela, laranja, verde, roxa, marrom e preta. No Japão, só há três cores: branca, marrom e preta. Uma faixa azul no Japão, em princípio, não possui qualquer significado. Já uma faixa marrom, nos dois países, pode representar um grau de maturidade (ou combatividade) diferentes.

Como os elementos se relacionam?

No centro de tudo está o identificador; para ter acesso a ele é necessário que seja apresentada a credencial adequada. Uma vez feita esta validação, é possível obter os dados constantes do perfil essencial. Por fim, dependendo do sistema, dados referentes aos perfis de contexto podem ser obtidos e utilizados adequadamente.

Idealmente, os dados referentes ao identificador, à credencial e ao perfil essencial estão normalmente contidos em um sistema central de diretório (tal como uma infra-estrutura de Active Directory). Os dados referentes ao perfil de contexto podem também estar armazenados neste mesmo diretório (como é o caso, por exemplo, dos dados de caixa-postal do Microsoft Exchange) ou em um outro sistema diretório (muitas vezes um servidor LDAP ou mesmo tabelas armazenadas em um banco de dados SQL). O elemente que serve de chave de união de todas essas informações é o identificador, único para cada sujeito.