Embed Size (px)
Citation preview
Controle de Acesso Baseado em Papéis - RBAC
Laboratório de Banco de Dados
Kelly Rosa Braghetto
Controle de Acesso
Autorização relaciona-se com os modos através dos quais usuários podem acessar recursos em um sistema computacional.
Os primeiros artigos relacionados à definição e a modelagem do Controle de Acesso surgiram na década de 1970. Os esforços no sentido de padronização se iniciaram na década de 80.
Autorização X Autenticação Autenticação é o processo que determina se uma
identificação fornecida por um usuário é legítima. O modo mais comum de autenticação é por senha. Formas menos comuns são biometrias e smart cards.
Autorização é uma decisão “sim” ou “não” para uma pergunta do tipo: “o usuário X pode acessar o recurso Y do sistema?”.
Para implementar um processo de autorização, um sistema de informação precisa manter algum relacionamento entre identificadores de usuários e recursos do sistema.
Matriz de Controle de Acesso Introduzida por Lampson (1972) e extendida por
Harrison, Ruzzo e Ullman (1976-8), a matriz de controle de acessos é estruturada da seguinte forma:– Colunas são indexadas por objetos (recursos do
sistema);– Linhas são indexadas por subjects (representação do
usuário dentro do sistema );– As entradas da matriz são operações de acessos (ou
conjunto delas). Esse tipo de matriz fundamenta muitos modelos
teóricos de segurança.
Matriz de Controle de Acesso
Problemas: não é adequada para a implementação direta, pois a matriz pode ser muito esparsa. Além disso, seu custo de manutenção a torna ineficiente.
Uma ACL (Access Control List) corresponde a uma coluna da matriz de acessos. Se foca nos objetos e tipicamente são implementadas no nível do sistema operacional.
Uma CL (Capability List) corresponde a uma linha da matriz de acessos. Se foca nos subjects e tipicamente são implementadas em serviços e aplicações. Aplicações de Banco de Dados utilizam as CPs para implementar o controle de permissões sobre tabelas e consultas de forma bem granular.
arq.txt cmd.exe win.ico
Jason {r,w} {r}
Laila {r} {r,w,x} {w}
Role-Based Access Control (RBAC) É uma família de modelos de referência na qual
privilégios são associados a papéis e papéis são associados a usuários.
Seu conceito começou a ser desenvolvido nos anos 70.
Na abordagem orientada a objetos:– papéis objetos– privilégios direitos de acesso a seus métodos
Motivação: Funcionários de uma organização mudam de posição mais freqüentemente que as obrigações (responsabilidades) relacionadas a uma posição.
RBAC - Características Pode ser configurado para apoiar vários métodos
de controle de acesso diferentes, como MAC (Mandatory Access Control) e o tradicional DAC (Discretionary Access Control).– MAC: baseia-se na atribuição de “rótulos” de
segurança a subjects (usuários) e objetos.– DAC: baseia-se em permissões atribuídas por um
usuário individual (tipicamente, o dono do objeto) a outros usuários.
Utilizado tanto em aplicações stand-alone como em aplicações distribuídas.
RBAC – Pergunta Freqüente
Qual a diferença entre Grupos e Papéis? – Grupos são tipicamente tratados como uma
coleção de usuários (e não uma coleção de permissões).
– Um papel é uma coleção de usuários associada a uma coleção de permissões.
Usuários Permissões
Usuários Permissões Papel
n n
n n
Padrões RBAC Privilégios atribuídos a papéis são derivados a
partir das responsabilidades pertencentes aos trabalhos associados a eles.
Papéis e privilégios são atribuídos e gerenciados por administradores.
Podemos atribuir mais de um papel a um mesmo usuário. A um papel, estão associados vários usuários.
Uma permissão pode ser atribuída a um ou mais papéis. A um papel, podem estar associadas uma ou mais permissões.
Padrões RBAC É possível utilizar o conceito de hierarquia de cargos
(herança e herança múltipla) na definição dos papéis. Por convenção, papéis mais “poderosos” aparecem no topo
do diagrama, enquanto que os mais “fracos” aparecem na base.
Project Supervisor
Project Member
Test Engineer Programmer
RBAC - Conceitos
User: é uma pessoa interagindo com o sistema. Role: é uma coleção de funções que um usuário ou
um grupo de usuários pode executar dentro do contexto de uma organização.
Subject: é a representação do usuário dentro do sistema. Pode-se entender o conceito de sujeito como o de um processo no sistema aliado a um conjunto de credenciais de acesso que associam aquele processo a um usuário da base do sistema.
RBAC - Conceitos
Object: qualquer recurso acessível num sistema, incluindo arquivos, periféricos, bancos de dados, ou entidades mais granulares (como campos individuais de um banco de dados). Objetos são tradicionalmente vistos como entidades passivas, que contêm ou recebem informação.
Operation: é um processo ativo invocado por um subject. O tipo das operações e dos objetos que RBAC gerencia são dependentes do tipo do sistema no qual ele está implementado.
RBAC - Conceitos
Constraints: predicados que podem operar sobre a autorização de um acesso, negando-o ou permitindo-o com base em critérios mais complexos do que o envolvido em operações simples. – Exemplo: um constraint comum é o de separação de
privilégios, no qual um mesmo usuário não pode pertencer a dois papéis que poderiam dar um poder excessivo ao mesmo – como um mesmo usuário participando dos papéis de “gerente de contas” e “auditor”.
Modelos RBAC do NIST
RBAC ganhou gradualmente mais apoio da comunidade acadêmica e comercial, com diversas implementações aparecendo no mercado.
Inexistência de um modelo padronizado para RBAC resultava em incerteza e ineficiência sobre seu significado e utilidade.
Resultado: modelo RBAC do NIST – National Institute of Standards and Technology (padrão atual da RBAC), em 2001.
Visão geral do modelo
RBAC é um conceito muito rico.– Vai de controles simples a controles complexos.
Um único molde definitivo ou iria incluir demais ou excluir demais.
Solução adotada: o modelo RBAC foi organizado em quatro níveis de recursos e funcionalidades crescentes.
Estes níveis foram definidos e formalizados em um conjunto de artigos (ver Referências).
RBAC0: Core RBAC Os recursos requeridos do Core RBAC são obrigatórios a
qualquer implementação de RBAC. Este nível prevê apenas usuários, papéis e permissões. Usuários (ou grupos de usuários) e permissões são associados a papéis.
user_sessions
(UA)User
Assignment
(PA)PermissionAssignment
USERS OBSOPS
SESSIONS
ROLES
Permissions
session_roles
RBAC0: Core RBAC
O RBAC0 define duas relações básicas: a relação entre usuários e papéis (UA – User Assignment), e a relação entre papéis e permissões (PA – Permission Assignment).
Tanto a UA quanto a PA são relações many-to-many.
O modelo RBAC não discorre sobre revogação de permissões ou de usuários de papéis.
RBAC1: Hierachical RBAC Difere do RBAC0 somente na introdução da hierarquia de
papéis - denominada como relação RH. Hierarquias de papéis são uma maneira natural de estruturar
papéis de forma a representar as responsabilidades dentro de organizações.
user_sessions
(RH)Role Hierarchy
session_roles
(UA)User
Assignment
(PA)PermissionAssignment
USERS OBSOPS
SESSIONS
ROLES
Permissions
RBAC2: Constrained RBAC RBAC nível 2 adiciona o recurso de constraints.
– Constraints podem estar associados às relações usuário – papel e papel – permissão ou à ativação de papéis dentro de sessões de usuário no sistema.
O RBAC2 só especifica um tipo de constraint obrigatório a ser apresentado pelo sistema: a separação de deveres, referente ao particionamento de tarefas e privilégios entre diferentes papéis. Mas qualquer outro tipo de constraint pode ser implementado, de acordo com as políticas de cada organização e as características do sistema de controle de acesso.
RBAC2: Constrained RBAC
user_sessions session_roles
(UA)User
Assignment
(PA)PermissionAssignment
USERS OBSOPS
SESSIONS
ROLES
Permissions
SSD
DSD
O nível 2 de RBAC do padrão prevê dois tipos de separação de deveres: – Separação Estática de Deveres (Static Separation of Duty)– Separação Dinâmica de Deveres (Dynamic Separation of Duty)
RBAC2 - Separação Estática de Deveres Visa diminuir o conflito de interesses em um
sistema baseado em papéis ao não permitir que um mesmo usuário pertença a dois papéis considerados mutuamente exclusivos.
A separação é estática porque ela sempre está ativa no sistema, agindo na relação usuário – papel.
Se um usuário é autorizado como membro de um papel, ele é proibido de ser membro de um papel conflitante.
Este tipo de constraints são herdados na hierarquia de papéis.
RBAC2 – Separação Dinâmica de Deveres Esse tipo de separação de deveres fornece a
capacidade de tratar situações de conflitos de interesse no momento em que o usuário entra no sistema assumindo um determinado papel.
O constraint age sobre o estabelecimento da sessão do usuário dentro do sistema.
Permite tratar situações em que um usuário pertença a um conjunto de papéis que não constituem conflito de interesse quando utilizados de modo independente, mas gerem preocupação se utilizados em conjunto.
RBAC – Exemplos de Constraints
Na relação papel – permissão:– permitir ou negar o acesso em determinados horários,
de acordo com uma política estabelecida. Na relação usuário – papel:
– forçar uma quantidade máxima de pessoas por papel (cardinality constraint). Um exemplo de utilização é no caso do papel de um gerente de projeto (só deve existir uma pessoa exercendo-o).
– permitir que um marinheiro de baixo escalão (com um papel correspondente) exerça o papel de comandante de navio (um papel com privilégios mais altos) apenas se ele for o último remanescente no barco, em caso de acidente, por exemplo.
RBAC – Exemplos de Constraints
No estabelecimento da sessão do usuário:
– permitir ou negar o acesso quando o usuário utilizar o sistema a partir de algumas origens específicas – de máquinas não confiadas na rede, por exemplo.
Na relação usuário – papel ou no estabelecimento da sessão:
– exclusão mútua: permite a separação de deveres.
RBAC3 – Modelo Consolidado O RBAC3 combina o RBAC1 e RBAC2, suportando tanto
as hierarquia de papéis quanto os constraints.
user_sessions
(RH)Role Hierarchy
session_roles
(UA)User
Assignment
(PA)PermissionAssignment
USERS OBSOPS
SESSIONS
ROLES
Permissions
SSD
DSD
Referências Sandhu, R., Coyne, E., Feinstein, H., Youman, C. Role-
Based Access Control Models, IEEE Computer 29(2), IEEE Press, 1996, Pages 38-47.
Sandhu, R., Ferraiolo, D., Gavrila, S., Chandramouli, R. and Kuhn, R. Proposed NIST Standard for Role-based access control. ACM Transactions on Information and System Security, Vol. 4, No. 3, August 2001, Pages 224–274.
Sandhu, R., Ferraiolo, D., and Kuhn, R. 2000. The NIST Model for Role-Based Access Control: Towards a Unified Standard. In Proceedings of 5th ACM Workshop on Role-Based Access Control, Berlin, Germany, July 2000.
Web Site do RBAC – NIST: http://csrc.nist.gov/rbac
