UNIVERSIDADE DE BRASLIA

FACULDADE DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA ELTRICA

APLICABILIDADE DO MODELO RBAC NO

CONTROLE DE ACESSO PARA A REDE SEM FIO DO
SENADO FEDERAL

HERALDO VIEIRA DA CONCEIO

ROBERTO DE OLIVEIRA SILVA

ORIENTADOR: ROBSON DE OLIVEIRA

ALBUQUERQUE

MONOGRAFIA DE ESPECIALIZAO EM
ENGENHARIA ELTRICA

PUBLICAO: UNB.LABREDES.MFE 003/2006

BRASLIA / DF: 08/2006

 UNIVERSIDADE DE BRASLIA
FACULDADE DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA ELTRICA

APLICABILIDADE DO MODELO RBAC NO

CONTROLE DE ACESSO PARA A REDE SEM FIO DO
SENADO FEDERAL

HERALDO VIEIRA DA CONCEIO

ROBERTO DE OLIVEIRA SILVA

MONOGRAFIA DE ESPECIALIZAO SUBMETIDA AO DEPARTAMENTO DE

ENGENHARIA ELTRICA DA FACULDADE DE TECNOLOGIA DA UNIVERSIDADE DE
BRASLIA, COMO PARTE DOS REQUISITOS NECESSRIOS PARA A OBTENO DO GRAU
DE ESPECIALISTA.

APROVADA POR:

ROBSON DE OLIVEIRA ALBUQUERQUE, Mestre, UnB

(ORIENTADOR)

ANDERSON CLAYTON ALVES NASCIMENTO, Doutor, UnB

(EXAMINADOR INTERNO)

ODACYR LUIZ TIMM JR, Mestre, OM

(EXAMINADOR)

DATA: BRASLIA/DF, 29 de agosto de 2006.

ii
FICHA CATALOGRFICA
CONCEIO, HERALDO VIEIRA DA
SILVA, ROBERTO DE OLIVEIRA
Aplicabilidade do Modelo RBAC no Controle de Acesso para a Rede Sem Fio do Senado Federal
[Distrito Federal] 2006.
xiv,76p., 297 mm (ENE/FT/UnB, Especialista, Engenharia Eltrica, 2006).

Monografia de Especializao Universidade de Braslia, Faculdade de Tecnologia. Departamento de

Engenharia Eltrica.

1. RBAC 2. Controle de acesso

3. Rede sem fio 4. Wireless

I. ENE/FT/UnB. II. Ttulo (Srie)

REFERNCIA BIBLIOGRFICA
CONCEIO, HERALDO VIEIRA DA e SILVA, ROBERTO DE OLIVEIRA. 2006. Aplicabilidade
do Modelo RBAC no Controle de Acesso para a Rede Sem Fio do Senado Federal. Monografia de
Especializao, Publicao UNB.LABREDES.MFE 003/2006, Departamento de Engenharia Eltrica,
Universidade de Braslia , Braslia , DF, 76p.

CESSO DE DIREITOS
NOME DO AUTOR: Heraldo Vieira da Conceio e Roberto de Oliveira Silva
TTULO DA DISSERTAO: Aplicabilidade do Modelo RBAC no Controle de Acesso para a Rede
Sem Fio do Senado Federal.
GRAU/ANO: Especialista/2006.

concedida Universidade de Braslia permisso para reproduzir cpias desta Monografia de

Especializao e para emprestar ou vender tais cpias somente para propsitos acadmicos e
cientficos. tambm concedida Universidade de Braslia permisso para publicao desta
dissertao em biblioteca digital com acesso via redes de comunicao, desde que em formato que
assegure a integridade do contedo e a proteo contra cpias de partes isoladas do arquivo. O autor
reserva outros direitos de publicao e nenhuma parte desta dissertao de mestrado pode ser
reproduzida sem a autorizao por escrito do autor.

Heraldo Vieira da Conceio

SQS 216 bloco E ap. 504
CEP 70.295-050 Braslia DF - Brasil

Roberto de Oliveira Silva

SQN 304 bloco F ap. 114
CEP 70.736-060 Braslia DF - Brasil

iii
s nossas famlias, pela educao, pela
oportunidade e pelo apoio que nos
permitiu chegar a esse ponto.

Lili, pela generosidade, compreenso,

pacincia, incentivo, fora, amizade e
companheirismo.

iv
 AGRADECIMENTOS

Ao nosso orientador Professor Robson de Oliveira Albuquerque, pelo tempo,

pacincia, apoio e incentivo dedicados orientao para o desenvolvimento deste trabalho.

Aos colegas do SIER Servio de Infra-estrutura de Rede e do SPB Servio de

Projetos Especiais B, do PRODASEN, pelas conversas enriquecedoras, colaborao e
amizade.

Ao PRODASEN, pela iniciativa de patrocinar, institucional e financeiramente, um

curso de ps-graduao como este.

A todos, nossos sinceros agradecimentos.

A Deus pelo dom da vida e por nos permitir viv-la com sade.

v
 Aplicabilidade do Modelo RBAC no Controle de Acesso para
a Rede Sem Fio do Senado Federal

RESUMO

A Tecnologia da Informao oferece atualmente diversas opes tecnolgicas,

amplamente utilizadas no processamento eletrnico de dados e na comunicao entre pessoas
e instituies. Uma dessas opes so as redes sem fio (Wireless Networks), que tm se
tornado bastante populares, tanto no segmento institucional/empresarial quanto no
domstico/residencial. Qualquer tecnologia aplicada ao processamento eletrnico, utilizada
para produo, distribuio e compartilhamento de informaes, requer mecanismos
apropriados de controle de acesso com o objetivo de garantir sua autenticidade,
confidencialidade e integridade. O RBAC (Role Based Access Control) ou Controle de
Acesso Baseado em Papis (ou Perfis) um modelo de controle de acesso para proteo de
informaes e recursos em ambientes informatizados.

Este trabalho apresenta uma descrio do RBAC, mostrando sua funcionalidade,

vantagens e implicaes, com nfase na sua aplicao na rede sem fio do Senado Federal.
Pretende-se identificar os cenrios em que isso pode acontecer, propondo tambm uma
arquitetura de componentes de hardware e software necessrios para a implementao do
modelo RBAC.

vi
 ABSTRACT

Information Technology offers several technological options widely used into the
electronic processing of data and on communication among people and institutions. One of
those options is Wireless Networks, which have become quite popular, either into the
institutional/business community or into the domestic/residential segment. The technology
applied to electronic processing, used for production, distribution and sharing of information,
requires appropriate mechanisms of access control with the objective of guaranteeing
authenticity, confidentiality and integrity. The RBAC (Role Based Access Control) is a model
of access control for protection of information and resources in computerized environments.

This work presents a description of the RBAC model, showing its functionality,
advantages and implications, with emphasis in its application on the Wireless Network of
Brazilian Federal Senate. It intends to identify the scenarios in which RBAC may fit, also
proposing an architecture of hardware and software components necessary for implementation
of the RBAC model.

vii
 NDICE

Captulo Pgina

1. INTRODUO ........................................................................................................ 1

1.1. OBJETIVO ............................................................................................................................ 6

1.2. ORGANIZAO DO TRABALHO ........................................................................................... 6

2. ROLE-BASED ACCESS CONTROL.................................................................... 7

2.1. MTODOS DE CONTROLE DE ACESSO .................................................................................. 8

2.1.1. Matriz de Controle de Acesso ..................................................................................... 9

2.1.2. Lista de Controle de Acesso (ACL) .......................................................................... 10

2.1.3. Capabilities ................................................................................................................. 10

2.1.4. User Based Access Control (UBAC)......................................................................... 11

2.1.5. Policy Based Access Control (PBAC)....................................................................... 12

2.1.6. Content Dependent Access Control (CDAC) .......................................................... 13

2.1.7. Context Based Access Control (CBAC) ................................................................... 13

2.1.8. View Based Access Control (VBAC)........................................................................ 14

2.1.9. Controles de Acesso Discricionrio e Mandatrio.................................................. 15

2.2. TERMOS E DEFINIES DO RBAC...................................................................................... 16

2.3. MODELO DE REFERNCIA RBAC .................................................................................... 17

2.3.1. Components do RBAC .............................................................................................. 17

2.3.2. Core RBAC................................................................................................................. 18

viii
2.3.3. Hierarchal RBAC ...................................................................................................... 20

2.3.4. Constrained RBAC .................................................................................................... 21

2.3.5. Modelo RBAC Consolidado...................................................................................... 23

2.4. ESPECIFICAO FUNCIONAL DO RBAC .......................................................................... 24

2.4.1. Funes Administrativas........................................................................................... 24

2.4.2. Funes de Suporte do Sistema ................................................................................ 25

2.4.3. Funes de Reviso .................................................................................................... 25

3. CARACTERIZAO DO AMBIENTE ............................................................. 27

3.1. PERFIL DA INSTITUIO SENADO FEDERAL NO CONTEXTO DA TI E DA SEGURANA DA

INFORMAO ........................................................................................................................... 27

3.2. SITUAO ATUAL DA REDE DO SENADO FEDERAL ........................................................... 29

3.3. DEMANDA POR REDE SEM FIO NO SENADO FEDERAL ...................................................... 30

4. APLICABILIDADE E GESTO DO RBAC NA REDE SEM FIO DO

SENADO FEDERAL ............................................................................................................. 32

4.1. FUNO DO RBAC NA REDE SEM FIO DO SENADO FEDERAL .......................................... 32

4.2. BENEFCIOS DO RBAC ..................................................................................................... 33

4.3. CONSIDERAES SOBRE ESFORO E TAREFAS PARA IMPLEMENTAO DO RBAC .......... 34

4.3.1. Definio dos Papis (Role Engineering) ................................................................. 35

4.3.2. Interoperabilidade e Estrutura Legada................................................................... 35

4.4. CONSIDERAES SOBRE ARQUITETURA E COMPONENTES PARA IMPLEMENTAO DO

RBAC NA REDE SEM FIO DO SENADO FEDERAL ...................................................................... 36

ix
4.5. A QUESTO DA LOCALIZAO DO USURIO MVEL ........................................................ 42

4.5.1. Spatial RBAC ............................................................................................................. 43

4.5.2. Influncia da localizao do usurio no contexto do Senado Federal................... 43

4.6. CENRIOS PARA APLICAO DO RBAC ............................................................................. 44

4.6.1. Acesso a recursos mquinas servidoras, sistemas.............................................. 44

4.6.2. Gerencia de desempenho (performance) e disponibilidade da rede ..................... 45

4.6.3. Acesso pblico ou convidado .................................................................................... 45

5. CONCLUSO ........................................................................................................ 47

5.1. PERSPECTIVAS FUTURAS ................................................................................................... 48

REFERNCIAS BIBLIOGRFICAS ................................................................................. 50

ANEXO I TRABALHOS J REALIZADOS NA REA ............................................... 52

ANEXO II SOLUES COMERCIAIS DISPONVEIS ............................................... 54

ANEXO III ESPECIFICAO FUNCIONAL DO RBAC ............................................ 57

x
 NDICE DE TABELAS
Tabela Pgina

TABELA 2.1 EXEMPLO DE MATRIZ DE CONTROLE DE ACESSO ................................................... 9

TABELA 2.2 EXEMPLO DE LISTA DE CONTROLE DE ACESSO ..................................................... 10

TABELA 2.3 EXEMPLO DE CAPABILITIES ................................................................................. 11

TABELA 2.4 FUNES RBAC ADMINISTRATIVAS .................................................................. 25

TABELA 2.5 FUNES RBAC DE SUPORTE DO SISTEMA ........................................................ 25

TABELA 2.6 FUNES RBAC DE REVISO ............................................................................. 26

xi
 NDICE DE FIGURAS
Figura Pgina

FIGURA 2.1 - UBAC.................................................................................................................. 12

FIGURA 2.2 PBAC.................................................................................................................. 12

FIGURA 2.3 CDAC ................................................................................................................. 13

FIGURA 2.4 CBAC ................................................................................................................. 14

FIGURA 2.5 VBAC ................................................................................................................. 15

FIGURA 2.6 - DAC E MAC........................................................................................................ 16

FIGURA 2.7 MODELO DE REFERNCIA DO RBAC.................................................................... 18

FIGURA 2.8 CORE RBAC........................................................................................................ 18

FIGURA 2.9 HIERARCHAL RBAC............................................................................................ 20

FIGURA 2.10 HIERARQUIA DE PAPIS...................................................................................... 21

FIGURA 2.11 SEPARAO ESTTICA DE PAPIS (SSD)............................................................ 22

FIGURA 2.12 SEPARAO DINMICA DE PAPIS (SSD)........................................................... 23

FIGURA 2.13 MODELO RBAC CONSOLIDADO ........................................................................ 23

FIGURA 4.1 - MODELO DE REFERNCIA OSI X 802.11 ............................................................... 36

FIGURA 4.2 ABORDAGEM MODULAR PARA SOLUO DE SEGURANA .................................... 37

FIGURA 4.3 ARQUITETURA REDE SEM FIO/RBAC ................................................................. 39

xii
 NDICE DE ABREVIAES

ACL Access Control List

ANSI American National Standards Institute
AP Access Point
ATM Asynchronous Transfer Mode
CBAC Content Based Access Control
CDAC Content Dependent Access Control
CDMA Code Division Multiple Access
DAC Discretionary Access Control
DSD Dynamic Separation of Duty
GSM Global System for Mobile Communications
HTTP Hiper Text Transfer Protocol
HTTPS Hiper Text Transfer Protocol Secure
IDS Intrusion Detection System
IEEE Institute of Electrical and Electronics Engineers
INCITS International Committee for Information Tecnology Standards
IP Internet Protocol
IPSEC Internet Protocol Security
ISO International Organization for Standardization
JMX Java Management Extensions
LAN Local Area Network
LDAP Lightweight Directory Access Protocol
LLC Logical Link Control
MAC Mandatory Access Control
MAC Media Access Control
MAN Metropolitan Area Network
MANETS Mobile Ad Hoc Networks
Mbps Mega Bits por Segundo
NAT Network Address Translation
NBR Normas Brasileiras
NIST National Institute of Standards and Technology
PBAC Policy Based Access Control

xiii
PDA Personal Digital Assistant
QoS Quality of Service
RADIUS Remote Authentication Dial-in User Service
RBAC Role Based Access Control
RSBAC Rule Set Base Access Control
SSD Static Separation of Duty
SSO Single Sign On
TI Tecnologia da Informao
TKIP Temporal Key Integrity Protocol
UBAC User Based Access Control
VBAC View Based Access Control
VLAN Virtual Local Area Network
VoIP Voice Over IP
WAN Wide Area Network
WEP Wired Equivalent Privacy
WLAN Wireless Local Area Network
WPA Wi-Fi Protected Access
WPA2 Wi-Fi Protected Access 2
XML Extensible Markup Language

xiv
1. INTRODUO

O surgimento do computador moderno no incio da dcada de 1960 marcou o comeo

de uma era de grandes transformaes e desenvolvimento de tecnologias voltadas ao
processamento eletrnico de dados. Resguardadas as limitaes e realidade de cada poca,
ano a ano, o poder revelado pelos computadores e tecnologias semelhantes foi conquistando
espao na vida das pessoas e instituies. Atualmente, a sociedade como um todo bastante
dependente da tecnologia relacionada a computadores.

A Tecnologia da Informao (TI) entendida como a aplicao de vrios ramos da

tecnologia e atividades da rea de informtica no processamento de dados tem como
componente principal o uso do computador dentro de uma infra-estrutura que permita
integrar, compartilhar, disseminar e aumentar a produtividade de informao.

A utilizao isolada dos computadores evoluiu para a infra-estrutura das redes. Da

perspectiva do usurio final, as Redes de Computadores so sistemas nos quais as
informaes so armazenadas, processadas e por meio dos quais circulam. So compostos de
computadores (centrais e terminais utilizados pelos usurios), componentes ativos e passivos
de transmisso (cabos, antenas, satlites, roteadores, switches, etc.), servios de apoio
(servios de atribuio de endereos, servios de resoluo de nomes, servios autenticao,
etc.). s redes, vincula-se uma crescente variedade de aplicaes (sistemas de correio
eletrnico e-mail, navegadores e sistemas de exibio de informao, sistemas para
compartilhamento e transferncia de arquivos, sistemas de informao em geral, etc.),
destinadas queles que as utilizam para realizar suas tarefas e atingir seus objetivos pessoais e
profissionais.

Do ponto de vista tcnico, uma Rede de Computadores um sistema de comunicao

compartilhado que suporta comunicao digital entre os computadores interligados [1].
Dependendo do tamanho e abrangncia geogrfica, as redes podem ser classificadas como
Locais, ou LAN (Local Area Network) quando o conjunto se encontra dentro de uma mesma
localizao geral, por exemplo, no mesmo prdio; MAN (Metropolitan Area Network) dentro
de uma rea metropolitana; WAN (Wide Area Network) quando os computadores esto mais
dispersos, abrangendo uma rea ampla, podendo atingir um pas ou continente [2], e
consistindo, normalmente, de duas ou mais LANs. Alm do aspecto geogrfico, outras
caractersticas tcnicas so freqentemente utilizadas para distinguir e categorizar os tipos de

1
redes. A topologia da rede representa o arranjo geomtrico dos computadores que a compem,
sendo as mais comuns as de barramento, anel ou estrela. A arquitetura determina como a
comunicao ocorre entre os pontos (ns) da rede, podendo ser ponto-a-ponto (peer-to-peer)
ou cliente-servidor (client-server). Os protocolos de rede so conjuntos de regras e
especificaes que definem detalhadamente como os computadores devem trocar informao
entre si de maneira que possam se entender. O protocolo determina o mtodo de compresso
de dados a ser utilizado, o mtodo de verificao de erros, como os dispositivos emissor e
receptor indicam o trmino do envio da mensagem e a confirmao do recebimento,
respectivamente. O meio fsico que conecta os computadores e demais dispositivos da rede
abrange vrias opes, podendo ser, entre outras, par tranado, coaxial, fibra tica.
Normalmente, as redes utilizam cabos como meio fsico para transportar dados de um ponto a
outro, fixos, em um local definido onde est instalado o computador.

Nos ltimos anos, houve um rpido desenvolvimento de tecnologias de Redes Sem Fio
(Wireless Networks), que permitem distribuir e compartilhar informao, acessar sistemas e
outros recursos de uma rede mais ampla independente de um local fixo, sem uso de cabos
entre o dispositivo (geralmente um notebook, laptop ou PDA) e o ponto de acesso. Aqui o
termo ponto de acesso colocado de uma maneira geral, sem referir-se a um conceito
definido. No entanto, uma das tecnologias de rede sem fio citadas neste trabalho apresenta um
componente com esse mesmo nome ou simplesmente AP (Access Point), cuja funo
permitir a conexo do dispositivo mvel rede. O acesso a recursos de uma rede por
tecnologias sem fio tem se tornado cada vez mais popular e, exercido de maneira apropriada,
permite atingir um nvel de flexibilidade e convenincia com um custo relativamente baixo.
Existem vrias tecnologias de rede sem fio, tais como comunicao por satlite, que usa
microondas para estabelecer contato com outras estruturas; telefonia celular, amplamente
utilizada por usurios de operadoras que adotam padres como o GSM ou CDMA; sistemas
sem fio (Cordless Systems), usados dentro de casa, sala ou escritrio, em pequenas distncias
para comunicao entre telefones sem fio e suas bases de operao; redes locais sem fio ou
WLAN (Wireless Local Area Networks), usadas em organizaes de qualquer porte e
residncias, permitindo que computadores com placas de comunicao sem fio conversem
entre si ou acessem uma estrutura de rede maior. Essa ltima o foco deste trabalho,
considerando a sua aplicao como uma extenso da rede fixa, visando ampliar as
possibilidades de acesso. Alm do uso como extenso de rede, h outros tipos de utilizao,
que esto fora do escopo deste trabalho: conexo entre prdios; MANETS (Mobile Ad Hoc

2
Networks), onde os dispositivos estabelecem conexes uns com os outros sem qualquer infra-
estrutura preexistente.

Atualmente, as redes locais (com e/ou sem fio) esto presentes em qualquer empresa
ou instituio, governamental ou particular, inclusive nas de pequeno porte, permitindo
distribuir e compartilhar informao de maneira mais gil. A necessidade de meios mais geis
e eficientes para disseminar e trocar informao foi a principal razo do nascimento das redes
e ainda representa o motivo de seu constante desenvolvimento e adoo dentro do ambiente
institucional. As redes foram concebidas com essa finalidade precpua, e permitir maior
acesso informao por diversas pessoas simultaneamente requer controles de acesso
adequados ao uso que se faz dela em determinado momento. A surge a necessidade de
ateno com a Segurana da Informao, especialmente com as tecnologias de redes sem fio,
uma vez que pela sua prpria natureza comunicao por ondas de rdio pelo ar, que
podem ser capturadas por qualquer um dentro do raio de alcance no atingem o mesmo
nvel de segurana fsica de uma rede fixa com cabos. A introduo de outras formas de
acesso, como as redes sem fio, eleva o uso da rede e aumenta a capacidade de obteno da
informao, tornando o aspecto da segurana cada vez mais importante dentro da estratgia de
TI da instituio. To importante quanto a segurana em si so os mtodos disponveis para
implement-la e o impacto que eles tm na estrutura de TI como um todo, buscando sempre
uma maneira mais adequada de gerenci-la.

Os mecanismos disponveis na Segurana da Informao permitem proteger

informaes e recursos de uma rede contra diversos tipos de ameaa (acesso no autorizado,
roubo ou alterao de informao), e so, tambm, instrumentos para tentar garantir o uso
controlado de tais recursos no sentido de adequ-los necessidade e funo especficas de
cada usurio dentro da instituio. Os princpios bsicos de segurana que se busca garantir
so a autenticidade, a confidencialidade e a integridade. Autenticidade a propriedade de
verificar a identidade da pessoa ou mquina que deseja efetuar qualquer tipo de acesso rede.
Confidencialidade diz respeito garantia de que a informao s ser vista e manipulada por
pessoas ou mquinas autorizadas. Integridade a capacidade de garantir que a informao no
seja modificada, alterando (corrompendo) ou no o seu significado original, por quem no
tenha a devida autorizao.

Vrias abordagens tm sido utilizadas para a manuteno desses princpios. Uma delas
adotar algum mtodo de controle de acesso. Toda instituio possui funcionrios que

3
executam atividades diferentes e exercem funes distintas, uns com mais poder e privilgios
que outros. Naturalmente, controlar permisses de acesso na utilizao dos recursos
computacionais por meio da rede torna-se uma atividade no apenas desejvel, mas essencial,
especialmente quando a infra-estrutura de acesso mais sensvel a problemas relacionados
segurana, como o caso das redes sem fio. O controle de acesso por si s no significa uma
soluo completa de segurana, mas representa um componente importante para atingi-la.
Uma soluo completa de segurana envolve, tambm, planejamento (definio de polticas
de segurana), processos e servios especficos, tais como comunicaes seguras,
autenticao, auditoria e administrao de segurana.

Diversos modelos de controle de acesso tm sido desenvolvidos e incorporados aos

sistemas e estruturas de comunicao. Um deles o RBAC (Role Based Access Control) ou
Controle de Acesso Baseado em Papis (ou Perfis). O RBAC um mtodo de acesso no
discricionrio, ou seja, os usurios tm de se submeter s polticas de segurana estabelecidas
na organizao [3]. Nesse sentido, o RBAC mostra grande habilidade em implementar as
polticas de forma eficiente e flexvel, tornando menos oneroso o trabalho de gerenciamento
dos recursos da rede.

O modelo RBAC baseia o controle de acesso na funo ou papel que o usurio exerce
dentro da organizao [3]. Essas funes definem um elenco de atividades para determinados
usurios e podem ser vistas como cargos ou posies que o indivduo ocupa na organizao,
representando a autoridade requerida para efetuar tarefas correlatas. Assim, no RBAC as
permisses aos recursos da rede no so atribudas diretamente ao usurio como acontece
em modelos comuns de controle de acesso mas sim aos papis, e estes, por sua vez, so
atribudos aos usurios. esta atribuio indireta que permite que o RBAC seja flexvel, pois
se podem atribuir vrios papis a cada usurio, e vrias permisses a cada papel. A eficincia
e facilidade de gerenciamento tambm so devidas a este mesmo fator, visto que uma vez
definidos os papis e suas permisses de acesso, basta-se associar os usurios aos papis para
definirem-se suas permisses de acesso. Do mesmo modo, uma alterao de permisso para
determinado papel permite alterar as permisses dos diversos usurios atribudos a ele de
forma bem mais fcil do que alterar a permisso usurio por usurio, como acontece em
outros modelos de controle.

Todos esses aspectos tcnicos e a evoluo da tecnologia incorporada em seus

componentes mostram que as redes so sistemas complexos que requerem gerenciamento e

4
controle. Mais do que isso, tornando-se parte da estrutura bsica da instituio, algumas
funes gerenciais exercidas so comuns a outras partes da administrao, porm alguns
requisitos so especficos da TI, e, em funo da complexidade e abrangncia, no podem ser
gerenciados exclusivamente pelo esforo humano, necessitando, assim, do uso de ferramentas
automatizadas de gerncia [4]. Dentro das principais reas de gerenciamento de rede
propostas pela International Organization for Standardization (ISO) [5] Gerenciamento de
Falhas, Gerenciamento de Contabilidade, Gerenciamento de Configurao e de Nome,
Gerenciamento de Desempenho e Gerenciamento de Segurana , essa ltima a possui
relao mais direta com o contexto deste trabalho, pois est envolvida com o monitoramento e
o controle de acesso s redes e s informaes.

O Senado Federal rgo que compe o Congresso Nacional, ao lado da Cmara dos
Deputados por meio da sua Secretaria Especial de Informtica, o PRODASEN, tem
procurado constantemente aperfeioar a sua infra-estrutura computacional e de comunicao
de dados, desde a implantao da sua rede local de computadores. Hoje, a rede do Senado
possui, aproximadamente, 4000 pontos ativos, distribudos por diversos prdios (incluindo as
residncias dos senadores na SQS 309), utilizando tecnologia de switches ethernet (fast e
gigabit) e ATM, alm de acesso remoto via VPN.

A busca de novas solues e tecnologias de hardware e software visa atender as

necessidades dos usurios, suportando a realidade e evoluo das aplicaes do mundo
legislativo, que possui algumas caractersticas peculiares. Dessa forma, o PRODASEN vem
implementando um projeto de ampliao da rede do Senado por meio de redes sem fio, onde o
plenrio da Casa (local de difcil acesso para realizao de obras para passagem de cabos) j
adota essa tecnologia, permitindo que os senadores acompanhem e tenham acesso s
informaes da ordem do dia utilizando notebooks do tipo Tablet PC.

Faz parte do projeto ampliar o acesso rede com tecnologia sem fio em outras reas
do Senado, como, por exemplo, grfica, ala das comisses, gabinetes dos senadores, entre
outras, suportando no somente aplicaes tradicionais de sistemas de informao e acesso a
banco de dados, mas tambm aquelas de udio e vdeo, que j so uma realidade em funo
da presena da Rdio e TV Senado.

5
1.1. OBJETIVO

Considerando esse cenrio, o objetivo desse trabalho analisar a aplicao do modelo

RBAC no controle de acesso da rede sem fio do Senado Federal, propondo uma arquitetura de
componentes de hardware e software necessrios sua implantao. Para isso, necessrio
um estudo aprofundado do modelo RBAC; uma anlise das caractersticas da rede do Senado
Federal, identificando suas peculiaridades, demandas de usurios, natureza e contexto das
aplicaes dentro da estrutura hierrquica e das atribuies funcionais do rgo; um estudo de
mecanismos de segurana (mtodos de acesso, autenticao, etc); um estudo de arquiteturas e
tcnicas de implementao de redes; um estudo das implicaes das caractersticas nicas das
redes sem fio no contexto do controle de acesso; um estudo de normas, padres e prticas de
gesto de segurana da informao.

1.2. ORGANIZAO DO TRABALHO

Dessa forma, este trabalho est dividido em cinco captulos. Este captulo introdutrio
apresentou as razes que nos motivaram a desenvolver o este trabalho, e o contexto no qual
ele est inserido.

O captulo 2 descreve as caractersticas e funcionalidade do modelo RBAC.

O captulo 3 mostra as caractersticas da rede do Senado Federal, identificando

demandas dos usurios, relacionando-as com o contexto do trabalho.

O captulo 4 identifica os cenrios onde a funcionalidade do modelo RBAC se aplica,

apresentando uma arquitetura para sua adoo.

Finalmente, o ltimo captulo apresenta concluses e possibilidades de continuao do

trabalho.

6
2. ROLE-BASED ACCESS CONTROL

O conceito do RBAC existe a cerca de 30 anos, porm somente tornou-se um modelo

maduro h aproximadamente 15 anos. Nesse perodo, o crescimento das redes de
computadores fez com que o nvel de intercmbio de informaes tornasse evidente a
necessidade de mecanismos segurana, dentre estes o controle de acesso. Nesse contexto, o
RBAC surgiu como uma alternativa vivel ao DAC e ao MAC.

Uma instituio que fez grandes contribuies para o desenvolvimento do RBAC foi o
NIST, National Institute of Standards and Technology. Em 1992, o NIST publicou seu
primeiro modelo do RBAC. Nos anos de 1997 e 1998, publicou outros artigos que
expandiram seu modelo original com a incorporao de diferentes tipos de relacionamentos
entre papis. Tambm em 1997, publicou documentos sobre ferramentas especficas para
implementao de RBAC na web. Em 1995 demonstrou o uso do RBAC em sistemas da rea
de sade, e, em 1999, em Intranets [6].

Mais recentemente, em 2003, desenvolveu o draft do padro para RBAC, proposto

pelo ANSI, que foi aprovado em 2004 como ANSI/INCITS 359-2004. Em janeiro deste ano,
2006, desenvolveu a verso 0.1 do draft do padro para implementao do RBAC.

O modelo RBAC proposto pelo NIST tem como razes os grupos do Unix, o
agrupamento de privilgios em sistema gerenciadores de banco de dados e o conceito de
separao de tarefas [6]. O sistema operacional Unix possui o papel de administrador, com
algumas permisses de acesso especficas para o desempenho desse papel. O RBAC herdou
esse conceito.

Alguns papis podem refletir competncias como digitador ou programador; outros

refletem responsabilidades ou autoridade do usurio em relao aos recursos, tais como:
gerente de projetos ou supervisor ou revisor. Ter competncia no implica em ter a
responsabilidade. Assim um programador pode compor a equipe de vrios projetos, mas ser
gerente de apenas um, tendo neste, portanto, as responsabilidades associadas gerncia. O
modelo RBAC deve refletir todas estas acepes da palavra papel.

No caso do RBAC, o termo papel define no s os usurios que devem ter as

permisses, mas tambm os recursos que podem ser acessados. Assim, ao se associar um
usurio a um papel, concede-se a este todas as permisses de acesso a recursos associados ao
7
papel. Inversamente, ao se associar a um papel permisses de acesso a um recurso, concede-se
permisso de acesso a todos os usurios associados ao papel.

A escolha do RBAC pelos administradores baseia-se principalmente na facilidade

deste mapear as funes existentes na empresa. Desta forma, o controle de acesso feito
alterando-se o papel do usurio conforme sua funo na empresa, e.g. programador, gerente
de projeto, etc. Da mesma forma, novos recursos podem ser atribudos a vrios usurios
concedendo-se permisso no recurso para um papel.

Outra caracterstica importante do RBAC a obedincia aos princpios de segurana

de atribuio do menor privilgio e a de separao de tarefas.

2.1. MTODOS DE CONTROLE DE ACESSO

Este captulo inicia resumindo os diversos tipos de controle de acesso, destacando as

caractersticas que os diferenciam conforme descrito por Camelot [7]. Em seguida, cita alguns
termos e definies utilizados para descrever o RBAC, extradas do draft do documento
padronizador ANSI/INCITS 359 [8]. Posteriormente, descreve o modelo de referncia do
RBAC proposto por Ferraiolo et al.[9] e a especificao funcional.

A segurana de redes tem como um de seus objetivos principais efetuar o controle de

acesso de usurios ou computadores a objetos da rede. Para que esse objetivo seja
contemplado de maneira mais ampla, diversas ferramentas podem ser utilizadas de acordo
com o ambiente em questo. Firewalls, Intrusion Detection System (IDS) e criptografia so
algumas das ferramentas mais usadas. Em muitos casos, no entanto, so usadas apenas as
ferramentas fornecidas pelo sistema operacional.

Os mtodos de controle de acesso mais utilizados baseavam-se em Matriz de Controle

de Acesso e suas variaes: Lista de Controle de Acesso (ACL, do ingls Access Control
List), e Capabilities. Mtodos mais recentes incluem: User Based Access Control, Policy
Based Access Control, Context Based Access Control, Mandatory Access Control ou
Discretionary Access Control.

Qualquer que seja o mtodo utilizado, o grande desafio do administrador do sistema

conceder ao usurio exatamente aqueles direitos de acesso que ele necessita para cumprir seus

8
deveres na organizao. Nem um direito a mais ou a menos deve ser fornecido. Isto o
princpio do mnimo privilgio [7].

Certamente, o grau de dificuldade que o administrador ir enfrentar para chegar ao

mnimo privilgio est diretamente relacionado com o mtodo de controle de acesso utilizado
e o sistema a ser administrado.

Um conceito utilizado para indicar a eficincia do mtodo de controle de acesso a

granularidade. Diz-se que um mtodo de controle de acesso tem granularidade alta quando ele
consegue atribuir direitos de acesso para cada usurio em cada objeto da rede. A
granularidade dita como baixa quando os direitos de acesso so dados para conjuntos de
usurios em conjuntos de objetos. Quanto mais alta for a granularidade do mtodo de acesso,
mais prximo do menor privilgio ser possvel alcanar com esse mtodo [7].

As subsees a seguir descrevem os vrios mtodos, destacando seus pontos fortes e

aplicabilidade.

2.1.1. Matriz de Controle de Acesso

A Matriz de Controle de Acesso o modelo mais simples de controle de acesso. Neste

modelo utilizada uma matriz para definir as permisses que os sujeitos (usurios ou
processos) tero ao acessar os objetos (arquivos ou outros recursos da rede).

A Tabela 2.1 exemplifica o mtodo em um sistema operacional hipottico. O processo

1 pode ler os arquivos 1 e 2 e escrever no arquivo 1. Adicionalmente, o processo 1 pode se
comunicar com o processo 2 enviando mensagens. O processo 2, por sua vez, pode ler os
arquivo 2, escrever no arquivo 1, e receber mensagens do processo 1.

Tabela 2.1 Exemplo de matriz de controle de acesso

arquivo 1 arquivo 2 processo 1 processo 2
processo 1 ler, escrever ler ler, escrever, escrever
executar
processo 2 escrever ler ler ler, escrever,
executar

9
 O significado dessas permisses pode no ser muito intuitivo. Ler e escrever arquivos
algo comum, porm ler um processo" pode ter um significado especfico em cada sistema
operacional. Neste exemplo, a permisso de ler um processo concede ao processo 2 o
recebimento de mensagens do processo 1, mas poderia tambm significar comunicao
atravs do uso de uma rea compartilhada de memria.

A Matriz de Controle de Acesso pode parecer a forma ideal para controlar acessos,
contudo, sua implementao de forma direta em um sistema com grande quantidade de
sujeitos e objetos pode gerar uma matriz gigantesca que ocuparia grande rea de
armazenamento e seria de difcil gerenciamento. Da o surgimento de simplificaes tais
como ACL e Capabilities.

2.1.2. Lista de Controle de Acesso (ACL)

A Lista de Controle de Acesso a variao mais utilizada da Matriz de Controle de

Acesso. Grande parte dos sistemas operacionais comerciais utiliza este modelo. O que o
diferencia do modelo original a forma de armazenar as permisses. Esse modelo armazena
as permisses junto aos objetos por meio de pares formados pelo sujeito e suas permisses de
acesso. O exemplo da Tabela 2.1 est reescrito como ACL na Tabela 2.2.

Tabela 2.2 Exemplo de lista de controle de acesso

objeto ACL
arquivo 1 [processo 1, (ler, escrever)], [processo 2, (escrever)]
arquivo 2 [processo 1, (ler)], [processo 2, (ler)]
processo 1 [processo 1, (ler, escrever, executar)], [processo 2, (ler)]
processo 2 [processo 1, (escrever)], [processo 2, (ler, escrever, executar)]

Semelhantemente Matriz de Controle de Acesso, ACL pode se tornar muito grande

em sistemas com grande quantidade sujeitos e objetos. Para viabilizar o uso de ACL, o Unix,
por exemplo, utiliza grupos como sujeitos e no usurios. Esta medida reduz drasticamente a
ACL, em contrapartida perda de granularidade.

2.1.3. Capabilities

Capabilities uma variao da Matriz de Controle de Acesso em que se armazenam as

permisses junto aos sujeitos por meio de pares formados pelo objeto e permisses de acesso

10
que o sujeito possui naquele objeto. O exemplo da Tabela 2.1 est reescrito atravs de
Capabilities na Tabela 2.3.

Tabela 2.3 Exemplo de capabilities

sujeito Capabilities
processo 1 [arquivo 1, (ler, escrever)], [arquivo 2, (ler)],
[processo 1, (ler, escrever, executar)], [processo 2, (escrever)]
processo 2 [arquivo 1, (escrever)], [arquivo 2, (ler)],
[processo 1, (ler)], [processo 2, (ler, escrever, executar)]

Como com Capabilities as permisses esto armazenadas com o sujeito, este deve
apresent-las quando desejar acessar um objeto. Um problema com Capabilities a
possibilidade do sujeito forjar sua lista. Para evitar tal falha, o sistema operacional deve ter
uma forma de reconhecer a autenticidade da lista de Capabilities.

2.1.4. User Based Access Control (UBAC)

No UBAC as permisses de acesso so dadas a cada usurio individualmente.

Potencialmente, esse mtodo permite que a granularidade seja a mais alta possvel. Contudo,
na prtica como esse mtodo exige que o administrador configure as permisses para cada
usurio, dependendo do tamanho da rede a ser administrada, esse potencial dificilmente
efetivado.

A necessidade de ajustar as permisses de acesso para cada usurio, por si j poderia

ser considerado pouco razovel, mas quando acrescentado o fato de que os usurios tm
necessidades que variam ao longo do tempo o esforo para ajuste atinge um custo proibitivo.

O que acontece em sistemas reais que utilizam esse modelo que as permisses de
acesso so dadas em conjuntos de usurios, no se alcanando assim grande granularidade.

A figura 2.1 representa o UBAC graficamente.

11
 Administrador

Permisso Usurio

Figura 2.1 - UBAC

2.1.5. Policy Based Access Control (PBAC)

No PBAC a poltica de acesso definida por um conjunto de regras que determinam

os recursos ao qual o usurio ter permisso de acesso. Por esta caracterstica, o PBAC
tambm conhecido como Rule Set Base Access Control (RSBAC), isto , controle de acesso
baseado em um conjunto de regras.

A implementao do PBAC muitas vezes feita por meio de ACL. Contudo, os

melhores resultados em implementao do controle de acesso por PBAC so obtidos atravs
de linguagem de especificao apropriada para descrever as polticas.

A figura 2.2 representa o PBAC graficamente.

Poltica

Permisso Usurio

Figura 2.2 PBAC

12
2.1.6. Content Dependent Access Control (CDAC)

CDAC um mtodo para controlar o acesso de usurios a recursos baseado no

contedo do recurso. usado, primariamente, para proteger bases de dados contendo dados
potencialmente sensveis.

Um exemplo do uso de CDAC seria de um sistema de armazenamento de pronturio

em um hospital. No caso de um paciente diagnosticado com AIDS, o acesso ao pronturio
seria restrito ao mdico responsvel.

Para determinar a permisso de acesso, no caso do CDAC, necessrio analisar o

contedo, acarretando em overhead (sobrecarga) quando o recurso acessado.

A figura 2.3 representa o CDAC graficamente.

Contedo

Permisso Usurio

Figura 2.3 CDAC

2.1.7. Context Based Access Control (CBAC)

Apesar do nome parecido com o CDAC, o CBAC trata de outra caracterstica

totalmente distinta. Nesse tipo de controle de acesso o que define a permisso de acesso ao
recurso o contexto em que o acesso se d, isto , os fatos que ocorreram previamente.

Um exemplo desse tipo de controle de acesso no dia-a-dia ocorre em mquinas de

saque eletrnicas. Nessas mquinas observamos que ainda que o usurio tenha a conta e a
senha, se o montante sacado no dia tiver alcanado o limite dirio, no ter permisso para
sacar mais.

13
 Este tipo de controle de acesso tambm ocorre em alguns firewalls denominados
statefull. Nesse tipo de firewall, os pacotes alm de serem analisados quanto origem e
destino, so verificados se pertencem a uma conexo previamente permitida.

A figura 2.4 representa o CBAC graficamente.

Contexto

Permisso Usurio

Figura 2.4 CBAC

2.1.8. View Based Access Control (VBAC)

Este tipo de controle de acesso utilizado basicamente em sistemas de banco de dados

onde vises (views) das tabelas restringem o acesso s informaes nelas contidas.

Como exemplo, pode-se considerar uma tabela contendo informaes sobre pacientes
de um hospital. Os mdicos teriam acesso a todas as informaes relativas ao diagnstico e
tratamento do paciente. As enfermeiras visualizariam apenas as medicaes a serem
ministradas ao paciente. J o departamento financeiro teria viso apenas dos procedimentos e
materiais despendidos no tratamento para efeito de clculo do valor devido.

O VBAC permite que se trate o controle de acesso com alta granularidade, contudo
preciso grande conhecimento da estrutura do banco de dados e das aplicaes e usurios que o
acessam.

A figura 2.5 representa o VBAC graficamente.

14
 Tabela
View A
Usurio A

View B
Usurio B

View C
Usurio C

Figura 2.5 VBAC

2.1.9. Controles de Acesso Discricionrio e Mandatrio

A filosofia do Controle de Acesso Discricionrio (DAC Discritionary Access

Control) de permitir que os usurios decidam sobre que permisses de acesso devem ser
atribudas. Desse modo, mesmo que a poltica de segurana defina as permisses de acesso,
depende dos usurios, que possuam poderes de atribuir permisses, para que a implementao
obedea poltica. Assim, esse modelo bastante sensvel ao nvel de comprometimento e de
conhecimento dos usurios. Esse tipo de acesso comum em sistemas de arquivo, onde os
usurios definem as permisses de acesso de seus arquivos e diretrios.

No Controle de Acesso Mandatrio (MAC Mandatory Access Control) as regras so

implementadas seguindo as polticas e so impostas aos usurios. Dessa maneira, os usurios
no tm influncia sobre as permisses de acesso. Esse modelo tambm conhecido como
modelo militar, isto porque dadas as exigncias de segurana do ambiente militar, o controle
de acesso deve ser imposto de forma a minimizar as falhas de segurana. Um exemplo
comum o de servidores proxy web com controle de acesso a pginas restritas. Nesses
servidores, uma vez estabelecidas as polticas de acesso, os usurios web tero de segu-las,
no tendo possibilidade de decidir sobre isto.

A figura 2.6 representa os controles DAC e MAC graficamente.

15
 Discricionrio

Permisso Usurio

Mandatrio

Permisso Usurio

Figura 2.6 - DAC e MAC

2.2. TERMOS E DEFINIES DO RBAC

Os termos e definies abaixo e seus respectivos significados so utilizados na

proposta de padro do RBAC [9].

Component (Componente) refere-se a um dos blocos principais do RBAC: Core

RBAC, Hierarchal RBAC, Static Separation of Duty (SSD) Relations e Dynamic Separation
of Duty (DSD) Relations.

Object (Objeto) qualquer recurso do sistema sujeito a controle de acesso, tais como:
arquivo, impressora, terminal, registro de base de dados, etc.

Operations (Operaes) uma imagem executvel de programa que quando

invocado executa alguma funo para o usurio.

Permissions (Permisses) uma aprovao para executar uma operao em um ou

mais objetos protegidos pelo RBAC.

16
 Role (Papel) refere-se a um cargo dentro do contexto de uma organizao com
algum significado associado relativo autoridade e responsabilidade conferidas ao usurio
designado role.

User (Usurio) definido como sendo um ser humano.

2.3. MODELO DE REFERNCIA RBAC

Devido diversidade de implementaes do RBAC, o National Institute of Standards

and Technology (NIST) dos Estados Unidos escreveu uma proposta de padro para o RBAC.
Nessa proposta constam o modelo de referncia e a especificao funcional utilizados no
RBAC.

2.3.1. Components do RBAC

O modelo de referncia do RBAC definido em funo dos componentes principais

do RBAC, tambm conhecidos como modelos de referncia. A relao entre os modelos de
referncia ilustrada na Figura 2.7.

O Core RBAC, ou RBAC0, define uma coleo de componentes e caractersticas

bsicas do RBAC e por ser o requisito mnimo para toda implementao de RBAC fica
abaixo.

O RBAC1 representa o Hierarchal RBAC que consiste no RBAC0 adicionando-se as

hierarquias de papis.

O RBAC2 representa o Constrained RBAC que consiste no RBAC0 adicionando-se as

restries, SSD Relations e DSD Relations.

O modelo RBAC3 o modelo consolidado e inclui os modelos RBAC1 e RBAC2 e,

por transitividade, o modelo RBAC0.

17
 RBAC3

RBAC1 RBAC2

RBAC0

Figura 2.7 Modelo de referncia do RBAC

Cada componente do modelo definido pelos seguintes sub-componentes:

Uma coleo de conjuntos de elementos bsicos;
Uma coleo de relaes RBAC envolvendo os conjuntos de elementos; e
Uma coleo de funes de mapeamento que mapeia instncias de um conjunto de
elementos em instncias de outro conjunto de elementos.

2.3.2. Core RBAC

composto pelas entidades: users (usurios), roles (papis), objects (objetos),

operations (operaes) e permissions (permisses); e pelas relaes dadas pelas sessions
(sesses). Este modelo representado pela Figura 2.8.

User Permission
Assignment Assignmen OPER- OB-
USERS ROLES ATIONS JECTS

PERMISSIONS

user_session session_roles
SES-
SIONS

Figura 2.8 Core RBAC

O termo usurios, apesar de ser definido como um ser humano, pode ser estendido de
modo a incluir mquinas, redes, ou agentes inteligentes autnomos, tais como um rob.

18
 As permisses conferem a seus possuidores a habilidade de executar alguma ao no
sistema. Nesse sentido, podemos dizer tratar-se de permisses positivas em contraste s
chamadas permisses negativas, as quais probem o usurio de executar determinadas tarefas.
O modelo assume que as permisses negativas so, na verdade, constraints (restries).

Na literatura comum encontrar termos como autorizao, direito de acesso ou

privilgio para denotar permisses. Isto acontece porque a denominao utilizada para as
permisses reflete o tipo de sistema a que pertencem e est intimamente ligada aos tipos de
operaes possveis nesse sistema. Assim, usurios possuem autorizao para efetuar logon
em sistemas. Direitos de acesso so atribudos a usurios para diretrios, arquivos,
impressoras e outros recursos de rede. Sistemas de banco de dados relacional concedem
privilgios de select, update, delete e insert nas suas tabelas e demais objetos.

O conceito central do RBAC o das relaes de papel. Na Figura 2.8 observamos que
os usurios se relacionam com os papis atravs da user assignment (atribuio de usurio),
que por ser do tipo muitos-para-muitos indica que um usurio pode ter vrios papis
atribudos a ele, e, inversamente, um papel pode ser atribudo a vrios usurios.
Analogamente, a permission assignment (atribuio de permisso), que tambm por ser do
tipo muitos-para-muitos, indica que um papel pode ter vrias permisses atribudas a ele, e,
inversamente, uma permisso pode ser atribuda a vrios papis. Essa maneira de se atribuir
usurios e permisses a papis responsvel pela grande flexibilidade e granularidade das
atribuies de permisso, o que no ocorre na atribuio direta de permisses a usurio, sem o
uso de papis.

O conceito de sessions (sesses) est relacionado com a possibilidade dos usurios

ativarem e desativarem os papis a que esto atribudos em determinado momento. Assim, um
usurio estabelece uma sesso quando ativa um subconjunto de papis aos quais pertence.
Dessa forma, as user_sessions (sesses de usurio) so definidas como uma relao um-para-
muitos em que um usurio pode estabelecer vrias sesses, mas cada sesso s pode ser
estabelecida por um usurio. Por outro lado, as session_roles (sesses de papis) so definidas
como uma relao muitos-para-muitos em que as sesses podem ativar vrios papis e cada
papel pode ser ativado por vrias sesses. O uso de sesses permite a implementao do
princpio do menor privilgio, pois o usurio pode ativar a cada momento apenas os papis
que necessita para efetuar as operaes daquele momento.

19
2.3.3. Hierarchal RBAC

O modelo RBAC1 criado introduzindo-se o conceito de hierarquia de papis. Este

modelo representado pela Figura 2.9.

Role
Hierarchy

User Permission
Assignment Assignmen OPER- OB-
USERS ROLES ATIONS JECTS

PERMISSIONS

user_sessions session_roles
SES-
SIONS

Figura 2.9 Hierarchal RBAC

As organizaes normalmente possuem uma estrutura hierrquica que determina uma

cadeia de comando. Dessa maneira, para refletir essa estrutura, o modelo RBAC1
normalmente implementado nos sistemas baseados em papis, permitindo que a poltica de
segurana seja descrita de maneira extremamente natural.

No RBAC as hierarquias so representadas posicionando-se os papis com mais

permisses acima e os com menos permisses abaixo. Na Figura 2.10, por exemplo,
observamos a hierarquia do Analista Snior, Analista Pleno e Analista Jnior. Nesta
representao temos que o Analista Pleno herda as permisses do Analista Jnior, e o Analista
Snior herda as permisses do Analista Pleno, e, conseqentemente, as do Analista Jnior.
Alm das permisses herdadas, o Analista Pleno e Analista Snior podem possuir permisses
especficas atribudas diretamente a eles. Essa forma de herdar as permisses permite que a
hierarquia dos papis utilize atribuies de permisses diferenciais, isto , basta atribuir ao
Analista Pleno aquelas permisses que ele precisa e que no esto atribudas ao Analista
Jnior. Assim, diz-se que a atribuio de permisses feita de forma bottom-up. A atribuio

20
de usurios feita de maneira top-down, isto , os usurios aos quais atribudo o papel de
Analista Pleno tambm atribudo o papel de Analista Jnior.

Analista Snior

Analista Pleno

Analista Jnior

Figura 2.10 Hierarquia de papis

O padro RBAC permite dois tipos de hierarquia: Hierarquia de Papis Geral e

Hierarquia de Papis Limitada. A Hierarquia de Papis Geral suporta herana mltipla, o que
permite que um papel herde de mais de um papel e tenha mais de um papel como herdeiro. A
Hierarquia de Papis Limitada no suporta herana mltipla. Nesse caso, um papel pode ter
mais de um papel como herdeiro, mas deve herdar apenas um papel.

2.3.4. Constrained RBAC

O modelo RBAC2 implementa, por meio de restries, o conceito de Separao de

Tarefas. A Separao de Tarefas um conceito utilizado nas organizaes para dificultar a
possibilidade de fraudes. Por este conceito, papis como o de requisitante de gasto e de
autorizador de gasto no devem ser atribudos ao mesmo usurio. Isto para impedir que uma
mesma pessoa possa requisitar um gasto e autoriz-lo logo em seguida. Com esse modelo,
para que ocorra uma fraude na organizao preciso que haja conluio entre membros dos dois
papis para viabiliz-la. Isto faz com que aumente o nvel de segurana na empresa.

O exemplo citado acima classificado como sendo um caso de papis mutuamente

exclusivos. Nesse caso, a Separao de Tarefas foi implementada na atribuio de usurios,
isto , um usurio no pode ter os dois papis atribudos a ele. Outra possibilidade seria a de
implementar por meio da atribuio de permisses, isto , as permisses para requisitar gasto
e autorizar gasto no poderiam ser atribudas ao mesmo papel, o que evitaria que algum papel
se tornasse perigosamente poderoso.

21
 H, tambm, Separao de Tarefas por Cardinalidade. Nesse caso, a restrio para
atribuio de um papel est na quantidade, geralmente mxima, de usurios que pode ser
atribudo a um papel. Um exemplo comum em empresas seria o do papel de Diretor
Financeiro, que seria limitado a no mximo um usurio.

Outra restrio possvel a de papis pr-requisito. Nessa restrio, uma atribuio de

usurio ou de papel s permitida se o usurio ou papel j tiver outra permisso especfica
atribuda. O exemplo mais conhecido desta restrio a de direitos de acesso em sistemas de
arquivos onde para atribuir a permisso escrita preciso ter a permisso de leitura atribuda.

A principal classificao para as formas de separao de tarefas possui dois tipos:

Separao Esttica de Tarefas e Separao Dinmica de Tarefas.

A Separao Esttica de Tarefas, em ingls Static Separation of Duty (SSD), segundo

o padro do NIST, feita implementando-se restries na atribuio de usurios a papis.
Assim, um usurio no pode ser atribudo a papis considerados mutuamente exclusivos. O
termo esttico nesta implementao deve-se ao fato de que a restrio manter-se esttica ao
longo do tempo. O modelo de RBAC com SSD ilustrado na Figura 2.11.

SSD

User Permission
Assignment Assignment OPER- OB-
USERS ROLES ATIONS JECTS

PERMISSIONS

user_sessions session_roles
SES-
SIONS

Figura 2.11 Separao esttica de papis (SSD)

A Separao Dinmica de Tarefas, em ingls Dynamic Separation of Duty (DSD),

segundo o padro do NIST, feita implementando-se restries nos papis que so ativados

22
em uma sesso de usurio. Assim, uma sesso no pode ativar papis considerados
mutuamente exclusivos ao mesmo tempo. Isto faz com que usurios possam ter diferentes
nveis de permisso em diferentes momentos. O modelo de RBAC com DSD ilustrado na
Figura 2.12.

User Permission
Assignment Assignmen OPER- OB-
USERS ROLES ATIONS JECTS

PERMISSIONS

user_sessions session_roles
SES-
SIONS
DSD

Figura 2.12 Separao dinmica de papis (SSD)

2.3.5. Modelo RBAC Consolidado

O modelo consolidado obtido combinando-se os modelos RBAC1 e RBAC2,

implementando-se tanto hierarquia de papis quanto restries. Este modelo representado
pela Figura 2.13.

Role
SSD Hierarchy

User Permission
Assignment Assignmen OPER- OB-
USERS ROLES ATIONS JECTS

PERMISSIONS

user_sessions session_roles
SES-
SIONS
DSD

Figura 2.13 Modelo RBAC Consolidado

23
 Essa combinao, no entanto, no to simples e vrias situaes podem decorrer
dela. A implementao de restries em hierarquia pode se dar de forma simples como, por
exemplo, restringindo o nmero de nveis que uma hierarquia de papis pode ter. Nesse caso,
a hierarquia de Analistas poderia ser restringida a apenas dois nveis: Analista Jnior e
Analista Snior.

Outra restrio possvel seria a de dois papis no poderem herdar de um mesmo

papel, no caso de herana simples. No caso de herana mltipla pode-se especificar uma
restrio de que dois ou mais papis no tenham herdeiros em comum.

Uma situao mais complexa pode ocorrer no caso de dois papis mutuamente
exclusivos possurem um herdeiro em comum. Essa situao pode ser aceitvel em algumas
implementaes e em outras no. O modelo contempla ambas as possibilidades.

Outra situao diz respeito cardinalidade. No caso de uma restrio em que um

usurio pode ter apenas um papel, a atribuio de um papel que descenda de outro pode violar
a restrio, pois o usurio seria membro tambm do papel ascendente.

2.4. ESPECIFICAO FUNCIONAL DO RBAC

A especificao funcional do RBAC descreve a semntica das vrias funes que so

necessrias para a criao e manuteno dos componentes do modelo do RBAC [9]. A
especificao completa descrita no Apndice A do documento de Ferraiolo [9] que se
encontra transcrito originalmente na ntegra no Anexo III.

As funes so agrupadas em trs categorias: Funes Administrativas, Funes de

Suporte do Sistema e Funes de Reviso.

2.4.1. Funes Administrativas

As Funes Administrativas so responsveis pela criao e manuteno de conjuntos

de elementos e relaes para construo dos vrios modelos do RBAC. A Tabela 2.4
discrimina estas funes para componentes do modelo. A funo marcada com * (asterisco)
na tabela redefinida no componente.

24
Tabela 2.4 Funes RBAC Administrativas
Core RBAC Hierarchal RBAC Static Separation of Dynamic Separation of
Duty (SSD) Relations Duty (DSD) Relations

AddUser Core RBAC Core RBAC Core RBAC

DeleteUser + + +
AddRole AddInheritance AssignUser* CreateDsdSet
DeleteRole DeleteInheritance CreateSsdSet DeleteDsdSet
AssignUser AddAscendant DeleteSsdSet AddDsdRoleMember
DeassignUser AddDescendant AddSsdRoleMember DeleteDsdRoleMember
GrantPermission DeleteSsdRoleMember SetDsdCardinality
RevokePermission SetSsdCardinality

2.4.2. Funes de Suporte do Sistema

As Funes de Suporte do Sistema so necessrias para o gerenciamento de sesses e

decises de controle de acesso durante a interao com o sistema de TI. A Tabela 2.5
discrimina essas funes para componentes do modelo. As funes marcadas com *
(asterisco) na tabela so redefinidas no componente.

Tabela 2.5 Funes RBAC de Suporte do Sistema

Core RBAC Hierarchal RBAC Static Separation of Dynamic Separation of
Duty (SSD) Relations Duty (DSD) Relations
CreateSession Core RBAC Core RBAC Core RBAC
DeleteSession + +
AddActiveRole CreateSession* CreateSession*
DropActiveRole AddActiveRole* AddActiveRole*
CheckAccess

2.4.3. Funes de Reviso

As Funes de Reviso possibilitam a reviso dos resultados das aes criadas pelas
funes administrativas. A Tabela 2.6 discrimina estas funes para componentes do modelo.
As funes marcadas com * (asterisco) na tabela so redefinidas no componente.

25
Tabela 2.6 Funes RBAC de Reviso
Core RBAC Hierarchal RBAC Static Separation of Dynamic
Duty (SSD) Relations Separation of Duty
(DSD) Relations
AssignedUsers Core RBAC Core RBAC Core RBAC
AssignedRoles + + +
RolePermissions AuthorizedUsers SsdRoleSets DsdRoleSet
UserPermissions AuthorizedRoles SsdRoleSetRoles DsdRoleSetRoless
SessionRoles RolePermissions* SsdRoleSetCardinality DsdRoleSetCardina
SessionPermissions UserPermissions* lity
RoleOperationOnOb RoleOperationOnObj
ject ect*
UserOperationOnOb UserOperationOnObj
ject ect*

26
3. CARACTERIZAO DO AMBIENTE

O Senado Federal um dos rgos que, ao lado da Cmara dos Deputados, compem
o Congresso Nacional. Trata-se de uma instituio do Poder Legislativo brasileiro, no mbito
federal, que representa os estados da federao na posio hierrquica mais alta da estrutura
legislativa do pas. Dentro da estrutura bicameral adotada pelo sistema brasileiro, o Senado
Federal atua como a Cmara Alta, composta por 3 (trs) representantes de cada estado da
federao e do Distrito Federal, eleitos por voto majoritrio para mandato de 8 (oito) anos.

3.1. PERFIL DA INSTITUIO SENADO FEDERAL NO CONTEXTO

DA TI E DA SEGURANA DA INFORMAO

O Senado Federal uma instituio civil do governo brasileiro. Suas atribuies esto
bem definidas na Constituio Federal brasileira. Alm da funo precpua de legislar,
elaborando leis, o Senado ainda exerce atividades em categorias que podem ser classificadas
como fiscalizadora e parlamentar. A proposio, anlise e debate de projetos de lei e de
decretos legislativos, e a emisso de pareceres sobre diversas matrias fazem parte da
atividade legislativa. Requerimentos de informao e a sua anlise caracterizam a funo
fiscalizadora. Os discursos, debates e apartes em plenrio e nas comisses tipificam a
atividade parlamentar. O Senado Federal ainda possui atribuies exclusivas e de fundamental
importncia para o correto funcionamento do governo brasileiro a Constituio Federal
estabelece as atribuies exclusivas do Senado Federal no art. 52.

Naturalmente, assim como outras organizaes civis, o Senado Federal faz uso intenso
de recursos de informtica e tecnologia para cumprir suas funes constitucionais e dar
suporte s suas atividades operacionais e administrativas. Atualmente, a dependncia que as
instituies tm de sistemas de processamento de informaes extremamente alta e expe a
preocupao com a integridade, disponibilidade e confidencialidade dos sistemas de
comunicao e das informaes.

Dentro do aplicvel, o Senado Federal tem grande preocupao em assegurar a

confidencialidade da informao. Isso se aplica, mas no se limita, a dados pessoais; as fases
do processo legislativo em que o dado ainda possui um carter reservado antes de tornar-se
informao pblica (lei); informaes confidenciais de terceiros quando apreciadas pelo
Senado Federal (por exemplo, dados bancrios e telefnicos de pessoas investigadas em
27
Comisses Parlamentares de Inqurito). No entanto, as atribuies do Senado Federal e a
natureza de suas atividades conferem questo da disponibilidade e integridade da
informao um peso maior em relao ao aspecto da privacidade.

No contexto da utilizao da TI como instrumento para cumprir suas funes, o

Senado Federal possui seus prprios requisitos de segurana da informao. Numa instituio
governamental civil pblica como o Senado Federal, eles se baseiam mais na integridade,
disponibilidade, acessibilidade da informao, muito em funo da crescente exigncia
pela sociedade por transparncia e correo nas atitudes dos agentes pblicos.
Internamente, o componente poltico que extremamente forte e influencia at algumas
funes administrativas determina uma hierarquia descentralizada onde a figura mais
importante, o senador, exige condies e tratamento igualitrio em relao aos demais, e que
seus subordinados diretos trabalhem com o objetivo de auxili-los no cumprimento das suas
obrigaes regimentais e constitucionais, e que os indiretos observem e colaborem para
manter essas premissas. Isso tambm um indicativo de que a integridade e disponibilidade
das informaes e recursos computacionais tm um peso maior. O que o Senado Federal
produz como produto final da sua atuao de propriedade do prprio Senado Federal e da
sociedade. A informao pblica e deve estar disponvel de forma ntegra, incluindo a
maneira como foi trabalhada ao longo do processo de criao. Os usurios dos sistemas e
recursos de informtica que trabalham no processo de produo da informao no detm a
sua posse. Eles assumem uma funo, um papel dentro desse processo, e isso que regula o
acesso aos recursos computacionais e prpria informao. No um usurio que determina,
por deciso discricionria sua, quem pode ou no ter acesso a determinado recurso ou
informao. Isso pode acontecer, e, de fato, acontece em alguns casos especficos, mas,
normalmente, o que ocorre que a concesso de acesso feita de acordo com uma norma,
diretriz ou poltica institucional corporativa que se baseia nas funes que os funcionrios do
Senado desempenham, nas leis que definem as atribuies do Senado, em princpios ticos,
em consideraes tcnicas pertinentes infra-estrutura disponvel (capacidade de
processamento, limitaes, etc.) e em prticas de uso normalmente aceitas.

Mais especificamente, em termos de controle de acesso, sua importncia no contexto

da Segurana da Informao e o perfil da instituio Senado Federal, o RBAC representa uma
opo interessante, especialmente quando tratamos do acesso por meios mais flexveis, como
o caso das redes sem fio.

28
 Uma idia da situao atual rede do Senado, da demanda pela rede sem fio da
aplicabilidade do RBAC no contexto abordado neste trabalho sero apresentados nas sees e
captulos seguintes.

3.2. SITUAO ATUAL DA REDE DO SENADO FEDERAL

Desde que foi criado com o objetivo de promover e desenvolver solues de

processamento eletrnico de dados com a aplicao da TI, o PRODASEN Secretaria
Especial de Informtica do Senado Federal procura adotar tecnologias e solues mais
adequadas, tcnica e financeiramente, para atender s necessidades de seus usurios e para
permitir que o Senado Federal cumpra suas funes.

Isso tem sido percebido no planejamento e destinao de parcela considervel do

oramento do rgo para manuteno e modernizao da infra-estrutura de rede lgica e
fsica, ainda que nem sempre o andamento dos projetos dessa natureza transcorra conforme o
desejado em termos de prazo, em funo dos processos administrativos (anlises tcnicas e
jurdicas, pareceres, preparao de editais, aprovao e autorizao de despesas, etc.) a que os
rgos pblicos esto obrigados por lei a cumprir.

Atualmente a rede do Senado Federal possui, aproximadamente, 4000 (quatro mil)

computadores conectados. A tecnologia predominantemente utilizada a Ethernet. O ncleo
da rede usa Gigabit Ethernet e ATM, sendo que essa ltima foi adotada inicialmente, mas
vem sendo gradativamente substituda pela primeira. A rede atende tambm s residncias dos
senadores, localizadas na SQS 309 do Plano Piloto. Os servidores principais da rede (de
banco de dados, de arquivos, de impresso, de aplicativos) encontram-se instalados e
protegidos fisicamente dentro de uma sala cofre, juntamente com robs utilizados para
procedimentos de cpias de segurana, e dispositivos de armazenamento compartilhados
pelos servidores.

Todos os pontos da rede so atendidos por switches, e aqueles da ponta da topologia se

comunicam com os do ncleo por uplinks Gigabit ou ATM. Em termos de endereamento,
trata-se de uma rede segmentada logicamente, onde cada switch representa uma sub-rede
configurada com VLANs e roteamento necessrios para comunicao com demais
equipamentos da rede.

29
 Em termos de conexo externa, o Senado Federal possui ligao dedicada e
permanente com a Internet e disponibiliza acesso remoto sua rede por meio de tecnologia de
VPN.

Especificamente em relao rede sem fio, o Senado Federal j adota uma soluo
localizada dentro do plenrio que permite aos senadores acompanhar a pauta das votaes por
meio de uma aplicao chamada Ordem do Dia Eletrnica. A tecnologia utilizada baseia-se
no padro IEEE 802.11b, operando a uma taxa de transmisso mxima terica de 11 Mbps.
Existe a previso de iniciar, ainda no ano de 2006, a migrao para o padro IEEE 802.11g,
de 54 Mbps na prtica, dependendo da distncia entre dispositivo mvel e a ponto de
acesso, da quantidade de dispositivos e da sobrecarga de protocolos e mtodo de acesso ao
meio, a taxa efetiva (Throughput) que uma aplicao pode atingir varia entre 5 a 7 Mbps no
padro IEEE 802.11b e 25 a 30 Mbps no IEEE 802.11a e 802.11g. Considerando-se que o
plenrio um local onde o acesso de pessoas controlado e a oportunidade para conduzir
uma reforma que permitisse instalao de rede fixa bastante restrita, a tecnologia sem fio foi
adotada pela sua flexibilidade e pela necessidade de introduzir uma soluo mais eficiente e
moderna para auxlio ao processo de votao e debate de matrias. Essa flexibilidade um
dos fatores que motivam a expanso da rede sem fio para outras reas do Senado Federal,
onde certas categorias profissionais exercem atividades que seriam executadas com mais
agilidade por meio do uso de dispositivos mveis com acesso aos recursos da rede.

3.3. DEMANDA POR REDE SEM FIO NO SENADO FEDERAL

A utilizao de rede sem fio no Senado Federal no pretende substituir a rede

tradicional fixa (com cabos), mas sim ampliar as possibilidades de acesso, oferecendo a
mobilidade e flexibilidade mencionadas.

Assim, como uma tecnologia que agrega outras possibilidades, a demanda por rede
sem fio no Senado surge da necessidade crescente, por parte de algumas categorias
profissionais, de realizar suas tarefas e obrigaes de maneira mais produtiva. A natureza de
algumas atividades efetuadas dentro do Senado Federal, em funo da sua composio e da
forma como funciona, tem exigido um esforo maior dos profissionais, e podem ser feitas de
maneira mais eficiente adotando-se instrumentos ou ferramentas mais adequadas. Por
exemplo, uma das atividades dos jornalistas do Senado Federal cobrir e divulgar o trabalho
dos oitenta e um senadores e das comisses. Isso geralmente feito no gabinete do senador

30
onde o jornalista comparece para entrevist-lo ou para conversar com seus assessores , ou
na sala das comisses onde acontecem as audincias e os trabalhos da comisso. A
possibilidade de acesso aos recursos da rede que o jornalista necessita, diretamente do local,
por meio de um notebook, torna o desempenho da sua tarefa mais produtivo. De maneira
semelhante, os funcionrios que trabalham com atendimento e resoluo de problemas nos
computadores dos gabinetes dos senadores e nas demais reas administrativas podem agilizar
o trabalho e oferecer uma posio mais precisa sobre o andamento das ocorrncias
aumentando, inclusive, a quantidade de solicitaes atendidas tendo acesso ao sistema de
registro de ocorrncias a partir do local, sem ter que pedir que algum do setor onde esto
realizando o atendimento pare suas atividades para que eles possam faz-lo a partir de um
computador ligado rede fixa.

Em meados da dcada de 90, o Senado Federal consolidou um novo modelo de

comunicao social, cujo objetivo principal era levar diretamente ao cidado as notcias dos
trabalhos desenvolvidos pelos senadores, buscando contornar os problemas do pouco espao
de divulgao dado pela imprensa e a eventual publicao de informaes distorcidas sobre as
atividades dos parlamentares pela mdia comercial. Esse modelo prioriza a instalao de
veculos de comunicao de massa como o Jornal do Senado (maio de 1995), a TV Senado
(fevereiro de 1996), a Rdio Senado (janeiro de 1997) e a Agncia Senado (janeiro de 1997)
[10]. Nesse contexto, a rede sem fio representa mais um instrumento de auxlio para esse tipo
de atividade, tornando mais dinmicas as tarefas da rea de comunicao.

O atendimento a qualquer demanda que envolva recursos de TI deve ser avaliada sob
vrios aspectos, e a Segurana da Informao um dos mais importantes. Se por um lado uma
rede sem fio pode trazer benefcios para a instituio (maior flexibilidade, maior
produtividade, uso mais eficiente do espao fsico, reduo de custos), por outro ela
insegura, devido prpria natureza do meio de comunicao e a medidas de segurana
inadequadas [11]. neste ponto das medidas de segurana que o RBAC se insere como
mais um mecanismo de proteo para contribuir na misso de atingir o nvel de segurana
requerido e planejado da instituio.

31
4. APLICABILIDADE E GESTO DO RBAC NA REDE SEM
FIO DO SENADO FEDERAL

A adoo de um modelo como o RBAC na rede sem fio do Senado Federal pretende
prover essa estrutura com um mecanismo mais flexvel para atribuio e gerenciamento de
permisses de acesso, visando, dessa forma, preservar os princpios da segurana da
informao nos nveis desejados e adequados aos objetivos e misso dessa instituio
legislativa, permitindo, inclusive, a prpria disponibilidade do meio de acesso sem fio aos
usurios que realmente necessitam, de acordo com a funo que desempenham e a poltica de
segurana da Casa.

A adoo de qualquer modelo ou tecnologia implica na avaliao das vantagens e

desvantagens, buscando uma relao custo-benefcio sempre favorvel. A aplicao do RBAC
em um ambiente de rede sem fio apresenta diversas consideraes que devem ser observadas
para permitir a efetividade da sua utilizao.

4.1. FUNO DO RBAC NA REDE SEM FIO DO SENADO FEDERAL

No que se refere implantao de rede sem fio em uma escala mais abrangente dentro
Senado Federal, o RBAC integraria o rol de instrumentos voltados para administrao de
segurana dessa estrutura, em conformidade com as prticas de segurana da instituio. As
necessidades de segurana relacionadas rede sem fio so identificadas a partir da percepo
da realidade do Senado Federal na utilizao da TI e procuram seguir a legislao brasileira e
padres nacionais e internacionais relacionadas segurana da informao. O estabelecimento
de uma poltica que englobe regras de uso geral, avaliao de riscos, procedimentos de
monitoramento e auditoria, tcnicas de projeto e implementao fundamental para uma
soluo efetiva de segurana.

Num plano bem abrangente, a norma NBR ISO/IEC 17799 [12] um padro de
qualidade e guia de referncia para polticas de segurana da informao reconhecido
mundialmente, que deve ser observado quando elas forem elaboradas.

Embora o conceito de RBAC no seja novo a idia bsica do RBAC existe a pelo
menos 30 anos , o uso de papis na poltica de administrao da rede relativamente novo
[6], e somente a partir de um perodo mais recente ele passou a atrair ateno como mtodo de

32
controle de acesso mais voltado para o desenvolvimento de aplicaes [13]. No contexto deste
trabalho, a adoo e implementao do RBAC no acontecem dentro da camada de aplicao,
onde o desenvolvedor constri o aplicativo inserindo comandos ou chamadas de APIs
(Application Programming Interfaces, ou Interface de Programao de Aplicativos) que
forneam a funcionalidade do RBAC, mas dirigida para camadas inferiores, considerando
como referncia o modelo de camadas OSI [14]. Controle de acesso, incluindo RBAC,
compreende elementos de hardware e software. Embora o software que implemente as
funcionalidades do RBAC possa ser considerado uma aplicao, o controle de acesso por
papis do RBAC na rede sem fio do Senado produzir efeitos nos protocolos a partir da
camada 3 (trs).

Conforme mencionamos anteriormente, a adoo do RBAC pretende, tambm,

assegurar o acesso neste contexto definido como a habilidade de utilizar um sistema,
recurso de TI, por exemplo, usar recursos de comunicao; executar programas; visualizar,
alterar ou apagar dados; e semelhantes estrutura de rede sem fio do Senado, permitindo
que ela possa suportar adequadamente todos os usurios que necessitem utiliz-la. Para isso, o
controle de acesso o meio pelo qual a habilidade de utilizar os sistemas concedida ou
restringida de alguma maneira deve analisar a identidade do usurio, mapeando-a para um
papel, e determinando, assim, se pode (e o quanto pode) ou no usar o recurso. Controle de
acesso est diretamente ligado identidade do usurio. E a identificao do usurio a base
para o processo de autorizao, sendo este parte de qualquer soluo de segurana projetada
para defender uma rede sem fio das vulnerabilidades a que est sujeita. Este um ponto
essencial: todos os processos envolvidos na implementao da segurana devem ser
cuidadosamente planejados e, posteriormente, monitorados para garantir a qualidade da
soluo. O RBAC representa um processo importante que, combinado com outras tcnicas
especficas para redes sem fio, compem uma soluo robusta para esse ambiente.

4.2. BENEFCIOS DO RBAC

Facilitar a administrao de autorizao, reforar a aplicao da poltica de segurana

corporativa e aprimorar a segurana e integridade dos sistemas so benefcios que
potencializam a utilizao do RBAC [3] [6]. Embora exista um esforo inicial considervel
para a identificao e determinao dos papis dentro da organizao, aps o estabelecimento
das permisses de acesso h uma tendncia de estabilidade, observada em um grau menor do
esforo administrativo requerido para manuteno.
33
 A simplificao do gerenciamento de permisses est relacionada idia de que os
usurios no tm acesso discricionrio aos recursos corporativos, mas so
administrativamente associados a papis, e a esses, por sua vez, so atribudas as permisses
de acesso de acordo com as funes, responsabilidades e qualificaes que representam
dentro da organizao. Assim, os usurios so associados aos respectivos papis, podendo
redefinir a associao de um papel para outro sem modificar estrutura bsica de acesso [3].
Vrios fatores podem influenciar a simplificao. Quanto maior a rotatividade de pessoal, e,
em conseqncia, maior o nmero de mudanas de papis, mais simples o RBAC em
comparao com outros mtodos de controle de acesso. At em organizaes muito
dinmicas, onde os papis e as permisses podem mudar rapidamente, o RBAC mais
eficiente na mudana dos papis dos usurios e na alterao das permisses dos papis [6].

O reforo da aplicao da poltica de segurana baseia-se no fato do RBAC ser

considerado no discricionrio no sentido de que os usurios so forados a cumprir a poltica
do rgo, mantida de maneira centralizada por um administrador de segurana que representa
a instituio.

O aprimoramento da segurana e integridade sistemas se revela na reduo do impacto

das violaes de segurana de duas maneiras: primeiro, o RBAC pode reduzir a predisposio
para ocorrncias de violaes de segurana; segundo, ocorrendo uma violao, o RBAC pode
limitar o estrago provocado por ela [6].

4.3. CONSIDERAES SOBRE ESFORO E TAREFAS PARA

IMPLEMENTAO DO RBAC

O esforo necessrio para implementar qualquer sistema ou tecnologia voltada para

segurana envolve aspectos administrativos, operacionais e financeiros que podem influenciar
a deciso de adotar um modelo como o RBAC. No caso do Senado Federal, ou qualquer
organizao que pretenda desenvolver um projeto em contexto semelhante, alguns pontos
devem ser observados com ateno. A natureza do modelo RBAC cria uma relao com as
funes desempenhadas pela instituio. A situao ideal seria aquela em que as funes e
processos do negcio fossem estabelecidos juntamente com uma estrutura para suport-los e
os sistemas fossem projetados com o conceito de papis correspondendo s funes e
processos definidos. Cada papel teria um conjunto de permisses associado de acordo com a
posio e funo dentro da instituio [6]. Entretanto, raramente esse cenrio ideal ocorre, e
34
necessrio trabalhar e adaptar-se s condies existentes. Isso implica que, alm do custo
direto da aquisio do hardware e software RBAC, algumas tarefas e procedimentos
especficos devem ser efetuados.

4.3.1. Definio dos Papis (Role Engineering)

O processo de definio dos papis chamado de Role Engineering ou Role

Definition. Dependendo do escopo da implementao e do tamanho da instituio esse
processo pode levar de semanas a meses, mas vital para o sucesso do RBAC.

Esse processo envolve a definio dos papis que determinaro quais usurios tero
acesso a quais informaes e aplicaes, alm do relacionamento entre os papis (hierarquia,
restries).

Uma caracterstica desse processo que ele pode identificar acessos informais
medida que os papis vo sendo definidos. A transio para um sistema de controle baseado
em papis formaliza vrios relacionamentos dentro da instituio [6].

No caso do Senado Federal, esse processo envolver, tambm, um levantamento e

uma avaliao dos atuais grupos de usurios definidos na base de autenticao da rede
corporativa, e uma integrao com a definio dos papis que correspondam s funes e
categorias profissionais existentes na instituio.

Algumas ferramentas de software foram desenvolvidas para auxiliar na definio dos

papis. O NIST, por exemplo, desenvolveu o RGP-Admin, um produto para gerenciar os
relacionamentos entre papis e permisses, e AccesMgr, uma interface grfica para
gerenciamento de listas de controle de acesso de arquivos do Windows.

4.3.2. Interoperabilidade e Estrutura Legada

Interoperabilidade a capacidade de se comunicar e transferir informao entre

sistemas de plataformas diferentes. Esse um requisito importante que precisa ser observado
especialmente quando a empresa ou instituio possui uma estrutura legada de sistemas e
componentes distribuda e hbrida.

No caso do Senado Federal, o impacto desses requisitos no deve ser to acentuado,

uma vez que a implementao da rede sem fio encontra-se em fase inicial, e a adoo do
RBAC tem um escopo bem definido de controlar acesso dentro do limite dessa rede,
35
oferecendo uma interface para os recursos da rede corporativa, conforme veremos mais
adiante. A interoperabilidade seria requerida para uma possvel e desejvel integrao da
autenticao do usurio com alguma base de dados ou servio de diretrio j existente.

4.4. CONSIDERAES SOBRE ARQUITETURA E COMPONENTES

PARA IMPLEMENTAO DO RBAC NA REDE SEM FIO DO SENADO
FEDERAL

Conforme mencionamos anteriormente, a rede sem fio do plenrio do Senado Federal

baseia-se no padro IEEE 802.11b, funcionando em modo infra-estrutura, ou seja, os usurios
com dispositivos sem fio (notebooks) se conectam a um outro equipamento chamado AP
Access Point (Ponto de Acesso), que possui, tambm, uma conexo para a rede fixa
tradicional, e permite a comunicao entre os usurios conectados a ele ou entre esses e os da
rede fixa. O padro IEEE 802.11b, assim como o 802.11a e 802.11g, faz parte de uma famlia
de especificaes e protocolos de comunicao para redes sem fio definida pelo comit de
padronizao do IEEE (Institute of Electrical and Electronics Engineers). Essa famlia de
padres amplamente utilizada para implementao de redes sem fio em ambientes
corporativos e domsticos, tambm, e reside nas camadas fsica e de enlace do modelo de
referncia OSI. A implantao da rede sem fio nas outras reas do Senado Federal continuar
adotando o padro 802.11b, que ser atualizado posteriormente para o 802.11g. A figura 4.1
mostra o escopo das especificaes IEEE 802.11 em referncia s camadas do modelo OSI.

Modelo de referncia OSI Modelo de referncia 802.11

Camada 7 Aplicao
Camada 6 Apresentao
Camada 5 Sesso Protocolos acima do 802.11
Camada 4 Transporte
Camada 3 Rede
LLC Alcance das
Camada 2 Enlace especificaes
MAC 802.11

Camada 1 Fsica Fsica

Figura 4.1 - Modelo de referncia OSI x 802.11

36
 A implementao eficiente e eficaz de qualquer sistema de controle de acesso requer
planejamento. A implantao do RBAC como componente da rede sem fio do Senado Federal
no foge a essa regra.

Inicialmente, oportuno falar sobre algumas caractersticas bsicas das redes sem fio
no que se refere a segurana. Levando-se em conta o nvel de segurana que se deseja atingir,
h diversas maneiras e mtodos de segurana que podem compor uma soluo de rede sem
fio. Para ilustrar as possibilidades, uma abordagem interessante a que prope a classificao
das redes sem fio em trs tipos [11]: Basic (Bsica), Hardened (Enrijecida) e Secured
(Fortalecida). A figura 4.2 mostra essa classificao de maneira modular.

Dados protegidos do usurio

Rede sem fio Fortalecida (Secured)

Rede sem fio Enrijecida (Hardened)

Rede sem fio Bsica (Insegura)

Figura 4.2 Abordagem modular para soluo de segurana

O primeiro nvel (Bsico Inseguro) usa as definies e recomendaes da

especificao original do padro 802.11, em sua forma mais bsica, e configurao padro
dos equipamentos de acesso conforme distribuda por seus fabricantes. Embora esse nvel de
segurana possa ser apropriado a alguns cenrios, no se aplica ao ambiente do Senado
Federal.

O nvel seguinte (Hardened Enrijecido) emprega mecanismos de proteo mais

especficos, tais como criptografia WEP e ACLs; protocolos de segurana dedicados, tais
como 802.1x para requisitar autenticao; RADIUS para gerenciamento centralizado de
usurios; WPA, WPA2, TKIP, 802.11i. Esse nvel de segurana adequado ao perfil do
Senado Federal.

37
 O nvel mais seguro (Secured Fortalecido) indicado para redes sem fio onde as
informaes so consideradas confidenciais e requer algum tipo de certificao de segurana,
com proteo ponto-a-ponto por VPN ou tecnologia semelhante.

O modelo para controle de acesso RBAC se insere como um componente adicional,

complementando os mecanismos do nvel intermedirio de segurana (Hardened
Enrijecido), agregando outras possibilidades de controle que so aplicadas considerando a
identidade do usurio e a sua funo dentro da instituio.

O emprego de uma soluo de segurana contemplando o modelo RBAC envolve

componentes de hardware e software, conforme j dissemos. Os componentes de hardware
(processador, memria, disco, interfaces de rede) devem ser dimensionados para suportar a
carga tanto em termos da quantidade de usurios simultneos que estaro sujeitos ao controle
quanto da complexidade que a funcionalidade do RBAC implementada pelo software
representa. As opes de hardware incluem mquinas servidoras tradicionais, no sentido de
que seriam adquiridas para a finalidade de executar o software RBAC, ou solues integradas
do tipo appliances, compostas do hardware e do software necessrios. Os appliances so
solues normalmente proprietrias os componentes tm especificaes prprias que no
seguem nenhum padro, e o software s executa sob a combinao especfica de componentes
de hardware para o qual foi desenvolvido , embora alguns mais modernos j utilizem
partes padronizadas e sistemas operacionais comerciais ou de cdigo aberto. Os appliances
podem no apresentar a mesma capacidade de expanso dos servidores tradicionais porque
so geralmente pr-configurados para uma tarefa especfica, priorizando aspectos de
desempenho e custo para o objetivo a que se destina.

O projeto dessa soluo deve integrar todos esses componentes de maneira que a sua
atuao conjunta cumpra os objetivos desejados, formando uma arquitetura abrangente em
relao ao escopo considerado, que, neste caso, se trata de uma rede sem fio com conexo
para a rede fixa corporativa do Senado Federal. No objetivo deste trabalho detalhar
tecnicamente o projeto da soluo, mas essencial fazer certas consideraes sobre a
arquitetura indicada para o assunto em questo. A figura 4.3 apresenta essa arquitetura,
mostrando os principais elementos relacionados implementao de controle de acesso em
um ambiente de rede sem fio.

38
 Rede Sem Fio (Wireless) Rede Fixa Corporativa

Switch Ethernet
Usurios fixos

Gateway RBAC

Servidor

AP Access Point
Console de
Gerenciamento
Usurio sem fio RBAC
RADIUS

AD Active Directory

Internet

Figura 4.3 Arquitetura Rede Sem Fio/RBAC

A idia mostrada nessa arquitetura que o controle de acesso RBAC efetuado por
um dispositivo dedicado, que a interface final dos usurios da rede sem fio com a rede
corporativa fixa. Todo o trfego originado na rede sem fio ou a ela dirigido deve,
necessariamente, passar por esse dispositivo, que atua como uma porta de comunicao, um
gateway, para a rede sem fio.

Variaes de definio podem existir, mas no contexto deste trabalho um gateway

um dispositivo que controla o fluxo de dados que entra ou sai de uma rede, transferindo-os
39
para outra rede ou sub-rede, efetuando operaes a partir da camada 3 (trs) do modelo OSI,
com base em endereo de origem e/ou destino, tipos de protocolos, identidade do usurio, tipo
de aplicao. Na rede sem fio do Senado Federal, o gateway implementaria a funcionalidade
do modelo RBAC para controlar o acesso aos servios disponveis na rede corporativa.

O modo de operao da rede sem fio que se pretende instalar permite a sua integrao
rede local corporativa da instituio. A rede sem fio passa a ser uma estrutura empresarial e
para que seja funcional, apresente os nveis de segurana requeridos e possa ser gerenciada
adequadamente necessrio estar bem familiarizado com a tecnologia utilizada e seus
aspectos funcionais, considerando-se como referncia conhecida o modelo OSI para
compreender extenso da soluo de segurana a ser aplicada.

Para a arquitetura apresentada, o tratamento da segurana deve ser distribudo nos

nveis em que os componentes atuam, formando uma soluo hierarquizada que garanta a
proteo requerida em cada camada. Solues para redes sem fio existem nas camadas 2 e 3,
sendo possvel combinar os recursos de cada camada para compor uma arquitetura de
segurana mais robusta.

Os APs so dispositivos que atuam estritamente na camada 2 como pontes entre meio
sem fio e a sua interface que permite conexo com a rede fixa, transferindo pacotes de dados.
Nessa camada, as medidas de segurana direcionam-se proteo da comunicao entre o
dispositivo do usurio e o AP pelo meio sem fio contra interceptao e alterao indevidas,
fazendo uso dos mecanismos e protocolos de criptografia e autenticao disponveis. Dois
pontos so importantes: quem pode se associar ao AP e, a partir da, a comunicao
propriamente dita. A questo da associao tratada com os protocolos de autenticao e a
comunicao com os de criptografia.

O gateway um dispositivo que atua a partir da camada 3, podendo executar uma srie
de servios, tais como filtragem de pacotes, NAT, roteamento, entre outros, sendo, no nosso
contexto, o RBAC o principal deles, em torno do qual os demais se integram.

O posicionamento do gateway como interface de duas redes neste caso, uma sem
fio e outra fixa com cabos pe em prtica um conceito chamado Segmentao. Segmentar
uma rede sem fio significa colocar os APs em uma rede separada da rede fixa por um
equipamento de segurana (gateway). H vrias maneiras de promover essa separao. A
mais efetiva em termos de segurana aquela que separa os APs fisicamente, fazendo do
40
gateway o nico caminho fsico para a rede fixa principal. No entanto, nem sempre possvel
ou vivel construir e manter uma estrutura fsica independente para essa finalidade, caso em
que o Senado Federal se enquadra. Nessa situao, uma opo fazer uso de VLANs ou
VPN, configurando a comunicao dos APs at o gateway por meio de um caminho virtual
utilizando parte da rede fixa como meio de transporte.

A razo para se utilizar um dispositivo de segurana numa arquitetura de segmentao

envolvendo redes sem fio e redes tradicionais fixas com cabos proteger os recursos
disponveis de possveis atividades maliciosas a partir da rede sem fio, que no possui o
mesmo nvel fsico de segurana de uma rede fixa. O princpio aqui o mesmo da utilizao
de firewalls para proteo de redes locais quando conectadas a redes pblicas, porm aplicado
num contexto localizado onde as caractersticas do meio fsico e funcionamento de uma
tecnologia (no caso a redes sem fio) podem comprometer a segurana de outras. O gateway
aqui colocado no um firewall completo com todas as funes desse tipo de dispositivo,
embora possa incorporar alguma funcionalidade nesse sentido. O principal que o gateway
implementa o modelo RBAC, e qualquer outra funcionalidade est direta ou indiretamente
relacionada quela para aplicao de seus princpios.

Numa abordagem hierarquizada de segurana para redes sem fio, o gateway o

prximo e mais poderoso nvel de segurana a partir dos mecanismos de proteo dos APs.
Considerando que os APs sejam preparados para enviar todo o trfego dos usurios para o
gateway j que este o nico destino possvel , ainda que o dispositivo sem fio do
usurio se associe ao AP, ele estar sujeito s regras de segurana estabelecidas no gateway
via RBAC para acesso aos recursos da rede corporativa. nesse momento que a poltica de
segurana reforada, e todos os controles de acesso so exercidos para manter o nvel de
segurana dentro dos requisitos estabelecidos.

O controle de acesso propriamente dito pressupe alguma maneira de autenticar o

usurio. O gateway deve fazer isso por meios prprios ou ter capacidade de interagir com
algum servio de autenticao externo em algum ponto da rede. Alguns servios de
autenticao muito utilizados so os baseados em RADIUS e Windows Active Directory, por
exemplo. O uso de um servio de autenticao j existente na rede permite aproveitar as
credenciais do usurio para autentic-lo no gateway e, no contexto do RBAC, mape-lo para o
papel apropriado.

41
 A relao entre o RBAC e um servio de diretrios existente, destinado para
autenticao de usurios, pressupe alguma interoperabilidade entre eles. Ela acontece
quando a implementao do software RBAC capaz de reconhecer objetos e propriedades do
servio de diretrios, utilizando-os como critrios de mapeamento dos usurios para os
papis. Por exemplo, a participao em grupos um dos critrios que podem ser avaliados
nesse sentido. Um grupo uma coleo ou lista nomeada de usurios. Esse conceito de
agrupamento est presente na maioria dos sistemas de segurana e pode ser usado para
programar alguns aspectos dos papis definidos no modelo RBAC.

A interoperabilidade entre o software RBAC e o servio de diretrios no que se refere

autenticao do usurio tambm permite implementar a funcionalidade de Single Sign On
(SSO). Isso significa, basicamente, compartilhamento de informaes de autenticao para
evitar que o usurio tenha que apresentar a sua identificao ou credenciais mais de uma vez.
uma forma de autenticao por software que permite ao usurio se autenticar uma vez e ter
acesso a recursos de vrios sistemas dentro do ambiente. No contexto deste trabalho,
representa autenticar os usurios no servio de diretrios e, a partir da, o RBAC mape-los
para os seus respectivos papis e autorizar o acesso aos recursos conforme as regras definidas
para cada papel.

Por motivos de simplificao, no desenho da arquitetura da figura 4.3 no aparecem

explicitamente elementos de redundncia do gateway (cluster, por exemplo) e outros
equipamentos de comunicao e segurana (firewalls, roteadores, etc.) para controle de acesso
Internet e outras redes externas. Porm, esses elementos devem fazer parte da soluo
projetada para evitar um ponto nico de falha no dispositivo que concentra todo o trfego da
rede sem fio e proteger os acessos externos.

4.5. A QUESTO DA LOCALIZAO DO USURIO MVEL

Ao se considerar a mobilidade, caracterstica marcante das redes sem fio, no modelo

RBAC, pode surgir a necessidade de ter-se permisses distintas para um mesmo usurio,
dependendo da localizao em que este faz o acesso rede. Um exemplo disto na rede do
Senado seria a permisso para acessar o sistema de votao. Para esse sistema, alm do
usurio, no caso o senador, ter que pertencer a um papel especfico, ele deveria estar
acessando a rede de um local especfico, no caso o plenrio, para poder ter acesso. H mais de

42
uma maneira de se implementar o controle de acesso atravs do RBAC considerando-se a
localizao, onde descrevemos abaixo as mais citadas.

A primeira possibilidade de se implementar o controle de acesso por localizao no

RBAC definindo-se papis por regies do espao fsico de onde a rede pode ser acessada.
Neste caso, determinados papis s podem ser ativados em determinadas localizaes da rede.
No nosso exemplo do sistema de votao do Senado definir-se-ia um papel de votante, o
qual se atribuiria ao senador, mas que s seria ativado quando ele estivesse nas dependncias
do plenrio da Casa. Esta implementao descrita por Montoro e Johnson [15].

Esta forma de considerar a localizao no modelo RBAC bastante intuitiva, porm

na prtica apresenta algumas dificuldades de implementao. Mesmo no exemplo, pode-se
perceber que seria preciso criar pelo menos dois papis para o Senado, um para quando
estivesse no plenrio e outro para quando no estivesse. Da mesma forma, muitos outros
papis poderiam ser duplicados se tivessem que atribuir permisses distintas dentro e fora do
plenrio. O problema se tornaria ainda mais complexo se fossem consideradas outras
localizaes da Casa, tais como gabinetes, restaurante, hall, etc. Neste caso, alguns papis
teriam de ser replicados para as diversas localidades, criando uma matriz de papis por
localizao. Esta soluo, alm de ter a implementao inicial trabalhosa, seria difcil de ser
mantida.

4.5.1. Spatial RBAC

Outra implementao possvel, denominada de Spatial RBAC descrita por Hansen e

Oleshchuk [16]. Nessa implementao, as permisses so atribudas dinamicamente aos
papis segundo a localizao do usurio. Desse modo, no caso do sistema de votao, o
senador seria atribudo a apenas um papel, o de senador, e a este papel seria atribuda a
permisso para votar. Contudo, esta permisso s seria ativada quando o senador acessasse a
rede de dentro do plenrio. Este mtodo elimina a necessidade de se definir vrios papis
semelhantes para um mesmo tipo de usurio, com diferenciaes feitas apenas devido a
permisses especficas para determinadas localizaes.

4.5.2. Influncia da localizao do usurio no contexto do Senado Federal

O exemplo do sistema de votao mencionado anteriormente (com possibilidade de

acesso por uma rede sem fio) hipottico e no representa uma realidade no ambiente do

43
Senado Federal, uma vez que a rede do sistema de votao independente e isolada por
razes de segurana. Ele foi citado para ilustrar a questo da mobilidade do usurio da rede
sem fio e sua relao com as permisses de acesso.

A princpio, essa questo da localizao do usurio colocada como fator nico e

a sua relao com permisses de acesso no parece ter relevncia no contexto do Senado
Federal, uma vez que as suas aplicaes e informaes no possuem qualquer carter de
restrio de acesso em funo do local onde se encontra o usurio.

Podem existir algumas restries de tempo ou perodo, associadas ou no com a

localizao, em determinados casos. Por exemplo, os consultores, assessores de senadores e
os prprios senadores, na poca da apresentao de emendas ao oramento, devem ter o
acesso ao sistema de emendas ao oramento garantido, priorizado; e o acesso s aplicaes de
streaming, durante o mesmo perodo, pode ser impedido ou restringido para qualquer papel,
visando evitar saturao do meio de comunicao. Ou o acesso s aplicaes de streaming
poderia ser liberado, durante aquele perodo, em reas onde a probabilidade do uso do sistema
de emendas fosse baixa ou absolutamente nenhuma. Nesse caso, o fator localizao no seria
nico e estaria associado a um perodo para determinar a concesso e/ou restrio de acesso.

O controle de permisses envolvendo esse tipo de variveis pressupe capacidade de

associao ou extenso do modelo RBAC aos fatores que se deseja considerar para determinar
as condies de acesso.

4.6. CENRIOS PARA APLICAO DO RBAC

A adoo de um modelo de controle de acesso como o RBAC s tem utilidade se, na

prtica, existirem situaes, cenrios nos quais ele possa ser aplicado e produza os resultados
esperados. No contexto do Senado Federal, a aplicao do RBAC no controle de acesso da
rede sem fio j num nvel mais abstrato e amplo um cenrio real. No entanto, existem
situaes mais especficas para as quais os princpios do RBAC podem ser aplicados,
considerando-se a realidade dos processos de negcio do Senado Federal.

4.6.1. Acesso a recursos mquinas servidoras, sistemas

Este o cenrio mais bsico para aplicao do RBAC (e de outros mtodos de

controle de acesso tambm), onde as permisses mnimas para acesso a cada recurso

44
disponvel na rede so associadas a cada papel, permitindo que os usurios realizem suas
tarefas em conformidade com poltica de segurana definida na instituio. Um recurso pode
ser um computador, uma impressora, um sistema de informao, um endereo de um servio
ou computador na Internet, e a atribuio de permisses por classes de usurios da rede sem
fio permite disponibilizar nveis de acesso diferenciados, com relativa facilidade de
administrao.

4.6.2. Gerencia de desempenho (performance) e disponibilidade da rede

Conforme j afirmamos, um dos objetivos da utilizao do modelo RBAC garantir a

disponibilidade da estrutura de acesso sem fio para os usurios cujas tarefas sejam
consideradas mais importantes para o Senado Federal.

As redes sem fio utilizam um meio compartilhado (o ar) como transporte para os
sinais (ondas eletromagnticas) que representam a informao. Dentro da rea de cobertura de
um AP no possvel dividir o ar em fatias, reservando-as para determinados grupos. Uma
maneira de controlar a disponibilidade da rede sem fio impor limites de utilizao da banda
da rede para os papis definidos no modelo RBAC, conforme sua funo e relevncia para a
instituio.

No caso de uma rede sem fio como mostrada na figura 4.3, esse tipo de controle no
ocorre diretamente na parte sem fio da arquitetura, mas nas interfaces fixas do gateway.
Indiretamente, pela limitao imposta na utilizao da banda no canal fixo, o efeito obtido no
canal sem fio o desejado, evitando que o meio compartilhado fique saturado por algum
usurio de perfil no relevante.

4.6.3. Acesso pblico ou convidado

Este cenrio combina as caractersticas dos dois anteriores para compor uma condio
na qual certos usurios possam ter, por meio da rede sem fio, acesso limitado a outros
recursos disponveis na rede corporativa.

No Senado Federal, esse um cenrio que pode ocorrer, embora a proposta inicial da
rede sem fio seja para atendimento a usurios internos com dispositivos mveis de sua
propriedade. Normalmente, instituies governamentais civis que optam por implementar
acesso sem fio s suas redes o fazem para fornecer essa capacidade aos seus funcionrios.
Porm, a rea de TI passa a ser solicitada no sentido de permitir que outros usurios

45
(funcionrios temporrios, terceirizados, funcionrios de outras instituies do governo,
profissionais de outras empresas realizando servios na instituio, visitantes em geral), alm
dos prprios funcionrios, possam utilizar a rede sem fio.

A existncia de uma rede sem fio num ambiente onde usurios em potencial estejam
portando equipamentos com tecnologia sem fio um convite ao uso pessoal ou profissional
desse tipo de dispositivo. No entanto, essa possibilidade deve ser muita bem controlada para
evitar problemas de segurana. No RBAC, a definio de perfis para convidados, com
restries de acesso aos recursos e limitao no uso de banda, uma maneira de exercer um
controle efetivo sobre essa classe de usurios.

Um exemplo seria o caso de jornalistas externos fazendo a cobertura de algum evento

no Senado Federal. Utilizando seus notebooks, eles poderiam enviar notcias ou matrias
sobre o evento para a redao de seus respectivos jornais pela rede sem fio, que permitiria,
neste caso, somente acesso Internet e servios de e-mail (correio eletrnico), por exemplo.

46
5. CONCLUSO

O principal objetivo da implantao de mtodos de controle de acesso em redes de

computadores assegurar o cumprimento de polticas de segurana e garantir a observao
dos princpios da Segurana da Informao nos nveis adequados instituio.

Este trabalho procurou apresentar as caractersticas mais relevantes do RBAC, um

modelo de controle de acesso baseado em papis, perfis ou funes, e sua aplicabilidade no
controle de acesso de uma rede sem fio. O conceito do RBAC no novo, e existem
implementaes em sistemas operacionais, sistemas gerenciadores de banco de dados, entre
outros. Vrios modelos RBAC surgiram ao longo do tempo, e, atualmente, j existe um
padro proposto pelo NIST definindo um conjunto de componentes e funcionalidades bsicas,
alm de uma terminologia consistente.

A questo da segurana das redes um assunto srio que deve ser abordado segundo
um processo que rene vrios componentes e tcnicas, atuando em diversas camadas. A
insero do RBAC nesse contexto representa uma opo de mtodo de controle de acesso que
pode atuar em vrios nveis, e no caso das redes sem fio complementa mecanismos
especficos desse tipo de tecnologia.

Diferentemente de outros mtodos de controle de acesso, como as matrizes ou listas de

controle de acesso que so usadas para controlar acesso num nvel mais baixo (acesso a
processos ou arquivo, por exemplo), o RBAC pode ser utilizado tambm em um nvel mais
alto, definindo operaes mais abstratas, tais como permitir ou negar acesso ao endereo
lgico de um recurso na rede, caracterstica essa apropriada para aplicao em redes sem fios,
onde uma srie de recursos e objetos podem ser tratados nesse nvel.

Dentre os diversos modelos de controle de acesso, o RBAC tem como grande

vantagem o fato de mapear quais dos recursos disponveis sero acessveis a cada papel ou
perfil, e no diretamente a cada usurio. O papel, neste caso, pode representar um cargo ou
funo dentro da corporao. Assim, o RBAC define de forma no discricionria quais
recursos cada usurio deve ter acesso baseado nos papis a que est associado. O modelo
pode tambm ser estendido para considerar a localizao do usurio na determinao das
permisses nos cenrios em que essa varivel seja relevante.

47
 Assim, a aplicao do RBAC na rede sem fio do Senado Federal agregaria vantagens
ao gerenciamento dos recursos da rede, tornando-o mais simples, porm mais robusto. Mais
simples devido prpria natureza do RBAC, e mais robusto por permitir o reforo das
polticas de segurana necessrias para a garantia do nvel de servio exigido para a rede
corporativa de uma das casas do nvel hierrquico mais alto do poder legislativo brasileiro.

Em face do exposto, a concluso que o RBAC um modelo de controle de acesso

eficiente e pode ser aplicado ao controle de redes sem fio, facilitando a administrao das
permisses de acesso aps a fase inicial de identificao, definio e mapeamento dos papis
na instituio.

5.1. PERSPECTIVAS FUTURAS

Existe uma grande expectativa em torno da implantao da rede sem fio do Senado
Federal num contexto mais abrangente do que o atual (somente no plenrio). Passada a fase
de site survey, realizada nas reas classificadas como prioritrias para essa demanda, h
interesse na adoo de uma soluo de rede sem fio que contenha os princpios descritos neste
trabalho.

Uma tarefa natural que segue a concluso deste trabalho e representa uma das
primeiras atividades da fase inicial da adoo do RBAC a definio dos papis. Numa
instituio como o Senado Federal alguns papis so intuitivos e bvios, tais como Senadores,
Consultores Legislativos, Assessores de Gabinete, Consultores de Oramento, Jornalistas,
Jornalistas Externos, entre outros. De uma forma mais completa e abrangente, esse processo
deve ser conduzido e aplicado de maneira estruturada em passos que possam quebrar a
complexidade inicial de uma implementao como essa. Alguns passos seriam: um
planejamento principal, onde, alm deste prprio trabalho, estariam declarados um
cronograma, oramento e alguns marcos para avaliao do progresso das atividades; uma
anlise dos recursos da rede em termos de requisitos de nvel de segurana necessrios; a
definio dos papis, baseados nos cargos, funes e perfis profissionais do Senado para
estabelecer as regras de acesso aos recursos da rede.

Uma das atividades futuras em relao a este trabalho tambm seria o estudo e
avaliao detalhados de produtos disponveis no mercado que atendam a esses requisitos. O

48
Anexo II deste trabalho apresenta as principais caractersticas de algumas solues de
mercado disponveis atualmente.

Outra ao muito importante, sem a qual no haver progresso para atingir o objetivo
final, a descrio detalhada do projeto em termos tcnicos, contendo as especificaes
necessrias para a aquisio e/ou desenvolvimento dos produtos necessrios.

49
 REFERNCIAS BIBLIOGRFICAS

[1] Network Technology Planning Guide (NTPG) - Networks and Networking.

California Departament of Education. Acessado em 15/08/2006 em
http://www.cde.ca.gov/ls/et/rd/ntpgchap1.asp.

[2] TANENBAUM, ANDREW S.. Redes de Computadores. Rio de Janeiro. Editora

Campus. 1997.

[3] FERRAIOLO, DAVID F.; CUGINI, JANER A.; KUHN, RICHARD. Role-Based
Access Control (RBAC): Features and Motivations National Institute of
Standards and Technology. Acessado em 19/05/2006 em
http://www.cs.unibo.it/people/faculty/montreso/master/materiale/ac/rbac.pdf.

[4] STALLINGS, William. Redes e Sistemas de Comunicao de Dados: Teorias e

aplicaes Corporativas. Rio de Janeiro. Editora Campus. 2005.

[5] ISO/IEC 7498-4:1989(E) Information Processing Systems Open Systems

Interconnection Basic Reference Model Part 4: Management Framework

[6] GALLAHER, MICHAEL P.; OCONNOR, ALAN C.; KROOP, BRIAN. The
Economic Impact of Role-Based Access Control. Research Triangle Institute.
Maro de 2002. Acessado em 6/6/2006 em http://www.nist.gov/director/prog-
ofc/report02-1.pdf.

[7] CAMELOT, Differentiating Between Access Control Terms, 2001

[8] NIST Role Based Access Control ANSI/INCITS 359 DRAFT 4/4/2003.
Acessado em 6/6/2006 em http://csrc.nist.gov/rbac/rbac-std-ncits.pdf.

[9] FERRAIOLO, D. F.; SANDHU, R.; GRAVILA, S.; KUHN, D.R.;

CHANDRAMOULI, R. Proposed NIST Standard for Role-Based Access Control
- ACM Transactions on Information and System Security, v. 4, n. 3, agosto de
2001, p. 224-274

[10] DUARTE, MARCIA YUKIKO MATSUUCHI; Histria da Central de

Atendimento do Senado Federal. In II Encontro Nacional da Rede Alfredo de
Carvalho. Abril de 2004.

[11] METOLLI, BAS; SADLER, ASH; BAXTER, RICHARD; HUGHES, IAN;

Securing Wireless LANS. BT Exact. 2005.

[12] ABNT NBR ISO/IEC 17799:2005 - Cdigo de Prtica para a Gesto da

Segurana da Informao Teoria e Prtica e ISO/IEC 27001:2005 Sistemas de
Gesto da Segurana da Informao Requisitos

[13] SANDHU, RAVI S.; COYNE, EDWARD J.; FEINSTEIN, HAL L.; YOUMAN,
CHARLES E. Role Based Access Control Models. Acessado em 6/6/2006 em
http://citeseer.ist.psu.edu/cache/papers/cs/15046/http:zSzzSzwww.list.gmu.eduzS

50
 zjournalszSzcomputerzSzpdf_verzSzi94rbac.pdf/sandhu96rolebased.pdf

[14] ISO/IEC 7498-1:1994(E) Information Technology Open Systems

Interconnection Basic Reference Model: The Basic Model

[15] MONTORO, T.; JOHNSON C.; Location History in a Low-cost Context

Awareness Environment. In: Proceedings of the Australasian information security
workshop conference on ACSW frontiers 2003, Australian Computer Society,
Inc., v. 21, 2003, p. 153-158.

[16] HANSEN, F.; OLESHCHUK, V.; Spatial Role Based Access Control Model for
Wireless Networks. In: Vehicular Technology Conference, 2003, v. 3, 2003, p.:
20932097.

51
 ANEXO I TRABALHOS J REALIZADOS NA REA

A pesquisa realizada para o desenvolvimento deste trabalho revelou algumas

iniciativas semelhantes de implementao de redes sem fio com controle de acesso baseado
no modelo RBAC.

A Harvard Medical School (HMS), localizada na cidade de Boston, no estado norte

americano do Massachusetts, desenvolveu um projeto chamado HMS Wireless Quad e
disponibiliza, desde maio de 2002, uma rede sem fio para conexo rede principal da HMS.
O documento Wireless at The Med School: Past, Present and Future, disponvel em
http://www.hms.harvard.edu/it/wireless/HarvardMedWLANCaseStudy.pdf, descreve um
pouco da historia do projeto, onde possvel identificar a utilizao do RBAC no controle de
acesso, de acordo com a seguinte transcrio:

Com o passar do tempo, HMS-IT planeja estender as capacidades do Controle de

Acesso Baseado em Papel (RBAC) construda dentro do mecanismo de autenticao
do Bluesocket. Conscientemente gerenciamento classes de usurios sem fio dentro
da comunidade escolar, HMS-IT pode permitir que autenticao e controle de
acesso disponibilizem diferentes nveis de acesso e suporte. Martino explica: Por
exemplo, no futuro, conectando aos perfis que executamos numa base de dados
Oracle, o sistema de gerenciamento sem fio poderia fazer uma chamada SQL de
forma que os estudantes obtivessem um documento ou apresentao; poder
alguma outra coisa. RBAC tambm pode ajudar no gerenciamento da largura de
banda para que estudantes baixando arquivos MP3 no derrubem o desempenho
da rede. Estender o RBAC sem fio para sistemas adicionais dentro do campus no
futuro disponibilizar privilgios de convidado e acesso a POP e correio
eletrnico para uma larga faixa de visitantes: desde estudantes em potencial e seus
pais, trabalhadores temporrios, at vendedores e fornecedores ... o homem do
FedEx que quer atualizar o seu inventrio a partir de um porto de carregamento

A pgina principal do projeto HMS Wireless Quad est disponvel em

http://www.hms.harvard.edu/it/wireless/index.html.

Outro trabalho que pode ser citado o de Frode Hansen and Vladimir Oleshchuk em
APPLICATION OF ROLE-BASED ACCESS CONTROL IN WIRELESS HEALTHCARE
INFORMATION SYSTEMS, onde a proposta a utilizao do SRBAC (Spatial RBAC)
uma extenso do modelo RBAC que incorpora a localizao do usurio na determinao e
ativao das permisses, conforme mencionado na seo 4.2.1 em sistemas da rea de
sade. Segundo os autores a idia central baseia-se na seguinte colocao:

Entretanto, em um ambiente de tratamento de sade sem fio, a permisso de um

usurio para acessar objetos no se basearia somente em seu papel desempenhado
na organizao, mas tambm num contexto relevante de segurana tal como a

52
 localizao. Assim, em uma configurao mvel, podemos atingir maior
flexibilidade definindo a poltica de segurana quando as permisses so atribudas
dinamicamente a um papel limitadas pela localizao na qual o usurio est
situado.

Ou seja, a permisso de um usurio para acessar objetos em um ambiente sem fio

aplicado rea de sade no se baseia unicamente no papel que ele desempenha na
organizao, mas tambm em outras variveis relevantes tais como a localizao.

No Brasil no foram encontradas referncias de trabalhos acadmicos semelhantes a

este.

53
 ANEXO II SOLUES COMERCIAIS DISPONVEIS

Os benefcios potenciais do RBAC tm sido reconhecidos por alguns fabricantes e

desenvolvedores de solues de segurana para redes. Alguns produtos tm incorporado
princpios do RBAC, porm o que se percebe hoje, mesmo j existindo um padro formal
proposto pelo NIST, que as implementaes foram adaptadas e baseadas em modelos
anteriores no padronizados, com algumas diferenas de terminologia, e nem todas as
caractersticas do modelo atual esto presentes, tornando mais difcil a tarefa de comparar as
solues disponveis e avaliar a sua efetividade para determinado ambiente.

A empresa Cisco Systems adota princpios do RBAC dentro do que chamam de NAC
(Network Admission Control http://www.cisco.com/go/nac) um conjunto de tecnologias
e solues que usa a infra-estrutura de rede para reforar a compatibilidade de qualquer
dispositivo com a poltica de segurana da organizao, permitindo autenticar, autorizar,
avaliar e remediar usurios e suas mquinas antes de conceder acesso rede. Especificamente,
um dos componentes do NAC, o Clean Access Server (CAS) e Clean Access Manager
(CAM), que implementa a funcionalidade RBAC para controle de acesso. O CAM um
servidor de administrao com console WEB de gerenciamento para o CAS. Esse soluo
pode ser utilizado tanto em redes sem fio quanto em redes tradicionais com cabos e
compreende outras caractersticas de segurana, opo de implementao dentro e fora da
banda, ferramentas de autenticao de usurios, controle de banda e de filtragem trfego
vinculados ao RBAC. Segundo o fabricante, as principais caractersticas as soluo so:

Arquitetura baseada em padres: HTTP, HTTPS, XML e Java Management

Extensions (JMX);

Autenticao de usurios: integrao com servidores de autenticao

existentes, incluindo Kerberos, LDAP, RADIUS e domnio Windows NT;

Integrao com concentrador VPN: integrao com concentradores VPN Cisco

(VPN 3000, ASA) provendo SSO (Single Sign-on);

Obedincia a polticas: permite configurar polticas de avaliao de

vulnerabilidade e remedio nos clientes por meio de um programa agente;

54
 Opo de implementao L2 ou L3 (nvel 2 ou 3): o CAS pode ser
implementado em nvel 2 (L2) de proximidade dos clientes ou nvel 3 (L3),
afastado por sub-redes;

Opo de implementao dentro da banda (in-band IB) ou fora da banda

(out-of-band OOB): o CAS pode ser colocado dentro da banda, obrigando
todo trfego dos clientes a passar por ele ou fora da banda, onde o trfego do
cliente s analisado na fase de avaliao de vulnerabilidade e remedio,
desviando aps a certificao para redes sem fio s o modo dentro da banda
pode ser utilizado;

Polticas de filtragem de trfego: efetua filtragem de trfego por endereo das

mquinas baseado em papis (role);

Controle de gerenciamento de banda: controla banda para downloads e uploads

dos usurios por papis;

Roaming: permite transferncia das conexes dos usurios pelas sub-redes

ligadas ao CAS;

Alta disponibilidade: suporta configurao de alta disponibilidade com mais de

um CAS para que outro servidor possa assumir as tarefas em caso de falha do
servidor principal.

No que se refere ao RBAC, especificamente, a implementao da Cisco Systems

parece no possuir as caractersticas mais avanadas do modelo, tais como hierarquias de
papis, restries e separao de tarefas. O mapeamento de um usurio para um papel pode
ser feito dinamicamente baseado no endereo fsico (MAC), endereo da sub-rede/IP da
mquina ou informao de login (atributos do servidor de autenticao: nome de usurio,
VLAN, etc.). O usurio mapeado para um nico papel de acordo com uma prioridade
(endereo MAC, IP, atributos), o que significa que se o endereo MAC se associa ao papel A
e o nome do usurio se associa ao papel B, o papel A o utilizado.

Outra empresa chamada Bluesocket Inc., que fabrica controllers (controladores -

http://www.bluesocket.com/products/controllerfamily.html) para redes sem fio, tambm
incorpora princpios RBAC em alguns de seus produtos. O BlueSecure 5.1 um pacote que

55
inclui controller, gerenciamento e APs onde o primeiro implementa funes RBAC para
controle de acesso. Segundo o fabricante, muitas caractersticas nicas do seu produto
derivam da sua capacidade em prover controle de acesso baseado em papis (RBAC). Os
papis podem ser mantidos localmente ou serem derivados de outras bases centrais de
autenticao (domnios Windows NT, Active Directory, LDAP, RADIUS). O controlador
tambm permite controle de banda e filtragem de trfego por papis.

A implementao RBAC da BlueSocket Inc. tambm parece no suportar as

caractersticas mais avanadas do modelo. Outras funcionalidades disponveis so:

Interoperabilidade com sistemas abertos;

Criptografia forte: suporte a IPSEC;

Monitoramento dos clientes e deteco de intruso: monitoramento em tempo

real do cliente, integrando o Check Points Integrity Clientless Security para
proteo contra vrus, worms, spyware, malware;

Segurana e QoS para VoIP.

56
 ANEXO III ESPECIFICAO FUNCIONAL DO RBAC

Appendix A: RBAC REQUIREMENTS SPECIFICATION

The RBAC Requirements Specification specifies administrative operations for the creation
and maintenance of RBAC element sets and relations; administrative review functions for
performing administrative queries; and system functions for creating and managing RBAC
attributes on user sessions and making access control decisions. Functions are defined with
sufficient precision to meet the needs of conformance testing and assurance, while providing
developers with design flexibility and the ability to incorporate additional features to meet the
needs of users.

The notation used in the formal specification of the RBAC requirements is basically a subset
of the Z notation. The only major change is the representation of a schema as follows:
Schema-Name (Declaration) Y Predicate; ; Predicate Z.
Most abstract data types and functions used in the formal specification are defined in Section 3, RBAC
Reference Model. New abstract data types and functions are introduced as needed. NAME is an abstract data type
whose elements represent identifiers of entities that may or may not be included in the RBAC system (roles,
users, sessions, etc.).

A.1 Requirements for Core RBAC

A.1-1 Administrative Commands for Core RBAC

AddUser
This command creates a new RBAC user. The command is valid only if the new user is not
already a member of the USERS data set. The USER data set is updated. The new user does
not own any session at the time of its creation. The following schema formally describes the
command AddUser:
AddUser ( user: NAME ) <
user USERS
USERS = USERS {user}
user _ sessions = user _ sessions {user a } >

DeleteUser
This command deletes an existing user from the RBAC database. The command is valid if
and only if the user to be deleted is a member of the USERS data set. The USERS and UA data
sets and the assigned_users function are updated. It is an implementation decision how to
proceed with the sessions owned by the user to be deleted. The RBAC system could wait for
such a session to terminate normally, or it could force its termination. Our presentation
illustrates the case when those sessions are forcefully terminated. The following schema
formally describes the command DeleteUser:

57
 DeleteUser (user: NAME ) <
user USERS
[s SESSIONS s user _ sessions(user ) DeleteSession( s)]
UA = UA \ {r: ROLES user a r}
assigned _ users = {r: ROLES r a (assigned _ users(r ) \ {user})}
USERS = USERS \ {user} >

AddRole
This command creates a new role. The command is valid if and only if the new role is not
already a member of the ROLES data set. The ROLES data set and the functions
assigned_users and assigned_permissions are updated. Initially, no user or permission is
assigned to the new role. The following schema formally describes the command AddRole:
AddRole(role: NAME ) <
role ROLES
ROLES = ROLES {role}
assigned _ users = assigned _ users {role a }
assigned _ permissions = assigned _ permissions {role a } >

DeleteRole
This command deletes an existing role from the RBAC database. The command is valid if and
only if the role to be deleted is a member of the ROLES data set. It is an implementation
decision how to proceed with the sessions in which the role to be deleted is active. The RBAC
system could wait for such a session to terminate normally, it could force the termination of
that session, or it could delete the role from that session while allowing the session to
continue. Our presentation illustrates the case when those sessions are forcefully terminated.
DeleteRole(role: NAME ) <
role ROLES
[ s SESSIONS role session _ roles( s) DeleteSession( s)]
UA = UA \ {u: USERS u a role}
assigned _ users = assigned _ users \ {role a asigned _ users(role)}
PA = PA \ {op: OPS , obj: OBJS (op, obj ) a role}
assigned _ permissions = assigned _ permissions \ {role a assigned _ permissions(role)}
ROLES = ROLES \ {role} >

AssignUser
This command assigns a user to a role. The command is valid if and only if the user is a
member of the USERS data dset, the role is a member of the ROLES data set, and the user is
not already assigned to the role. The data set UA and the function assigned_users are updated
to reflect the assignment. The following schema formally describes the command:
AssignUser (user , role: NAME ) <
user USERS ; role ROLES ; ( user a role) UA
UA = UA {user a role}
assigned _ users = assigned _ users \ {role a assigned _ users(role)}
{role a ( assigned _ users(role) {user})} >

58
DeassignUser
This command deletes the assignment of the user user to the role role. The command is valid
if and only if the user is a member of the USERS data set, the role is a member of the ROLES
data set, and the user is assigned to the role.
It is an implementation decision how to proceed with the sessions in which the session user is
user and one of his/her active roles is role. The RBAC system could wait for such a session to
terminate normally, or could force its termination, or could inactivate the role. Our
presentation illustrates the case when those sessions are forcefully terminated. The following
schema formally describes the command DeassignUser:
DeassignUser (user , role: NAME ) <
user USERS ; role ROLES ; (user a role) UA
[s: SESSIONS s user _ sessions(user ) role session _ roles( s) DeleteSession( s)]
UA = UA \ {user a role}
assigned _ users = assigned _ users \ {role a asigned _ users(role)}
{role a (asigned _ users(role) \ {user})} >

GrantPermission
This command grants a role the permission to perform an operation on an object to a role. The
command may be implemented as granting permissions to a group corresponding to that role,
i.e., setting the access control list of the object involved.
The command is valid if and only if the pair (operation, object) represents a permission, and
the role is a member of the ROLES data set. The following schema formally defines the
command:
GrantPermission(object , operation, role: NAME ) <
(operation, object ) PERMS ; role ROLES
PA = PA {(operation, object ) a role}
assigned _ permissions = assigned _ permissions \ {role a assigned _ permissions(roles)}
{role a (assigned _ permissions(role) {(operation, object )})} >

RevokePermission
This command revokes the permission to perform an operation on an object from the set of
permissions assigned to a role. The command may be implemented as revoking permissions
from a group corresponding to that role, i.e., setting the access control list of the object
involved.
The command is valid if and only if the pair (operation, object) represents a permission, the
role is a member of the ROLES data set, and the permission is assigned to that role. The
following schema formally describes the command:
RevokePermission( operation, object , role: NAME ) <
(operation, object ) PERMS ; role ROLES ; ((operation, object ) a role) PA
PA = PA \ {(operation, object ) a role}
assigned _ permissions = assigned _ permissions \ {role a assigned _ permissions(role)}
{role a ( assigned _ permissions(role) \ {(operation, object )})} >

A.1-2 System Functions for Core RBAC

CreateSession(user, session)
This function creates a new session with a given user as owner and an active role set. The
function is valid if and only if:
- the user is a member of the USERS data set, and

59
- the active role set is a subset of the roles assigned to that user. In a RBAC
implementation, the sessions active roles might actually be the groups that represent
those roles.
The following schema formally describes the function. The session parameter, which
represents the session identifier, is actually generated by the underlying system.
CreateSession(user: NAME ; ars:2 NAMES ; session: NAME ) <
user USERS ; ars {r: ROLES |(user a r ) UA}; session SESSIONS
SESSIONS = SESSIONS {session}
user _ sessions = user _ sessions \ {user a user _ sessions(user )}
{user a (user _ sessions(user ) {session})}
session _ roles = session _ roles {session a ars} >

DeleteSession(user, session)
This function deletes a given session with a given owner user. The function is valid if and
only if the session identifier is a member of the SESSIONS data set, the user is a member of
the USERS data set, and the session is owned by the given user. The following schema
formally describes the function:
DeleteSession(user , session: NAME ) <
user USERS ; session SESSIONS ; session user _ sessions(user )
user _ sessions = user _ sessions \ {user a user _ sessions( user )}
{user a (user _ sessions( user ) \ {session})}
session _ roles = session _ roles \ {session a session _ roles( session)}
SESSIONS = SESSIONS \ {session} >

AddActiveRole
This function adds a role as an active role of a session whose owner is a given user. The
function is valid if and only if:
- the user is a member of the USERS data set, and
- the role is a member of the ROLES data set, and
- the session identifier is a member of the SESSIONS data set, and
- the role is assigned to the user, and
- the session is owned by that user.
In an implementation, the new active role might be a group that corresponds to that role. The
following schema formally describes the function:
AddActiveRole( user , session, role: NAME ) <
user USERS ; session SESSIONS ; role ROLES ; session user _ sessions( user )
(user a role) UA; role session _ roles( session)
session _ roles = session _ roles \ {session a session _ roles( session)}
{session a ( session _ roles( session) {role})} >

DropActiveRole
This function deletes a role from the active role set of a session owned by a given user. The
function is valid if and only if the user is a member of the USERS data set, the session
identifier is a member of the SESSIONS data set, the session is owned by the user, and the role
is an active role of that session. The following schema formally describes this function:

60
 DropActiveRole(user , session, role: NAME ) <
user USERS ; role ROLES ; session SESSIONS
session user _ sessions(user ); role session _ roles( session)
session _ roles = session _ roles \ {session a session _ roles( session)}
{session a ( session _ roles( session) \ {role}) >

CheckAccess
This function returns a Boolean value meaning whether the subject of a given session is
allowed or not to perform a given operation on a given object. The function is valid if and
only if the session identifier is a member of the SESSIONS data set, the object is a member of
the OBJS data set, and the operation is a member of the OPS data set. The sessions subject
has the permission to perform the operation on that object if and only if that permission is
assigned to (at least) one of the sessions active roles. An implementation might use the
groups that correspond to the subjects active roles and their permissions as registered in the
objects access control list. The following schema formally describes the function:
CheckAccess( session, operation, object: NAME ; out result: BOOLEAN ) <
session SESSIONS ; operation OPS ; object OBJS
result = ( r: ROLES r session _ roles( session) ((operation, object ) a r ) PA) >

A.1-3 Review Functions for Core RBAC

AssignedUsers
This function returns the set of users assigned to a given role. The function is valid if and only
if the role is a member of the ROLES data set. The following schema formally describes the
function:
AssignedUsers(role: NAME ; out result:2USERS ) <
role ROLES
result = {u: USERS |(u a role) UA} >

AssignedRoles
This function returns the set of roles assigned to a given user. The function is valid if and only
if the user is a member of the USERS data set. The following schema formally describes the
function:
AssignedRoles(user: NAME ; result:2 ROLES ) <
user USERS
result = {r: ROLES |( user a r ) UA} >

A.1-4 Advanced Review Functions for Core RBAC

RolePermissions
This function returns the set of permissions (op, obj) granted to a given role. The function is
valid if and only if the role is a member of the ROLES data set. The following schema
formally describes the function:
RolePermissions(role: NAME ; result:2 PERMS ) <
role ROLES
result = {op: OPS ; obj: OBJS |((op, obj ) a role) PA} >

61
UserPermissions
This function returns the permissions a given user gets through his/her assigned roles. The
function is valid if and only if the user is a member of the USERS data set. The following
schema formally describes this function:
UserPermissions(user: NAME ; result:2 PERMS ) <
user USERS
result = {r: ROLES ; op: OPS ; obj: OBJS |(user a r ) UA ((op, obj ) a r ) PA (op, obj )} >

SessionRoles
This function returns the active roles associated with a session. The function is valid if and
only if the session identifier is a member of the SESSIONS data set. The following schema
formally describes this function:
SessionRoles( session: NAME ; out result:2 ROLES ) <
session SESSIONS
result = session _ roles( session) >

SessionPermissions
This function returns the permissions of the session session, i.e., the permissions assigned to
its active roles. The function is valid if and only if the session identifier is a member of the
SESSIONS data set. The following schema formally describes this function:
SessionPermissions( session: NAME ; out result:2 PERMS ) <
session SESSIONS
result = {r: ROLES ; op OPS ; obj OBJS | r session _ roles( session) ((op, obj ) a r ) PA
(op, obj )} >

A.2 Requirements for Hierarchical RBAC

A.2a General Role Hierarchies

A.2a-1 Administrative Commands for General Role Hierarchies

All functions of section A.1-1 remain valid. In addition, this section defines the following
new, specific functions:

AddInheritance
This commands establishes a new immediate inheritance relationship r_asc r_desc between existing roles
r_asc, r_desc. The command is valid if and only if r_asc and r_desc are members of the ROLES data set, r_asc
is not an immediate ascendant of r_desc, and r_desc does not properly inherit r_asc (in order to avoid cycle
creation). The following schema uses the notations:

==
>> ==
to formally describes the command:
AddInheritance(r _ asc, r _ desc: NAME ) <
r _ asc ROLES ; r _ desc ROLES ; (r _ asc >> r _ desc); (r _ desc r _ asc)
= {r , q: ROLES | r r _ asc r _ desc q r a q} >

DeleteInheritance
This command deletes an existing immediate inheritance relationship r_asc r_desc. The command is valid if
62
and only if the roles r_asc and r_desc are members of the ROLES data set, and r_asc is an immediate ascendant
of r_desc. The new inheritance relation is computed as the reflexive-transitive closure of the immediate
inheritance relation resulted after deleting the relationship r_asc r_desc. The following schema formally
describes this command:
DeleteInheritance( r _ asc, r _ desc: NAME ) <
r _ asc ROLES ; r _ desc ROLES ; r _ asc >> r _ desc
= ( >> \ {r _ asc a r _ desc}) * >

AddAscendant
This commands creates a new role r_asc, and inserts it in the role hierarchy as an immediate ascendant of the
existing role r_desc. The command is valid if and only if r_asc is not a member of the ROLES data set, and
r_desc is a member of the ROLES data set. Note that the validity conditions are verified in the schemas AddRole
and AddInheritance, referred to by AddAscendant.
AddAscendant (r _ asc, r _ desc: NAME ) <
AddRole(r _ asc)
AddInheritance(r _ asc, r _ desc) >

AddDescendant
This commands creates a new role r_desc, and inserts it in the role hierarchy as an immediate descendant of the
existing role r_asc. The command is valid if and only if r_desc is not a member of the ROLES data set, and
r_asc is a member of the ROLES data set. Note that the validity conditions are verified in the schemas AddRole
and AddInheritance, referred to by AddDescendant.

AddDescendant (r _ asc, r _ desc: NAME ) <

AddRole(r _ desc)
AddInheritance(r _ asc, r _ desc) >

A.2a-2 System Functions for General Role Hierarchies

This section redefines the functions CreateSession and AddActiveRole of section A.1-2. The
other functions of section A.1-2 remain valid.

CreateSession(user, session)
This function creates a new session with a given user as owner, and a given set of active roles.
The function is valid if and only if:
- the user is a member of the USERS data set, and
- the active role set is a subset of the roles authorized for that user. Note that if a role is
active for a session, its descendants or ascendants are not necessarily active for that
session. In a RBAC implementation, the sessions active roles might actually be the
groups that represent those roles.
The following schema formally describes the function. The parameter session, which
identifies the session, is actually generated by the underlying system.
CreateSession(user: NAME ; ars:2 NAME ; session: NAME ) <
user USERS ; ars {r , q: ROLES |( user a q ) UA q r r}; session SESSIONS
SESSIONS = SESSIONS {session}
user _ sessions = user _ sessions \ {user a user _ sessions( user )}
{user a (user _ sessions(user ) {session})}
session _ roles = session _ roles {session a ars} >

63
AddActiveRole
This function adds a role as an active role of a session whose owner is a given user. The
function is valid if and only if:
- the user is a member of the USERS data set, and
- the role is a member of the ROLES data set, and
- the session identifier is a member of the SESSIONS data set, and
- the user is authorized to that role, and
- the session is owned by that user.
The following schema formally describes the function:
AddActiveRole( user , session, role: NAME ) <
user USERS ; session SESSIONS ; role ROLES ; session user _ sessions(user )
user authorized _ users(role); role session _ roles( session)
session _ roles = session _ roles \ {session a session _ roles( session)}
{session a ( session _ roles( session) {role})} >

A.2a-3 Review Functions for General Role Hierarchies

All functions of section A.1-3 remain valid. In addition, this section defines the following
review functions:

AuthorizedUsers
This function returns the set of users authorized to a given role, i.e., the users that are assigned
to a role that inherits the given role. The function is valid if and only if the given role is a
member of the ROLES data set. The following schema formally describes the function:
AuthorizedUsers(role: NAME ; out result:2USERS ) <
role ROLES
result = authorized _ users(role) >

AuthorizedRoles
This function returns the set of roles authorized for a given user. The function is valid if and
only if the user is a member of the USERS data set. The following schema formally describes
the function:
AuthorizedRoles(user: NAME ; result:2 ROLES ) <
user USERS
result = {r , q: ROLES |(user a q ) UA q r} >

A.2a-4 Advanced Review Functions for General Role Hierarchies

This section redefines the functions RolePermissions and UserPermissions of section A.1-4.
All other functions of section A.1-4 remain valid.

RolePermissions
This function returns the set of all permissions (op, obj), granted to or inherited by a given
role. The function is valid if and only if the role is a member of the ROLES data set. The
following schema formally describes the function:

64
 AllPermissions(role: NAME ; result:2 PERMS ) <
role ROLES
result = {q: ROLES ; op: OPS ; obj: OBJS |( role q ) (( op, obj ) a role) PA (op, obj )} >

UserPermissions
This function returns the set of permissions a given user gets through his/her authorized roles.
The function is valid if and only if the user is a member of the USERS data set. The following
schema formally describes this function:
UserPermissions(user: NAME ; result:2 PERMS ) <
user USERS
result = {r , q: ROLES ; op: OPS ; obj: OBJS |(user a q ) UA (q r ) ((op, obj ) a r ) PA
(op, obj )} >

A.2b Limited Role Hierarchies

A.2b-1 Administrative Commands for Limited Role Hierarchies

This section redefines the function AddInheritance of section A.2a-1. All other functions of
section A.2a-1 remain valid.

AddInheritance
This commands establishes a new immediate inheritance relationship r_asc r_desc between existing roles
r_asc, r_desc. The command is valid if and only if r_asc and r_desc are members of the ROLES data set, r_asc
has no descendants, and r_desc does not properly inherit r_asc (in order to avoid cycle creation). The following
schema uses the notations:

==
>> ==
to formally describes the command:
AddInheritance(r _ asc, r _ desc: NAME ) <
r _ asc ROLES ; r _ desc ROLES ; r ROLES (r _ asc >> r ); (r _ desc r _ asc)
= {r , q: ROLES | r r _ asc r _ desc q r a q} >

A.2b-2 System Functions for Limited Role Hierarchies

All functions of section A.2a-2 remain valid.

A.2b-3 Review Functions for Limited Role Hierarchies

All functions of section A.2a-3 remain valid.

A.2b-4 Advanced Review Functions for Limited Role Hierarchies

All functions of section A.2a-4 remain valid.

A.3 Requirements for Static Separation of Duty (SSD) Relations

The static separation of duty property, as defined in the model, uses a collection SSD of pairs of a role set and an
associated cardinality. We define the new data type SSD, which in an implementation could be the set of names
used to identify the pairs in the collection.
65
The functions ssd_set and respectively ssd_card are used to obtain the role set and the
associated cardinality from each SSD pair:
ssd _ set: SSD 2 ROLES
ssd _ card : SSD N
ssd SSD ssd _ card ( ssd ) 2 ssd _ card ( ssd ) | ssd _ set ( ssd )|

A.3a SSD Relations

A.3a-1 Administrative commands for SSD Relations

This section redefines the function AssignUser of section A.1-1 and defines a set of new,
specific functions. The other functions of section A.1-1 remain valid.

AssignUser
The AssignUser command replaces the command with the same name of Core RBAC. This
command assigns a user to a role. The command is valid if and only if:
- the user is a member of the USERS data set, and
- the role is a member of the ROLES data set, and
- the user is not already assigned to the role, and
- the SSD constraints are satisfied after assignment.
The data set UA and the function assigned_users are updated to reflect the assignment. The
following schema formally describes the command:
AssignUser (user , role: NAME ) <
user USERS ; role ROLES ; (user a role) UA
ssd SSD I (assigned _ users(r ) us) =
r subset
subset ssd _ set ( ssd )
|subset |= ssd _ card ( ssd )
us = if r = role then {user } else

UA = UA {user a role}
assigned _ users = assigned _ users \ {role a assigned _ users(role)}
{role a (assigned _ users(role) {user})} >

CreateSsdSet
This command creates a named SSD set of roles and sets the cardinality n of its subsets that
cannot have common users. The command is valid if and only if:
- the name of the SSD set is not already in use
- all the roles in the SSD set are members of the ROLES data set
- n is a natural number greater than or equal to 2 and less than or equal to the cardinality of
the SSD role set, and
- the SSD constraint for the new role set is satisfied.
The following schema formally describes this command:
CreateSsdSet ( set _ name: NAME ; role _ set:2 NAMES ; n: N) <
set _ name SSD; (n 2) (n | role _ set |); role _ set ROLES
I assigned _ users(r ) =
r subset
subset role _ set
|subset |= n

SSD = SSD {set _ name}

ssd _ set = ssd _ set {set _ name a role _ set}
ssd _ card = ssd _ card {set _ name a n} >

66
AddSsdRoleMember
This command adds a role to a named SSD set of roles. The cardinality associated with the
role set remains unchanged. The command is valid if and only if:
- the SSD role set exists, and
- the role to be added is a member of the ROLES data set but not of a member of the SSD
role set, and
- the SSD constraint is satisfied after the addition of the role to the SSD role set.
The following schema formally describes the command:
AddSsdRoleMember ( set _ name: NAME ; role: NAME ) <
set _ name SSD; role ROLES ; role ssd _ set ( set _ name)
I assigned _ users(r ) =
r subset
subset ssd _ set ( set _ name ) {role}
|subset |= n

ssd _ set = ssd _ set \ {set _ name a ssd _ set ( set _ name)}
{set _ name a ( ssd _ set ( set _ name) {role})} >

DeleteSsdRoleMember
This command removes a role from a named SSD set of roles. The cardinality associated with
the role set remains unchanged. The command is valid if and only if:
- the SSD role set exists, and
- the role to be removed is a member of the SSD role set, and
- the cardinality associated with the SSD role set is less than the number of elements of the
SSD role set.
Note that the SSD constraint should be satisfied after the removal of the role from the SSD
role set. The following schema formally describes the command:
DeleteSsdRoleMember ( set _ name: NAME ; role: NAME ) <
set _ name SSD; role ssd _ set ( set _ name); ssd _ card ( set _ name) < | ssd _ set ( set _ name)|
ssd _ set = ssd _ set \ {set _ name a ssd _ set ( set _ name)}
{set _ name a ( ssd _ set ( set _ name) \ {role})} >

DeleteSsdSet
This command deletes a SSD role set completely. The command is valid if and only if the
SSD role set exists. The following schema formally describes the command:
DeleteSsdSet ( set _ name: NAME ) <
set _ name SSD; ssd _ card = ssd _ card \ {set _ name a ssd _ card ( set _ name)}
ssd _ set = ssd _ set \ {set _ name a ssd _ set ( set _ name)}
SSD = SSD \ {set _ name} >

SetSsdSetCardinality
This command sets the cardinality associated with a given SSD role set. The command is
valid if and only if:
- the SSD role set exists, and
- the new cardinality is a natural number greater than or equal to 2 and less than or equal to
the number of elements of the SSD role set, and
- the SSD constraint is satisfied after setting the new cardinality.
The following schema formally describes the command:

67
 SetSsdSetCardinality ( set _ name: NAME ; n: N) <
set _ name SSD; (n 2) (n | ssd _ set ( set _ name)|)
I assigned _ users(r ) =
r subset
subset ssd _ set ( set _ name )
|subset |= n

ssd _ card = ssd _ card \ {set _ name a ssd _ card ( set _ name)} {set _ name a n} >

A.3a-2 System Functions for SSD

All functions in section A.1-2 remain valid.

A.3a-3 Review Functions for SSD

All functions in section A.1-3 remain valid. In addition, this section defines the following
functions:

SsdRoleSets
This function returns the list of all SSD role sets. The following schema formally describes
the function:
SsdRoleSets(out result:2 NAME ) < result = SSD >

SsdRoleSetRoles
This function returns the set of roles of a SSD role set. The function is valid if and only if the
role set exists. The following schema formally describes the function:
SsdRoleSetRoles( set _ name: NAME ; out result:2 ROLES ) <
set _ name SSD
result = ssd _ set ( set _ name) >

SsdRoleSetCardinality
This function returns the cardinality associated with a SSD role set. The function is valid if
and only if the role set exists. The following schema formally describes the function:
SsdRoleSetCardinality ( set _ name: NAME ; out result: N) <
set _ name SSD
result = ssd _ card ( set _ name) >

A.3a-4 Advanced Review Functions for SSD

All functions in section A.1-4 remain valid.

A.3b SSD Relations with General Role Hierarchies

A.3b-1 Administrative Commands for SSD with General Role Hierarchies

This section redefines the functions AssignUser and AddInheritance of section A.2a-1, and
the functions CreateSsdSet, AddSsdRoleMember, SetSsdSetCardinality of section A.3a-1.
The other functions of sections A.2a-1 and A.3a-1 remain valid.

68
AssignUser
The command AssignUser replaces the command with the same name from Core RBAC with
Static Separation of Duties. This command assigns a user to a role. The command is valid if
and only if:
- the user is a member of the USERS data set, and
- the role is a member of the ROLES data set, and
- the user is not already assigned to the role, and
- the SSD constraints are satisfied after assignment.
The data set UA and the function assigned_users are updated to reflect the assignment. The
following schema formally describes the command:
AssignUser (user , role: NAME ) <
user USERS ; role ROLES ; (user a role) UA
ssd SSD I (authorized _ users(r ) au) =
r subset
subset ssd _ set ( ssd )
|subset |= ssd _ card ( ssd )
au = if r = role then {user } else

UA = UA {user a role}
assigned _ users = assigned _ users \ {role a assigned _ users(role)}
{role a ( assigned _ users(role) {user})} >

AddInheritance
This commands establishes a new immediate inheritance relationship r_asc r_desc between existing roles
r_asc, r_desc. The command is valid if and only if:
- r_asc and r_desc are members of the ROLES data set, and
- r_asc is not an immediate ascendant of r_desc, and
- r_desc does not properly inherit r_asc, and
the SSD constraints are satisfied after establishing the new inheritance.
The following schema uses the notations:
==
>> ==
to formally describes the command:
AddInheritance(r _ asc, r _ desc: NAME ) <
r _ asc ROLES ; r _ desc ROLES ; (r _ asc >> r _ desc); (r _ desc r _ asc)
ssd SSD I (authorized _ users(r ) au) =
r subset
subset ssd _ set ( ssd )
|subset |= ssd _ card ( ssd )
au = if r = r _ desc then authorized _ users ( r _ asc ) else

= {r , q: ROLES | r r _ asc r _ desc q r a q} >

CreateSsdSet
This command creates a named SSD set of roles and sets the associated cardinality n of its
subsets that cannot have common users. The command is valid if and only if:
- the name of the SSD set is not already in use
- all the roles in the SSD set are members of the ROLES data set
- n is a natural number greater than or equal to 2 and less than or equal to the cardinality of
the SSD role set, and
- the SSD constraint for the new role set is satisfied.
The following schema formally describes this command:

69
 CreateSsdSet ( set _ name: NAME ; role _ set:2 NAMES ; n: N) <
set _ name SSD; (n 2) (n | role _ set |); role _ set ROLES
I authorized _ users(r ) =
r subset
subset role _ set
|subset |= n

SSD = SSD {set _ name}

ssd _ set = ssd _ set {set _ name a role _ set}
ssd _ card = ssd _ card {set _ name a n} >

AddSsdRoleMember
This command adds a role to a named SSD set of roles. The cardinality associated with the
role set remains unchanged. The command is valid if and only if:
- the SSD role set exists, and
- the role to be added is a member of the ROLES data set but not of a member of the SSD
role set, and
- the SSD constraint is satisfied after the addition of the role to the SSD role set.
The following schema formally describes the command:
AddSsdRoleMember ( set _ name: NAME ; role: NAME ) <
set _ name SSD; role ROLES ; role ssd _ set ( set _ name)
I authorized _ users(r ) =
r subset
subset ssd _ set ( set _ name ) {role}
|subset |= n

ssd _ set = ssd _ set \ {set _ name a ssd _ set ( set _ name)}
{set _ name a ( ssd _ set ( set _ name) {role})} >

SetSsdSetCardinality
This command sets the cardinality associated with a given SSD role set. The command is
valid if and only if:
- the SSD role set exists, and
- the new cardinality is a natural number greater than or equal to 2 and less than or equal to
the number of elements of the SSD role set, and
- the SSD constraint is satisfied after setting the new cardinality.
The following schema formally describes the command:
SetSsdSetCardinality ( set _ name: NAME ; n: N) <
set _ name SSD; (n 2) (n | ssd _ set ( set _ name)|)
I authorized _ users(r ) =
r subset
subset ssd _ set ( set _ name )
|subset |= n

ssd _ card = ssd _ card \ {set _ name a ssd _ card ( set _ name)} {set _ name a n} >

A.3b-2 System Functions for SSD with General Role Hierarchies

All functions of section A.2a-2 remain valid.

A.3b-3 Review Functions for SSD with General Role Hierarchies

All functions of sections A.2a-3 and A.3a-3 remain valid.

A.3b-4 Advanced Review Functions for SSD with General Role Hierarchies

70
All functions of section A.2a-4 remain valid.

A.3c SSD Relations with Limited Role Hierarchies

A.3c-1 Administrative Commands for SSD with Limited Role Hierarchies

This section redefines the function AddInheritance of section A.3b-1. All other functions of
section A.3b-1 remain valid.

AddInheritance
This commands establishes a new immediate inheritance relationship r_asc r_desc between existing roles
r_asc, r_desc. The command is valid if and only if r_asc and r_desc are members of the ROLES data set, r_asc
has no descendants, and r_desc does not properly inherit r_asc (in order to avoid cycle creation). The following
schema uses the notations:

==
>> ==
to formally describes the command:
AddInheritance(r _ asc, r _ desc: NAME ) <
r _ asc ROLES ; r _ desc ROLES ; r ROLES ( r _ asc >> r ); (r _ desc r _ asc)
ssd SSD I (authorized _ users(r ) au) =
r subset
subset ssd _ set ( ssd )
|subset |= ssd _ card ( ssd )
au = if r = r _ desc then authorized _ users ( r _ asc ) else

= {r , q: ROLES | r r _ asc r _ desc q r a q} >

A.3c-2 System Functions for SSD with Limited Role Hierarchies

All functions of section A.2a-2 remain valid.

A.3c-3 Review Functions for SSD with Limited Role Hierarchies

All functions of sections A.2a-3 and A.3a-3 remain valid.

A.3c-4 Advanced Review Functions for SSD with Limited Role Hierarchies

All functions of sections A.2a-4 remain valid.

A.4 Requirements for Dynamic Separation of Duties (DSD) Relations

The dynamic separation of duty property, as defined in the model, uses a collection DSD of pairs of a role set
and an associated cardinality. We define the new data type DSD, which in an implementation could be the set of
names used to identify the pairs in the collection.
The functions dsd_set and respectively dsd_card are used to obtain the role set and the associated cardinality
from each DSD pair:

71
 dsd _ set : DSD 2 ROLES
dsd _ card : DSD N
dsd SSD dsd _ card ( dsd ) 2 dsd _ card ( dsd ) | dsd _ set ( dsd )|

4.4a DSD Relations

A.4a-1 Administrative Commands for DSD Relations

All functions of section A.1-1 remain valid. In addition, this section defines the following
functions:

CreateDsdSet
This command creates a named DSD set of roles and sets an associated cardinality n. The
DSD constraint stipulates that the DSD role set cannot contain n or more roles simultaneously
active in the same session.
The command is valid if and only if:
- the name of the DSD set is not already in use
- all the roles in the DSD set are members of the ROLES data set
- n is a natural number greater than or equal to 2 and less than or equal to the cardinality of
the DSD role set, and
- the DSD constraint for the new role set is satisfied.
The following schema formally describes this command:
CreateDsdSet ( set _ name: NAME ; role _ set:2 NAMES ; n: N) <
set _ name DSD; (n 2) (n | role _ set |); role _ set ROLES
s: SESSIONS ; role _ subset:2 role _ set role _ subset session _ roles( s) | role _ subset |< n
DSD = DSD {set _ name}
dsd _ set = dsd _ set {set _ name a role _ set}
dsd _ card = dsd _ card {set _ name a n} >

AddDsdRoleMember
This command adds a role to a named DSD set of roles. The cardinality associated with the
role set remains unchanged. The command is valid if and only if:
- the DSD role set exists, and
- the role to be added is a member of the ROLES data set but not of a member of the DSD
role set, and
- the DSD constraint is satisfied after the addition of the role to the DSD role set.
The following schema formally describes the command:
AddDsdRoleMember ( set _ name: NAME ; role: NAME ) <
set _ name DSD; role ROLES ; role dsd _ set ( set _ name)
s: SESSIONS ; role _ subset:2 dsd _ set ( set _ name ) {role}
role _ subset session _ roles( s) | role _ subset | < dsd _ card ( set _ name)
dsd _ set = dsd _ set \ {set _ name a dsd _ set ( set _ name)}
{set _ name a (dsd _ set ( set _ name) {role})} >

DeleteDsdRoleMember
This command removes a role from a named DSD set of roles. The cardinality associated with
the role set remains unchanged. The command is valid if and only if:
- the DSD role set exists, and
- the role to be removed is a member of the DSD role set, and
72
- the cardinality associated with the DSD role set is less than the number of elements of the
DSD role set.
Note that the DSD constraint should be satisfied after the removal of the role from the DSD
role set. The following schema formally describes the command:
DeleteDsdRoleMember ( set _ name: NAME ; role: NAME ) <
set _ name DSD; role dsd _ set ( set _ name); dsd _ card ( set _ name) < | dsd _ set ( set _ name)|
dsd _ set = dsd _ set \ {set _ name a dsd _ set ( set _ name)}
{set _ name a (dsd _ set ( set _ name) \ {role})} >

DeleteDsdSet
This command deletes a DSD role set completely. The command is valid if and only if the
DSD role set exists. The following schema formally describes the command:
DeleteDsdSet ( set _ name: NAME )
{
set _ name DSD
dsd _ card = dsd _ card \ {set _ name a dsd _ card ( set _ name)}
dsd _ set = dsd _ set \ {set _ name a dsd _ set ( set _ name)}
DSD = DSD \ {set _ name}
}

SetDsdSetCardinality
This command sets the cardinality associated with a given DSD role set. The command is
valid if and only if:
- the DSD role set exists, and
- the new cardinality is a natural number greater than or equal to 2 and less than or equal to
the number of elements of the DSD role set, and
- the DSD constraint is satisfied after setting the new cardinality.
The following schema formally describes the command:
SetDsdSetCardinality ( set _ name: NAME ; n: N) <
set _ name DSD; (n 2) (n | dsd _ set ( set _ name)|)
s: SESSIONS ; role _ subset:2 dsd _ set ( set _ name)
role _ subset session _ roles( s) | role _ subset | < n
dsd _ card = dsd _ card \ {set _ name a dsd _ card ( set _ name)} {set _ name a n} >

A.4a-2 System Functions for DSD Relations

This section redefines the functions CreateSession and AddActiveRole of section A.1-2. The
other functions of section A.1-2 remain valid.

CreateSession
This function creates a new session whose owner is the user user and a given active role set.
The function is valid if and only if:
- the user is a member of the USERS data set, and
- the sessions active role set is a subset of the roles assigned to the sessions owner, and
- the sessions active role set satisfies the DSD constraints.
The following schema formally describes the function. The session parameter, which
identifies the new session, is actually generated by the underlying system.

73
 CreateSession(user: NAME ; ars:2 NAME ; session: NAME ) <
user USERS ; ars {r: ROLES |(user a r ) UA}; session SESSIONS
dset: DSD; rset:2 NAME
rset dsd _ set (dset ) rset ars | rset | < dsd _ card ( dset )
SESSIONS = SESSIONS {session}
user _ sessions = user _ sessions \ {user a user _ sessions( user )}
{user a (user _ sessions(user ) {session})}
session _ roles = session _ roles {session a ars} >
AddActiveRole
This function adds a role as an active role of a session whose owner is a given user. The
function is valid if and only if:
- the user is a member of the USERS data set, and
- the role is a member of the ROLES data set, and
- the session identifier is a member of the SESSIONS data set, and
- the role is assigned to the user, and
- the old active role set completed with the role to be activated satisfies the DSD
constraints, and
- the session is owned by that user.
The following schema formally describes the function:
AddActiveRole(user , session, role: NAME ) <
user USERS ; session SESSIONS ; role ROLES ; session user _ sessions(user )
user assigned _ users(role); role session _ roles( session)
dset: DSD; rset:2 NAME
rset dsd _ set (dset ) rset session _ roles( session) {role} | rset | < dsd _ card (dset )
session _ roles = session _ roles \ {session a session _ roles( session)}
{session a ( session _ roles( session) {role})} >

A.4a-3 Review Functions for DSD Relations

All functions of sections A.1-3 remain valid. In addition, this section defines new, specific
functions.

DsdRoleSets
This function returns the list of all DSD role sets. The following schema formally describes
the function:
DsdRoleSets(out result:2 NAME ) < result = DSD >

DsdRoleSetRoles
This function returns the set of roles of a DSD role set. The function is valid if and only if the
role set exists. The following schema formally describes the function:
DsdRoleSetRoles( set _ name: NAME ; out result:2 ROLES ) <
set _ name DSD
result = dsd _ set ( set _ name) >

74
DsdRoleSetCardinality
This function returns the cardinality associated with a DSD role set. The function is valid if
and only if the role set exists. The following schema formally describes the function:
DsdRoleSetCardinality( set _ name: NAME ; out result: N) <
set _ name DSD
result = dsd _ card ( set _ name) >

A.4a-4 Advanced Review Functions for DSD Relations

All functions of sections A.1-4 remain valid.

A.4b DSD Relations with Role Hierarchies

A.4b-1 Administrative commands for DSD Relations with General Role Hierarchies

All functions of sections A.4a-1 and A.2a-1 remain valid.

A.4b-2 System Functions for DSD Relations with General Role Hierarchies

This section redefines the functions CreateSession and AddActiveRole of section A.1-2 (or
A.2a-2). All other functions of section A.1-2 remain valid.

CreateSession
This function creates a new session whose owner is the user user and a given active role set.
The function is valid if and only if:
- the user is a member of the USERS data set, and
- the sessions active role set is a subset of the roles authorized for the sessions owner, and
- the sessions active role set satisfies the DSD constraints.
The underlying system generates a new session identifier, which is included in the SESSIONS
data set.
The following schema formally describes the function:
CreateSession(user: NAME ; ars:2 NAME ; session: NAME ) <
user USERS ; ars {r , q: ROLES |(user a q ) UA q r r}; session SESSIONS
dset: DSD; rset:2 NAME
rset dsd _ set (dset ) rset ars | rset | < dsd _ card ( dset )
SESSIONS = SESSIONS {session}
user _ sessions = user _ sessions \ {user a user _ sessions(user )}
{user a (user _ sessions(user ) {session})}
session _ roles = session _ roles {session a ars} >
AddActiveRole
This function adds a role as an active role of a session whose owner is a given user. The
function is valid if and only if:
- the user is a member of the USERS data set, and
- the role is a member of the ROLES data set, and
- the session identifier is a member of the SESSIONS data set, and
- the role is authorized for that user, and

75
- the old active role set completed with the role to be activated satisfies the DSD
constraints, and
- the session is owned by that user.
The following schema formally describes the function:
AddActiveRole(user , session, role: NAME ) <
user USERS ; session SESSIONS ; role ROLES ; session user _ sessions( user )
user authorized _ users(role); role session _ roles( session)
dset: DSD; rset:2 NAME
rset dsd _ set (dset ) rset session _ roles( session) {role} | rset | < dsd _ card (dset )
session _ roles = session _ roles \ {session a session _ roles( session)}
{session a ( session _ roles( session) {role})} >

A.4b-3 Review Functions for DSD Relations with General Role Hierarchies

All functions of sections A.4a-3 and A.2a-3 remain valid.

A.4b-3 Advanced Review Functions for DSD Relations with General Role Hierarchies

All functions of section A.2a-4 remain valid.

A.4c DSD Relations with Limited Role Hierarchies

A.4c-1 Administrative Commands for DSD Relations with Limited Role Hierarchies

All functions of sections A.2b-1and A.4a-1 remain valid.

A.4c-2 System Functions for DSD Relations with Limited Role Hierarchies

All functions of section A.4b-2 remain valid.

A.4c-3 Review Functions for DSD Relations with Limited Role Hierarchies

All functions of section A.4b-3 remain valid.

A.4c-4 Advanced Review Functions for DSD Relations with Limited Role Hierarchies

All functions of section A.2a-4 remain valid.

76