AUTORIZACIÓN DE ACCESO INTEGRADO
Campo del Invento La tecnología descrita se dirige a la seguridad de las computadoras y más particularmente, a controlar el acceso a recursos que se encuentran en un sistema de computadora. Antecedentes del Invento Conforme incrementa la dependencia en las computadoras y redes de cómputo junto con la sofisticación y la frecuencia de ataques a las computadoras y redes de cómputo, el asunto de la seguridad de las computadoras se vuelve cada vez más prominente en la industria. Las técnicas de seguridad de las computadoras actuales, son inadecuadas en cuanto a proteger a los programas de aplicación y sistemas de operación de softwares maliciosos y ("malware") - por ejemplo viruses, gusanos y "trojans" -designados para dañar o interrumpir específicamente un sistema de cómputo, y otras actividades no deseadas. Los modelos de seguridad de control de acceso existentes normalmente se basan en una credencial del usuario para autorizar el acceso a recursos en una computadora. En estos modelos, cada proceso que corre o se ejecuta con las mismas credenciales se le proporcionan los mismos derechos de acceso, ya sea que el proceso necesite o no acceso para todos los recursos que están disponibles para el usuario. Asimismo, un proceso que necesita acceso a un recurso, por ejemplo, leer, escribir, etc., especifica el acceso requerido en el momento en el que se accesa el recurso. Por ejemplo, un usuario entra a una computadora personal con una cuenta de usuario, y espera tener la capacidad de accesar todos los documentos de procesamiento de palabras almacenados en la computadora personal y que son creados utilizando un programa de procesamiento de palabras en particular. Con el objeto de satisfacer esta expectativa, un sistema de seguridad de control de acceso convencional concede que todos los programas corran dentro del permiso del contexto del usuario para accesar a todos los documentos de procesamiento de palabras antes mencionados. Sin embargo, esta es una conceción con un nivel de permiso excesivo, ya que algunos programas corren dentro de un contexto del usuario diferente al programa de procesamiento de palabras al que realmente necesita accesar para cualesquiera de los documentos de procesamiento de palabras. Normalmente, el malware infecta los procesos explotando los defectos del código. Una vez que el malware corre dentro de un proceso comprometido, hereda los derechos de acceso del contexto del usuario en el cual está corriendo el proceso, y obtiene acceso a todos los recursos que están disponibles para el usuario, lo cual puede ser mucho mayor que lo que el proceso original siempre ha necesitado. Sumario del Invento Por consiguiente, sería de gran utilidad un método integrado para autorizar un acceso, el cual mejore y aumente la seguridad de recursos en una computadora. Breve Descripción de los Dibujos La figura 1, es un diagrama de bloque que ilustra los componentes seleccionados normalmente incorporados en al menos algunos de los sistemas de cómputo en los cuales se ejecuta la instalación. La figura 2, es un diagrama de bloque que ilustra los componentes seleccionados de la instalación, de acuerdo con algunas modalidades. La figura 3, ilustra una política de ejemplo adecuada para ser utilizada por la instalación, de acuerdo con algunas modalidades. La figura 4, ilustra un diagrama de flujo de un método a través del cual la instalación realiza la auditoría de solicitudes de acceso denegadas, de acuerdo con algunas modalidades. La figura 5, ilustra un diagrama de flujo de un método a través del cual la instalación lleva a cabo la auditoría de instalaciones inherentemente peligrosas, de acuerdo con algunas modalidades. La figura 6, ilustra un diagrama de flujo de un método a través del cual la instalación lleva a cabo la adaptación para facilitar la sintonización fina de una política, de acuerdo con algunas modalidades. La figura 7, ilustra un diagrama de flujo de un método a través del cual la instalación proporciona una revisión de control de acceso organizado por niveles, de acuerdo con algunas modalidades. La figura 8, ilustra un diagrama de flujo de un método a través del cual la instalación determina un nivel de riesgo de seguridad de un programa de aplicación, de acuerdo con algunas modalidades. La figura 9, ilustra un diagrama de flujo de un método a través del cual la instalación impone una política más estricta al detectar una anomalía, de acuerdo con una modalidad. La figura 10, ilustra un diagrama de flujo de un método a través del cual la instalación impone una política al detectar una anomalía, de acuerdo con algunas modalidades. Se describe una instalación ("facility") de software para proteger a una computadora de los efectos adversos que surgen de las explotaciones contra los programas de aplicación y del sistema de operación que se encuentran en el sistema de cómputo. En algunas modalidades, la instalación se implementa como una parte integral del sistema de operación y agrega al sistema de operación una capa de control de acceso operado por lógica. Por ejemplo, la instalación se implementa en una forma que es integral al mecanismo de control de acceso del sistema de operación. La instalación puede proporcionar un modelo de autorización que recibe solicitudes de autorización para diversos accesos de recursos susceptibles a seguridad y regresa una decisión que permite o niega un acceso de recursos con base en una política centralizada. Una política es un conjunto de reglas y prácticas que determinan cómo se administra y protege un recurso - tal como, a manera de ejemplo, una red, un sistema de archivos o un programa de aplicación, etc. En un almacenamiento de políticas centralizado, las reglas en una política están centralizadas, lo cual permite que las reglas y/o la política, sean revocadas centralmente y se ajusten centralmente. Esto en contraste con un modelo de control de acceso distribuido o por objeto, que se implementa normalmente utilizando las listas de control de acceso que están unidas a los objetos físicos. El módulo de autorización puede ser consultado directamente por los diversos componentes del sistema de operación que dan servicio a las solicitudes de acceso de recursos emitidas por los programas de modo-usuario, por ejemplo, los programas de aplicación que se ejecutan dentro del contexto de un usuario. Como alternativa, el módulo de autorización puede ser consultado por una "capa de intercepción" que se encuentra en la parte superior de dichos componentes del sistema de operación. La capa de intercepción es el código que intercepta las funciones de llamadas del sistema utilizadas por los programas de modo-usuario para accesar a los recursos, y aplica "encapsuladores" para las funciones de llamada del sistema interceptado. El módulo de autorización realiza sus decisiones de control de acceso (por ejemplo, permite o niega) con base en la identidad de un principal, el cual es ya sea la identidad del programa de aplicación - por ejemplo proceso de aplicación - que intenta el acceso al recurso, o una combinación de la identidad del programa de aplicación y la identidad del usuario a nombre del cual se ejecuta el programa de aplicación, y una política que aplica para el principal. En algunas modalidades, la instalación proporciona una característica de auditoría. Por ejemplo, una política puede indicar que una acción en particular, ya sea que una solicitud de autorización sea permitida (por ejemplo, concedida) o denegada (por ejemplo bloqueada) será sometida a una auditoría, de modo que se agrega una entrada a un registro de auditoría. La entrada puede incluir una indicación de la regla quebrantada, el recurso u objeto y el principal. Para ciertas operaciones, tal como operaciones inherentemente peligrosas, la entrada puede incluir una indicación de la regla, si la regla fue permitida o denegada, el recurso u objeto y el principal. La instalación puede activar en forma adicional eventos con base en la auditoría. Por ejemplo, la instalación puede estar configurada para proporcionar al principal (por ejemplo, el programa de aplicación y/o el usuario) u otra parte interesada, una notificación o indicación de la regla quebrantada o la operación inherentemente peligrosa. En algunas modalidades, la instalación proporciona una característica de modo de adquisición, en donde la instalación elabora pruebas o reportes con respecto a una regla, en lugar de aplicar la regla. Por ejemplo, una regla en una política, puede especificar que será denegada una solicitud de autorización para llevar a cabo una acción. Si se activa el modo de adquisición para la regla, por ejemplo, a través del autor de la política, la instalación, en lugar de denegar la autorización solicitada para llevar a cabo la acción, permite u otorga la autorización para llevar a cabo la acción, y surge un evento que indica que la solicitud de autorización para llevar a cabo la acción podría ser denegada. La instalación puede generar un reporte, el cual indica, por ejemplo, que la regla pudo haber sido bloqueada, el estado del programa de aplicación antes de la solicitud de la acción, y similares. La característica de modo de adición de adquisición facilita la sintonización fina de la política. Por ejemplo, el autor de una política puede analizar el reporte y hacer una determinación de si una política o una regla en la política, necesita ser más o menos restrictiva. En algunas modalidades, la instalación es ejecutada como parte de una revisión de control de acceso por niveles. Aquí, la instalación lleva a cabo la revisión de la política como parte de una serie de revisiones de control de acceso. Por ejemplo, cuando se elabora una solicitud de recurso, el mecanismo de control de acceso convencional puede ser invocado inicialmente para determinar si existe la autorización para el recurso requerido. En forma subsecuente al mecanismo de control de acceso convencional que determine inicialmente que existe una autorización para el recurso requerido, la instalación puede ser invocada para revisar sus políticas, para determinar si existe la autorización para el recurso requerido. En forma subsecuente, una o más revisiones de control de acceso adicional pueden ser invocadas adicionalmente, para determinar finalmente si existe la autorización para el recurso requerido. Las diversas modalidades de la instalación y sus ventajas serán mejor comprendidas haciendo referencia a las figuras 1 a la 10 de los dibujos. Los elementos de los dibujos no están necesariamente a escala, poniéndose énfasis más bien en ilustrar claramente los principios de la presente invención. A lo largo de los dibujos, los números similares se utilizan para las partes similares y correspondientes de los diferentes dibujos. La figura 1, es un diagrama de bloque que ilustra componentes seleccionados normalmente incorporados en al menos algunos de los sistemas de cómputo en los cuales se ejecuta la instalación. Estos sistemas de cómputo 100 pueden incluir una o más unidades de procesamiento central ("CPUs") 102, para ejecutar los programas de cómputo; una memoria de computadora 104 para almacenar los programas y datos - incluyendo estructuras de datos - mientras que están siendo utilizados al mismo tiempo; un dispositivo de almacenamiento persistente 106, tal como un disco duro, para almacenar en forma persistente programas y datos; una unidad de disco del medio legible en computadora 108, tal como una unidad de disco CD-ROM, para leer programas y datos almacenados en un medio legible en computadora; y una conexión de red 110 para conectar el sistema de cómputo a los otros sistemas de cómputo, tal como a través de la Internet, para intercambiar programas y/o datos -incluyendo estructuras de datos. La instalación puede ser descrita dentro del contexto general de las instrucciones legibles en computadora, tales como módulos del programa, ejecutados por los sistemas de cómputo 100 u otros aparatos. Generalmente, los módulos del programa incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc., que llevan a cabo tareas particulares o implementan tipos de datos abstractos particulares. La memoria 104 y el dispositivo de almacenamiento persistente 106, son medios legibles en computadora que pueden contener instrucciones que implementan la instalación. Se apreciará que la memoria 104 y el almacenamiento persistente 106 pueden tener otros diversos contenidos además de las instrucciones que implementan la instalación. Se podrá apreciar que los sistemas de cómputo 100 pueden incluir uno o más aparatos de despliegue para desplegar las salidas del programa, tal como monitores de video o paneles LCD, y uno o más aparatos de entrada para recibir la entrada del usuario, tal como teclados, micrófonos, o aparatos de señalización, tales como un ratón. Aunque los sistemas de cómputo 100 configurados como se describió anteriormente, se utilizan normalmente para soportar la operación de la instalación, se podrá apreciar que la instalación puede implementarse utilizando aparatos de diversos tipos y configuraciones, y teniendo diversos componentes. La figura 2, es un diagrama de bloque que ilustra los componentes seleccionados de la instalación, de acuerdo con algunas modalidades. Tal como se ilustra en la figura 2, la instalación incluye un módulo de autorización 202 el cual se implementa como un componente integral de un sistema de operación 204, adecuado para ejecutarse en un sistema de cómputo 100. El módulo de autorización 202 funciona generalmente como una capa de protección agregada para procesos de alto riesgo, tales como aplicaciones orientadas hacia la red, servicios orientados hacia la red y componentes del sistema de operación, aplicaciones que tratan con contenido no confiable y códigos no confiables, por ejemplo, normalmente los códigos que son proporcionados vía Internet. El módulo de autorización 202 proporciona la lógica para llevar a cabo el control de acceso operado por la política de los recursos disponibles en el sistema de cómputo 100. La instalación también incluye políticas 206 a partir de las cuales el módulo de autorización 202 realiza sus decisiones de control de acceso. Las políticas 206 son las reglas que determinan si se permite o niega una solicitud de autorización para accesar a un recurso. En algunas modalidades, las políticas 206 obtienen reglas recopiladas en el tiempo de activación - por ejemplo binario - que son impuestas por el sistema de operación 204, y en particular, el módulo de autorización 202. En algunas modalidades, se implementan las políticas 206 como parte de un almacenamiento de políticas centralizado, el cual permite que las políticas 206, incluyendo las reglas en las políticas 206, sean revocadas centralmente y ajustadas centralmente, por ejemplo, por los usuarios y/o administradores. El módulo de autorización 202 puede ser consultado por los diversos componentes del módulo central del sistema de operación 208 que dan servicio a las solicitudes de acceso a los recursos emitidas por un principal, por ejemplo, un principal 212a. El módulo de autorización 202 también puede ser consultado por una capa de intercepción 210 que intercepta las funciones de llamada del sistema emitidas por un principal, por ejemplo, un principal 212b, para accesar a los recursos. La capa de intercepción 210 aplica encapsuladores a las funciones de llamada del sistema interceptado, que hace posible que el módulo de autorización 202 lleve a cabo la revisión de control de acceso contra la política aplicable 206. Por ejemplo, la aplicación de un encapsulador puede incluir determinar la identidad del principal y/o varios factores ambientales asociados con el sistema de cómputo 100 y proporcionar esta información como parte de una solicitud de autorización para realizar una llamada del sistema al módulo de autorización 202 para que permita llevar a cabo la revisión de control de acceso. Además, el módulo de autorización 202 puede ser consultado directamente por un principal, por ejemplo, un principal 212c. En algunas modalidades, la revisión de control de acceso llevada a cabo por el módulo de autorización 202, es una función de un principal que realiza la solicitud de acceso del recurso de una política que aplica para el principal. Por lo tanto, el módulo de autorización 202 realiza sus decisiones de control de acceso (por ejemplo, permiso o negación) con base en una identidad de un principal - ya sea la identidad de un programa de aplicación de llamadas, o la combinación de la identidad del programa de aplicación de llamadas y la identidad de un usuario a nombre del cual se ejecuta el programa de aplicación - y las reglas en la política que son aplicables para el principal. En algunas modalidades, el módulo de autorización 202 puede considerar adicionalmente parámetros, tales como por ejemplo, tipo de acceso requerido, factores ambientales -por ejemplo, la computadora en la cual se ejecuta el programa de aplicación dentro de una red corporativa o conectada a una red pública, nivel de arreglo de un programa que agrega o cambia una pequeña parte de la computadora, etc. - además de la identidad del principal y las reglas en la política que son aplicables al principal en la realización de su decisión de control de acceso. En algunas modalidades, la instalación puede incluir un módulo de detección de anomalías opcional 214, tal como se ilustra a través de las líneas discontinuas o "punteadas" de la figura 2. El módulo de detección de anomalías 214 funciona generalmente para monitorear el comportamiento del sistema de cómputo 100 y los programas que se ejecutan en el sistema de cómputo 100, con el objeto de detectar un estado de anomalía. En algunas modalidades, el módulo de detección de anomalías 214 proporciona a la instalación una primera notificación al detectar una anomalía, y una segunda notificación subsecuente, al detectar el término de la anomalía detectada previamente. Esto permite a la instalación activar la implementación de las políticas 206 al detectar una anomalía, hasta que la anomalía haya terminado, después de lo cual ya no se ¡mplementan las políticas 206. Como alternativa, se le puede imponer inicialmente a la instalación un conjunto de políticas menos restrictivas hasta que se detecte una anomalía, en cuyo caso se impone un conjunto de políticas más restrictivas, hasta que la anomalía haYA finalizado y se implementa nuevamente el conjunto de políticas menos restrictivas. El módulo de detección de anomalías 214 puede detectar una anomalía ya sea en un proceso simple que se ejecute en el sistema de cómputo 100, un grupo de procesos que se ejecutan en el sistema de cómputo 100 ó en todo el sistema de cómputo 100. Los aspectos antes mencionados de la instalación, son únicamente ilustrativos y no pretenden sugerir alguna limitación a la implementación de los componentes ilustrados y/o el alcance de uso o funcionalidad de la instalación. Por ejemplo, en algunas modalidades, el módulo de autorización 202 no necesita ser implementado como parte o en forma integral al sistema de operación 204, sino puede ser implementado en forma separada o externa al sistema de operación 204, por ejemplo, como un programa del sistema no operativo. Además, en algunas modalidades, las políticas 206 no necesitan ser ímplementadas como parte de un almacenamiento de políticas centralizado. Por lo tanto, las políticas 206 no necesitan estar en un lugar, sino pueden ser ímplementadas, por ejemplo, utilizando un modelo distribuido. Además, incluso aunque las políticas 206 se ilustran como parte, o contenidas en un módulo de autorización 202, las políticas 206 necesitan ser accesibles únicamente para el módulo de autorización 202.
En la descripción que se encuentra a continuación, las modalidades de la instalación se describen junto con una variedad de ejemplos ilustrativos. Se podrá apreciar que las modalidades de la instalación pueden ser utilizadas en circunstancias que difieren significativamente de estos ejemplos en varios aspectos. La figura 3, ilustra una política de ejemplo adecuada para ser utilizada por la instalación, de acuerdo con algunas modalidades. La política de ejemplo incluye las reglas para proteger una aplicación de servidor web. A manera de ejemplo, un proceso de aplicación, tal como se indica con la partida 302, que requiere un recurso, es revisado para determinar si es un proceso de servidor web WebServerX, tal como se indica en la partida 304. Si el módulo de autorización 202 determina que el proceso de aplicación que está solicitando es un proceso de servidor web WebServerX, el módulo de autorización 202 ya sea permite o niega la autorización del recurso requerido, con base en las reglas incluidas en la política. Como se ilustra, la política de ejemplo contiene los privilegios o derechos de acceso concedidos a un proceso WebServerX, y por default se niega la autorización para el recurso requerido, tal como se indica a través de la regla 306, a menos que se especifique el privilegio o derecho de acceso. Dicho de otra forma, a menos que el recurso solicitado sea concedido explícitamente en la política, se niega la autorización para el recurso solicitado. En algunas modalidades, la política puede contener reglas que especifican las restricciones de acceso, por ejemplo, reglas que especifican que será denegada la autorización para llevar a cabo acciones particulares o que se niega la autorización para accesar recursos, o reglas que originen una auditoría, por ejemplo, registro de un evento. La primera regla en la política de ejemplo es una directriz para permitir que el proceso WebServerX escriba archivos "$html", tal como se indica en la partida 308, a "$WebDirectories", tal como se indica a través de la partida 310. El archivo "$html" es una representación de una recolección de los tipos de archivo, por ejemplo, *.html, *.gif, etc. El "$ WebDirectories" es una representación de una recolección de directorios configurados para ser directorios web, y puede definirse a través de un administrador, tal como un administrador web, que es diferente al creador de la política, tal como un administrador de seguridad. Por ejemplo, el módulo de autorización 202 regresa una decisión de permiso (por ejemplo, otorgamiento de autorización) con base en esta regla en respuesta a un proceso WebServerX que requiere escribir un archivo de un tipo definido por el parámetro "$html" a un o de los directorios definidos por el parámetro "$WebD¡rectories". Por lo tanto, una regla en la política puede aplicar para grupos de objetos dinámicos definidos independientemente, tales como "$WebDirectories", y parámetros ambientales conf igurables en forma dinámica, tal como "$html". La segunda regla en la política de ejemplo es una directriz para permitir que el proceso WebServerX escriba al "$FTP Upload Directory", tal como se indica a través de la partida 312, si se está ejecutando en nombre del "usuario A", tal como se indica a través de la partida 314. Por ejemplo, el módulo de autorización 202 regresa una decisión de permiso (por ejemplo, otorgamiento de autorización) con base en esta regla en respuesta a un proceso WebServerX que se ejecuta en nombre del usuario A que requiere escribir al "$FTP Upload Directory". La tercera regla en la política de ejemplo es una directriz para permitir el tráfico http de entrada, tal como se indica a través de la partida 316. Por ejemplo, el módulo de autorización 202 regresa una decisión de permiso (por ejemplo, concesión de autorización) con base en esta regla en respuesta a un proceso WebServerX que requiere recibir datos http de entrada, por ejemplo, recibir paquetes de datos http transmitidos a través de una conexión de la red. La cuarta regla en la política de ejemplo es una directriz para permitir "tráfico FTP", tal como se indica a través de la partida 318, si se habilita la variable "$FTP", tal como se indica con la partida 320. Aquí, "$FTP" es una variable, y puede ajustarse a través de un administrador que es diferente a un administrador de seguridad quien crea la política. Por ejemplo, el módulo de autorización 202 lleva a cabo una revisión de tiempo de operación para determinar si "$FTP" variable está habilitada, y si es así, regresa una decisión de permiso (por ejemplo, otorgamiento de autorización) con base en esta en respuesta a un proceso WebServerX que solicita enviar o recibir datos definidos por el parámetro "tráfico FTP". Como alternativa, si el "$FTP" no está habilitado, el módulo de autorización 202 regresará una decisión de negativa (por ejemplo, negación de autorización) en respuesta a la solicitud de acceso antes mencionada, tal como se indica con la partida 306. Se podrá apreciar que la política puede incluir reglas que definen privilegios para objetos dentro y fuera del sistema de operación, tal como los procesos de aplicación que se ilustran a través del privilegio de ejemplo anterior. Las reglas en una política pueden ser especificadas utilizando un esquema sustancioso, similar a escribir un código utilizando lenguaje de programación recopilado o interpretado. Por ejemplo, el esquema puede soportar la inclusión de condiciones y condiciones temporales, por ejemplo "permitir X únicamente si Y", dependencias en los parámetros y variables del ambiente configurable en forma dinámica, dependencias en los factores ambientales, y similares, en las reglas. Además, el uso de parámetros facilita la creación de reglas que aplican a objetos tanto presentes como futuros. Por ejemplo, los documentos de un tipo en particular pueden ser representados por un parámetro, y utilizando el parámetro, se puede crear una regla que especifique una restricción que aplica a todos los documentos del tipo en particular, ya sea normalmente en existencia o creados posteriormente. En algunas modalidades, la política puede especificar que ciertas decisiones serán relegadas para la decisión del usuario final, por ejemplo, a través de un cuadro de diálogo que aparece temporalmente. La figura 4, ilustra un diagrama de flujo de un método
400 a través del cual la instalación lleva a cabo la auditoría de solicitudes de acceso denegadas, de acuerdo con algunas modalidades. A manera de ejemplo, un usuario (por ejemplo UserABC) puede haber entrado a una computadora y haber iniciado una aplicación de procesamiento de palabras (por ejemplo WPApp) y solicitado abrir un archivo (por ejemplo archivo X) almacenado en un directorio (por ejemplo YZDir) en la computadora. Como resultado, WPApp emite una solicitud de acceso al recurso FileX almacenado en el directorio YZDir. Comenzando con un primer paso, el módulo de autorización 202 recibe la consulta de autorización, por ejemplo, una solicitud de autorización de acceso al FileX archivado en YZDir, en el paso 402. En el paso 404, el módulo de autorización 202 identifica al principal que está requiriendo la autorización de acceso al FileX almacenado en YZDir. En el ejemplo anterior, el principal puede ser ya sea un WPApp o la combinación de WPApp y UserABC. En el paso 406, el módulo de autorización 202 identifica la política aplicable al principal identificado, por ejemplo, a partir de un almacenamiento de políticas centralizado tal como las políticas 206, y lleva a cabo una revisión de control de acceso con base en la identidad del principal y la política aplicable. En el paso 408, el módulo de autorización 202 determina si el resultado de la revisión de control de acceso llevada a cabo en el paso 406 es para denegar el acceso. Continuando con el ejemplo anterior, el módulo de autorización 202 analiza la política aplicable identificada para determinar si una regla o privilegio en la política, autoriza al principal a accesar el FileX almacenado en YZDir, en el paso 408. Si el módulo de autorización 202 determina que la política aplicable autoriza al principal a llevar a cabo la acción solicitada, entonces en el paso 420, el módulo de autorización 202 regresa una decisión de permiso, la cual es una indicación de que el principal está autorizado para llevar a cabo la acción solicitada, y procede a un paso final. Como alternativa, si el módulo de autorización 202 determina que la política aplicable no autoriza al principal a llevar a cabo la acción solicitada, entonces en el paso 410, el módulo de autorización 202 regresa una decisión de negación, la cual es una indicación de que el principal no está autorizado para llevar a cabo la acción solicitada. En el paso 412, el módulo de autorización 202 puede regresar una serie de caracteres de error al principal, informando al mismo de la carencia de autorización para llevar a cabo la acción solicitada. En el paso 414, el módulo de autorización 202 realiza una revisión para determinar si se habilita la auditoría. Una señal o un registro asociado con la política o regla aplicable, puede indicar si se lleva a cabo la auditoría. Si la auditoría no es habilitada, el módulo de autorización 202 procede a un paso final. Como alternativa, si se habilita la auditoría, el módulo de autorización 202 realiza una entrada en un registro de auditoría en el paso 416. La entrada puede identificar la solicitud denegada, la regla quebrantada, el principal y/o el recurso solicitado. En el paso 418, el módulo de autorización 202 puede activar uno o más eventos con base en la auditoría de la solicitud denegada. Por ejemplo, el módulo de autorización 202 puede proporcionar a un administrador de seguridad una indicación, por ejemplo, vía correo electrónico, correo de voz, mensajería de texto, etc., del intento por parte del principal para llevar a cabo una acción no autorizada, terminar el proceso de aplicación subsecuente al intento por parte del principal para llevar a cabo una acción no autorizada, imponer un conjunto de políticas más estrictas en forma subsecuente al intento por parte del principal para llevar a cabo una acción no autorizada, y similares. Posteriormente a la activación de los eventos, el módulo de autorización 202 procede a un paso final. Los expertos en la técnica podrán apreciar que, para este y otros procesos y métodos aquí descritos, se pueden implementar con un orden diferente en las funciones llevadas a. cabo en los procesos y métodos. Además, los pasos señalados son únicamente de ejemplo, y algunos de los pasos pueden ser opcionales, combinados con menos pasos, o expandidos en pasos adicionales sin detractarse de la esencia de la presente invención. La figura 5, ilustra un diagrama de flujo de un método
500 a través del cual la instalación lleva a cabo la auditoría de operaciones inherentemente peligrosas, de acuerdo con algunas modalidades. A manera de ejemplo, un usuario (por ejemplo UserABC) puede haber entrado a una computadora e iniciado un programa de buscador web (por ejemplo WebBrowser) y haber solicitado acceso a una página web (por ejemplo PageX) en un sitio web no confiable (por ejemplo WebSiteY). Como resultado, el WebBrowser emite una solicitud de recuperación PageX del WebSiteY. Los pasos del 502 al 508 son substancialmente similares a los pasos del 402 al 408 del método 400. Si en el paso 508, el módulo de autorización 202 determina que la política aplicable no autoriza al principal a llevar a cabo la acción requerida, entonces en el paso 510, el módulo de autorización 202 regresa una decisión de negación, la cual es una indicación de que el principal no está autorizado para llevar a cabo la acción solicitada. En el ejemplo anterior, el WebBrowser puede no tener autorización de accesar al sitio no confiable WebSiteY. En el paso 512, el módulo de autorización 202 puede regresar una serie de caracteres de error al principal, informándole de la carencia de autorización para llevar a cabo la acción solicitada. En forma subsecuente al regreso de una serie de caracteres de error, el módulo de autorización procede a un paso final. Como alternativa, si el módulo de autorización 202 determina que la política aplicable autoriza al principal a llevar a cabo la acción solicitada, entonces en el paso 514, el módulo de autorización 202 regresa una decisión de permiso, la cual es una indicación de que el principal está autorizado para llevar a cabo la acción solicitada. En el paso 516, el módulo de autorización 202 hace una revisión para determinar si la acción autorizada es una operación inherentemente peligrosa. Por ejemplo, la instalación puede mantener una lista de operaciones inherentemente peligrosas, y el módulo de autorización 202 puede revisar esta lista para determinar si la acción autorizada está descrita como una operación inherentemente peligrosa. Si la acción autorizada se encuentra como una operación inherentemente peligrosa, entonces en el paso 518, el módulo de autorización 202 lleva cabo una operación de auditoría. Por ejemplo, el módulo de autorización 202 puede ingresar en un registro de auditoría de operaciones inherentemente peligrosas una indicación de la solicitud de autorización para llevar a cabo la operación inherentemente peligrosa. La entrada también puede incluir una indicación de que el principal solicita la autorización para llevar a cabo la operación inherentemente peligrosa. El módulo de autorización 202 puede llevar a cabo adicionalmente otras acciones las cuales pueden ser activadas a través de la autorización para llevar a cabo la operación inherentemente peligrosa. Después ded llevar a cabo la operación de auditoría en el paso 518, ó determinar que la acción autorizada no es una operación inherentemente peligrosa en el paso 516, el módulo de autorización 202 procede a un paso final. En algunas modalidades, el módulo de autorización 202 puede ingresar en el registro de auditoría de operaciones inherentemente peligrosas una indicación de una solicitud de autorización para llevar a cabo una operación inherentemente peligrosa. Continuando con el ejemplo anterior, suponiendo que el acceso al sitio WebSiteY no confiable está indicado como una operación inherentemente peligrosa, y además, que la política aplicable no otorga autorización al WebBrowser de accesar el WebSiteY, el módulo de autorización 202 regresa una decisión de negación (paso 510) y registra la solicitud de autorización para llevar a cabo la operación inherentemente peligrosa y la negación subsecuente de autorización, por ejemplo, en el registro de auditoría de operaciones inherentemente peligrosas. El módulo de autorización 202 también puede registrar una indicación de que el principal solicita autorización para llevar a cabo la actividad inherentemente peligrosa. La figura 6, ilustra un diagrama de flujo de un método
600 a través del cual la instalación lleva a cabo la adquisición para facilitar la sintonización final de una política, de acuerdo con algunas modalidades. A manera de ejemplo, un usuario (por ejemplo UserABC) puede haber entrado a una computadora y haber Iniciado un programa de buscador web (por ejemplo WebBrowser) y solicitado acceso a una página web (por ejemplo PageX) en un sitio web (por ejemplo WebSiteY). Como resultado, el WebBrowser emite una solicitud para recuperar la PageX del WebSiteY. Los pasos del 602 al 608 son substancialmente similares a los pasos 402 a 408 del método 400. Si en el paso 608, el módulo de autorización 202 determina que la política aplicable autoriza al principal a llevar a cabo la acción requerida, entonces en el paso 610, el módulo de autorización 202 regresa una decisión de permiso, la cual es una indicación de que el principal está autorizado para llevar a cabo la acción solicitada, y procede a un paso final. Como alternativa, si el módulo de autorización 202 determina que la política aplicable no autoriza al principal a llevar a cabo la acción solicitada, entonces en el paso 612, el módulo de autorización 202 hace una revisión para determinar si se habilita la adquisición para la regla en la política que niega la autorización para llevar a cabo la acción solicitada. Continuando con el ejemplo anterior, una política aplicable al WebBrowser puede contener una regla que niega expresamente al WebBrowser el acceso a la Internet, y por lo tanto, el WebSiteY, aunque también puede proporcionar una indicación para aplicar la adquisición en lugar de aplicar la regla.
Si el módulo de autorización 202 determina que la adquisición no está habilitada para la regla que niega la autorización para llevar a cabo la acción solicitada, entonces en el paso 618, el módulo de autorización 202 regresa una decisión de negación, la cual es una indicación de que el principal no está autorizado para llevar a cabo la acción solicitada. En el ejemplo anterior, la regla que niega expresamente al WebBrowser el acceso a la Internet, y por lo tanto, el WebSiteY, puede no tener una indicación de aplicar la adquisición. En este caso, la regla es aplicada y se niega al WebBrowser autorización para accesar la WebSiteY. En el paso 620, el módulo de autorización 202 puede regresar una serie de caracteres de error al principal, informándole que carece de autorización para llevar a cabo la acción solicitada. En forma subsecuente al regreso de una serie de caracteres de error, el módulo de autorización procede a un paso final. Como alternativa, si en el paso 612 el módulo de autorización 202 determina que se habilita la adquisición para la regla que niega la autorización para llevar a cabo la acción solicitada, entonces en el paso 614, el módulo de autorización 202 ingresa en un registro de reportes de adquisición una indicación de la regla quebrantada. El ingreso también puede incluir una indicación de que el principal solicitó la autorización de llevar a cabo la acción que dio como resultado el rompimiento de la regla. En el paso 616, el módulo de autorización 202 regresa una decisión de permiso, la cual es una indicación de que el principal está autorizado para llevar a cabo la acción requerida, y procede a un paso final. Por lo tanto, en lugar de aplicar la regla aplicable, el módulo de autorización 202 otorga autorización para llevar a cabo la acción solicitada y registra una indicación de este evento. Un administrador de seguridad u otro usuario interesado, posteriormente puede analizar los contenidos del registro del reporte de adquisición para determinar si una regla o política es demasiado restrictiva o no lo suficientemente restrictiva, y sintonizar en forma fina la regla o política antes de implementar o imponer realmente la regla o política. En algunas modalidades, el módulo de autorización
202 puede ingresar en el registro de reporte de adquisición una Indicación de una regla que proporcione la autorización para llevar a cabo una acción solicitada. Continuando con el ejemplo anterior, suponiendo que una regla autoriza expresamente al WebBrowser accesar a la Internet, y por lo tanto, el WebSiteY, y también proporciona una indicación de aplicar la adquisición, el módulo de autorización 202 regresa una decisión de permiso (paso 610), y registra una indicación de que la regla ha proporcionado la autorización para llevar a cabo la acción solicitada. Esta información también puede ser utilizada para sintonizar en forma fina la regla o política. Por ejemplo, si se determina, a partir de las entradas en el registro de reporte, que la autorización de acceso al recurso fue otorgada en forma muy fácil, la regla o política puede ser ajustada o alterada para reducir los casos en los cuales se conceda ¡a autorización para accesar al recurso. La figura 7, ilustra un diagrama de flujo de un método 700 a través del cual la instalación proporciona una revisión de control de acceso por niveles, de acuerdo con algunas modalidades. Haciendo referencia nuevamente a uno de los ejemplos anteriores, un usuario (por ejemplo UserABC) puede haber entrado a una computadora e iniciar una aplicación de procesamiento de palabras (por ejemplo WPApp) y solicitado abrir un archivo (por ejemplo FileX) almacenado en un directorio (por ejemplo YZDir) en la computadora. Como resultado, el WAPpp emite una solicitud para accesar al recurso FileX almacenado en el directorio YZDir. Comenzando con el paso de inicio, el módulo de autorización 202 recibe la consulta de autorización, por ejemplo, una solicitud de autorización para accesar el FileX almacenado en YZDir, en el paso 702. En el paso 704, un sistema de operación que corre en la computadora del usuario lleva a cabo una revisión de control de acceso convencional. Continuando con el ejemplo anterior, el sistema de operación puede hacer una revisión para determinar si el usuario tiene derechos de abrir (por ejemplo, acceso de lectura) el FileX en YZDir. En el paso 706, el sistema de operación, utilizando este mecanismo de revisión de acceso convencional, determina si niega al usuario el acceso al FileX. Si el mecanismo de revisión de acceso convencional del sistema de operación determina que se le debe negar al usuario el acceso al File X, entonces en el paso 708, el sistema de operación regresa a una decisión de negación, y procede a un paso final. La decisión de negación es una indicación de que el usuario no está autorizado para llevar a cabo la acción solicitada, por ejemplo, abrir el File X. Como alternativa, si el mecanismo de revisión de acceso convencional al sistema de operación determina que al usuario no se le debe negar el acceso al File X, entonces en el paso 710, el módulo de autorización 202 identifica que el principal está solicitando la autorización para accesar el File X almacenado en YZDir. En el paso 712, el módulo de autorización 202 identifica la política aplicable para el principal identificado, por ejemplo, a partir de un almacenamiento de política centralizado tal como las políticas 206, y lleva a cabo una revisión de control de acceso con base en la identidad del principal y la política aplicable. Continuando con el ejemplo anterior, el módulo de autorización 202 analiza la política aplicable identificada para determinar si una regla o privilegio en la política, autoriza al principal el acceso al File X almacenado en YZDir, en el paso 714. Si un módulo de autorización 202 determina que la política aplicable autoriza al principal a llevar a cabo la acción solicitada, entonces en el paso 720, el módulo de autorización 202 regresa a una decisión de permiso, la cual es una indicación de que el principal está autorizado para llevar a cabo la acción solicitada, y procede a un paso final. Como alternativa, si el módulo de autorización 202 determina que la política aplicable no autoriza al principal a llevar a cabo la acción solicitada, entonces en el paso 716, el módulo de autorización 202 regresa a una decisión de negación, la cual es una indicación de que el principal no está autorizado para llevar a cabo la acción solicitada. En el paso 718, el módulo de autorización 202 puede regresar una serie de caracteres de error al principal, y proceder a un paso final. La serie de caracteres de error puede informar al principal de la carencia de autorización para llevar a cabo la acción solicitada. Se podrá apreciar que la revisión de acceso por niveles puede llevarse a cabo en orden inverso al que se ilustra en el método 700. Por ejemplo, el módulo de autorización 202, primero lleva a cabo su revisión de control de acceso. Si el módulo de autorización 202 determina que la autorización debe concederse para un acceso de recurso en particular, entonces el sistema de operación lleva a cabo su revisión de seguridad utilizando su mecanismo de control de acceso convencional. La figura 8, ¡lustra un diagrama de flujo de un método 800 a través del cual la instalación determina un nivel de riesgo de seguridad de un programa de aplicación, de acuerdo con algunas modalidades. En particular, la instalación realiza una evaluación del nivel de riesgo de seguridad y/o intento de un programa de aplicación con base en un análisis de una política designada para el programa de aplicación. A manera de ejemplo, un usuario puede haber entrado a una computadora y haber solicitado cargar y/o ejecutar un programa de aplicación en la computadora. Comenzando con el primer paso, un sistema de operación que corre en la computadora del usuario recibe una solicitud de cargar/ejecutar el programa de aplicación en el paso 802. En el paso 804, el sistema de operación invoca la instalación para determinar si el programa de aplicación tiene una política correspondiente. Por ejemplo, la política aplicable al programa de aplicación puede mantenerse como parte de las políticas 206. Si la instalación determina que una política aplicable al programa de aplicación no existe, la instalación informa al sistema de operación que no existe una política aplicable. En el paso 806, el sistema de operación niega la solicitud de cargar/ejecutar el programa de aplicación y regresa a una condición de error. En forma subsecuente a la negación de la solicitud, el sistema de operación procede a un paso final para esta solicitud. Como alternativa, si en el paso 804 la instalación determina que existe una política aplicable para el programa de aplicación, entonces en el paso 808, la instalación analiza la política aplicable para determinar el nivel de riesgo de seguridad potencial asociado con, o que resulta de la carga/ejecución del programa de aplicación. La instalación puede basar el nivel de riesgo, en el nivel o grado de autorización concedido por las reglas en la política. Por ejemplo, si las reglas autorizan al programa de aplicación un gran número de recursos o un número de recursos inherentemente peligrosos, la instalación puede ajustar más alto el nivel de riesgo, que si las reglas únicamente autorizan al programa de aplicación algunos recursos relativamente seguros. La instalación informa al sistema de operación de que existe una política aplicable, y procede a un paso final. La figura 9, ilustra un diagrama de flujo de un método 900 a través del cual la instalación impone una política más restrictiva al detectar una anomalía, de acuerdo con algunas modalidades. A manera de ejemplo, la instalación que corre en una computadora puede tener dos políticas, una PolicyA y una PolicyB, las cuales son aplicables para un programa de aplicación. Además, la PolicyA puede ser menos restrictiva que la PolicyB, ya que la PolicyA otorga autorización a un mayor número de recursos. Comenzando con el primer paso, la instalación impone la PolicyA menos restrictiva en el paso 902. En el paso 904, la instalación puede detectar un estado de anomalía en un objeto específico del programa de aplicación que se ejecuta en la computadora. Continuando con el ejemplo anterior, un objeto específico del programa de aplicación puede ejecutarse en la computadora, y la instalación puede monitorear la ejecución del proceso del programa de aplicación. Mientras se monitorea el proceso del programa de aplicación la instalación puede detectar una condición o estado de anomalía en el proceso. Por ejemplo, la instalación puede haber generado previamente una gráfica dirigida que representa las llamadas del sistema normalmente emitidas por el programa de aplicación, rastreando los objetos específicos previos del programa de aplicación que corrieron en la computadora, y habiendo determinado la presencia de un estado de anomalía a partir de una comparación de las llamadas del sistema elaborada por el proceso del programa de aplicación corriente y la gráfica dirigida. En el paso 906, la instalación impone la PolicyB más restrictiva en respuesta a la detección del estado de anomalía, y procede a un paso final. En una modalidad, la instalación impone la PolicyB más restrictiva en el proceso del programa de aplicación en el cual se detectó el estado de anomalía. Como alternativa, la instalación puede imponer la PolicyB más restrictiva en el programa de aplicación, por ejemplo, todos los objetos específicos o procesos del programa de aplicación. Además, dependiendo de la anomalía detectada, el programa de aplicación y/o la política en particular, la instalación puede imponer un conjunto de políticas no restrictivas en toda la computadora, por ejemplo, políticas más restrictivas que aplican a todos los procesos que se ejecutan en la computadora. La figura 10, ilustra un diagrama de flujo de un método 1000 a través del cual la instalación impone una política al detectar una anomalía, de acuerdo con algunas modalidades. A manera de ejemplo, la instalación que corre en una computadora puede tener una política, PolicyA, la cual es aplicable a un programa de aplicación web. Comenzando con el primer paso, la instalación no impone la política en el programa de aplicación web en el paso 1002.
Por lo tanto, la PolicyA está inactiva y no se aplica a los objetos específicos del programa de aplicación web que se ejecuta en la computadora. En el paso 1004, la instalación puede detectar un estado de anomalía en un objeto específico del programa de aplicación web que se ejecuta en la computadora. Continuando con el ejemplo anterior, se puede ejecutar en la computadora un objeto específico del programa de aplicación web, y la instalación puede monitorear la ejecución del proceso del programa de aplicación web. Mientras se monitorea el proceso del programa de aplicación, la instalación puede detectar una condición o estado de anomalía en el proceso. Por ejemplo, la instalación puede monitorear el tráfico de red generado u originado por el proceso de aplicación web y determinar a partir del tráfico de la red, que está presente un estado de anomalía en el proceso de aplicación web. En el paso 1006, la instalación impone la política inactiva, PolicyA, en el programa de aplicación web, por ejemplo, en el proceso del programa de aplicación web en el cual se detectó la anomalía, y procede a un paso final. Como alternativa, la instalación puede imponer la PolicyA en todos los objetos específicos o procesos del programa de aplicación web. Por lo tanto, la política inactiva se vuelve activa y se aplica al programa de aplicación web.
A partir de lo anterior, se podrá apreciar que las modalidades específicas de la presente invención han sido descritas para propósitos de ilustración, aunque se pueden realizar varias modificaciones sin apartarse del espíritu y alcance de la presente invención. Por consiguiente, la presente invención no está limitada excepto por las reivindicaciones adjuntas.