SK, TR), OAPI (BF, BJ, CF, CG, CI, CM, GA, GN, GQ, For two-letter codes and other abbre\>iations, referto the "Guid- GW, ML, MR, NE, SN, TD, TG). ance Notes on Codes and Abbreviations" appearing at the begin- ning ofea h regular issue of the PCT Gazette. Published: — with intemational search report
SISTEMA Y METODOS QUE PROPORCIONAN MODELO DE SEGURIDAD MEJORADO REFERENCIA CRUZADA Esta solicitud reivindica la prioridad a la Solicitud de Patente de E. U. No. de Serie 10/691,999 titulada SISTEMA Y METODOS QUE PROPORCIONAN MODELO SE SEGURIDAD MEJORADO presentada el 23 de octubre de 2003, cuya totalidad se incorpora en la presente por referencia. CAMPO TECNICO La presente invención se refiere generalmente a sistemas de computación y, más particularmente, a un sistema y método que emplea un modelo de seguridad mejorado de acuerdo con datos dispuestos de manera jerárquica. ANTECEDENTES DE LA INVENCION Los sistemas operativos modernos impulsan muchas de las innovaciones con base en ia tecnología actual mediante el ofrecimiento de una plataforma para el desarrollo tanto de hardware como de software a la vez que sirven para muchas necesidades diversas. Esto sistemas han evolucionado a partir de sistemas de administración de archivos más simples hasta estaciones de trabajo más complejas que proporcionan un desempeño muy alto a un costo razonable. Tales sistemas incluyen con frecuencia arquitecturas de procesamiento múltiple, memoria de alta velocidad, dispositivos periféricos avanzados, una variedad de bibliotecas y componentes de sistema para auxiliar el desarrollo de software, y arquitecturas de 2
barra colectora intrincada/intercalada, por ejemplo. En el corazón de estos sistemas se incluyen sistemas operativos sofisticados que manejan o administran no solamente el hardware relacionado con la computadora, sino un vasto arreglo de componentes de software que tienen varias relaciones. Estos componentes se describen con frecuencia en términos de objetos o clases que tienen relaciones de escalones múltiples tales como en un arreglo de árbol jerárquico para archivos y directorios que se encuentran en muchos sistemas de administración de datos. Las tecnologías emergentes han generado otras estructuras y modelos tipo para almacenar y administrar objetos dentro de una base de datos. Estas incluyen tales estructuras jerárquicas como jerarquías de contención que permiten relaciones múltiples entre artículos u objetos respectivos. Tales jerarquías están modeladas con frecuencia como una Gráfica Acíclica Dirigida (DAG) y relaciones de trayectoria múltiple de soporte para un artículo de un nodo de raíz de la jerarquía de contención. Independientemente del tipo de estructura de datos involucrado, sin embargo, se han aplicado modelos de seguridad a estos sistemas para determinar y facilitar como se permite el acceso de las entidades (por ejemplo, usuarios u otros componentes) a objetos o artículos que residen en las estructuras respectivas. En muchos aspectos, los modelos de seguridad actuales limitan la efectividad de los sistemas operativos para manejar datos de manera tanto segura como eficiente. Por ejemplo, un modelo de seguridad implementa la seguridad mediante la asociación de una 3
Lista de Control de Acceso (ACL) con cada archivo o directorio en una jerarquía. En un modelo de sucesión o herencia que proporciona soporte para especificar una ACL por omisión para artículos recientemente creados en un directorio, pero subsiguientemente si se cambia la ACL en un directorio, los archivos y carpetas contenidos en la jerarquía bajo ese directorio no son actualizados automáticamente. También, las ACLs especificadas en cualquier directorio pueden ser propagadas usando, por ejemplo, APIs de mayor nivel. En consecuencia, cada artículo puede anular la política de seguridad por encima de ese y especificar una ACL en su nivel que bloquee explícitamente la herencia posterior desde arriba, o simplemente re-herede cuando una ACL recientemente creada se propague por la jerarquía. Desafortunadamente, en un nivel de volumen, puesto que no hay un solo lugar donde se rastreen (generalmente son rastreadas por artículo) estas diferentes políticas de seguridad, es excesivamente difícil, sino es que imposible, determinar una política de seguridad resultante en ese nivel. Como se mencionó antes, si se especifica una nueva ACL en un directorio, se puede propagar por la jerarquía, pero esto implica usualmente correr operaciones en cada archivo y directorio en esa jerarquía. Para volúmenes significativamente grandes, esto puede tomar una cantidad exorbitante de tiempo. Se nota que aún las ACLs de una sola instancia no alivian este asunto puesto que la instancia única ocurre independientemente de las trayectorias de contención. Así, si dos jerarquías tienen la misma ACL en sus artículos 4
contenidos, y si la política de una de ellas cambió, sería incorrecto actualizar simplemente la tabla de instancia única puesto que cambiaría la política en la otra jerarquía también. Otros problemas con los modelos de seguridad actuales involucran la presencia de vínculos duros entre artículos que presentan problemas de semántica cuando se consideran en conjunto con la herencia de ACL. Por ejemplo, cuando se crea un Artículo bajo una Carpetal, recibe una ACL1 por omisión de la Carpeta"!. La creación de un vínculo subsiguiente para el Artículo de una Carpeta2 no cambia la seguridad. Sin embargo, si se aplica una nueva ACL3 en la Carpeta2 a su jerarquía, cambia la ACL en el Artículo también. Subsiguientemente, si se aplica una nueva ACL en la Carpetal, entonces la hereda al Artículo. En consecuencia, quien o cualquiera que escriba al final superpone las ACLs heredadas existentes. Este tipo de arreglo de seguridad es por lo menos confuso y muy frecuentemente impredecible lo cual es altamente indeseable. BREVE DESCRIPCION DE LA INVENCION A continuación se presenta un resumen simplificado de la invención con el fin de proporcionar un entendimiento básico de algunos aspectos de la invención. Este resumen no es una vista general extensa de la invención. No pretende identificar elementos clave/críticos de la invención para delinear el alcance de la invención. Su único propósito es presentar algunos conceptos de la invención en una forma simplificada como una introducción a la descripción más detallada que se presenta posteriormente.
5
La presente invención se refiere a sistemas y métodos que proporcionan un modelo de seguridad predecible y globalizado para datos arreglados de manera jerárquica. Tales jerarquías pueden incluir substancialmente cualquier tipo de artículos arreglados jerárquicamente tales como estructuras de árbol comunes o estructuras de datos más elaboradas tales como una Gráfica Acíclica Dirigida (DAG), por ejemplo. En un aspecto, se proporciona un componente de seguridad que permite que se apliquen políticas de seguridad en una manera más global tal como desde una i más regiones de seguridad que están mapeadas en una base de datos. Estas políticas pueden incluir políticas definidas explícitamente y/o políticas más generalizadas que puede ser heredadas desde varias porciones de una trayectoria o región asociada con el tipo de estructura de datos involucrada (por ejemplo, políticas de seguridad aplicadas de una manera para una estructura de árbol y de una manera subsiguiente para una jerarquía de contención). Puesto que se aplican políticas de seguridad respectivas a un nivel regional o global de una base de datos en oposición a la aplicación de un archivo de seguridad separado por artículo de dato en una estructura jerárquica, la presente invención incrementa significativamente el desempeño de la base de datos. Los incrementos en el desempeño se logran mitigando las operaciones de computación asociadas con los modelos de seguridad del sistema convencional que crean/administran una pluralidad de archivos de seguridad aislados que también continúan creciendo en cantidad a medida que se agregan artículos de 6
datos a la base de datos. En otro aspecto de la presente invención, se proporcionan varios componentes y procesos para permitir que las políticas de seguridad se asocien automáticamente con artículos de la base de datos. Estos componentes definen un modelo de seguridad que hace mapa de una política de seguridad para un artículo respectivo dependiendo del tipo de estructura de datos empleado. Por ejemplo, en un tipo de base de datos, una jerarquía de contención puede incluir varias relaciones de sujeción o contención entre artículos que aparecen en la jerarquía. La relación de sujeción o contención puede emplearse para propagar una política de seguridad para un artículo respectivo, en donde la política puede incluir tanto una porción explícita (por ejemplo, definida por un administrador del sistema) como una porción heredada recibida de los componentes padres y/u otros componentes asociados con el artículo. Así, se puede modelar una regla que permite que un artículo herede una política de seguridad a lo largo de las ramas de una trayectoria a partir de una raíz de la jerarquía con el artículo respectivo de acuerdo con la estructura jerárquica. También, si se encuentra un arreglo de árbol más tradicional, tal como en el caso de si hay una trayectoria entre un nodo de raíz de un árbol con el artículo de dato respectivo, entonces se puede aplicar la elaboración de mapa alternativa de políticas de seguridad. Proporcionando varios enfoques para políticas de seguridad de elaboración de mapa que dependen del tipo de jerarquía encontrado, la presente invención proporciona un modelo de seguridad robusto que facilita el desempeño del sistema y promueve la 7
estabilidad mediante la mitigación de la incertidumbre asociada con las técnicas convencionales de seguridad. Para la realización de lo precedente y las finalidades relacionadas, se describen en la presente ciertos aspectos ilustrativos de la invención en relación con la siguiente descripción y los dibujos adjuntos. Estos aspectos son indicativos de varias maneras en las cuales se puede practicar la invención, todas las cuales se pretende que estén cubiertas por la presente invención. Otras ventajas y aspectos novedosos de la invención se hacen aparentes a partir de la siguiente descripción detallada de la invención cuando se considera en conjunto con los dibujos. BREVE DESCRIPCION DE LOS DIBUJOS La Figura 1 es un diagrama de bloques esquemático de un sistema de seguridad de base de datos y un modelo de acuerdo con un aspecto de la presente invención. La Figura 2 es un diagrama de una lista de control de acceso y componente de órdenes de acuerdo con un aspecto de la presente invención. La Figura 3 es un diagrama que ilustra la distribución de políticas de seguridad de acuerdo con un aspecto de la presente invención. La Figura 4 es un diagrama que ilustra una máscara de acceso de ejemplo de acuerdo con un aspecto de la presente invención. La Figura 5 es un diagrama que ilustra una estructura de datos de ejemplo para regiones de seguridad protegidas de manera similar 8
de acuerdo con un aspecto de la presente invención. La Figura 6 es un diagrama que ilustra la creación de una región de seguridad de acuerdo con un aspecto de la presente invención. La Figura 7 es un diagrama de flujo que ilustra un proceso de seguridad de acuerdo con un aspecto de la presente invención. La Figura 8 es un diagrama de bloques esquemático que ilustra un entorno operativo adecuado de acuerdo con un aspecto de la presente invención. La Figura 9 es un diagrama de bloques esquemático de un entorno de computación de muestra con el cual puede interactuar la presente invención. DESCRIPCION DETALLADA DE LA INVENCION La presente invención se refiere a un sistema y metodología para facilitar la seguridad para artículos de datos que residen dentro (o asociados con) una base de datos o estructura de almacenamiento jerárquica (por ejemplo, ramificación de árbol jerárquico para varios nodos). En un aspecto, se proporciona un sistema de seguridad para base de datos que tiene una estructura de datos jerárquica asociada con uno o más artículos de datos. El sistema incluye un componente de seguridad que se aplica a una política de seguridad para los artículos de datos desde una ubicación o región global asociada con una base de datos. Se emplean varios componentes y procesos para permitir que se reciban propiedades de seguridad explícitas y/o heredadas por y propagadas a los artículos de datos dependiendo del tipo de estructura de datos encontrado o procesado. Asociando las 9
políticas y/o propiedades de seguridad en un nivel global, de volumen o regional de la base de datos - en contraste con el nivel del artículo, las operaciones de procesamiento de la base de datos se mitigan en sistemas convencionales que generalmente vinculan los archivos de seguridad e individuales con artículos de datos respectivos que residen en la base de datos. Como se usan en esta solicitud, los términos "componente", "árbol", "modelo", "sistema" y los similares tienen el propósito de referirse a una entidad relacionada con la computadora, ya sea hardware, una combinación de hardware y software, software o software en ejecución. Por ejemplo, un componente puede ser, pero no está limitado a, un proceso que corre en un procesador, un procesador, un objeto, un ejecutable, una secuencia de ejecución, un programa y/o una computadora. A manera de ilustración, tanto una aplicación que corre en un servidor como el servidor pueden ser un componente. Uno o más componentes pueden residir en un proceso y/o secuencia de ejecución y un componente puede ser localizado en una computadora y/o distribuido entre dos o más computadoras. Haciendo referencia inicialmente a la Figura 1, se ilustra un sistema y modelo 100 de seguridad de base de datos de acuerdo con un aspecto de la presente invención. El sistema 100 incluye una base de datos 110 que tiene un componente 120 (o componentes) de seguridad que son administrados desde una ubicación global o regional dentro de la base de datos (también puede ser administrada desde ubicaciones remotas fuera de la base de datos). La base de 10
datos 120 incluye una o más estructuras jerárquicas 130 y 140. Tales jerarquías pueden incluir substancialmente cualquier tipo de datos (¡lustrados como nodos elípticos) arreglados de manera jerárquica tales como estructuras de árbol común en 130 o estructuras de datos más elaboradas tales como una jerarquía 140 de contención que se modela generalmente como una Gráfica Acíclica Dirigida (DAG). Aunque se ilustran el árbol 130 y la jerarquía 140 de contención (aludida como DAG también), se debe apreciar que el modelo de seguridad de la presente invención se puede aplicar substancialmente a cualquier tipo de estructura de datos jerárquica. Como se describirá con mayor detalle más adelante, se emplean varios procesos y componentes para administrar políticas de seguridad del componente 120 de seguridad a las jerarquías 130 y 140 respectivas. En un aspecto de la presente invención, el componente 20 de seguridad permite que se apliquen políticas de seguridad en una manera más global tal como desde una o más regiones 140 de seguridad que se mapean en/desde la base de datos 110. Estos políticas pueden incluir políticas o propiedades definidas explícitamente en 160 y/o políticas o propiedades más generalizadas en 170 que pueden ser heredadas de varias porciones de una trayectoria o región asociada con el tipo de estructura de datos involucrado. Por ejemplo, las políticas de seguridad se pueden aplicar en una manera para la estructura 130 de árbol y en una manera subsiguiente para la DAG 140, si se desea. Como se indicó antes, se proporcionan varios componentes y 11
procesos para permitir que las políticas de seguridad se asocien automáticamente con artículos de la base de datos. Estos componentes definen un modelo de seguridad que da un mapa a una política de seguridad desde el componente 120 de seguridad a un artículo respectivo en las jerarquías 130 y 140 dependiendo del tipo de estructuras de datos empleado. Por ejemplo, en un tipo de estructura, una jerarquía de contención puede incluir varias relaciones de sujeción o conservación entre artículos que aparecen en la jerarquía. La relación de sujeción o conservación puede ser empleada para propagar una política de seguridad para un artículo respectivo, en donde la política puede incluir una porción 160 explícita (por ejemplo, definida por un administrador del sistema) y/o una porción 170 heredada recibida del padre y/u otros componentes asociados con el artículo. Así, se pueden proporcionar reglas para permitir que un artículo herede una política de seguridad a lo largo de las ramas de una trayectoria de una raíz de la jerarquía para el artículo respectivo de acuerdo con la estructura jerárquica. También, si se encuentra un arreglo de árbol más tradicional, tal como en el caso de si hay una trayectoria entre un nodo de raíz y un árbol para el dato respectivo, entonces se puede aplicar la elaboración de mapa alternativa de políticas de segundad. Se hace notar que la base de datos 110 y/o las jerarquías 130/140 pueden ser modeladas como un almacén de artículos (por ejemplo, región de memoria en la base de datos). La granularidad en la que se puede especificar y reforzar una política de seguridad está 12
generalmente en el nivel de varias operaciones en un artículo en un almacén dado. En general, el componente 120 ( o modelo) de seguridad específica un conjunto de principales a los que se puede otorgar o negar el acceso para realizar estas operaciones en un artículo a través, por ejemplo, de Listas de Control de Acceso (ACLs). Las ACLs respectivas son típicamente una colección ordenada de Entradas de Control de Acceso (ACEs) las cuales se describen con mayor detalle más adelante. La política de seguridad de un artículo puede ser descrita mediante política de control de acceso discrecional y la política de control de acceso del sistema, por ejemplo, en donde estos políticas pueden ser modeladas como un conjunto de ACL's. Un primer conjunto (ACL - DACL's discrecionales) describe el acceso discrecional otorgado a varios principaíes por un propietario del artículo mientras que un segundo conjunto de ACL's es aludido como SACL's (Listas de Control de Acceso al Sistema) el cual especifica como se logra la auditoría del sistema cuando un objeto es manipulado. Además de estas listas, los artículos en un almacén de artículos están asociados generalmente con un ¡dentificador de seguridad (SID) que corresponde al propietario del artículo (SID del propietario). Otro aspecto para organizar artículos en un almacén de artículos es aquel de la jerarquía de contención tal como se ilustra en 140. Generalmente, la jerarquía de contención se realiza vía las relaciones de sujeción o conservación entre artículos. Por ejemplo, la relación de 13
sujeción o conservación entre dos artículos A y B expresada como "A contiene a B" permite que el artículo A influencie el tiempo de vida del artículo B. Típicamente, un artículo en un almacén de artículos no puede existir hasta que hay una relación de sujeción de otro artículo para ese. Una excepción para esta regla es la raíz de la jerarquía de contención. Como se indicó antes, la relación de sujeción, además de controlar el tiempo de vida del artículo, proporciona un componente para propagar la política de seguridad para un artículo. La política de seguridad especificada para artículos respectivos incluye generalmente dos (o más) porciones - una porción que se especifica explícitamente para ese artículo y una porción que se hereda del padre del artículo en el almacén de artículos. La política de seguridad definida explícitamente para un artículo puede incluir también dos (o más) porciones - una porción que gobierna el acceso al artículo bajo consideración y una porción que influencia la política de seguridad heredada por sus descendientes en la jerarquía de contención u otra estructura jerárquica. La política de seguridad heredada por un descendiente es generalmente función de la política definida explícitamente y la política heredada. Haciendo referencia ahora a la Figura 2, se ilustra en una lista
200 de control de acceso y un componente 210 de ordenación de acuerdo con un aspecto de la presente invención. Como se indicó antes, las políticas de seguridad son propagadas generalmente a través de relaciones de sujeción en una jerarquía de contención. Puesto que la política de seguridad es propagada a través de 14
relaciones de sujeción y pueden ser anuladas también en un artículo, lo siguiente describe cómo se determina la política de seguridad efectiva para un artículo. Por ejemplo, un artículo en una jerarquía de contención hereda una ACL junto con las trayectorias de la raíz del almacén de artículos para el artículo. Dentro de la ACL heredada de una trayectoria dada, el ordenamiento de las varias Entradas de Control de Acceso (ACE's) en la ACL 200 determina generalmente la política de seguridad final que se refuerza. La siguiente notación describe el ordenamiento de ACE's en una ACL vía el componente 210 de ordenamiento. El ordenamiento de las ACE's en una ACL que se hereda por un artículo puede ser determinado mediante las siguientes reglas: Regla 1 Para ACL's (L) heredadas en el artículo (I) Para artículos 11, 12 Para A1 y A2 de ACE's en L, 11 es un ancestro de (2 e 12 es un ancestro de 13 y A1 es una ACE heredada de 11 y A2 es una ACE heredada de 12 Implica A2 precede a A1 en L La regla anterior estratifica las ACE's heredadas de los varios artículos en una trayectoria al artículo I desde la raíz de la jerarquía de contención. Las ACE's heredadas de un contenedor más cercano 15
tiene prioridad sobre las entradas heredadas de un contenedor distante. De manera intuitiva, esto permite la habilidad de un administrador para anular las ACE's heredadas desde más lejos en la jerarquía de contención. La siguiente regla ordena a las ACE's que niegan el acceso a un artículo adelante de las ACE's que otorgan el acceso a un artículo. Regla 2 Para ACL's (L) heredadas en el artículo (I) Para artículos 11 Para A1 y A2 de ACE's en L, 11 es un ancestro de 12 y A1 es una ACCESO_ NEGADO_ACE heredada de 11 y A2 es una ACCESO_ OTORGADO _ACE heredada de 11
Implica A1 precede a A2 en L Volviendo ahora a la Figura 3, un sistema 300 ¡lustra la distribución de política de seguridad de acuerdo con un aspecto de la presente invención. El sistema 300 despliega una o más políticas 310 de seguridad para una estructura 320 de árbol y/o una DAG 330. En el caso de una jerarquía de contención que es un árbol 320 hay una trayectoria desde la raíz del árbol hasta el artículo y el artículo tiene así una ACL heredada en 340. Bajo estas circunstancias, la ACL heredada por un artículo iguala la ACL heredada por un archivo (artículo) en modelos de seguridad existentes en términos de ordenamiento relativo de las ACE's dentro de ellas. Sin embargo, 16
cuando la jerarquía de contención es una Gráfica Acíclica Dirigida (DAG) 330, se permite a ios artículos relaciones de sujeción múltiples. Bajo estas condiciones hay trayectorias múltiples para un artículo desde la raíz de la jerarquía de contención. Puesto que un artículo hereda una ACL junto con las trayectorias con las que están asociados los artículos, se emplea en 351 colección de ACL's en oposición a una sola. Se nota que el modelo antes descrito es diferente del modelo de sistema de archivo donde exactamente una ACL está asociada con un archivo o carpeta; Así, para las interfases de legado, el sistema 300 puede regresar una ACL asociada con la trayectoria particular sobre la cual fue accedido el artículo. Sin embargo, para modelos de almacén de artículos, se puede regresar un conjunto de ACL's asociadas con el artículo. Típicamente hay dos aspectos que tienen que ser elaborados cuando la jerarquía de contención es una DAG 330 en oposición a un árbol 320. En un aspecto, el modelo proporciona una descripción de cómo la política de seguridad efectiva para un artículo es calculada cuando hereda más de una ACL de sus padres y cómo los artículos que están organizados y representados afectan la administración del modelo de seguridad para un almacén de artículos. El siguiente algoritmo evalúa los derechos de acceso para un principal dado a un artículo dado. Antes de proceder con el algoritmo, la siguiente notación describe las ACL's asociadas con un artículo. Heredada_ACL's(Art¡culold) - un conjunto de ACL's heredadas 17
por un artículo cuya identidad de artículo es un Articulold de sus padres en el almacén. Explicita_ACL(ArticuloId) - una ACL definida explícitamente para el artículo cuya identidad es Articulold. ESTATUS
ACLAccesoCheck( PSID pPropietarioSid, PDACL pDael, DWORD AccesoDeseado, HANDLE FichaCliente, PPRIVILEGIO_CON JUNTO pPrivilegioConjunto, DWORD *pAccesoOtorgado) La rutina anterior regresa a ESTATUS_ÉXITO si el acceso deseado no fue negado explícitamente y pAccesoOtorgado determina cuál de los derechos deseados por el usuario fueron otorgados por la ACL especificada. Si el acceso deseado fue negado explícitamente la rutina regresa a ESTATUS_ ACCESO_ NEGADO. ESTATUS Articulo AccesoCheck( OS_ARTlCULOlD Articulold, DWOIRD AccesoDeseado HANDLE FichaCliente, PPRIVlLEGIO_CO JUNTO pPrivilegioConjunto) { ESTATUS Estatus;
18
PDACL pACLExplicita=NULO; PDACL pACLsHeredadas = NULO DWORD NúmerodeACLsHeredadas=0; p ACLExplí cita = ObtenerACL Explícita Para Articulo (Articulo Id) ; ObtenerAC Ls H ered adasPa ra Articulo (Articulo Id, &pACLs He redada s,& umeroDeACLsHeredadas) Estatus=CheckAccesoACL( pPropietarioSid pACLExplicita, AccesoDeseado, FichaCíiente, pPrivilegioConjunto, &AccesoOtorgado); si (Estatus ! = ESTATUS_EXITO) regresar a Estatus; si (AccesoDeseado=AccesoOtorgado) regresar a ESTATUS_EXíTO; para( i=0; (i < N um e ro DeAC Ls He redad as &&Estatus= = ESTATUS_ EXITO); { AccesoOtorgadoParaACL=0; Estatus=CheckAccesoACL( pPropietarioSid, pACLExplicita, 19
AccesoDeseado, FichaCliente, pPrivilegioConjunto, &AccesoOtorgadoParaACL); si (Estatus = = ESTATUS_EXITO { AccesoOtorgado |=AccesoOtorgadoParaACL; } } Si ((Estatus==ESTATUS_EXITO)&& AccesoOtorgado 1 =AccesoDeseado)) { Estatus = ESTATUS_ACCESO_ NEGADO; } regresar a Estatus; } Se nota que la esfera de influencia de la política de seguridad definida en un artículo cubre los descendientes del artículo en la jerarquía de contención definida en el almacén de artículos. Para artículos donde se define una política explícita, entonces el efecto es similar a definir una política que se hereda por sus descendientes en la jerarquía de contención. Las ACL's heredadas por los descendientes pueden ser obtenidas tomando las ACL's heredadas por el artículo y agregando las ACE's heredables en la ACL explícita al comienzo de la ACL (a menos que se fije una bandera que especifica que las ACE's no se van a heredar). Esto se alude como el conjunto de ACL's heredables asociadas con el artículo.
20
En la ausencia de especificación explícita de seguridad en la jerarquía de contención con raíces en un artículo de carpeta, la especificación de seguridad de la carpeta se aplica generalmente a todos los descendientes de ese artículo en la jerarquía de contención. Así, cada artículo para el cual se proporciona una especificación de política de seguridad explícita define una región de artículos protegidos de manera similar y las ACL's efectivas para todos los artículos en la región es el conjunto de ACL's heredables para ese artículo. Esto definiría completamente las regiones en el caso de una jerarquía de contención que es un árbol. Si cada región fuera a estar asociada con un número, entonces sería suficiente simplemente incluir fa región a la que pertenece un artículo junto con el artículo. Para jerarquía de contención que son DAG's, los puntos en la jerarquía de contención en los cuales cambia la política de seguridad efectiva se determinan generalmente mediante dos tipos de artículos:
Artículos para los cuales se ha especificado una ACL explícita. Típicamente estos son los puntos en la jerarquía de contención donde un administrador ha especificado explícitamente una ACL; y Artículos que tienen más de un padre y los padres tienen diferentes políticas de seguridad asociadas con ellos. Típicamente estos son los artículos que son los puntos de confluencia de la política de seguridad especificada para un volumen de artículos e indican el comienzo de una nueva política de seguridad. Con la definición anterior, los artículos en el almacén de artículos caen generalmente en una de dos categorías - aquellos que 21
son la raíz de una región de seguridad protegida de manera similar y aquellos que no. Los artículos que no definen regiones de seguridad pertenecen generalmente a una región de seguridad. Como en el caso de los árboles, la seguridad efectiva para un artículo puede ser especificada mediante la especificación de la región a la cual pertenece un artículo. Esto conduce a un modelo sencillo para administrar la seguridad de un almacén de artículos con base en las varias regiones protegidas de manera similar en el almacén. La siguiente discusión que se refiere a las Figuras 4 a 6 está relacionada a descripciones más detalladas de políticas de seguridad y/o implementaciones de seguridad que se pueden emplear de acuerdo con la presente invención. Por ejemplo, aunque se pueden describir elaboraciones de mapas de bits detallados, se debe apreciar que la presente invención no está limitada a las implementaciones particulares así descritas (por ejemplo, otras elaboraciones y/o implementaciones de mapas de bits posibles). En general, un describidor de seguridad incluye información de seguridad asociada con un objeto asegurable. Un describidor de seguridad incluye una estructura S E G U R l DA D_ DESCRIBIDOR y su información de seguridad asociada. El describidor de seguridad puede incluir la siguiente información de seguridad: SID's para el propietario y grupo primario de un objeto. Una DACL que especifique los derechos de acceso permitidos o negados a usuarios o grupos particulares. Una SACL que especifique los tipos de intentos de acceso que 22
generan registros de auditoría para el objeto. Un conjunto de bits de control que califique el significado de un describidor de seguridad o sus miembros individuales. Las aplicaciones no deben manipular directamente los contenidos de un describidor de seguridad. Se pueden proporcionar funciones de Interfase de Programación de Aplicación (API) para fijar y recuperar la información de seguridad en un describidor de seguridad del objeto. Además, hay funciones para crear e iniciar un describidor de seguridad para un nuevo objeto. Una lista de control de acceso discrecional (DACL) identifica fiduciarios o miembros de consejo que se les permite o niega el acceso a un objeto asegurable. Cuando un proceso intenta acceder a un objeto asegurable, el sistema revisa las ACE's en la DACL del objeto para determinar si le concede acceso. Si el objeto no tiene una DACL, el sistema puede otorgar acceso completo. Si la DACL del objeto no tiene ACE's, el sistema niega los intentos para acceder al objeto porque la DACL no permite derechos de acceso. El sistema revisa las ACE's en secuencia hasta que encuentra una o más ACE's que permiten ios derechos de accaso requerido, o hasta que se niegan los derechos de acceso requerido. Una lista de control de acceso del sistema (SACL) permite a los administradores registrar intentos para acceder a un objeto asegurado. La ACE especifica los tipos de intentos de acceso por un fiduciario o miembro del consejo específico que causa que el sistema genere un registro en un registro de evento de seguridad. Una ACE en una SACL 23
puede generar registros de auditoría cuando falla un intento de acceso, cuando tiene éxito, o ambos. También, una SACL puede activar una alarma cuando un usuario no autorizado intenta tener acceso a un objeto. Generalmente, las ACEs contienen la siguiente información de control de acceso: Un ¡dentificador de seguridad (SID) que identifica el fiduciario al cual se aplica la ACE. Una máscara de acceso especifica los derechos de acceso controlados por la ACE. Una bandera indica el tipo de ACE. Un conjunto de banderas de bits que determina si los contenedores u objetos de niño pueden heredar la ACE del objeto primario al cual está unida la ACL. La siguiente Tabla enlista los tipos posibles de ACE soportados por objetos asegurables.
Tipo Descripción
Acceso-negado Usado en una DACL para negar derechos de acceso a un fiduciario.
ACE
ACE Acceso- Usado en una DACL para permitir derechos permitido de acceso a un fiduciario.
ACE Sistema- Usado en una SACL para generar un registro auditoria de auditoría cuando el fiduciario intenta ejercitar los derechos de acceso específicos.
24
En un aspecto, los objetos asegurables pueden arreglar sus derechos de acceso vía el formato de máscara de acceso (otros formatos posibles) ilustrado en una máscara 400 en la Figura 4. En este formato, los 16 bits de orden bajo son para derechos de acceso de objeto específico, los siguientes 7 bits son para derechos de acceso normal, los cuales se aplican para la mayoría de los tipos de objetos y los 4 bits de orden superior se emplean para especificar derechos de acceso genérico que los tipos de objeto pueden mapear en un conjunto de derechos estándar y de objeto específico. Un bit (AS bit) ACCESO_SISTE A_SEGURIDAD corresponde al derecho para acceder a la SACL del objeto. Los derechos genéricos se especifican en los 4 bits de orden superior en la máscara 400. Generalmente, cada tipo de objeto asegurable mapea estos bits para un conjunto de sus derechos de acceso estándar y de objeto específico. Por ejemplo, un tipo de objeto de archivo puede mapear el bit de GENÉRICO_LEER para los derechos de acceso estándar de LEER_CONTROL y SINCRONIZAR y para los derechos de acceso de objeto específico de ARCHlVO_ LEER_DATOS, ARCH IVO_LEER_EA y ARCHIVO_ LEER_ ATRIBUTOS. Otros tipo de objetos mapean el bit GENÉRICO_ LEER (GR) para el conjunto de derechos de acceso adecuados para ese tipo de objeto. Los derechos de acceso genérico pueden ser utilizados para especificar el tipo de acceso deseado cuando se abre una asidera para un objeto, por ejemplo. Esto es típicamente más simple que especificar todos los derechos estándar y específicos 25
correspondientes. La siguiente tabla representa las constantes posibles definidas para derechos de acceso genérico.
Generalmente, cada tipo de objeto asegurable tiene un conjunto de derechos de acceso que corresponden a operaciones específicas para ese tipo de objeto. Además de estos derechos de acceso de objeto específicos, hay un conjunto de derechos de acceso estándar que corresponden a operaciones comunes para la mayoría de los tipos de objetos asegurables. La siguiente tabla representa las constantes posibles definidas para derechos de acceso estándar.
Constante Significado
SUPRIMIR El derecho de suprimir el objeto.
LEER_CONTROL El derecho de leer la información en el describidor de seguridad del objeto, sin incluir la información en la SACL.
26
La Figura 5 ilustra una estructura 500 de datos de ejemplo para regiones de seguridad protegidas de manera similar de acuerdo con un aspecto de la presente invención. Los artículos que definen regiones protegidas de manera similar tienen una entrada asociada con ellos en la tabla de seguridad como se ilustra en 500. La tabla de seguridad se define como sigue: Identidad de Artículo - Esta es la Identidad de Artículo de la raíz de una región de seguridad protegida de manera similar. Ordtrayectoria de Artículo - Esta es la ordtrayectoria asociada con la raíz de la región de seguridad protegida de manera similar. ACL de Artículo Explícita - Esta es la ACL explícita definida por la raíz de la región de seguridad protegida de manera similar. En algunos casos esta puede ser NULA, (por ejemplo, cuando se define una nueva región de seguridad porque el artículo tiene padres múltiples que pertenecen a regiones diferentes). ACLs de Trayectoria - Esta es el conjunto de ACL's heredado por 27
el artículo. ACL's de Región - Esta es el conjunto de ACL's definido por la región de seguridad protegida de manera similar asociada con el artículo. Esto difiere de la columna de ACL's Heredadas cuando la columna explícita tiene un valor no-NULO. El cálculo de la seguridad efectiva para un artículo en un almacén dado influencia a la tabla 500. Con el fin de determinar la política de seguridad asociada con un artículo, se analiza la región de seguridad asociada con el artículo y se recuperan las ACL's asociadas con esa región. Conforme se cambia la política de seguridad asociada con el artículo (por ejemplo, agregando directamente ACL's explícitas o indirectamente agregando vínculos de sujeción que resulta en la formación de nuevas regiones de seguridad) la tabla 500 de seguridad se debe mantener actualizada para facilitar que el algoritmo anterior para determinar la seguridad efectiva de un artículo sea válido. Los algoritmos posibles para mantener la tabla de segundad son como sigue: Crear un nuevo artículo en un contenedor - Cuando se crea recientemente un artículo en un contenedor hereda las ACL's asociadas con el contenedor. Puesto que el artículo creado recientemente tiene un padre, pertenece a la región de segundad como su padre. Así, típicamente no hay necesidad de crear una nueva entrada en la tabla de seguridad. Agregar una ACL explícita a un artículo - Cuando se agrega una ACL a un artículo define una nueva región 28
de seguridad para sus descendientes en la jerarquía de contención que pertenece a la misma región de seguridad que el mismo artículo dado. Para los artículos que pertenecen a otras regiones de seguridad, pero que son descendientes del artículo dado en la jerarquía de contención, la región de seguridad permanece sin cambio, pero la ACL efectiva asociada con la región se cambia para refleajr la adición de la nueva ACL. La introducción de esta nueva región de seguridad puede disparar definiciones de región adicionales para aquellos artículos que tienen múltiples vínculos de sujeción con ancestros que une como puente la vieja región de seguridad y la región de seguridad definida recientemente. Para tales artículos, se puede definir una nueva región de seguridad y se repite el procedimiento. La Figura 6 representa una nueva región de seguridad protegida de manera similar que se crea de una región de seguridad existente mediante la introducción de una nueva ACL. Esto se indica por el nodo marcado con 2 en el número 600 de referencia. Sin embargo, la introducción de esta nueva región resulta en una región 3 adicional que se crea en el número 610 de referencia debido a un artículo que tiene múltiples vínculos de sujeción. La siguiente secuencia de actualizaciones para las tablas de seguridad refleja la hechura de regiones de seguridad protegidas de manera similar. Agregar un vínculo de sujeción a un artículo - Cuando se agrega un vínculo de sujeción a un artículo típicamente da origen a una de tres posibilidades. Si el objetivo del 29
vínculo de sujeción, es decir, el artículo bajo consideración es la raíz de una región de seguridad, la ACL efectiva asociada con la región se cambia y generalmente no se requieren modificaciones adicionales a la tabla de seguridad. Si la región de seguridad de la fuente del nuevo vínculo de sujeción es idéntica a la región de seguridad de los padres existentes del artículo, entonces no se requieren cambios típicamente. Sin embargo, si el artículo ahora tiene padres que pertenecen a diferentes regiones de seguridad, entonces se forma una nueva región de seguridad con el artículo dado como la raíz de la región de seguridad. Este cambio se propaga a los artículos en la jerarquía de contención modificando la región de seguridad asociada con el artículo. Los artículos que pertenecen a la misma región de seguridad que el artículo bajo consideración y que son sus descendientes en la jerarquía de contención deben ser cambiados. Cuando se hace el cambio, los artículos que tienen múltiples vínculos de sujeción deben ser examinados para determinar si se requieren cambios adicionales. Se pueden requerir cambios adicionales si cualquiera de los artículos tiene padres de diferentes regiones de segundad. Suprimir un vínculo de sujeción de un artículo - Cuando se suprime un vínculo de sujeción de un artículo es posible que colapse una región de seguridad con su región padre si se satisfacen ciertas condiciones. De manera más precisa, esto se puede realizar bajo las siguientes condiciones: Si la eliminación del vínculo de sujeción resulta en un artículo que tiene solamente un padre y no se especifica una ACL explícita 30
para ese artículo. Si la eliminación del vínculo de sujeción resulta en un artículo cuyos padres están todos en la misma región de seguridad y no se define una ACL explícita para ese artículo. Bajo estas circunstancias la región de seguridad puede ser marcada para ser la misma que la del padre. Esta marca se debe aplicar a todos los artículos cuya región de seguridad corresponda con la región que se colapsa. Suprimir una ACL explícita de un artículo - Cuando se elimina una ACL explícita de un artículo es posible que colapse la región de seguridad enraizada en ese artículo con aquella de sus padres. De manera más precisa, esto se puede lograr si la eliminación de la ACL explícita resulta en un artículo cuyos padres en la jerarquía de contención pertenecen a la misma región de seguridad. Bajo estas circunstancias la región de seguridad se puede marcar para que sea la misma que el padre y aplicar el cambio a ios artículos cuya región de seguridad corresponda con la región que se colapsa. Modificar una ACL asociada con un artículo - En este caso, generalmente no se requieren nuevas adiciones a la tabla de seguridad. La ACL efectiva asociada con la región se actualiza y se propaga el nuevo cambio de ACL a las regiones de seguridad que son afectadas por éste. La Figura 7 es un diagrama de flujo que ilustra un proceso 700 de seguridad de acuerdo con un aspecto de la presente invención. Aunque, para propósitos de simplicidad de la explicación, la 31
metodología se muestra y se describe como una serie de actos, se debe entender y apreciar que la presente invención no está limitada por el orden de los actos, ya que algunos actos, de acuerdo con la presente invención, pueden ocurrir en órdenes diferentes y/o concurrentemente con otros actos de esos mostrados y descritos en la presente. Por ejemplo, aquellos expertos en la técnica entenderán y apreciarán que una metodología podría ser representada alternativamente como una serie de estados o eventos interrelacionados, tales como en un diagrama de estado. Además, no todos los actos ilustrados pueden ser requeridos para implementar una metodología de acuerdo con la presente invención. Avanzando a 710 de la Figura 7, se definen una o más políticas de seguridad para estructuras jerárquicas. Como se indicó antes, éstas pueden incluir estructuras de árbol común y otras estructuras tales como jerarquías de contención. También, son posibles las estructuras híbridas que tienen algunos aspectos de arreglos de árbol y algunos aspectos relacionados con jerarquías de contención. Las políticas de seguridad se pueden proporcionar en tales dispositivos como Listas de Control de Acceso que tienen una o más Entradas de Control de Acceso que describen la política respectiva en las mismas. En 720, se definen reglas de elaboración de mapas explícitas y/o heredadas para las políticas de seguridad. Tales reglas pueden incluir funciones de anulación en el caso de mapeados explícitos, mientras que otras reglas proporcionan el cómo las políticas serán mapeadas en un arreglo más complejo tal como una jerarquía de contención por 32
lo que son posibles múltiples relaciones de sujeción. En 730, se determinan los ordenamientos para las reglas y políticas respectivas. Por ejemplo, las Entradas de Control de Acceso pueden estar dispuestas en la Lista de Control de Acceso que depende del tipo de estructura y/o relación jerárquica encontradas. En 740, se define una o más regiones de seguridad para una estructura jerárquica dada. En 750, se aplica una o más políticas de seguridad para regiones seleccionadas definidas en 740. Con referencia a la Figura 8, un entorno 810 de ejemplo para implementar varios aspectos de la invención incluye una computadora 812. La computadora 812 incluye una unidad 814 de procesamiento, una memoria 816 de sistema y una barra colectora 818 de sistema. La barra colectora 818 del sistema acopla componentes del sistema que incluyen, pero no limitados a, la memoria 816 de sistema con la unidad 814 de procesamiento. La unidad 814 de procesamiento puede ser cualquiera de varios procesadores disponibles. Se pueden emplear también microprocesadores duales y otras arquitecturas de procesador múltiple como la unidad 814 de procesamiento. La barra colectora 818 del sistema puede ser cualquiera de varios tipos de estructura(s) de barra colectora incluyendo la barra colectora de la memoria o controlador de memoria, una barra colectora periférica o barra colectora externa, y/o una barra colectora local que usa una variedad de arquitecturas de barra colectora disponibles incluyendo, pero no limitadas a, barra colectora de 16 bits, Arquitectura Estándar Industrial (ISA), Arquitectura de Micro Canal 33
(MSA), ISA Extendida (EISA), Electrónica de Impulsión Inteligente (IDE), Barra Colectora Local VESA (VLB), Interconectar Componente Periférico (PCI), Barra Colectora de Serie Universal (USB), Puerto de Gráficas Avanzadas (AGP), barra colectora de la Asociación Internacional de Tarjetas de Memoria para Computadoras Personales (PCMCIA) y Interfase de Sistemas para Computadoras Pequeñas (SCSI). La memoria 816 del sistema incluye una memoria 820 volátil y una memoria 822 no volátil. El sistema básico de entrada/salida (BIOS), que contiene las rutinas básicas para transferir información entre elementos en la computadora 812, tal como durante el arranque, se almacena en la memoria 822 no volátil. A manera de ilustración, y no de limitación, la memoria 822 no volátil puede incluir memoria de solamente lectura (ROM), ROM programable (PROM), ROM que se puede borrar eléctricamente (EEPROM) o memoria instantánea. La memoria 820 volátil incluye una memoria de acceso aleatorio (RAM), la cual actúa como una memoria caché externa. A manera de ilustración y no de limitación, la RAM está disponible en muchas formas tales como RAM sincrónica (SRAM), RAM dinámica (DRAM), DRAM sincrónica (SDRAM), SDRAM de régimen de datos doble (DDR SDRAM), SDRAM aumentada (ESDRAM), DRAM Sincvinc (SLDRAM) y RAM Rambus (DRRAM). La computadora 812 incluye también medios de almacenamiento de computadora removibles/no removibles, volátiles/no volátiles. La Figura 8 ilustra, por ejemplo un almacenaje 824 de disco. El 34
almacenaje 824 de disco incluye, pero no está limitado a, dispositivos como un impulsor de disco magnético, impulsor de disco suave, impulsor de cinta, impulsor Jaz, impulsor Zip, impulsor LS-100, tarjeta de memoria instantánea o barra de memoria. Además, el almacenaje 824 de disco puede incluir medios de almacenaje por separado o en combinación con otros medios de almacenaje que incluyen, pero no están limitados a, un impulsor de disco óptico tal como un dispositivo de ROM de disco compacto (CD-ROM), impulsor re-grabable de CD (CD-R Drive), impulsor que se puede re-escribir (CD-RW Drive) o un impulsor de ROM de disco versátil digital (DVD-ROM). Para facilitar la conexión de los dispositivos 824 de almacenaje de disco a la barra colectora 818 del sistema, se usa típicamente una interfase removible o no removible tal como una interfase 826. Se debe apreciar que la Figura 8 describe software que actúa como un intermediario entre los usuarios y los recursos básicos de la computadora descritos en el entorno 810 de operación. Tal software incluye un sistema 828 de operación. El sistema 828 operativo, el cual se puede almacenar en el almacenaje 824 de disco, actúa para controlar y ubicar recursos del sistema 812 de computadora. Las aplicaciones 830 del sistema aprovechan la administración de recursos operando el sistema 828 a través de los módulos 832 de programa y los datos 834 de programa almacenados ya sea en la memoria 816 del sistema o en el almacenaje 824 de disco. Se debe apreciar que la presente invención se puede implementar con varios sistemas operativos o combinaciones de sistemas operativos.
35
Un usuarios introduce comandos o información a la computadora 812 a través del (de los) dispositivo(s) 836 de alimentación. Los dispositivos 836 de alimentación incluyen, pero no están limitados a, un dispositivo de señalamiento tal como un ratón, una bola de rastreo, una estilográfica, un cojín de toque, un teclado, un micrófono, una barra para juegos, un cojín para juegos, un plato satélite, un escáner, una tarjeta de sintonizador de TV, una cámara digital, una cámara de video digital, una cámara de red y los similares. Estos y otros dispositivos de alimentación se conectan a la unidad 814 de procesamiento a través de la barra colectora 818 del sistema vía el (los) puerto(s) 838 de interfase. El (los) puerto(s) 838 de interfase incluyen, por ejemplo, un puerto serial, un puerto en paralelo, un puerto para juegos y una barra colectora en serie universal (USB). Oíro(s) dispositivo(s) 840 de salida usa(n) algunos de los puertos del mismo tipo que el (los) dispositivo(s) 836. Así, por ejemplo, se puede usar un puerto USB para proporcionar alimentación a la computadora 812 y para sacar información de la computadora 812 para un dispositivo 840 de salida. Se proporciona un adaptador 842 de salida para ilustrar que hay algunos dispositivos 840 de salida como monitores, altavoces e impresoras, entre otros dispositivos 840 de salida, que requieren adaptadores especiales. Los adaptadores 842 de salida incluyen, a manera de ilustración y no de limitación, tarjetas de video y sonido que proporcionan un medio de conexión entre el dispositivo 840 de salida y la barra colectora 818 del sistema. Se debe notar que otros dispositivos y/o sistemas de dispositivos 36
proporcionan capacidades tanto de entrada como de salida tales como la(s) computadora(s) 844 remota(s). La computadora 812 puede operar en un entorno de red usando conexiones lógicas para una o más computadoras remotas, tal como la(s) computadora(s) 844 remota(s). La(s) computadora(s) 844 remota(s) puede ser una computadora personal, un servidor, un enrutador, una PC de red, una estación de trabajo, un aparato doméstico con base en un microprocesador, un dispositivo igual u otro nodo de red común y los similares, e incluye típicamente muchos o todos de los elementos descritos con relación a la computadora 812. Para propósitos de brevedad, solamente se ilustra un dispositivo 846 de almacenaje de memoria con la(s) computadora(s) 844 remota(s). La(s) computadora(s) 844 remota(s) está(n) conectada(s) de manera lógica con la computadora 812 a través de una interfase 848 de red y después conectada físicamente vía la conexión 850 de comunicación. La interfase 848 de red abarca redes de comunicación tales como las redes de área local (LAN) y las redes de área amplia (WAN). Las tecnologías de LAN incluyen Interfase de Información Distribuida de Fibra (FDDl), Interfase de Información Distribuida de Cobre (CDDI), Ethernet/IEEE 1102.3, Anillo Ficha/IEEE 1102.5 y ios similares. Las tecnologías WAN incluyen, pero no están limitadas a, vínculos de punto a punto, redes de conmutación de circuito como Redes Digitales de Servicios Integrados (ISDN) y variaciones en las mismas, redes de conmutación de paquete y Líneas Suscriptoras Digitales (DSL). La(s) conexion(es) 850 se refiere(n) al hardware/software 37
empleado para conectar la interfase 848 de red a la barra colectora 818. Aunque la conexión 850 de comunicación se muestra para claridad ilustrativa dentro de la computadora 812, también puede ser externa a la computadora 812. El hardware/software necesario para conexión a la interfase 848 de red incluye, únicamente para propósitos de ejemplo, tecnologías internas y externas tales como modems que incluyen modems de grado teléfono regular, modems para cable y modems DSL, adaptadores ISDN y tarjetas Ethernet. La Figura 9 es un diagrama de bloques esquemático de un entorno 900 de computación de muestra con el cual puede ¡nteractuar la presente invención. El sistema 900 incluye uno o más clientes 910. Los clientes 910 pueden ser hardware y/o software (por ejemplo secuencias, procesos, dispositivos de computación). El sistema 900 incluye también uno o más servidores 930. Los servidores 930 pueden ser también hardware y/o software (por ejemplo, secuencias, procesos, dispositivos de computación). Los servidores 930 pueden alojar secuencias para realizar transformaciones empleando la presente invención, por ejemplo. Una comunicación posible entre un cliente 910 y un servidor 930 puede ser en la forma de un paquete de datos adaptado para ser transmitido entre dos o más procesos de computadora. El sistema 900 incluye un marco 950 de comunicación que puede ser empleado para facilitar las comunicaciones entre los clientes 910 y los servidores 930. Los clientes 910 están conectados de manera operable con uno o más almacenes 960 de datos de clientes que se pueden emplear para almacenar información local para 38
los clientes 910. De manera similar, los servidores 930 están conectados de manera operable con uno o más almacenes 940 de datos del servidor que se pueden emplear para almacenar información local para los servidores 930. Lo que se ha descrito anteriormente incluye ejemplos de la presente invención. Por supuesto, no es posible describir cada combinación concebible de componentes o metodologías para propósitos de descripción de la presente invención, pero alguien de pericia ordinaria en la técnica puede reconocer que son posibles muchas combinaciones y permutaciones adicionales de la presente invención. En consecuencia, la presente invención pretende abarcar todas esas alteraciones, modificaciones y variaciones que caen dentro del espíritu y el alcance de las reivindicaciones adjuntas, además, hasta el grado en que el término "incluye" se use en ya sea la descripción detallada o las reivindicaciones, tal término pretende ser incluyente en una manera similar al término "que comprende" ya que "que comprende" se interpreta cuando se emplea como una palabra transicional en una reivindicación.