Uma Solução Unificada para Controle de Acesso ... · ons e session_roles) representam sessões de...

Click here to load reader

  • date post

    11-Nov-2018
  • Category

    Documents

  • view

    212
  • download

    0

Embed Size (px)

Transcript of Uma Solução Unificada para Controle de Acesso ... · ons e session_roles) representam sessões de...

  • Uma Soluo Unificada paraControle de Acesso Multiplataforma de Aplicaes

    Cleverson Sacramento de OliveiraSerge Normando Rehem

    Tema: Engenharia de Software (processo de desenvolvimento de sistemas)

    Total de pginas: 22

  • 2010

  • Ttulo RASEA: uma soluo unificada para controle de acesso multiplatafor-ma de aplicaes

    Autores Cleverson Sacramento de OliveiraSerge Normando Rehem

    Tema Engenharia de Software

    (processo de desenvolvimento de sistemas)

    Resumo A falta de padronizao do controle de acesso s aplicaes corpora-tivas faz parte da realidade de muitas empresas. comum observar

    neste cenrio que diversas aplicaes implementam solues prpri-

    as. Os efeitos negativos so percebidos pelos usurios dos sistemas,

    que so obrigados a manter diversas senhas, e pela prpria empresa,

    que precisa garantir o controle por meio de processos e auditorias,

    onerando os custos operacionais. Este trabalho tem como objetivo

    prover uma soluo orientada a servios que suporte o controle de

    acesso unificado de usurios s aplicaes, fundamentando-se em

    conceitos e tecnologias existentes para garantir a interoperabilidade

    em ambientes heterogneos. O projeto RASEA foi concebido como

    uma soluo de Software Livre que implementa conceitos como RBAC

    (Role-based Access Control) e SOA (Service-oriented Architecture). Dis-

    ponvel publicamente no repositrio SourceForge, o projeto regido

    pela licena GPLv3. Uma das principais contribuies, e caractersti-

    ca marcante do RASEA, a simplicidade do uso, alcanada atravs

    de experincias adquiridas em mais de 30 (trinta) meses de pesqui-

    sas e implementaes. O elemento 'agente' da arquitetura proposta

    representa um grande diferencial em relao s solues de merca-

    do, possibilitando a extensibilidade e integrao com diversas tecno-

    logias e plataformas ao invs de substitu-las. O RASEA, que est sen-

    do utilizado em ambiente de produo por algumas empresas, pode

    ser implantado tambm no SERPRO, promovendo uma economia nos

    custos de desenvolvimento de aplicaes e a simplificao na admi-

    nistrao do controle de acesso dos sistemas corporativos.

    Palavras-chave Controle de Acesso. Autorizao. RBAC. Web Services.

    Total de pginas 22

  • CURRCULOS

    Cleverson Sacramento de Oliveira Mestre em Sistemas e Computao, MBA Executi-

    vo em Sistemas de Informao e Bacharel em Informtica. Fez parte do quadro docente da

    UNIJORGE. Atua no desenvolvimento de software h mais de 10 anos, participando de pro-

    jetos crticos em diversas plataformas e tecnologias. Atuou como Gerente de Inovao, Con-

    sultor Tcnico e Arquiteto de Software. No SERPRO, faz parte da equipe da Coordenao

    Estratgica de Tecnologia (CETEC) na regional Salvador, dedicado ao projeto framework De-

    moiselle.

    Serge Normando Rehem PMP, Especialista em Sistemas Distribudos pela UFBA e

    MBA em Administrao pela UNIFACS. Analista do SERPRO h 12 anos, atualmente lidera a

    equipe tcnica do framework Demoiselle, na projeo da Coordenao Estratgica de Tecno-

    logia (CETEC) na regional Salvador. lder do grupo de usurios JavaBahia, colunista da re-

    vista Java Magazine e autor do blog http://bazedral.blogspot.com sobre trabalho colabora-

    tivo.

    http://bazedral.blogspot.com/

  • SUMRIO

    1.Introduo........................................................................................................................................ 51.1.Motivao.................................................................................................................................. 51.2.Objetivo..................................................................................................................................... 6

    2.Fundamentos....................................................................................................................................62.1.Autenticao, Autorizao e Controle de Acesso...................................................................... 62.2.RBAC.........................................................................................................................................7

    3.Histrico do projeto.........................................................................................................................93.1.Cronologia............................................................................................................................... 103.2.Cenrio A Sistemas Internos................................................................................................. 113.3.Cenrio B Sistema de Matrcula........................................................................................... 123.4.Cenrio C Fbrica de Software.............................................................................................13

    4.Projeto RASEA.............................................................................................................................. 144.1.Viso Geral.............................................................................................................................. 144.2.Independncia de plataforma e Integrao.............................................................................. 154.3.Servidor....................................................................................................................................164.4.Agente......................................................................................................................................17

    5.Consideraes finais...................................................................................................................... 195.1.Resultados obtidos................................................................................................................... 195.2.Trabalhos futuros..................................................................................................................... 20

    Anexo A Mdulo administrativo.................................................................................................. 22

  • 1. Introduo

    A falta de padronizao do controle de acesso s aplicaes corporativas faz parte da reali-

    dade de muitas empresas. comum observar neste cenrio que diversas aplicaes imple-

    mentam solues prprias. Os efeitos negativos so percebidos pelos usurios dos siste-

    mas e pela prpria empresa. Este captulo delimita o escopo do objeto de estudo, apresen-

    ta a motivao e o objetivo do trabalho.

    1.1. Motivao

    Por manipular informaes corporativas, o acesso s aplicaes geralmente restrito a

    usurios autorizados. O controle de acesso baseia-se em regras incorporadas ao sistema

    durante o processo de desenvolvimento do software, utilizando padres e boas prticas (BU-

    EGE; LAYMAN; TAYLOR, 2003). De acordo com Kern (2004, p. 87), existem poucas publica-

    es a respeito de segurana de aplicaes, se comparadas vasta literatura sobre segu-

    rana de redes.

    Figura 1.1 Diviso lgica da aplicao

    Sob a tica deste trabalho, uma aplicao pode ser logicamente subdividida em dois blo-

    cos, vide Figura 1.1. Na primeira parte, A e B representam as funcionalidades da aplicao

    (telas, regras de negcio, relatrios e integraes) e sua a base de dados. Na segunda par-

    te, C e D simbolizam o mdulo de segurana, responsvel pelas operaes de controle de

    acesso de acordo com a NBR ISO/IEC 27001 (ABNT, 2006, p. 80).

    Os autores Gaedke, Meinecke e Nussbaumer (2005, p. 1156) afirmam que diversas empre-

    sas costumam projetar diferentes mdulos de controle de acesso para cada sistema imple-

    mentado, gerando gastos desnecessrios decorrentes do retrabalho e da dificuldade em ge-

    renciar as polticas de segurana. Este cenrio est ilustrado no lado esquerdo da Figura

    1.2, apresentando os seguintes pontos fracos do ponto de vista do controle de acesso: re-

    dundncias desnecessrias do mdulo de controle (dificultando o gerenciamento) e poss-

    5

  • vel falta de padronizao da estrutura dos dados.

    Uma possvel soluo para este problema a unificao do controle de acesso, conforme

    apresentado ao lado direito da Figura 1.2. Cada aplicao possui um ponto de acesso nico

    (ALUR; CRUPI; MALKS, 2003, p. 164) que, com base nas informaes disponibilizadas pelo

    servio unificado, concede ou revoga o acesso ao sistema. A utilizao de Web Services ga-

    rante a interoperabilidade entre o servio unificado e as aplicaes de forma independente

    de plataforma.

    1.2. Objetivo

    Este trabalho tem como principal objetivo prover uma soluo orientada a servios que su-

    porte o controle de acesso unificado de usurios s aplicaes, fundamentando-se em con-

    ceitos e tecnologias existentes para garantir a interoperabilidade em ambientes heterogne-

    os. Adicionalmente, pretende-se demonstrar que os conceitos e ferramentas aqui apresen-

    tados podem ser aplicados tanto internamente ao SERPRO quanto em clientes e demais r-

    gos do governo, proporcionando o reuso, a diminuio do retrabalho, a reduo de prazos

    e custos e o aumento da segurana e confiabilidade das solues construdas

    2. Fundamentos

    O problema gerado pela descentralizao no controle de acesso s aplicaes comerciais

    motivou a proposta de unificao para garantir a independncia de plataforma. Este captu-

    lo trata dos padres, modelos, conceitos e paradigmas relacionados com a soluo propos-

    ta, tais como: autenticao, autorizao, controle de acesso e RBAC.

    2.1. Autenticao, Autorizao e Controle de Acesso

    comum que pessoas no habituadas com o assunto confundam os termos 'autenticao'

    e 'autorizao'. Resumidamente, a autenticao enfoca na identificao enquanto a autori-

    6

    Figura 1.2 Descentralizao / centralizao do controle de acesso

  • zao define o que possvel fazer. De acordo com Silva (2004, p. 66), autenticao a

    capacidade de garantir que algum, ou alguma coisa, de fato quem diz ser, dentro de um

    contexto definido. O enfoque deste trabalho est no processo de autorizao e controle de

    acesso e, por este motivo, questes relativas autenticao no sero detalhadas.

    Garantir a confidencialidade da informao uma necessidade latente nas aplicaes cor-

    porativas. Assegurar a autorizao significa que ningum poder executar aes sobre um

    recurso caso no tenha permisso (JAAS, 2001). Segundo Barker (2008, p. 144) uma per -

    misso composta por uma ao e um recurso. Quando uma permisso concedida a um

    usurio, tem-se uma autorizao. Alguns autores, tais como Sandhu, Ferraiolo e Kuhn

    (2000), utilizam o termo 'operaes' para referenciar as 'aes' e o termo 'objeto' para refe-

    renciar os 'recursos'.

    De acordo com a norma internacional ISO/IEC 10181-3 (ISO, 1996, p. 1, traduo nossa),

    o processo de determinar quais utilizaes dos recursos [...] so permitidas, [...] prevenin-

    do o acesso no autorizado, chamado de controle de acesso. Para garantir o tratamento

    e o controle efetivo das requisies de acesso ao sistema, este trabalho considera que os

    usurios estejam devidamente autenticados ao executarem operaes sobre os recursos

    das aplicaes (BARKER, 2008).

    A soluo proposta segue a premissa de que tudo proibido, a menos que explicitamente

    permitido, conforme a norma ISO/IEC 17799 (ABNT, 2005, p. 66). Desta forma, o usurio

    somente ter acesso ao recurso caso esteja explicitamente autorizado. As autorizaes po-

    dem ser concedidas ou negadas. Esta caracterstica conhecida como autorizaes positi-

    vas ou negativas (BERTINO, 2001, p. 42).

    2.2. RBAC

    A sigla RBAC, do ingls Role-Based Access Control, significa controle de acesso baseado em

    papis. Um papel representa um grupo de usurios de uma organizao, que rene pesso-

    as do mesmo cargo, funo, responsabilidade, atividade ou outra categorizao. A aborda-

    gem orientada aos papis o diferencial do RBAC em relao aos seus antecessores Man-

    datory Access Control (MAC) e Discretionary Access Control (DAC).

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

    nology (NIST) consolidou as estratgias em um nico modelo (SANDHU; FERRAIOLO;

    KUHN, 2000, p. 2), dando origem ao padro ANSI INCITS 359-2004 (ANSI, 2004). A arqui -

    tetura do projeto RASEA tem como base o padro ANSI INCITS 359-2004, doravante refe-

    renciado apenas como RBAC.

    7

  • O padro RBAC composto por componentes abordados pelo Modelo de Referncia e pela

    Especificao Funcional. O Modelo de Referncia estabelece rigorosamente as entidades

    RBAC, seus relacionamentos e as nomenclaturas utilizadas pela Especificao Funcional.

    Esta ltima define as operaes responsveis por criar, excluir e manter os elementos do

    Modelo de Referncia.

    O Modelo de Referncia e a Especificao Funcional so definidos em trs segmentos, co-

    nhecidos como Componentes RBAC (FERRAIOLO, 2001, p. 228), que so: Core RBAC, Hie-

    rarchical RBAC e Constrained RBAC. Este trabalho se concentrar no componente Core RBAC

    por tratar com mais aprofundamento os elementos fundamentais. Sero apresentados o Hi-

    erarchical RBAC e o Constrained RBAC.

    O Modelo de Referncia do Core RBAC ilustrado na Figura 2.1 estabelece a relao entre

    USERS, ROLES e os demais elementos. A entidade SESSIONS e suas relaes (user_sessi-

    ons e session_roles) representam sesses de usurios autenticados. As entidades OPS, OBS

    e PRMS representam os elementos operations, objects e permissions, respectivamente.

    Figura 2.1 Modelo de Referncia do Core RBACFonte: ANSI (2004).

    A Figura 2.2 representa as operaes suportadas pelo componente Core RBAC agrupadas

    em trs categorias, que so: comandos administrativos, responsveis pela criao e manu-

    teno dos elementos RBAC e suas relaes; funes de apoio ao sistema, as quais mani-

    pulam informaes das sesses de usurios e executam o controle de acesso ao sistema e;

    funes de consulta, que recuperam informaes referentes aos elementos RBAC e suas re-

    laes (ANSI, 2004, p. 1117).

    O Hierarchical RBAC acrescenta ao Core RBAC o conceito de hierarquia de papis, onde um

    papel pode herdar as autorizaes de outro papel (SANDHU; FERRAIOLO; KUHN, 2000, p.

    3). Este componente contribui com a relao role hierarchy para o Modelo de Referncia e

    com quatro operaes administrativas para a Especificao Funcional, responsveis pela

    8

  • manipulao da relao role hierarchy, que so: AddInheritance; DeleteInheritance; AddAscen-

    dant e; AddDescendant (FERRAIOLO, 2001, p. 244; ANSI, 2004, p. 1718).

    O componente Constrained RBAC acrescenta ao Hierarchical RBAC o tratamento de conflitos

    de interesses. Com este componente possvel estabelecer regras para impossibilitar que

    um usurio seja associado ao papel solicitante e aprovador de oramentos simultaneamen-

    te, por exemplo. O Constrained RBAC contribui com o Modelo de Referncia com os seguin-

    tes elementos: Static Separation of Duty Relations, aplicado s relaes user assignment e role

    hierarchy e; Dynamic Separation of Duty Relations, aplicado relao session_roles.

    Figura 2.2 Especificao Funcional do Core RBAC

    O padro RBAC no menciona o controle de acesso a mltiplos sistemas. A arquitetura do

    projeto RASEA utiliza o padro RBAC ANSI INCITS 359-2004 (ANSI, 2004), acrescentando-

    se a entidade application com o propsito de controlar o acesso s diversas aplicaes cor-

    porativas simultaneamente.

    3. Histrico do projeto

    As ideias apresentadas neste trabalho foram validadas com aplicaes prticas antes da

    concepo do projeto. O nome RASEA um acrnimo do ingls cRoss-plAtform accesS con-

    trol for Enterprise Applications, que pode ser traduzido como Controle de Acesso Multiplata-

    9

  • forma para Aplicaes. Regido pelas licenas GPL (2007) e LGPL (2007), o RASEA est dis-

    ponvel no maior repositrio de Software Livre reconhecido internacionalmente

    (http://sourceforge.net/projects/rasea/).

    3.1. Cronologia

    Durante o perodo de mais de 30 (trinta) meses de pesquisas e implementaes, participa-

    ram ativamente do processo usurios responsveis pela administrao de acesso nas orga-

    nizaes envolvidas. O projeto-piloto AvanSEG surgiu em fevereiro de 2007 (Figura 3.1). A

    execuo do projeto foi bem sucedida, cumprindo o cronograma de 18 (dezoito) meses, fi -

    nalizando em julho de 2008. Em junho de 2008, nasceu o S4A.

    Figura 3.1 Macro-cronograma dos projetos: AvanSEG, S4A e RASEA

    Em novembro de 2008, surgiu o RASEA, que foi implantado em janeiro de 2009 em 4 (qua-

    tro) projetos em uma Fbrica de Software e em 2 (dois) projetos de uso interno de uma de-

    terminada empresa. Em maio de 2009, o RASEA foi institudo como sistema padro para

    controle de acesso s aplicaes da Fbrica de Software e aos sistemas internos da organi -

    zao.

    Figura 3.2 Comparativo entre os projetos: AvanSEG, S4A e RASEA

    Com base nos relatos e sugestes dos usurios, as funcionalidades foram evoluindo a cada

    10

    http://sourceforge.net/projects/rasea/

  • projeto, conforme apresentado na Figura 3.2. Durante o processo de desenvolvimento, os

    usurios envolvidos elogiaram a evoluo do trabalho e evidenciaram a simplicidade pro-

    porcionada nas atividades de controle de acesso e gerenciamento de permisses.

    3.2. Cenrio A Sistemas Internos

    Em meados de 2007, deu-se incio ao projeto de unificao da base de usurios de uma or-

    ganizao. At ento, cada sistema possua uma base prpria com credenciais de usurios,

    dificultando o gerenciamento da poltica de segurana da empresa. Diversos estudos foram

    feitos para identificar as informaes relevantes, descartando os dados redundantes e des-

    necessrios. Aps a criao da base unificada surgiu outro problema: o controle descentra-

    lizado de acesso s aplicaes internas da empresa.

    O projeto envolveu diretamente 20 (vinte) sistemas crticos, acessados por aproximadamen-

    te 450 (quatrocentos e cinquenta) usurios. Durante sua execuo, concebeu-se uma solu-

    o para unificao do controle de acesso, tendo como premissa bsica a integrao com

    as aplicaes internas de forma independente de tecnologia. Surgiu em meados de 2007 o

    projeto-piloto AvanSEG. Durante os experimentos, observou-se a necessidade de implemen-

    tar algoritmos mais eficientes.

    Figura 3.3 Arquitetura dos Sistemas Internos

    Na Figura 3.3, o elemento 1 representa o servidor, que prov os servios de controle de

    acesso para as aplicaes parceiras e integra com a base nica de usurios 7. As aplica-

    es 2, 3 e 4 acessam os servios disponibilizados por 1. Apesar de no fazerem parte do

    escopo do projeto-piloto, os elementos 5 e 6 evidenciam a harmonia das ferramentas de in-

    fra-estrutura com a soluo proposta.

    11

  • 3.3. Cenrio B Sistema de Matrcula

    Aps testes exaustivos e refatoraes do cdigo-fonte do AvanSEG, surgiu o Security for Ap-

    plications (S4A) como uma soluo para ambiente de produo. Em princpio, pretendia-se

    tornar o projeto S4A open source, porm, devido s demandas internas da empresa, o plano

    foi suspenso.

    Em 2008, deu-se incio ao Sistema de Matrcula da rede pblica de ensino, projetado para

    suportar 720 (setecentos e vinte) usurios com acesso simultneo em horrios de pico pr-

    determinados, geograficamente distribudos por mais de 600 (seiscentas) unidades conec-

    tadas Internet. Os acessos aplicao foram controlados pelo S4A. Os requisitos no-fun-

    cionais do sistema focaram em dois aspectos: performance e disponibilidade.

    Durante o perodo de 60 (sessenta) dias, aproximadamente 1.000.000 (um milho) de alu-

    nos foram cadastrados no sistema, gerando picos de acesso durante o horrio comercial.

    Apesar de utilizar apenas dois servidores, o sistema foi projetado para cluster com alta es-

    calabilidade, possibilitando a substituio de servidores sem interrupo do servio.

    Figura 3.4 Arquitetura do projeto Inscrio Online

    Na Figura 3.4, o elemento 1 representa os usurios da aplicao, que acessam o sistema

    atravs da intranet ou Internet. O item 2 representa o servidor, que hospeda o Sistema de

    Matrcula. O controle de acesso executado pelo agente S4A implantado na aplicao, que

    acessa o servidor 4 ou 5 atravs do balanceador de carga 3. A base unificada de usurios

    da organizao ilustrada pelo elemento 6. Nenhuma configurao especial foi feita no

    S4A para suportar cluster, e sim no servidor de aplicao, conforme a documentao oficial

    da ferramenta (STANSBERRY; ZAMARRENO, 2009).

    12

  • 3.4. Cenrio C Fbrica de Software

    Em muitas empresas de desenvolvimento de sistemas, o estabelecimento dos custos e pra-

    zos dos projetos feito com base na estimativa do tamanho funcional, utilizando a tcnica

    de Anlise de Pontos de Funo (APF) (VAZQUEZ; SIMES; ALBERT, 2003).

    Para cada nova aplicao, fazia-se necessria a construo de um novo mdulo para con-

    trole de acesso que, com base na estimativa da organizao, representava 190 PF (cento e

    noventa pontos de funo). Supondo um sistema de 1.000 PF (mil pontos de funo), o

    controle de acesso representaria 19% (dezenove por cento) do custo de desenvolvimento.

    Empregando o S4A como componente reutilizvel (DAN; JOHNSON; CARRATO, 2008, p.

    25), a organizao economizou 190 PF (cento e noventa pontos de funo) a cada aplica-

    o desenvolvida, com investimento mnimo na integrao do software. Os benefcios foram

    percebidos principalmente na reduo do custo e prazo do projeto. Por questes de confi-

    dencialidade, no sero apresentados o custo do PF nem a produtividade da organizao.

    Figura 3.5 Economia na utilizao do S4A

    Na Figura 3.5, o eixo horizontal representa o tamanho funcional da aplicao e o eixo verti-

    cal indica o percentual de economia, considerando que a aplicao possua funcionalidades

    para controle de acesso. De acordo com a base histrica da empresa (2004 2009), os sis-

    temas construdos pela Fbrica de Software variam entre 600 PF (seiscentos pontos de fun-

    o) e 3.000 PF (trs mil pontos de funo), gerando uma economia entre 6% (seis por

    cento) e 31% (trinta e um por cento) nos custos do projeto.

    4. Projeto RASEA

    Projetado como uma soluo para controle de acesso unificado, o RASEA implementa os

    13

  • conceitos RBAC, SOA e Web Services para garantir a maturidade da soluo e a independn-

    cia de plataforma. Este captulo apresenta a arquitetura da soluo proposta. Os detalhes

    de codificao no sero abordados, haja vista que o cdigo-fonte est disponvel publica-

    mente em http://svn.rasea.org/svnroot/rasea/.

    4.1. Viso Geral

    A Arquitetura de Software auxilia na identificao dos componentes e seus relacionamentos

    de alto nvel (SHAW; GARLAN, 1994), facilitando o entendimento da soluo como um todo.

    O projeto RASEA fundamenta sua arquitetura sobre dois elementos principais tratados sob

    duas perspectivas, que so respectivamente: servidor, agente, independncia de plataforma

    e integrao.

    Enquanto o elemento 'servidor' preocupa-se com a disponibilidade dos servios, o 'agente'

    aborda aspectos especficos das plataformas das aplicaes. A perspectiva 'independncia

    de plataforma' agrega padres e tecnologias, possibilitando que diferentes plataformas be-

    neficiem-se da soluo. A perspectiva 'integrao' promove a interao entre o RASEA, as

    informaes da organizao e as aplicaes clientes.

    Figura 4.1 Viso geral da arquitetura do projeto RASEA

    Na Figura 4.1, o elemento A representa o servidor, o qual disponibiliza um mdulo adminis-

    trativo B (Anexo A Mdulo administrativo) para que o administrador do acesso C gerencie

    as permisses aos sistemas. O servidor prov o mdulo de servios D. Os agentes so co-

    nectados s aplicaes parceiras E e F. As aplicaes G, que no utilizam os servios para

    controle de acesso, so chamadas de aplicaes autnomas, que podem acessar os servi-

    os de gerenciamento.

    14

    http://svn.rasea.org/svnroot/rasea/

  • Figura 4.2 Diagrama de Classes de Domnio do RASEA

    Ainda na Figura 4.1, o servidor A mantm a base de dados H, que contm informaes es-

    truturadas conforme o Modelo de Referncia do padro RBAC. A base de dados I detm cre-

    denciais dos usurios existentes na organizao. O servidor A acessa a base de dados de

    usurios I para executar tarefas de autenticao.

    O Diagrama de Classes de Domnio (Figura 4.2) representa a viso orientada a objetos (OO)

    do padro RBAC utilizando UML (RAY, 2004). Por se tratar de uma percepo OO, algumas

    entidades (descritas no captulo 2.2.) sofreram adaptaes na sua nomenclatura, aproxi-

    mando-se mais da realidade das aplicaes (GAEDKE; MEINECKE; NUSSBAUMER, 2005, p.

    1156). A associao permission_assignment representada pela classe Authorization. A enti-

    dade object ganhou um nome mais intuitivo: Resource, que pode ser traduzido como 'recur-

    so'. A associao user_assignment representada pela classe Member.

    4.2. Independncia de plataforma e Integrao

    Uma das premissas do RASEA garantir a interoperabilidade com aplicaes parceiras em

    diferentes plataformas. Para possibilitar esta caracterstica, optou-se por duas estratgias:

    garantir a independncia de plataforma e empregar Web Services no canal de comunicao.

    De acordo com Li e Karp (2007, p. 9), os padres abertos, adotados pelos Web Services,

    possibilitam o desacoplamento das aplicaes, facilitando o desenvolvimento de componen-

    tes independentes de tecnologias.

    Esta deciso est totalmente aderente aos padres de interoperabilidade de governo eletr-

    nico elencados na arquitetura e-PING (2010, cap. 10.1.4): Orienta-se o uso de Web Servi-

    ces para demandas de integrao entre sistemas de informao de governo. De maneira

    que, independente das tecnologias em que foram implementados, possa-se adotar um pa-

    15

  • dro de interoperabilidade que garanta escalabilidade, facilidade de uso, alm de possibili-

    tar atualizao de forma simultnea e em tempo real.

    Figura 4.3 Integrao com base de usurios legada

    Os servios foram agrupados em dois EndPoints: controle de acesso e gerenciamento. O

    EndPoint de controle de acesso contm servios consumidos pelos agentes e prov informa-

    es para o efetivo controle de acesso. O EndPoint de gerenciamento rene os servios de

    administrao do servidor RASEA, acessados por aplicaes (parceiras ou autnomas) que

    necessitam modificar informaes do servidor.

    Alm da integrao com seus servios, o RASEA possibilita a conexo com repositrios de

    credenciais de usurios, tal como o LDAP. A Figura 4.3 ilustra a integrao entre o servidor

    A e a base de usurios B. A estratgia de armazenamento das credenciais (C, D e E) defi-

    nida no arquivo de configurao do servidor. Para garantir a extensibilidade da soluo, o

    RASEA permite que novas estratgias F sejam acopladas.

    fundamental que todos os nveis de integrao (CUMMINS, 2002, p. 316) estabeleam

    conexes seguras. A integrao entre as aplicaes e os servios RASEA podem empregar o

    HyperText Transfer Protocol Secure (HTTPS) ou o Secure LDAP (LDAPS), por exemplo. No faz

    parte do escopo desde trabalho detalhar protocolos e tcnicas de segurana.

    4.3. Servidor

    O servidor o ponto central da arquitetura RASEA, responsvel por implementar o modelo

    RBAC, prover servios por meio de Web Services, integrar com dados da organizao e dis-

    ponibilizar uma interface grfica para gerenciamento. Todas as informaes fornecidas pe-

    los servios do RASEA tm sempre como fonte duas bases de dados: a base de autoriza-

    o, que implementa o modelo RBAC; e a base de autenticao, que contm as credenciais

    dos usurios.

    16

  • Figura 4.4 Arquitetura em camadas do servidor RASEA

    A base de autorizao mantida nica e exclusivamente pelo servidor RASEA, sendo poss-

    vel efetuar modificaes nos dados atravs do mdulo administrativo ou via servios de ge-

    renciamento. A interao com a base de autenticao implementa o padro de projeto Stra-

    tegy (GAMMA, 2000, p. 292), onde o servidor toma o arquivo de configurao como fonte

    de parmetros.

    O servidor RASEA tem a estrutura interna dividida em 3 (trs) camadas: apresentao, ne-

    gcio e acesso aos dados. A responsabilidade da camada de apresentao possibilitar a

    interao entre os consumidores e as funcionalidades do servidor. A camada de negcio o

    ncleo do servidor, composto pelas operaes do RBAC. A camada de acesso aos dados

    mantm as informaes armazenadas nas bases.

    A Figura 4.4 apresenta a arquitetura em camadas do servidor RASEA, tendo como principal

    elemento o seu ncleo A, envolto pelas camadas de apresentao e acesso aos dados. Os

    elementos B e D fazem parte da camada de apresentao, que expem as funcionalidades

    do servidor para os consumidores C e E. A camada de acesso manipula a base de autoriza-

    o G (por meio de F) e a base de credenciais I (por meio de H).

    4.4. Agente

    Todas aplicaes parceiras devem estar conectadas a um agente. O agente RASEA atua

    como um conversor do modelo independente de plataforma para a tecnologia especfica de

    cada aplicao (IBM, 2009). Alm disso, o agente executa efetivamente as tarefas de con-

    trole de acesso s aplicaes.

    17

  • Os agentes simplificam o desenvolvimento de aplicaes parceiras, que passam a dispor de

    uma API de controle de acesso local e no precisam se preocupar com detalhes de acesso

    ao servio Web. Alm disto, os agentes ampliam a atuao do RASEA dentro das aplicaes

    parceiras, oferecendo suporte completo interceptao das tentativas de acesso.

    Figura 4.5 Tipos de agente

    A Figura 4.5 destaca a especializao do agente RASEA em diferentes tecnologias. O item A

    representa os servios providos pelo servidor, que so acessados pelos agentes. Os itens B,

    C e D representam especializaes de agentes, construdos em tecnologias especficas, tais

    como: Java, .NET e PHP. O item E representa agentes desenvolvidos em qualquer tecnologia

    que suporte o consumo de Web Services, proporcionando flexibilidade soluo.

    Os agentes devem se especializar ao mximo, garantindo o encaixe perfeito com a tecnolo-

    gia da aplicao parceira. Como exemplo, pode-se citar a utilizao de Java na construo

    de aplicaes. Existem diversas ferramentas, paradigmas, frameworks, bibliotecas e tecnolo-

    gias que podem ser utilizadas na construo de aplicaes, tais como: JavaServer Faces

    (JSF), Apache Struts; Google Web Toolkit (GWT), Abstract Window Toolkit (AWT), dentre outras.

    fundamental que exista um agente para cada tecnologia especfica.

    O servidor RASEA tambm uma aplicao que requer o controle de acesso s suas funcio-

    nalidades. Este requisito possui um carter recursivo (DAVISON; HINKLEY, 1997), visto que

    o servidor acessa os seus prprios servios para garantir o controle de acesso a si mesmo,

    caracterizando-o tambm como uma aplicao parceira.

    O agente conectado ao servidor RASEA foi implementado na tecnologia Seam Security

    (SEAM, 2009), visto que o servidor compatvel com o JBoss Seam Framework para platafor-

    18

  • ma Java. O processo de interceptao das requisies aplicao est de acordo com a es-

    pecificao oficial da ferramenta (SEAM, 2009), materializada na classe RaseaPermission-

    Resolver.

    A premissa para todo agente atuar no ponto central, onde todas as requisies aos recur -

    sos da aplicao sejam interceptadas. Para conseguir isto, existem solues simplrias e

    solues arrojadas. Um exemplo de soluo para agentes Web a insero da tag

    em todas as pginas. Esta uma soluo simples, porm pouco elegante. Como

    exemplo de soluo robusta para a plataforma Java, tem-se o Java Authentication and Autho-

    rization Service (JAAS), que atua diretamente no ncleo da mquina virtual.

    5. Consideraes finais

    Neste captulo, sero apresentados os resultados obtidos a partir de anlises elaboradas

    durante o desenvolvimento deste trabalho. Foram detectadas oportunidades de melhoria da

    soluo proposta, motivando a sua evoluo em trabalhos futuros. Por fim, conclui-se que o

    projeto RASEA capaz de promover a reduo de custos no desenvolvimento de aplicaes

    comerciais e a simplificao na administrao do controle de acesso de aplicaes, inclusi-

    ve no SERPRO.

    5.1. Resultados obtidos

    Os cenrios apresentados na evoluo do projeto foram estrategicamente selecionados para

    experimentar e validar o objetivo geral deste trabalho, que prover uma soluo orientada

    a servios que suporte o controle de acesso unificado de usurios s aplicaes, fundamen-

    tando-se em conceitos e tecnologias existentes para garantir a interoperabilidade em ambi-

    entes heterogneos (captulo 1.2.).

    O projeto est em constante evoluo e pode ser acompanhado pela rede social Twitter

    (http://twitter.rasea.org). No decorrer deste trabalho, programadores autnomos oferece-

    ram contribuies e algumas empresas demonstraram interesse na implantao do RASEA

    em suas instalaes.

    O design de uma soluo que concentra os elementos essenciais de controle de acesso ba-

    seado nas experincias adquiridas durante a evoluo do projeto a principal contribuio

    deste trabalho. No decorrer do desenvolvimento do AvanSEG, S4A e RASEA os usurios elo-

    giaram a simplicidade no controle de acesso e gerenciamento das permisses.

    A simplicidade no uso (Anexo B Exemplo de uso) foi uma deciso de projeto que permitiu

    19

    http://twitter.rasea.org/

  • no apenas a atuao de profissionais no especialistas em segurana na administrao de

    acesso a aplicaes, como tambm melhorou o controle na segurana do sistema, dado

    que o administrador no se perde em demasiados detalhes, concentrando-se nos elemen-

    tos essenciais do controle de acesso.

    5.2. Trabalhos futuros

    Durante o desenvolvimento deste trabalho foram identificadas diversas oportunidades de

    melhoria e evoluo do projeto ainda no implementadas, enumeradas a seguir: implemen-

    tao do Hierarchical e Constrained RBAC; criao de agentes em diferentes linguagens de

    programao; seleo de outros mtodos de autenticao e; avaliar e integrar com mais

    tecnologias de mercado.

    Como contribuio prtica deste trabalho, construiu-se o agente para a plataforma Java in-

    tegrado com a ferramenta Seam Security. fundamental a criao de novos agentes em ou-

    tras plataformas e tecnologias, tais como: ASP, .NET e PHP, alm de oferecer integraes

    com mtodos de autenticao utilizando certificados digitais e ferramentas de Single Sign-

    On (SSO).

    Est em andamento a criao de um agente para o Demoiselle1, que permitir a integrao

    do RASEA com qualquer aplicao que utiliza o framework de governo. Este agente pode ser

    empregado para viabilizar a unificao do controle de acesso de todas as aplicaes corpo-

    rativas construdas no SERPRO, promovendo uma soluo padronizada para as questes re-

    lacionadas a autorizao, mantendo os mecanismos atuais de autenticao baseados nos

    diretrios de usurios existentes (notadamente o SENHA-REDE e a Rede Local de Software

    Livre). Clientes e demais rgos de governos poderiam fazer o mesmo, potencializando o

    uso e evoluo do RASEA em conjunto com o Demoiselle enquanto projetos open source de

    governo.

    Indo alm do raciocnio acima, os sistemas unificados de permisses poderiam ser ofereci-

    dos como servios em nuvem. Pode-se imaginar um cenrio onde, em poucos minutos, o

    cliente teria sua disposio uma instncia confivel e segura do RASEA com o Demoiselle,

    permitindo o imediato controle de acesso das suas aplicaes (que tambm poderiam es-

    tar na nuvem). Pensar em Cloud Computing amplia as possibilidades e favorece a incorpora-

    o de tecnologias como REST e NoSQL, podendo aumentar ainda mais a escalabilidade e

    perfomance da soluo atual.

    1 O Framework Demoiselle a integrao de vrias tecnologias de software e uma arquitetura de referncia, focados no desenvolvimento de aplicaes Java/Web, provendo independncia por meio de padronizao. http://www.frameworkdemoiselle.gov.br

    20

  • Reuso, padronizao, economia, confiabilidade, segurana, interoperabilidade, servios,

    evoluo e, principalmente, inovao. Alm de conceitos, este trabalho apresenta uma solu-

    o comprovada com altssimo potencial de evoluo para um problema recorrente no

    s no SERPRO. Ao unificar esforos em torno das necessidades e objetivos comuns, todos

    ganham. Para mais informaes tcnicas sobre o RASEA, acesse o site oficial do projeto:

    http://www.rasea.org

    21

    http://www.rasea.org/

  • Anexo A Mdulo administrativo

    A interface grfica foi projetada para atender as solicitaes dos usurios, almejando a faci-

    litao e simplificao no gerenciamento de permisses.

    Ilustrao 1 Foram includos filtros nas listagens para facilitar a busca, conforme solicitaes dos usurios.

    Ilustrao 2 Cada listagem antecede a tela de cadastro ou alterao de registros.

    22

  • Ilustrao 3 Listagem de todas as aes associadas a uma aplicao.

    Ilustrao 4 Listagem de todos os recursos do sistema de custos.

    23

  • Ilustrao 5 Alterao dos dados de um recurso e associao das possveis operaes, tambm conhecida como permisses.

    Ilustrao 6 Concesso das permisses de um determinado recurso para os papis do sistema.

    24

  • Ilustrao 7 A mesma funcionalidade da tela anterior, porm possibilitando o gerenciamento das permisses sob a perspectiva de um

    determinado papel.

    Ilustrao 8 Listagem das aplicaes cadastrados que possuem o seu controle de acesso gerenciado pelo RASEA.

    25

  • Anexo B Exemplo de uso

    Para exemplificar o uso do RASEA, foi utilizado a aplicao de exemplo contactlist. Como

    esta aplicao foi desenvolvida pelo grupo JBoss utilizando a ferramenta Seam Framework,

    reutilizamos o agente RASEA para o Seam Security. O cdigo-fonte da aplicao de exemplo

    original est disponvel no seguinte repositrio:

    http://anonsvn.jboss.org/repos/seam/tags/JBoss_Seam_2_2_0_GA/examples/contactlist/

    Como o cdigo-fonte original no contm diretivas de segurana, a aplicao foi modifica-

    da. Incluiu-se a biblioteca rasea-seam-agent.jar, que ativada a partir da configurao do

    arquivo components.xml do JBoss Seam. Segue o exemplo da configurao com destaque

    para a simplicidade:

    (...)

    Na aplicao possvel utilizar a diretiva do Seam Security no arquivo JSF:

    Ou na classe Java diretamente:

    @Restrict("#{s:hasPermission('contact', 'insert')}")public String insert(){ ... }

    O processo completo de modificao na aplicao contactlist est disponvel publicamente

    no YouTube (http://www.youtube.com/watch?v=DV53pW14kso).

    26

    http://www.youtube.com/watch?v=DV53pW14ksohttp://anonsvn.jboss.org/repos/seam/tags/JBoss_Seam_2_2_0_GA/examples/contactlist/

  • Bibliografia

    ABNT: ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. NBR ISO/IEC 17799: tecnolo-gia da informao: tcnicas de segurana: cdigo de prtica para a gesto da segurana da informao. Rio de Janeiro, 2005.

    ______. NBR ISO/IEC 27001: tecnologia da informao: tcnicas de segurana: sistemas de gesto de segurana da informao: requisitos. Rio de Janeiro, 2006.

    ANSI: American National Standard Institute. ANSI INCITS 359-2004: Information Techno-logy: Role Based Access Control. New York, 2004.

    ALUR, Deepak; CRUPI, John; MALKS, Dan. Core J2EE Design Patterns: Best practices and Design Strategies. 2 ed. Upper Saddle River: Prentice Hall PTR, 2003. ISBN: 0-13-142246-4.

    BARKER, Steve. Access control by action control. In: Symposium on Access Control Models and Technologies, 2008, Estes Park. Anais... New York: ACM, 2008. p. 143152. ISBN: 978-1-60558-129-3.

    BERTINO, Elisa et al. A logical framework for reasoning about access control models. In: ACM Workshop on Role Based Access Control, 2001, Chantilly. Anais... New York: ACM, 2001. p. 4152. ISBN: 1-58113-350-2.

    BUEGE, Brian; LAYMAN, Randy; TAYLOR, Art. Segurana contra Hackers J2EE e Java: Desenvolvendo aplicaes seguras com a tecnologia Java. So Paulo: Futura, 2003. ISBN: 85-7413-156-3.

    CUMMINS, Fred A. Integrao de Sistemas: EAI Enterprise Application Integration. Rio de Janeiro: Campus, 2002. ISBN: 85-352-0975-1.

    DAN, Asit; JOHNSON, Robert D.; CARRATO, Tony. SOA service reuse by design. In: Internati -onal Conference on Software Engineering, 2008, Leipzig. Anais New York: ACM, 2008. p. 2528. ISBN: 978-1-60558-029-6.

    DAVISON, Anthony C.; HINKLEY, D. V. Bootstrap methods and their application. [S.I.]: Cambridge University Press, 1997. ISBN: 0521574714.

    E-PING: Padres de Interoperabilidade de Governo Eletrnico. Verso 2010. Gover-no Brasileiro: Comit Executivo de Governo Eletrnico. Disponvel em: . Acesso em: 27 ago. 2010.

    FERRAIOLO, David F. et al. Proposed NIST standard for role-based access control. ACM Transactions on Information and System Security (TISSEC), v. 4, n. 3, p. 224274, 2001. ISSN:1094-9224.

    GAEDKE, Martin; MEINECKE, Johannes; NUSSBAUMER, Martin. A modeling approach to fe-derated identity and access management. In: International World Wide Web Conference, 14, 2005, Chiba. Anais... New York: ACM, 2005. p. 11561157. ISBN: 1-59593-051-5.

    GAMMA, Erich et al. Padres de Projeto: Solues Reutilizveis de Software Orientado a Objetos. Porto Alegre: Bookman, 2000. ISBN: 85-7307-610-0.

    27

  • GPL: GNU General Public License. Version 3. [S.I.]: Free Software Foundation, 2007. Disponvel em: . Acesso em: 25 ago. 2010.

    IBM. The PIMA Project: Platform-Independent Model for Applications. [S.I.]: IBM Resear-ch. Disponvel em . Acesso em: 25 de ago. 2010.

    ISO: International Organization for Standardization. ISO/IEC 10181-3: information techno-logy, open systems interconnection, security frameworks for open systems: access control framework. [S.I.], 1996.

    JAAS, Java Authentication and Authorization Service: Reference Guide. Version 1.5.0. [S.I]: Sun Microsystems, 2001. Disponvel em: . Acesso em: 25 ago. 2010.

    KERN, Axel et al. A meta model for authorisations in application security systems and their integration into RBAC administration. In: Symposium on Access Control Models and Tech-nologies, 9, 2004, Yorktown Heights. Anais... New York: ACM, 2004. p. 8796. ISBN: 1-58113-872-5.

    LI, Jun; KARP, Alan H. Access control for the services oriented architecture. In: Workshop On Secure Web Services, 2007, Fairfax. Anais... New York: ACM, 2007. p. 917. ISBN: 978-1-59593-892-3.

    LGPL: GNU Lesser General Public License. Version 3. [S.I.]: Free Software Foundation, 2007. Disponvel em: . Acesso em: 25 ago. 2010.

    RAY, Indrakshi et al. Using uml to visualize role-based access control constraints. In: Sym-posium on Access Control Models and Technologies, 2004, New York. Anais... New York: ACM, 2004. p. 115124. ISBN: 1-58113-872-5.

    SANDHU, Ravi; FERRAIOLO, David; KUHN, Richard. The NIST Model for Role-Based Ac-cess Control: Toward A Unified Standard. [S.I]: National Institute of Standards and Tech-nology, 2000. Disponvel em: . Acesso em: 25 ago. 2010.

    SEAM Security: The Seam Security API. Version 2.1.1.GA. [S.I], 2009. Disponvel em: . Acesso em: 25 ago. 2010.

    SHAW, Mary; GARLAN, David. An Introduction to Software Architecture. School of Computer Science Carnegie Mellon University: Pittsburgh, 1994.

    SILVA, Lino S. Public Key Infrastructure PKI: Conhea a Infra-estrutura de Chaves Pbi-cas e a Certificao Digital. So Paulo: Novatec, 2004. ISBN: 85-7522-046-2.

    STANSBERRY, Brian; ZAMARRENO, Galder. JBoss Application Server Clustering Gui-de. [S.I.]: JBoss Labs. Disponvel em: . Acesso em: 25 ago. 2010.

    VAZQUEZ, Carlos E.; SIMES, Guilherme S.; ALBERT, Renato M. Anlise de Pontos de Funo: Medio, Estimativas e Gerenciamento de Projetos de Software. 4. ed. So Paulo: rica, 2003. ISBN: 85-7194-899-2.

    28

    1. Introduo1.1. Motivao1.2. Objetivo

    2. Fundamentos2.1. Autenticao, Autorizao e Controle de Acesso2.2. RBAC

    3. Histrico do projeto3.1. Cronologia3.2. Cenrio A Sistemas Internos3.3. Cenrio B Sistema de Matrcula3.4. Cenrio C Fbrica de Software

    4. Projeto RASEA4.1. Viso Geral4.2. Independncia de plataforma e Integrao4.3. Servidor4.4. Agente

    5. Consideraes finais5.1. Resultados obtidos5.2. Trabalhos futuros

    Anexo A Mdulo administrativoAnexo B Exemplo de usoBibliografia