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 <[email protected]>
Agosto / 2003
1
Agenda
•
•
•
•
•
•
Motivação do trabalho
Objetivos
Visão geral de controle de acesso
RBAC – Role Based Access Control
Sentinel – arquitetura e funcionalidades
Trabalhos futuros
Trabalho de graduação em segurança da informação
2
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
Trabalho de graduação em segurança da informação
3
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
Trabalho de graduação em segurança da informação
4
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
Trabalho de graduação em segurança da informação
5
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
Trabalho de graduação em segurança da informação
6
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”
Trabalho de graduação em segurança da informação
7
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.
Trabalho de graduação em segurança da informação
8
RBAC – Role Based Access Control
• DAC e MAC associam usuários a permissões
Usuários
n
n
Permissoes
• RBAC traz o conceito de papel, intermediando esse acesso
Usuários
n
n
Papel
n
n
Permissoes
• 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
Trabalho de graduação em segurança da informação
9
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
Trabalho de graduação em segurança da informação
10
RBAC – Role Based Access Control
Hierarquia de Papéis
Usuários
Atribuição
de Usuários
Sessões
Papéis
Atribuição
de Permissões
Permissões
rwx-rw-dr----
Recursos
Constraints
• 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
Trabalho de graduação em segurança da informação
11
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
Trabalho de graduação em segurança da informação
12
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
Trabalho de graduação em segurança da informação
13
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.*”
Trabalho de graduação em segurança da informação
14
Sentinel – arquitetura e funcionalidades
Classes de definição e semântica do Resource
ResourceID
Engenho de
Autorização
Chamadas ao Sentinel
de diversos pontos da
aplicação
Biometria
LDAP
Certificados Digitais
Camada de
dados
Auditoria/
Logging
Plugins de
Autenticação
Nome e senha
Aplicação “usuária”
•Arq texto
•Syslog
•SGBDR
Usuários
Papéis
Permissões
•Filesystem
•XML
•SGBDR
...
Trabalho de graduação em segurança da informação
15
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
Trabalho de graduação em segurança da informação
16
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
retroequipar, não altera
significativamente a arquitetura da
aplicação
Cons: O programador escrever código
para perguntar ao Sentinel a cada
operação
Usuários
Usuários
Papéis
Permissões
Fachada
•
• Prós: Mais fácil de implementar ou
Configurações
Relatórios
Sentinel
Consultas
Entrada de Dados
Trabalho de graduação em segurança da informação
17
Sentinel – Integração estilo kernel
• O núcleo da aplicação exporta APIs para
•
• Prós: Mais seguro: o desenvolvedor
execução das funcionalidades com controle
de acesso já previamente autorizado no
•
Sentinel
As funcionalidades usam-se dessas APIs
para implementarem suas tarefas
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)
“Kernel” ou Núcleo
Fachada
Usuários
Configurações
Stub
Relatórios
Stub
Consultas
Stub
Entrada de Dados
Stub
Usuários
Papéis
Permissões
Sentinel
APIs de Baixo
Nível da App
APIs do Sistema
Operacional
Trabalho de graduação em segurança da informação
18
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
Trabalho de graduação em segurança da informação
19
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
...
Trabalho de graduação em segurança da informação
20