Controle de Acesso Baseado
em Papéis - RBAC
Laboratório de Banco de Dados
Kelly Rosa Braghetto
[email protected]
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
Jason
Laila
arq.txt
{r,w}
{r}
cmd.exe
{r,w,x}
win.ico
{r}
{w}
 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.
Role-Based
(RBAC)
Access
Control
 É 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
Usuários
n
n
n
n
Papel
Permissões
Permissões
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
Programmer
Test Engineer
Project Member
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.
(UA)
User
Assignment
USERS
(PA)
Permission
Assignment
ROLES
OPS
OBS
Permissions
user_sessions
session_roles
SESSIONS
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 manyto-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.
(RH)
Role Hierarchy
(UA)
User
Assignment
USERS
(PA)
Permission
Assignment
ROLES
OPS
OBS
Permissions
user_sessions
session_roles
SESSIONS
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
 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)
SSD
(PA)
Permission
Assignment
(UA)
User
Assignment
USERS
OPS
ROLES
OBS
Permissions
user_sessions
session_roles
SESSIONS
DSD
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.
(RH)
Role Hierarchy
SSD
(PA)
Permission
Assignment
(UA)
User
Assignment
USERS
OPS
ROLES
OBS
Permissions
user_sessions
session_roles
SESSIONS
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 RoleBased Access Control, Berlin, Germany, July 2000.
 Web Site do RBAC – NIST: http://csrc.nist.gov/rbac