Sentinel: um engenho Java para controle de acesso RBAC

1
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
  ltlincoln_at_tempest.com.brgt
• Agosto / 2003

2
Agenda

• Motivação do trabalho
• Objetivos
• Visão geral de controle de acesso
• RBAC Role Based Access Control
• Sentinel arquitetura e funcionalidades
• Trabalhos futuros

3
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

4
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

5
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

6
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

7
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

8
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.

9
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

10
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

11
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

12
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

13
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

14
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.

15
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

. . .
Biometria
LDAP
Certificados Digitais
Nome e senha
16
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

17
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

18
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)

19
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

20
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. OConnor 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
• ...