Skip to content

Security Toolbox

Segurança

Desde sempre a restrição de acesso a funcionalidades de um sistema, ou ao sistema como um todo é um requisito não funcional sempre presente na aplicações de hoje em dia. Também sempre presente é a falta de preocupação com a segurança da aplicação. Um dos itens mais sensíveis é normalmente relegador para segundo ou terceiro plano ou é assumido que se já foi implementado em aplicações anterioresm então não tem custo ou esfoço ser adicionado à aplicação corrente.

Sabendo isto, e sendo que o MiddleHeaven tem como objetivo oferecer o máximo de requisitos não funcionais já implementado as funcionalidades de segurança não poderiam ficar de fora. Não só a implementação tem que existir como tem que satisfazer os requisitos mais comuns que são normalmente esquecidos ou relegados.

Desenhar e implementar um novo modelo de segurança não é uma tarefa simples. Seria melhor que não posse necessário. Contudo, devido à diretiva de isolamento do MiddleHeaven não ha como escapar.

O modelo de segurança é normalmente baseado em dois conceitos: autenticação e autorização. O primeiro responde à pergunta “Quem és tu?” e o segundo a “O que podes fazer?”.

Autenticação

A autenticação é a ação de identificar o sujeito e validar que ele é quem diz ser. A autenticação se baseia sempre em algum tipo de informação que apenas o verdadeiro sujeito sabe ou pode apresentar. Esta informação é chamada de Credencial. A Credencial mais comum é o nome de usuário do sujeito. O nome de usuário designa uma conta de segurança no sistema que é protegida como uma senha. Portanto, o sistema requisita o nome de usuário para o sujeito e a respetiva senha de acesso. Se a senha for confirmada pelo sistema, o sistema aceita a credencial, caso contrário a rejeita.

O passo de autenticação é portanto aquele em que o sistema recolhe e verifica a autenticidade das credencias do usuário. Básicamente ele faz o papel do agente de segurança na porta do edificio que apenas o deixa entrar se você apresentar uma credencial válida.

O mecanismo de nome e senha é historicamente o mais utilizado porque não depende de software sofisticado ou hardware especifio. Contudo a sua segurança é baixa comparado com outros mecanismos de validação de credenciais. Sobretudo quando a senha não é tratada de forma segura.

Hoje,outros mecanismos está disponiveis sendo a verificação por impressão digital aquele que parece mais cómodo e já integrado com alguns laptops. Do ponto de vista do MiddleHeaven todos os vários mecanismos e credentais têm que ser possiveis. Por isso o modelo de segurança, autenticação e autorização do MiddleHeaven é expansível, contudo ele é concreto. Esta é uma diferença para o modelo padrão da plataforma Java o JAAS ( Java Autentication and Autorization Service). O JAAS é expansível , mas não é concreto, o que significa que um sistema real tem que implementar muito do resto do código necessário para o processo de autenticação e autorização. O MiddleHeaven tenta não incorrer nesse problema e à semelhança de outros frameworks de segurança fornece um modelo para o dominio de segurança que a aplicação pode utilizar directamente.

Autorização

A autorização é a ação de permitir ao sujeito a execução de alguma ação sobre o estado do sistema. Depois que todas as credenciais foram recolhidas e autenticadas o sujeito só poderá fazer aquilo para o qual está autorizado. Também aqui existem vários mecanismo possiveis para a autorização. O mais simples é o mecanismo baseado em papeis (roles). “Papel” é utilizado como no teatro em que o ator desepenha um ou mais papeis.

Na autorização baseada em papeis o sistema outorga ao sujeito um conjunto de papeis de segurança com base nas credenciais que ele apresentou. Normalmente apenas no nome. Os papeis são atribuidos ao sujeito e configurados através de alguma funcionalidade do sistema. Esta funcionalidade é comum e precisa ser re-implementada a cada novo sistema. Existem formas mais simples como a utilização de arquivos onde as configurações permanecem fixas, mas isso é estramente caotico e complexo de ser atualizado para sistemas com muitos usuários e impossivel quando os usuários são desconhecidos à pirori como em sistema web onde normalmente é o usuário que se registra no sistema. Em sistema empresariais normalmente existe um encarregado ou uma equipe encarregada da segurança do sistema e de outorgar acesso a novos usuários.

Outro tipo de autorização é a baseada em permissões. Neste tipo de autorização é outorgada explicitamente ao sujeito a permissão de realizar certa ação sobre um recurso. Este tipo de autorização embora com um controle mais fino é mais complexa de implementar, controlar e até de outorgar as permissões. Rápidamente se torna uma tarefa dificil de gerenciar quando o sistema tem muitos usuários e/ou muitas permissões.

O MiddleHeaven tem que fornecer um mecanismo que possa ser utilizado em ambos os ambientes e em configurações diferentes.

A autorização passa por outro passo. A aplicação tem que se protegida de acesso indevido. Assim, quando o recurso a que o usuário está tentando acessar é restrito, a aplicação tem que verificar se o sujieto está autorizado a acessar aquele recurso e que ações ele pode tomar. O exemplo classico é o usuário ter acesso a um cadastro de cliente, mas apenas poder adicionar um cliente. Ele não pode remover um cliente e não pode editar os dados de um cliente já registrado. O registro do cliente é o recurso protegido e as acções possiveis são : cadastrar, editar e remover. Conforme o dominio da aplicação e as regras de negocio de cada empresa aquilo que o usuário pode e não pode fazer através da aplicação a um determinado recurso forma um conjunto de regras de segurança. Estas regras, assim como as regras de dominio, elas próprias, mudam frequentemente.

A par disso é comum que do ponto de vista de interface com o usuário a aplicação não apresente as opções a que ele não tem acesso, desta forma evitando que o usuário seja constantemente bombardeado com avisos de segurança que o informam que ele não pode utilizar aquela funcionalidade.

Sujeito e Usuário

O sistema de segurança tem que ser desacoplado do dominio da aplicação. Contudo, quando chega no ponto do controle de usuários a diferença fica meio difusa… em alguns casos forçando que o modelo da aplicação implemente alguma interface ou método especifico. O MiddleHeaven deixa bem clara a diferença. O sujeito (classe Subject) é aquele controlado pelo sistema de segurança. É para ele que a autenticação e autorização ocorre. O objecto usuário é aquele defindo pelo dominio da aplicação e pode ser qualquer objecto (classe Object). Desta forma a aplicação pode consultar o usuário em sessão e o MiddleHeaven pode consultar o sujeito sem perigo de interferência.

Na prática muita da autorização é mantida na aplicação como informação relacionada ao usuário o que significa que provavelmente a aplicação terá que procurar e instanciar um objecto usuário para poder outorgar autenticação ao objecto sujeito. O MiddleHeaen considera que isso é um preço menor que forçar que o objeto usuário estenda alguma classe especial que descenda de Subject.

A divisão de águas vai mais longe. Normalmente informações relacionadas à senha como a validade , quem alterou , quando e qual é a senha estão associadas ao usuário do sistema em particular muitas vezes escritas na mesma tabela. Embora isso seja possivel e comum não é realmente uma necessidade. Aliás uma entidade senha independente seria muito mais útil já que para validar a credencial não precisaríamos carregar o objecto de usuário.

Requisitando credenciais

O sistema tem que ser capaz de requisitar,ao sujeito, todas as credenciais que lhe interessam , obtê-las e validá-las. O sujeito é a entidade que o toolbox de segurança entende e controla. Todos os acessos ao sistema têm que ter um sujeito associado. O sujeito por ser um usuário – uma pessoa- ou pode ser outro sistema. Hoje em dia a comunicação entre sistemas é comum e isso tem que ser considerado.

Quando o sujeito é uma pessoa obter as credenciais comumente significa apresentar algum tipo de interface gráfica especifica ( a famosa tela de login), mas pode ir além como a consulta a hardware ou a consulta a outros sistemas ( em um sistema single sign-on por exemplo). Quando o sujeito é outro sistema a comunicação é mediada por algum tipo de protocolo que pode ou não suportar funcionalidade de segurança (muitas vezes não suporta). Para conseguir colaborar com todas as forma de requisição o MiddleHeaven segue o padrão de projeto Callback já existente no JAAS. A ideia aqui é que o objecto autenticador diz À aplicação que informações precisa e a aplicação se encarrega de perguntar ao usuário e/ou à API mediadora com o outro sistema.

Outras credenciais

Hoje em dia a proteção de contas com senha não é mais uma garantia de que o usuário é licito. Ainda para mais em sistemas web abertos, literalmente, a todo o mundo. Muitas aplicações já requerem que durante a inscrição o usuário comprove que é um ser humano. Os famosos mecanismos CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) que testa se a inscrição está sendo realmente feita por um ser humano. Este tipo de credencial é normalmente verificado durante o cadastro e outorgado ao sujeito em runtime quando ele apresenta outro tipo de credencial. Daqui se infere que com base em credenciais é possivel ,não só outorgar papeis e permissões, mas também outras credenciais.

Um outro tipo de credencial é aquele outorgado por licenças. A licença é normalmente um componente de software protegido que outorga a autorização ao sujeito, ou grupo de sujeitos, de poder executar certas ações no sistema. Uma dessas ações é a própria possibilidade de utilizar o sistema como um todo. Esta é uma funcionalidade comum em software proprietário já que é utilizada como fonte de renda, mas é util também em sistema de demonstração em que parte das funcionalidades são limitadas. O acesso limitado por licença também tem que ser equacionado dentro do mecanismo de segurança e embora o MiddleHeaven suporte a definição de licenças através de uma toolbox separada o MiddleHeaven provê forte integração entre as duas toolboxes através de autenticadores.

O modelo

O modelo da Toolbox de Segurança do MiddleHeaven tem que ser rico, concreto e extensivel o suficiente para ser útil em muitos sistemas sem ser necessário recorrer a reimplementação. Além disso a implementação do modelo tem que utilizar práticas de codificação que não permitam que o processo de segurança seja viciado por algum dos intervenientes plugáveis.

Muitas outras APIs foram estudadas para chegar em um modelo coerente , concreto e extensivel. Principalmente a JAAS por ser o padrão da plataforma e com a qual o modelo tem que ser compativel e extensivel afim de reaproveitar modulos já implementados em JAAS. Em segundo a API de segurança Acegi, hoje, Spring Security que tenta algo semelhante ao que o MiddleHeaven Security Toolbox realiza. O problema com o modelo do Acegi é que é delegada à aplicação boa parte da responsabilidade de autenticação do usuário sendo a API apenas um mecanismo de controle mas não uma segurança.

Autenticator e Autorizator

Precisamos que o sujeito seja autenticado ( suas credenciais sejam verificadas autênticas). Existem várias formas padrão de fazer isto – da qual a dobradinha nome/senha é a mais usada. Esta forma implica algumas funcionalidades padrão como a criptografia destrutiva da password e o trafego protegido da password. Estas funcionalidades têm que ser providas ( ou pelo menos possiveis via configuração) pelo MiddleHeaven.

Independentemente de como o sujeito é autenticado e o sistema recolhe as suas credenciais o sujeito tem que ser autorizado. Os mecanismos de autorização que variam da simplicidade do modelo de papeis (roles) até ao modelo de permissões explicitas são uma decisão de implementação da aplicação. O papel da toolbox, neste ponto, é prover plugabilidade e algumas implementações padrão das estratégias mais comuns (roles, por exemplo). Além disso, autenticadores especiais podem aumentar as credenciais dos sujeito como aqueles relacionados a licenças ou a CAPTCHA.

O conjunto de Autenticadores e Autorizadores escolhidos para a aplicação formam um contexto de autenticação e autorizção. Este contexto é totalmente configurado pela aplicação e o a toolbox se encarrega se verificar que ele é cumprido.

Assinatura e Sessão

É comum que após o login do usuário ele ganhe o direito de utilizar o sistema. Contudo é também comum que este direito não seja permanente. Em periodos regulares ou aleatório o sistema verifica se as credenciais ainda são válidas e se não foram é pedido ao usuário que as revalide ( as informa de novo). Esta funcionalidade é muito comum em sistema web em que é comum abandonar o browser aberto em terminda página ou utilizar um computador publico. Esta funcionalidade também é interessante em ambiente desktop em que após um tempo de inatividade o sistema é trancado e o usuário tem que refazer o login ( por exemplo, em sistemas operativos após voltar da proteção de tela).

A metáfora para o login/sign in costuma ser a de um hotal onde o hóspede assina um livro quando entra e quando sai do hotel (é dai que vem o nome “sign in” = “assinar para entrar”). O MiddleHeaven reforma esta metáfora implementando o conceito de assinatura através do objeto Signature. Se o sistema tem uma assinatura válida o usuário é tido como autenticado e o processo de login não precisa ser repetido. Se a assinatura não está presente as credenciais são pedidas de novo. O como e porquê uma assinatura se perde depende da própria implementação da assinatura.

Em sistemas web o conceito de login/sign in dá origem ao conceito de sessão. Se o usuário está logado a sessão é válida. Em java isso se confunde muitas vezes com o objeto Session da API de Servlets. Normalmente o objeto do usuário é guardado no objeto Session e quando este objeto é invalidado (pelas regras do Servlet Container) o usuário é invalidado junto e o processo de login é novamente necessário. Esta ideia tem vários problemas sobretudo em sistema que precisam escalar. A solução é utilizar cookies para manter a sessão válida mesmo quando o objeto Session é outro. O problema aqui é que precisamos manter na cookie as informações que permitem reconstituir a autenticação do usuário.

O JAAS não inclui este conceito porque ele é de uso genérico e desacoplado das funcionaldiades finais da aplicação. O Spring Security implementa este conceito colocando na cookie o nome e senha do usuário. Isso é tudo muito certo se esse é o mecanismo de autenticação, mas e se não for ? Poderiamos guarda apenas o nome do usuário ( guardar apenas a identificação do usuário) mas teriamos que recuperar todas as suas credenciais. O Spring Security/Acegi não é o fornecedor das credenciais o que significa que a aplicação pode refazer todo o processo apenas baseado no nome do usuário. Neste caso a assinatura é controlada pelo sistema de segurança. O problema com este modelo é que assume que autenticação e autorização são feitas de uma vez só e pelo mesmo tipo de objetos (o JAAS tem este mesmo problema).

O MiddleHeaven toma outra rota. Sendo que o mecanismo de autenticação e autorização é feito por objetos diferentes é sempre possivel autorizar o usuário se ele já tiver sido autenticado. Assim, a assinatura apenas necessita de manter as credenciais do sujeito para que o sistema não repida o processo de as requisitar e revalidar. Contudo elas têm que ser mantidas de forma sigilosa ( leia-se criptografada). A estratégia é então colocar as credenciais em um cookie criptografado. O problema com isso é que os browsers só são obrigados a guardar um numero limitado de cookies por servidor e cada cookie pode ter no máximo 4096 bytes de tamanho. A criptografia de todas as credenciais tem portanto que caber em 4096 bytes. Isso pode se revelar complexo de gerenciar. O resultado é que precisamos de um gerenciador de assinatura que seja implementado conforme o ambiente que o sujeito está utilizando para comunicar com o sistema. Entra em cena o SignatureStore. Em ambiente web o SignatureStore controla as cookies de assinatura em outros ambientes ele fará outro tipo de controle. Assim várias estratégias são possiveis até para o mesmo ambiente. Por exemplo, no ambiente web podemos reverter ao uso do objecto Session em uma primeira release mais limitada para depois alterarmos para um mecanismo mais abrangente.

Deixe um Comentário

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s

%d bloggers like this: