MAC5701 Tpicos em Cincia da Computao Monografia

Stefan Neusatz Guilhen sneusatz@ime.usp.br

Controle de acesso baseado em papis e certificados de atributos X.509

Orientador: Prof. Dr. Francisco Carlos da Rocha Reverbel Departamento de Cincia da Computao

Universidade de So Paulo - So Paulo, SP 2005 -

1 Introduo
A grande maioria dos sistemas desenvolvidos atualmente tem como requisito algum tipo de controle de acesso s informaes a aos recursos que so de grande importncia. Primeiro, usurios devem se identificar ao sistema utilizando algum mecanismo de autenticao. Depois de identificado, o usurio deve somente poder acessar recursos para os quais ele tem permisso de acesso. O RBAC [1] ou Role-Based Access Control um mecanismo para controle de acesso baseado em papis. Ele define um conjunto de papis, que geralmente representam posies profissionais como gerente, administrador, diretor, etc, e atribui a cada papel um conjunto de permisses ou privilgios, que representam as aes que eles podem executar. Esse mecanismo simplifica de maneira significativa o gerenciamento de controle de acesso para um grande nmero de usurios, uma vez que tipicamente o nmero de papis que os usurios podem desempenhar muito inferior ao nmero de usurios em si. Diversos servios de segurana e middlewares, como servidores de aplicao, utilizam o RBAC como mecanismo de autorizao e controle de acesso. Entretanto, a maioria dessas aplicaes no utiliza uma maneira padronizada para mapear os usurios de uma aplicao aos seus respectivos papis. Recentemente, o comit X9 da U.S. American National Standards Institute (ANSI) desenvolveu uma infra-estrutura de gerenciamento de privilgios, ou PMI [2],[3], que utiliza os certificados de atributos X.509 para armazenar o conjunto de privilgios de um usurio. Os certificados de atributos X.509 podem armazenar o conjunto de papis de um usurio, estabelecendo dessa forma uma estrutura padronizada para fazer o mapeamento entre os usurios e seus papis. Essa monografia est organizada da seguinte forma: a seo 2 apresenta os modelos de controle de acesso definidos pelo RBAC. A seo 3 apresenta uma viso geral das infra-estruturas de chave pblica (PKI) e de gerenciamento de privilgios (PMI), dos certificados de atributo X.509 e da relao entre a PMI e a PKI. A seo 4 discute os modelos push e pull de distribuio de credenciais (privilgios) utilizando os certificados de atributo X.509. Por fim, a seo 5 apresenta dois projetos estudados que fornecem um servio de controle de acesso utilizando o RBAC e certificados digitais.

2 Role-Based Access Control - RBAC

Role-Based Access Control ou RBAC um mecanismo de autorizao (controle de acesso) que define um conjunto de papis (roles) e atribui a cada papel um conjunto de permisses. Cada usurio ento associado a um ou mais papis e herda todas as permisses desses papis. A grande vantagem associada ao uso do RBAC a simplificao do processo de gerenciamento de permisses. Uma empresa pode ter facilmente milhares de

funcionrios que so usurios de um sistema. Entretanto, pode-se observar que muitos usurios possuem exatamente os mesmos privilgios, pois desempenham o mesmo papel (ou funo) dentro da empresa. A idia ento agrupar os usurios em papis, que representam sua funo junto ao sistema e atribuir aos papis e no aos usurios individuais o seu conjunto de permisses. Existem quatro modelos de RBAC. O modelo simples, ou RBAC0 o modelo descrito acima: define diversos papis, que geralmente representam posies profissionais tais como secretria, diretora e gerente. O administrador do sistema atribui a cada papel um conjunto de permisses que representam as aes que os papis podem executar nos recursos protegidos e depois atribui um ou mais papis para cada usurio real. Ao acessar um recurso, o usurio apresenta os seus papis e o servio de autorizao determina o conjunto de permisses desses papis para decidir se o acesso deve ou no ser permitido. O modelo hierrquico, ou RBAC1, uma extenso mais sofisticada do modelo bsico, permitindo que um papel estenda outros papis e herde o seu conjunto de permisses. Assim, por exemplo, um papel gerente pode estender o papel funcionrio para indicar que todos os privilgios alocados a um funcionrio tambm se aplicam a um gerente, mesmo que isso no esteja explicitamente descrito. Esse modelo facilita ainda mais o gerenciamento de permisses, pois permite que permisses comuns a vrios papis sejam agrupadas em novo papel do qual os demais herdam, evitando replicao das permisses. O modelo restrito, ou RBAC2, uma outra extenso do modelo bsico. Embora a numerao possa sugerir que ela uma extenso do RBAC1, ela na verdade uma outra extenso do RBAC0. Com o RBAC2, o administrador do sistema pode definir um conjunto de restries para as permisses alocadas aos usurios. Uma restrio comum declarar que certos papis so mutuamente exclusivos, ou seja, a mesma pessoa no pode possuir os dois papis ao mesmo tempo. Outras restries podem restringir o nmero de papis que um usurio pode ter ou ento o nmero de pessoas que podem ter um dado papel. J o modelo consolidado, ou RBAC3, uma extenso que inclui os modelos RBAC1 e RBAC2 ao mesmo tempo. importante salientar que o RBAC apenas define formalmente os modelos descritos acima. Ou seja, o RBAC no uma framework para controle de acesso, apenas uma especificao. Implementaes do RBAC so livres para definir como a poltica de controle de acesso a um recurso deve ser descrita, como papis devem ser descritos e como associar os papis aos usurios. Na prtica, observase o uso de XML como linguagem para definir a poltica de acesso e tambm os papis e suas relaes/restries.

3 PKI e PMI
A infra-estrutura de gerenciamento de privilgios, ou simplesmente PMI, surgiu a partir da necessidade de um mecanismo forte de autorizao e que fosse independente do mecanismo de autenticao. O padro X.509, juntamente com a

ITU-T e a ISO/IEC [2] havia definido uma infra-estrutura de chave pblica, a PKI, cujo elemento central o certificado de chave pblica, tambm conhecido por public key certificate ou PKC. O principal foco dessa infra-estrutura era prover um mecanismo forte de autenticao. Os PKCs so documentos digitalmente assinados por uma entidade certificadora a Certification Authority ou CA e associam a identidade de um usurio a uma chave pblica. Na prtica, o uso da PKI revelou a necessidade de se armazenar outros tipos de dados em um certificado, alm da chave pblica e da identidade do seu portador. Por isso, verses recentes do padro X.509 definem uma srie de extenses no PKC para o armazenamento de informaes como, por exemplo, dos papis que um usurio desempenha, seus privilgios ou outro tipo de informao de autorizao. Porm utilizar as extenses dos PKCs para armazenar informaes a respeito de autorizao gerou alguns efeitos negativos, dentre os quais os que mais se destacam so: Em primeiro lugar, as informaes de autorizao tipicamente no tm o mesmo tempo de validade da identidade e da chave pblica que so armazenadas em um PKC. Em geral, informaes de autorizao tendem a ter validade mais curta do que a identidade e chave pblica. Por isso, se essas informaes so colocadas na extenso de um PKC, o tempo durante o qual o PKC deveria ser vlido encurtado, pois modificaes das informaes de autorizao iro requerer que um novo PKC seja emitido e o antigo seja revogado. Em segundo lugar, dificilmente a entidade que emite um certificado de chave pblica ter autoridade para estabelecer informaes de autorizao e controle de acesso. Como resultado, uma entidade emissora de PKCs precisa realizar algumas operaes a mais para obter essas informaes de uma ou mais fontes de autorizao.

Reconhecendo que os certificados de chave pblica (PKCs) no so a melhor estrutura para carregar informaes de autorizao, o comit X9 da U.S. American National Standards Institute (ANSI) desenvolveu umas abordagens alternativas, conhecidas como certificados de atributos ou ACs. Semelhante ao certificado de chave pblica, que associa uma chave pblica a uma identidade, um AC associa um conjunto de atributos ao seu portador. A edio 4 do padro X.509 a primeira a totalmente padronizar um mecanismo forte de autorizao, que foi chamado de infra-estrutura de gerenciamento de privilgios ou PMI. A estrutura de dados fundamental dessa infra-estrutura o X.509 Attribute Certificate, ou X.509 AC. A entidade emissora dos certificados de atributos chamada de Attribute Authority ou AA. Os X.509 ACs so digitalmente assinados pela AA. Quando as permisses de autorizao de um usurio so revogadas, a Attribute Authority emite uma lista de certificados de atributos revogados (Attribute Certificate Revocation List ou ACRL) contendo a lista de ACs que no devem mais ser aceitos.

Os certificados de atributos estabelecem uma separao clara entre o processo de autenticao (identificao) e autorizao (controle de acesso). Com eles, entidade emissora dos PKCs Certification Authority no tem mais a responsabilidade de obter de alguma forma os atributos de autorizao de um usurio. Ela precisa apenas se preocupar com os atributos relacionados identidade do mesmo. A Attribute Authority assume a responsabilidade pelos atributos de autorizao de um usurio. Assim como a Certification Authority no se preocupa com informaes de autorizao, a Attribute Authority no se preocupa com informaes sobre a identidade de uma pessoa, apenas com inferncias que podem ser feitas a seu respeito uma vez que sua identidade foi provada. Isso traz as seguintes vantagens: Promove a interoperabilidade na medida em que favorece o gerenciamento distribudo de privilgios e atributos de autorizao. Como esses atributos de autorizao no so emitidos pelas Certification Authorities, possvel distribuir o gerenciamento desses atributos por vrias Attribute Authorities, cada uma fornecendo informaes de autorizao em um contexto diferente. Por exemplo, em um pas possvel que cada cidado tenha um PKC assinado por uma nica Certification Authority e que comprova sua identidade. Os seus privilgios nos mais diversos contextos da vida social podem ser emitidos por diferentes Attribute Authorities. Uma AA pode emitir CAs contendo informaes sobre os papis do cidado no sistema eleitoral (eleitor, mesrio, etc) enquanto outra pode emitir CAs contendo os atributos de sua carteira de motorista, identificando a sua autorizao para dirigir determinados tipos de veculos. Separao de jurisdio. Como os certificados de atributos so emitidos por autoridades que realmente possuem as informaes de autorizao (AAs), as Certification Authorities no precisam mais coletar essas informaes e isso evita delegao de responsabilidades para as CAs. Certificados de atributos podem ter um tempo de vida muito mais curto do que os certificados de chave pblica e podem ser revogados separadamente. Isso uma conseqncia imediata da remoo dos atributos de autorizao dos certificados de chave pblica. Se os atributos de um usurio mudam apenas os seus respectivos ACs precisam ser revogados sem causar nenhuma revogao de seu PKC.

A figura abaixo ilustra a definio de um certificado de atributos de acordo com a RFC3281 [3]:
AttributeCertificate ::= SEQUENCE { acinfo AttributeCertificateInfo, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING }

AttributeCertificateInfo ::= SEQUENCE { version AttCertVersion -- version is v2, holder Holder, issuer AttCertIssuer, signature AlgorithmIdentifier, serialNumber CertificateSerialNumber, attrCertValidityPeriod AttCertValidityPeriod, attributes SEQUENCE OF Attribute, issuerUniqueID UniqueIdentifier OPTIONAL, extensions Extensions OPTIONAL } Figura 1 Certificado de Atributo

4 - Distribuio de Credenciais modelos push e pull

Existem dois modelos fundamentais para distribuio de certificados contendo as credenciais (permisses, papis, etc) de um usurio: o modelo push e o modelo pull. O modelo push utilizado em ambientes onde necessrio que o cliente empurre (push) seus certificados de atributos para o servidor. O resultado disso que o servidor no precisa fazer nenhum tipo de busca para encontrar os atributos do cliente, o que melhora o desempenho. O modelo push ideal nos casos em que os direitos e privilgios do cliente so definidos e atribudos no domnio do cliente.

Figura 2 Modelo Push de propagao

No modelo pull,o cliente simplesmente se autentica e o servidor por sua vez puxa (pull) os certificados de atributos do cliente de algum repositrio. Ele ideal nos casos em que os privilgios do cliente so definidos e atribudos no domnio do servidor.

Figura 3 Modelo Pull de propagao

Tipicamente o modelo push aplicado da seguinte forma: uma requisio de acesso submetida ao servio de autorizao juntamente com o certificado de atributos do cliente que originou a requisio. O servio de autorizao decide se o acesso deve ou no ser permitido baseado nas informaes contidas nos atributos do certificado, na poltica de controle de acesso em vigor e na validade do certificado. Vrios fatores podem colaborar para que um certificado seja considerado invlido, mas os dois principais so: o certificado expirou (ou seja, seu prazo de validade venceu) ou ele foi revogado, seja porque o portador no mais considerado um usurio aprovado do sistema ou porque seu conjunto de privilgios foi alterado. O primeiro caso fcil de se verificar j que o certificado contm o prazo de validade em um dos seus atributos. J a revogao mais complicada de se tratar no modelo push. A soluo usual adotada de fazer com que a autoridade emissora do certificado publique listas de revogao de certificados (CRLs) contendo os certificados que no devem mais ser considerados vlidos. O principal problema com as CRLs que essas listas so publicadas periodicamente, de forma que a revogao de privilgios de um certo usurio no entre em vigor imediatamente. Outros mecanismos tambm foram propostos, como, por exemplo, o OCSP [5], que um protocolo que permite a verificao online da validade de um certificado junto entidade certificadora. J no modelo pull, o servio de autorizao responsvel por obter as informaes necessrias ao invs de depender dos dados fornecidos pelo usurio. Nesse modelo, as informaes de autenticao so mantidas no lado servidor sob a forma de certificados de atributos. Esses certificados so em geral armazenados em repositrios confiveis tipicamente servios de diretrio LDAP. A revogao de certificados suportada diretamente por esse modelo atravs da simples

remoo do certificado de atributo correspondente. Uma discusso mais detalhada sobre o assunto pode ser encontrada em [4].

5 Projetos estudados
Akenti Authorisation Infraestructure O Akenti uma infra-estrutura de autorizao desenvolvida no Lawrence Berkeley National Laboratory [7]. O principal objetivo do projeto de fornecer uma maneira de expressar e fazer valer uma poltica de controle de acesso de forma distribuda, evitando os problemas que aparecem quando uma nica pessoa responsvel por gerenciar e garantir os requisitos de controle de acesso. O controle de acesso aos recursos tem sido feito por um longo tempo com o uso de listas de controle de acesso. Essas listas so gerenciadas e controladas por uma nica pessoa, que responsvel pela manuteno da poltica de controle adotada. O problema que nem sempre adequado centralizar esse tipo de gerenciamento, pois possvel que mais de uma pessoa tenha autoridade para decidir como o acesso ao recurso deve ser feito. Nesse caso, o uso de listas de controle de acesso totalmente inadequado, pois o carter centralizado desse tipo de mecanismo impede que mudanas feitas por uma das pessoas envolvidas possam ser aplicadas imediatamente. Uma requisio tem que ser feita para o controle central, que tem que verificar se a requisio foi originada por uma parte autorizada, checar se a requisio no foi alterada durante o envio e s ento aplicar as mudanas apropriadas. Isso compromete a escalabilidade, principalmente nos casos em que as partes envolvidas na definio da poltica de controle de acesso esto distribudas geograficamente. O Akenti foi desenvolvido para lidar com essa situao, promovendo o gerenciamento distribudo da poltica de acesso aos recursos. Nele, uma parte envolvida na definio da poltica pode gerenciar os seus requisitos de controle de acesso independentemente de outras partes. Alm disso, cada parte pode modificar seus requisitos a qualquer momento e pode ter certeza de que as mudanas iro entrar em vigor imediatamente. O Akenti realiza decises de autorizao baseado em um conjunto de documentos digitalmente assinados que possuem as instrues de autorizao. A PKI e protocolos seguros de troca de mensagens fornecem autenticao de identidades e integridade de mensagens respectivamente. A figura a seguir ilustra a arquitetura e os principais componentes do Akenti:

Figura 4 Akenti - Arquitetura

No Akenti, os recursos a serem protegidos so configurados como Resource Servers. Clientes se autenticam aos Resource Servers utilizando certificados de chave pblica X.509. As requisies so delegadas ao Policy Engine, que responsvel por encontrar as polticas de acesso definidas para o recurso, as credenciais do cliente e decidir se o acesso deve ou no ser concedido. Tanto as polticas de acesso quanto as credenciais do cliente so armazenadas em certificados digitais que se encontram distribudos em diversos Certificate Servers. Todas as aes do Policy Engine so registradas no Log Server para auditoria. Um cach pode ser opcionalmente utilizado para evitar que o Policy Engine tenha que procurar sempre pelas credenciais de um cliente que j fez requisies anteriormente. Para implementar o gerenciamento distribudo de polticas de controle de acesso, o Akenti faz uso de uma srie de certificados digitais. As pessoas que possuem autoridade para criar polticas de acesso geram certificados de condio de uso, que so criados e assinados pelo Use-Condition Generator. As Attribute Authorities nas quais o Policy Engine confia podem gerar e assinar certificados de atributos contendo as credenciais dos usurios atravs do Attribute Generator. J as Certification Authorities confiveis geram os X.509 PKCs que so usados pelo cliente durante a autenticao. A figura a seguir ilustra a gerao dos certificados:

Figura 5 Akenti - Certificados

O Akenti suporta o RBAC se a poltica de condio de uso for descrita em funo dos papis dos usurios e os certificados de atributos gerados pelas AAs contiverem os papis de cada usurio como credenciais. Entretanto o Akenti bem flexvel nesse ponto e permite que outros mtodos de controle de acesso sejam aplicados, no apenas o RBAC. Como desvantagens, podemos citar que a nica forma de autenticao suportada pelo Akenti atravs de certificados de chave pblica, dificultando sua utilizao em recursos que aceitam outras formas de autenticao, como login-senha ou anlise impresso digital, por exemplo. Alm disso, todos os certificados gerados pelo Akenti so proprietrios, incluindo os certificados de atributos, que no aderem ao padro proposto pela PMI que usa os X.509 ACs como certificados de atributos. PERMIS O PERMIS [6] (PrivilEge and Role Management Infraestructure Standards) uma infra-estrutura de autorizao financiada pela European Commission (EC) e desenvolvida no instituto de segurana da informao da universidade de Salford, UK. O objetivo do projeto implementar uma PMI baseada nos certificados de atributos X.509. O Permis utiliza o RBAC como mecanismo de controle de acesso. Todos os dados necessrios para decises de autorizao, como a especificao dos papis e os privilgios alocados a cada papel, so descritos por uma poltica de autorizao, que por sua vez armazenada em um certificado digital para garantir sua integridade. O Permis escolheu o XML como linguagem para descrio dessa poltica porque XML possui um extenso conjunto de ferramentas de suporte e tem se consolidado como um padro na indstria. Algum tempo depois do Permis ter definido o seu DTD, o consrcio Oasis comeou um trabalho para definir a

Extensible Access Control Markup Language ou XACML [8]. Apesar do Permis no aderir XACML, muitas similaridades existem entre os dois formatos de descrio da poltica de controle de acesso. Tanto o AC contendo a poltica de acesso bem como os ACs contendo os papis associados a cada usurio so armazenados em servios de diretrio LDAP distribudos, implementando um modelo pull para distribuio dos ACs. Nesse caso, as listas de revogao (CRLs) no so necessrias uma vez que a entidade emissora dos certificados (Attribute Authority) pode simplesmente remover os certificados que no so mais vlidos do seu repositrio. A arquitetura do Permis composta por um subsistema de alocao de privilgios, que responsvel por alocar privilgios aos usurios, e um subsistema de verificao de privilgios, que responsvel por autenticar e autorizar usurios. O componente principal do subsistema de alocao de privilgios Privilege Allocator. Atravs dele, as Attribute Authorities podem associar papis aos usurios na forma de certificados de atributos. ele quem gera e assina os certificados de atributos contendo os papis dos usurios e tambm o AC que contm a poltica de controle de acesso. Os ACs gerados so armazenados em um diretrio LDAP. J o subsistema de verificao de privilgios autentica e autoriza usurios, verificando suas permisses de acesso. A funcionalidade desse subsistema foi dividida em duas partes: um componente especfico de aplicao para realizao da autenticao, chamado de AEF ou Access-Control Enforcement Function, e um componente independente de aplicao, chamado de ADF ou Access-Control Decision Function. Cada aplicao pode definir a sua forma de autenticao independentemente da autorizao (por exemplo, utilizando PKI com X.509 PKCs ou simplesmente um par usurio-senha). A comunicao entre a AEF e a ADF feita atravs da Permis API, uma API baseada na AZN API [9] definida pelo Open Group. A figura a seguir ilustra a arquitetura do Permis, com seus principais componentes:

Figura 6 Permis Arquitetura.

Como podemos observar, o Permis fornece um mecanismo de autorizao para proteo de recursos baseado no RBAC, implementando inclusive o modelo RBAC1. Ao contrrio do Akenti, o Permis bem flexvel quanto ao mecanismo de autenticao utilizado e suporta qualquer forma de autenticao. Alm disso, ele adere aos certificados de atributo X.509 definidos pela PMI, o que facilita sua interoperabilidade com diversas Attribute Authorities. No Akenti, as AAs envolvidas precisam gerar os certificados usando ferramentas prprias do Akenti, pois o formato do certificado no padronizado.

6 Concluso
Uma grande parte dos sistemas que foram desenvolvidos nos ltimos anos utiliza algum modelo de RBAC para suportar controle de acesso. Esse mecanismo est presente desde frameworks especficas de segurana at servidores de aplicao, o que comprova o seu fortalecimento e amadurecimento como meio para fornecer controle de acesso a recursos computacionais. O Permis um exemplo de sucesso do uso do RBAC em combinao com os certificados de atributos X.509 definidos pela PMI para prover um servio de autorizao robusto e confivel.

7 Referncias
[1] R.S. Sandhu, E.J. Coyne, H.L. Feinstein, C.E. Youman, Role based access control models, IEEE Comput. 29, 1996. [2] ITU-T Rec. X.509 ISSO/IEC 9595-8, The Directory: Public-key and Attribute Certificate Frameworks, 2001. [3] An Internet Attribute Certificate Profile for Authorization, Abril 2002, http://www.ietf.org/rfc/rfc3281.txt [4] J. Crampton, H. Khambhammetu, Authorization and Certificates: Are we pushing when we should be pulling? Proceedings of the IASTED International Conference on Communication, Network, and Information Security, 2003, p 62-66 [5] Online Certificate Status Protocol OCSP, Junho 1999, http://www.ietf.org/rfc/rfc2560.txt [6] D.W. Chadwick, A. Otenko, The PERMIS X.509 role based privilege management infrastructure, Future Generation Computer Systems, Volume 19, Edio 2, Fevereiro 2003, p 277-289. [7] Akenti Authorization Infrastructure. http://dsd.lbl.gov/Akenti [8] OASIS eXtensible Access Control Markup Language http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml [9] Open Group. Authorization (AZN) API, Janeiro 2000, ISBN 1-85912-266-3