182 Simpsio Brasileiro de Redes de Computadores

355

PoliCap - Um Servio de Poltica para o Modelo CORBA de Segurana

Carla Merkle Westphal, Joni da Silva Fraga e Michelle Silva Wangham Universidade Federal de Santa Catarina - LCMI-DAS-UFSC Campus Universitrio - Trindade - Florianpolis - SC - Brasil C.P. 476 - CEP 88040-900 e-mail: {merkle, fraga, wangham}@lcmi.ufsc.br
Resumo - Este artigo prope o PoliCap - um Servio de Poltica a ser utilizado por aplicaes distribudas que utilizam o modelo CORBA de segurana. O PoliCap foi projetado para ser inserido no contexto do projeto de segurana JsCoWeb. Esse projeto est desenvolvendo um esquema de autorizao com o objetivo de concretizar a gerncia de polticas de segurana em redes de larga escala como a Internet. O servio de poltica PoliCap supre a carncia existente na utilizao de polticas de segurana para a programao com objetos distribudos. O artigo ainda apresenta os resultados de uma implementao realizada e a avaliao dos mesmos usando o Critrio Comum de Segurana, padro ISO 15408. Palavras-chave - Segurana, Polticas de segurana, Esquema de autorizao, CORBA. Abstract - This paper presents Policap - a Policy Service to be uilized for distributed applications that use CORBA security model. Policap was proposed for insertion in the JaCoWeb Security Project. This project is developing an authorization scheme in order to deal with management of security policies in large-scale networks, such as the Internet. The Policap policy service fills in the existing gap in the use of security policies for distributed object programming. The paper further presents the implementation resuits obtained and an evaluation of these resuits based on Common Criteria, ISO standard 15408. Keywords - Security, Security Policies, Authorization Scheme, CORBA.

1 INTRODUO Atualmente, negcios tornam-se cada vez mais dependentes de seus sistemas de informao e, portanto, necessitam tambm que essas informaes sejam acessadas de forma correta e segura. Nos sistemas distribudos de larga escala, a proteo da informao uma tarefa difcil de ser realizada j que a proteo fsica dos computadores que contm informaes estratgicas dificilmente atingida. Alm disso, como a informao compartilhada, tecnicamente, qualquer pessoa pode ter acesso ao sistema atravs da rede. A gerncia de polticas de segurana em sistemas de larga escala como a Internet uma questo muito importante atualmente. Entretanto, apresenta vrias dificuldades devido a existncia de um grande nmero de usurios, objetos e operaes, a falta do uso de polticas de segurana e ambientes heterogneos presentes em redes de larga escala. Dessa forma, a complexidade e a escalabilidade dificultam a gerncia das polticas de segurana [1]. A complexidade inerente aos sistemas de objetos distribudos causa vulnerabilidades adicionais que devem ser contidas pela arquitetura de segurana. Dentre estas vulnerabilidades, o controle de acesso em sistemas de larga escala problemtico, j que sistemas de objetos distribudos podem crescer sem limites e componentes so constantemente adicionados, removidos e modificados nestes ambientes. Em sistemas geograficamente muito grandes normalmente existem diferentes domnios de polticas de segurana, o que dificulta suas administraes. No sentido de minimizar estes problemas a OMG (Object Management Group)1 introduziu o CORBAsec que um modelo de segurana que, quando implementado e administrado corretamente, pode prover um alto nvel de segurana para informaes e aplicaes de objetos distribudos em ambientes de larga escala. Segundo este modelo, quando um objeto criado e feito visvel via CORBA em um sistema, automaticamente ele tambm torna-se membro de um ou mais domnios de polticas de segurana. Entretanto, as propostas includas no modelo so recentes e alguns problemas so facilmente identificados: as especificaes atuais [2] no cobrem procedimentos para gerenciar membros dos domnios e no definem procedimentos para incluir ou remover polticas [2] [3].
Doutoranda (bolsista da CAPES) do Curso de Ps-Graduao em Engenharia Eltrica da UFSC. ' um consrcio de empresas com o objetivo de especificar um conjunto de padres e conceitos para a programao orientada a objetos em ambientes distribudos abertos.

182 Simpsio Brasileiro de Redes de Computadores

369

relao a cada objetivo de segurana, em conformidade com todos os outros requisitos definidos em [16], pode-se definir que o prottipo estende o CAPP no sentido de usar uma poltica de segurana discricionria, sendo considerado um TOE nvel EAL3. Isso quer dizer que o prottipo metodicamente testado e verificado, ou seja, o prottipo aplicvel a circunstncias onde se necessita um nvel moderado de segurana em um TOE convencional.
6 TRABALHOS RELACIONADOS

A literatura apresenta alguns trabalhos sobre gerncia de polticas de segurana em ambientes de larga escala. A prpria especificao do servio de gerncia de domnios [3] do CORBAsec no est padronizada. Um projeto acadmico que pode ser mencionado o Cherubim [17]. O Contrai [18] um produto que implementa o CORBAsec e a gerncia de polticas de segurana. A arquitetura de segurana do projeto Cherubim consiste de duas partes: uma IDL CORBA estendida com o objetivo de automatizar a ligao entre polticas de segurana e aplicaes e, um framework de segurana para agentes dinmicos. Seu principal objetivo construir um sistema de segurana dinmico capaz de prover mecanismos de segurana especficos para aplicaes em um ambiente mvel e de larga escala. O controle de acesso nesse projeto foi desenvolvido usando-se o conceito de capabilities, que carregam os direitos de acesso do principal at a mquina do servidor onde ocorre o processo de autorizao. O projeto elaborou interfaces para manipular polticas de autorizao discricionrias, mandatrias (MAC) e baseadas em papis (RBAQ mas no utiliza os objetos COSS do CORBAsec implementando objetos prprios. O ORB utilizado o JacORB [5] e os servios criptogrficos so implementados com a API criptogrfica do Java 1A1K [13]. O Contrai [18] um ORB que estende o ORBAsec com os servios COSS do CORBAsec que implementam servios de autenticao, transmisso segura de mensagens e controle de acesso automtico. A poltica de autorizao discricionria estabelecida com uma linguagem de controle de acesso usada por objetos servidores para definir seus objetos de poltica. A interceptao do controle de acesso executada no lado do objeto servidor. A gerncia de polticas de segurana feita usando-se o mdulo de gerncia de domnios. Comparando o PoliCap com as experincias apresentadas, verificamos que o PoliCap um servio que realiza o controle de acesso no lado do cliente, ao contrrio das propostas descritas. O PoliCap combina caractersticas do Cherubim, como as capabilities, e do Control, com o adicional do uso restrito de objetos padronizados ou em via de padronizao no CORBAsec. 7 CONCLUSES O PoliCap preenche uma lacuna no gerenciamento de polticas de segurana existente no modelo CORBAsec, concretizando o primeiro nvel de controle de acesso do projeto JaCoWeb. O segundo nvel de controle de acesso desenvolvido com o uso das capabilities propostas para o modelo CORBAsec. O PoliCap e as capabilities para o CORBAsec fornecem uma contribuio importante para gerenciar polticas de autorizao em redes de larga escala. Importante tambm a descrio do funcionamento dinmico relativo aos objetos de servio e interceptadores do CORBAsec. O prottipo uma experincia real de implementao do modelo discricionrio do CORBAsec, considerando que existem poucas experincias desse tipo disponveis. Esse prottipo facilita a gerncia e administrao de polticas de segurana, permitindo que a segurana seja garantida a nvel de ORB. A segurana garantida a nvel de ORB tem vantagens como transparncia da segurana para aplicaes e maior confiana nos servios de segurana que so sempre executados.

TOE e de seus requisitos e testes funcionais. Para tanto, desenvolveu-se um ST para o prottipo, que chamado ST-Prottipo-JaCoWeb. Esse ST atua em conformidade com o [16] atendendo o nvel EAL3 do CC. O ST-Prottipo-JaCoWeb, como definido para um ST, composto por uma descrio do TOE, pelas ameaas s quais o TOE est sujeito, pelas polticas de segurana, por objetivos de segurana que determinam os requisitos funcionais que devem existir no sistema e uma declarao da conformidade a algum PP disponvel e certificado (como o CAPP). A descrio do TOE j foi apresentada na seo 4. As ameaas (Threats) que o prottipo espera impedir so designadas da seguinte forma: T.ACCESS, onde um usurio obtm acesso a informaes ou recursos do sistema sem ter a devida permisso, T.CAPTURE, onde um invasor pode modificar ou obter informaes pela escuta da linha de transmisso, T.INTEGRITY, onde a integridade das informaes transmitidas pode ser comprometida devido a erros do usurio ou de transmisso, T.SECRET, onde um usurio do prottipo pode obter informaes do sistema para as quais no tem permisso de maneira intencional ou acidental e T.IMPERSON, onde um invasor pode obter acesso a informaes ou recursos por se fazer passar por um usurio autorizado do prottipo. Alguns tipos de ameaas no podem ser contidas no prottipo construdo: o abuso por parte dos usurios autorizados de forma que ocorra consumo excessivo dos recursos e, consequentemente, negao de servio a outros usurios autorizados, e, no h como responsabilizar um usurio sobre os atos cometidos pois servios de auditoria no esto presentes. Dentre os tipos de polticas de segurana existentes no prottipo esto a poltica discrionria designada P.DAC (Discretionary Access Control) que visa impedir a ocorrncia das ameaas acima citadas. Os direitos de acesso aos recursos e informaes fornecidos pelo prottipo esto disponveis atravs dos objetos DomainAccessPolicy e RequiredRights. Os objetivos de segurana so determinados a fim de estabelecer os requisitos funcionais necessrios para conter as ameaas definidas para um sistema e concretizar a poltica de segurana estabelecida. Dentre os objetivos de segurana definidos que esto em conformidade com o CAPP esto os seguintes: O.AUTHORIZATION, que estabelece que as funes de segurana do prottipo devem ser implementadas de forma que apenas usurios autorizados tenham acesso ao sistema, O.DISCRETIONARY_ACCESS, que estabelece que as funes de segurana do prottipo devem fornecer permisses de acesso aos recursos e informaes baseado nos atributos de privilgio dos sujeitos, O.MANAGE, que estabelece que o prottipo deve fornecer suporte ao administrador autorizado do sistema e O.ENFORCEMENT, que estabelece que o prottipo deve ser projetado e implementado de forma aplicar as polticas de segurana no lado do objeto servidor da aplicao. Cada objetivo de segurana implementado por um conjunto de requisitos funcionais definidos para o prottipo. Como o prottipo est sendo avaliado em conformidade com [16], pode-se assumir o mesmo conjunto de requisitos funcionais e de garantia de segurana. Apenas como exemplo, o objetivo O.DISCRETIONARY_ACCESS implementado pelos seguintes requisitos de segurana: FDP_ACC.l (poltica de controle de acesso discricionria, implementada pelos objetos do CORBAsec), FPD_ACF.l (funo de controle de acesso implementada pelo objeto ServerAccessDecision), FIA_ATD.l (definio de atributos do usurio feita de forma esttica no prottipo), FIA_USB. l (ligao entre usurio e principal que estabelecida caso o usurio seja gerente ou cliente do servidor bancrio do prottipo), FMT_MSA.l (gerncia dos atributos de segurana dos objetos, implementada pelo objeto RequiredRights do CORBAsec) e FMT_MSA.3 (inicializao de atributos estticos, implementado para gerenciar os objetos de poltica no prottipo). Verificando cada um dos requisitos funcionais e de garantia existentes no prottipo, com

l S2 Simpsio Brasileiro de Redes de Computadores

367

carregados, livrando os applets das restries impostas pelo modelo sandbox do Java, permitindo comunicao com quaisquer objetos sem limite de localizao. Dessa forma o servidor Web e o servidor da aplicao no necessitam permanecer na mesma mquina. O objeto PrincipalAuthenticator, responsvel pela autenticao e criao do objeto Credential, no foi implementado nesse primeiro prottipo. As credenciais do prottipo so criadas estaticamente e possuem atributos de segurana que identificam os direitos do cliente no sistema e o mecanismo de segurana que est sendo utilizado (SSL, no nosso caso). O PoliCap e as capabilities representam uma evoluo do prottipo inicial. A presena desses dois componentes far com que o nosso modelo retome o seu formato original, como apresentado na figura 2, onde a autorizao tambm realizada na mquina do cliente. 5 AVALIAO DO PROTTIPO USANDO O CRITRIO COMUM DE SEGURANA O Critrio Comum (Common Critrio - CC) para avaliao da segurana o resultado do esforo de vrias organizaes internacionais pra desenvolver um nico critrio de avaliao da segurana para sistemas e produtos de tecnologias de informao em sistemas distribudos. Esse critrio deriva de padres anteriores como TCSEC (ou livro laranja), ITSEC, CTCPEC e conta com a colaborao do Canad, Frana, Alemanha, Holanda, Inglaterra e Estados Unidos. Tomou-se padro ISO 15408 em 1999 [14]. O CC [14] define como expressar os requisitos de segurana de um sistema ou produto, define categorias distintas de requisitos funcionais (functional requirements) e requisitos de garantia (assurance requirements). Os requisitos funcionais definem o comportamento de segurana desejado. Os requisitos de garantia so o fundamento para se conquistar a confiana de que as medidas de segurana solicitadas esto efetiva e corretamente implementadas. A confiana na segurana de uma tecnologia de informao pode ser obtida atravs das aes realizadas durante o processo de desenvolvimento, avaliao e operao. Alguns conceitos importantes desse critrio compreendem o TOE, PP e ST. O objeto de avaliao (TOE - Target of Evaluation) a parte do produto ou sistema que est sujeita avaliao, no nosso caso, o TOE a ser considerado o prottipo desenvolvido. O proflle de proteo (PP - Protection Profile) uma definio de conjuntos de requisitos e objetivos, independentes de implementao, que permite aos consumidores e desenvolvedores criar conjuntos padronizados de requisitos de segurana que estejam de acordo com suas necessidades. No caso da avaliao do prottipo realizada foi utilizado um PP registrado e aceito como padro, designado Controlled Access Protection Proflle (CAPP) [16], que define requisitos e objetivos relativos a um objeto de avaliao e utiliza, dentre outras caractersticas, polticas discricionrias. As ameaas de segurana ao TOE, os objetivos, os requisitos e a especificao resumida das funes e garantias de segurana, juntos, formam as entradas principais ao alvo de segurana (ST Security Target). O ST contm os objetivos de segurana e requisitos de um TOE especfico e define as medidas funcionais e de garantia oferecidas por esse TOE para preencher os requisitos determinados. O ST pode declarar conformidade a um ou mais PPs e forma a base para uma avaliao. O CC fornece garantia de segurana de um TOE usando o conceito de investigao ativa que uma avaliao de um sistema ou produto de tecnologia da informao a fim de determinar suas propriedades de segurana. Tcnicas de avaliao que podem ser usadas so: anlise do projeto do TOE e de seus requisitos, testes funcionais, anlise de vulnerabilidades, dentre outras. A exemplo de critrios anteriores, o CC tambm possui um conjunto de nveis de garantia de segurana. Os nveis EALs (Evaluation Assurance Leveis) uniformizam o modo de balancear a garantia obtida com o custo e possibilidade de adquirir tal grau de garantia. Existem sete nveis de garantia: EAL1, EAL2, EAL3, EAL4, EAL5, EAL6 e EAL7. As tcnicas utilizadas para avaliar o prottipo desenvolvido foram: anlise do projeto do

nico domnio de nomes. A figura 5 sintetiza as funcionalidades implementadas no prottipo. Dentre os objetos implementados nesse prottipo (alm do applet e servidor da aplicao) esto os objetos ServerAccessDecision, Vault, SecurityContext, DomainAccessPolicy, RequiredRights, SecurityManager e PolicyCurrent do modelo CORBA de segurana. Esses objetos usam outros servios CORBA (COSS) como o servio de nomes. O controle de acesso executado pelo prottipo baseado no mecanismo de lista de acesso implementado pelos objetos DomainAccessPolicy e RequiredRights. As entidades que esto sujeitas aos controles de segurana no nosso sistema so os principais (com seus atributos de privilgio) e os objetos servidores da aplicao (com seus atributos de controle). O objeto ServerAccessDecision responsvel pela validao dos pedidos de acesso aos mtodos do objeto servidor, interagindo com os objetos DomainAccessPolicy e RequiredRights. O mtodo access_allowed (figura 6) do objeto ServerAccessDecision obtm os direitos requeridos invocando o mtodo get_required_rights do objeto RequiredRights e obtm os direitos fornecidos pela poltica DomainAccessPolicy invocando o mtodo get_effective_rights. Compara os direitos requeridos e os direitos fornecidos ao atributo de privilgio para decidir se o mtodo a ser invocado pode ou no pode ser executado.

Figura 6. Mtodo access_allowed do objeto ServerAccessDecision.

Os objetos DomainAccessPolicy e RequiredRights residindo somente na mesma mquina do servidor da aplicao (controle de acesso apenas no lado do servidor) torna desnecessrio o uso de capabilities em um segundo nvel de controle. Esses objetos so criados estaticamente, em tempo de ligao entre os objetos de aplicao comunicantes. A insero, atualizao e remoo de direitos nesses dois objetos so executadas pelos prprios objetos servidores da aplicao, logo depois de se registrarem no servio CORBA de nomes (CosNaming). A implementao usa como mecanismos de desvio os interceptors presentes no JacORB. No prottipo, o nico interceptador de controle de acesso criado na mquina do servidor de aplicao. O interceptador de controle de acesso invoca o objeto ServerAccessDecision que, por sua vez, interage com os objetos RequiredRights e DomainAccessPolicy para a autorizao na mquina do servidor. No prottipo, foram utilizadas as funes criptogrficas IAIK-JCE e o pacote iSaSiLk v.5.2 que implementa o SSL v3 em Java (disponvel em [13]). Toda a negociao e uso do SSL, no prottipo, executada de forma transparente pelo iSaSiLk [19], A assinatura digital do modelo de segurana do Java foi utilizada para permitir aos clientes acesso ao disco local ou conexes com mquinas diferentes a partir das quais foram

l S2 Simpsio Brasileiro de Redes de Computadores

365

credencial do cliente. Depois das incluses para gerar a capability, o Request fica representado como na figura 4.
IOR servidor Request novo com a capability (IOR, mtodo, emissor, nonce) Campos adicionados Request antigo Identificador Nonce Rondam Mtodo solicitado Emissor

Figura 4. Estrutura do Request com campos adicionais para implementar a capability. Em tempo de deciso de acesso, o interceptador de controle de acesso no lado do servidor faz a verificao da capability. Dessa forma pode-se construir capabilities para cada uma das invocaes de um cliente no CORBAsec. Essas capabilities so utilizadas para formar um segundo nvel de controle de acesso no esquema de autorizao JaCoWeb. 4 RESULTADOS DE IMPLEMENTAO Um prottipo - incluindo o servio de polticas PoliCap e o mecanismo de capabilities foi desenvolvido em nossos laboratrios (figura 5). Uma aplicao exemplo constituda de um sistema bancrio composto por um objeto servidor CORBA e um applet cliente Java foi construda para testar as implementaes deste prottipo. O objeto servidor CORBA foi desenvolvido com a ferramenta JacORB 1.0 [5], um ORB Java/ree, e o applet cliente foi implementado com a ferramenta JDK 1.2.1. O browser Netscape Communicaror 4.5 tambm foi usado como ambiente para a interao entre o cliente e o servidor. O objetivo dessa implementao foi de concretizar uma poltica de controle de acesso discricionria baseada nas estruturas definidas no CORBAsec.

SSL (Secure Socket Luyer) - SaSLk

Figura 5. Estrutura do Prottipo Implementado.

Essa verso do PoliCap preocupou-se em amadurecer primeiramente, todo o aspecto dinmico dos objetos de servio do CORBAsec, o que no uma tarefa trivial. Isso porque a especificao utilizada extremamente ampla [2] e o dinamismo de uma aplicao que usa o CORBAsec no descrito na literatura, portanto, requer um esforo considervel e prev o entendimento de um grande nmero de objetos. Portanto, foi feito um experimento que no comporta ainda os objetos DomainAccessPolicy e RequiredRights locais, estabelecidos em tempo de ligao entre cliente e servidor. O experimento implementa polticas discricionrias, estando limitado a uma nica verificao de controle de acesso no lado do servidor. O prottipo tambm est limitado a um

primeira requisio. As requisies de operaes subseqentes na interface do servidor sero validadas apenas com o mecanismo de competncias. Os dois nveis de controle de acesso reduzem o trfego de rede em caso da negao de acesso e ao mesmo tempo a segurana do sistema no depende unicamente da integridade do cliente. O mecanismo de competncia? no padronizado pelo CORBAsec, embora exista a sugesto sobre o uso de capabilities em [2], a partir das abstraes criadas no modelo. No se pode afirmar que exista uma definio universal do contedo de uma capability. Tradicionalmente, uma capability deve conter a referncia de um objeto e um conjunto de direitos. A capability define os direitos do detentor sobre o objeto em questo. Em [8], uma capability clssica representada como a tripla (IdObject, Rights, Random) contendo o nome do objeto, um conjunto de direitos de acesso e um nmero aleatrio, respectivamente. O nmero aleatrio previne falsificao, sendo normalmente resultado de uma funo one-wayf, aplicada sobre o identificador do objeto e os direitos sobre o mesmo (Random = f (IdObject, Rights))*. Quando uma requisio chega no lado do servidor, com a sua respectiva capability, a funo one-way f executada novamente e o seu resultado conferido com o nmero aJeatrio enviado para detecar possveis modificaes na mensagem da requisio (tampering). Este nmero aleatrio que faz o papel de um nonce, assegura tambm a propriedade de 'freshness' f 10] da requisio do cliente. Assim como no pode ser possvel falsificar uma capability, tambm no deve ser possvel reutiliz-la ou repass-la a terceiros. Para isto, normalmente, alm do nmero aleatrio includo em uma capability um campo de identificao do solicitante da operao (o cliente). A capabilities so protegidas por mecanismos de cifragem quando transmitidas no suporte de comunicao [8]. No esquema JaCoWeb, as capabilities so criadas dinamicamente a cada requisio do cliente para operaes no servidor. A classe Request (estrutura do pedido) definida nas especificaes CORBA usada na composio de uma capability no nosso esquema. Uma capability no JaCoWeb contm nos seus campos: a IOR (Interoperable Object Referenc) do objeto servidor, representando a identidade da entidade sobre a qual a capability fornece os direitos de acesso; o mtodo solicitado, representando o direito; o identificador do emissor/principal, representando a identidade da entidade solicitante da operao; e um nonce que assegura a propriedade 'freshness' do pedido. Em um Request de uma invocao usual no CORBA, o IOR do objeto servidor e a identificao do mtodo solicitado j esto presentes. Os outros dois campos da capability, identificador do emissor do pedido e um campo de nonce, devem ser inseridos no Request durante a interceptao de alto nvel, no objeto AccessDecision do lado do cliente. O valor de nonce calculado da seguinte forma:
nonce =/{identifcador do emissor, mtodo solicitado, IOR do servidor, Random);

onde / corresponde funo hash one-way SHA, presente no pacote java.security [11]. O valor Random um nmero aleatrio calculado fazendo uso da classe java.security.SecureRandom da API Criptogrfica do Java JDK 1.2 [l 1]. Este valor aleatrio uma redundncia que garante a propriedade freshness da mensagem do Request, garantindo contra os ataques por mensagens antigas [8], Os valores de Random so inseridos nas mensagens de Request e enviados para o servidor funcionando como um contador de mensagens. Todos os pedidos de operaes do cliente sobre a interface do servidor, tero as mensagens correspondentes enviadas pela associao segura, seguindo a numerao de seqncia Random, Random+1, Random+2,... . O identificador do emissor (ou solicitante da operao) conseguido a partir da
1 Existem vrios algoritmos prticos que implementam funes one-way hash. Os algoritmos de MD4, MD5 e SHA so exemplo destas funes [9].

18e Simpsio Brasileiro de Redes de Computadores

363

autorizao definida e o objeto de poltica correspondente com o domnio de poltica. A operao delete_policy da interface DomainAccessPolicyAdmin remove a poltica de autorizao (e o objeto de poltica correspondente) do domnio. A operao get_local_domain_policy da interface DomainAccessPolicyAdmin monta um objeto DomainAccessPolicy com os direitos efetivos (GrantedRights) presentes na poltica de autorizao relativas ao atributo de privilgio e os seus estados de delegao (sujeito). Na verdade esta operao monta localmente, em tempo de ligao, uma verso do DomainAccessPolicy, essencial na validao (em tempo de deciso de acesso) de diversas operaes existentes em uma mesma interface. Por exemplo, tomando o objeto DomainAccessPolicy com as informaes da tabela l - objeto global definido no domnio -, ao se executar a operao:
localDomainAccessPolicy = getjocal_domain_policy ( SecClientlnvocationAccessDiscretionary,'role,autordade,caixa', initiator),

o retorno desta operao o objeto DomainAccessPolicy - uma verso representada na tabela 3 - que deve atuar localmente no objeto AccessDecision de uma invocao.
Atributo de Privilgio roleicaixa Estado de Delegao Initiator Direitos Fornecidos (Granted Rights) corba: gu

Tabela 3. Objeto DomainAccessPolicy retornado pela operao get_local_domain_policy. A operao get_local_required_rights da interface RequiredRightsAdmin monta tambm uma verso local, com os direitos requeridos presentes no objeto RequiredRights global (centralizado) do servio de poltica do domnio. Esta verso do objeto RequiredRights, montada localmente em tempo de ligao, contm todas as linhas relativas a uma interface, considerando que um objeto cliente pode executar as diversas operaes definidas nesta interface de objeto de aplicao. Por exemplo, tendo-se o objeto RequiredRights (global) da tabela 2, ao se executar a operao:
localRequiredRights = getjocal_require<i_rights (Renda_fixa),

o valor de retorno da operao o objeto RequiredRights (local) representado na tabela 4.

Direitos Requeridos (RequiredRights) Corbaig Corba:gs Combinador de Direitos

AH Any

Operao Ver Saldo Depositar

Interface Renda Fixa Renda Fixa

Tabela 4. Objeto RequiredRights retornado pela operao get_local_required_rights. 3.3 Capabilities usando o CORBAsec No modelo CORBAsec, as decises de controle de acesso podem ser realizadas tanto no lado do cliente como no lado do servidor. O controle de acesso no lado do objeto destino definido nas especificaes do CORBAsec como normal. Mas, tambm salientado que quando as verificaes de controle de acesso so feitas no lado do cliente, as negaes de acesso ao objeto servidor determina uma reduo no trfego de rede. Nota-se tambm que em alguns ORB's, consideraes de integridade do sistema podem tomar indesejvel a confiana no controle de acesso feito unicamente no lado do cliente [2]. No JaCoWeb, o objetivo realizar o controle de acesso aos objetos distribudos visveis via CORBA, assumindo que, num primeiro nvel as verificaes so realizadas pelo objeto AccessDecision do cliente em parceria com o servio PoliCap. A execuo das operaes get_local_domain_policy e get_local_required_rights a partir da interceptao de controle de acesso em tempo de ligao, monta os objetos DomainAccessPolicy e RequiredRights locais. Estes objetos fazem parte da estrutura necessria no objeto AccessDecision do cliente para gerar capabilities (competncias) a serem verificadas no objeto AccessDecision do servidor. A verificao de alto nvel s feita uma vez, durante a ligao dos objetos cliente e servidor, na

disponveis atravs dos objetos DomainAccessPolicy e RequiredRights. As interfaces destes objetos permitem o acesso de polticas discricionrias. Aplicaes administrativas so responsveis pela definio desses objetos enquanto aplicaes operacionais utilizam esses objetos para realizar o controle de acesso [2]. De acordo com o servio CORBA de segurana, quando um objeto criado ele automaticamente toma-se membro de um ou mais domnios (domnios de polticas) ficando sujeito s polticas de segurana do domnio. Entretanto, a especificao atual [2] no possui procedimentos para gerenciar os membros dos domnios (incluir, remover, etc) e nem mesmo possui procedimentos para gerenciar os objetos de polticas de segurana. Os domnios de poltica de segurana so constitudos por colees de referncias de objetos que possuem um conjunto de polticas de segurana comuns e so gerenciados por um objeto gerente de domnio [3]. Este gerente tem como funo [6]: prover mecanismos para a criao e o acesso aos objetos de poltica no domnio; e tambm, manter as estruturas do domnio atualizadas. Entretanto, interfaces para adicionar novas polticas (novos objetos de poltica) aos domnios ou para modificar o membership de domnios ainda no esto padronizadas. A idia inicial para preencher estas lacunas est sendo proposta no servio de gerncia de membership de domnios de segurana (Security Domain Membership Management Service) [3], onde proposta a extenso da interface DomainManager com funes administrativas que sirvam para definir e remover objetos de polticas em um domnio. Mesmo com estas interfaces ainda no padronizadas no CORBAsec, sentiu-se a necessidade da introduo deste servio de gerncia de objetos de poltica no esquema de autorizao proposto. O servio desenvolvido - o PoliCap - se baseia em documentos drafts (propostas iniciais) liberados pela OMG [3] e certamente no estar muito distante das especificaes que devero em breve ser padronizadas. O PoliCap (figura 2) um servio que oferece operaes tanto para funes administrativas quanto operacionais sobre objetos de polticas, cumprindo o papel de gerente de domnio para objetos de poltica (DomainAccessPolicy) e de gerente de direitos para os objetos de direitos requeridos (RequiredRights) do nosso domnio. O esquema de autorizao proposto (JaCoWeb), inicialmente, foi definido como constitudo por um nico domnio e o servio de poltica atua como um servio centralizado de gerenciamento de polticas e de direitos. Aplicaes administrativas interagem com o PoliCap para gerenciar as polticas e direitos requeridos e, aplicaes operacionais ou objetos COSS, interagem com o servio de poltica para obter, em tempo de ligao, as polticas e os direitos requeridos necessrios aos controles em tempo de execuo sobre as invocaes de um mtodo. A idia que, em tempo de ligao, o servio de poltica (gerente de domnio) fornea os objetos DomainAccessPolicy e RequiredRights que atuam sobre uma invocao. A figura 3 descreve a interface do PoliCap.

Figura 3. Interface IDL do PoliCap. A operao set_policy da interface DomainAccessPoicyAdmin associa a poltica de

l S2 Simpsio Brasileiro de Redes de Computadores

361

objetos de poltica DomainAccessPolicy e de direitos requeridos RequiredRights que so usados localmente na validao de pedidos de acesso a objetos de aplicao. A partir dessa verificao de alto nvel so geradas capabilities (competncias) que so validadas localmente nos servidores remotos, completando ento o segundo nvel de controle de acesso definido em nosso esquema.

Figura 2. Estrutura do Controle de Acesso do Esquema de Autorizao JaCoWeb. Para montar esses dois nveis de controle de acesso, utilizamos os dois nveis de interceptao definidos no modelo CORBA de segurana e seus objetos de servio (COSS). A interceptao de alto nvel (Controle de Acesso), no lado do cliente (applet de aplicao), desvia para o objeto de servio AccessDecsion que obtm, em tempo de ligao, a partir do servio de poltica PoliCap (detalhado na seo 3.2), os objetos locais (DomainAccessPolicy e RequiredRights) a serem usados nas verificaes do mecanismo de capabilities em tempo de deciso de acesso. No lado do servidor da aplicao, a interceptao de alto nvel usada para validar a capability recebida com a requisio da invocao. A interceptao de baixo nvel (Chamada Segura) do modelo CORBA, em ambos os lados (cliente e servidor), usada para proteger em uma associao segura a mensagem que transporta a requisio com a capability. A representao de privilgios (ou direitos) na forma de capabilities no esquema de autorizao detalhada na seo 3.3. Alm dos controles citados acima, os controles criptogrficos tambm so necessrios no esquema e so definidos na forma de objetos de sevio CORBA que usam a tecnologia de segurana residente sob o ORB (objetos Vault e SecurityContext). Os objetos de servio Vault e SecurityContext e o interceptador de chamada segura relativos a associao segura, no esto representados na figura 2 pois so iguais aos da figura l, seguindo o modelo CORBAsec. 3.2 PoliCap O servio de poltica PoliCap, proposto neste artigo, tem como objetivo possibilitar o gerenciamento centralizado de objetos de poltica em um domnio de uma aplicao de objetos distribudos, suprindo a carncia nas especificaes do CORBAsec quanto ao gerenciamento de objetos de poltica. Segundo estas especificaes, as polticas de segurana so feitas

de Invocao (QOPPolicy, InvocatonCredentialPolicy, SecurityMechanismPolicy, EstablishTrustPolicy e DelegationDirecvePoHcy). Deve ento com estas informaes decidir quais mecanismos de segurana (cifragem, assinatura, etc.) sero usados na associao segura entre cliente e servidor, estabelecer a confiana entre ambas as partes, garantir a delegao e selecionar a credencial a ser usada na invocao. Esta credencial deve ser compatvel com os componentes de segurana que ficam registradas na IOR (Interoperable Object Reference) do objeto destino. O interceptador de chamada segura tambm estabelece o contexto de segurana (objeto SecurityContext) que ser usado para a proteo das mensagens (algoritmos de cifragem, etc). Em access decision time, o interceptador de controle de acesso invoca a operao access_allowed do objeto AccessDecision. A operao access_allowed responsvel por autorizar ou no a invocao, obtendo os direitos fornecidos pela poltica de autorizao DomainAccessPolicy (GrantedRights) e comparando os mesmos com os direitos requeridos (obtidos do objeto RequiredRights) para executar a operao na invocao. Em message protection time, o interceptador de chamada segura no lado do cliente, executa o mtodo send_message que chama o mtodo SecurityContext::protect_message para proteger as mensagens. Do lado do servidor, o mtodo receive_message do interceptador chama o mtodo SecurityContext::reclaim_message, para recuperar a mensagem.
3 PoliCap - UM SERVIO DE POLTICA PARA O CORBAsec

O PoliCap um servio de polticas para objetos distribudos cujas invocaes so reguladas segundo o modelo CORBAsec. O PoliCap foi projetado no contexto do projeto JaCoWeb e corresponde a um primeiro nvel de verificao do controle de acesso no esquema de autorizao. O segundo nvel de controle de acesso corresponde a um mecanismo de capabilities. A seguir descrito sucintamente o esquema de autorizao JaCoWeb. Na seqncia o servio de poltica proposto apresentado justificando-se a sua necessidade e relevncia. Por fim apresentado o mecanismo de capabilities. 3.1 JaCoWeb O JaCoWeb tem como objetivo o uso do modelo CORBA de segurana integrado com os modelos de segurana Java e Web de modo a compor um esquema de autorizao para aplicaes distribudas em redes de larga escala. Esse esquema est sendo desenvolvido com o objetivo de concretizar a implantao de polticas globais, o que representa um grande desafio, principalmente em redes de larga escala como a Internet [4]. Neste ambiente, aplicaes distribudas so expressas na forma de clientes representados por apples Java, e de objetos servidores de aplicao, visveis via CORBA. O esquema de autorizao define dois nveis de controle de segurana: o nvel global e o nvel local. Esses dois nveis so concretizados em objetos de servio COSS e por ncleos de segurana e TCB's (Trusted Computing Bases), respectivamente. Os objetos de servio, descritos na seo 2.1, concentram funes de identificao e autenticao de usurios e os controles de autorizao no acesso de objetos de aplicao visveis a nvel global. Os ncleos de segurana e TCB's, presentes em cada mquina do sistema, validam os acessos aos recursos locais. A figura 2 mostra os componentes principais que implementam os controles do nosso esquema. O applet de aplicao (figura 2), depois de autenticado, interage com o servio de nomes CORBA (CosNaming) [5], para obter, a partir do nome do objeto, a referncia ou IOR do objeto servidor de aplicao. Isso deve permitir a ligao com o objeto servidor. As chamadas executadas por esse applet de aplicao sobre um servidor remoto da aplicao esto sujeitas a dois nveis de controle de acesso. No nvel mais alto, a verificao ocorre em tempo de ligao, e uma vez validada a requisio, o servio de poltica PoliCap fornece verses dos

182 Simpsio Brasileiro de Redes de Computadores

359

[18]. O objeto SecurityManager mantm informaes de estado associadas com a instncia do ORB ou com o processo no qual o ORB reside. Por exemplo, referncias aos objetos RequiredRights e AccessDecision, que so utilizadas durante uma invocao, so armazenadas no objeto SecurityManager. Informaes de estado associadas aos objetos de poltica do contexto de execuo corrente residem no objeto PolicyCurrent. Importantes no estabelecimento de uma associao segura entre objetos clientes e servidores, os objetos de Polticas de Invocao definem caractersticas como a qualidade de proteo das mensagens, as credenciais a serem usadas na invocao, etc. Objetos de poltica da invocao que determinam os tipos de associaes possveis e o objeto DomainAccessPolicy que atua durante uma invocao, so acessados a partir do PolicyCurrent. O objeto Current armazena, no lado do servidor, as credenciais que so enviadas pelo cliente durante o estabelecimento de uma associao segura. Os objetos Vault e SecurityContext participam do estabelecimento de uma associao segura. Uma associao segura definida entre objetos cliente e servidor quando estabelecida a confiana entre as entidades atravs da autenticao. Esta autenticao se concretiza no instante em que as credenciais do cliente tomam-se disponveis no lado do servidor e quando estabelecido o contexto de segurana que ser usado para proteger as mensagens em trnsito. O objeto Vault cria credenciais em favor do objeto PrincipalAuthenticator, de acordo com a tecnologia de segurana subjacente, usada na autenticao. Alm disso, o objeto Vault tambm responsvel por criar os objetos de contexto de segurana SecurityContext nos lados do cliente e servidor em uma associao. O objeto SecurityContext armazena informaes do contexto de segurana que usado para proteger mensagens fornecendo integridade e/ou confidencialidade. 2.2 Interceptadores (Interceptara) Nas especificaes do modelo de segurana CORBA, os chamados servios ORB so implementados por intercepors. Logicamente, um interceptar interposto no caminho de uma chamada entre um cliente e um destino. Cada servio COSS relacionado com a segurana associado a um interceptor, cuja finalidade provocar o desvio transparente de uma invocao de mtodo, ativando um objeto de servio associado. No modelo CORBA de segurana so definidos dois interceptors que atuam durante uma invocao de mtodo, tanto no cliente como no objeto servidor da aplicao (figura 1): o Access Control Interceptor que em nvel mais alto provoca um desvio para realizar o controle de acesso na chamada e, o Secure Invocation Interceptar que faz uma interceptao de mais baixo nvel no sentido de fornecer propriedades de integridade e de confidencialidade nas transferncias de mensagens correspondentes invocao. Estes interceptadores definidos no CORBAsec so criados durante o processo de binding (ligao) entre dois objetos de aplicao que devem se comunicar. Os dois interceptadores citados esto ligados a diferentes funcionalidades em momentos distintos de uma invocao de mtodo. Em bind time (em tempo de ligao), o interceptador de controle de acesso responsvel por criar o objeto AccessDecision atualizando sua referncia no objeto SecurityManager. O objeto AccessDecision, por sua vez, em tempo de ligao, responsvel por disponibilizar os objetos de poltica (DomainAccessPolicy) do domnio. Isto ocorre como conseqncia da execuo da operao get_domain_policy do gerente de domnio - que resulta na insero da referncia do DomainAccessPolicy no objeto PolicyCurrent. O AccessDecision tambm localiza ainda o objeto RequiredRights do ambiente inserindo a referncia ao mesmo no objeto SecurityManager. O interceptador de chamada segura em tempo de ligao deve obter e/ou definir as caractersticas necessrias para a invocao no lado do cliente, a partir dos objetos de Polticas

direitos na execuo de operaes em todos os objetos de um domnio. A representao de uma poltica de acesso particular definida na tabela 1. Para simplificar a administrao, o DomainAccessPolicy agrega principais usando seus atributos de privilgio. Alguns tipos de agrupamento so group (grupo) e role (papis desempenhados pelos principais no sistema). Existe a possibilidade de permitir direitos diferentes a um sujeito que inicia uma invocao (initiator) ou que est participando de uma cadeia de delegao de tarefas (delegat). Dessa forma, o sujeito no sentido tradicional de uma matriz de acesso a combinao de um atributo de privilgio e de um estado de delegao. Para lidar com diversas necessidades de expressar a autorizao, os direitos so classificados em conjuntos de tipos de direitos chamados famlias de direitos. O CORBAsec fornece apenas a famlia Corba que contm quatro tipos de direitos: g (get), s (sei), m (manage) e u (use), embora permita a livre definio de outras famlias de direitos.
Atributo de Privilgio role;gerente_banco role : gerente__banco role: caixa Estado de Delegao Initiator Delegat Initiator Direitos Fornecidos (Granted Rights) corba: gscorba: g corba: g-u

Tabela l. Objeto DomainAccessPolicy. Uma poltica de acesso fornece ento direitos aos atributos de privilgio conforme o seu estado de delegao. Em contraste, um objeto RequiredRights define que para a invocao de cada operao na interface de um objeto seguro, alguns direitos so necessrios ou requeridos (atributos de controle). Um exemplo de objeto RequiredRights mostrado na tabela 2. Essa tabela define os direitos requeridos para se ter acesso a cada operao especfica de um objeto. Tambm existe o combinador de direitos que possibilita especificar se um principal necessita todos (Ali) os direitos requeridos para executar uma operao, ou, se suficiente a posse de qualquer um (Any) dos direitos requeridos.
Direitos Requeridos (Required Rights) Cort>a:g Corbaigs Corba:g-u Combinador de Direitos

AH Any Ali

Operao Ver_Satdo Depositar Depositar

Interface Renda Fixa Renda Fixa Conta corrente

Tabela 2. Objeto RequiredRights para as interfaces Renda_Fixa e Conta_corrente. Os direitos requeridos so atribudos para interfaces e no para instncias, ou seja, todas as instncias de uma interface tero sempre o mesmo conjunto de direitos requeridos. Todas as decises de acesso na invocao dos objetos feita atravs de uma interface de um objeto de servio AccessDecision que determina se uma operao a ser executada por um objeto destino especfico permitida ou no. As decises de acesso dependem dos atributos de privilgio e de controle fornecidos respectivamente, pelo objetos DomainAccessPolicy e RequiredRights. A regra geral na deciso de acesso pode ser enunciada como segue: um cliente recebe autoridade para executar a operao m em um objeto servidor o, se a credencial associada com a invocao do mtodo contm um atributo de privilgio que fornea um direito em um domnio de segurana que contm o objeto o, e, se o mesmo direito est presente na tabela "RequiredRights" da operao m. Por exemplo, a poltica definida na tabela l fornece a um principal caixa, no estado de delegao Initiator, todos (Ali) os direitos requeridos - g e u - para executar a operao Depositar da interface Conta_corrente. Objetos cruciais para o entendimento da dinmica do funcionamento do CORBAsec so os chamados objetos de sesso. Todos os objetos de servio (COSS) de segurana so acessados atravs de objetos de sesso SecurityManager, PolicyCurrent e Current (figura 1), que armazenam informaes sobre o contexto corrente de segurana relativo ao processo (capsule speciflc) ou ao fluxo de execuo da invocao (thread specific) respectivamente

182 Simpsio Brasileiro de Redes de Computadores

357

2.1 Objetos de servio no CORBAsec PrincipalAuthenticator, Credential, DomainAccessPolicy, RequiredRights, AccessDecision, SecurityManager, PolicyCurrent, Current, Vault e SecurityContext, introduzidos nas especificaes CORBA, constituem os objetos de servio COSS que implementam os controles de segurana em uma invocao de mtodo. O objeto PrincipalAuthenticator implementa o servio de autenticao de principais2 no CORBA. A autenticao define um conjunto de trocas entre o principal e o objeto de servio PrincipalAuthenticator que tem como objetivo final a aquisio de credenciais pelo principal. Uma credencial (objeto Credential) contm os privilgios de um principal necessrios para que este possa acessar os objetos do sistema durante uma sesso. Depois de adquirir credenciais, o principal e os objetos que atuam em seu nome, como clientes, podem iniciar chamadas a objetos servidores.

Figura l. Modelo CORBA de Segurana. Os controles de autorizao enfatizados no modelo permitem que polticas de segurana definidas sejam verificadas em dois nveis: no nvel de middleware usando objetos de servio durante uma invocao de mtodo e portanto, de forma transparente para a aplicao; e, no nvel da aplicao, que fica consciente dos servios de segurana do ambiente. Neste trabalho ns nos restrigimos aos controles de autorizao transparentes. No CORBAsec, as polticas de segurana so descritas na forma de atributos de segurana dos recursos do sistema (atributos de controle) e dos principais (atributos de privilgio). O objeto DomainAccessPolicy representa a interface de acesso poltica de autorizao discricionria, representando para um conjunto de principais um conjunto de
!

O principal a entidade (usurio ou processo) responsvel e autorizada pela poltica de segurana a acessar informaes ou recursos mantidos pelo sistema.

O servio de poltica PoliCap, proposto neste artigo, tem como objetivo possibilitar o gerenciamento centralizado de objetos de poltica em um domnio de aplicaes de objetos distribudos. As nossas propostas suprem as carncias identificadas no CORBAsec quanto ao gerenciamento de objetos de poltica e foram desenvolvidas no sentido de atuarem no esquema de autorizao do modelo do projeto JaCoWeb [4]. O esquema de autorizao JaCoWeb (http://www.lcmi.ufsc.br/iacoweb/) atualmente em desenvolvimento em nossos laboratrios, corresponde a uma estrutura de controle de acesso baseada em dois nveis de controle: um global e outro local, nas estaes dos objetos de aplicao. O PoliCap constitui o primeiro nvel de verificao e atua em tempo de ligao. Um segundo nvel de controle de acesso baseado em mecanismo de capabilities realizado em tempo de execuo da aplicao, refletindo as polticas do PoliCap, permitindo verificaes em ambos os lados - no cliente e no servidor - nas invocaes de mtodo. O mecanismo de capabilities montado usando as abstraes do prprio CORSA. Este esquema de autorizao fundamentado nas especificaes do CORBAsec, integrando tambm aspectos dos modelos de segurana Java e Web, na composio da segurana de objetos distribudos em redes de larga escala. O artigo no seu plano, inicialmente, apresenta o modelo de segurana do padro CORBA na seo 2. Na seo 3 descrita a proposio do servio de poltica e o esquema de autorizao considerado. Resultados de implementao so mostrados na seo 4 e a avaliao do prottipo desenvolvido feita na seo 5 de acordo com o Critrio Comum de Segurana. A seo 6 apresenta alguns trabalhos correlates. 2 CORBAsec- MODELO DE SEGURANA DO CORBA As especificaes CORBA/OMG definem caractersticas de um ambiente de suporte aplicaes distribudas segundo a arquitetura OMA (Object Management Architecture). Essa arquitetura divide o espao de objetos distribudos em trs partes: objetos de aplicao, objetos de servio (COSS - Common Object Services Speciftcation) que suportam servios comuns, independentes de domnios de aplicao e ainda, em facilidades comuns. Os objetos se comunicam nessa arquitetura via ORB (Object Request Broker). O ORB, num sentido mais genrico, um canal de comunicao para objetos distribudos. A OMG redigiu um documento definindo as principais linhas no que se refere a segurana de objetos distribudos [2]. O modelo de segurana descrito neste documento estabelece vrios procedimentos que tratam da autenticao e da autorizao na invocao de um mtodo remoto, da segurana na comunicao entre objetos, alm de aspectos envolvendo esquemas de delegao de direitos, no-repudiao, auditoria e administrao da segurana. O modelo CORBA de segurana relaciona objetos e componentes de quatro nveis numa estratificao de sistema (figura 1): o nvel de aplicao com os objetos de aplicao; o nvel de middleware formado por objetos de servio, servios ORB e o ncleo do ORB (nvel middleware CORBA); o nvel de tecnologia de segurana formado pelos servios de segurana subjacentes; e por fim, o nvel de proteo bsica composto por uma combinao de funcionalidades de sistemas operacionais e do hardware. A figura l ilustra os nveis e os componentes principais do CORBAsec. Nesta figura, os objetos cliente e destino representam o nvel das aplicaes. Os servios ORB e objetos de servio COSS so construdos sobre o ncleo ORB e estendem as funes bsicas com qualidades ou controles adicionais, facilitando a implementao de objetos distribudos. Um conjunto de servios ORB e servios COSS usado no nvel de middleware, na implementao da segurana no modelo CORBA. A tecnologia de segurana subjacente define algoritmos e protocolos usados na implementao de alguns objetos de servio do CORBAsec.

Nesta verso do prottipo implementamos apenas polticas discricionrias aplicadas no lado do servidor de aplicao. Polticas no-discricionrias ou obrigatrias so objetivos futuros em nosso prottipo. Usando os objetos Credential e Policy do esquema acreditamos que possamos implementar uma verso do modelo Bell e Lapadula [20] ou ainda de modelos baseados em papis [21]. Esse prottipo, com os testes realizados, forneceu subsdios para avaliao com relao ao Critrio Comum de segurana (ISO 15408), e conclumos que atende o nvel EAL3. REFERNCIAS [1] Bob Blakley, "lhe Emperoi^s Old Armor," In Proc. of the 1996 ACM New Security Paradigms
[2] [3] [4] Workshop, 1996, pp. 2-16, ACM. OMG, "Security Service:v1.2 Final," OMG Document Number 98-01-02, Nov. 1998. OMG, "Security Domain Membership Management Service," Doe. orbos/99-07-21, Aug. 1999. Carla M. Westphall and Joni S. Fraga, "A Large-scale System Authorization Scheme Proposal Integrating Java, CORBA and Web Security Models and a Discretonary Prototype," IEEE LANOMS'99, Dec. 03-05, pp. 14-25, Rio de Janeiro - Brazil, 1999. Gerald Brose, "JacORB - A free Java ORB," Freie Universitt Berlin, Institui fr Informatik, Beriin, 1999 (http://www.inf.fu-berlin.de/-brose/jacorb/). OMG, "ORB Interface," OMG Document 99-07-08, June 1999. V. Nicomette, "La Protection dans ls Systmes Objets Rpartis,". PhD thesis. Institui National Polytechnique de Toulouse, 1996. Li Gong, "A Secure Identity-Based Capability Systems," In Proc ofthe 1989 IEEE Symposium on Security and Privacy, pp. 56-63, Oakland, Califrnia, May 1989. W. Stallings, "Cryptography and Network Security:Principles and Practice," Prentice Ha//, 2M edition, July 1998. Martin Abadi and Roger Needham, "Prudent Engineering Practice for Cryptographic Protocols," IEEE Transactions on Software Engineering, Vol. 22, Number 1, pp. 6-15, 1996. Sun M. Inc., "Java Cryptography Architecture API Specification & Reference," Oct. 1998. A. O. Freier, P. Karlton and P. C. Kocher, "Secure Socket Layer 3.0," Internet Draft, Nov. 1996. Graz - University of Technology, "iSaSiLk Toolkit," Inst. for Applied Information Processing and Communications, Graz University of Technology, 1999 (http://jcewww.iaik.at/iSaSiLk/isasilk.htm). CC Project Sponsoring Organisations, "Common Criteria for Information Technology Security Evaluation," In Part2: Security Funcional Requirements, ISO/IEC 15408-2, December 1999. Murray G. Donaldson et ali, "Guide for the Production of PPs and STs, Version 0.8," Project ISO/IEC JT 1.27.22, Working Draft, July 1999. Information Security Systems Organization, "Controlled Access Protection Profile," National Security Agency, Oct. 1999 (http.7/www.radium.ncsc.mil/tpep/library/pratection_profiles/index.html). Campbell, Roy H. and Qian Tin, "Dynamic Agent-Based Security Architecture for Mobile Computers," Proc. of the Second PDCN '98, Austrlia, December 1998. Adiron Inc., "Contrai - Access Control for ORBAsec SL2 Version 1.0 Alpha," Adiron LLC CASE Center, Syracuse University, NY, December 1999 (http://www.adiron.com/). M. S. Wangham, "Estudo e Implementao de um Esquema de Autorizao Discricionria baseado na Especificao CORBAsec," Dissertao de Mestrado, Curso de Ps-Graduao em Engenharia Eltrica, UFSC, Maro 2000. D. E. Bell and L. J. Lapadula, "Secure computer systems: Mathematical foundations and model," Tech. Rep. M74-244, MITRE Corp, October 1974. K. Beznosov and Y. Deng, "A Framework for Implementing Role-based Access Control Using CORBA Security Service," In Proc. of4'dACM Workshop on Role-Based Access, Oct. 1999.

[5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19]

[20] [21]