200 likes | 358 Views
Sentinel: um engenho Java para controle de acesso RBAC. Trabalho de graduação – Segurança da Informação – CIn / UFPE Cristiano Lincoln de Almeida Mattos <lincoln@tempest.com.br> Agosto / 2003. Agenda. Motivação do trabalho Objetivos Visão geral de controle de acesso
E N D
Sentinel: um engenho Java para controle de acesso RBAC Trabalho de graduação – Segurança da Informação – CIn / UFPE Cristiano Lincoln de Almeida Mattos <lincoln@tempest.com.br> Agosto / 2003
Agenda • Motivação do trabalho • Objetivos • Visão geral de controle de acesso • RBAC – Role Based Access Control • Sentinel – arquitetura e funcionalidades • Trabalhos futuros
Motivação do trabalho • Segurança é cada vez mais necessário em sistemas computacionais e controle de acesso é um aspecto básico • Controle de acesso costuma ser mal dimensionado, arquitetado e implementado em muitas aplicações • Resultados: • Permissões excessivas • Muito esforço para gerenciamento • Arquiteturas restritas e inflexíveis • Reimplementação
Objetivos • O objetivo do Sentinel é o de ser um engenho de controle de acesso que possa ser utilizado em grande variedade de aplicações Java • Arquitetado pensando em flexibilidade e extensibilidade • Integrar-se a diferentes tipos de aplicações • Utilizar modelo RBAC, que vem ganhando grande aceitação • O objetivo deste trabalho foi descrever e caracterizar o problema, traçar os critérios para tratá-lo, descrever a arquitetura e implementar o engenho
Visão geral de controle de acesso • Acesso pode ser definido como a capacidade de realizar alguma operação em um recurso computacional • Controle de acesso baseia-se em três princípios • Autenticação: o processo de identificação do usuário • Vários tipos: senhas (algo que você sabe), tokens (algo que você possui), biometria (algo que você é), etc. • Autorização: uma vez autenticado, o que esse usuário pode fazer? • Auditoria: prover mecanismos de acompanhar os eventos do sistema • Conceitos pertinentes • Sujeito • Permissão: objeto + operação
Modelos e políticas de controle de acesso • Modelos de controle de acesso (autorização) definem características primitivas de um conjunto de regras de autorização a serem utilizadas – definem a semântica básica • Dentro de um modelo podem existir diferentes políticas de controle de acesso – declarações sucintas das propriedades de proteção que um sistema precisa possuir • Políticas para sistemas militares, financeiras, para saúde, etc. • Os dois modelos mais conhecidas atualmente são MAC (Mandatory Access Control) e DAC (Discretionary Access Control) • RBAC é um modelo que vem ganhando bastante força
Modelos e políticas de controle de acesso • DAC: usuários são donos de um recurso e tem o controle sobre quem deve acessá-lo com que permissões • Muito utilizado em sistemas comerciais (UNIX, Windows, etc.) • MAC: usuários não são donos do objeto e não podem definir suas permissões de acesso, atendo-se à política implantada pelo administrador • Principalmente utilizado em ambientes restritos como militares, financeiros • Exemplo de política de acesso multinível – Bell Lapadula • Rotulação das informação em níveis – classified, confidential, secret, top secret, etc. • Usuários possuem rótulos e acessam as informações de acordo com o rótulo delas • Propriedades básicas: • Usuários só podem ler dados de categorias iguais ou menores que a sua: “no read up” • Usuários só podem escrever dados de categorias menores que a sua: “no write down”
DAC e MAC hoje • O MAC é reconhecido por ser potencialmente mais seguro e controlável, mas não tem obtido popularidade comercial • Pouco flexível e adaptado aos processos empresariais • O DAC é bastante popular no mundo comercial, mas também tem suas deficiências • Gerenciamento complexo, em sistemas com milhares de usuários e recursos • Acaba-se gerando permissões excessivamente relaxadas • Grupos costumam ser utilizados para simular papéis • Nenhum dos dois modelos prevê regras de acesso mais complexas, como separação de privilégios.
Usuários Permissoes n n Usuários Papel Permissoes n n n n RBAC – Role Based Access Control • DAC e MAC associam usuários a permissões • RBAC traz o conceito de papel, intermediando esse acesso • Apesar de simples, o conceito traz poder expressivo • Usuário tem permissão de acesso somente se pertence a um papel autorizado a essa permissão • Organizações trabalham em cima de papéis / cargos. Por isso, papéis são mais estáveis que usuários e obejtos: com isso, o gerenciamento é facilitado • Heranças de papéis provêem um meio sucinto de expressar privilégios gradualmente maiores • RBAC vem sendo bastante discutido na academia e no mundo comercial, com estudos que comprovam a sua eficácia na diminuição de custos com gerenciamento
RBAC – Role Based Access Control • Papéis não são grupos de usuários • Apesar de grupos rotineiramente serem utilizados para “simular” papéis em sistemas DAC • Em RBAC, grupos expressam características próprias como local (“grupo-usuários-recife”) • Hierarquia de papéis
Hierarquia de Papéis Usuários Papéis Permissões Atribuiçãode Usuários Atribuiçãode Permissões rwx-- rw-d- r---- Recursos Constraints Sessões RBAC – Role Based Access Control • Constraints são predicados que atuam sobre uma autorização de acesso, negando-a ou permitindo-a com base em critérios mais complexos que o de simples operações • Separação de privilégios estática: uma mesma pessoa não pode pertencer a papéis excludentes • Separação de privlégios dinâmica: uma pessoa só pode estar logada com um dos papéis de um conjunto excludente • Autorização dependente do contexto: exemplos do médico na UTI e marinheiro no navio
RBAC – Role Based Access Control • O NIST padronizou um modelo RBAC, com diferentes níveis de complexidade • Níveis: • RBAC1 – Core RBAC: sem hierarquias nem restrições (constraints) • RBAC2 – Hierarchical RBAC: com hierarquias, sem restrições • RBAC3 – Constrained RBAC: com hierarquias, com restrições • O modelo RBAC é neutro em termos de política, podendo ser configurado para implantar vários tipos • RBAC pode ser considerado mandatório ou discrecionário? Nenhum – dependendo da política configurada, ele pode pender mais para um lado ou o outro
Sentinel – critérios de design • Segurança • Atender às regras de autorização do modelo RBAC • Utilizar técnicas de programação segura • Flexibilidade • Ser um engenho de controle de acesso independente de aplicação, mas com mecanismos flexíveis para integração a diferentes tipos de aplicação • Suporte a diferentes vários tipos de autenticação – login/senha, certificado digital, etc. • Extensibilidade • O Sentinel provê um framework baseado em plugins que permitem estender e customizar as regras de acesso • Plugins são utilizados para implementar autenticadores, constraints e operações que sejam de necessidade específica da aplicação
Sentinel – arquitetura e funcionalidades • Desenvolvido em Java Puro: amplamente portável • Genérico e dissociado da aplicação • Porém, toda aplicação tem seu conceito próprio do recurso que deve ser protegido e consequentemente as operações a serem executadas naquele recurso • Para tal, é necessária uma camada de adaptação para se integrar à aplicação: a definição e implementação dos Resources • Integração através do conceito de “Recurso” • Pode representar funcionalidades, objetos em um sistema de arquivos, colunas em uma tabela de um SGBD, etc. • Implementado com uma classe abstrata provida pela aplicação para definir o namespace e a semântica dos objetos • Exemplos: • Arquivo: “/etc/passwd”, “c:\windows\win.ini”, “/lib/abc*” • Funcionalidades: “Funcionalidade001”, “RelatorioVendasSemestral”, “funcoes.relats.vendas” • Outros tipos: “.1.3.6.1.2.1.1.1” (OID de SNMP), “dados.planilhas.custos-Recife” , “dados.*”
Sentinel – arquitetura e funcionalidades Classes de definição e semântica do Resource Aplicação “usuária” ResourceID UsuáriosPapéisPermissões Engenho deAutorização Camada de dados Chamadas ao Sentinelde diversos pontos daaplicação • Filesystem • XML • SGBDR Auditoria/Logging Plugins deAutenticação • Arq texto • Syslog • SGBDR . . . LDAP Biometria Nome e senha Certificados Digitais
Sentinel – componentização • Plugins de autenticação • Implementação de classe com interface bem-definida • Caso autenticado, recebe uma credencial de acesso que deve ser utilizada em cada pedido de autorização • Plugins de constraints • Sob a relação usuário – papel: acionados na alteração entre usuário e papel, recebe o ID do usuário e o papel envolvidos • Sob a relação papel – permissões: acionado em um pedido de autorização, recebe o ID do papel, do objeto e das permissões desejadas • No estabelecimento da sessão: acionado no momento do login, recebe o ID do usuário, papel e informações de origem do usuário • Plugins de operações • Podem ser implementadas operações mais complexas e apropriadas a uma determinada aplicação: “débito” e “crédito” ao invés de leitura, escrita e remoção
UsuáriosPapéisPermissões Usuários Configurações Fachada Relatórios Sentinel Consultas Entrada de Dados Sentinel – Integração opcional • Arquiteturalmente, o Sentinel é um componente independente dentro da aplicação • Cada funcionalidade da aplicação pergunta ao Sentinel se o usuário atual está autorizado a usar uma funcionalidade • Prós: Mais fácil de implementar ou retroequipar, não altera significativamente a arquitetura da aplicação • Cons: O programador escrever código para perguntar ao Sentinel a cada operação
“Kernel” ou Núcleo Usuários UsuáriosPapéisPermissões APIs de Baixo Nível da App Configurações Stub Fachada Relatórios Stub Consultas Stub APIs do Sistema Operacional Sentinel Entrada de Dados Stub Sentinel – Integração estilo kernel • O núcleo da aplicação exporta APIs para execução das funcionalidades com controle de acesso já previamente autorizado no Sentinel • As funcionalidades usam-se dessas APIs para implementarem suas tarefas • Prós: Mais seguro: o desenvolvedor não tem como esquecer de checar permissões • Cons: Requer repensar ou reestruturar radicalmente a aplicação (ou que ela já tenha sido projetada assim)
Sentinel – conclusões e trabalhos futuros • Controle de acesso parece simples, mas o campo é cheio de sutilezas e preocupações práticas (segurança, performance, extensibilidade, gerenciamento, etc.) • O campo de RBAC possui teoria bem embasada, mas poucas experiências na modelagem, arquitetura e implementação de engenhos. O Sentinel é um passo para suprir essa lacuna e agregar a experiência. • Trabalhos futuros • Funcionamento do Sentinel como serviço de autorização em rede. • Um autorizador central de um ambiente distribuído • Possivelmente utilizando CORBA ou Web Services como interface de acesso • Segurança no transporte, e credenciais de acesso resistentes a spoofing • Implementação de constraints utilizando princípios de especificação formal do conceito • Construção de biblioteca robusta e extensa de plugins de autenticação e constraints para serem utilizados no framework definido pelo Sentinel • Melhorias na camada de dados e interfaces de configuração
Referências • Ross Anderson, Security Engineering: a guide to building dependable distrited systems, Wiley Computer Publishing, 2001 • Ravi S. Sandhu, Edward J. Coyne, Hal L. Feinstein & Charles E. Youman. Role-based access control models. IEEE Computer, 29(2):38-47, February 1996. • Michael P. Gallaher, Alan C. O’Connor & Brian Kropp, The Economic Impact of Role-Based Access Control, Mar/2002, National Institute of Standards and Technology, US Department of Commerce11 • David Ferraiolo & Richard Kuhn, Role-Based Access Control, 1992, Proceedings of 15th National Computer Security Conference • David Ferraiolo, Ravi Sandhu, Serban Gavrila, Richard Kuhn & Ramaswamy Chandramouli, Proposed NIST Standard for Role-BasedAccess Control, August 2001, ACM Transactions on Information and System Security, Vol. 4, No. 3 • ...