BRPI0711700A2 - translado de diretiva de controle de acesso baseado em função para diretiva de autorização de recursos - Google Patents

Abstract

TRANSLADO DE DIRETIVA DE CONTROLE DE ACESSO BASEADO EM FUNçãO PARA DIRETIVA DE AUTORIZAçãO DE RECURSOS. Transiação de modelos de autoração baseados em função para gerenciar "funções" RBAC para diretiva de autorização de recursos (RAP), tais como aplicações baseadas em ACL, é fornecida. Um sistema RBAC genérico é definido do qual mapeamentos para outro mecanismo de aplicação de autorização torna possível a transíação de "funções" RBAC para diretivas de autorização de recursos aplicadas a recursos gerenciados por um administrador de recursos, por exemplo, um administrador de recursos de sistema de arquivo. Está descrita uma implementação que usa o Windows Authorization Manager como um mecanismo de armazenamento e modelo de objeto para gerenciar tipos de objeto e relações transladados de um sistema RBAC.

Description

"TRANSLADO DE DIRETIVA DE CONTROLE DE ACESSO BASEADO EM FUNÇÃO PARA DIRETIVA DE AUTORIZAÇÃO DE RECURSOS"

CAMPO TÉCNICO

A presente invenção diz respeito a transladar diretiva de controle de acesso basea- do em função (RBAC) para diretiva de autorização de recursos.

ANTECEDENTES

Um dos problemas mais desafiadores no gerenciamento de grandes redes resulta da absoluta complexidade da administração de segurança, tornando autorização uma ques- tão importante em sistemas de computadores e de rede. Sob este aspecto, existem meca- nismos de autorização em sistemas de operação, aplicações, ou em qualquer lugar onde controle de acesso a recursos é envolvido. Autorização é tradicionalmente composta de dois processos separados: autenticação e controle de acesso. Autenticação lida com o problema "quem é o usuário?" e controle de acesso lida com o problema "o que o usuário pode fazer para/com um certo recurso?".

No nível de recurso, historicamente, redes têm usado diretiva de autorização de re- cursos (RAP) para decidir se um usuário está autorizado para se conectar a um recurso es- pecificado. Para uma RAP exemplar, redes de computação distribuída tradicionais têm usa- do listas de controle de acesso (ACL) baseadas em domínio como o mecanismo dominante para controle de acesso. Uma ACL especifica direitos de acesso de usuários para os recur- sos em termos de leitura, gravação ou execução de permissões em estruturas de dados, mas inevitavelmente leva a problemas de maneabilidade e complexidade à medida que o número de recursos e usuários continua a proliferar para grandes números nos espaços de computação compartilhados atualmente.

Ao contrário dos métodos de RAP convencionais de controle de acesso, os quais concedem ou revogam acesso de usuário em uma base rígida de objeto a objeto, uma alter- nativa para RAP é diretiva de controle de acesso baseado em função (RBAC), também chamada de segurança baseada em função. RBAC tem se tornado um modelo proeminente para controle de acesso porque ele reduz a complexidade e custo da administração de se- gurança em grandes aplicações de rede. RBAC é um método de regular acesso a computa- dor ou recursos de rede com base nas funções de usuários individuais dentro de uma em- presa. Neste contexto, acesso é a capacidade de um usuário individual para executar uma tarefa específica, tal como ver, criar ou modificar um arquivo. Funções são definidas de a- cordo com funções existentes/rótulos dentro da empresa, por exemplo, competência de ser- viço, autoridade ou responsabilidade.

Quando implementado de forma apropriada, RBAC capacita usuários para executar uma ampla faixa de tarefas autorizadas ao regular dinamicamente suas ações de acordo com funções, relações e restrições flexíveis. No RBAC, funções podem ser facilmente cria- das, mudadas, ou interrompidas à medida que as necessidades da empresa se desenvol- vem, sem ter que atualizar individualmente os privilégios para cada usuário.

RBAC capacita assim atividades que são difíceis em modelos de lista de controle de acesso (ACL) distribuídos na maioria dos sistemas de computadores. Tais atividades in- cluem aplicações através de consulta de autorização. Entretanto, atualmente não existe mo- do para transladar modelos de autoração baseados em função para gerenciar "funções" RBAC para diretiva de autorização de recursos (RAP)1 tais como aplicações baseadas em ACL1 ou outros mecanismos de aplicação de autorização. Tal como descrito com mais deta- lhes a seguir com relação às várias modalidades da invenção, seria desejável aperfeiçoar estas e outras deficiências do estado da técnica.

SUMÁRIO

Em vista do exposto anteriormente, a presente invenção fornece sistemas e méto- dos para transladar modelos de autoração baseados em função para gerenciar "funções" RBAC para diretiva de autorização de recursos (RAP), tais como aplicações baseadas em ACL1 ou outros mecanismos de aplicação de autorização. A invenção define assim um sis- tema RBAC genérico, a partir do qual mapeamentos para outro mecanismo de aplicação de autorização tornam possível a translação de "funções" RBAC para diretivas de autorização de recursos aplicadas aos recursos gerenciados por um administrador de recursos (por e- xemplo, um administrador de recursos de sistema de arquivo). Em uma modalidade exem- plar não limitativa, uma implementação é discutida usando Windows Authorization Manager como um mecanismo de armazenamento e modelo de objeto para gerenciar tipos de objeto e relações transladados de um sistema RBAC.

Outros recursos da presente invenção estão descritos a seguir.

DESENHOS

Os métodos para transladar diretiva RBAC para RAP em um ambiente de computa- ção de rede sao descritos adicionalmente com referencia aos desenhos anexos, nos quais:

A figura 1 é um diagrama de blocos de uma vista geral do sistema RBAC definido de acordo com a invenção;

A figura 2 é um diagrama de blocos de uma criação de exemplo de uma função pa- ra um sistema RBAC definido de acordo com a invenção;

Afigura 3 é um fluxograma exemplar mostrando a criação de diretiva RBAC, a atua- lização de diretiva RBAC e translação para estruturas RAP de acordo com a invenção;

A figura 4 é um diagrama de blocos mostrando as inter-relações de funções de em- presa e escopos baseados em recursos de aplicação de acordo com a definição de diretiva RBAC da invenção;

A figura 5 é um fluxograma exemplar não Iimitativo da criação de diretiva RBAC de acordo com a invenção, e translação automática correspondente para listas de controle de acesso (ACLs) de acordo com a invenção;

Afigura 6 é um diagrama de blocos exemplar mostrando a aplicação por recurso de entradas de controle de acesso (ACEs) em um sistema de autorização usando ACLs.

A figura 7Aé um diagrama de blocos representando um ambiente de rede exemplar no qual a presente invenção pode ser implementada; e

A figura 7B é um diagrama de blocos representando um ambiente exemplar não Ii- mitativo de sistema de computação no qual a presente invenção pode ser implementada.

DESCRIÇÃO DETALHADA

Vista Geral

RBAC é uma solução emergente para autorização centralizada através de uma or- ganização. RBAC capacita atividades que são difíceis nos modelos ACL distribuídos na mai- oria dos sistemas de computadores. Tais atividades incluem aplicações através de consulta de autorização. Em consideração às dificuldades de acomodar implementações ACL com- plexas em relação às vantagens de sistemas de diretiva RBAC1 a invenção fornece um mo- delo de autoração baseado em função para gerenciar "funções" RBAC que podem então ser transladadas para aplicações baseadas em ACL e outros mecanismos de aplicação de auto- rização. Para alcançar isto a invenção define um inédito sistema RBAC genérico, por exem- plo, baseado em modelos conceituais RBAC existentes.

Assim, em um aspecto da invenção, a invenção fornece um modelo RBAC que é compatível com estruturas de diretiva de autorização de recurso, tais como ACLs, de manei- ra que uma translação pode ser executada entre estruturas de dados baseadas em função para ACLs. Isto inclui a capacidade para mapear a diretiva RBAC para permissões baseadas em ACL.

Em vários outros aspectos não Iimitativos da invenção, métodos para implementar diretiva RBAC usando grupos de filiação são fornecidos. Além disso, várias modalidades não Iimitativas da ferramenta de autoração baseada em função da invenção incluem a capa- cidade para criar uma definição de nível de sistema para autorização baseada em função distribuída de recursos de computador.

Em uma implementação Windows exemplar não Iimitativa da invenção, a diretiva RBAC para capacidades de translação ACL da invenção fornecem translação de "Funções para ACLs" com o Windows Authorization Manager (WAM). Em tal implementação, o WAM é utilizado como um mecanismo de armazenamento e modelo de objeto para gerenciar tipos de objeto e relações que um sistema RBAC usa, os quais podem ser transladados para es- truturas de dados ACL de acordo com a diretiva de autorização de recursos. Adicionalmente, embora a invenção possa ser aplicada a uma grande variedade de sistemas de computado- res, em uma modalidade exemplar não Iimitativa o sistema de arquivo NTFS Windows é usado como um administrador de recursos exemplar. Os sistemas e métodos para transladar diretiva RBAC para diretiva de autorização de recursos (RAP) estão descritos em várias modalidades não Iimitativas a seguir. Entretan- to, os versados na técnica podem perceber, mediante avaliação das várias modalidades descritas neste documento, que a translação dos modelos de diretiva RBAC para modelos RAP de acordo com a invenção pode ser praticada através de uma variedade de modelos de diretiva RBAC, existentes agora ou projetados no futuro, ou com o modelo de diretiva RBAC definido de acordo com a invenção. Igualmente, uma pessoa pode perceber que dire- tiva RBAC pode ser transladada para uma variedade de modelos RAP, isto é, qualquer mo- delo que conceda privilégios ou autorização em estruturas e análise de dados por recurso, por aplicação ou por serviço, existentes agora ou projetadas no futuro, e assim a invenção não está limitada à RAP de acordo com modelos e modalidades baseados em ACL descritos neste documento.

Nomenclatura

Finalmente, com relação à nomenclatura, além de considerar o contexto de como os termos são usados, para a evitação de dúvida, os seguintes termos RBAC devem ser entendidos para significar o seguinte:

Escopo - Um conjunto de recursos;

Lista de Controle de Acesso (ACL) - Diretiva de controle de acesso em um recurso de computador;

Definição de função (ou função de aplicação) - Um conjunto de permissões que po- dem ser designadas para os mais importantes em um dado escopo;

Designação de função - Uma designação de uma definição de função de um ou mais dos mais importantes em um dado escopo;

Função Organizacional (ou grupo de funções) - Um conjunto de pessoas que têm as mesmas permissões em um dado conjunto de recursos (escopo);

Grupo Organizacional - Um tipo de grupo de segurança nativo para o modelo de a- plicação de autorização de um dado recurso de computador; e

Grupo de recursos - Um tipo de grupo de segurança nativo para o modelo de apli- cação de autorização de um dado recurso de computador que é usado para dar a elementos no grupo específico acesso a recursos específicos.

Definição de Diretiva RBAC e Translação de Diretiva RBAC para Diretiva de Autori- zação de Recursos

Tal como mencionado na seção de antecedentes, em geral, modelação RBAC for- nece economia de tempo, computação e complexidade em relação aos modelos de lista de controle de acesso (ACL) distribuídos, e são de forma conceituai mais fáceis para autorar porque eles mapeiam para conceitos organizacionais existentes. Também, não existe modo para transladar modelos de autoração baseados em função para gerenciar "funções" RBAC para diretiva de autorização de recursos (RAP)1 tais como aplicações baseadas em ACL.

Em consideração a estes e outros problemas do estado da técnica, em um alto ní- vel, o sistema RBAC da invenção fornece vantajosamente administração centralizada de recursos de computador de permissões de autorização baseados em funções organizacio- nais e leva em conta consultas em filiações e capacidades de função de usuário, e permite translação das estruturas baseadas em função para estruturas de autorização de recurso, tais como ACLs.

Desta maneira, tal como mostrado na figura 1, a invenção fornece um sistema RBAC que inclui um modelo de armazenamento centralizado RBAC RBAÇ_DB. Um principal atributo do armazenamento centralizado RBAC_DB é que toda a definição de diretiva da invenção pode ser armazenada ali. A diretiva necessariamente não necessita ser definida por um administrador dominante centralizado (um modelo de administração de delegação pode existir). Além disso, diretiva necessariamente não necessita ser autorada no armaze- namento central. Uma implementação distribuída pode distribuir autoração para outros ar- mazenamentos de diretiva, entretanto a diretiva eventualmente estará sincronizada com o armazenamento central. No sistema RBAC da figura 1, permissões de aplicação de uma diretiva de autorização de recursos de aplicação são definidas e são mapeadas para fun- ções de aplicação, ou vice-versa. Tal como mostrado, conjunto ou conjuntos de recursos, por exemplo, Arquivo compartilhado FS de Servidor de Arquivo FSRV, são definidos como escopo(s) S e Funções Organizacionais (ou de "Empresa") ERs são definidas em termos dos grupos de recursos RGs e grupos de usuários universais UGs nas definições de função RDs e os escopos S e permissões (designações de função RAs) dados para as funções de empresa ERs. A partir da definição das funções de empresa ERs com base nas definições de função RDs1 Escopo(s) S e Designações de Função RAs, o sistema RBAC pode criar os grupos UGs e RGs de um sistema de gerenciamento de identidade IMS, tal como, mas não se limitando a este, grupos de Diretório Ativo e pode configurar a diretiva de recurso, tal co- mo ACLs, tal como necessário.

A figura 2 ilustra um exemplo do modelo de armazenamento centralizado RBAC RBAC_DB tal como aplicado a um exemplo onde uma aplicação ou recurso de arquivo com- partilhado FS1 de servidor de arquivo FSRV é definido como um escopo S1. Neste exemplo, o conjunto de recursos FS1 é designado de \\Server\Share, tendo identificador de segurança (SID) e AccessMask: 0x1F01FF é definido como escopo S1 com o nome Documentos de Vendas para recursos em \\Server\Share. Uma Função de Empresa ER1 correspondente é então definida em termos dos grupos de recursos e grupos de usuários universais na defini- ção de função RD1 e o escopo S1 e a designação de função RA dada para as funções de empresa ER1. Vantajosamente, a partir da definição da Função de Empresa ER1 baseada na definição de função RD1, Escopo S1 e Designação de Função RA1, o sistema RBAC pode criar os grupos UG1 e RG1 de um sistema de gerenciamento de identidade IMS, tal como, mas não se limitando a estes, grupos de Diretório Ativo UG1 e RG1 de Diretório Ativo AD. A invenção pode ser assim utilizada para configurar a diretiva de recurso, tal como A- CLs1 tal como necessário, através da ótica de funções organizacionais do sistema RBAC da invenção.

A figura 3 ilustra um fluxograma exemplar não Iimitativo das estruturas de diretiva RBAC da invenção, tal como transladadas para estruturas de dados de diretiva de autoriza- ção de recursos de acordo com uma modalidade de sistema de arquivo da invenção (isto é, onde o sistema de arquivo contém os recursos solicitados). Em 300, função ou funções são definidas para cada um dos níveis de permissão de um arquivo para o sistema de arquivo (níveis feitos sob medida são possíveis). Em 310, escopo ou escopos são definidos em ter- mos de identificadores de recursos (por exemplo, arquivos compartilhados, diretórios ou arquivos). Em 320, a(s) função(s) ou o(s) escopo(s) pode(m) ser atualizado(s) de acordo com os dados mais atuais. Isto pode incluir atualizar grupos de filiação à medida que eles mudam em 320a e pode incluir mudanças de permissão de definição de função à medida que níveis de autorização organizacional se desenvolvem em 320b. Então, em 330, estas estruturas podem ser mapeadas para ACLs subjacentes que são estabelecidas para os re- cursos (isto é, ACLs de sistema de arquivo). Embora a figura 3 esteja descrita no contexto de um recurso de sistema de arquivo, os conceitos podem ser estendidos para a autorização de solicitações para qualquer tipo de recurso, aplicação ou serviço em um ambiente de computação de rede.

Integração de Aplicação

Tal como mostrado na figura 4, de acordo com o modelo RBAC e o armazenamento 400 da invenção, para uma aplicação particular, as permissões primitivas são primeiramente definidas dentro do sistema RBAC em termos de funções, isto é, Funções de Empresa ERs. Recursos de aplicação, tais como arquivo compartilhado FS1 são então acrescentados ao sistema RBAC por meio dos escopos S. Às Funções de empresa ERs é então permitido acesso dentro dos escopos S de acordo com designações de função e definições de função associadas com Funções de Empresa ERs.

Definições de Função de Aplicação

Para permitir gerenciamento e consultas de permissão a ser feitos centralmente, as permissões para cada tipo de aplicação também são fornecidas como entrada para o siste- ma RBAC. Isto é feito em termos de funções de aplicação definidas como conjuntos de per- missões correspondendo a uma função em uma aplicação. Como um exemplo não Iimitativo usando o sistema de arquivo Windows, a invenção define uma função para cada um dos níveis de permissão de Ul de Explorador de sistema de arquivo atual em termos das opera- ções (por exemplo, tal como disponível no Ul de editor de ACL avançado): Controle Total, Modificar, Ler & Executar, Ler e Gravar. Pode ser percebido que um conjunto de permissões feitas sob medida, a não ser os níveis de permissão de sistema de arquivo Windows, pode ser definido como uma definição de função de aplicação igualmente.

Definição de Escopo de Recurso

Para cada conjunto de recursos a ser designado para funções é definido um escopo de acordo com a invenção em termos de identificadores de recursos. No exemplo de siste- ma de arquivo, os recursos são arquivos compartilhados, diretórios ou arquivos. Os identifi- cadores de recursos podem ser o nome de caminho total para o recurso. Um escopo tam- bém pode ser definido mais amplamente incluindo recursos se estendendo sobre múltiplos servidores. No exemplo de sistema de arquivo Windows, por exemplo, um escopo como este pode ser definido em termos de uma lista delimitada por vírgulas dos nomes principais de usuário (UPNs) de arquivos compartilhados.

O nome de um escopo pode ser baseado no caminho para um container físico con- tendo os recursos de escopos. No exemplo de sistema de arquivo da figura 2, tal como mencionado, um nome de escopo como este pode ser: "\\Server\Share", que pode ser decla- rado mais de forma granular para um arquivo tal como \\folder\file se necessário. O nome de escopo também pode ser qualquer nome que descreva suficientemente os recursos, tal co- mo "Documentos de Vendas", o qual pode ser mais útil para um escopo se estendendo so- bre múltiplos documentos compartilhados em servidores em uma organização de vendas, isto é, um nome como este pode melhor mapear para a estrutura organizacional e caracte- rísticas operacionais.

O exemplo da figura 2 usa um escopo que contém um único arquivo compartilhado FS1. Esse nome de escopo é usado para prefixar um "grupo de recursos" que é então usa- do para povoar cada função. Se mais de um arquivo compartilhado ou diretório estiver sen- do usado, então a lista de arquivos compartilhados, arquivos, ou diretórios definindo o esco- po pode ser mantida no objeto de escopo S1.

Para cada conjunto de recursos (escopo), o administrador dos recursos capacita o sistema RBAC para gerenciar permissões pelo estabelecimento das permissões de recurso reais para permitir que a conta de serviço de autorização confiável atualize suas permissões. Em uma modalidade exemplar da invenção, se o escopo se aplicar a um arquivo comparti- lhado ou diretório com todos os seus recursos (arquivos e diretórios) dentro e abaixo de um arquivo compartilhado ou diretório especificado, então tais arquivos compartilhados ou dire- tórios são configurados para herdar permissões do arquivo compartilhado ou diretório espe- cificado por padrão.

Translacão de Função Para ACL

As ações seguintes são pré-formadas pelo sistema de translação RBAC para ACL executando em um controlador de domínio ou servidor de domínio na conta de serviço de autorização confiável definida anteriormente: Criação de Escopo, Criação de Função Orga- nizacional e Atualização de Diretiva incluindo Mudanças de Filiação e Mudanças de Permis- são de Definição de Função. Vários detalhes específicos de implementação não Iimitativos estão entrelaçados nas modalidades exemplares descritas a seguir, entretanto, pode ser percebido que a invenção pode ser aplicada independentemente de plataformas de compu- tação ou de qualquer modelo particular de diretiva de autorização de recursos.

Criação de Escopo

Quando um novo escopo é criado, o sistema RBAC da invenção cria um grupo de usuários para cada definição de função na aplicação. Assim, no exemplo de sistema de ar- quivo Windows, o sistema RBAC cria um grupo para cada uma das definições de função de aplicação: Controle Total, Modificar, Ler & Executar, Ler e Gravar. A estes grupos são conce- didas permissões nos recursos de computador e, portanto, são um grupo de segurança su- portado pelo modelo de aplicação de autorização nativo para o recurso de computador. Por exemplo, em um sistema Windows, estes grupos podem ser grupos de domínio local de Di- retório Ativo. Estes grupos têm nomes que descrevem escopo e permissão, tal como "Esco- po 1-controle total". Estes grupos definem as permissões para as funções organizacionais (tradicionalmente estes grupos são chamados de grupos de recursos). Para cada definição de função para relação de grupo de recursos, o sistema RBAC da invenção cria um objeto de designação de função no armazenamento de dados do sistema RBAC. Isto permite uma consulta de filiação de função de aplicação baseada em escopo, a qual retorna os elemen- tos do grupo de recursos. Às funções organizacionais são então designadas permissões para o escopo por meio de filiação nestes grupos.

O exposto a seguir descreve otimizações exemplares não Iimitativas para uma im- plementação Windows da invenção. Em uma implementação como esta, os recursos dentro de um escopo estão (idealmente) todos em um domínio e um Grupo Local de Domínio de Diretório Ativo (AD) satisfaz para tal propósito. Grupos locais de domínio são preferíveis, embora não obrigatórios, porque eles são somente acrescentados a um sinal do usuário quando o usuário entra em sessão para um servidor nesse domínio e não quando entrando em sessão para um outro domínio. Isto impede que SIDs sejam acrescentados ao sinal de entrada em sessão, o que diminuiria assim o tempo de entrada em sessão quando os SIDs não são necessários.

Também, em uma implementação como esta, é preferível não criar grupos de re- cursos até que funções organizacionais tenham sido designadas para a definição de função correspondente no escopo. Depois de criar os grupos, o sistema RBAC da invenção chama a API de gerenciamento de autorização apropriada (por exemplo, no Windows, esta seria NTMarta ou MACLs) para conceder ao grupo as permissões apropriadas nos recursos no escopo. Para o exemplo de sistema de arquivo, uma Entrada de Controle de Acesso (ACE) é então acrescentada, por exemplo, aos recursos no escopo, para cada grupo de recursos (Controle Total, Modificar, etc.). As permissões, por exemplo, a máscara de acesso, dadas para cada grupo são então recuperadas pela propriedade AccessMask de cada definição de função correspondendo ao grupo de recursos.

Em uma outra otimização exemplar não Iimitativa de uma implementação Windows da invenção, representações de Linguagem de Definição de Descritor de Segurança (SDDL) do descritor de segurança são armazenadas com suas definições de função corresponden- tes.

Criação de Função Organizacional

Para suportar consultas bidirecionais de funções para escopos e permissões de re- curso, tal como mencionado, cada Função Organizacional é definida no sistema RBAC. Para cada Função Organizacional o sistema RBAC da invenção cria um "Grupo Organizacional" no sistema de gerenciamento de identidade da organização (por exemplo, um Grupo Uni- versal de Diretório Ativo) e um objeto de Função Organizacional no armazenamento de sis- tema RBAC. O Grupo Organizacional inclui os elementos da Função Organizacional e é li- gado ao objeto de Função Organizacional no sistema RBAC.

Embora o Grupo Organizacional deva ser um grupo de segurança suportado pelo modelo de aplicação de autorização nativo para o recurso de computador, a filiação do gru- po pode ser gerenciada separadamente em quaisquer objetos de filiação dos sistemas. E- xemplos de tais filiações incluem, mas não se limitando a estes, grupos de segurança de domínio e lista de distribuição de correio eletrônico. O sistema RBAC da invenção pode sin- cronizar tais listas de filiação com grupos de segurança exigidos.

Em um aspecto opcional da invenção, o sistema RBAC pode ser estendido além do conceito principal por permitir que lógica de negócio seja capturada em primitivas listas de controle de acesso (ACL) de sistema de operação (OS), mas a invenção também pode ser estendida para grupos de correio eletrônico, por exemplo, Listas de Distribuição (DLs).

Quando uma nova função é criada no sistema RBAC da invenção, à nova função é designada permissões em termos das definições de função, tal como definido anteriormente, por exemplo, pelo administrador que criou a função. No sistema RBAC, à função organiza- cional é designada uma função de aplicação para um escopo por meio do objeto de desig- nação de função se relacionando à definição de função especificada e ao escopo.

Para cada Designação de Função para a Função Organizacional, o sistema RBAC da invenção designa o grupo de organização para o grupo de recursos casando com o es- copo especificado e definição de função, concedendo assim aos usuários na função as per- missões definidas na definição de função.

Atualização de Diretiva

O sistema RBAC da invenção suporta a capacidade para fazer atualizações de dire- tiva incluindo, mas não se limitando a estas, mudanças nas filiações ou nas permissões das funções, descritas como se segue.

Mudanças de Filiação

O sistema RBAC da invenção suporta Mudanças de Filiação para funções organi- zacionais, as quais são armazenadas no grupo organizacional, isto é, no sistema de geren- ciamento de identidade da organização, correspondendo à função organizacional. Uma im- plementação do sistema RBAC opcionalmente pode abstrair os grupos subjacentes ou esco- lher para expor o grupo organizacional como uma função.

Mudanças de Permissão de Definição de Função

Quando permissões são mudadas para uma função em um escopo, o administrador tipicamente faz assim pela adição ou remoção de funções de aplicação designadas para as funções organizacionais. Neste caso, o sistema RBAC da invenção acrescenta ou remove o grupo organizacional do grupo de recursos correspondendo à definição de função de aplica- ção sendo acrescentada ou removida da função.

Se uma definição de função de aplicação estiver sendo acrescentada ou apagada, então um grupo de recursos correspondente necessita ser criado ou apagado tal como des- crito anteriormente (por exemplo, ver Definição de Escopo de Recurso). Se uma definição de função de aplicação estiver sendo mudada, as permissões para os recursos de computa- dor são então atualizadas para dar ao conjunto atualizado de grupos de recursos as permis- sões apropriadas nos recursos de computador (tal como discutido na seção de criação de escopo anterior).

Implementações exemplares da invenção operam conforme o fluxograma da figura 5 de acordo com as etapas detalhadas descritas anteriormente. Em 500, funções de aplica- ção para o sistema RBAC da invenção são definidas. Em 510, escopo ou escopos de recur- so são definidos de acordo com o sistema RBAC da invenção. Em 520, grupos são definidos para cada escopo e cada função. Em 530, permissões são dadas para os grupos criados. Em 540, a diretiva RBAC definida assim de acordo com 500 a 530 pode ser mapeada para ACLs dentro do sistema para o propósito de executar diretiva de autorização de recursos subjacente, por exemplo, para diretórios, pastas, etc. de um sistema de arquivo.

Implementação AzMan Exemplar Não Limitativa

O exposto a seguir descreve uma implementação exemplar não limitativa da inven- ção usando o Windows Authorization Manager (AzMan) como um armazenamento de siste- ma RBAC. O AzMan do Servidor Windows fornece infra-estrutura para a administração de segurança baseada em função, tornando-a mais escalável, flexível e mais fácil de imple- mentar. Usando AzMan, funções podem ser definidas assim como as tarefas que essas fun- ções podem executar. Funções podem ser embutidas para herdar características de outras funções, e grupos de aplicação podem ser definidos. Além do mais, o AzMan capacita o uso de manuscritos para modificar permissões dinamicamente, e permite que lógica de seguran- ça seja envolvida na diretiva de segurança que pode ser armazenada no Diretório ativo. O AzMan também inclui uma API fácil de usar para executar verificações de acesso.

Sob este aspecto, o AzMan fornece um modelo conceituai RBAC similar tal como ao modelo descrito anteriormente de acordo com a invenção e também fornece mecanismos de armazenamento e interfaces administrativas. Assim, a estrutura AzMan pode ser alavan- cada para fornecer uma implementação de Funções para ACL que translada estruturas de diretiva baseada em função para estruturas de diretiva baseada em ACL. Em fazendo assim, os conceitos usados no sistema RBAC são implementados com os seguintes mapeamentos exemplares não limitativos:

Função Organizacional (ou grupo de funções) - Um objeto de grupo de aplicação AzMan.

Escopo - Um objeto de escopo AzMan.

Definição de função - (ou função de aplicação) - Um objeto de Definição de Função AzMan.

Designação de função - Um Objeto de designação de Função AzMan.

Nota: Grupos de aplicação AzMan podem ser definidos ou computados estatica- mente em tempo de execução.

Com relação à configuração para a implementação AzMan descrita atualmente, uma conta de Diretório Ativo (AD) é criada que é então usada por um serviço de autorização confiável para atualizar filiações de função no AD e ACLs nos recursos. Esta conta AD entra então em sessão para cada servidor de recurso a fim de atualizar as ACLs nos recursos. Então, um objeto de armazenamento de AzMan é criado e o serviço de autorização confiável é designado para a função administrativa de AzMan de Leitor de Diretiva.

Com relação à inicialização de aplicação na implementação Azman, uma aplicação é definida no AzMan para o administrador de recursos NTFS. As operações NTFS são ma- peadas para operações AzMan. Para simplificar o processo de conversão para máscara de acesso, cada permissão pode ser feita igual em número à máscara de acesso correspon- dente. Uma definição de Função AzMan é definida para cada nível de permissão no Editor NTFS ACL (Controle Total, Modificar, etc.) e uma máscara de acesso correspondente é ar- mazenada na propriedade Application Data no objeto de definição de função.

Com relação à criação de escopo na implementação Azman, para cada escopo, um escopo AzMan é definido na aplicação NTFS AzMan. A lista de arquivos compartilhados e UNCs de diretório no escopo podem ser retidos na propriedade Application Data do escopo de objeto AzMan.

Com relação à criação de função organizacional na implementação Azman, para cada função organizacional um grupo de aplicação global AzMan é criado. O grupo universal AD é designado para o grupo de aplicação global AzMan. Para cada função de aplicação para a qual a função organizacional é designada o sistema RBAC cria um objeto de Desig- nação de Função AzMan, o qual se vincula a uma definição de função definida de aplicação (isto é, Controle Total, Modificar, etc.)·

Para cada designação de função AzMan1 o sistema RBAC designa o grupo univer- sal AD para os grupos de recursos definidos anteriormente pela enumeração da lista de fun- ções organizacionais no AzMan1 isto é, os grupos de aplicação global AzMan1 e também para cada função enumerando os RoIeAssignments. Cada RoIeAssignment identifica um escopo e uma definição de função. O sistema RBAC designa então o grupo universal AD1 identificado como um elemento para o grupo de aplicação AzMan na implementação atual- mente descrita, para o grupo de recursos casando com o escopo e definição de função iden- tificada por cada objeto de designação de função.

Com relação às mudanças de filiação na implementação AzMan1 mudanças de filia- ção para funções organizacionais são armazenadas no grupo universal AD correspondendo à função organizacional. O sistema RBAC abstrai isto ou expõe o grupo AD e o grupo de aplicação AzMan contém pelo menos um dos grupos universais AD.

Com relação às mudanças de permissão na implementação AzMan1 mudanças de permissão são gerenciadas tal como elas foram anteriormente, com a tarefa adicional de acrescentar ou remover a designação do grupo global AzMan para as designações de fun- ção AzMan e acrescentar, eliminar, ou atualizar as definições de função AzMan quando permissões de função organizacional são adicionadas, apagadas ou mudadas.

Contexto Suplementar - Sistemas Baseados em ACL

Uma lista de controle de acesso (ACL) é uma estrutura de dados, tal como uma ta- bela, que informa um sistema de computador de quais direitos de acesso cada usuário tem para um objeto de sistema particular, tal como um diretório de arquivo ou arquivo individual. Cada objeto tem um atributo de segurança que identifica a sua lista de controle de acesso. A lista tem uma entrada para cada usuário de sistema com privilégios de acesso ou negação explícita de privilégios de acesso. Os privilégios mais comuns incluem a capacidade para ler um arquivo (ou todos os arquivos em um diretório), para gravar no arquivo ou arquivos, e para executar o arquivo (se ele for um arquivo executável, ou programa). Uma variedade de sistemas de operação usa listas de controle de acesso implementadas diferentemente por cada sistema de operação.

No Windows, de uma maneira geral, uma lista de controle de acesso (ACL) é asso- ciada com cada objeto de sistema. Cada ACL tem uma ou mais entradas de controle de a- cesso (ACEs) consistindo do nome de um usuário ou grupo de usuários. O usuário também pode ser um nome de função, tal como "programador", ou "medidor". Para cada um destes usuários, grupos ou funções os privilégios de acesso são relatados em uma cadeia de ca- racteres de bits chamada de máscara de acesso. De uma maneira geral, o administrador de sistema ou o proprietário de objeto cria a lista de controle de acesso para um objeto.

Tal como refletido pela figura 6, as ACLs 600a, 600b, 600c..... 600N incluem uma ou mais entradas de controle de acesso (ACEs). Por exemplo, a ACL 600a inclui a ACE1, ACE2.....ACEN. As ACLs são listas de ACEs que permitem/negam a um dirigente certos direitos. Cada uma das ACEs das ACLs pode ser mapeada por recurso, de tal maneira que cada recurso tem uma lista de ACEs das ACLs que se aplicam àquele recurso. Por exemplo, tal como mostrado, a ACE1, ACE2 e a ACEN da ACL 600a são mapeadas para vários recur- sos dos subcomponentes S1, S2, ..., SN do sistema de computação. Por exemplo, o sub- componente S1 pode ser um primeiro servidor, e S2 pode ser um segundo servidor, e assim por diante. Os recursos r1, r2, r3 são associados com o subcomponente S1, os recursos r4, r5, r6 são associados com o subcomponente S2 e os recursos rx, ry, rN são associados com o subcomponente SN. Entretanto, recursos podem ser subagrupados dentro do sistema, as ACEs das ACLs podem ser mapeadas para os recursos individuais do sistema de computa- ção tal como mostrado pelas linhas pontilhadas transladando das ACLs para diretiva basea- da em recurso baseada nas ACEs correspondentes.

Contexto Suplementar - Padrão NIST RBAC

Como um modelo de diretiva RBAC exemplar não limitativo, o Instituto Nacional de Padrões e Tecnologia (NIST) tem um padrão RBAC (isto é, Comitê Internacional para Pa- drões de Tecnologia de Informação (INCITS) Designação: INCITS 359), para o qual uma vista geral é fornecida como se segue. O padrão NIST inclui um modelo de referência defi- nindo alguns recursos RBAC admitidos comumente e especificações funcionais para os re- cursos RBAC definidos no modelo de referência. O padrão NIST consiste de duas partes principais - o Modelo de Referência RBAC e a Especificação Funcional de Sistema e Admi- nistrativa RBAC, as quais são descritas com mais detalhes a seguir.

O Modelo de Referência RBAC define conjuntos de elementos RBAC básicos (isto é, usuários, funções, permissões, operações e objetos) e relações tais como tipos e funções que estão incluídas neste padrão. O modelo de referência RBAC serve a dois propósitos. Primeiro, o modelo de referência define o escopo dos recursos RBAC que estão incluídos no padrão. Este identifica o conjunto mínimo de recursos incluídos em todos os sistemas RBAC compatíveis, aspectos de hierarquias de função, aspectos de relações de restrição estáticas, e aspectos de relações de restrição dinâmicas. Segundo, o modelo de referência fornece uma linguagem, em termos de conjuntos e funções de elemento, para uso na definição da especificação funcional.

A Especificação Funcional de Sistema e Administrativa RBAC especifica os recur- sos que são exigidos de um sistema RBAC. Estes recursos se incluem em três categorias, operações administrativas, avaliações administrativas e funcionalidade de nível de sistema. As operações administrativas definem funções em termos de uma interface administrativa e um conjunto associado de semânticas que fornecem a capacidade para criar, apagar e man- ter elementos e relações RBAC (por exemplo, para criar e apagar designações de função de usuário). Os recursos de avaliação administrativa definem funções em termos de uma inter- face administrativa e um conjunto associado de semânticas que fornecem a capacidade pa- ra executar operações de consulta nos elementos e relações RBAC. Funcionalidade de nível de sistema define recursos para a criação de sessões de usuário para incluir ativa- ção/desativação de função, a aplicação de restrições na ativação de função, e para cálculo de uma decisão de acesso.

O modelo de referência RBAC é definido em termos de quatro componentes de modelo - RBAC Núcleo, RBAC Hierárquico, Separação Estática de Relações de Deveres, e Separação Dinâmica de Relações de Deveres. Cada componente de modelo é definido pe- los seguintes subcomponentes: um conjunto de conjuntos de elementos básicos, um conjun- to de relações RBAC envolvendo esses conjuntos de elementos (contendo subconjuntos de produtos Cartesianos indicando designações válidas) e um conjunto de Funções de Mape- amento, que produzem exemplos de elementos a partir de um elemento, estabelecem para um dado exemplo a partir de um outro conjunto de elementos.

O RBAC Núcleo define uma coleção mínima de elementos RBAC, conjuntos de e- lementos e relações a fim de alcançar completamente um sistema de Controle de Acesso Baseado em Função. Este inclui designação de função de usuário e relações de designação de função de permissão, consideradas fundamentais em qualquer sistema RBAC. Além do mais, o RBAC Núcleo introduz o conceito de ativação de função como parte de uma sessão do usuário dentro de um sistema de computador. O RBAC Núcleo é exigido em qualquer sistema RBAC compatível com NIST, mas os outros componentes são independentes uns dos outros e podem ser implementados separadamente. O modelo RBAC como um todo é definido fundamentalmente em termos de usuários individuais sendo designados para fun- ções e permissões sendo designadas para funções. Como tal, uma função é um dispositivo para indicar relações de muitos para muitos entre usuários e permissões individuais. Além do mais, o modelo de núcleo RBAC inclui um conjunto de sessões (SESSÕES) onde cada sessão é um mapeamento entre um usuário e um subconjunto ativado de funções que são designadas para o usuário.

O RBAC Núcleo inclui conjuntos de cinco elementos de dados básicos chamados de usuários (USUÁRIOS), funções (FUNÇÕES), objetos (OBS), operações (OPS) e permis- sões (PRMS). Um usuário de uma maneira geral se refere a um humano sendo, mas como um conceito, a idéia de um usuário e umas credenciais do usuário podem ser estendidas para incluir máquinas, redes, ou agentes autônomos inteligentes que agem em nome de seres humanos de algum modo. Uma função é uma função de serviço dentro do contexto de uma organização com algumas semânticas associadas com referência à autoridade e res- ponsabilidade conferidas ao usuário designado para a função. Permissão é uma aprovação para executar uma operação em um ou mais objetos protegidos RBAC. Uma operação é uma imagem executável de um programa, a qual mediante invocação executa alguma fun- ção para o usuário. Os tipos de operações e objetos que RBAC controla são dependentes do tipo de sistema no qual ele será implementado. Por exemplo, dentro de um sistema de arquivo, operações podem incluir leitura, gravação e execução; dentro de um sistema de gerenciamento de base de dados, operações podem incluir inserção, eliminação, suplemen- tação e atualização. O propósito de qualquer mecanismo de controle de acesso é proteger recursos de sistema (isto é, objetos protegidos). Consistente com modelos anteriores de controle de acesso um objeto é uma entidade que contém ou recebe informação.

Cada sessão é um mapeamento de um usuário para possivelmente muitas funções, isto é, um usuário estabelece uma sessão durante a qual o usuário ativa algum subconjunto de funções que a ele é designado. Cada sessão é associada com um único usuário e cada usuário é associado com uma ou mais sessões. A função session_roles nos dá as funções ativadas pela sessão e a função session_users nos dá o usuário que está associado com uma sessão. As permissões disponíveis para o usuário são as permissões designadas para as funções que estão atualmente ativas através de todas as sessões do usuário.

O componente RBAC Hierárquico acrescenta relações para suportar hierarquias de função. Uma hierarquia é matematicamente uma ordem parcial definindo uma relação de antigüidade entre funções, pela qual funções mais antigas conseguem as permissões de suas mais novas e funções mais novas conseguem usuários de suas mais antigas. Além do mais, o RBAC Hierárquico vai além de simples usuário e designação de função de permis- são pela introdução do conceito de um conjunto da função de usuários autorizados e per- missões autorizadas.

Hierarquias são um meio natural de estruturar funções para refletir linhas de autori- dade e responsabilidade da organização. Hierarquias de função definem uma relação de herança entre funções. Herança tem sido descrita em termos de permissões; isto é, r1 "her- da" da função r2 se todos os privilégios de r2 também forem privilégios de r1. Para algumas implementações RBAC distribuídas permissões de função não são gerenciadas centralmen- te, enquanto que as hierarquias de função são. Para estas, hierarquias de função são ge- renciadas em termos de relações de contenção de usuário: a função r1 "contém" a função r2 se todos os usuários autorizados para r1 também forem autorizados para r2. Deve-se notar, entretanto, que contenção de usuário implica em que um usuário de r1 tenha (pelo menos) todos os privilégios de r2, enquanto que a herança de permissão para r1 e r2 não implica em qualquer coisa a respeito de designação de usuário.

Este padrão reconhece dois tipos de hierarquias de função - hierarquias gerais de função e hierarquias limitadas de função. Hierarquias gerais de função fornecem suporte para uma ordem parcial arbitrária para servir como a hierarquia de função, para incluir o conceito de múltiplas heranças de permissões e filiação de usuário entre funções. Hierarqui- as limitadas de função impõem restrições resultando em uma estrutura de árvore mais sim- pies (isto é, uma função pode ter um ou mais ascendentes imediatos, mas é restringida a um único descendente imediato).

Hierarquias gerais de função suportam o conceito de múltiplas heranças, o que for- nece a capacidade para herdar permissão de duas ou mais fontes de função e para herdar filiação de usuário de duas ou mais fontes de função.

Um terceiro componente de modelo, Relações de Separação Estática de Deveres (SSD), acrescenta relações de exclusividade entre funções com relação às designações de usuário. Conflito de interesse em um sistema baseado em função pode aparecer como re- sultado de um usuário ganhando autorização para permissões associadas com funções con- flitantes. Um meio de impedir esta forma de conflito de interesse é através de SSD, isto é, impor restrições na designação de usuários para funções. Por causa de o potencial para inconsistências com relação à separação estática de relações de deveres e relações de he- rança de uma hierarquia de função, o componente de modelo de relações SSD define rela- ções tanto na presença quanto na ausência de hierarquias de função. Restrições estáticas podem tomar uma grande variedade de formas. Um exemplo comum é um SSD que define separar mutuamente designações de usuário com relação a conjuntos de funções.

O quarto componente de modelo, Relações de Separação Dinâmica de Deveres (DSD)1 define relações de exclusividade com relação às funções que são ativadas como parte de uma sessão do usuário e fornece a capacidade para impor uma diretiva específica de organização de DSD.

Comparando SSDs e DSDs, relações SSD definem e colocam restrições em um espaço de permissão total do usuário. As relações SSD reduzem o número de potenciais permissões que podem ser tornadas disponíveis para um usuário pela colocação de restri- ções nos usuários que podem ser designados para um conjunto de funções. As relações DSD, tal como as relações SSD, são pretendidas para limitar as permissões que estão dis- poníveis para um usuário. Entretanto, relações DSD diferem das relações SSD pelo contexto no qual estas limitações são impostas. O componente de modelo de Relações DSD define propriedades DSD que limitam a disponibilidade das permissões em relação a um espaço de permissão do usuário pela colocação de restrições nas funções que podem ser ativadas dentro ou por meio de sessões do usuário. As propriedades DSD fornecem suporte estendi- do para o princípio de privilégio mínimo em que cada usuário tem diferentes níveis de per- missão em diferentes momentos, dependendo da função sendo executada. Estas proprieda- des asseguram que permissões não persistem além do tempo em que elas são exigidas para desempenho de deveres. Este aspecto de privilégio mínimo é freqüentemente referido como revogação conveniente de dever. Outras diferenças entre SSDs e DSDs existem i- gualmente e, como pode ser percebido, revogação dinâmica de permissões pode ser em vez disto uma questão complexa sem as estruturas de Separação Dinâmica de deveres, e como tal ela foi de uma maneira geral ignorada no passado por motivos de conveniência.

Ambientes Distribuídos e de Rede Exemplares

Os versados na técnica podem perceber que a invenção pode ser implementada em conexão com qualquer computador ou outro cliente ou dispositivo de servidor, o que po- de ser implementado como parte de uma rede de computadores ou em um ambiente de computação distribuída. Sob este aspecto, a presente invenção diz respeito a qualquer sis- tema ou ambiente de computador tendo qualquer número de unidades de memória ou de armazenamento, e qualquer número de aplicações e processos ocorrendo através de qual- quer número de unidades ou volumes de armazenamento, os quais podem ser usados em conexão com processos para transladar através de modelos de diretiva de acesso de acordo com a presente invenção. A presente invenção pode se aplicar a um ambiente com compu- tadores servidores e computadores clientes implementados em um ambiente de rede ou ambiente de computação distribuída, tendo armazenamento remoto ou local. A presente invenção também pode ser aplicada a dispositivos de computação autônomos, tendo funcio- nalidade de linguagem de programação, capacidades de interpretação e execução para ge- rar, receber e transmitir informação em conexão com serviços e processos remotos ou lo- cais.

Computação distribuída fornece compartilhamento de recursos e serviços de com- putador por meio de troca entre dispositivos e sistemas de computação. Estes recursos e serviços incluem a troca de informação, armazenamento intermediário de provisão e arma- zenamento de disco para objetos, tais como arquivos. Computação distribuída leva a vanta- gem da conectividade de rede, permitindo que clientes aproveitem suas energias coletivas para beneficiar a empresa total. Sob este aspecto, uma variedade de dispositivos pode ter aplicações, objetos ou recursos que podem implicar nos sistemas e métodos para executar translação por meio dos modelos de diretiva de acesso da invenção.

Afigura 7Afornece um diagrama esquemático de um ambiente de rede ou de com- putação distribuída exemplar. O ambiente de computação distribuída compreende os objetos de computação 10a, 10b, etc. e os objetos ou dispositivos de computação 110a, 110b, 110c, etc. Estes objetos podem compreender programas, métodos, armazenamentos de dados, lógica programável, etc. Os objetos podem compreender partes dos mesmos ou de disposi- tivos diferentes tais como PDAs, dispositivos de áudio/vídeo, reprodutores de MP3, compu- tadores pessoais, etc. Cada objeto pode se comunicar com um outro objeto através da rede de comunicações 14. Esta rede pode por si mesma compreender outros objetos de compu- tação e dispositivos de computação que forneçam serviços para o sistema da figura 7A, e pode por si mesma representar múltiplas redes interligadas. De acordo com um aspecto da invenção, cada objeto 10a, 10b, etc. ou 110a, 110b, 110c, etc. pode conter uma aplicação que pode fazer uso de uma API, ou outro objeto, software, firmware e/ou hardware, adequa- dos para uso com os sistemas e métodos para transladar de modelos de diretiva RBAC para modelos RAP de acordo com a invenção.

Também pode ser percebido que um objeto, tal como o 110c, pode ser hospedado em um outro dispositivo de computação 10a, 10b, etc. ou 110a, 110b, etc. Assim, embora o ambiente físico representado mostre os dispositivos conectados como computadores, tal ilustração é simplesmente exemplar e o ambiente físico alternativamente pode ser represen- tado ou descrito compreendendo vários dispositivos digitais tais como PDAs, televisões, re- produtores de MP3, etc., objetos de software tais como interfaces, objetos COM e outros mais.

Existe uma variedade de configurações de sistemas, componentes e de redes que suportam ambientes de computação distribuída. Por exemplo, sistemas de computação po- dem ser conectados conjuntamente através de sistemas com fio ou sem fio, através de re- des locais ou de redes amplamente distribuídas. Atualmente, muitas das redes são acopla- das à Internet, a qual fornece uma infra-estrutura para computação amplamente distribuída e abrange muitas redes diferentes. Qualquer uma das infra-estruturas pode ser usada para comunicações exemplares feitas incidentes para translado através de modelos de diretiva de acesso de acordo com a presente invenção.

Em ambientes de comunicação inter-rede de residência, existem pelo menos quatro mídias desiguais de transporte de rede em que cada uma pode suportar um protocolo exclu- sivo, tal como linha de energia, dados (tanto sem fio quanto com fio), voz (por exemplo, tele- fone) e mídias de entretenimento. Dispositivos de controle de residência tais como interrup- tores de luz e aparelhos elétricos podem usar linhas de energia para conectividade. Serviços de dados podem entrar na residência como banda larga (por exemplo, DSL ou Modem a cabo) e são acessíveis dentro da residência usando conectividade sem fio (por exemplo, HomeRF ou 802.11B) ou com fio (por exemplo, Home PNA, Cat 5, Ethernet, mesmo linha de energia). Tráfego de voz pode entrar na residência tal como com fio (por exemplo, Cat 3) ou sem fio (por exemplo, telefones celulares) e pode ser distribuído dentro da residência, por exemplo, usando fiação Cat 3. Mídias de entretenimento, ou outros dados gráficos, podem entrar na residência através de satélite ou cabo e são tipicamente distribuídos na residência usando cabo coaxial. IEEE 1394 e DVI também são conexões digitais para agrupamentos de dispositivos de mídia. Todos estes ambiente de redes e outros que possam aparecer, ou que já tenham se desenvolvido, como padrões de protocolo podem ser interligados para formar uma rede, tal como uma intranet, a qual pode ser conectada ao mundo externo atra- vés de uma rede de área estendida, tal como um ambiente de rede GSM ou a Internet. Em resumo, existe uma variedade de fontes desiguais para o armazenamento e transmissão de dados e, conseqüentemente, avançando, dispositivos de computação exigirão modos de compartilhamento de dados, tais como dados acessados ou utilizados incidentes para pro- gramar objetos, tal durante a translação por meio de modelos de diretiva de acesso de acor- do com a presente invenção.

A Internet comumente se refere à coleção de redes e portas de comunicação que utilizam o conjunto de protocolos de Protocolo de Controle de Transmissão/Protocolo de Internet (TCP/IP), os quais são bem conhecidos na técnica de rede de computadores. A In- ternet pode ser descrita como um sistema de redes de computadores remotos distribuídos geograficamente interligados pelos computadores executando protocolos de comunicação inter-rede que permitem aos usuários interagir e compartilhar informação através da(s) re- de(s). Por causa de tal compartilhamento de informação amplamente difundida, redes remo- tas tais como a Internet têm até aqui se desenvolvido de uma maneira geral para um siste- ma aberto com o que desenvolvedores podem projetar aplicações de software para executar operações ou serviços especializados, substancialmente sem restrição.

Assim, a infra-estrutura de rede capacita um hospedeiro de topologias de rede tais como arquiteturas de cliente/servidor, não hierárquicas ou híbridas. O "cliente" é um elemen- to de uma classe ou grupo que usa os serviços de uma outra classe ou grupo ao qual ele não está relacionado. Assim, em computação, um cliente é um processo, isto é, aproxima- damente um conjunto de instruções ou tarefas que solicita um serviço fornecido por um ou- tro programa. O processo cliente utiliza o serviço solicitado sem ter que "conhecer" quais- quer detalhes de trabalho a respeito do outro programa ou do serviço propriamente dito. Em uma arquitetura de cliente/servidor, particularmente um sistema de rede, um cliente é usu- almente um computador que acessa recursos de rede compartilhados fornecidos por um outro computador, por exemplo, um servidor. Na ilustração da figura 7A, como um exemplo, os computadores 110a, 110b, etc. podem ser considerados como clientes e os computado- res 10a, 10b, etc. podem ser considerados como servidores, onde os servidores 10a, 10b, etc. mantêm os dados que são então reproduzidos para os computadores clientes 110a, 110b, etc., embora qualquer computador possa ser considerado um cliente, um servidor, ou ambos, dependendo das circunstâncias. Qualquer um destes dispositivos de computação pode estar processando dados ou solicitando serviços ou tarefas que podem implicar na translação de RBAC para modelos RAP de acordo com a invenção.

Um servidor é tipicamente um sistema de computador remoto acessível através de uma rede remota ou local, tal como a Internet. O processo cliente pode estar ativo em um primeiro sistema de computador, e o processo servidor pode estar ativo em um segundo sistema de computador, em comunicação um com o outro através de uma mídia de comuni- cações, fornecendo assim funcionalidade distribuída e permitindo que múltiplos clientes ti- rem proveito das capacidades de coleta de informação do servidor. Quaisquer objetos de software utilizados conforme as técnicas para transladar através de modelos de diretiva de acesso da invenção podem ser distribuídos através de múltiplos dispositivos ou objetos de computação.

Cliente(s) e servidor(s) se comunicam um com o outro utilizando a funcionalidade fornecida por camada(s) de protocolo. Por exemplo, o Protocolo de Transferência de Hiper- texto (HTTP) é um protocolo comum que é usado em conjunto com a Rede de Alcance Mundial (WWW), ou "a Rede". Tipicamente, um endereço de rede de computadores tal como um endereço de protocolo de Internet (IP) ou outra referência tal como um Localizador Uni- versal de Recursos (URL) pode ser usado para identificar os computadores servidores ou clientes um com o outro. O endereço de rede pode ser referido como um endereço URL. Comunicação pode ser fornecida através de uma mídia de comunicações, por exemplo, cli- ente(s) e servidor(s) podem ser acoplados um ao outro por meio de conexão(s) TCP/IP para comunicação de alta capacidade.

Assim, a figura 7A ilustra um ambiente distribuído ou de rede exemplar, com servi- dões) em comunicação com computador(s) cliente(s) através de uma rede/barramento, no qual a presente invenção pode ser empregada. Com mais detalhes, os diversos servidores 10a, 10b, etc., são interligados através de uma rede de comunicações/barramento 14, a qual pode ser uma LAN, WAN, intranet, a Internet, etc., com diversos dispositivos de computação clientes ou remotos 110a, 110b, 110c, 110d, 110e, etc., tais como um computador portátil, computador de mão, cliente magro, de dispositivo de rede, ou outro dispositivo, tal como um VCR, TV, forno, luz, aquecedor e outros mais de acordo com a presente invenção. É assim considerado que a presente invenção pode se aplicar a qualquer dispositivo de computação em conexão com o qual é desejável transladar um modelo de diretiva de acesso para um outro.

Em um ambiente de rede no qual a rede de comunicações/barramento 14 é a Inter- net, por exemplo, os servidores 10a, 10b, etc. podem ser servidores da Rede com os quais os clientes 110a, 110b, 110c, 11 Od, 11 Oe1 etc. se comunicam por meio de qualquer um dos diversos protocolos conhecidos tais como HTTP. Os servidores 10a, 10b, etc. também po- dem servir como os clientes 110a, 110b, 110c, 11 Od, 11 Oe, etc., tal como pode ser caracte- rístico de um ambiente de computação distribuída.

Tal como mencionado, comunicações podem ser com fio ou sem fio, ou uma com- binação onde apropriado. Os dispositivos clientes 110a, 110b, 110c, 110d, 11 Oe, etc. podem ou não se comunicar através da rede de comunicações/barramento 14, e podem ter comu- nicações independentes associadas com isso. Por exemplo, no caso de uma TV ou VCR, pode ou não existir um aspecto de rede para o controle do mesmo. Cada computador cliente 110a, 110b, 110c, 110d, 110e, etc. e o computador servidor 10a, 10b, etc. podem ser equi- pados com os vários módulos ou objetos de programa de aplicação 135a, 135b, 135c, etc. e com conexões ou acesso a vários tipos de elementos ou objetos de armazenamento, por meio dos quais arquivos ou fluxos de dados podem ser armazenados ou dos quais parte(s) de arquivos ou fluxos de dados podem ser transferidos, transmitidos ou migrados. Qualquer um ou mais dos computadores 10a, 10b, 110a, 110b, etc. pode ser responsável pela manu- tenção e atualização de uma base de dados 20 ou outro elemento de armazenamento, tal como uma base de dados ou memória 20 para armazenar dados processados ou salvos de acordo com a invenção. Assim, a presente invenção pode ser utilizada em um ambiente de rede de computadores tendo os computadores clientes 110a, 110b, etc. que podem acessar e interagir com uma rede de computadores/barramento 14 e os computadores servidores 10a, 10b, etc. que podem interagir com os computadores clientes 110a, 110b, etc. e outros dispositivos semelhantes, e as bases de dados 20.

Dispositivo de Computação Exemplar

Tal como mencionado, a invenção se aplica a qualquer dispositivo em que pode ser desejável transladar através de modelos de diretiva de acesso de um dispositivo de compu- tação. Deve ser entendido, portanto, que dispositivos de computação e objetos de computa- ção portáteis, de mão e outros de todos os tipos são considerados para uso em conexão com a presente invenção, isto é, em qualquer lugar em que um dispositivo pode desejar transladar através de modelos de diretiva para controle de acesso (por exemplo, rede GSM por meio de um dispositivo portátil tal como um telefone móvel). Desta maneira, o computa- dor remoto de uso geral descrito a seguir na figura 7B é, todavia, um exemplo, e a presente invenção pode ser implementada com qualquer cliente tendo interoperabilidade e interação de rede/barramento. Assim, a presente invenção pode ser implementada em um ambiente de serviços hospedados de rede no qual muito pouco ou mínimos recursos de cliente são implicados, por exemplo, um ambiente de rede no qual o dispositivo cliente serve simples- mente como uma interface para a rede/barramento, tal como um objeto colocado em um dispositivo.

Embora não exigido, a invenção pode ser parcialmente implementada por meio de um sistema de operação, para uso por um desenvolvedor de serviços para um dispositivo ou objeto, e/ou incluída no software de aplicação que opera em conexão com o(s) componen- te(s) da invenção. Software pode ser descrito no contexto geral de instruções executáveis por computador, tais como módulos de programa, sendo executadas por um ou mais compu- tadores, tais como estações, servidores ou outros dispositivos clientes. Os versados na téc- nica perceberão que a invenção pode ser praticada com outras configurações e protocolos de sistema de computador.

A figura 7B ilustra assim um exemplo de um ambiente de sistema de computação adequado 100a no qual a invenção pode ser implementada, contudo, tal como deixado claro anteriormente, o ambiente de sistema de computação 100a é somente um exemplo de um ambiente de computação adequado para um dispositivo de computação e não é pretendido para sugerir qualquer limitação tal como para o escopo de uso ou funcionalidade da inven- ção. Nem o ambiente de computação 100a deve ser interpretado como tendo qualquer de- pendência ou exigência se relacionando com qualquer um ou combinação dos componentes ilustrados no ambiente de operação exemplar 100a.

Com referência à figura 7B, um dispositivo remoto exemplar para implementação da invenção inclui um dispositivo de computação de uso geral na forma de um computador 110a. Componentes do computador 110a podem incluir, mas não se limitando a estes, uma unidade de processamento 120a, uma memória de sistema 130a e um barramento de sis- tema 121a que acopla vários componentes de sistema incluindo a memória de sistema à unidade de processamento 120a. O barramento de sistema 121a pode ser qualquer um dos diversos tipos de estruturas de barramento incluindo um barramento de memória ou contro- lador de memória, um barramento periférico, e um barramento local usando qualquer uma de uma variedade de arquiteturas de barramento.

O computador 110a inclui tipicamente uma variedade de mídias legíveis por compu- tador. Mídias legíveis por computador podem ser quaisquer mídias disponíveis que possam ser acessadas pelo computador 110a. A título de exemplo, e não de limitação, mídias legí- veis por computador podem compreender mídias de armazenamento de computador e mí- dias de comunicação. Mídias de armazenamento de computador incluem tanto mídias volá- teis quanto não voláteis, removíveis quanto não removíveis implementadas em quaisquer métodos ou tecnologias para armazenamento de informação tais como instruções legíveis por computador, estruturas de dados, módulos de programa ou outros dados. Mídias de ar- mazenamento de computador incluem, mas não se limitando a estas, RAM, ROM, EEPROM, memória rápida ou outra tecnologia de memória, CDROM, discos versáteis digi- tais (DVD) ou outro armazenamento de disco ótico, cassetes magnéticos, fita magnética, armazenamento de disco magnético ou outros dispositivos de armazenamento magnético, ou qualquer outra mídia que possa ser usada para armazenar a informação desejada e que possa ser acessada pelo computador 110a. Mídias de comunicação tipicamente incorporam 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 incluem quaisquer mídias de entrega de informação.

A memória de sistema 130a pode incluir mídias de armazenamento de computador na forma de memória volátil e/ou não volátil tais como memória somente de leitura (ROM) e/ou memória de acesso aleatório (RAM). Um sistema de entrada/saída básico (BIOS), con- tendo as rotinas básicas que ajudam a transferir informação entre elementos dentro do computador 110a, tal como durante partida, pode ser armazenado na memória 130a. A me- mória 130a tipicamente também contém dados e/ou módulos de programa que são imedia- tamente acessíveis para a unidade de processamento 120a e/ou atualmente sendo opera- dos por ela. A título de exemplo, e não de limitação, a memória 130a também pode incluir um sistema de operação, programas de aplicação, outros módulos de programa e dados de programa.

O computador 110a também pode incluir outras mídias de armazenamento de com- putador removíveis/não removíveis, voláteis/não voláteis. Por exemplo, o computador 110a pode incluir uma unidade de disco rígido que lê mídias magnéticas não removíveis não volá- teis ou grava nelas, uma unidade de disco magnético que lê um disco magnético não volátil removível ou grava nele, e/ou uma unidade de disco ótico que lê um disco ótico não volátil removível ou grava nele, tal como um CD-ROM ou outras mídias óticas. Outras mídias de armazenamento de computador removíveis/não removíveis, voláteis/não voláteis que podem ser usadas no ambiente de operação exemplar incluem, mas não se limitando a estas, cas- setes de fita magnética, cartões de memória rápida, discos versáteis digitais, fita de vídeo digital, RAM de estado sólido, ROM de estado sólido e outros mais. Uma unidade de disco rígido é tipicamente conectada ao barramento de sistema 121a por meio de uma interface de memória não removível tal como uma interface, e uma unidade de disco magnético ou unidade de disco ótico é tipicamente conectada ao barramento de sistema 121a por meio de uma interface de memória removível, tal como uma interface.

Um usuário pode entrar com comandos e informação no computador 110a por meio de dispositivos de entrada tais como um teclado e dispositivo apontador, comumente referi- do como um mouse, mouse estacionário ou superfície sensível ao toque. Outros dispositivos de entrada podem incluir um microfone, comando de jogos, controle manual de jogos, ante- na parabólica, digitalizador, ou coisa parecida. Estes e outros dispositivos de entrada são freqüentemente conectados à unidade de processamento 120a por meio da entrada de usu- ário 140a e interface ou interfaces associadas que são acopladas ao barramento de sistema 121a, mas podem ser conectadas por meio de outra interface e outras estruturas de barra- mento, tais como uma porta paralela, porta de jogos ou um barramento serial universal (USB). Um subsistema de gráficos também pode ser conectado ao barramento de sistema 121a. Um monitor ou outro tipo de dispositivo de exibição também é conectado ao barra- mento de sistema 121a por meio de uma interface, tal como a interface de saída 150a, a qual por sua vez pode se comunicar com memória de vídeo. Além de um monitor, computa- dores também podem incluir outros dispositivos periféricos de saída tais como alto-falantes e uma impressora, os quais podem ser conectados por meio da interface de saída 150a.

O computador 110a pode operar em um ambiente distribuído ou de rede usando conexões lógicas para um ou mais outros computadores remotos, tal como o computador remoto 170a, o qual por sua vez pode ter capacidades, tais como capacidades de mídia, diferentes das do dispositivo 110a. O computador remoto 170a pode ser um computador pessoal, um servidor, um roteador, um PC de rede, um dispositivo de pares ou outro nó de rede comum, ou qualquer outro dispositivo remoto de consumo ou de transmissão de mídia, e pode incluir qualquer um ou todos os elementos descritos anteriormente em relação ao computador 110a. As conexões lógicas representadas na figura 7B incluem uma rede 171a, tal como rede de área local (LAN) ou uma rede de área estendida (WAN)1 mas também po- dem incluir outras redes/barramentos. Tais ambientes de comunicação inter-rede são co- muns em residências, escritórios, redes de computadores estendidas de empresa, intranets e na Internet.

Quando usado em um ambiente de comunicação inter-rede LAN, o computador 110a é conectado à LAN 171a por meio de uma interface ou adaptador de rede. Quando usado em um ambiente de comunicação inter-rede WAN, o computador 110a inclui tipica- mente um componente de rede (placa de rede, modem, etc.) ou outro dispositivo para esta- belecer comunicações através da WAN, tal como a Internet. Um dispositivo para se conectar a uma rede, a qual pode ser interna ou externa, pode ser conectado ao barramento de sis- tema 121a por meio da interface de entrada de usuário da entrada 140a, ou por outro meca- nismo apropriado. Em um ambiente de rede, módulos de programa representados em rela- ção ao computador 110a, ou a partes do mesmo, podem ser armazenados em um dispositi- vo remoto de armazenamento de memória. Será percebido que as conexões de rede mos- tradas e descritas são exemplares e outros meios de se estabelecer um elo de comunica- ções entre os computadores podem ser usados.

Estruturas ou Arquiteturas de Computação Distribuída Exemplares

Várias estruturas de computação distribuída têm sido e estão sendo desenvolvidas considerando a convergência de computação pessoal e a Internet. Usuários individuais e de negócio são providos do mesmo modo com uma interface interoperável e capacitada na Rede de forma ininterrupta para aplicações e dispositivos de computação, construindo ativi- dades de computação de navegador da Rede ou orientadas em rede de modo crescente.

Por exemplo, a plataforma de código gerenciado da MICROSOFT®, isto é, a .NET1 inclui servidores, blocos construtivos de serviços, tais como armazenamento de dados ba- seado na Rede e software de dispositivo transferível. Falando de uma maneira geral, a pla- taforma .NET fornece (1) a capacidade para fazer a faixa total de dispositivos de computa- ção trabalhar conjuntamente e para ter informação de usuário atualizada e sincronizada au- tomaticamente em todos eles, (2) capacidade interativa aumentada para páginas da Rede, capacitada pelo maior uso de XML em vez de HTML, (3) serviços em linha direta que carac- terizam acesso e entrega customizados de produtos e serviços para o usuário de um ponto de partida central para o gerenciamento de várias aplicações, tal como correio eletrônico, por exemplo, ou software, tal como o Office .NET1 (4) armazenamento de dados centraliza- do, o que aumenta eficiência e facilidade de acesso à informação, assim como sincroniza- ção de informação entre usuários e dispositivos, (5) a capacidade para integrar várias mídias de comunicações, tais como correio eletrônico, faxes e telefones, (6) para desenvolvedores, a capacidade para criar módulos reutilizáveis, aumentando assim produtividade e reduzindo o número de erros de programação e (7) muitos outros recursos de integração de multiplata- forma e de linguagem igualmente.

Embora algumas modalidades exemplares neste documento estejam descritas em conexão com software, tal como uma interface de programação de aplicações (API), residin- do em um dispositivo de computação, uma ou mais partes da invenção também podem ser implementadas por meio de um sistema de operação, ou um objeto "intermediário", um obje- to de controle, hardware, firmware, instruções ou objetos de linguagem intermediários, etc. De tal maneira que os métodos para transladar através de modelos de diretiva de acordo com a invenção podem ser acessados por meio de todas as linguagens e serviços capacita- dos por código gerenciado e incluídos ou suportados por estes, tal como o código .NET1 e em outras estruturas de computação distribuída igualmente.

Existem múltiplos modos de implementar a presente invenção, por exemplo, uma API apropriada, kit de ferramentas, código acionador, sistema de operação, controle, objeto de software autônomo ou transferível, etc. que capacitam aplicações e serviços para usar os sistemas e métodos para transladar através de modelos de diretiva da invenção. A invenção considera o uso da invenção a partir do ponto de vista de uma API (ou de outro objeto de software), assim como a partir de um objeto de software ou de hardware que recebe um programa transferido de acordo com a invenção. Assim, várias implementações da invenção descritas neste documento podem ter aspectos que estão completamente em hardware, parcialmente em hardware e parcialmente em software, assim como em software.

Tal como mencionado anteriormente, embora modalidades exemplares da presente invenção tenham sido descritas em conexão com vários dispositivos de computação e arqui- teturas de rede, os conceitos subjacentes podem ser aplicados a qualquer dispositivo ou sistema de computação no qual é desejável transladar um modelo de diretiva de acesso para um outro. Por exemplo, o(s) algoritmo(s) e implementações de hardware da invenção podem ser aplicados ao sistema de operação de um dispositivo de computação, fornecido como um objeto separado no dispositivo, como parte de um outro objeto, como um controle reutilizável, como um objeto transferível de um servidor, como um "intermediário" entre um dispositivo ou objeto e a rede, como um objeto distribuído, como hardware, na memória, uma combinação de quaisquer dos anteriores, etc. Embora linguagens de programação e- xemplares, nomes e exemplos sejam escolhidos neste documento como representativos de várias alternativas, estas linguagens, nomes e exemplos não são pretendidos para ser limi- tativos. Os versados na técnica compreenderão que existem inúmeros modos de fornecer código e nomenclatura de objeto que alcançam funcionalidade igual, similar ou equivalente à alcançada pelas várias modalidades da invenção.

Tal como mencionado, as várias técnicas descritas neste documento podem ser im- plementadas em conexão com hardware ou software ou, onde apropriado, com uma combi- nação de ambos. Assim, os métodos e aparelho da presente invenção, ou certos aspectos ou partes da mesma, podem tomar a forma de código de programa (isto é, instruções) incor- porado em mídias tangíveis, tais como discos flexíveis, CD-ROMs, unidades rígidas, ou qualquer outra mídia de armazenamento legível por máquina, em que, 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 praticar a invenção. No caso de execução de código de programa em computadores programáveis, o dispositivo de computação de uma maneira geral inclui um processador, uma mídia de armazenamento legível pelo processador (incluindo memória volátil e não volátil e/ou elementos de armazenamento), pelo menos um dispositivo de en- trada e pelo menos um dispositivo de saída. Um ou mais programas que podem implemen- tar ou utilizar os métodos para transladar através de modelos de diretiva da presente inven- ção, por exemplo, por meio do uso de uma API de processamento de dados, controles reuti- lizáveis, ou coisa parecida, são preferivelmente implementados em um alto nível processual ou em linguagem de programação de objeto orientado para se comunicar com um sistema de computador. Entretanto, o(s) programa(s) pode(m) ser implementado(s) em linguagem de montagem ou de máquina, se desejado. Em qualquer caso, a linguagem pode ser uma lin- guagem compilada ou interpretada e combinada com implementações de hardware.

Os métodos e aparelho da presente invenção também podem ser praticados por meio de comunicações incorporadas na forma de código de programa que é transmitido a- través de alguma mídia de transmissão, tal como através de fiação ou cabeamento elétrico, através de fibras óticas, ou por meio de qualquer outra forma de transmissão, em que, quando o código de programa é recebido, carregado e executado por uma máquina, tal co- mo uma EPROM, uma matriz de portas, um dispositivo lógico programável (PLD), um com- putador cliente, etc., a máquina se torna um aparelho para praticar a invenção. Quando im- plementados em um processador de uso geral, o código de programa combina com o pro- cessador para fornecer um aparelho exclusivo que opera para chamar a funcionalidade da presente invenção. Adicionalmente, quaisquer técnicas de armazenamento usadas em co- nexão com a presente invenção invariavelmente podem ser uma combinação de hardware e software.

Embora a presente invenção tenha sido descrita em conexão com as modalidades preferidas das várias figuras, é para ser entendido que outras modalidades similares podem ser usadas ou modificações e adições podem ser feitas à modalidade descrita para executar a mesma função da presente invenção sem desviar desta. Por exemplo, embora ambientes de rede exemplares da invenção estejam descritos no contexto de um ambiente de rede, tal como um ambiente de rede não hierárquico, os versados na técnica reconhecerão que a presente invenção não está limitada a isto, e que os métodos, tal como descrito no presente pedido, podem se aplicar a qualquer dispositivo ou ambiente de computação, tal como uma mesa de comando de jogos de computador, computador portátil, computador de mão, etc., se com fio ou sem fio, e podem ser aplicados a qualquer número de tais dispositivos de computação conectados através de uma rede de comunicações, e interagindo através da rede. Além disso, deve ser enfatizado que uma variedade de plataformas de computador, incluindo sistema de operação de dispositivos portátil e outros sistemas de operação de a- plicação específica são considerados, especialmente à medida que o número de dispositi- vos de rede sem fio continua a proliferar.

Embora modalidades exemplares se refiram a utilizar a presente invenção no con- texto de construções de linguagem de programação particulares, a invenção não está assim limitada, mas em vez disto pode ser implementada em qualquer linguagem para fornecer métodos para transladar através de modelos de diretiva. Ainda adicionalmente, a presente invenção pode ser implementada em uma pluralidade de microplaquetas ou dispositivos de processamento ou através deles, e armazenamento pode ser efetuado de forma similar a- través de uma pluralidade de dispositivos. Portanto, a presente invenção não deve ser Iimi- tada a qualquer modalidade única, mas em vez disto deve ser interpretada em amplitude e escopo de acordo com as reivindicações anexas.

Claims (21)

1. Método para autorar diretiva de controle de acesso baseado em função em um ambiente de computação de rede, CARACTERIZADO pelo fato de que compreende: definir pelo menos um escopo, em que cada escopo representa um conjunto de re- cursos no ambiente de computação de rede 510; definir pelo menos uma função de aplicação, cada uma incluindo um conjunto de permissões que são designadas para os mais importantes em um dado escopo 500; e definir pelo menos um grupo de recursos dos mais importantes em um sistema de gerenciamento de identidade organizacional, em que cada um dos elementos do pelo me- nos um grupo de recursos é designado para acesso a recursos específicos de acordo com um escopo do pelo menos um escopo e uma função de aplicação da pelo menos uma fun- ção de aplicação 520.

2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende adicionalmente: conceder ou negar permissões para o pelo menos um grupo de recursos com base no escopo e função de aplicação correspondentes do grupo de recursos.

3. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende adicionalmente: transladar o pelo menos um escopo, a pelo menos uma função de aplicação e o pe- lo menos um grupo de recursos para permissões correspondendo a um modelo de diretiva de autorização de recursos.

4. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende adicionalmente: transladar o pelo menos um escopo, a pelo menos uma função de aplicação e o pe- lo menos um grupo de recursos para estruturas de dados correspondendo a um modelo de diretiva de autorização de recursos.

5. Método, de acordo com a reivindicação 4, CARACTERIZADO pelo fato de que compreende adicionalmente: transladar o pelo menos um escopo, a pelo menos uma função de aplicação e o pe- lo menos um grupo de recursos para formar informação de translação para transladar para estruturas de dados de lista de controle de acesso (ACL) e entrada de controle de acesso (ACE) de um modelo de diretiva de autorização de recursos baseado em ACLs e ACEs.

6. Método, de acordo com a reivindicação 5, CARACTERIZADO pelo fato de que o modelo de diretiva de autorização de recursos baseado em ACLs e ACEs é o Windows Au- thorization Manager (AzMan).

7. Método, de acordo com a reivindicação 5, CARACTERIZADO pelo fato de que compreende adicionalmente: propagar a informação de translação para estruturas de dados de lista de controle de acesso (ACL) e entrada de controle de acesso (ACE) do ambiente de computação de rede.

8. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a dita definição do pelo menos um grupo de recursos dos mais importantes inclui selecionar um grupo de filiação pré-existente associado com uma organização operando no ambiente de computação de rede.

9. Método, de acordo com a reivindicação 8, CARACTERIZADO pelo fato de que compreende adicionalmente: atualizar o pelo menos um grupo de recursos quando o grupo de filiação pré- existente muda.

10. Método, de acordo com a reivindicação 9, CARACTERIZADO pelo fato de que a dita definição do pelo menos um grupo de recursos dos mais importantes inclui selecionar um grupo de correios eletrônicos ou uma lista de distribuição associados com a organização.

11. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que um escopo do pelo menos um escopo é definido como um ou mais de uma coleção de ar- quivos, pastas ou outros objetos tal como organizados por um sistema de arquivo do siste- ma de operação.

12. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende adicionalmente: atualizar o pelo menos um escopo quando um conjunto de recursos associados com um escopo muda.

13. Interface de programação de aplicações, CARACTERIZADA pelo fato de que compreende módulos de interface executáveis por computador tendo instruções executáveis por computador para executar o método de acordo com a reivindicação 1.

14. Mídia legível por computador para armazenar dados de diretiva de controle de acesso baseado em função para controlar acesso em um ambiente de computação de rede, CARACTERIZADA pelo fato de que compreende: uma primeira estrutura de dados incluindo dados de escopo representando pelo menos um escopo, em que cada escopo representa um conjunto de recursos no ambiente de computação de rede 310; uma segunda estrutura de dados incluindo dados de função definindo pelo menos uma função de aplicação, cada função de aplicação incluindo um conjunto de permissões que são designadas para os mais importantes em um dado escopo 300; e uma terceira estrutura de dados incluindo dados de grupo definindo pelo menos um grupo de recursos dos mais importantes em um sistema de gerenciamento de identidade organizacional, em que a cada um dos elementos do pelo menos um grupo de recursos é concedido ou negado acesso a recursos específicos de acordo com um escopo do pelo me- nos um escopo e uma função de aplicação da pelo menos uma função de aplicação, em que as primeira, segunda e terceira estruturas de dados são mapeáveis de a- cordo com uma função de mapeamento predeterminada para estruturas de dados associa- das com uma diretiva de autorização de recursos que aplica diretiva de autorização por re- curso 600a-N.

15. Mídia legível por computador, de acordo com a reivindicação 14, CARACTERIZADA pelo fato de que a diretiva de autorização de recursos é uma diretiva de autorização de recursos que inclui estruturas de dados de listas de controle de acesso (A- CEs) como a autorização de recurso de base.

16. Mídia legível por computador, de acordo com a reivindicação 14, CARACTERIZADA pelo fato de que compreende adicionalmente: um módulo executável por computador para autorar as primeira, segunda e terceira estruturas de dados.

17. Mídia legível por computador, de acordo com a reivindicação 14, CARACTERIZADA pelo fato de que compreende adicionalmente: um módulo executável por computador para transladar as primeira, segunda e ter- ceira estruturas de dados para as estruturas de dados associadas com a diretiva de autori- zação de recursos.

18. Mídia legível por computador, de acordo com a reivindicação 14, CARACTERIZADA pelo fato de que compreende adicionalmente: um módulo executável por computador para transladar as primeira, segunda e ter- ceira estruturas de dados para as permissões associadas com a diretiva de autorização de recursos.

19. Ferramenta de autoração para criar diretiva de controle de acesso baseado em função para ser imposta em um ambiente de computação de rede incluindo autorizações baseadas em diretiva de autorização de recursos, CARACTERIZADA pelo fato de que com- preende: dispositivo para definir pelo menos um escopo, em que cada escopo representa um conjunto de recursos no ambiente de computação de rede 510; dispositivo para definir pelo menos uma função de aplicação, cada uma incluindo um conjunto de permissões que são designadas para os mais importantes em um dado es- copo 500; e dispositivo para definir pelo menos um grupo de recursos dos mais importantes em um sistema de gerenciamento de identidade organizacional, em que cada um dos elementos do pelo menos um grupo de recursos é designado para acesso a recursos específicos de acordo com um escopo do pelo menos um escopo e uma função de aplicação da pelo me- nos uma função de aplicação 520.

20. Ferramenta de autoração, de acordo com a reivindicação 19, CARACTERIZADA pelo fato de que compreende adicionalmente: dispositivo para conceder ou negar permissões ao pelo menos um grupo de recur- sos com base no escopo e função de aplicação correspondentes do grupo de recursos.

21. Ferramenta de autoração, de acordo com a reivindicação 20, CARACTERIZADA pelo fato de que compreende adicionalmente: dispositivo para transladar o pelo menos um escopo, a pelo menos uma função de aplicação e o pelo menos um grupo de recursos para permissões correspondendo ao mode- lo de diretiva de autorização de recursos.