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.

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 Usuários Permissoes n Permissoes Usuários n Papel

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

RBAC – Role Based Access Control Usuários Papéis Permissões Atribuição de Usuários Atribuição de Permissões Sessões Hierarquia de Papéis Constraints rwx-- rw-d- r---- Recursos 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ários Papéis Permissões Engenho de Autorização Camada de dados Chamadas ao Sentinel de diversos pontos da aplicação Auditoria/ Logging Filesystem XML SGBDR Plugins de Autenticação Arq texto Syslog SGBDR . . . Nome e senha Certificados Digitais LDAP Biometria

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

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 Sentinel Consultas Relatórios Usuários Papéis Permissões Fachada Usuários Configurações Entrada de Dados

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 Usuários Papéis Permissões APIs do Sistema Operacional APIs de Baixo Nível da App “Kernel” ou Núcleo Usuários Entrada de Dados Consultas Relatórios Configurações Stub Fachada

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-Based Access Control, August 2001, ACM Transactions on Information and System Security, Vol. 4, No. 3 ...