ES2574003T3 - Procedimiento y aparato para proporcionar seguridad de red utilizando control de acceso basado en roles - Google Patents

Abstract

Un aparato para asegurar el acceso a una red, comprendiendo el aparato; un medio de extracción (220) para extraer de un paquete un identificador de grupo de usuarios fuente (400) del paquete; un medio de recuperación (220) para recuperar, de una base de información de reenvío, un identificador de grupo de usuarios de destino (410) del paquete; y un medio de determinación de permiso (220) para determinar los permisos aplicables para el paquete utilizando el identificador de grupo de usuarios fuente y el identificador de grupo de usuarios de destino del paquete para determinar los permisos que se aplican al paquete, en el que la utilización del identificador de grupo de usuarios fuente y el identificador de grupo de usuarios de destino comprende indexar una matriz de control de acceso con el identificador de grupo de usuarios fuente y el identificador de grupo de usuarios de destino para proporcionar una lista de permisos permitidos; y un medio para comprobar los permisos en una comprobación de control de acceso basado en roles.

Description

DESCRIPCION

Procedimiento y aparato para proporcionar seguridad de red utilizando control de acceso basado en roles 5 ANTECEDENTES DE LA INVENCION

Campo de la invencion

[0001] Esta invencion se refiere al campo de la seguridad de redes de information, y mas en particular se 10 refiere a un procedimiento y aparato para asegurar el acceso a una red por parte de un usuario basandose en el rol del usuario.

Descripcion de la tecnica relacionada

15 [0002] Las tecnologlas de acceso a redes flexibles tales como inalambricas, el protocolo dinamico de configuration de anfitrion, pasarelas de red privada virtual (VPN) y similares permiten a los usuarios acceder a una red protegida dada desde una diversidad de puntos de acceso o entrada. Esto es cierto para todo tipo de redes, incluyendo las redes empresariales, las redes de proveedores de servicios y similares. Al mismo tiempo, la seguridad brindada mientras se proporciona tal acceso es de una preocupacion creciente. Las tecnologlas basadas 20 en el servicio de autenticacion remota telefonica de usuario (RADIUS), el sistema de control de acceso de controlador de acceso terminal (TACACS), el protocolo DIAMETER y otros protocolos permiten que un usuario sea autenticado en el momento de la entrada en la red.

[0003] Como es sabido, los trayectos de comunicaciones a traves de tales redes estan separados 25 conceptualmente (por ejemplo, pueden verse como trayectos virtuales separados), aunque pueden pasar por

algunos o todos de los mismos dispositivos de red (es decir, segmentos flsicos), y por eso son controlados por separado utilizando, por ejemplo, listas de control de acceso (ACL). Convencionalmente, las restricciones sobre el acceso del que disfrutan los usuarios de la red estan impuestas por las ACL, que se utilizan para procesar paquetes y controlar as! el trafico de red de tales usuarios. Por escalabilidad y manejabilidad, las aCl convencionales 30 requieren que la correspondencia de una direction de anfitrion de usuario (como la fuente del (los) paquete(s) dado(s); por ejemplo, una direccion de protocolo Internet (IP)) sea relativamente estatica, o que la polltica de seguridad sea suficientemente laxa para permitir todas las posibles direcciones posibles para el usuario.

[0004] Las ACL de seguridad de hoy en dla adolecen de varias debilidades. Estas ACL se aplican 35 convencionalmente a una interfaz dada y contienen direcciones IP que vinculan la polltica de seguridad directamente

a la topologla de red. Como resultado, un cambio en la red tal como la redistribution de subredes hace que la polltica de seguridad tenga que ser revisada. Por otra parte, parecerla que las ACL en diversas partes de la red tendrlan que ser actualizadas cada vez que un usuario es autenticado en la red, con el fin de anadir reglas asociadas con la direccion IP fuente asignada al anfitrion de este usuario, que serlan especlficas de ese usuario. 40 Esto causarla un enorme incremento en el numero de ACL unicas y aumentarla espectacularmente el ritmo al que tales reglas tendrlan que ser actualizadas.

[0005] Dentro de una ACL dada, tambien existe el problema de incrementos drasticos de tamano resultantes de la expresion de direcciones IP individuales, donde el numero de entradas a menudo es el numero de direcciones

45 fuente multiplicado por el numero de direcciones de destino, multiplicado por el numero de permisos. De este modo, la adicion de una sola direccion IP individual puede tener un impacto significativo sobre el tamano de un numero sustancial de ACL.

[0006] Cuando un cliente cambia la topologla de red, las ACL deben ser reexaminadas. Puesto que tales ACL 50 pueden alcanzar con bastante facilidad varios cientos o incluso varios miles de llneas de longitud, tal reexamen

puede resultar no insignificante, cuando menos. Debido a la complejidad de tal ACL, la confianza en los cambios que se efectuan no es muy alta, tlpicamente, y las ACL a menudo requieren pruebas extensivas por parte del usuario antes de ser implantadas en un entorno de production. Por otra parte, como las plataformas que utilizan memorias direccionables segun el contenido (CAM) para implantar ACL requieren la recompilation de algunas o todas las ACL 55 cuando se efectua algun cambio, los incrementos en el coste de procesamiento puede ser bastante graves, aproximandose a una ecuacion de segundo grado en el numero de usuarios. Estos incrementos de complejidad aumentan la posibilidad de una interruption de la red, un agujero de seguridad, o ambos. Una sola ACL pone a prueba la capacidad de un usuario de gestionar su polltica de seguridad. Implantar tales ACL por toda la red empresarial tiene impacto, por lo tanto, sobre la manejabilidad de las redes de hoy en dla. Dado lo anterior,

particularmente a la luz del acceso cada vez mas flexible que se requiere ahora y que se requerira en el futuro, es diflcii confiar en las soluciones existentes basadas en ACL.

[0007] Lo que se requiere, entonces, es un mecanismo que permita la identification eficiente del trafico de red 5 procedente de un anfitrion dado. Preferentemente, tal estrategia deberla emplear la tecnologla de ACL existente, en

tanto que reduciendo o eliminando el problema del crecimiento multiplicativo de ACL que se encuentra actualmente cuando se anaden anfitriones. Tambien preferentemente, tal estrategia deberla permitir que la red sea reconfigurada y crecer facilmente, sin incurrir en una carga administrativa desproporcionada o consumir cantidades excesivamente grandes de recursos de red.

10

[0008] El documento US2003/0110268 describe un servicio de red privada virtual (VPN) que se proporciona a traves de una infraestructura de red compartida que comprende dispositivos de borde del proveedor (PE) interconectados que tienen interfaces de borde del cliente (CE). Algunas de las interfaces de CE estan asignadas a una VPN que soporta LAN virtuales. Una correspondencia entre una interfaz de CE y una LAN virtual se aprende

15 basandose en tramas marcadas recibidas en la interfaz de CE y que incluyen un identificador de la LAN virtual. El

proceso de aprendizaje permite la detection de pares de interfaces de CE que corresponden a una LAN virtual

comun. Tras la deteccion, se establece una deteccion virtual en la infraestructura de red compartida entre los dispositivos de PE que tienen estas interfaces de CE, y posteriormente se utiliza para reenviar tramas que incluyen el identificador de la VLAN virtual.

20

[0009] Aspectos y ejemplos de la invention se exponen en las reivindicaciones.

[0010] Se desvela un dispositivo de red. El dispositivo de red incluye una lista de control de acceso. La lista de control de acceso incluye una entrada de lista de control de acceso, la cual, a su vez, incluye un campo de grupo de

25 usuarios. En otra realization, el dispositivo de red incluye una tabla de reenvlo. La tabla de reenvlo incluye una

pluralidad de entradas de tabla de reenvlo. En tal realizacion, al menos una de las entradas de tabla de reenvlo

incluye un campo de grupo de usuarios.

[0011] En una realizacion, una lista de control de acceso es poblada con un identificador de grupo de usuarios de 30 destino. El identificador de grupo de usuarios de destino identifica un grupo de usuarios de destino de un destino. En

otra realizacion, se desvela un procedimiento en el cual una tabla de reenvlo es poblada con un identificador de grupo de usuarios.

[0012] Lo precedente es un resumen y por lo tanto contiene, por necesidad, simplificaciones, generalizaciones y 35 omisiones de detalle; en consecuencia, los expertos en la materia apreciaran que el resumen es solo ilustrativo y no

pretende ser limitativo de ningun modo. Otros aspectos, caracterlsticas inventivas y ventajas de la presente invencion, tal como se define unicamente por las reivindicaciones, resultaran evidentes en la description detallada no limitativa expuesta mas adelante.

40 BREVE DESCRIPCION DE LOS DIBUJOS

[0013] La presente invencion puede comprenderse mejor, y numerosos objetos, caracterlsticas y ventajas hacerse evidentes para los expertos en la materia por referencia a los dibujos adjuntos.

45 La fig. 1A es un diagrama que ilustra un grupo jerarquico de usuarios segun realizaciones de la presente invencion. La fig. 1B es un diagrama que ilustra un conjunto disjunto de grupos de usuarios segun realizaciones de la presente invencion.

La fig. 2 es un diagrama de bloques que ilustra una arquitectura para autenticacion de usuario.

La fig. 3 es un diagrama de bloques que ilustra una tabla de reenvlo segun realizaciones de la presente invencion.

50 La fig. 4 es un diagrama que ilustra un procedimiento de determination de permisos aplicables para un paquete.

La fig. 5 es un diagrama de bloques que ilustra una matriz de permisos segun realizaciones de la presente invencion.

La fig. 6A es un diagrama de bloques que ilustra un ejemplo de encadenamiento de la matriz de permisos segun realizaciones de la presente invencion.

55 La fig. 6B es un diagrama de bloques que ilustra otro ejemplo de encadenamiento de la matriz de permisos segun realizaciones de la presente invencion.

La fig. 6C es un diagrama de bloques que ilustra una vista logica de los ejemplos de encadenamiento de la matriz de permisos representados en las figs. 6A y 6B segun realizaciones de la presente invencion.

La fig. 7 es un diagrama de bloques que ilustra un ejemplo de una lista de control de acceso (ACL) segun

realizaciones de la presente invencion.

La fig. 8A es un diagrama de bloques que ilustra un ejemplo de subred del lado del anfitrion segun realizaciones de la presente invencion.

La fig. 8B es un diagrama de flujo que ilustra un ejemplo del funcionamiento de la subred del lado del anfitrion 5 mostrada en la fig. 8A, de una manera segun realizaciones de la presente invencion.

La fig. 9A es un diagrama de bloques que ilustra un ejemplo de una subred del lado del servidor segun realizaciones de la presente invencion.

La fig. 9B es un diagrama de flujo que ilustra un ejemplo del funcionamiento de la subred del lado del servidor mostrada en la fig. 9A, de una manera segun realizaciones de la presente invencion.

10 La fig. 10 es un diagrama de bloques que ilustra un ejemplo de una arquitectura de red que incluye un anfitrion y un servidor, segun realizaciones de la presente invencion.

La fig. 11 es un diagrama de flujo que ilustra un ejemplo de un recorrido de paquetes a traves de la arquitectura de red mostrada en la fig. 10 y el procesamiento realizado sobre los mismos segun realizaciones de la presente invencion.

15 La fig. 12 es un diagrama de flujo que ilustra un ejemplo del procesamiento realizado sobre un paquete sometido a procesamiento de control de acceso basado en roles (RBAC) segun realizaciones de la presente invencion, donde el paquete es primer paquete recibido de tales paquetes.

La fig. 13 es un diagrama de flujo que ilustra un ejemplo del procesamiento realizado sobre un paquete recibido posteriormente sometido a procesamiento de control de acceso basado en roles (RBAC) segun realizaciones de la 20 presente invencion.

La fig. 14 es un diagrama de flujo que ilustra un ejemplo del procesamiento de un paquete a medida que el paquete circula a traves de trayecto de datos de un dispositivo de red segun realizaciones de la presente invencion.

[0014] El uso de los mismos slmbolos de referencia en diferentes dibujos indica elementos similares o identicos.

25

DESCRIPCION DETALLADA DE LA INVENCION

[0015] Lo siguiente pretende proporcionar una descripcion detallada de un ejemplo de la invencion y no deberla considerarse como limitativo de la propia invencion. Mas bien, cualquier numero de variaciones puede entrar dentro

30 del alcance de la invencion, el cual esta definido en las reivindicaciones a continuacion de la descripcion.

Introduccion

[0016] La presente invencion proporciona un procedimiento y aparato que aborda las limitaciones resumidas 35 anteriormente mediante el uso de listas de control de acceso basado en roles (RBACL), que estan disenadas para

abordar directamente tales problemas. El acceso a la red permitido a un usuario (por ejemplo, una persona que tiene un identificador de usuario, un servidor, un telefono de protocolo Internet (IP), y otros de tales dispositivos de red) esta basado convencionalmente en el (los) grupo(s) al cual (los cuales) pertenece el usuario, el (los) rol(es) asignado(s) al usuario por la empresa, el (los) privilegio(s) que tiene el usuario como cliente ISP o criterios similares. 40 Se apreciara que tal usuario puede, de hecho, ser una persona que tenga un identificador de usuario, un dispositivo de red, un dispositivo de telecomunicaciones o algun otro dispositivo o entidad identificable con una necesidad de acceso a una red de comunicaciones. Las RBACL controlan el trafico de red imponiendo los permisos que han de aplicarse a ese trafico de red, basandose en el (los) rol(es) del usuario que genera el trafico de red.

45 [0017] Un procedimiento y aparato segun la presente invencion representan los roles del usuario utilizando grupos. A un usuario se le confiere la pertenencia a uno o mas grupos basandose en los roles de ese usuario. Cada grupo puede representar uno o mas roles. A su vez, se aplican listas de permisos al decidir si permitir la comunicacion entre grupos. El grupo de un usuario, por ejemplo, cuando la entidad de red (por ejemplo, un usuario) es autenticado (por ejemplo, como parte de la autenticacion de usuario por medio del protocolo 802.1X, u otro de tales 50 mecanismos). Asl, cuando la entidad se autentifica, la entidad es ubicada dentro de un “grupo de usuario” (UG). La autenticacion puede estar basada en la identificacion del usuario, la funcion del servidor en la red, u otra de tales caracterlsticas.

[0018] Esta informacion puede utilizarse entonces para efectuar una determinacion en cuanto al tratamiento de un 55 paquete originado por la entidad. Por ejemplo, cuando un paquete es originado sobre la red, la informacion respecto al grupo fuente se inserta dentro del paquete. La comunicacion de esta informacion (tambien denominada indicador en este documento) puede implementarse de varias maneras. Por ejemplo, la informacion puede implementarse como un indicador de grupo fuente (un indicador que indica el grupo al cual pertenece la fuente), aunque pueden emplearse otros procedimientos.

[0019] A medida que el paquete recorre la red, la informacion del grupo fuente es transportada junto con otra information en el paquete. En el borde de egreso de la red, puede obtenerse el grupo de destino. Por ejemplo, en el borde “L3” (el dispositivo de red en el borde de la red de capa 3), el grupo de destino puede obtenerse de la base de

5 informacion de reenvlo (FIB) del dispositivo de red por medio del prefijo de anfitrion totalmente resuelto. El prefijo de anfitrion se resuelve mediante el protocolo de resolution de direcciones (ARP). La respuesta del ARP es marcada con el grupo de destino cuando el paquete es originado sobre la red. El resultado de la FIB es poblado con el grupo de destino ademas de la informacion de reescritura. Una vez que se han determinado los grupos fuente y de destino, pueden aplicarse los permisos (ACL) utilizando esta informacion.

10

[0020] Las ventajas clave de la presente invention incluyen la reduction multiplicativa del tamano de las ACL, el incremento multiplicativo en el rendimiento de las ACL por software, el desacoplamiento de la topologla de la red y las pollticas de seguridad (u otras caracterlsticas) (que permiten a la ACL seguir al usuario a medida que el usuario se desplaza por la empresa), y una gestion de red simplificada.

15

La implementacion de roles en una arquitectura de autenticacion

[0021] La fig. 1A es un diagrama que ilustra un grupo jerarquico de usuarios segun realizaciones de la presente invencion. Los grupos jerarquicos de usuarios (UG) son similares a las jerarqulas de clases encontradas en la

20 programacion orientada a objetos. Cada grupo vastago hereda los permisos de su grupo progenitor y amplla esos permisos con los suyos. Se representa una jerarqula de grupos de usuarios 100 que incluye varios grupos de usuarios, cada uno de los cuales tiene dependencias sobre otros grupos de usuarios. La jerarqula de grupos de usuarios 100 incluye un grupo de todos los usuarios 110, un grupo de empleados 120, un grupo de consultores 130, un grupo de directores 140 y un grupo de ejecutivos 150. Como puede verse en la fig. 1A, estos grupos estan

25 relacionados jerarquicamente entre si, con el grupo de ejecutivos 150 siendo un subconjunto del grupo de directores 140, el grupo de directores 140 siendo subconjunto del grupo de empleados 120, y el grupo de empleados 120 y el grupo de consultores 130 siendo subconjuntos del grupo de todos los usuarios 110. De esta manera, el acceso a diversos recursos puede limitarse basandose en el (los) grupo(s) al cual (los cuales) pertenece el usuario. Por ejemplo, un usuario puede pertenecer al grupo de directores 140. Tlpicamente, un usuario del grupo de directores

30 140 tendra acceso a mas recursos informaticos y de informacion de la organization que lo tendra un usuario del grupo de empleados 120, y menos de tal acceso que un usuario del grupo de ejecutivos 150. Como resultara evidente, cuanto mas se recorra hacia abajo en la jerarqula de grupos de usuarios 100, mayor es el nivel de responsabilidad, y por eso, mayor es la cantidad de acceso.

35 [0022] La fig. 1B es un diagrama que ilustra un conjunto disjunto de grupos de usuarios segun realizaciones de la presente invencion. Los grupos de usuarios disjuntos se utilizan donde existen funciones no superpuestas, iguales y no relacionadas. En la implementacion real de RBACL, los UG jerarquicos pueden implementarse utilizando UG disjuntos y la gestion de jerarqula (de haberla) puede hacerse la responsabilidad de la entidad de gestion de red responsable de configurar las RBACL. Estos grupos incluyen un grupo de ingenierla 160, un grupo de ventas 170 y

40 un grupo de marketing 180. Tales grupos de usuarios disjuntos se utilizan donde existen funciones no superpuestas, iguales y no relacionadas realizadas por los grupos en cuestion. Como las responsabilidades de cada uno de estos grupos son tan diferentes y distintas de las de los otros grupos, se esperarla que cada uno de estos grupos tuviera su propio conjunto de recursos, accesible por los miembros del grupo dado. Asl, se esperarla que los usuarios de un grupo dado mantendrlan el mismo conjunto de permisos, permitiendoles acceder al mismo conjunto de recursos,

45 aunque esto no tiene que ser estrictamente el caso.

[0023] Se apreciara que los grupos de usuarios se meten en el mismo grupo porque comparten los mismos permisos. Esta creation de grupos no implica que no se produzcan comunicaciones entre o a traves de grupos de usuarios. Ni esto implica que no existe imposition de permisos dentro de un grupo dado. Simplemente implica que

50 como grupo, los usuarios tendran los mismos privilegios dentro de la red.

[0024] Cabe destacar que la implementacion de control de acceso basado en roles presenta problemas especiales en un entorno de red. Debido a la naturaleza bidireccional de las comunicaciones de red, el control de acceso tiene que aplicarse tanto entre el usuario (anfitrion) y el objeto (servidor), como entre el objeto (servidor) y el usuario

55 (anfitrion). Esto requiere que los usuarios esten agrupados entre si dentro de un rol y, igualmente, los objetos tambien esten agrupados entre si en un rol. En este punto, el control de acceso se aplica estrictamente entre los grupos. Con tal desacoplamiento, los dispositivos de red son libres de desplazarse a traves de la red, y cambiar las direcciones IP. Todas las topologlas de red pueden cambiar sin perturbar las pollticas de seguridad implementadas por las RBACL existentes. Siempre que los roles y los permisos sigan siendo los mismos, tales cambios pueden

producirse sin afectar a la polltica de seguridad implantada. Desde el punto de vista de cualquier paquete dado, el paquete simplemente es originado desde un grupo, destinado para otro grupo, donde los dos grupos pueden o pueden no ser diferentes. La cuestion respondida mediante el uso de RBACL es si, basandose en el grupo fuente y de destino, es admisible el transporte del paquete.

5

[0025] La implementacion de RBACL incluye tlpicamente varias operaciones. Estas operaciones incluyen

1. La determinacion del grupo de usuarios fuente (SUG; o usuario)

2. La determinacion del grupo de usuarios de destino (DUG; u objeto)

10 3. La determinacion de permisos

4. La imposicion de permisos

[0026] La fig. 2 es un diagrama de bloques que ilustra una arquitectura para autenticacion de usuario. La determinacion de SUG puede efectuarse, por ejemplo, cuando el usuario es autentificado en la red. Los siguientes

15 ejemplos pueden utilizar, por ejemplo, el protocolo de servidor de autenticacion remota telefonica de usuario

(RADIUS), que proporciona autenticacion, autorizacion y contabilidad centralizadas para diversos tipos de acceso.

La autenticacion de usuario es iniciada por un usuario, quien intenta iniciar sesion en un anfitrion 200. El usuario (no mostrado) hace que el anfitrion 200 actue como suplicante, y por tanto, envle un mensaje de inicio a un servidor 210 (tambien denominado autenticador). El servidor 210 responde al anfitrion 200 con un mensaje de 20 peticion/identificacion, al cual el anfitrion 200 responde con un mensaje de respuesta/identidad, basandose en la respuesta del usuario. Este mensaje de respuesta/identidad puede ser, por ejemplo, la tlpica combinacion de nombre de usuario y contrasena. El servidor 210 pasa esta informacion a un servidor de autenticacion 220.

[0027] El servidor de autenticacion 220 responde con una puesta a prueba de acceso. Se observara que se

25 produce una diversidad de intercambios entre el servidor 210 y el servidor de autenticacion 220 durante la

autenticacion, y que estos se supone que son meramente ejemplares. Tales intercambios variaran, dependiendo del protocolo de autenticacion empleado. Una vez que el intercambio de puesta a prueba de acceso se ha completado, el servidor 210 interactua con el anfitrion 200 reenviando la puesta a prueba desde el servidor de autenticacion 220 al anfitrion 200. El anfitrion 200, en este ejemplo, responde con una contrasena de un solo uso (OTP), que el 30 servidor 210 reenvla al servidor de autenticacion 220. Suponiendo que la contrasena es aceptada por el servidor de autenticacion 220, el servidor de autenticacion 220 responde con un mensaje de aceptacion de acceso que hace que el servidor 210 autorice una direccion de red para el anfitrion 200.

[0028] Las realizaciones de la presente invencion conflan en este procedimiento de autenticacion para permitir la 35 diseminacion de informacion de grupo de usuarios. La presente invencion puede emplear un procedimiento de

autenticacion tal que presentado en relacion con la fig. 2 proporcione la capacidad de transportar la pertenencia de grupo del usuario desde el servidor de autenticacion 220 a un dispositivo de acceso a red de ingreso. En el protocolo RADIUS, un atributo especlfico del proveedor que contiene el grupo de usuarios que ha de pasarse al servidor 210 (y, en ultima instancia, al conmutador de ingreso) usa la respuesta de aceptacion de acceso RADIUS. Asl, la 40 determinacion del grupo de usuarios fuente se efectua cuando el usuario es autenticado en la red. Alternativamente, si el sistema operativo del anfitrion es de confianza, el grupo de usuarios puede proceder del propio anfitrion. Si tal es el caso, cada aplicacion puede marcar un paquete dado de manera diferente, basandose en la aplicacion que origina el paquete.

45 [0029] Se observara que, en la especificacion IEEE 802.1X original, todo el puerto es autenticado cuando se efectua una sola autenticacion valida en el puerto. Despues de ello, cualquier anfitrion unido a ese puerto se considera autenticado. De la misma manera, el procedimiento mas simple de obtencion del indicador de grupo fuente (SGT) es marcar todo el puerto como autentificado en el momento de la primera autenticacion valida. El identificador de grupo proporcionado por la autenticacion inicial entonces se utiliza e instala en el puerto de ingreso. 50

[0030] La fig. 3 es un diagrama de bloques que ilustra una tabla de reenvlo 300 segun la presente invencion. La tabla de reenvlo 300 incluye varias entradas de tabla de reenvlo (representadas en la fig. 3 como las entradas de tabla de reenvlo 310(1)-(N)). Cada una de las entradas de tabla de reenvlo 310(1)-(N) incluye varios campos, de los cuales se representan ciertos en la fig. 3. Entre estos campos estan un campo de direccion MAC (representado 55 como los campos de direccion MAC 320(1)-(N)), un campo de identificador de red de area local virtual (VLAN) (representado como los campos de identificador VLAN 330(1)-(N)), un campo de identificador de puerto (representado como los campos de identificador de puerto 340(1)-(N)), y un campo de identificador de grupo de usuarios (indicador) (representado como los campos de identificador de grupo de usuarios 350(1)-(N)).

[0031] Cuando la direccion del control de acceso a los medios (MAC) y la VLAN han sido autentificadas en un puerto dado, el grupo de usuarios recuperado mediante la autenticacion RADIUS es asignado a la combination de direccion MAC/identificador VLAN. Esta information aparece en la tabla de reenvlo 300 en los campos de direccion MAC 320(1)-(N) y los campos de identificador VLAN 330(1)-(N). La tabla de reenvlo 300 contiene as! las

5 combinaciones de direccion MAC/identificador VLAN que pueden utilizarse como clave de busqueda con el resultado de la busqueda que proporciona el identificador de puerto (tal como esta almacenado en el campo apropiado de los campos de identificador de puerto 340(1)-(N)) y el identificador de grupo de usuarios (tal como esta almacenado en un campo correspondiente de los campos de identificador de grupo de usuarios (350(1)-(N)). La entrada particular de las entradas de tabla de reenvlo 310(1 )-(N) es preferentemente estatica en el conmutador de ingreso, y en tal 10 caso, la elimination deberla ser activada por el protocolo de autenticacion empleado, y no los criterios de antiguedad que se emplean tlpicamente con las entradas de tabla de reenvlo.

[0032] Se observara que, en una implementation, cuando un paquete es enviado por un anfitrion tal como el anfitrion 200, la busqueda de aprendizaje de capa 2 (proporcionada como parte de la funcion de aparejo en el

15 conmutador de red que mantiene la tabla de reenvlo 300) tambien obtiene el identificador de grupo de usuarios para el paquete buscando el contenido del paquete en la tabla de reenvlo. Alternativamente, la busqueda de aprendizaje de capa 2 del conmutador puede estar disenada para extraer el identificador de grupo de usuarios del propio paquete. Este identificador de grupo de usuarios se utiliza para marcar el paquete para su identification como que ha sido generado por un usuario del grupo de usuarios dado. Tal indicador se denomina en este documento el 20 indicador de grupo fuente (SGT). Este STG se inserta dentro del paquete para su uso en el procesamiento subsiguiente del paquete. Por ejemplo, el SGT puede ser insertado dentro del encabezamiento de la capa 2, haciendo que tal informacion este disponible para encaminadores de capa 3, as! como conmutadores de capa 2.

[0033] Se observara que el identificador de variable “N” se utiliza en varios ejemplos en las figuras descritas en 25 este documento para designar de manera mas simple el elemento final de una serie de elementos relacionados o

similares. El uso repetido de tales identificadores de variable no significa que implica necesariamente una correlacion entre los tamanos de tales series de elementos, aunque tal correlacion puede existir. El uso de tales identificadores de variable no requiere que cada serie de elementos tenga el mismo numero de elementos que otra serie delimitada por el mismo identificador de variable. En cambio, en cada ejemplo de uso, la variable identificada 30 por “N” (o cualquier otro de tales identificadores) puede contener el mismo valor o un valor diferente de otros ejemplos del mismo identificador de variable.

[0034] Por otra parte, respecto a las senales descritas en este documento, los expertos en la materia reconoceran que una senal puede ser transmitida directamente desde un primer bloque hasta un segundo bloque, o una senal

35 puede ser modificada (por ejemplo, amplificada, atenuada, retardada, enclavada, almacenada en memoria intermedia, invertida, filtrada o modificada de otro modo) entre los bloques. Aunque las senales de la realizacion descrita anteriormente estan caracterizadas como transmitidas desde un bloque hasta el siguiente, otras realizaciones de la presente invencion pueden incluir senales modificadas en lugar de tales senales transmitidas directamente siempre que el aspecto de informacion y/o funcional de la senal sea transmitido entre bloques. Hasta 40 cierto punto, una entrada de senal en un segundo bloque puede ser conceptualizada como una segunda senal obtenida de una primera senal producida como salida de un primer bloque debido a las limitaciones flsicas de los circuitos implicados (por ejemplo, inevitablemente existira algo de atenuacion y retardo). Por lo tanto, tal como se utiliza en este documento, una segunda senal obtenida de una primera senal incluye la primera senal o cualquier modification en la primera senal, ya sea debido a las limitaciones del circuito o debido al paso a traves de otros 45 elementos del circuito que no cambian el aspecto de informacion y/o funcional final de la primera senal.

[0035] Antes de que pueda aplicarse la RBACL apropiada, tambien se efectua una determination en cuanto al grupo de usuarios de destino. Aunque pueden utilizarse varios mecanismos para efectuar tal determinacion, ahora se analizan dos maneras de determinar el DUG del objeto (servidor). Tal como se apreciara, cada una tiene sus

50 propias ventajas en ciertos escenarios.

[0036] El primer mecanismo para determinar el DUG emplea informacion en la base de informacion de reenvlo (FIB) proporcionada durante la resolution de direccion por el protocolo de resolution de direcciones (ARP) (es decir, la IP FIB). Para la mayorla de los casos que implican trafico de red utilizando IP, el grupo de usuarios de destino

55 puede obtenerse de la FIB. En el borde de la capa 3 (L3) de la red de egreso de la red, la FIB estara poblada con el prefijo de red resuelto despues de realizarse la resolucion del ARP. Puesto que la respuesta del ARP es el activador para la actualization de entrada de FIB y tiene que ser recibida antes de que circule cualquier trafico al anfitrion, la respuesta del ARP se utiliza como el activador para insertar el grupo de usuarios de destino dentro de la entrada de la FIB.

[0037] El procedimiento exacto de obtencion del grupo de usuarios de destino depende de la plataforma y la conectividad de red al anfitrion. Lo siguiente son los tres escenarios posibles diferentes para obtener el grupo de usuarios de destino.

5

[0038] En el primer escenario, el anfitrion es autentificado directamente con el encaminador. En este caso, el anfitrion esta conectado directamente a un encaminador tradicional (uno sin conmutacion de capa 2 (L2) de red). Cuando se recibe la respuesta del ARP, se interrogara a la base de datos de autenticacion local para recuperar el grupo de usuarios correspondiente para la direccion IP de destino. Si no se encuentra ninguna entrada en la base de

10 datos de autenticacion local, se asignara un grupo de usuarios de destino por defecto.

[0039] En el segundo escenario, el anfitrion es autentificado directamente con el conmutador de capa 2 (L2) de red conectado directamente. Cuando el anfitrion es autentificado con el conmutador de L2 conectado directamente, el encaminador puede estar a multiples saltos dentro de la capa 2 de red. Cuando la respuesta del ARP es recibida por

15 el conmutador de borde conectado directamente al anfitrion, el paquete es marcado con el SGT mediante uno de los mecanismos descritos previamente. Cuando la respuesta del aRp es recibida por el encaminador que activo la peticion del ARP, el grupo de usuarios de destino se tomara del propio paquete.

[0040] En el tercer escenario, el anfitrion es autentificado directamente con el conmutador de capa 3 (L3) de red. 20 En este caso, el anfitrion esta conectado directamente al conmutador de L3 que proporciona la autenticacion y la

interfaz de L3 de borde para el anfitrion. Se observara que el termino “conmutador de L3” se refiere a un encaminador con la funcionalidad adicional de un conmutador de L2. Cuando llega la respuesta del ARP procedente del anfitrion, el paquete es marcado con el SGT procedente de la capa de control de acceso a los medios (MAC), la busqueda de aprendizaje de VLAN en la tabla de L2. De esta manera, el conmutador de L3 puede ver este caso 25 como el mismo que el escenario previo.

[0041] Alternativamente, el grupo de usuarios de destino puede determinarse por medio de una ACL de ingreso estatico. Tal como se apreciara, cuando se conecta una red habilitada para RBACL a una red no habilitada para RBACL, la infraestructura de autenticacion no estara presente en la red no habilitada para RBACL. De manera

30 similar a la asignacion del grupo de usuarios fuente descrita previamente, el grupo de usuarios de destino tiene que clasificarse por medio del mismo mecanismo en tales situaciones. Utilizando la ACL de ingreso para proporcionar la clasificacion del grupo de usuarios de destino, las direcciones IP/subredes de destino pueden indicar el grupo de usuarios de destino para determinar la RBACL correcta que se ha de aplicar. Se observara que tambien puede utilizarse la ACL de egreso, siempre que la determinacion de DUG se produzca antes de la imposition de RBACL. 35 Se apreciara que, no infrecuentemente, es mejor comprobar utilizando una ACL de egreso.

[0042] La fig. 4 es un diagrama que ilustra un procedimiento de determinacion de permisos aplicables para un paquete dado, utilizando las operaciones analizadas anteriormente. El grupo de usuarios fuente del paquete (representado en la fig. 4 como un grupo de usuarios fuente (SUG) 400) y el grupo de usuarios de destino

40 (representado como un grupo de usuarios de destino (DUG) 410) se toman como entradas a un procedimiento de determinacion de permisos (representado como una determinacion de permisos 420). Asl, el SUG y el DUG son as! entradas al procedimiento de determinacion de que permisos aplicar, tal como se ha descrito. La determinacion de permisos 420 empleara tlpicamente una lista de permisos. La determinacion de la lista de permisos se realiza mediante la utilization de una matriz de control de acceso que es, en ciertas realizaciones, una matriz indexada por 45 los grupos fuente y de destino con el fin de proporcionar una lista de permisos permitidos. En el caso aqul planteado, el grupo de usuarios fuente y el grupo de usuarios de destino se emplean para efectuar esta determinacion. Los resultados de la determinacion de permisos 420 son comprobados luego en una comprobacion de RBACL 430. Asl, el SUG y el DUG se utilizan para determinar la RBACL (lista de permisos) que se aplica.

50 Un ejemplo de una arquitectura de permisos basada en software

[0043] La fig. 5 es un diagrama de bloques que ilustra una matriz de permisos 500 y una lista de permisos 510, segun la presente invention. Cada una de las entradas en la matriz de permisos 500 (representadas como entradas de la matriz de permisos 520(1,1)-(N,N)) apunta a una de las entradas en la lista de permisos 510 (representadas

55 como entradas de la lista de permisos 530 (1)-(N)). Cada una de las entradas de la matriz de permisos (PME) 520(1,1)-(N,N) es indexada por uno de un numero de identificadores de grupo de usuarios fuente 540(1)-(N) y uno de un numero de identificadores de grupo de usuarios de destino 550(1)-(N). Como resultara evidente, cada uno de los identificadores de grupo de usuarios fuente 540(1)-(N) corresponde a una fila en la matriz de permisos 500, mientras que cada uno de los identificadores de grupo de usuarios de destino 550(1)-(N) corresponde a una

columna en la matriz de permisos 500. Cada una de las entradas de la lista de permisos 530(1)-(N) proporciona una lista de permisos en cuanto a las clases de trafico de red que estan permitidas entre el grupo de usuarios fuente y el grupo de usuarios de destino. Por ejemplo, dado un identificador de grupo de usuarios fuente de cuatro (4) y un identificador de grupo de usuarios de destino de tres (3), se identifica la PME 520(4,3). La PME 520(4,3) incluye un 5 puntero a la entrada de la lista de permisos 530(5). La entrada de la lista de permisos 530(5) podrla contener una lista de permisos tal como la siguiente:

permit tcp www permit tcp telnet

10 permit tcp ftp permit tcp ftp-data implicit deny

[0044] Tal como se apunto, estos permisos son tlpicamente muy pocos en comparacion con las ACL tradicionales.

15 Esto es porque tales permisos no se aplican a todo el trafico de red que pasa por una interfaz dada, sino solo al trafico entre dos grupos de usuarios especlficos. Por ejemplo, la especificacion de los tipos de trafico de entrada permitidos desde Internet (la interfaz ACL) ya no es necesaria - solo tienen que especificarse (en la lista de permisos RBACL) los tipos de trafico permitidos que entran de Internet a ciertos servidores.

20 [0045] Tlpicamente, la matriz de permisos estara poblada muy escasamente. Sin embargo, existe un escenario en el que una columna o fila particular de la matriz puede estar totalmente poblada. Si vemos la polltica de seguridad como una lista de conjuntos de permisos entre grupos fuente y de destino, la polltica de seguridad puede definirse como:

Tabla 1. Ejemplo de matriz de permisos.

SUG1

DUG4 ListaDePermisosA

SUG2

DUG5 ListaDePermisosB

SUG3

DUG6 ListaDePermisosC

25

[0046] La fig. 6A es un diagrama de bloques que ilustra un ejemplo de encadenamiento de matrices de permisos segun la presente invencion. En este escenario, el puntero que se selecciona en la matriz de permisos 500 apunta a una de varias listas de permisos (representadas en la fig. 6A como una lista de permisos 600, una lista de permisos 610 y una lista de permisos 620), que, a su vez, apuntan unas a otras y se terminan por un permiso de denegacion

30 impllcita (representado como la denegacion impllcita 630 en la fig. 6A). En la tabla 1 anterior se da un ejemplo de listas de permisos 600, 610 y 620.

[0047] Asl, como puede verse, la lista de permisos 620 se construye sobre los permisos enumerados en la lista de permisos 610, que a su vez, se construye sobre la lista de permisos enumerada en la lista de permisos 600. Como

35 con una lista de permisos tlpica, la lista se termina por una denegacion impllcita, que indica que, a menos que se permita especlficamente de otro modo, no se conceden permisos.

[0048] De la manera representada en la fig. 6A, puede crearse una lista de permisos para cada una de las entradas en la matriz de permisos 500 simplemente combinando listas de permisos (por ejemplo las listas de 40 permisos 600, 610 y 620, asl como otras de tales listas de permisos) para llegar al conjunto deseado de permisos para la combinacion de grupo de usuarios fuente y grupo de usuarios de destino representada por la entrada en la matriz de permisos 500 que apunta al grupo dado de listas de permisos.

45

50

[0049] Una caracterlstica deseable es permitir que un administrador de seguridad de la red especifique una lista de permisos para cualquier grupo fuente que se comunique con un grupo de destino especlfico o viceversa. Si un identificador de grupo es un unico identificador ninguna semantica codificada en el valor, proporcionar enmascaramiento variable del identificador de grupo sirve de poco. Sin embargo, enmascarar el identificador de grupo entero aborda la necesidad anterior. Esto conduce a las 4 posibles formas de especificar una asignacion de lista de permisos.

SUGx

CUALQUIERA

SUGx

CUALQUIERA

DUGy

DUGy

CUALQUIERA

CUALQUIERA

ListaDePermisos1

ListaDePermisos2

ListaDePermisos3

ListaDePermisos4

[0050] Se observara que la forma final (CUALQUIERA a CUALQUIERA) rellenara toda la matriz con la ACL

ListaDePermisos4. Tal configuracion puede conducir a que un paquete dado necesite potencialmente que se apliquen multiples listas de permisos. Conceptualmente, la matriz apunta a una cadena de listas de permisos (como en las figs. 6A y 6B), donde cada una es recorrida en orden. Tal como se representa, cada lista de permisos se termina con un continuar impllcito, y la denegacion impllcita se aplica al final de la cadena.

5

[0051] De hecho, las estructuras de punteros que soportan tales combinaciones pueden estar separadas de las propias listas de permisos, simplificando las estructuras de punteros y reduciendo la duplicacion de la informacion de permisos. Tal estrategia se analiza mas adelante en relacion con la fig. 6B.

10 [0052] La fig. 6B es un diagrama de bloques que ilustra un ejemplo de un conjunto de listas de permisos que emplean un conjunto separado de estructuras de punteros (denominado encadenamiento) con el fin de simplificar el conjunto de estructuras de listas de permisos necesarias para soportar la presente invencion. Como antes, una entrada en la matriz de permisos 500 es un puntero al conjunto deseado de listas de permisos. Sin embargo, a diferencia de las estructuras mostradas en la fig. 6A, la entrada dada en la matriz de permisos 500 apunta a uno de 15 varios bloques de punteros (representados en la fig. 6B como los bloques de punteros 650, 655 y 660). Como puede verse, el bloque de punteros 650 apunta tanto a una lista de permisos 665 como al bloque de punteros 655. De modo similar, el bloque de punteros 655 apunta a una lista de permisos 670, as! como al bloque de punteros 660. Igualmente, el bloque de punteros 660 apunta a una lista de permisos 675, pero, en cambio, tambien apunta a una denegacion impllcita 680, que termina la cadena de punteros. Resultara evidente que pueden crearse estructuras 20 complejas utilizando esta estrategia, permitiendo a un usuario hacer un uso diferente de las listas de permisos mediante el uso acertado de punteros.

[0053] En la arquitectura representada en la fig. 6B, cada una de las entradas de la matriz de permisos 500 apunta a un bloque de punteros, tal como el bloque de punteros 650. El bloque de punteros 650 apunta tanto a una lista de

25 permisos (por ejemplo, la lista de permisos 665) como a otro bloque de punteros cualquiera (por ejemplo, el bloque de punteros 655) o una denegacion impllcita (por ejemplo, la denegacion impllcita 680). Asl, cada lista de permisos (por ejemplo, las listas de permisos 665, 670 y 675) estan disponibles para uno cualquiera de los bloques de punteros que constituye la lista de permisos global implementada en ultima instancia para una entrada dada en la matriz de permisos 500. Tal arquitectura permite el uso eficiente de listas de permisos requiriendo solo una de tales 30 listas de permisos para cualquier tipo de permiso que pudiera implementarse. Asl, para cada conjunto de permisos, el sistema simplemente implementa un conjunto de bloques de punteros y hace que los punteros de la lista de permisos de esos bloques de punteros apunten a las listas de permisos necesarias para implementar el conjunto deseado de permisos. Puesto que cada uno de estos permisos puede reutilizarse cualquier numero de veces, el espacio consumido por tal implementacion es significativamente inferior al que pudiera ser si no.

35

[0054] La fig. 6C es un diagrama de bloques que ilustra una vista logica de los ejemplos de encadenamiento de la matriz de permisos representada en la fig. 6A y la 6B segun la presente invencion. Tal como se apunto en ambos ejemplos, la entrada dada de la matriz de permisos 500 apunta al primero de varias listas de permisos (representadas en la fig. 6C como las listas de permisos 690, 692 y 694), que se terminan por una denegacion

40 impllcita 696, de la manera analizada anteriormente.

[0055] Asl, en una implementacion basada en software, puede emplearse una estructura basada en arbol, basada en troceo, u otra de tales estructuras de busqueda, siendo la busqueda una concordancia en la concatenacion de los grupos de usuarios fuente y de destino. El resultado de la busqueda es un puntero a una cadena de ACL. Estas ACL

45 son recorridas en el orden en que estan presentes en la cadena. Las ACL se ven logicamente como una sola ACL encadenada.

[0056] En muchas implementaciones de ACL, tlpicamente se emplean dos estrategias. Una estrategia es el modelo basado en procesador de red (software). Este tipo de implementacion es similar a la implementacion por

50 software y puede beneficiarse de esa estrategia. La otra estrategia es usar una solucion basada en CAM. La siguiente seccion se centra en la implementacion basada en CAM.

Un ejemplo de una arquitectura de permisos basada en hardware implementada usando listas de control de acceso basadas en roles

55

[0057] Una implementacion basada en CAM proporciona la ventaja de una busqueda paralela y la capacidad de enmascarar campos. La busqueda paralela proporciona un rendimiento elevado, predecible y consistente. Por desgracia, una sola busqueda crea una enorme cantidad de complejidad para la programacion del software del dispositivo, porque la implementacion tlpica supone procesamiento secuencial.

[0058] Si el numero de grupos soportados por una plataforma es pequeno (por ejemplo, inferior a 256), una implementacion ASIC de la matriz de permisos puede ser viable usando la memoria en chip. En tal escenario, la salida de la matriz proporciona una etiqueta (por ejemplo, una etiqueta de flujo) que puede utilizarse entonces para

5 realizar una busqueda de CAM de manera similar a la de las implementaciones de ACL basadas en CAM tradicionales.

[0059] El caso probable, sin embargo, es que el numero de grupos que han de ser soportados sera mucho mayor, haciendo inviable una implementacion en chip. La determinacion de permisos y la imposition de permisos se

10 implementan as! tlpicamente junto con la propia busqueda de CAM. Utilizando una sola etiqueta de flujo para la busqueda de RBACl, los grupos fuente y destino pueden situarse en la especificacion de flujo de CAM en el lugar de las direcciones de red fuente y destino (por ejemplo, direcciones IP).

[0060] La fig. 7 es un diagrama de bloques que ilustra un ejemplo de una lista de control de acceso (ACL) segun la 15 presente invention, y representada como la lista de control de acceso 700. La lista de control de acceso 700 incluye

varias entradas (denominadas entradas de lista de control de acceso o ACE), que estan representadas en la fig. 7 como las entradas de lista de control de acceso 710(1)-(N). Cada una de las ACE 710(1)-(N) incluye, por ejemplo, una etiqueta de flujo (representada en la fig. 7 como los campos de etiqueta de flujo 720(1)-(N)), un identificador de grupo de usuarios fuente (SUG) (representado en la fig. 7 como los campos de SUG 730(1)-(N)), un identificador de 20 grupo de usuarios de destino (DUG) (representado en la fig. 7 como los campos de DUG 740(1)-(N)), y otras especificaciones de flujo (representadas en la fig. 7 como otros campos de especificacion de flujo 750(A)-(N)). Como es sabido, una ACL tal como la ACL 700 puede implementarse utilizando una memoria direccionable segun el contenido (CAM), y mas especlficamente, una CAM ternaria (TCAM), permitiendo de ese modo la busqueda rapida y eficiente de information. Se proporciona una etiqueta de flujo opcional (tambien denominada etiqueta ACL, 25 mantenida en un campo apropiado de los campos de etiqueta de flujo 720(1)-N)) para distinguir las RBACL de las ACL de interfaz tradicional en el mismo dispositivo. Un dispositivo que emplee solo RbACL no necesitarla tal campo.

Una red de ejemplo que emplea RBACL y el funcionamiento de la misma

30 [0061] La fig. 8A es un diagrama de bloques que ilustra un ejemplo de una arquitectura de subred del lado del anfitrion y autenticacion segun la presente invencion. En esta arquitectura, un anfitrion 800 se comunica con una subred 810 por medio de un conmutador 820. Un usuario que inicia sesion en el anfitrion 800 es autentificado por un servidor de autenticacion 830 por medio del conmutador 820, de la manera representada y analizada en relation con la fig. 2. Asl, por ejemplo, un usuario inicia sesion en el anfitrion 800 y es autentificado por el servidor de 35 autenticacion 830 por medio del conmutador 820. Durante esta autenticacion, el grupo de usuarios del usuario es identificado y asignado al usuario como un indicador de grupo fuente (SGT), que corresponde al rol del usuario (por ejemplo, ingenierla, direction, marketing, ventas o similares).

[0062] Mas especlficamente, un usuario podrla estar en un rol de ingenierla. El anfitrion 800 inicia la autenticacion 40 (por ejemplo, por medio del protocolo IEEE 802.1X). Bajo el protocolo RADIUS, el servidor de autenticacion 830 pone a prueba al usuario para una combination de identification de usuario y contrasena. En el momento de una autenticacion exitosa, la aceptacion de acceso RADIUS asigna al usuario un SGT de 5, que corresponde al rol de ingenierla.

45 [0063] La MAC, la VLAN del ordenador del usuario (anfitrion 800) se inserta en la tabla L2 y se marca como una direccion MAC segura. La tabla 2 ilustra la tabla de capa 2 despues de ser poblada con esta informacion.

Tabla 2. Ejemplo de tabla de capa 2

MAC

Identificador de VLAN Puerto Grupo de usuarios

1234.ABCD.1234

4 PortAI 5

50 [0064] La fig. 8B es un diagrama de flujo que ilustra un ejemplo del funcionamiento de la subred del lado del anfitrion mostrada en la fig. 8A. El procedimiento comienza con el anfitrion 800 iniciando el procedimiento de autenticacion (etapa 850). A continuation, se emite una puesta a prueba desde el servidor de autenticacion 830, para poner a prueba al usuario respecto a su nombre de usuario y contrasena (de nuevo, de la manera descrita en relacion con la fig. 2) (etapa 855). En respuesta a esta puesta a prueba, el usuario suministra su nombre de usuario 55 y contrasena (etapa 860). Entonces se efectua una determinacion en cuanto a si el servidor de autenticacion 830 puede autentificar al usuario (etapa 865). Si el usuario no puede ser autentificado, se efectua una determinacion en cuanto a si no permitir que el usuario reintroduzca su nombre de usuario y contrasena (etapa 870). Si la

reintroduccion de esta informacion es aceptable, el procedimiento ejecuta un bucle hasta el servidor de autenticacion 830 poniendo a prueba al usuario (etapa 855). Si no (por ejemplo, si esta reintroduccion ha sido permitida un numero maximo de veces o si no se permite en absoluto), el procedimiento finaliza.

5 [0065] Alternativamente, si el usuario es autentificado (etapa 865), se permite que el usuario inicie sesion, lo cual se consigue reenviando la aceptacion de acceso al anfitrion 800 (etapa 875). Ademas, se asigna un SGT basandose en el (los) rol(es) del usuario (etapa 880). Este, junto con otra informacion, se utiliza para poblar la tabla de capa 2 (es decir, la tabla de reenvlo, o una construccion comparable) mantenida por el conmutador 820 (etapa 885). Esto completa el procedimiento de inicio de sesion del usuario.

10

[0066] Tal como se apunto, la fig. 8B representa un diagrama de flujo que ilustra un procedimiento segun una realizacion de la presente invencion, como otras de las figuras analizadas en este documento. Se aprecia que las operaciones analizadas en este documento pueden consistir en comandos introducidos directamente por un usuario del sistema informatico o por etapas ejecutadas por modulos de hardware de aplicacion especlfica, pero la

15 realizacion preferente de la invencion incluye etapas ejecutadas por modulos de software. La funcionalidad de las etapas a las que se hace referencia en este documento puede corresponder a la funcionalidad de modulos o porciones de modulos.

[0067] Las operaciones a las que se hace referencia en este documento pueden ser modulos o porciones de

20 modulos (por ejemplo, modulos de software, firmware o hardware). Por ejemplo, aunque la realizacion descrita

incluye modulos de software y/o incluye comandos de usuario introducidos manualmente, los diversos modulos de ejemplo pueden ser modulos de hardware de aplicacion especlfica. Los modulos de software analizados en este documento pueden incluir archivos de guion, por lotes u otros archivos ejecutables, o combinaciones y/o porciones de tales archivos. Los modulos de software pueden incluir un programa informatico o subrutinas del mismo

25 codificados en medios legibles por ordenador.

[0068] Ademas, los expertos en la materia reconoceran que los llmites entre modulos son meramente ilustrativos y realizaciones alternativas pueden fusionar modulos o imponer una descomposicion alternativa de la funcionalidad de los modulos. Por ejemplo, los modulos analizados en este documento pueden ser descompuestos en submodulos

30 que han de ejecutarse como multiples procesos informaticos, y, opcionalmente, en multiples ordenadores. Por otra parte, realizaciones alternativas pueden combinar multiples instancias de un modulo o submodulo particular. Ademas, los expertos en la materia reconoceran que las operaciones descritas en la realizacion de ejemplo son unicamente ilustrativas. Las operaciones pueden combinarse o la funcionalidad de las operaciones puede distribuirse en operaciones adicionales de acuerdo con la invencion.

35

[0069] Alternativamente, tales acciones pueden incluirse en la estructura de circuitos que implementa tal funcionalidad, tal como el microcodigo de un ordenador con conjunto de instrucciones complejas (CISC), firmware programado dentro de dispositivos programables o borrables/programables, la configuracion de una matriz de puertas programable in-situ (FPGA), el diseno de una matriz de puertas o un circuito integrado de aplicacion

40 especlfica (ASIC) totalmente personalizado, o similares.

[0070] Cada uno de los bloques del diagrama de flujo puede ser ejecutado por un modulo (por ejemplo, un modulo de software) o una porcion de un modulo o un usuario de sistema informatico. Asl, el procedimiento descrito anteriormente, las operaciones del mismo y los modulos para el mismo pueden ser ejecutados en un sistema

45 informatico configurado para ejecutar las operaciones del procedimiento y/o pueden ser ejecutados desde medios legibles por ordenador. El procedimiento puede incluirse en un medio legible por una maquina y/o legible por ordenador para configurar un sistema informatico para ejecutar el procedimiento. Asl, los modulos de software pueden ser almacenados dentro de y/o transmitidos a una memoria de sistema informatico para configurar el sistema informatico para realizar las funciones del modulo.

50

[0071] Tal sistema informatico normalmente procesa la informacion segun un programa (una lista de instrucciones almacenadas internamente tal como un programa de aplicacion particular y/o un sistema operativo) y produce informacion de salida resultante por medio de dispositivos de entrada/salida. Un proceso informatico incluye tlpicamente un programa en ejecucion (en funcionamiento) o una porcion de un programa, valores de programa

55 actuales e informacion de estado, y los recursos utilizados por el sistema operativo para gestionar la ejecucion del proceso. Un proceso progenitor puede generar otros procesos vastagos para ayudar a realizar la funcionalidad global del proceso progenitor. Como el proceso progenitor genera especlficamente los procesos vastagos para realizar una porcion de la funcionalidad global del proceso progenitor, las funciones realizadas por los procesos vastagos (y los procesos nietos, etc.) a veces puede describirse que son realizadas por el proceso progenitor.

[0072] Tal sistema informatico incluye tlpicamente multiples procesos informaticos que se ejecutan “simultaneamente”. A menudo, un sistema informatico incluye una unidad de procesamiento individual que es capaz de soportar muchos procesos activos alternativamente. Aunque puede parece que se ejecutan multiples procesos

5 simultaneamente, en cualquier momento dado solo es ejecutado realmente un proceso por la unidad de procesamiento individual. Cambiando rapidamente la ejecucion del proceso, un sistema informatico ofrece la apariencia de ejecucion simultanea de procesos. La capacidad de un sistema informatico de multiplexar los recursos del sistema informatico entre multiples procesos en varias fases de ejecucion se denomina multitarea. Los sistemas con unidades de procesamiento multiples, que por definicion pueden soportar un verdadero procesamiento 10 simultaneo, se denominan sistemas multiprocesamiento. Los procesos activos a menudo se denominan de ejecucion simultanea cuando tales procesos se ejecutan en un entorno multitarea y/o multiprocesamiento.

[0073] Los modulos de software descritos en este documento pueden ser recibidos por tal sistema informatico, por ejemplo, desde medios legibles por ordenador. Los medios legibles por ordenador pueden estar acoplados

15 permanentemente, de manera desmontable o a distancia al sistema informatico. Los medios legibles por ordenador pueden incluir de manera no exclusiva, por ejemplo, cualquier numero de lo siguiente: medios de almacenamiento magnetico incluyendo medios de almacenamiento en disco y en cinta, medios de almacenamiento optico tales como medios de disco compacto (por ejemplo, CD-ROM, CD-R, etc.) y medios de almacenamiento en disco de video digital, memoria de almacenamiento de memoria no volatil, incluyendo unidades de memoria basada en 20 semiconductor tales como memoria FLASH, EEPROM, EPROM, ROM o circuitos integrados de aplicacion especlfica. Medios de almacenamiento volatil incluyendo registros, memorias intermedias o caches, memoria principal, RAM, y similares, y medios de transmision de datos incluyendo una red informatica, telecomunicacion punto a punto, y medios de transmision de ondas portadoras. En un entorno basado en UNIX, los modulos de software pueden incluirse en un archivo los cuales puede ser un dispositivo, un terminal, un archivo local o remoto, 25 un zocalo, una conexion de red, una senal, u otro recurso de comunicacion o cambio de estado. Pueden usarse otros tipos nuevos y diversos de medios legibles por ordenador para almacenar y/o transmitir los modulos de software analizados en este documento.

[0074] La fig. 9A es un diagrama de bloques que ilustra un ejemplo de una subred del lado del servidor segun la 30 presente invention. En este ejemplo, un servidor 900 esta acoplado a una subred 910 mediante un conmutador 920.

El conmutador 920 tambien acopla el servidor 900 a un servidor de autenticacion 930, que proporciona la autenticacion de entidades que intentan iniciar sesion y acceder a la subred 910. En este escenario, a diferencia de la autenticacion de usuario representada en las figs. 8A y 8B, el procedimiento aqul es la autenticacion del servidor 900 por el servidor de autenticacion 930.

35

[0075] El servidor 900 es autentificado de manera similar a la utilizada para autentificar el ordenador anfitrion del usuario (anfitrion 800). El servidor 900 y el servidor de autenticacion 930 emplean un protocolo de autenticacion (por ejemplo, el IEEE 802.1X) que se utiliza para autentificar la identidad del servidor 900. La MAC, la VLAN del servidor (servidor 900) se inserta en la tabla de capa 2 y se marca como una direction MAC segura. La tabla 3 ilustra la tabla

40 de capa 2 despues de ser poblada con esta information.

Tabla 3. Ejemplo de tabla de capa 2

MAC

Identificador de VLAN Puerto Grupo de usuarios

5678.1234.DCBA

100 PortB5 6

[0076] La fig. 9B es un diagrama de flujo que ilustra un ejemplo del funcionamiento de la subred del lado del 45 servidor mostrada en la fig. 9A. El procedimiento comienza con el inicio del procedimiento de autenticacion por el

servidor 900 (etapa 950). Una vez que se inicia la autenticacion, el servidor de autenticacion 930 pone a prueba al servidor 900 por medio del conmutador 920 (etapa 955). En respuesta, el servidor 900 suministra informacion de autenticacion al servidor de autenticacion 930 por medio del conmutador 920 (etapa 960). Entonces se efectua una determination por el servidor 930 en cuanto a si el servidor 900 ha sido autentificado correctamente (etapa 965). Si 50 el servidor 900 ha fallado este procedimiento de autenticacion, el procedimiento termina y al servidor 900 no se le permite acceder, o que otros nodos de red accedan al mismo, a traves de la red.

[0077] Sin embargo, si el servidor 900 es autentificado (etapa 965), se permite que el servidor 900 acceda a la red mediante el reenvlo por el servidor de autenticacion 930 de la aceptacion de acceso al conmutador 920 y el servidor

55 900 (etapa 970). Ademas, se asigna un indicador de grupo (mas especlficamente, un DGT (aunque, desde la perspectiva del servidor 900, un SGT)) al servidor 900 en el conmutador 920 basandose en el (los) rol(es) del servidor (etapa 975). Se apreciara que, de hecho, la cuestion en cuanto a si un grupo de usuarios es un grupo de

usuarios fuente o de destino se toma desde el punto de vista de la direccion del paquete en cuestion. Esto, junto con otra informacion, se utiliza para poblar la tabla de capa 2 del conmutador 920 (etapa 980).

[0078] La fig. 10 es un diagrama de bloques que ilustra un ejemplo de una arquitectura de red 1000 que incluye un 5 anfitrion (1005) y un servidor 1010. De la manera representada en las figs. 8A y 8B, el anfitrion 1005 es autentificado

por un servidor de autenticacion 1015 por medio de un conmutador 1020. El conmutador 1020 tambien proporciona al anfitrion 1005 acceso a una subred 1025. De la manera representada en las figs. 9A y 9B, el servidor 1010 es autentificado por un servidor de autenticacion 1030 por medio de un conmutador 1035. El conmutador 1035 tambien proporciona al servidor 1010 acceso a (y desde) una subred 1040. Las subredes 1025 y 1040 estan acopladas 10 comunicativamente entre si a traves de un nucleo empresarial 1050. La subred 1025 accede al nucleo empresarial 1050 por medio de un encaminador 1055, e igualmente, la subred 1040 accede al nucleo empresarial 1050 por medio de un encaminador 1060.

[0079] En la fig. 10 tambien se muestra un paquete 1070, que tiene contenido 1075. El paquete 1070 es 15 transmitido por el anfitrion 1005 al conmutador 1020. La informacion de grupo de usuarios fuente es anadida al

paquete 1070 por el conmutador 1020 en forma de un indicador de grupo fuente 1080, basandose en la informacion proporcionada por el servidor de autenticacion 1015 durante el procedimiento de autenticacion, con el fin de crear un paquete 1085. Tal como se representa en la fig. 10, el paquete 1085 incluye tanto el contenido 1075 como el SGT 1080. El paquete 1085 recorre la subred 1025 y llega al encaminador 1055. El encaminador 1055 encamina el 20 paquete 1085 a traves del nucleo empresarial 1050 hasta el encaminador 1060. El encaminador 1060 presenta el paquete 1085 al conmutador 1035 (y de este modo, al servidor 1010) por medio de la subred 1040. El encaminado 1035 efectua una determinacion en cuanto a si pasar el paquete 1085 al servidor 1010, basandose, al menos en parte, en la informacion de DUG proporcionada al servidor 1010 por el servidor de autenticacion 1030. Se apreciara que, alternativamente, el encaminador 1060 tambien podrla encargarse de esta tarea y efectuar esta determinacion. 25

[0080] A continuacion se ofrece un ejemplo especlfico del recorrido de la arquitectura de red 1000 por el paquete 1075/el paquete 1085. Despues de la autenticacion, el anfitrion 1005 puede enviar paquetes (por ejemplo, el paquete 1075) en la red. Puesto que se estan aplicando RBACL en la capa 3 de red en el presente ejemplo, cualquier paquete que el usuario intente enviar mas alla de su subred local (por ejemplo, la subred 1025) sera

30 sometido a inspeccion de RBACL. Como se apreciara, los conmutadores 1020 y 1035 tambien pueden emplear

RBACL en el dominio de la capa 2 (por ejemplo, dentro de las subredes 1025 y 1040, respectivamente). Sin

embargo, en tal caso, probablemente se necesitarlan ajustes, tales como basar las RBACL en el direccionamiento de capa 3 de los paquetes, de manera similar a las VLAN ACL (VACL).

35 [0081] Si el paquete 1085 es el primer paquete que ha de enviarse desde el anfitrion 1005 al servidor 1010, se

activara un procedimiento de ARP para el destino. El envlo del paquete 1085 comienza tomandose el SUG (en este

caso, con un valor de 5) del SGT 1080. Una busqueda de FIB en el encaminador 1055 para un paquete que tenga el destino del paquete 1085 indica el siguiente encaminador de salto al cual deberla ser reenviado el paquete. Esta informacion de siguiente salto podrla ser, por ejemplo, la informacion de reescritura de MAC para el encaminador 40 1060, o para un encaminador entre el encaminador 1055 y el encaminador 1060. Esto puede verse en la tabla 4, que ilustra una FIB con tal contenido.

Tabla 4. FIB de ejemplo (encaminador 1055).

CAM

Memoria

Prefijo

Grupo de usuarios Informacion de siguiente salto

3.4.X.X

— Reescritura

23.X.X

—

X.X.X.X

---

45 [0082] Se observara que, en este ejemplo, la informacion de prefijo esta contenida en una CAM, mientras que el grupo de usuarios y la informacion de siguiente salto estan contenidos en una memora estandar (por ejemplo, SRAM). La busqueda se realiza utilizando el prefijo para determinar que entrada en la memoria inspeccionar.

[0083] Cuando el paquete 1075 (paquete posterior 1085) es enviado desde el anfitrion 1005, se quita el indicador 50 al paquete 1075, tal como se apunto. En este ejemplo, en el momento de entrar en el conmutador 1020, el paquete 1075 es marcado con el SGT 1080 (lo cual indica un grupo de usuarios de 5). Este grupo de usuarios es recuperado de la tabla de capa 2 en el conmutador de ingreso (conmutador 1020) de la manera analizada previamente. Este paquete (que ahora, incluyendo el SGT 1080, se denomina paquete 1085) es enviado luego a traves de la arquitectura de red 1000 por medio del encaminamiento y la conmutacion proporcionados de ese modo.

[0084] En el encaminador de egreso (encaminador 1060), se realiza la busqueda de FIB). Si la busqueda de FIB alcanza una subred unida localmente, la adyacencia de recoleccion hace que se genere una peticion de ARP para el servidor deseado (por ejemplo, el servidor 1010). La peticion de ARP es enviada desde el encaminador 1060 al 5 servidor 1010. La respuesta de ARP es enviada luego desde el servidor 1010. El conmutador de L2 de ingreso (conmutador 1040) inserta el SUG para el servidor 1010 (o, tal como se utiliza por los conmutadores/encaminadores de la arquitectura de red 1000 (por ejemplo, el anfitrion 1005) como el DUG para los paquetes enviados al servidor 1010; lo cual se establece para un grupo de usuarios de 6) dentro de la respuesta de ARP (en el encabezamiento de L2). El encaminador 1060 recibe la respuesta de ARP y puebla la FIB con el prefijo de anfitrion resuelto, la 10 information de reescritura que contiene la direction MAC del anfitrion, y el grupo de usuarios de destino (6) a partir de la respuesta de ARP. Un ejemplo de la FIB que resulta se muestra en la tabla.

Tabla 5. Contenido de FIB de ejemplo despues de la respuesta de ARP y la poblacion.

CAM

Memoria

Prefijo

Grupo de usuarios Informacion de siguiente salto

3.4.1.1

6 Reescritura

3.4.X.X

— Recoleccion

X.X.X.X

—

15 [0085] En el caso en el que el paquete 1085 es un paquete subsiguiente desde el anfitrion 1005 al servidor 1010, las tablas en cuestion ya deberlan estar pobladas. Una vez que la FIB del encaminador 1060 contiene el prefijo de anfitrion totalmente resuelto, el siguiente paquete al servidor 1010 estara sometido a control de acceso. (En una realization de la presente invention en este ejemplo, el primer paquete que activo la resolution de ARP se omite). Cuando el paquete subsiguiente llega desde el anfitrion 1005 llega al encaminador 1060, el encaminador 1060 ya 20 posee la informacion relacionada con los grupos fuente y destino pertinentes. El SUG (5) es extraldo del SGT del paquete subsiguiente y el DUG (6) es descubierto por la busqueda de FIB.

[0086] En este punto, se realiza una busqueda de ACL. Suponiendo que se emplea una implementation basada en cAm, la clave de busqueda en la CAM contiene la informacion del paquete as! como los grupos de usuarios 25 fuente y destino (5 y 6). En este ejemplo, el unico permiso admitido entre los 2 grupos es el trafico web (puerto tcp 80). Las entradas de la RBACL de ejemplo se muestran en la tabla 6.

Tabla 6. Contenido de RBACL de ejemplo.

SUG

DUG Especificacion de flujo Resultado

5

6 Puerto RCP 80 Permitir

7

8 Puerto TCP 23 Denegar

CUALQUIERA

CUALQUIERA

CUALQUIERA

CUALQUIERA

30 [0087] Puesto que, en este ejemplo, el paquete subsiguiente es en efecto trafico web (destinado al puerto TCP 80), se alcanza la entrada de CAM apropiada y se permite la transmision del paquete a la subred 1040 (y de ese modo, en el servidor 1010 por medio del conmutador 1035). Sin embargo, para ilustrarlo mejor, si el paquete subsiguiente ha sido un paquete Telnet (destinado al puerto TCP 23), el paquete alcanzara la entrada CUALQUIERA-CUALQUIERA en la CAM, lo cual no permitirla tal transmision (implementando eficientemente la 35 denegacion impllcita presente en las ACL por software). A continuation se presenta una discusion mas generalizada de las operaciones descritas en los pasajes anteriores en relation con las figs. 11, 12, 13 y 14.

[0088] La fig. 11 es un diagrama de flujo que ilustra un ejemplo generalizado del proceso del recorrido de un paquete a traves de una red tal como la representada como la arquitectura de red 1000. En tal escenario, el proceso 40 comienza con el anfitrion 1005 enviando un paquete (por ejemplo, el paquete 1070) (etapa 1100). El paquete as! transmitido pasa por el conmutador local (por ejemplo, el conmutador 1020), el cual marca el paquete con informacion de grupo de usuarios fuente (por ejemplo, un SGT) (etapa 1105). El paquete de destino (por ejemplo, el paquete 1085) pasa entonces por la subred local (por ejemplo, la subred 1025) (etapa 1110). Despues de pasar por la subred local, el paquete pasa por el dispositivo de red proximo (por ejemplo, el encaminador 1055) (etapa 1115), 45 En este punto, tal como se apunto, el encaminador 1055 encamina el paquete a traves de la interred dada (por ejemplo, el nucleo empresarial 1050) (etapa 1120). Despues de pasar por la interred, el paquete es recibido por el dispositivo de red lejano (por ejemplo, el encamiandor 1055) (etapa 1125). En el dispositivo de red lejano, se realiza el procesamiento de control de acceso basado en roles (etapa 1130). Tal procesamiento se describe en detalle en relacion con las figs. 12, 13 y 14.

[0089] Despues se efectua una determinacion en cuanto a si el paquete dado ha pasado el procesamiento de RBAC que se realiza (etapa 1135). Si el paquete no pasa la inspection de RBAC (es decir, el procesamiento de RBAC que se realizo), el paquete se omite (etapa 1140). Como resultara evidente para los expertos en la materia,

5 pueden realizarse otras acciones en respuesta a tal resultado. Alternativamente, si el paquete dado pasa la inspeccion de RBAC (etapa 1135), se permite que el paquete pase por el dispositivo de red lejano (etapa 1150), y luego pasa por la subred lejana (por ejemplo, la subred 1040) (etapa 1160). El paquete pasa entonces por al conmutador lejano (por ejemplo, el conmutador 1035) (etapa 1170). Por ultimo, el paquete llega al servidor de destino (por ejemplo, el servidor 1010) (etapa 1180).

10

[0090] La fig. 12 es un diagrama de flujo que ilustra un ejemplo del procesamiento de RBAC realizado en el paquete por un dispositivo de red tal como el encaminador 1060, en el caso en el que el paquete es el primero de tales paquetes recibidos. El procedimiento comienza con la recepcion de un paquete que ha de ser procesado utilizando la presente invention (etapa 1200). En primer lugar, se extrae el SGT del paquete (etapa 1210). A

15 continuation, se realiza una busqueda para determinar como deberla ser tratado el paquete (etapa 1220). Despues se efectua una determinacion en cuanto a si la direction de destino del paquete dado indica que se requiere procesamiento de RBAC (etapa 1230). Si la direccion de destino indica que no se requiere procesamiento de RBAC, el encaminador lejano realiza otro procesamiento en el paquete, segun se requiera, y encamina el paquete segun corresponda (etapa 1235).

20

[0091] Sin embargo, si la direccion de destino del paquete indica que ha de realizarse el procesamiento de RBAC, el encaminador lejano envla una petition de protocolo de resolution de direccion (ARP) al servidor de destino (por ejemplo, el servidor 1010) (etapa 1240). El servidor responde con una respuesta de ARP (etapa 1250). A continuacion, el conmutador lejano inserta el DGT (o el SGT, desde la perspectiva del servidor 1010) que

25 corresponde al grupo del servidor, dentro de la respuesta de ARP (etapa 1260). El encaminador lejano recibe esta respuesta de ARP (incluyendo el DGT (o el SGT, desde la perspectiva del servidor 1010) que indica el DUG del servidor 1010) (etapa 1270)), y puebla si base de information de reenvlo (FIB) con esta information (etapa 1280). Como antes, el encaminador lejano realiza entonces cualquier otro procesamiento requerido, y encamina el paquete segun corresponda (etapa 1235). Se observara que, de hecho, este encaminamiento puede incluir omitir el paquete

30 dado si la RBACL indica que el dispositivo de red ha de denegar el acceso al paquete.

[0092] La fig. 13 es un diagrama de flujo que ilustra un ejemplo del procesamiento realizado sobre un paquete recibido posteriormente al de la fig. 12, aunque aun sometido al procesamiento de RBAC segun la presente invencion. El procedimiento comienza, como antes, con la reception del paquete dado (etapa 1300). Tambien como

35 antes, se extrae el SGT del paquete (etapa 1310). Se realiza una busqueda mediante el dispositivo de red (por ejemplo, el encaminador 1060), con el fin de determinar como ha de ser tratado el paquete dado (etapa 1320). Despues se efectua una determinacion en cuanto a si la direccion de destino del paquete indica que se requiere procesamiento de RBAC (etapa 1330). Si la direccion de destino del paquete no indica que se requiere procesamiento de RBAC, el dispositivo de red lejano realiza otro procesamiento segun sea necesario, y encamina el

40 paquete apropiadamente (etapa 1340).

[0093] Sin embargo, si el dispositivo de red lejano determina que la direccion de destino del paquete indica que se requiere procesamiento de RBAC, el dispositivo de red lejano realiza una busqueda en la base de informacion de reenvlo (FIB) para determinar el DUG (etapa 1350). El dispositivo de red lejano, durante el procesamiento de ACL de

45 egreso, efectua entonces una determinacion en cuanto a si la entrada de la RBACL indica que el paquete dado deberla ser denegado (etapa 1360). Si la entrada de la RBACL indica que el paquete deberla ser denegado, el paquete se omite (etapa 1370). Alternativamente, si la entrada de RBACL indica que el paquete deberla ser reenviado, el dispositivo de red lejano realiza otro procesamiento segun sea necesario y encamina el paquete dado segun corresponda (etapa 1340).

50

[0094] La fig. 14 es un diagrama de flujo que ilustra un ejemplo del procesamiento de un paquete dado a medida que el paquete circula a traves del trayecto de datos de un dispositivo de red que implementa la presente invencion (por ejemplo, el encaminador 1060). El procesamiento comienza con el paquete pasando a traves de una ACL de seguridad de entrada (etapa 1400). Tlpicamente, los usuarios crean tales ACL con el fin de impedir que los paquetes

55 que representen una amenaza conocida entren en el dispositivo de red dado. A continuacion, las caracterlsticas de entrada del dispositivo de red responden al paquete dado (etapa 1410). Las caracterlsticas de entrada del dispositivo de red pueden incluir, por ejemplo, la interception del protocolo de control de transmision (TCP), el equilibrio de carga del servidor, la detection de intrusion, funciones de cortafuego, redirection de la cache web, cifrado/descifrado, marcacion/vigilancia de QOS (calidad de servicio) de entrada, encaminamiento basado en

pollticas y similares. Tal como se apreciara, la mayorla de estas caracterlsticas son especlficas de la interfaz de ingreso o anulan las decisiones de encaminamiento que pudieran efectuarse dentro del dispositivo de red.

[0095] A continuacion, se realiza una comprobacion de reenvlo de trayecto inverso (RPF) (etapa 1420). Al realizar 5 la comprobacion de RPF, el dispositivo de red (por ejemplo, el encaminador 1060) determina si el paquete dado es

recibido en la interfaz que se esperarla que el dispositivo de red utilizase para reenviar un paquete unidifusion de vuelta a la fuente del paquete entrante. Tlpicamente, si la comprobacion de RPF tiene exito, el encaminador reenvla el paquete a su destino previsto, por medio de las acciones restantes representadas en la fig. 14. Alternativamente, si la comprobacion de RpF falla, se desecha el paquete.

10

[0096] Asl, habiendo pasado la comprobacion de RPF, el encaminador realiza entonces la busqueda de encaminamiento (etapa 1430). A continuacion, se realiza una busqueda de ACL basada en roles (etapa 1440). En este punto se utilizan una busqueda basada en el SUG del usuario (tal como se indica por el SGT del paquete, o asignacion estatica por medio de ACL) y el DUG del servidor (tal como se obtiene mediante la busqueda de FIB (que

15 se obtiene del SGT del paquete previo) o asignacion estatica) para determinar si ha de concederse acceso al paquete.

[0097] Una vez que se concede acceso al paquete basandose en la combinacion de SUG/DUG, entonces se aplican al paquete las caracterlsticas de salida (etapa 1450). Ejemplos de caracterlsticas de salida que pueden

20 implementarse incluyen, por ejemplo, deteccion de intrusion, conformation de trafico, cifrado y descifrado criptografico, contabilidad de protocolo internet (IP) y similares. Despues se aplican las restricciones gobernadas por una ACL de seguridad de salida (etapa 1460). La ACL de seguridad de salida controla el reenvlo de paquetes para asegurar que, despues del procesamiento por el dispositivo de red, los paquetes potencialmente alterados no representen una amenaza para la seguridad de la(s) subred(es) en el lado de salida del dispositivo de red. De modo 25 similar, pueden aplicarse caracterlsticas de salida adicionales (etapa 1470).

Ejemplos de ventaias de la presente invencion

[0098] En su forma mas simple, las RBACL proporcionan control de acceso entre grupos de dispositivos de red. La 30 asignacion de grupo esta basada en el rol del individuo o dispositivo dentro de la empresa en cuestion. Mediante la

aplicacion de conceptos de RBAC a la red, el usuario se beneficia de varias maneras significativas. Las ventajas de una estrategia segun la presente invencion incluyen la escalabilidad mejorada de la red, la flexibilidad mejorada en la configuration de red y la manejabilidad mejorada de la red.

35 [0099] La primera, la escalabilidad, aborda el problema de incrementos multiplicativos en el consumo de recursos a medida que se anaden usuarios a la red. Por ejemplo, la presente invencion aborda el problema de la “explosion” de la ACL reduciendo multiplicativamente el tamano de la ACL. En general, el tamano de la ACL (en cuanto al numero de entradas de la aCl (ACE)) se ha reducido de:

40 NUMaces = NUMdirecciones_fuente * NUMdirecciones_destino * NUMpermisos

a:

NUMaces = NUMgrupos_fuente * NUMgrupos_destino * NUMpermisos 45

[0100] De los tres elementos (orlgenes, destinos, permisos), el numero de permisos a menudo es el menor de los tres elementos. Como puede verse, resulta razonable esperar que:

NUMdirecciones_fuente >> NUMgrupos_fuente 50

y:

NUMdirecciones_destino >> NUMgrupos_destino

55 [0101] Siendo ese el caso, uno de los terminos multiplicativos es un numero relativamente pequeno, con los otros dos terminos multiplicativos habiendose reducido sustancialmente, reduciendo el numero de ACE multiplicativamente. Por ejemplo, en una ACL, si suponemos 20 orlgenes diferentes (PC clientes o subredes), 5 destinos diferentes (servidores), y 4 permisos (permitir correo web, FTP y SMTP) entre ellos, esto crearla una ACL con 400 ACE. Si suponemos que los orlgenes son todos del mismo grupo (razonable, ya que una fuente es un

miembro de grupo, o esta sometido a una denegacion impilcita), y que los destinos son todos del mismo grupo (bajo el mismo razonamiento), el mismo ejemplo utilizando RBACL utilizarla solo 4 ACE, una reduccion de tamano de dos ordenes de magnitud.

5 [0102] Una mejora adicional de los aspectos de escalabilidad de implementaciones de la presente invencion es el hecho de que el conjunto de permisos de RBACL puede reutilizarse de una manera mucho mas eficaz que las ACL existentes. Por ejemplo, supongamos que al grupo de Ingenierla se le permite acceder por el puerto TCP 80 (www) al grupo de Servidor Web de Ingenierla. La lista de permisos consiste en 1 ACE (permitir www) y deniega el resto del trafico. Esta misma lista de permisos puede reutilizarse para que el grupo de Marketing se comunique con el grupo 10 de servidor Web de Marketing. Tal reutilizacion no es posible con las ACL tradicionales.

[0103] Un beneficio secundario de la presente invencion es que, dado el tamano sustancialmente reducido de las RBACL cuando se compara con las ACL existentes, la disminucion de tamano tiene como resultado un incremento significativo en el rendimiento del software, el cual esta en proportion directa a la reduccion del tamano de las ACL.

15 En otras palabras, puede esperarse un incremento (potencialmente, un incremento multiplicativo) en el rendimiento de las RBACL por software comparado con las ACL tradicionales.

[0104] Otro beneficio fundamental de las RBACL es el desacoplamiento de la topologla de red de la polltica de seguridad, proporcionando una estrategia mucho mas flexible para el control del trafico de red. Aunque las ACL han

20 estado presentes en la tecnologla de las operaciones en red durante muchlsimo tiempo, las ACL no han podido introducirse en la empresa. La principal ubicacion de las ACL hasta la fecha ha sido en el perlmetro de la red, tlpicamente entre la empresa e Internet. El cambio constante experimentado dentro de la mayorla de las empresas ha hecho de tal implementation y uso de ACL una propuesta inmanejable. Algunos ejemplos de tal cambio constante incluyen:

25

1. Usuarios actualizando continuamente las direcciones de red (por ejemplo, actualization de direcciones IP por medio de DHCP)

2. Movilidad flsica de los usuarios

3. Division en subredes

30 4. Cambios constantes que se efectuan en la topologla general de la red empresarial 5. Adicion constante de nuevos dispositivos/usuarios a la red

[0105] La flexibilidad proporcionada por las RBACL permite a los usuarios desplazarse a cualquier parte de la red sin causar efectos adversos en la polltica de seguridad. Una vez autentificado y asignado a un grupo de usuarios,

35 los permisos pueden aplicarse independientemente de la position del usuario en la red. La propia RBACL no cambia, porque los grupos relevantes y la polltica de seguridad permanecen sin cambiar. En un sentido, la polltica de seguridad de los usuarios les sigue alrededor de la red. No importa donde inicia sesion el usuario o el conmutador/encaminador flsico al que el usuario este conectado, la polltica de seguridad aplicada sigue siendo la misma.

40

[0106] La manejabilidad proporcionada por las RBACL es quiza su mejor ventaja. Esto esta estrechamente relacionado con las ventajas que las RBACL proporcionan con respecto a la escalabilidad y la flexibilidad. La escalabilidad que las RBACL proporcionan mejor la gestion de la red permitiendo que un administrador de red revise la RBACL y comprenda sus efectos (es decir, los objetivos que la RBACL pretende lograr). Con una ACL tradicional

45 que puede tener cientos o incluso miles de llneas de longitud, comprender exactamente que se hara para un flujo dado es casi imposible.

[0107] La disminucion de tamano de la RBACL tambien permite que la RBACL sea instalada en encaminadores/conmutadores por toda la red de la empresa. El desacoplamiento de la topologla de red de la polltica

50 de seguridad que esta implementada hace posible mover la misma RBACL a cualquier parte de la red, ya que las RBACL no se ven afectadas por la topologla de la red. Las direcciones de red y las interfaces de ingreso/egreso no afectan a la definition de la RBACL. Esto permite el movimiento del usuario por toda la red (y por tanto, la empresa), ya que sus permisos seran impuestos en todos los dispositivos de red.

55 [0108] A medida que se anaden usuarios a la red o se instalan nuevos servidores, las ACL tradicionales deben ser actualizadas para que incluyan el nuevo usuario/dispositivo. Esto supone un gran coste, especialmente a medida que las ACL se vuelven cada vez mas grandes. Con cada cambio, existe un riesgo de interruption de la red o un agujero de seguridad. El riesgo aumenta en proporcion directa al tamano de la ACL. Ademas, a medida que el tamano de la ACL aumenta, el rendimiento del software disminuye en proporcion directa. En una organization

grande, cuando una ACL necesita ser actualizada, el equipo de seguridad de la organizacion debe evaluar e introducir las entradas apropiadas. Despues, esta ACL modificada es comprobada por la organizacion. Finalmente, la ACL revisada y comprobada se instalara mediante la coordinacion con el equipo de gestion de red de la organizacion. El coste de tal procedimiento puede ser sustancial. En un escenario similar, utilizando RBACL, el 5 nuevo servidor simplemente se anade al grupo apropiado. No existe cambio en la ACL y los permisos apropiados para el grupo se aplicaran automaticamente.

[0109] Aunque se han mostrado y descrito realizaciones particulares de la presente invencion, resultara obvio para los expertos en la materia que, basandose en las ensenanzas de este documento, pueden efectuarse cambios y 10 modificaciones sin apartarse de esta invencion y sus aspectos mas generales, por lo tanto, las reivindicaciones adjuntas son para englobar dentro de su alcance todos esos cambios y modificaciones como dentro del verdadero alcance de esta invencion. Por otra parte, aunque la invencion se ha mostrado y descrito particularmente con referencia a estas realizaciones especlficas, se comprendera por los expertos en la materia que lo anterior y otros cambios en la forma y los detalles pueden efectuarse en las mismas sin apartarse del alcance de la invencion.

15

Claims (16)

1. REIVINDICACIONES

   1. Un aparato para asegurar el acceso a una red, comprendiendo el aparato;

   5 un medio de extraccion (220) para extraer de un paquete un identificador de grupo de usuarios fuente (400) del paquete;

   un medio de recuperacion (220) para recuperar, de una base de informacion de reenvio, un identificador de grupo de usuarios de destino (410) del paquete; y

   10

   un medio de determinacion de permiso (220) para determinar los permisos aplicables para el paquete utilizando el identificador de grupo de usuarios fuente y el identificador de grupo de usuarios de destino del paquete para determinar los permisos que se aplican al paquete, en el que la utilizacion del identificador de grupo de usuarios fuente y el identificador de grupo de usuarios de destino comprende indexar una matriz de control de acceso con el 15 identificador de grupo de usuarios fuente y el identificador de grupo de usuarios de destino para proporcionar una lista de permisos permitidos; y

   un medio para comprobar los permisos en una comprobacion de control de acceso basado en roles.

   20 2. El aparato de la reivindicacion 1, que comprende ademas:

   un medio para poblar una lista de control de acceso con el identificador de grupo de usuarios de destino en el que el grupo de usuarios de destino identifica un grupo de usuarios de destino de un destino.

   25 3. El aparato de la reivindicacion 1, que comprende ademas:

   un medio para determinar el identificador de grupo de usuarios de destino buscando

   el identificador de grupo de usuarios de destino en una lista de control de acceso.

   30
2. 4. El aparato de la reivindicacion 1, que comprende ademas:

   un medio para poblar una lista de control de acceso con el identificador de grupo de usuarios de destino.

   35 5. El aparato de la reivindicacion 4, en el que:

   el medio para comparar y el medio para poblar estan incluidos en el dispositivo de red.
3. 6. El aparato de la reivindicacion 5, en el que el medio para poblar comprende ademas:

   40

   un medio para recibir de otro dispositivo de red un mensaje de autenticacion que incluye el identificador de grupo de usuarios fuente.
4. 7. Un dispositivo de red que comprende:

   45

   un aparato segun cualquiera de las reivindicaciones 1 a 6 implementado utilizando una lista de control de acceso; y una memoria 50 en el que:

   la memoria esta configurada para almacenar la lista de control de acceso y para recibir un identificador de grupo de usuarios recibido por la memoria;

   55 la lista de control de acceso comprende una entrada de lista de control de acceso; la entrada de lista de control de acceso comprende un campo de grupo de usuarios; y,

   el medio para comparar comprende la memoria configurada para soportar una comparacion de un identificador de

   grupo de usuarios almacenado en el campo de grupo de usuarios y el identificador de grupo de usuarios recibido por la memoria.
5. 8. El dispositivo de red de la reivindicacion 7, en el que la lista de control de acceso comprende una o 5 una pluralidad de entradas de lista de control de acceso.
6. 9. El dispositivo de red de la reivindicacion 8, en el que cada una de las entradas de lista de control de acceso comprende:

   10 un campo de etiqueta de flujo;

   en el que el campo de etiqueta de flujo permite a la entrada de lista de control de acceso ser identificada como una entrada de lista de control de acceso basado en roles.

   15 10. El dispositivo de red de la reivindicacion 9, en el que cada una de las entradas de lista de control de

   acceso comprende ademas:

   un campo de grupo de usuarios;

   20 en el que el campo de grupo de usuarios permite ademas a la entrada de lista de control de acceso ser identificada como una entrada de lista de control de acceso basado en roles.
7. 11. El dispositivo de red de la reivindicacion 10, en el que cada una de las entradas de lista de control de acceso comprende ademas:

   25

   un campo de grupo de usuarios fuente; y, un campo de grupo de usuarios de destino.
8. 12. El dispositivo de red de la reivindicacion 11, en el que:

   30

   el campo de grupo de usuarios fuente almacena el identificador de grupo de usuarios fuente; y,

   el identificador de grupo de usuarios fuente identifica un grupo de usuarios de una fuente de un paquete procesado

   utilizando la lista de control de acceso.

   35 13. El dispositivo de red de la reivindicacion 11 o 12, en el que:

   el campo de grupo de usuarios de destino almacena un identificador de grupo de usuarios de destino;

   y,

   40

   el identificador de grupo de usuarios de destino identifica un grupo de usuarios de destino de un destino de un paquete procesado utilizando la lista de control de acceso.
9. 14. Un procedimiento de determinacion de permisos aplicables para un paquete dado para asegurar el 45 acceso a una red que comprende: tomar como entradas a un procedimiento de determinacion de permiso un grupo

   de usuarios fuente (400) y un grupo de usuarios de destino (410) del paquete; determinar una lista de permisos (420) indexando una matriz de control de acceso con el grupo de usuarios fuente y el grupo de usuarios de destino para proporcionar una lista de permisos permitidos; y, comprobar los permisos en una comprobacion de control de acceso basado roles (430).

   50
10. 15. El procedimiento de la reivindicacion 14, en el que:

    el identificador de grupo de usuarios de destino es almacenado en una entrada de lista de control de acceso basado en roles de la lista de control de acceso.

    55
11. 16. El procedimiento de la reivindicacion 14 o 15, en el que:

    el grupo de usuarios fuente es asignado a una fuente del paquete basandose en un rol de la fuente; y, el grupo de usuarios de destino es asignado al destino basandose en un rol del destino.
12. 17. El procedimiento de la reivindicacion 16, que comprende ademas:

    determinar el grupo de usuarios de destino buscando el grupo de usuarios de destino en una lista de control de 5 acceso.
13. 18. El procedimiento de la reivindicacion 17, en el que:

    el identificador de grupo de usuarios de destino es almacenado en una entrada de lista de control de acceso basado 10 en roles de la lista de control de acceso.
14. 19. El procedimiento de la reivindicacion 17, que comprende ademas:

    poblar la lista de control de acceso con un identificador de grupo de usuarios de destino, que identifica el grupo de 15 usuarios de destino.
15. 20. El procedimiento de cualquiera de las reivindicaciones 15 a 19, que comprende ademas:

    poblar un tabla de reenvlo con un identificador de grupo de usuarios fuente que identifica el grupo de usuarios del 20 paquete.
16. 21. Un medio legible por ordenador que lleva instrucciones para configurar un sistema informatico para llevar a cabo un procedimiento de acuerdo con cualquiera de las reivindicaciones 14 a 20.