Controle de Acesso Baseado em Papéis - RBAC Laboratório de Banco de Dados Kelly Rosa Braghetto kellyrb@ime.usp.br

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 arq.txt cmd.exe win.ico Jason {r,w} {r} Laila {r,w,x} {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 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. n n Usuários Permissões n n Usuários Papel 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 Test Engineer Programmer 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 (PA) Permission Assignment USERS 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 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. (RH) Role Hierarchy (UA) User Assignment (PA) Permission Assignment USERS 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 (UA) User Assignment (PA) Permission Assignment USERS ROLES OPS 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. SSD (RH) Role Hierarchy (UA) User Assignment (PA) Permission Assignment USERS ROLES OPS 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 Role-Based Access Control, Berlin, Germany, July 2000. Web Site do RBAC – NIST: http://csrc.nist.gov/rbac