BRPI0712605A2 - abstraÇço de polÍtica de seguranÇa a partir de, e transformaÇço emm representaÇÕes nativas de mecanismo de verificaÇço de acesso - Google Patents

Abstract

ABSTRAÇçO DE POLÍTICA DE SEGURANÇA A PARTIR DE, E TRANSFORMAÇçO EM REPRESENTAÇÕES NATIVAS DE MECANISMOS DE VERIFICAÇçO DE ACESSO. A abstração da política de controle de acesso a partir dos mecanismos de verificação de acesso permite uma expressão mais rica da política, utilizando um modelo de declaração com semântica, do que é permitido pelos mecanismos de verificação de acesso. Adi- cionalmente, a abstração da política de controle de acesso permite uma expressão uniforme da política através de múltiplos mecanismos de verificação de acesso. Razões tipo prova para qualquer pesquisa de acesso são fornecidas, tal como quem acessou qual recurso, construídas a partir das declarações de política propriamente ditas, independentemente do mecanismo de verificação de acesos que fornecem acesso. O acesso é auditado e as razões baseadas em política para o acesso são fornecidas com base na política de controle de acesso.

Description

"ABSTRAÇÃO DE POLÍTICA DE SEGURANÇA A PARTIR DE, E TRANSFORMAÇÃO EM REPRESENTAÇÕES NATIVAS DE MECANISMOS DE VERIFICAÇÃO DE ACESSO"

Fundamentos

A configuração de Política de Segurança é tipicamente de "via única"; uma vez que a intenção foi configurada, é extremamente difícil, se não impossível, se pesquisar e medir a intenção a partir do que foi configurado. Muito freqüentemente, o que pode ser expresso freqüentemente é menos do que precisa ser expresso. Mudanças na intenção são extrema- mente difíceis quando a intenção é muito acoplada á configuração detalhada. Adicionalmen- te, os mecanismos de verificação de acesso de legado duram mais do que sua utilidade vis- to que freqüentemente as políticas configuradas não podem ser facilmente migradas. Para se analisar o sistema, todos os acessos devem ser auditados e cuidadosamente reconcilia- dos com a intenção como consubstanciado na política de segurança configurada, exigindo um esforço humano substancial. Como resultado disso, os usuários se deparam com os seguintes problemas:

1. Nenhuma forma para definir a política de controle de acesso de forma central que possa ser aplicada a múltiplos servidores de arquivo distribuídos através de um domínio administrativo;

2. Nenhuma forma para definir a política de controle de acesso de forma central pa- ra múltiplos aplicativos independentemente do mecanismo de avaliação de autorização em cada aplicativo;

3. Nenhuma forma uniforme para definir a política de coleta de dados de auditoria de forma central para os recursos distribuídos através de um domínio administrativo;

4. Nenhuma forma de identificação dos acessos que violam a política de controle de acesso definida;

5. Nenhuma forma de se verificar automaticamente a consistência entre a política de controle de acesso definida e o comportamento dos mecanismos de avaliação de autori- zação;

6. Nenhuma forma para se agrupar os recursos através de aplicativos e políticas armazenados para aplicar a política de autorização comum;

7. Nenhuma experiência de usuário comercial (UX) para suportar a delegação de direitos nos recursos e especificação da política de autorização;

8. Nenhum mecanismo fácil para delegar permissões pessoais para outros princí- pios ou mecanismo para compartilhar o ônus administrativo entre os principais de uma for- ma altamente restrita.

A raiz do problema é que não existe preservação explícita da intenção de política separada do que é nativo para o mecanismo de verificação de acesso. A política é configu- rada com uma finalidade: para o mecanismo de verificação de acesso consumir o mesmo para ditar se o acesso deve ser concedido. De acordo com isso, a representação de política é orientada na direção da otimização do desempenho da verificação de acesso, que é ine- gavelmente importante. Mas o preço a se pagar tem sido que é extremamente difícil se de- senterrar o significado do que foi configurado. Mesmo em um ambiente homogêneo, tal co- mo múltiplos compartilhamentos diferentes com configurações de lista de controle de acesso (ACL) iguais ou similares, não é fácil e freqüentemente impossível se discernir sistematica- mente que a mesma política foi aplicada a todos esses compartilhamentos, e, portanto, re- capturar a intenção por trás dessa política. Os ambientes heterogêneos exacerbam esse problema. Quando a política é profundamente espelhada nas representações nativas para as implementações de verificação de acesso, existe pouca chance de se extrair a política abstrata a partir do que foi configurado nos mecanismos de controle nativos. Visto que a intenção de política propriamente dita não é persistida e gerenciada de forma independente, é impossível se expressar qualquer coisa mais rica do que o mecanismo de verificação de acesso subjacente permite. A implicação é que acaba havendo um espaço largo entre a intenção e a implementação dessa intenção nos formatos de configuração de política nativa.

Dessa forma, são necessários processos e um sistema que solucionem as desvan- tagens da técnica anterior.

Sumário da Invenção

Esse sumário é fornecido para introduzir uma seleção dos conceitos de uma forma simplificada que são adicionalmente descritos abaixo na Descrição Detalhada. Esse sumário não deve identificar características chave ou características essenciais da matéria reivindi- cada, nem pretende ser utilizado como um auxílio na determinação do escopo da matéria reivindicada.

Considerando-se as desvantagens da técnica identificadas acima, a abstração da política de segurança a partir de, e transformando em representações nativas dos mecanis- mos de verificação de acesso é fornecida. Para várias modalidades, um método de imple- mentação de uma política de controle de acesso de recurso de computador compreende a abstração de uma política de controle de acesso a partir dos mecanismos de verificação de acesso. Os mecanismos de verificação de acesso possuem capacidades de expressão de política nativa que podem ser mais limitadas do que a política de controle de acesso. Além disso, um sistema para a implementação de uma política de segurança de acesso de recur- so de computador compreende meios para realizar a auditoria de um acesso de recurso, e meios de fornecimento de razões (de acordo com a política de controle de acesso) pelas quais um acesso auditado em particular foi permitido. As razões fornecidas são construídas a partir da política de controle de acesso propriamente dita, independentemente dos meca- nismos de verificação de acesso que possuem capacidades de expressão de política mais limitadas do que a política de controle de acesso.

Abaixo encontra-se uma descrição de outras vantagens e características da invenção.

Desenhos

A abstração da política de segurança a partir de, e a transformação em representa- ções nativas de mecanismos de verificação de acesso é adicionalmente descrita com refe- rência aos desenhos em anexo, nos quais:

A figura 1 é um diagrama em bloco representando um dispositivo de computação i- lustrativo adequado para uso em conjunto com a abstração de política de segurança a partir de e transformação para representações nativas dos mecanismos de verificação de acesso;

A figura 2 ilustra um ambiente de computação em rede ilustrativo no qual muitos processos computadorizados podem ser implementados para realizar a abstração da políti- ca de segurança a partir de e a transformação em representações nativas dos mecanismos de verificação de acesso;

A figura 3 é um diagrama em bloco ilustrando a computação da representação das permissões utilizando uma política de segurança ilustrativa;

A figura 4 é um diagrama em bloco ilustrando a computação da representação das permissões utilizando uma delegação que permite a política de segurança ilustrativa adicional;

A figura 5 é um diagrama em bloco ilustrando permissões ilustrativas resultando em injeção em uma representação do mecanismo de verificação de acesso;

A figura 6 é um diagrama em bloco ilustrando o fornecimento de uma prova resul- tando de um evento de acesso e auditoria ilustrativo; e

A figura 7 é um diagrama em bloco ilustrando um sistema ilustrativo implementando a abstração da política de segurança a partir de e a transformação em representações nati- vas ilustrativas dos mecanismos de verificação de acesso.

Descrição Detalhada

Determinados detalhes específicos são apresentados na descrição e figuras a se- guir para fornecer uma compreensão profunda de várias modalidades da invenção. Deter- minados detalhes bem conhecidos associados freqüentemente com tecnologia de computa- ção e software não são apresentados na descrição a seguir para evitar obscurecer desne- cessariamente as várias modalidades da invenção. Adicionalmente, os versados na técnica relevante compreenderão que podem praticar outras modalidades da invenção sem um ou mais dos detalhes descritos abaixo. Finalmente, enquanto vários métodos são descritos com referência às etapas e seqüências na descrição a seguir, a descrição como tal serve para fornecer uma implementação clara das modalidades da invenção, e as etapas e seqüências de etapas não devem ser consideradas como exigidas para a prática dessa invenção. Ambientes de Computaçao Ilustrativos

Com referência à figura 1, é ilustrado um diagrama em bloco representando um dispositivo de computação ilustrativo adequado para uso em conjunto com a implementação dos processos descritos acima. Por exemplo, as instruções executáveis por computador que realizam os processos e métodos para abstração da política de segurança a partir de, e transformação em representações nativas dos mecanismos de verificação de acesso podem residir e/ou ser executadas em tal ambiente de computação como ilustrado na figura 1. O ambiente do sistema de computação 220 é apenas um exemplo de um ambiente de compu- tação adequado e não deve sugerir qualquer limitação quanto ao escopo do uso ou funcio- nalidade da invenção. Nem deve o ambiente de computação 220 ser interpretado como possuindo qualquer dependência ou exigências referentes a qualquer um ou combinação de componentes ilustrados no ambiente operacional ilustrativo 220. Por exemplo, um jogo de console de computador também pode incluir esses itens tal como os descritos abaixo para uso em conjunto com a implementação dos processos descritos acima.

Os aspectos da invenção são operacionais com outras inúmeras finalidades gerais ou ambientes ou configurações de sistema de computação de finalidade especial. Exemplos de sistemas de computação, ambientes e/ou configurações bem conhecidos que podem ser adequados para uso com a invenção incluem, mas não estão limitados a computadores pessoais, sistemas de servidor, dispositivos portáteis, sistemas multiprocessadores, siste- mas com base em microprocessador, aparelhos decodificadores, partes eletrônicas de con- sumidor programável, PCs em rede, mini computadores, computadores principais, ambien- tes de computação distribuídos que incluem qualquer um dos sistemas ou dispositivos aci- ma, e similares.

Aspectos da invenção podem ser implementados no contexto geral das instruções executáveis por computador, tal como módulos de programa, sendo executados por um computador. Geralmente, os módulos de programa incluem rotinas, programas, objetos, componentes, estruturas de dados, etc. que realizam tarefas em particular ou implementam os tipos de dados abstratos particulares. Aspectos da invenção também podem ser pratica- dos nos ambientes de computação distribuídos onde tarefas são realizadas pelos dispositi- vos de processamento remoto que são conectados através de uma rede de comunicações. Em um ambiente de computação distribuidor, os módulos de programa podem ser localiza- dos em ambos os meios de armazenamento de computador local e remoto incluindo disposi- tivos de armazenamento em memória.

Um sistema ilustrativo para implementação dos aspectos da invenção inclui um dis- positivo de computação de finalidade geral na forma de um computador 241. Os componen- tes do computador 241 podem incluir, mas não estão limitados a uma unidade de proces- samento 259, uma memória de sistema 222, e um barramento de sistema 221 que acopla vários componentes de sistema incluindo a memória do sistema para a unidade de proces- samento 259. O barramento de sistema 221 pode ser qualquer um dentre os vários tipos de estruturas de barramento incluindo um barramento de memória ou controlador de memória, um barramento periférico, e um barramento local utilizando qualquer uma dentre uma varie- dade de arquiteturas de barramento. Por meio de exemplo, e não de limitação, tais arquite- turas incluem o barramento de Arquitetura Padrão da Indústria (ISA), barramento de Arquite- tura de Micro Canal (MCA), barramento ISA Melhorado (EISA), barramento local da Associ- ação de Padrões Eletrônicos de Vídeo (VESA), o barramento de Interconexão de Compo- nente Periférico (PCI) também conhecido como barramento Mezzanine, além de seu suces- sor, o padrão PCI-Express.

O computador 241 inclui tipicamente uma variedade de meios legíveis por compu- tador. A mídia legível por computador pode ser qualquer mídia disponível que possa ser acessada por computador 241 e inclui ambas as mídias volátil e não volátil, mídia removível e não removível. Por meio de exemplo, e não de limitação, a mídia legível por computador pode compreender mídia de armazenamento em computador e mídia de comunicação. A mídia de armazenamento em computador inclui ambas as mídias volátil e não volátil, remo- vível e não removível implementadas em qualquer método ou tecnologia para armazena- mento de informação tal como instruções legíveis por computador, estruturas de dados, mó- dulos de programa ou outros dados. A mídia de armazenamento em computador inclui, mas não está limitada a RAM, ROM, EEPROM, memória flash ou outra tecnologia de memória, CD-ROM, discos versáteis digitais (DVD) ou outro armazenamento em disco ótico, fitas magnéticas, armazenamento em disco magnético out outros dispositivos de armazenamento magnético, ou qualquer outro meio que possa ser utilizado para armazenar a informação desejada e que possa ser acessado por computador 241. A mídia de comunicação consubs- tancia tipicamente instruções legíveis por computador, estruturas de dados, módulos de programa ou outros dados em um sinal de dados modulado tal como uma onda portadora ou outro mecanismo de transporte e inclui qualquer meio de distribuição de informação. O ter- mo "sinal de dados modulado" significa um sinal que possui uma ou mais de suas caracte- rísticas configuradas ou alteradas de tal forma a codificar a informação no sinal. Por meio de exemplo, e não de limitação, a mídia de comunicação inclui a mídia com fio tal como uma rede com fio ou conexão de fio direta, e a mídia sem fio tal como mídia acústica, RF, infra- vermelho e outra mídia sem fio. Combinações de qualquer um dos acima deve ser incluída também no escopo da mídia legível por computador.

A memória do sistema 222 inclui a mídia de armazenamento em computador na forma de memória volátil e/ou não volátil tal como a memória de leitura apenas (ROM) 223 e memória de acesso randômico (RAM) 260. Um sistema básico de entrada/saída (BIOS) 224, contendo as rotinas básicas que ajudam a transferir informação entre os elementos dentro do computador 241, tal como durante a inicialização, é tipicamente armazenado na ROM 223. A RAM 260 contém tipicamente dados e/ou módulos de programa que são imediata- mente acessíveis a e/ou estão sendo atualmente operados pela unidade de processamento 259. Por meio de exemplo, e não de limitação, a figura 1 ilustra o sistema operacional 225, os programas de aplicativo 226, outros módulos de programa 227, e dados de programa 228.

O computador 241 também pode incluir outras mídias de armazenamento em com- putador removível/não removível, volátil/não volátil. Por meio de exemplos apenas, a figura 1 ilustra um acionador de disco rígido 238 que lê a partir de ou escreve em mídia magnética não removível e não volátil, um acionador de disco magnético 239 que lê a partir de ou es- creve em um disco magnético removível e não volátil 254, e um acionador de disco ótico 240 que lê a partir de ou escreve em um disco ótico removível e não volátil 253 tal como um CD ROM ou outra mídia ótica. Outra mídia de armazenamento em computador removí- vel/não removível, volátil/não volátil que pode ser utilizada no ambiente operacional ilustrati- vo incluem, mas não estão limitadas a fitas magnéticas, cartões de memória flash, discos versáteis digitais, fita de vídeo digital, RAM em estado sólido, ROM em estado sólido, e simi- lares. O acionador de disco rígido 238 é tipicamente conectado ao barramento de sistema 221 através de uma interface de memória não removível tal como a interface 234, e o acio- nador de disco magnético 239 e acionador de disco ótico 240 são tipicamente conectados ao barramento do sistema 221 por uma interface de memória removível, tal como a interface 235.

Os acionadores e sua mídia de armazenamento em computador associada discuti- dos acima e ilustrados na figura 1, fornecem o armazenamento de instruções, dados, estru- turas, módulos de programa e outros dados legíveis por computador para o computador 241. Na figura 1, por exemplo, o acionador de disco rígido 238 é ilustrado como armazenan- do o sistema operacional 258, os programas de aplicativo 257, outros módulos de programa 256 e os dados de programa 255. Note-se que esses componentes podem ser iguais ou diferentes do sistema operacional 225, dos programas de aplicativo 226, de outros módulos de programa 227 e dos dados de programa 228. O sistema operacional 258, os programas de aplicativo 257, outros módulos de programa 256, e os dados de programa 255 recebem números diferentes aqui para ilustrar que, no mínimo são cópias diferentes. Um usuário po- de registrar os comandos e informação no computador 241 através de dispositivos de entra- da tal como um teclado 251 e dispositivo de apontar 252, comumente referido como mouse, TrackBall ou teclado de toque. Outros dispositivos de entrada (não ilustrados) podem incluir um microfone, joystick, painel de jogo, antena parabólica, digitalizador ou similar. Esses e outros dispositivos de entrada são freqüentemente conectados à unidade de processamento 259 através de uma interface de entrada de usuário 236 que é acoplada ao barramento do sistema, mas podem ser conectados por outra interface e estruturas de barramento, tal co- mo uma porta paralela, porta de jogo ou um barramento serial universal (USB). Um monitor 242 ou outro tipo de dispositivo de exibição é conectado também ao barramento do sistema 221 através de uma interface, tal como uma interface de vídeo segura ou não 232. Um pa- drão de vídeo seguro ilustrativo seria o padrão de Interface de Multimídia de Alta Definição (HDMI). Em adição ao monitor, computadores também podem incluir outros dispositivos de saída periférica tal como alto falantes 244 e impressora 243, que podem ser conectados através de uma interface periférica de saída 233.

O computador 241 pode operar em um ambiente em rede utilizando conexões lógi- cas para um ou mais computadores remotos, tal como um computador remoto 246. O com- putador remoto 246 pode ser um computador pessoal, um servidor, um roteador, um PC em rede, um dispositivo não hierarquizado ou outro nó de rede comum, e inclui tipicamente mui- tos ou todos os elementos descritos acima com relação ao computador 241, apesar de ape- nas um dispositivo de armazenamento em memória 247 ter sido ilustrado na figura 1. As conexões lógicas apresentadas na figura 1 incluem uma rede de área local (LAN) 245 e uma rede de área ampla (WAN) 249, mas também podem incluir outras redes. Tais ambientes em rede são lugar comum em escritórios, redes de computador empresariais, intranets e na Internet.

Quando utilizado em um ambiente em rede LAN, o computador 241 é conectado à LAN 245 através de uma interface de rede ou adaptador 237. Quando utilizado em um am- biente em rede WAN1 o computador 241 inclui tipicamente um modem 250 ou outro meio de estabelecimento de comunicações através da WAN 249, tal como a Internet. O modem 250, que pode ser interno ou externo, pode ser conectado ao barramento do sistema 221 através da interface de entrada de usuário 236, ou outro mecanismo adequado. Em um ambiente em rede, os módulos de programa apresentados com relação ao computador 241, ou partes do mesmo, podem ser armazenados no dispositivo de armazenamento em memória remota. Por meio de exemplo, e não de limitação, a figura 1 ilustra os programas de aplicativo remo- tos 248 como residentes no dispositivo de memória 247. Será apreciado que as conexões de rede ilustradas são ilustrativas e outros meios de estabelecimento de um link de comuni- cações entre os computadores podem ser utilizados.

Deve-se compreender que as várias técnicas descritas aqui podem ser implemen- tadas com relação a hardware ou software ou, onde adequado, com uma combinação dos dois. Dessa forma, os métodos e aparelho da invenção, ou determinados aspectos ou partes do mesmo, podem assumir a forma de código de programa (isso é, instruções) consubstan- ciado em mídia tangível, tal como discos flexíveis, CD-ROM, discos rígidos, ou qualquer outro meio de armazenamento legível por máquina onde, quando o código de programa é carregado e executado por uma máquina, tal como um computador, a máquina se torna um aparelho para a prática da invenção. No caso de execução de código de programa em com- putadores programáveis, o dispositivo de computação geralmente inclui um processador, um meio de armazenamento legível pelo processador (incluindo elementos de armazenamento e/ou memória volátil e não volátil), pelo menos um dispositivo de entrada, e pelo menos um dispositivo de saída. Um ou mais programas que podem implementar ou utilizar os proces- sos descritos com relação à invenção, por exemplo, através do uso de uma API, controles reutilizáveis, ou similar. Tais programas são preferivelmente implementados em uma lingua- gem de programação orientada por objeto ou de procedimento de alto nível para comunicar com um sistema de computador. No entanto, os programas podem ser implementados em linhagem de máquina ou conjunto, se desejável. Em qualquer caso, a linguagem pode ser uma linguagem compilada ou interpretada, e combinada com implementações de hardware.

Apesar de as modalidades ilustrativas poderem se referir à utilização de aspectos da invenção no contexto de um ou mais sistemas de computador independentes, a invenção não está limitada a isso, mas, ao invés disso, pode ser implementada com relação a qual- quer ambiente de computação, tal como uma rede ou ambiente de computação distribuído. Adicionalmente ainda, aspectos da invenção podem ser implementados em ou através de uma pluralidade de chips ou dispositivos de processamento, e o armazenamento pode ser realizado de forma similar através de uma pluralidade de dispositivos. Tais dispositivos po- dem incluir computadores pessoais, servidores em rede, dispositivos portáteis, super com- putadores, ou computadores integrados em outros sistemas tal como automóveis e aeronaves.

Em vista dos ambientes de computação diversos que podem ser construídos de acordo com a estrutura geral fornecida na figura 1, os sistemas e métodos fornecidos aqui não podem ser considerados como limitados de forma alguma a uma arquitetura de compu- tação particular. Ao invés disso, a invenção não deve ser limitada a qualquer modalidade única, mas, ao invés disso deve ser considerada na abrangência e escopo de acordo com as reivindicações em anexo.

Com referência a seguir à figura 2, é ilustrado um ambiente de computação em re- de ilustrativo no qual muitos processos computadorizados podem ser implementados para realizar os processos descritos acima. Por exemplo, a computação paralela pode ser parte de tal ambiente em rede com vários clientes na rede da figura 2 utilizando e/ou implemen- tando a abstração da política de segurança a partir de e transformando em representações nativas dos mecanismos de verificação de acesso. Os versados na técnica podem apreciar que as redes podem conectar qualquer computador ou outro cliente ou dispositivo servidor, ou em um ambiente de computação distribuída. A esse respeito, qualquer sistema ou ambi- ente de computador possuindo qualquer número de unidades de processamento, memória ou armazenamento, e qualquer número de aplicativos e processos ocorrendo simultanea- mente é considerado adequado para uso com relação aos sistemas e métodos fornecidos.

A computação distribuída fornece o compartilhamento de recursos e serviços de computador pela permuta entre os dispositivos e sistemas de computação. Esses recursos e serviços incluem a permuta de informação, armazenamento temporário e armazenamento em disco de arquivos. A computação distribuída leva vantagem da conectividade de rede, permitindo que os clientes alavanquem sua potência coletiva para beneficiar toda a empre- sa. A esse respeito, uma variedade de dispositivos pode ter aplicativos, objetos ou recursos que podem implicar nos processos descritos aqui.

A figura 2 fornece um diagrama esquemático de um ambiente de computação dis- tribuída ou em rede ilustrativo. O ambiente compreende dispositivos de computação 271, 272, 276 e 277 além de objetos 273, 274 e 275 e a base de dados 278. Cada uma dessas entidades 271, 272, 273, 274, 275, 276, 277 e 278 pode compreender ou fazer uso de pro- gramas, métodos, armazenadores de dados, lógica programável, etc. As entidades 271, 272, 273, 274, 275, 276, 277 e 278 podem abranger as partes de dispositivos iguais ou dife- rentes tal com PDAs, dispositivos de áudio/vídeo, aparelhos de MP3, computadores pesso- ais, etc. Cada entidade 271, 272, 273, 274, 275, 276, 277, 278 pode se comunicar com outra entidade 271, 272, 273, 274, 275, 276, 277, 278 por meio da rede de comunicações 270. A esse respeito, qualquer entidade pode ser responsável pela manutenção e atualização de uma base de dados 278 ou outro elemento de armazenamento.

Essa rede 270 pode compreender outras entidades de computação que fornecem serviços para o sistema da figura 2, e pode representar múltiplas redes interconectadas. De acordo com um aspecto da invenção, cada entidade 271, 272, 273, 274, 275, 276, 277 e 278 pode conter módulos de programa funcional discretos que podem fazer uso de uma API, ou outro objeto, software, firmware e/ou hardware, para solicitar serviços de uma ou mais das outras entidades 271, 272, 273, 274, 275, 276, 277 e 278.

Pode-se apreciar também que um objeto, tal como 275, pode ser hospedado em outro dispositivo de computação 276. Dessa forma, apesar de o ambiente físico apresentado poder ilustrar os dispositivos conectados como computadores, tal ilustração é meramente ilustrativa e o ambiente físico pode alternativamente ser apresentado ou descrito compreen- dendo vários dispositivos digitais tal como PDAs, televisões, aparelhos de MP3, etc., objetos de software tal como interfaces, objetos COM e similares.

Existe uma variedade de sistemas, componentes, e configurações de rede que su- portam os ambientes de computação distribuídos. Por exemplo, os sistemas de computação podem ser conectados por sistemas com e sem fio, por redes locais ou redes amplamente distribuídas. Atualmente, muitas redes são acopladas à Internet, o que fornece uma infra- estrutura para a computação amplamente distribuída e engloba muitas redes diferentes. Qualquer uma dessas infra-estruturas, acoplada à Internet ou não, pode ser utilizada em conjunto com os sistemas e metodos fornecidos.

Uma infra-estrutura de rede pode permitir um hospedeiro das topologias de rede tal como as arquiteturas cliente/servidor, não hierarquizada ou híbrida. O "cliente" é um mem- bro de uma classe ou grupo que utiliza os serviços de outra classe ou grupo ao qual não está relacionado. Na computação, um cliente é um processo, isso é, aproximadamente um conjunto de instruções ou tarefas, que solicita um serviço fornecido por outro programa. O processo de cliente utiliza o serviço solicitado sem ter que "conhecer" quaisquer detalhes de trabalho do outro programa ou do serviço propriamente dito. Em uma arquitetura clien- te/servidor, particularmente um sistema em rede, um cliente é normalmente um computador que acessa os recursos de rede compartilhados fornecidos por outro computador, por e- xemplo, um servidor. No exemplo da figura 2, qualquer entidade 271, 272, 273, 274, 275, 276, 277 e 278 pode ser considerada um cliente, um servidor, ou ambos, dependendo das circunstâncias.

Um servidor é tipicamente, apesar de não necessariamente, um sistema de compu- tador remoto acessível através de uma rede remota ou local, tal como a Internet. O processo de cliente pode ser ativo em um primeiro sistema de computador, e o processo de servidor pode estar ativo em um segundo sistema de computador, se comunicando um com o outro através de um meio de comunicações, fornecendo, assim, funcionalidade distribuída e per- mitindo que múltiplos clientes levem vantagem das capacidades de coleta de informação do servidor. Quaisquer objetos de software podem ser distribuídos através de múltiplos disposi- tivos de computação ou objetos.

Os clientes e os servidores se comunicam um com o outro utilizando a funcionali- dade fornecida pelas camadas de protocolo. Por exemplo, o Protocolo de Transferência de Hipertexto (HTTP) é um protocolo comum que é utilizado em conjunto com a Rede Mundial (WWW), ou "a Rede". Tipicamente um endereço de rede de computador tal como o endere- ço de Protocolo de Internet (IP) ou outra referência tal como o Localizador de Recurso Uni- versal (URL) pode ser utilizado para identificar os computadores servidor ou cliente uma para o outro. O endereço de rede pode ser referido como um endereço URL. A comunicação pode ser fornecida através de um meio de comunicações, por exemplo, clientes e servidores podem ser acoplados um ao outro através das conexões TCP/IP para comunicação de alta capacidade.

Em vista dos ambientes de computação diversos que podem ser construídos de acordo com a estrutura geral fornecida na figura 2 e a diversificação adicional que pode o- correr na computação em um ambiente de rede tal como o da figura 2, os sistemas e méto- dos fornecidos aqui não podem ser considerados como limitados de forma alguma a uma arquitetura de computação ou sistema operacional particular. Ao invés disso, a invenção não deve ser limitada a qualquer modalidade única, mas deve ser considerada de acordo com o escopo de acordo com as reivindicações em anexo.

Mecanismos de Abstração e Verificação de Acesso

Fazendo-se uma analogia de desenvolvimento de software, o gerenciamento de software se torna (relativamente) mais simples com o advento das abstrações contidas em linguagens de alto nível. É difícil até mesmo se imaginar projetos de software em grande escala desenvolvidos apenas em uma linguagem próxima ao hardware como montagem. A maior parte dos programas atuais é escrita sem muita consideração ao ambiente de execu- ção subjacente e se baseiam em compiladores para preservar a semântica. Várias transfor- mações do código de baixo nível tal como otimizações de compilador podem tornar a recap- tura da intenção de alto nível original impossível. Como tal, o significado do programa existe em um modelo que é independente de seu ambiente de execução. Pode-se pesquisar e compreender muitas facetas do que um programa resulta (nem todas as facetas, obviamen- te, nos programas escritos em linguagens Turing completa) sem precisar na verdade rodar o mesmo.

A política de segurança garante tratamento similar. Atualmente os mecanismos de representação de política de segurança são peças muito independentes de dados, e ad-hoc em sua expressão. Mesmo um modelo lógico simples, linguagem ou abstração seguem um longo caminho no sentido de gerenciamento de intenção. A política de segurança não preci- sa da potência de expressão das linguagens de programação; apenas semântica suficiente para permitir a composição das declarações de política. O objetivo principal é que o signifi- cado da política seja discernível independentemente dos mecanismos de verificação de a- cesso. Quando observado sob esse ponto de vista, o gerenciamento de política de seguran- ça descrito aqui se prova útil para tal independência entre a política de segurança e os me- canismos de verificação de acesso. A fim de se fazer isso, uma linguagem é utilizada permi- tindo que se expresse formas de declarações prevalecentes no controle de acesso e a ca- pacidade é fornecida para racionalizar com as expressões na linguagem, isso é, realizar pesquisas, computações lógicas e derivar provas.

A linguagem é um Modelo de Política ou Linguagem de Política expressivo inde- pendente dos mecanismos de verificação de acesso e é rica o suficiente para capturar o significado. Note-se que qualquer linguagem que tenha as seguintes qualidades pode ser adequada:

Expressão:

a. Capacidade de especificar afirmações que mapeiem principais a recursos, e principais a atributos ou propriedades, incluindo valores de propriedade;

b. Capacidade de especificar quem fez tais afirmações;

c. Capacidade de especificar as afirmações previstas em outros principais que rea- lizam outras afirmações (ou similares). As mesmas podem variar de muito específicas e mui- to gerais.

d. Capacidade de construir construções de política de nível mais alto utilizando pri- mitivos de expressão. Isso é, os primitivos não restringem excessivamente seu escopo ex- pressivo.

Semântica & Monotonicidade de Declaração

a. É possível se compor e combinar afirmações e derivar o mesmo conjunto de conseqüências independentemente da ordem na qual são processados.

b. É possível se justificar as conseqüências com "provas" construídas a partir das declarações de política.

c. É possível se adicionar novas afirmações ou regras sem contradizer conclusões tiradas das afirmações existentes. A revogação das regras pode ser permitida.

Trato Computacional:

a. É possível se computar as conseqüências das afirmações declarativas de uma forma performant.

b. Análise e pesquisa de traços de auditoria é performant.

Primitivos do mecanismo de verificação de acesso de extremidade traseira (ou al- gum subconjunto desejado de extremidade traseira) são identificados. Isso é, os dados que são consumidos pelos mecanismos de verificação de acesso existentes para realizar uma decisão para permitir o acesso. Exemplos desses primitivos são definições de papel e de- signações de papel (Gerente de Autorização (AzMan) e ASP.NET); licenças de gerencia- mento de direitos (RMS, IPP); ACLs (compartilhamento de arquivos, firewalls, etc.).

Esses primitivos são então caracterizados como predicados na linguagem de políti- ca. Por exemplo, um registro de controle de acesso (ACE) em um ACL pode corresponder ao predicado "chuckr pode ler foo.txt". Outro exemplo pode ser, para um aplicativo AzMan1 que "chuckr está no desenvolvimento de papel". Pode haver muitos desses primitivos de- pendendo dos diferentes mecanismos de verificação de acesso. Esses primitivos são referi- dos como permissões.

As permissões conseqüentes da política declaratória são então computadas. De- pendendo do escopo da aplicabilidade, para fins de eficiência, métodos heurísticos podem ser utilizados para identificar o subconjunto de política que precisa ser considerado para computação das permissões conseqüentes, mas essa invenção não trata disso. Assume-se que as permissões sejam recriadas a cada vez que a política é invalidada. As permissões resultantes são utilizadas para configurar os mecanismos de verificação de acesso nativos adequados. A verificação de acesso consome essas configurações quando as solicitações de acesso são feitas.

Os eventos de auditoria são criados quando os acessos são realizados, e esses são reconciliados com a política representada na abstração de modelo de política resultando na informação de auditoria acionada por política. Adicionalmente, as pesquisas podem ser feitas na política independentemente dos mecanismos de verificação de acesso para com- preender quais os acessos que a política permite e por que.

Situações Ilustrativas

O exemplo a seguir ilustra a separação da intenção da implementação, e a configu- ração do significado da intenção no mecanismo de verificação de acesso de baixo nível.

O exemplo abaixo demonstra a modelagem de um sistema de controle de acesso de julgamento através de um sistema que possui capacidades de expressão muito limitadas. Especificamente, a única informação que o mecanismo de verificação de acesso pode re- presentar é quais as ações que um principal específico pode realizar através de um recurso especifico. Note-se que para fins desse exemplo supõe-se que até mesmo falte capacidade de se registrar que é o proprietário. As declarações da natureza acima são tratadas como tendo sido expressadas pelo sistema. O sistema propriamente dito pode ser identificado ou modelado com uma chave.

Com referência a seguir à figura 3, é ilustrado um diagrama em bloco ilustrando a computação da representação de permissões utilizando a política de segurança ilustrativa abaixo.

As declarações em itálico são coisas que não podem ser expressas no sistema de controle de acesso, porém, podem ser representadas no modelo de política. Essas declara- ções refletem a intenção por trás da política 301. As declarações não em itálico são as que podem ser expressas no sistema de controle de acesso, e com o que a implementação pode lidar. Essas são as "permissões" 303.

O objetivo é concluir o que pode ser expresso no sistema de controle de acesso (is- so é, declarações não em itálico 303) a partir das declarações de política (isso é, declara- ções em itálico 301).

A regra de política a seguir 301 captura o comportamento acima:

Sistema diz Principal "X" pode realizar a Ação "Y" para Recurso "Z"

Se o Sistema disser Principal "O" é o proprietário do Recurso "Z"

E se Principal "O" disser que Principal "X" pode realizar a Ação Ύ" para o Recurso "Z"

Supondo-se que a seguinte informação 305 é conhecida:

sistema diz que Pedro é o proprietário de foo.txt

Pedro diz que Ravi pode lerfoo.txt

Pedro diz que João pode imprimir foo.txt

A partir do acima exposto, é possível se concluir logicamente 307 as seguintes permissões 303:

Sistema diz que Ravi pode ler foo.txt Sistema diz que João pode imprimir foo.txt

Adicionalmente, o proprietário pode delegar toda ou parte de sua capacidade para qualquer pessoa que ele escolher. Com referência a seguir à figura 4, é ilustrado um dia- grama em bloco ilustrando a computação da representação de permissões utilizando uma política de segurança ilustrativa adicional referente à delegação. A declaração a segui 401 da política 301 representa no exemplo a intenção de Pedro em delegar a capacidade de fornecimento de permissões de leitura para foo.txt para Roberto.

Pedro diz que Principal "X"pode ler foo.txt

Se Roberto disser que Principal "X" pode lerfoo.txt

Supondo-se que a informação adicional a seguir 405 seja conhecida:

Roberto diz que Tom pode lerfoo.txt

É possível se concluir logicamente 307 o seguinte:

Pedro diz que Tom pode ler foo.txt

E subseqüentemente se concluir logicamente 307 a seguinte permissão 403:

O sistema diz que Tom pode ler foo.txt

Com referência a segui à figura 5, é ilustrado um diagrama em bloco ilustrando a in- jeção das permissões ilustrativas resultantes em uma representação do mecanismo de veri- ficação de acesso. São essas declarações não em itálico 403 303 (isso é, permissões) que são injetadas 501 na representação do mecanismo de verificação de acesso 503 para im- plementar a política de segurança 301.

Com referência a seguir à figura 6, é ilustrado um diagrama em bloco ilustrando o fornecimento de uma prova resultante de um evento de acesso e auditoria ilustrativo. Su- pondo-se que Tom não leia foo.txt 601 e o evento de auditoria correspondente seja criado 603. A razão completa é computada 605 para Tom poder ler foo.txt utilizando as declara- ções de política 301.

Isso é, a prova a seguir é fornecida 605, construída a partir das declarações de polí- tica 301 propriamente ditas.

Tom pode ler Foo.txt por que:

O sistema diz que Tom pode ler Foo.txt por que:

E Pedro diz que Tom pode ler Foo.txt por que:

Roberto diz que Tom pode ler Foo.txt.

A resposta acima é completamente independente das configurações nos mecanis- mos de verificação de acesso nativo 503. É o trilho de auditoria de política real do porque aconteceu e é computado de forma sistemática a partir das declarações de política 301 pro- priamente ditas. Esses trilhos de auditoria e declarações de política podem, obviamente, ser aumentados com uma grande variedade de informação adicional, tal como selos de tempo, localizações onde a declaração foi feita, etc. Com referência a seguir à figura 7, é ilustrado um diagrama em bloco ilustrando um sistema ilustrativo implementando a abstração da política de segurança a partir de e trans- formação em representações nativas dos mecanismos de verificação de acesso. Note-se que a figura 7 ilustra uma manifestação possível, e outras são possíveis e contempladas fornecendo resultados iguais ou similares.

Um mecanismo de controle de acesso com base em papel (RBAC) 701 que suporta a delegação é exposto aos usuários através de interfaces de usuário acionadas por política adequadas 703. Os usuários que configuram a política observam apenas esses aspectos da política que podem visualizar ou configurar. Uma vez que tal política é configurada, seu sig- nificado é capturado no modelo de política núcleo 705, que é o coração do sistema.

O modelo de política núcleo 705 é utilizado para os seguintes fins:

Servir como uma representação comum para toda a política para suportar a pesqui- sa uniforme de política que pode ter sido configurada através de vistas heterogêneas.

Acionar experiências de usuário e visões de usuário (por exemplo, o resultado de um administrador delegando seus privilégios a um assistente resultará na mudança da expe- riência do usuário assistente para refletir seus novos privilégios administrativos).

Permitir a computação da representação das permissões no formato que seja ade- quado para o mecanismo de verificação de acesso (por exemplo, Papéis ACLs e AzMan) 707.

Racionalizar os acessos manifestados como eventos de auditoria 709 com a políti- ca do modelo de auditoria exposto 711 para determinar como a política acomoda o acesso.

Um sistema que possui a maior parte das características acima efetivamente soma capacidades de delegação finas, por exemplo, para papeis AzMan e ACLs sem alterar qual- quer um dos mecanismos de verificação de acesso de baixo nível 713.

Concluindo, a abstração da política de controle de acesso a partir dos mecanismos de verificação de acesso permite uma expressão mais rica da política (utilizando um modelo de declaração com semântica ou um modelo impertitive) do que o que é permitido pelos mecanismos de verificação de acesso. Razões tipo prova para qualquer pesquisa de aces- so, tal como quem tem acesso a que recurso, são construídas a partir das declarações de política propriamente ditas, independentemente do mecanismo de verificação de acesso que fornece o acesso. As capacidades "e se" pesquisam a política para compreender o impacto da alteração da política sem na verdade mudar as configurações de verificação de acesso. As permissões são configuradas através de múltiplos mecanismos de verificação de acesso como o resultado das conseqüências lógicas da computação a partir de um único conjunto de declarações de política. O acesso é auditado e razões baseadas na política são forneci- das para o acesso e identificação das tentativas de acesso que estão em desacordo com a política. Isso pode auxiliar na solução de problemas onde a política pode ser muito folgada, caso no qual a auditoria pode ajudar a descobrir furos na política. Isso também cria um trilho forense que permite que os investigadores (ambos corporativos e oficiais) determinem quem utilizou seu acesso para fins nefastos.

Os vários sistemas, métodos e técnicas descritos aqui podem ser implementados com hardware ou software ou, onde adequado, com uma combinação de ambos. Dessa forma, os métodos e aparelho da presente invenção, ou determinados aspectos ou partes dos mesmos, podem assumir a forma de código de programa (isso é, instruções) consubs- tanciadas em mídia tangível, tal como discos flexíveis, CD-ROMs, discos rígidos, ou qual- quer outro meio de armazenamento legível por máquina, onde, quando o código de progra- ma é carregado e executado por uma máquina, tal como um computador, a máquina se tor- na um aparelho para a prática da invenção. No caso da execução de código de programa em computadores programáveis, o computador incluirá geralmente um processado, um meio de armazenamento legível pelo processador (incluindo memória volátil/não volátil e/ou elementos de armazenamento), pelo menos um dispositivo de entrada, e pelo menos um dispositivo de saída. Um ou mais programas são preferivelmente implementados em uma linguagem de programação orientada por objeto ou de procedimento de alto nível para co- municar com um sistema de computador. No entanto, os programas podem ser implementa- dos no conjunto ou linguagem de máquina, se desejável. Em qualquer caso, a linguagem pode se uma linguagem compilada ou interpretada, e combinada com implementações de hardware.

Os métodos e aparelho da presente invenção também podem se consubstanciados na forma de um código de programa que é transmitido através de algum meio de transmis- são, tal como através de fiação ou cabo elétrico, através de fibras óticas, ou através de qualquer outra forma de transmissão, onde, quando o código de programa é recebido e car- regado e executado por uma máquina, tal como uma EPROM, um conjunto de porta, um dispositivo lógico programável (PLD), um computador de cliente, um gravador de vídeo ou similar, a máquina se torna um aparelho para a prática da invenção. Quando implementado em um processador de finalidade geral, o código de programa combina com o processador para fornecer um aparelho singular que opera para realizar a funcionalidade de indexação da presente invenção.

Enquanto a presente invenção foi descrita com relação às modalidades preferidas das várias figuras, é compreendido também que outras modalidades similares podem ser utilizadas ou modificações e adições podem ser feitas à modalidade descrita para a realiza- ção da mesma função da presente invenção sem se desviar da mesma. Adicionalmente, deve-se enfatizar que uma variedade de plataformas de computador, incluindo sistemas operacionais de dispositivo portátil e outros sistemas de interface de hardware/software es- pecíficos de aplicativo, é contemplada aqui, especialmente à medida que o número de dis- positivos em rede sem fio continua a se proliferar. Portanto, a presente invenção não deve ser limitada a qualquer modalidade singular, mas, ao invés disso, deve se construída dentro da abrangência e escopo de acordo com as reivindicações em anexo.

Finalmente, as modalidades descritas aqui podem se adaptadas para uso em ou- tras arquiteturas de processador, sistemas com base em computador, ou virtualizações de sistema, e tais modalidades são expressamente antecipadas pelas descrições realizadas aqui e, dessa forma, a presente invenção não deve ser limitada às modalidades específicas descritas aqui, mas ao invés disso, construídas de forma mais ampla.

Claims (20)

1. Método de implementação de uma política de controle de acesso de recurso de computador, CARACTERIZADO pelo fato de compreender: a abstração de uma política de controle de acesso a partir dos mecanismos de veri- ficação de acesso, os ditos mecanismos de verificação de acesso possuindo capacidades de expressão de política iguais ou mais limitadas do que a política de controle de acesso.

2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de com- preender adicionalmente: a computação das conseqüências lógicas a partir de uma declaração de política de controle de acesso; e a configuração das permissões através de pelo menos um mecanismo de verifica- ção de acesso com base nas conseqüências lógicas computadas.

3. Método, de acordo com a reivindicação 2, CARACTERIZADO pelo fato de as permissões serem configuradas através de múltiplos mecanismos de verificação de acesso.

4. Método, de acordo com a reivindicação 3, CARACTERIZADO pelo fato de com- preender adicionalmente: o recebimento de uma pesquisa referente ao acesso aos recursos; o fornecimento de resultados da pesquisa juntamente com as razões, de acordo com a política de controle de acesso, de porque os resultados particulares foram fornecidos, as ditas razões sendo construídas a parti da política de controle de acesso propriamente dita, independentemente dos mecanismos de verificação de acesso.

5. Método, de acordo com a reivindicação 4, CARACTERIZADO pelo fato de com- preender adicionalmente: a pesquisa da política de controle de acesso para determinar um impacto de altera- ção da política de controle de acesso; e o fornecimento de informação detalhando o dito impacto da alteração da política de controle de acesso sem alterar as configurações de verificação de acesso.

6. Método, de acordo com a reivindicação 5, CARACTERIZADO pelo fato de com- preender adicionalmente: a auditoria de um acesso a recurso; e o fornecimento de razões, de acordo com a política de controle de acesso, de por- que um acesso auditado particular foi permitido, as ditas razões construídas a partir da polí- tica de controle de acesso propriamente dita, independentemente dos mecanismos de verifi- cação de acesso.

7. Meio legível por computador, CARACTERIZADO pelo fato de possuir instruções no mesmo para a realização das etapas de acordo com a reivindicação 1.

8. Meio legível por computador, CARACTERIZADO pelo fato de possuir instruções no mesmo para a realização das etapas de acordo com a reivindicação 2.

9. Meio legível por computador, CARACTERIZADO pelo fato de possuir instruções no mesmo para a realização das etapas de acordo com a reivindicação 3.

10. Meio legível por computador, CARACTERIZADO pelo fato de possuir instru- ções no mesmo para a realização das etapas de acordo com a reivindicação 4.

11. Meio legível por computador, CARACTERIZADO pelo fato de possuir instru- ções no mesmo para a realização das etapas de acordo com a reivindicação 5.

12. Meio legível por computador, CARACTERIZADO pelo fato de possuir instru- ções no mesmo para a realização das etapas de acordo com a reivindicação 6.

13. Sistema para a implementação de uma política de controle de acesso a recurso de computador, CARACTERIZADO pelo fato de compreender: meios para abstrair uma política de controle de acesso a partir de mecanismos de verificação de acesso, os ditos mecanismos de verificação de acesso possuindo capacida- des de expressão de política iguais ou mais limitadas do que a política de controle de acesso.

14. Sistema, de acordo com a reivindicação 13, CARACTERIZADO pelo fato de compreender adicionalmente: meios para computar as conseqüências lógicas a partir de uma declaração de polí- tica de controle de acesso; e meios para configurar as permissões através de pelo menos um mecanismo de ve- rificação de acesso com base nas conseqüências lógicas computadas.

15. Sistema, de acordo com a reivindicação 14, CARACTERIZADO pelo fato de as permissões serem configuradas através de múltiplos mecanismos de verificação de acesso.

16. Sistema, de acordo com a reivindicação 15, CARACTERIZADO pelo fato de compreender adicionalmente: meios para receber uma pesquisa referente ao acesso a recursos; meios para fornecer resultados da pesquisa juntamente com as razões de acordo com a política de controle de acesso, porque os resultados particulares foram fornecidos, as ditas razões construídas a partir da política de controle de acesso propriamente dita, inde- pendentemente dos mecanismos de verificação de acesso.

17. Sistema, de acordo com a reivindicação 16, CARACTERIZADO pelo fato de compreender adicionalmente: meios para pesquisar a política de controle de acesso para determinar um impacto na alteração da política de controle de acesso; e meios para fornecer informação detalhando o dito impacto de alteração da política de controle de acesso sem alterar as configurações de verificação de acesso.

18. Sistema, de acordo com a reivindicação 5, CARACTERIZADO pelo fato de compreender adicionalmente: meios para auditar um acesso a recurso; e meios para fornecer razões, de acordo com a política de controle de acesso, de porque um acesso auditado particular foi permitido, as ditas razões sendo construídas a par- tir da política de controle de acesso propriamente dita, independentemente dos mecanismos de verificação de acesso.

19. Sistema para implementação de uma política de segurança de acesso a recur- sos de computador, CARACTERIZADO pelo fato de compreender: meios para auditar um acesso a recurso; e meios para fornecer razões, de acordo com a política de controle de acesso, porque um acesso auditado particular foi permitido, as ditas razões construídas a partir da dita polí- tica de controle de acesso propriamente dita, independentemente dos mecanismos de verifi- cação de acesso que possuem capacidades de expressão de política mais limitadas do que a política de controle de acesso.

20. Sistema, de acordo com a reivindicação 19, CARACTERIZADO pelo fato de compreender adicionalmente: meios para identificar as tentativas de acesso a recurso que não estão em acordo com a política de segurança de acesso com base na política de controle de acesso propria- mente dita, independentemente dos ditos mecanismos de verificação de acesso.