BRPI0609954A2

BRPI0609954A2 - segurança baseada na região

Info

Publication number: BRPI0609954A2
Application number: BRPI0609954-8A
Authority: BR
Inventors: Ziquan Li; Tanmoy Dutta
Original assignee: Microsoft Corp
Priority date: 2005-05-04
Filing date: 2006-03-09
Publication date: 2010-05-11
Also published as: SG161277A1; ES2600745T3; JP2008541226A; EP1875389A4; NO20074868L; RU2413978C2; NZ561945A; CN101375275B; TW200639673A; RU2007140924A; WO2006118662A3; WO2006118662A2; CN101375275A; TWI399662B; EP1875389B1; MX2007012421A; AU2006241479A1; KR101292430B1; EP1875389A2; IL186068A0

Abstract

SEGURANçA BASEADA NA REGIãO. A invenção exposta se refere a sistemas e métodos que provêem segurança baseada na região para os objetos da base de dados tendo relações hierárquicas. Em um aspecto, um sistema é provido que facilita a segurança e o gerenciamento da base de dados. O sistema inclui um componente da base de dados que armazena uma pluralidade de objetos tendo uma relação hierárquica entre os objetos. Um componente de região define zonas de segurança para um subconjunto dos objetos e mapeia os dados de segurança para o subconjunto, onde as zonas de segurança são independentes, separadas ou dissociadas das relações hierárquicas entre os objetos.

Description

"SEGURANÇA BASEADA NA REGIÃO"

CAMPO TÉCNICO

A invenção exposta se refere de forma geral a sis-temas de computador, e mais particularmente, se refere asistemas e métodos que provêem segurança para um subconjuntode objetos baseados em um descritor de região para o subcon-junto de modo a mitigar a propagação dos dados e exigências dearmazenamento de hierarquias de herança de objeto clássicas.

ANTECEDENTES DA INVENÇÃO

0 projeto de base de dados comercial moderno in-clui um hospedeiro das considerações dos dados complexos en-volvendo como armazenar, gerenciar e manipular grandes quan-tidades de dados. Tais dados freqüentemente incluem relaçõesintrincadas com outros dados tal como em uma árvore de obje-tos provendo propriedades de herança entre vários obj etos.Esses tipos de relações freqüentemente complicam o projetoeficiente dos bancos de dados e componentes para gerenciartais dados. Por exemplo, um aspecto para o processo de pro-jeto da base de dados se situa no entendimento da maneira emque um sistema de gerenciamento da base de dados relacionaiarmazena os dados. Para munir, de maneira eficiente e preci-sa, os usuários com a informação, um programa de base de da-dos precisa acessar fatos (dados) sobre tópicos diferentesarmazenados em tabelas separadas. Por exemplo, uma tabelapode somente armazenar fatos sobre empregados e uma outratabela pode somente armazenar fatos com relação às vendas ea seguir outras tabelas para alguma outra matéria incorpora-da. Quando usando os dados, esses fatos são então automati-camente combinados e apresentados em muitas maneiras dife-rentes . Por exemplo, os usuários podem imprimir relatóriosque combinam fatos sobre empregados e fatos sobre vendas.

De forma geral, para proj etar uma base de dados, ainformação é quebrada em alguma ordem tal como tópicos sepa-rados em uma biblioteca e a seguir um programa de base dedados determina como os tópicos são relacionados. Esses pro-gramas freqüentemente incluem uma consulta de base de dadosrelacionai usando uma linguagem de base de dados comum talcomo a linguagem de consulta estruturada (SQL). Antes quetais linguagens possam ser aplicadas nos dados, várias deci-sões são geralmente tomadas quanto a quais tipos de dadossão importantes e como tais dados devem ser organizados. Porexemplo, essas decisões podem incluir determinar o escopo deuma base de dados para decidir quais dados armazenar nele. Aseguir, determinar as tabelas necessárias para dividir a in-formação em tópicos separados, tais como "empregados" ou"pedidos". Cada tópico então será uma tabela na base de da-dos . Outros aspectos incluem determinar campos respectivosque são necessários de modo a decidir qual informação arma-zenar em cada tabela. Cada categoria de informação em umatabela é chamada um campo e é exibida como uma coluna na ta-bela. Por exemplo, um campo em uma tabela de empregados po-deria ser o último nome, um outro poderia ser data de alu-guel. Uma outra consideração é determinar as relações talcomo decidindo como os dados em uma tabela estão relaciona-dos com os dados em outras tabelas. Projetistas freqüente-mente adicionam campos em tabelas ou criam novas tabelas pa-ra esclarecer as relações, quando necessário.

Existem várias ciladas comuns que podem ser encon-tradas quando projetando uma base de dados. Esses problemaspodem fazer com que os dados sejam mais difíceis de usar emanter. Esses podem incluir ter uma tabela com um grande nú-mero de campos que não se referem todos ao mesmo tópico. Porexemplo, uma tabela poderia conter campos pertencentes aosclientes bem como campos que contêm informação de vendas.Também, é freqüentemente mais eficiente se cada tabela con-tém dados relacionados com somente um tópico. Em outros ca-sos , um extra é criado quando os campos são intencionalmentedeixados em branco em muitos registros porque eles não sãoaplicáveis a esses registros. Isso geralmente implica que oscampos pertencem a uma outra tabela. A redundância é um ou-tro problema quando existe um grande número de tabelas, mui-tas das quais tendo os mesmos campos. Por exemplo, quandoseparando tabelas para vendas de janeiro e vendas de feve-reiro, ou para clientes locais e clientes distantes, nasquais existe um armazenamento redundante do mesmo tipo deinformação. Assim, uma técnica é consolidar toda a informa-ção pertencente a um único tópico em uma tabela.

Além das complexidades de como configurar e proje-tar as tabelas e os campos da base de dados, outras conside-rações devem ser observadas. Essas incluem como a segurançados dados deve ser provida para as tabelas e os campos res-pectivos (por exemplo, segurança tal como quem ou o que podeacessar um arquivo). Isso inclui como prover segurança paraestruturas complexas armazenadas em bancos de dados tal comoobjetos hierárquicos. Classicamente, considerações de segu-rança foram propagadas em uma hierarquia de herança paratais obj et os, onde cada item na hierarquia precisaria seratualizado se um dos itens fosse alterado. Entretanto, exis-te um problema comum confrontado por qualquer implementaçãoque utiliza linhas de tabela de base de dados relacionai pa-ra armazenar obj etos hierárquicos, que é como estabelecer ainformação de segurança ou os dados em cada objeto e preen-cher os dados de segurança para seus objetos filhos com baseno modelo de herança.

SUMÁRIO DA INVENÇÃO

O seguinte apresenta um sumário simplificado dainvenção a fim de prover um entendimento básico de algunsaspectos da invenção. Esse sumário não é uma visão geral ex-tensiva da invenção. Ele não é planejado para identificarelementos chaves/críticos da invenção ou para delinear o es-copo da invenção. Sua única finalidade é apresentar algunsconceitos da invenção em uma forma simplificada como um pre-lúdio para a descrição mais detalhada que é apresentada aseguir.

A invenção exposta se refere a sistemas e métodosque provêem segurança baseada na região para uma pluralidadede objetos da base de dados tendo relações hierárquicas en-tre os obj etos. Um componente de região é provido que mapeiaa informação de segurança para um subconjunto de obj etos queexistem em uma hierarquia a fim de criar uma ou mais zonasde segurança que são independentes da hierarquia. Isso per-mite que os objetos existentes em uma região ou zona compar-tilhem atributos de segurança, o que mitiga as exigências deprocessamento da base de dados (por exemplo, menos nós nosquais atualizar os dados de segurança). Em geral, arquitetu-ras clássicas de base de dados freqüentemente utilizam li-nhas de tabela da base de dados relacionai para armazenarobjetos hierárquicos, o que também faz com que um descritorde segurança relacionado seja estabelecido em cada objeto etambém preenche o descritor de segurança para obj etos filhosrespectivos com base no modelo de herança. Isso causa quan-tidades cada vez mais crescentes de tempo de processamentopara cada atualização de objeto e é mitigado pela introduçãodas considerações baseadas na região.

Uma região pode ser uma coleção de objetos (nãotem que estar em uma árvore contigua) que compartilham omesmo descritor de segurança ou similar. Quando um descritorde segurança em um objeto é atualizado, a região à qual oobj eto pertence pode rachar ou colapsar. Por exemplo, umaregião pode rachar se um descritor de segurança diferente emqualquer objeto filho resulta da mudança; enquanto que umaregião pode colapsar em uma outra região se a mudança resul-ta no mesmo descritor de segurança que esse da outra região.Ao invés de cada objeto diretamente possuir o seu própriodescritor de segurança, uma região possui o descritor de se-gurança; assim dramaticamente reduzindo o número de atuali-zações de objeto quando um descritor de segurança em um ob-jeto é alterado que pode afetar os descritores de segurança em outros objetos.

Em geral, uma região é classicamente definida comouma subárvore de objetos em um modelo de objeto hierárquico.No caso da invenção exposta, uma região é definida como umconjunto de objetos que compartilham o mesmo descritor desegurança, por meio do que esses objetos que compartilham omesmo descritor de segurança não têm que ficar sob a mesmasubárvore. Essa falta de controle permite que processos efi-cientes manipulem os descritores de segurança dos objetos.Assim, a segurança baseada na região essencialmente trans-forma um domínio de objeto em um domínio de descritor de se-gurança e executa as operações do descritor de segurança nodomínio do descritor de segurança direta e independentementeda hierarquia que mitiga o processamento geral da base dedados.

Para a realização das finalidades precedentes erelacionadas, certos aspectos ilustrativos da invenção sãodescritos aqui em conj unto com a descrição seguinte e os de-senhos anexos. Esses aspectos são indicativos das várias ma-neiras nas quais a invenção pode ser praticada, todas asquais são planejadas para serem cobertas pela invenção ex-posta. Outras vantagens e novos aspectos da invenção podemse tornar evidentes a partir da descrição detalhada seguinteda invenção quando considerada em conjunto com os desenhos.

BREVE DESCRIÇÃO DOS DESENHOS

A Figura 1 é um diagrama de blocos esquemático i-lustrando um sistema de segurança de objeto de acordo com umaspecto da invenção exposta.

A Figura 2 é um diagrama ilustrando uma transfor-mação de domínio de segurança exemplar de acordo com um as-pecto da invenção exposta.

A Figura 3 ilustra uma transformação de domínio desegurança alternativo de acordo com um aspecto da invenção exposta.

A Figura 4 ilustra interfaces de segurança exem-plares de acordo com um aspecto da invenção exposta.

A Figura 5 ilustra o processamento do componenteda região de acordo com um aspecto da invenção exposta.

A Figura 6 ilustra algoritmos de processamento deregião exemplares de acordo com um aspecto da invenção ex-posta.

A Figura 7 ilustra um processo da região de segu-rança de acordo com um aspecto da invenção exposta.

A Figura 8 é um diagrama de blocos esquemático i-lustrando um ambiente de operação adequado de acordo com umaspecto da invenção exposta.

A Figura 9 é um diagrama de blocos esquemático deum ambiente de computação exemplar com o qual a invenção ex-posta pode interagir.

DESCRIÇÃO DETALHADA DA INVENÇÃO

A invenção exposta se refere a sistemas e métodosque provêem segurança baseada na região para obj etos da basede dados tendo relações hierárquicas. Ao invés de atualizarum descritor de segurança separado para cada objeto, a in-venção exposta introduz o conceito de uma região, por meiodo que a segurança para um dado objeto é derivada da sua as-sociação com a região em oposição à hierarquia. Isso está emcontraste com as arquiteturas clássicas que exigem descri-ções de objeto individuais e têm segurança imposta pela hie-rarquia da herança. Dessa maneira, o processamento da basede dados e o armazenamento podem ser conservados desde quemuitos objetos podem compartilhar atributos de segurança si-milares que podem ser definidos em uma escala mais globalpara a região respectiva. Em um aspecto, um sistema é provi-do que facilita a segurança da base de dados e o gerencia-mento . 0 sistema inclui um componente de base de dados quearmazena uma pluralidade de objetos tendo uma relação hie-rárquica entre os objetos. Um componente de região definezonas de segurança para um subconjunto dos objetos e mapeiaos dados de segurança para o subconj unto, onde as zonas desegurança são independentes, separadas ou dissociadas dasrelações hierárquicas entre os obj etos.

Como usado nesse pedido, os termos "componente","sistema", "objeto", "zona" e semelhantes são planejados pa-ra se referir a uma entidade relacionada com computador,hardware, uma combinação de hardware e software, software ousoftware em execução. Por exemplo, um componente pode ser,mas não é limitado a ser, um processo funcionando em um pro-cessador, um processador, um objeto, um executável, um enca-deamento da execução, um programa e/ou um computador. Pormeio de ilustração, ambos uma aplicação funcionando em umservidor e o servidor podem ser um componente. Um ou maiscomponentes podem residir dentro de um processo e/ou encade-amento da execução e um componente pode estar localizado emum computador e/ou distribuído entre dois ou mais computado-res . Também, esses componentes podem executar de vários mei-os legíveis por computador tendo várias estruturas de dadosarmazenadas neles. Os componentes podem se comunicar atravésde processos locais e/ou remotos tal como de acordo com umsinal tendo um ou mais pacotes de dados (por exemplo, dadosde um componente interagindo com um outro componente em umsistema local, sistema distribuído e/ou através de uma redetal como a Internet com outros sistemas através do sinal).

Com referência inicialmente à figura 1, um sistemade segurança do objeto 100 é ilustrado de acordo com um as-pecto da invenção exposta. O sistema 100 inclui uma base dedados relacionai 110 (por exemplo, SQL ou outro tipo de basede dados) que é associado com um componente da região 120(ou componentes) que define uma ou mais zonas de segurançado objeto 130. Em geral, nós individuais de uma hierarquiade objeto (por exemplo, ver um obj eto da hierarquia no nume-rai de referência 140) não são individualmente atualizadosquando as mudanças da segurança do obj eto são feitas. Ao in-vés disso, as estratégias de segurança são atribuídas pelocomponente da região 120 pela zonas de segurança respectivasem 130. Pelo mapeamento dos objetos para uma zona de segu-rança 130 ao invés de atualização de cada objeto individual-mente, o número de operações de leitura/gravação na base dedados 110 pode ser mitigado. Assim, o componente da região120 transforma o mapeamento da estratégia de segurança deuma hierarquia de herança - onde cada objeto é atualizado,para um dominio de segurança de objetos onde zonas de obje-tos compartilham uma estratégia de segurança similar. Dessamaneira, um subconjunto menor de atualizações de segurançapode ser propagado quando a estratégia de segurança de umobjeto muda meramente atualizando o subconjunto reduzido dezonas de segurança 130 em oposição à atualização de cada ob-jeto individual em uma hierarquia de herança clássica. É ob-servado que os conceitos de herança podem ser utilizados pa-ra propagar a estratégia no sistema 100, entretanto, a he-rança fica entre as zonas de segurança 130 ao invés da he-rança convencional entre os objetos em uma árvore. Assim, aherança ocorre entre componentes que são modelados em um do-mínio de segurança ao invés de em um domínio de objeto. Issoimplica que os mapeamentos de segurança para um objeto res-pectivo ficam entre o obj eto e sua zona associada 130 ao in-vés de explicitamente configurado pelo objeto individual140. Portanto, o componente de região 120 prove segurançapara uma região de objetos identificados e essencialmentesepara, dissocia ou é independente das hierarquias de obj etoconvencionais que propagam as mudanças de segurança para to-dos os objetos na hierarquia.

Em geral, os itens na base de dados 110 podem seratribuídos com um ID (identificador) para um descritor desegurança. A base de dados inclui uma tabela [Table!Item]tendo uma coluna chamada SDID (ID do descritor de seguran-ça) . Esse SDID é um ID único de um descritor de segurançaque é armazenado e mantido em uma tabela do sistema SQL o-culto, por exemplo. Uma tabela do sistema pode ser expostaatravés de uma visualização pública (por exemplo,Sys.Security_Descriptor) . A tabela seguinte é uma ilustraçãosimplificada de como um descritor de segurança pode ser co-nectado ou associado com um modelo de objeto básico:

[Table!Item]: Associa um item com um ID do descri-tor de segurança.

<table>table see original document page 12</column></row><table>

Para eficientemente atribuir um ID do descritor desegurança (SD ID) para um item do objeto, a tecnologia daregião do SD é baseada em parte na observação que a maiorparte dos itens de objeto tende a compartilhar o mesmo des-critor de segurança. Uma região do SD é um conj unto de itens(que não tem que ser contiguo como nos sistemas convencio-nais) que compartilham o mesmo SD ID ou similar. Tipicamen-te, todos os itens na [Table!Item] mostrada acima podem seragrupados em regiões de SD diferentes. A relação das regiõesde SD pode ser estabelecida em uma tal maneira que o SD deuma região de SD pode herdar do SD de uma outra região de SDno dominio de segurança descrito acima. Essencialmente, umaárvore da região do SD é estabelecida que é comparável com aárvore do item do objeto correspondente, mas com menos nóscomo será mostrado com relação às figuras 2 e 3 abaixo. Aárvore da região do SD, assim, pode ser usada para atualizaro SD do item eficientemente. Tipicamente quando uma árvoredo item de segurança é criada, três regiões de SD são cria-das para atribuir SDs para substancialmente todos os itensna árvore. Assim, uma região de SD é para o item da raiz(onde um SD explicito é definido), uma outra região de SD épara os itens de conteiner respectivos e o último SD paraitens sem contêiner.

Com referência agora às figuras 2 e 3, transforma-ções do domínio de segurança exemplares 200 e 300 são ilus-tradas de acordo com um aspecto da invenção exposta. Em 200da figura 2, os nós de uma árvore de objetos são ilustrados,onde o nó preto em 210 é um item de raiz, nós cinzas em 220são itens de contêiner e nós brancos em 2 30 são itens semcontêiner. Quando um descritor de segurança (SD) do item éatualizado (por exemplo, mudando o dono do SD, grupo, listade controle de acesso e assim por diante) , a região do SDonde o item pertence pode ser dividida em três subgrupos ousubconjuntos como ilustrado em 240. As mudanças de segurançasão geralmente efetuadas através de dados citados como umaentrada de controle de acesso (ACE) que pode ser de uma for-ma explicita ou implícita. Quando ACEs explicitas são adi-cionadas no SD de um item, novas regiões de SD podem sercriadas ao redor desse item. Nesse caso, três regiões de SDsão criadas, uma para o próprio item (onde as ACEs explici-tas são adicionadas), uma para os seus filhos de contêiner euma para seus filhos sem contêiner. Com referência à figura3, uma situação mais complexa é ilustrada quando uma ACE ex-plicita não propagada é adicionada em um SD em um item em310, em cujo caso cinco novas regiões são criadas ao redordo item como ilustrado em 320. Nesse caso, uma região é cri-ada para o próprio item (onde a ACE explicita é adicionada)330, uma região para seus filhos de contêiner direto em, umaregião para seus filhos sem contêiner direto em 350, uma re-gião para seus filhos de contêiner não direto em 360 e umaregião para seus filhos sem contêiner não direto em 370.

Para resumir as figuras 2 e 3, novas regiões podemser criadas quando o SD de um item é atualizado explicita-mente (não através da herança). De forma geral, 3 ou 5 novasregiões (outras quantidades possíveis) são criadas dependen-do das atualizações sendo feitas no SD. Cinco regiões de SDsão criadas se uma ACE não propagada é adicionada e três re-giões de SD são geralmente criadas em outros casos. Como umexemplo, assuma o item cujo SD contém propriedades não her-dadas (ACEs não herdadas na maior parte dos casos) como oitem de raiz. Como mencionado acima, o item de raiz do tipode contêiner pode possuir 3 ou 5 regiões de SD dependendodos tipos de ACEs explicitas no SD. Um não contêiner podeter sua própria região de SD se o seu SD tem propriedadesexplicitas. Se todas as propriedades explicitas de um SD doitem de raiz são removidas, então as regiões de SD possuídaspor esse item de raiz podem ser colapsadas no SD do seu itemde pai que então mitiga as atualizações de segurança do ob-jeto individuais. Cada região de SD pode ser representadacomo uma linha em uma tabela de Security_Hierachy tal como oexemplo seguinte:

[Table!Security_Hierachy]: Armazena a relação deherança do SD e estabelece os itens para compartilhar o mes-mo descritor de segurança.

<table>table see original document page 15</column></row><table>

As colunas da tabela acima podem incluir um _SDIdque é o ID da região do SD, um campo _SDIdParent que é o IDdo SD de onde as propriedades de segurança herdadas estãovindo, um campo _RootItemId que é o ID do item onde o SD ex-plicito é definido, um campo _IsContainer que élseoSDseaplica no conteiner ou 0 para um sem conteiner e um campo_Scope que é codificado como segue: 0: o SD se aplica no i-tem de raiz. 1: o SD se aplica somente nos filhos do item deraiz. 2: o SD se aplica nos filhos diretos do item de raiz.3: o SD se aplica nos filhos não diretos do item de raiz.

É observado que quando uma base de dados é auto-carregado, três descritorés de segurança padrão podem sercriados se desejado; um descritor para o item da raiz supe-rior, um descritor para todos os filhos de conte iner e umdescritor para todos os filhos sem conteiner. Conseqüente-mente, três regiões de SD no item de raiz superior podem sercriadas também. Tipicamente, todos os itens subseqüentementecriados no volume podem ter um dos SDs como seu SD padrão.

Quando ACEs explicitas são adicionadas no item, novas regi-ões de SD podem ser criadas como discutido acima.

A Figura 4 ilustra interfaces de segurança exem-plares 400 de acordo com um aspecto da invenção exposta. Vá-rias interfaces de segurança 4 00 podem ser providas para in-teragir com as considerações baseadas na região descrita a-cima. O seguinte descreverá apenas uns poucos exemplos deinterface que podem ser aplicadas. Esses podem incluir in-terfaces para recuperar os dados de segurança em 410, inter-faces para estabelecer a informação de segurança em 420 einterfaces para ligações de retenção como será descrito emmais detalhes abaixo. O seguinte fragmento de código é umexemplo de uma declaração pública para algumas dessas inter-faces 400.

Public sealed class ItemSecurity

{

public ItemSecurity( Guid itemid )

public string GetSDDLSecurity()

public GenericSecurityDescriptor GetSecurity()

public void SetSDDLSecurity( string sd,

SECURITY_INFORMATION si )

public void SetSecurity( GenericSecurityDescriptor

gsd, SECURITY_INFORMATION si )

public string GetüserEffectiveSecurity()public void AddHoldingLink( Guid itemld )public void RemoveHoldingLink( Guid itemld )

}

O seguinte prove uma breve descrição para as in-terfaces de segurança 410 a 430:

public string GetSDDLSecurity() - Recupera todo odescritor de segurança no item no formato de seqüência deSDDL. Ele inclui listas de controle de acesso herdadas e ex-plicitas .

public GenericSecurityDescriptor GetSecurity()Recupera todo o descritor de segurança no item no formato deuma classe ACLs gerenciada GenericSecurityDescriptor.

public void SetSDDLSecurity ( string sd,SECURITY_INFORMATION si ) - Ajusta o descritor de segurançano item. Essa função ignora as ACEs herdadas. Ela regeneraas ACEs herdadas do seu pai e outras ligações de retenção.Ela pode ser chamada para ajustar o dono, o grupo, indicadorde controle ou ACEs explicitas.

SECURITY_INFORMATION especifica qual parte do des-critor de segurança é para ser atualizada.

public void SetSecurity( GenericSecurityDescriptorgsd, SECURITY_INFORMATION si ) - Ajusta o descritor de segu-rança no item. Toma a classe de ACLs gerenciada como o parâ-metro de entrada.

public void AddHoldingLink ( Guid itemld ) - Atua-liza o descritor de segurança no item quando adicionando umanova ligação de retenção no item.

public void RemoveHoldingLink ( Guid itemld ) - A-tualiza o descritor de segurança no item quando removendouma nova ligação de retenção do item.

public string GetUserEffectiveSecurity() - Recupe-ra o descritor de segurança no item que contém as ACEs rele-vantes para o contexto de segurança atual.

A figura 5 ilustra o processamento do componenteda região 500 de acordo com um aspecto da invenção exposta.Em 510, as definições- da região são providas. Essas incluemuma região do descritor de segurança (SD) que é um conjuntode itens que compartilham o mesmo SD. O conjunto de itensnão tem que formar uma árvore contígua. Uma linha de hierar-quia de segurança (SH) é uma linha em uma tabela [Ta-ble!Security_Hierachy] listada abaixo. Cada região de SD de-ve ter uma linha de SH na tabela.

<table>table see original document page 18</column></row><table>

Uma linha na tabela acima é citada como uma linhade SH que corresponde com uma região de SD. Linhas nessa ta-bela indicam um conjunto de itens (pode ser um item único)que compartilham o mesmo descritor de segurança (SD1 no e-xemplo acima) . 0 conjunto de itens é definido por uma raizcomum (o Itemld), um tipo comum (contêiner ou sem contêiner)e um escopo. 0 escopo é opcional para suportar modelos desegurança de sistema operacional diferentes.

Em 520, as considerações de criação e intercalaçãoda região são descritas. Nesse aspecto, uma nova região deSD pode ser criada sob as seguintes condições:

1. Mudanças de SD feitas em um item sem contêiner.

Três novas regiões de SD podem ser criadas sob asseguintes condições:

1. Mudanças de SD feitas em um item de con-têiner e

2. As mudanças de SD não incluem ACEs nãopropagadas.

Cinco novas regiões de SD podem ser criadas sob asseguintes condições;

1. Mudanças de SD feitas em um item de con-têiner e

2.As mudanças de SD incluem ACEs não propagadas .

As regiões de SD podem ser intercaladas sob as se-guintes condições:

1. SD do pai está forçando a herança do SDesvaziando os SDs do filho ou

2. ACEs explicitas são removidas de um SD.

Em 530, várias noções são providas que podem serutilizadas nos algoritmos seguintes descritos com relação àfigura 6. Essas notações incluem:

Item ou * - O sistema de item atual aplicando as operações.

SDId(x) ou SDId - O sd_id do descritor de segurança no item x.

SDId_NC(x) ou SDId_NC - O SD se aplica ao objetos filhos sem contêiner do item x.

SDId_C(x) ou SDId_C -O SDId se aplica aos objetos filhos de contêiner do item x.

SDId_NC2(x) ou SDId_NC2 - 0 SDId se aplica a objetos filhos sem contêiner diretos do item x.

SDId_C2(x) ou SDId_C2 - O SDId se aplica a objetos filhos de contêiner direto do item x.

SDId_NC3(x) ou SDId_NC3 - 0 SDId se aplica a objetos filhos sem contêiner não diretos do item x.

SDId_C3(x) ou SDId_C3 - O SDId se aplica a objetos filhos de contêiner não diretos do item x.

SHRow (x, i, j) - A fila na tabela [Ta-ble!Security_Hierachy] onde _RootItemId = x,_IsContainer =i, _Scope = j.

UpdateltemSD(OldSDid, NewSDId, Rootltem, IsContai-ner, Scope) - Atualização do SDId de todos os itens do tipo(IsContainer) cujo SDId atual = OldSDid, predecessor é Roo-tltem dentro do Scope para NewSDId.

UpdateSDBlob(SDId) - Atualiza o conteúdo dos des-critores de segurança desse SDId e seus filhos se o SDId deseus filhos não formam um circulo com esse SDId. Por exem-pio, quando uma ligação de retenção (com SDO) é adicionadaem um item de arquivo (com SDl) que não tem sua própria li-nha na tabela [Table!Security_Hierachy] , três linhas serãocriadas (SDO, SDl, _Item, 0, 0), (SDl, SDO, _Item, 0, 1)(SDl, SDO, _Item, 1, 1) . Aqui reutilizar SDO para os itensfilhos desse item para reduzir significativamente o númerode atualizações na tabela [Table!Item].

UpdateSDId (SDId, SDIdJSIew) - Atualiza as linhasdo item atual em [Table!Security_Hierachy] onde _SDId = SDIdpara estabelecer _SDId = SDId_New.

UpdateParentSDId (SDIdPar, SDIdPar_New) - Atualizaas linhas de [Table! Security__Hierachy] onde _ParentSDId =SDIdPar para estabelecer _ParentSDId = SDIdPar_New.

CreateNewSD (SDId) - Criar um novo SD do SD atualmais as mudanças sendo feitas (adicionar/remover ACEs, adi-cionar/remover ligações de retenção).

A Figura 6 ilustra os algoritmos de processamentode região exemplares 600 de acordo com um aspecto da inven-ção exposta. Nesse aspecto, pelo menos três algoritmos sepa-rados ou combinados 600 podem ser utilizados para efetuar osprocessos da região. Esses incluem um estabelecer descritorde segurança em 610; um adicionar ligação de retenção 620 eum remover algoritmo da ligação de retenção em 630. Com re-lação ao estabelecer descritor de segurança 610, existem vá-rias maneiras para alterar o descritor de segurança em umobjeto que pelo menos incluem:

• Adicionar/remover ACEs explicitas nãohereditárias.

• Adicionar/remover ACEs explicitas here-ditárias que se aplicam a esse item e todos os seus filhos.

• Adicionar/remover ACEs explicitas here-ditárias que somente se aplicam a seus filhos.

• Adicionar/remover ACEs explicitas here-ditárias que somente se aplicam a esse item e seus filhosdiretos.

• Adicionar/remover ACEs explicitas here-ditárias que somente se aplicam a contêineres de filhos.

• Adicionar/remover ACEs explicitas here-ditárias que somente se aplicam a objetos de filhos.

• Adicionar/remover ACEs explicitas here-ditárias que somente se aplicam a certos tipos de objetos.

• Mudar o dono do descritor de segurança.

• Mudar o grupo do descritor de segurança.

• Mudar os indicadores de controle do des-critor de segurança.

i. Parar a herança das ACEs.

ii. Parar a herança das ACEs.iii. Mudar outros indicadores de controle so-

mente aplicados nesse item.

Em 620, quando uma ligação de retenção é adiciona-da em um item, o descritor de segurança nesse item pode ounão ser alterado, dependendo de se a ligação de retenção temACEs hereditárias e se o SD nesse item tem o indicadorSE_DACLE_PROTECTED ativado. Entretanto, a tabela [Ta-ble!Security_Hierachy] deve ser atualizada. Quando uma liga-ção de retenção é adicionada em um item, três novas linhaspara o item devem ser adicionadas na tabela [Ta-ble!Security_Hierachy] se o item não tem uma linha designadaainda. Para' reduzir a atualização na tabela [Table!Item], osseguintes formatos podem ser usados para criar essas linhas:(SDO, SD1, *, 0, 0), (SD1, SDO, *, 0, 1), (SD1, SD0, *, 1,1) onde SDO é o SDId antigo do item alvo da ligação de re-tenção, SD1 é o novo SDId do item alvo. Por esse esquema,deve somente precisar atualizar o item fonte na tabela [Ta-ble !Item].

Com base nesse esquema, se uma ACE explicita nãohereditária é adicionada sobre esse item posteriormente, nãoexecutar uma atualização na tabela [Table!Item]. Em 630, po-de ser assumido que o SDId do descritor de segurança na li-gação de retenção a ser removido é o SDId_HD. No caso de re-moção da ligação de retenção, as regiões do SD podem colap-sar e assim linhas em [Table!Security_Hierachy] podem serintercaladas.

A Figura 7 ilustra um processo de região de segu-rança exemplar 700 para a segurança do objeto da base de da-dos de acordo com um aspecto da invenção exposta. Embora,para finalidades de simplicidade de explicação, a metodolo-gia seja mostrada e descrita como uma série ou número de a-ções, é para ser entendido e verificado que a invenção ex-posta não é limitada pela ordem das ações, como algumas a-ções podem, de acordo com a invenção exposta, ocorrer em or-dens diferentes e/ou simultaneamente com outras ações dessasmostradas e descritas aqui. Por exemplo, aqueles versados natécnica entenderão e verificarão que uma metodologia poderiaser alternativamente representada como uma série de estadosou eventos relacionados, tal como em um diagrama de estado.Além do mais, nem todas as ações ilustradas podem ser neces-sárias para implementar uma metodologia de acordo com a in-venção exposta.

Prosseguindo para 710 da figura 7, os descritoresde segurança para objetos respectivos em bancos de dados sãoseparados ou dissociados de uma hierarquia de obj eto clássi-ca removendo a exigência para cada obj eto a ser atualizado(segurança sábia) em vista de qualquer atualização potencialna hierarquia. Em 720, um ou mais descritores de segurançasão utilizados para definir regiões de objeto para objetosque residem na base de dados. Como mencionado acima, issopode incluir colapsar ou intercalar os dados de segurança doobjeto de árvores de objetos similares ou dissimilares demodo a definir regiões de segurança ou subconjuntos de obje-to que subscrevem para dados de segurança similares da regi-ão. Também, tais dados de região podem ser definidos em umalinha da base de dados incluindo relações resultantes paraoutros objetos que pertencem à região. Em 730, estratégiasde segurança do objeto são estabelecidas por regiões sele-cionadas na base de dados. Como mencionado acima, dependendodo tipo de entrada de controle de acesso (implíci-ta/explicita) e a localização de uma mudança da segurança emuma hierarquia do objeto, várias regiões de segurança podemser criadas a partir de tais colocações. Em 740, as trans-formações ocorrem entre domínios de objetos clássicos e osdomínios de segurança da invenção exposta a fim de propagaras mudanças de segurança dentro da base de dados. Isso podeincluir criar subconjuntos de região ao redor de um dado ob-jeto no momento em que uma mudança de segurança é solicitadapara o objeto (por exemplo, criar três ou cinco regiões de-pendendo do tipo de mudança de segurança).

Com referência à figura 8, um ambiente exemplar810 para implementar vários aspectos da invenção inclui umcomputador 812. O computador 812 inclui uma unidade de pro-cessamento 814, uma memória do sistema 816 e um barramentodo sistema 818. 0 barramento do sistema 818 acopla componen-tes do sistema incluindo, mas não limitado a, a memória dosistema 816 na unidade de processamento 814. A unidade deprocessamento 814 pode ser qualquer um de vários processado-res disponíveis. Microprocessadores duplos e outras arquite-turas de multiprocessador também podem ser utilizados como aunidade de processamento 814.

0 barramento do sistema 818 pode ser qualquer umde vários tipos de estrutura(s) de barramento incluindo obarramento de memória ou o controlador de memória, um barra-mento periférico ou barramento externo e/ou um barramentolocal usando qualquer variedade de arquiteturas de barramen-to disponíveis incluindo, mas não limitado a, barramento de11 bits, arquitetura de padrão industrial (ISA), arquiteturade micro-canal (MSA), ISA estendida (EISA), eletrônica deacionamento inteligente (IDE), barramento local VESA (VLB),interligação de componente periférico (PCI), barramento se-rial universal (USB), porta gráfica avançada (AGP), barra-mento da associação internacional de placa de memória decomputador pessoal (PCMCIA) e interface dos sistemas de com-putadores pequenos (SCSI).

A memória do sistema 816 inclui memória volátil820 e memória não volátil 822. O sistema básico de entra-da/ saida (BIOS), contendo as rotinas básicas para transferirinformação entre os elementos dentro do computador 812, talcomo durante a partida, é armazenado na memória não volátil822. Por meio de ilustração, e não limitação, a memória nãovolátil 822 pode incluir memória somente de leitura (ROM),ROM programável (PROM), ROM eletricamente programável(EPROM), ROM eletricamente apagável (EEPROM) ou memória fla-sh. A memória volátil 820 inclui memória de acesso aleatório(RAM), que age como memória de cache externa. Por meio deilustração e não limitação, a RAM está disponível em muitasformas tais como RAM sincrona (SRAM), RAM dinâmica (DRAM),DRAM sincrona (SDRAM), SDRAM de taxa de dados duplos (DDRSDRAM), SDRAM aperfeiçoada (ESDRAM), DRAM Synchlink (SLDRAM)e RAM Rambus direta (DRRAM).

O computador 812 também inclui meios de armazena-mento no computador removíveis/não removíveis, voláteis/nãovoláteis. A figura 8 ilustra, por exemplo, um armazenamentode disco 824. 0 armazenamento de disco 824 inclui, mas não élimitado a, dispositivos como uma unidade de disco magnéti-co, unidade de disco flexível, unidade de fita, unidade Jaz,unidade Zip, unidade LS-100, placa de memória flash ou bas-tão de memória. Além disso, o armazenamento em disco 824 po-de incluir meios de armazenamento separadamente ou em combi-nação com outros meios de armazenamento incluindo, mas nãolimitados a, uma unidade de disco ótico tais como um dispo-sitivo ROM de disco compacto (CD-ROM), unidade gravável deCD (unidade de CD-R), unidade regravável de CD (unidade deCD-RW) ou uma unidade de ROM de disco versátil digital (DVD-ROM) . Para facilitar a conexão dos dispositivos de armazena-mento de disco 824 no barramento do sistema 818, uma inter-face removível ou não removível é tipicamente usada tal comoa interface 82 6.

É para ser verificado que a figura 8 descrevesoftware que age como um intermediário entre usuários e osrecursos de computador básicos descritos no ambiente opera-cional adequado 810. Tal software inclui um sistema opera-cional 828. O sistema operacional 828, que pode ser armaze-nado no armazenamento de disco 824, age para controlar e a-locar os recursos do sistema de computador 812. As aplica-ções do sistema 830 tiram vantagem do gerenciamento dos re-cursos pelo sistema operacional 828 através de módulos doprograma 832 e dados do programa 834 armazenados na memóriado sistema 816 ou no armazenamento de disco 824. É para serverificado que a invenção exposta pode ser implementada comvários sistemas operacionais ou combinações de sistemas operacionais .

Um usuário insere comandos ou informação no compu-tador 812 através do(s) dispositivo(s) de entrada 836. Osdispositivos de entrada 836 incluem, mas não são limitadosa, um dispositivo de indicação tais como um mouse, track-ball, caneta, base sensível ao toque, teclado, microfone,botão de direção, base de jogos, disco de satélite, scanner,placa sintonizadora de TV, câmera digital, câmara de videodigital, câmera de rede e semelhantes. Esses e outros dispo-sitivos de entrada se conectam na unidade de processamento814 através do barramento do sistema 818 via a(s) porta(s)de interface 838. A(s) porta (s) de interface 838 incluem,por exemplo, uma porta serial, uma porta paralela, uma portade jogos e um barramento serial universal (USB). 0(s) dispo-sitivo (s) de saida 840 usam alguns dos mesmos tipos de por-tas como dispositivo(s) de entrada 836. Assim, por exemplo,uma porta USB pode ser usada para prover entrada para o com-putador 812 e fornecer informação do computador 812 para umdispositivo de saida 840. O adaptador de saida 842 é providopara ilustrar que existem alguns dispositivos de saida 84 0como monitores, alto-falantes e impressoras, entre outrosdispositivos de saida 840 que exigem adaptadores especiais.

Os adaptadores de saida 842 incluem, por meio de ilustraçãoe não limitação, placas de video e som que provêem um métodode conexão entre o dispositivo de saida 840 e o barramentodo sistema 818. Deve ser observado que outros dispositivose/ou sistemas de dispositivos provêem ambas as capacidadesde entrada e saida tal como computador(es) remoto(s) 844.

0 computador 812 pode operar em um ambiente de re-de usando conexões lógicas para um ou mais computadores re-motos, tal como o(s) computador(es) remoto(s) 844. 0(s) com-putador (es) remoto(s) 844 pode(m) ser um computador pessoal,um servidor, um roteador, um PC de rede, uma estação de tra-balho, um aparelho com base em microprocessador, um disposi-tivo par ou outro nó de rede comum e semelhantes, e tipica-mente inclui muitos ou todos os elementos descritos relati-vos ao computador 812. Com finalidades de brevidade, somenteum dispositivo de armazenamento de memória 846 é ilustradocom o (s) computador(es) remoto(s) 844 . 0(s) computador(es)remoto (s) 844 é/são logicamente conectado(s) no computador812 através de uma interface de rede 84 8 e a seguir fisica-mente conectados via a conexão de comunicação 850. A inter-face de rede 848 abrange redes de comunicação tais como re-des locais (LAN) e redes remotas (WAN). Tecnologias de LANincluem interface de dados distribuídos por fibra (FDDI) ,interface de dados distribuídos por cobre (CDDI), Ether-net/IEEE 802-3, Token Ring/IEEE 802.5 e semelhantes. Tecno-logias de WAN incluem, mas não são limitadas a, ligações deponto a ponto, redes de comutação de circuito como redes di-gitais de serviços integrados (ISDN) e variações nelas, re-des de comutação de pacote e linhas de assinante digital (DSL).

A(s) conexão(ões) de comunicação 850 se refere(m)ao hardware/software utilizado para conectar a interface derede 84 8 no barramento 818. Embora a conexão de comunicação850 seja mostrada por clareza ilustrativa dentro do computa-dor 818, ela pode também ser externa ao computador 812. Ohardware/software necessário para conexão na interface derede 848 inclui, para finalidades exemplares somente, tecno-logias interna e externa tais como modems incluindo modemsde qualidade de telefone regular, modems a cabo e modems deDSL, adaptadores ISDN e placas de Ethernet.

A Figura 9 é um diagrama de blocos esquemático deum ambiente de computação exemplar 900 com o qual a invençãoexposta pode interagir. O sistema 900 inclui um ou mais cli-entes 910. 0(s) cliente (s) 910 pode (m) ser hardware e/ousoftware (por exemplo, encadeamentos, processos, dispositi-vos de computação). O sistema 900 também inclui um ou maisservidores 930. 0(s) servidor(es) 930 podem também ser hard-ware e/ou software (por exemplo, encadeamentos, processos,dispositivos de computação). Os servidores 930 podem alojarencadeamentos para executar transformações utilizando a in-venção exposta, por exemplo. Uma comunicação possível entreum cliente 910 e um servidor 930 pode ser na forma de um pa-cote de dados adaptado para ser transmitido entre dois oumais processos de computador. O sistema 900 inclui uma es-trutura de comunicação 950 que pode ser utilizada para faci-litar as comunicações entre o(s) cliente(s) 910 e o(s) ser-vidor (es) 930. O(s) cliente(s) 910 são conectados operativa-mente em um ou mais armazenamentos de dados do cliente 960que podem ser utilizados para armazenar informação localao (s) cliente (s) 910. Similarmente, o (s) servidor(es) 930são operativãmente conectados em um ou mais armazenamentosde dados do servidor 940 que podem ser utilizados para armazenar informação local aos servidores 930.

O que foi descrito acima inclui exemplos da inven-ção exposta. Naturalmente, não é possivel descrever cadacombinação concebivel de componentes ou metodologias com afinalidade de descrição da invenção exposta, mas alguém ver-sado na técnica pode reconhecer que muitas combinações epermutas adicionais da invenção exposta são possíveis. Dessamaneira, a invenção exposta é planejada para abranger todastais alterações, modificações e variações que se situam den-tro do espirito e do escopo das reivindicações anexas. Alémdo mais, até a extensão que o termo "inclui" é usado na des-crição detalhada ou nas reivindicações, tal termo é planeja-do para ser inclusivo em uma maneira similar ao termo "com-preendendo" como "compreendendo" é interpretado quando uti-lizado como uma palavra de transição em uma reivindicação.

Claims

1. Sistema que facilita a segurança e o gerencia-mento da base de dados, CARACTERIZADO pelo fato de que com-preende :um componente de base de dados que armazena umapluralidade de objetos tendo uma relação hierárquica entreos objetos eum componente de região que define uma ou mais zo-nas de segurança para um subconj unto dos obj etos e mapeia osdados de segurança para o subconjunto, as zonas de segurançasão independentes das relações hierárquicas entre os objetos.

2. Sistema, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o componente de região proveuma transformação de um dominio de objeto para um dominio desegurança.

3. Sistema, de acordo com a reivindicação 2,CARACTERIZADO pelo fato de que o componente de região incluipelo menos um descritor de segurança que define pelo menosuma das zonas de segurança.

4. Sistema, de acordo com a reivindicação 2,CARACTERIZADO pelo fato de que o componente de região supor-ta a segurança de herança entre as regiões no dominio de se-gurança .

5. Sistema, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o componente de região supor-ta uma expansão das zonas de segurança ou um colapso das zo-nas de segurança com base em uma análise das mudanças de se-gurança .

6. Sistema, de acordo com a reivindicação 5,CARACTERIZADO pelo fato de que o componente de região expan-de as regiões de segurança por pelo menos três regiões combase nas mudanças de segurança detectadas.

7. Sistema, de acordo com a reivindicação 6,CARACTERIZADO pelo fato de que as mudanças de segurança sãodetectadas por uma entrada de controle de acesso (ACE).

8. Sistema, de acordo com a reivindicação 7,CARACTERIZADO pelo fato de que a entrada de controle de a-cesso representa uma mudança de segurança explicita ou im-plícita.

9. Sistema, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que também compreende uma tabelaque associa um item de obj et o com um identificador do des-critor de segurança.

10. Sistema, de acordo com a reivindicação 9,CARACTERIZADO pelo fato de que também compreende uma tabelaque mapeia o identificador do descritor de segurança para osconteúdos de um descritor de segurança.

11. Sistema, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que também compreende pelo menosum de um nó de raiz, um filho, nó, um item de contêiner e umitem sem contêiner.

12. Sistema, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que também compreende um compo-nente para propagar as mudanças de segurança entre as zonasde segurança.

13. Sistema, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que também compreende pelo menosuma interface para interagir com o componente de região ou abase de dados.

14. Sistema, de acordo com a reivindicação 13,CARACTERIZADO pelo fato de que a interface inclui uma funçãode obter segurança, uma função de obter descritor, uma fun-ção de estabelecer segurança, uma função de adicionar liga-ção de retenção, uma função de remover ligação de retenção euma função de obter segurança efetiva.

15. Sistema, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que também compreende uma linhade hierarquia de segurança para definir relações do objetode segurança em um dominio de segurança.

16. Meio legivel por computador, CARACTERIZADO pe-lo fato de que tem instruções legíveis por computador arma-zenadas nele para implementar os componentes da reivindica-ção 1.

17. Método para segurança da base de dados de ob-jetos, CARACTERIZADO pelo fato de que compreende:definir objetos da base de dados em um dominio deobjetos,definir componentes de segurança em um dominio desegurança,prover um mapeamento entre o dominio de obj etos eo dominio de segurança eutilizar o mapeamento para definir as regiões desegurança para os objetos da base de dados.

18. Método, de acordo com a reivindicação 17,CARACTERIZADO pelo fato de que também compreende gerar pelomenos três regiões de segurança com a detecção das mudançasno dominio de segurança.

19. Método, de acordo com a reivindicação 17,CARACTERIZADO pelo fato de que também compreende prover ummecanismo de herança para os componentes de segurança dentrodo dominio de segurança.

20. Sistema para facilitar a segurança do obj etoda base de dados, CARACTERIZADO pelo fato de que compreende:dispositivo para armazenar objetos da base de da-dos,dispositivo para estabelecer regiões de segurançapara os objetos,dispositivo para mapear as regiões de segurançapara os objetos edispositivo para acessar os obj et os com base pelomenos em parte nas regiões de segurança-