A segurança de dados é um assunto que vem se tornando cada vez mais relevante no desenvolvimento de aplicações corporativas. Em geral, podemos proteger com relativa facilidade as funcionalidades de nossos sistemas, atribuindo permissões de acesso aos usuários e verificando estas permissões durante a sua execução. Mas isto não é suficiente em aplicações corporativas. Por exemplo, em um sistema acadêmico, somente um professor pode atribuir notas a um aluno, correto? Isso parece fácil de ser implementado. No entanto, pode um professor atribuir uma nota a qualquer aluno? Definitivamente não! Ou seja, precisamos garantir a segurança dos dados, que poderia ser definida como: “A capacidade de um sistema de garantir que as informações fiquem restritas a um contexto de negócio”. Traduzindo, um usuário não pode visualizar ou alterar dados que não estejam em seu contexto de negócio, e não somente em suas permissões funcionais.

Este objetivo é bastante ambicioso, mas totalmente necessário, e, em termos tecnológicos, temos evoluído bastante neste sentido. A especificação JavaEE 5 simplesmente ignora este problema, mas existem algumas soluções de mercado bastante robustas. Irei discorrer sobre duas delas (Spring Security e JBoss Seam), descrever rapidamente a solução que adotamos na Dextra para o desenvolvimento de um sistema de gestão acadêmica e, finalmente, propor uma nova e diferenciada abordagem.

1 – Spring Security

O Spring Security tem como objetivo garantir a segurança no acesso aos objetos de domínio de uma aplicação. Através deste mecanismo, o componente de segurança impede que um objeto de domínio específico seja carregado ou alterado de acordo com uma ACL (access control list) cadastrada em banco de dados. Basicamente, ele permite que sejam armazenados e obtidos de forma eficiente uma ACL para cada um dos objetos de domínio de sua aplicação. Esta abordagem não me parece muito interessante porque, em geral, não quero cadastrar uma ACL para cada um dos meus objetos de domínio. Não quero, por exemplo, cadastrar quais professores podem atribuir notas para cada aluno do meu sistema. E, afinal, meus requisitos são um pouco mais complexos e difíceis de serem implementados desta forma, pois não quero que um professor possa atribuir uma nota em qualquer matéria para um aluno, mas somente em uma matéria e turma específicas. Ou seja, minha regra de segurança pode envolver um ou mais objetos de domínio, relacionados entre si. Com o Spring Security seria preciso, por exemplo, sempre que um relacionamento entre aluno, turma, matéria, professor e outros for atualizado, reconstruir todas as ACLs afetadas.

2 – JBoss Seam

O JBoss Seam provê um mecanismo de segurança para objetos de domínio que utiliza uma abordagem diferenciada, baseada em regras. Utilizando a ferramenta Drools, é possível escrever regras que são eficientemente processadas e que permitem liberar ou bloquear o acesso do usuário a um objeto de domínio específico. Com o uso de regras no lugar de uma ACL, o mecanismo é muito mais abrangente e extensível, pois não preciso cadastrar as permissões em banco de dados, somente escrever uma regra de segurança que diz que um professor somente pode atribuir uma nota a um aluno quando este for professor de uma turma da qual o aluno faça parte. Há, no entanto, um forte acoplamento entre a solução do JBoss Seam e a necessidade de uso do framework JBoss Seam, que nem sempre é uma opção fácil de ser adotada.

3 – Usando aspectos

Recentemente, quando confrontado com este problema, adotei uma solução diferente das duas abordagens acima. Neste caso, a solução adotada envolveu o uso de aspectos através da ferramenta JBoss AOP. Com os aspectos em mãos, implementamos as regras de segurança que são checadas sempre que determinadas funcionalidades são executadas. Tomamos ainda uma decisão, no mínimo, controversa com relação ao uso deste mecanismo de segurança. O objetivo de todo mecanismo de segurança é garantir que o sistema funcione de forma segura. Para isso, basicamente, é preciso que o sistema funcione. Ou seja, a aplicação precisa implementar as mesmas regras definidas no mecanismo de segurança, senão certamente o mecanismo de segurança bloqueará o uso da sua aplicação. Como, neste caso específico, as regras de segurança eram muito complexas e tinham grande propensão a mudanças, optamos por implementar as regras de segurança somente no mecanismo de segurança. Desta forma, por exemplo, quando o mecanismo de segurança encontra um objeto de domínio em uma lista e descobre que ele não deveria estar ali, em vez de acusar uma falha de segurança, ele simplesmente remove o objeto da lista, mecanismo que nós denominamos de filtragem de segurança Assim, não foi preciso implementar em toda a aplicação as regras de segurança e, mesmo assim, o sistema garante segurança no acesso aos dados na aplicação.

Obs: É claro que existem alguns desafios de performance relacionados à solução adotada, mas tratamos performance caso-a-caso, como deve ser efetivamente tratado.

4 – Segurança de Dados – Responsabilidade dos próprios dados!

Apesar de todas as abordagens acima ilustradas, fico sempre ruminando a idéia de que a segurança no acesso a dados é uma característica intrínseca aos dados, não à aplicação. A aplicação deve se preocupar com suas funcionalidades, enquanto o banco de dados deveria se preocupar com os dados. Basicamente, nesta idéia “mirabolante”, seria responsabilidade do banco de dados criar uma visão dos dados para a aplicação. Ou seja, quando a aplicação acessa o banco de dados com um determinado usuário ou uma determinada visão, ela deveria ver somente os dados aos quais possui acesso, como se estes fossem os únicos dados existentes. É claro que esta não é uma solução simples, mas acredito que teremos que pensar um pouco sobre ela na evolução dos SGBDs atuais e no seu relacionamento com as aplicações.

De qualquer forma, continuamos evoluindo a segurança de nossas aplicações de forma rápida e responsável, adotando tecnologias não intrusivas e mecanismos cada vez mais performáticos e consistentes.