Comercio electrónico

Criptología y seguridad

Cuestiones legales

Intimidad y privacidad

Virus

Por Luis Rodríguez Berzosa

Desde los orígenes del tiempo (informático) se ha tratado de controlar el acceso a los recursos de información. La tecnología utilizada para este control de accesos ha evolucionado con los propios sistemas de información protegidos. En este artículo se pretende contemplar en una perspectiva histórica el problema de la autorización, contemplando su pasado, su presente y, de manera especial, su futuro, que indudablemente estará ligado con las nuevas tecnologías de clave pública, actualmente tan en boga en este microcosmos de la seguridad.

El problema

La autenticación pretende establecer quién eres. La autorización (o control de accesos) establece qué puedes hacer con el sistema. Ambos conceptos parecen ir ligados de forma indisoluble, pero no siempre. La posesión de la llave de mi coche le parece autoridad suficiente para dejarse conducir, incluso por un individuo cuyo pasaporte poco tiene que ver con el mío. Estos dos conceptos, que a menudo se mezclan de manera difusa, son completamente independientes. Sin embargo, especialmente cuando se accede a un recurso de información vía red, sin protección física, existen tres actividades que irán siempre ligadas: La autenticación (quién soy), la autorización (qué puedo hacer) y el registro de auditoría (qué he hecho).

En un mundo cada vez más dependiente de las redes, es vital no sólo proteger el acceso a los recursos por los 'malos', sino también evitar una manipulación accidental con fatales consecuencias. Un ejemplo en boga: la protección de los ficheros de datos personales, objeto del reciente Reglamento de la LORTAD.

La solución conceptual

Existen tradicionalmente dos tipos básicos de controles de acceso con filosofías diametralmente opuestas:

* En el modelo de control de acceso discrecional (DAC), un usuario bien identificado (típicamente, el creador o 'propietario' del recurso) decide cómo protegerlo estableciendo cómo compartirlo, mediante controles de acceso impuestos por el sistema. Este es el modelo habitual en buena parte de los sistemas operativos más habituales. Lo esencial es que el propietario del recurso puede cederlo a un tercero.

En sus inicios estos sistemas eran excesivamente simples, al permitir un conjunto limitado de operaciones posibles sobre un recurso (rwx por propietario, grupo o resto de usuarios, como en Unix), si bien pronto se añadieron las famosas listas de control de accesos (ACLs), listas de usuarios y grupos con sus permisos específicos. Las ACLs permiten un nivel de granularidad que, en ocasiones, es inconveniente, por cuanto complica la administración de la seguridad.

* En el modelo de control de acceso mandatorio (MAC), es el sistema quién protege los recursos. Todo recurso del sistema, y todo principal (usuario o entidad del sistema que represente a un usuario) tiene una etiqueta de seguridad. Esta etiqueta de seguridad sigue el modelo de clasificación de la información militar, en donde la confidencialidad de la información es lo más relevante, formando lo que se conoce como política de seguridad multinivel. Una etiqueta de seguridad se compone de una clasificación o nivel de seguridad (número en un rango, o un conjunto de clasificaciones discretas, desde DESCLASIFICADO hasta ALTO SECRETO) y una o más categorías o compartimentos de seguridad (CONTABILIDAD, VENTAS, I+D...). En este tipo de sistemas, todas las decisiones de seguridad las impone el sistema, comparando las etiquetas del accesor frente al recurso accedido, siguiendo un modelo matemático (Bell-LaPadula, 1973). Los criterios de seguridad TCSEC correspondientes al nivel de seguridad B1 o superior incluyen este modelo.

El modelo DAC se ha venido usando profusamente en sistemas operativos de propósito general con clasificación de seguridad TCSEC C1 o superior, y en virtualmente todos los sistemas de bases de datos, aplicativos, y sistemas de comunicaciones de propósito comercial. El modelo MAC no ha salido habitualmente del entorno militar, donde la clasificación de la información es lo más relevante.

Los modelos DAC y MAC son inadecuados para cubrir las necesidades de la mayor parte de las organizaciones. El modelo DAC es demasiado débil para controlar el acceso a los recursos de información de forma efectiva, en tanto que el MAC es demasiado rígido. Desde los 80 se ha propuesto el modelo de control de accesos basado en roles (RBAC), como intento de unificar los modelos clásicos DAC y MAC, consiguiendo un sistema donde el sistema impone el control de accesos, pero sin las restricciones rígidas impuestas por las etiquetas de seguridad.

Básicamente, un rol establece un nivel de indirección entre los usuarios y los derechos de acceso, a través de un par de relaciones: asignación de roles a usuarios, y asignación de permisos y privilegios a roles. Las políticas de control de accesos basado en roles regulan el acceso de los usuarios a la información en términos de sus actividades y funciones de trabajo, representándose así de forma natural la estructura de las organizaciones.

Uno de los problemas más acuciantes en la gestión de grandes sistemas de información heterogéneos es la complejidad de la administración de seguridad. La aproximación RBAC, intuitivamente, modela de forma natural la estructura de autorización en las organizaciones del mundo real, facilitando las tareas administrativas al separar la asignación de individuos a funciones o perfiles de trabajo, y la definición de políticas de acceso (definición de roles en términos de lo que pueden hacer en el sistema). Permiten asimismo la construcción jerárquica de estas políticas de acceso, por herencia o especialización. Así, la política de control de accesos para un supervisor de planta puede ser una especialización de la del operador de planta. Por ello, la tecnología RBAC tiene el potencial de reducir la complejidad y el coste de la administración de seguridad en estos entornos heterogéneos.

Además, dada la alta integración entre los roles y las responsabilidades de los usuarios, pueden seguirse los principios del mínimo privilegio y de la separación de responsabilidades. Estos principios son vitales para alcanzar el objetivo de integridad, al requerir que a un usuario no se le otorguen mayores privilegios que los necesarios para efectuar su trabajo, y que para completar una transacción de cierta seguridad (por ejemplo, la autorización de un pago) se requiera la culminación de una cadena de transacciones simples por más de un usuario.

El modelo RBAC es hoy día ubicuo: desde sistemas de base de datos relacionales, pasando por sistemas operativos de red, cortafuegos, productos de seguridad mainframe y entornos abiertos, sistemas de Sign-On único y de seguridad web...

La industria ha venido usando otros modelos de control de accesos, como complemento de estos tres básicos, como el modelo de capacidades, en donde parte de las decisiones de autorización se toman a partir de 'capacidades', 'derechos efectivos' o atributos de privilegio, contenidos en las credenciales que un usuario adquiere durante la autenticación. DCE, por ejemplo, incorpora este modelo en su servicio de seguridad. A menudo estos atributos de autorización se integran en un objeto conocido como 'Certificado de Atributos de Privilegio' (PAC, por sus siglas en inglés). Un PAC es como una acreditación de visitante: Se obtiene tras prueba de identidad, está emitida por una autoridad en la que se confía, no identifica al individuo pero sí lo categoriza (e.g. 'Visitante'), es de duración limitada, y no encierra en sí mismo información de privilegios o permisos (qué puertas puedo franquear, por ejemplo).

La 'Edad de Piedra': Sistemas centralizados

Érase una vez una época en la que todo era mucho más simple. El mainframe era la pieza angular de los sistemas de información (algo que, en muchos casos, sigue teniendo vigencia). Ya en 1976 IBM lanza RACF (Resource Access Control Facility), sistema de seguridad que, pese a su espartana simplicidad inicial, evolucionó, revolucionando la concepción sobre los sistemas de control de accesos. Casi al tiempo, surgieron otros productos de seguridad análogos, como CA-ACF2, TopSecret, y un largo etcétera.

Unix se encontraba en sus balbucientes inicios. Su seguridad se basaba en el modelo DAC simple, donde en esencia los recursos podían leerse, escribirse y ejecutarse, y donde se concedían permisos para el propietario, para el grupo y para el resto de usuarios del sistema.

La 'Edad de Bronce': Sistemas distribuidos

Y es cuando hace su aparición la informática distribuida. Se empieza a hablar de cliente/servidor. Se introduce el concepto de middleware transaccional. Las bases de datos relacionales implementan controles de acceso a datos basados en perfiles de usuario o roles, con sistemas bastante sofisticados. Aparece DCE como plataforma de informática distribuida, donde el servicio de seguridad se basa en una autenticación distribuida (Kerberos) y la emisión de certificados de atributos de privilegio (tickets que encierran los atributos de autorización de un principal DCE).

DCE, pese a su elegante diseño en cuanto a seguridad, no cobra la difusión que merece (debido a su fama de complejo). En informática distribuida, estamos en el punto de no retorno: Hay ya demasiados sistemas de seguridad heterogéneos como para pensar en integrarlos en una única infraestructura de seguridad, sea DCE o no.

Aparecen en la industria soluciones que prometen, además de facilidades como Sign-On único o administración centralizada de la seguridad, un primer control de accesos a las aplicaciones corporativas. Estos sistemas, que se interponen entre los usuarios y los sistemas de seguridad de los diferentes componentes de una aplicación distribuida, aportan más a la facilidad de administración de seguridad y la conveniencia de los usuarios (lo cual no es poco) que a la seguridad en sí misma. Aparecen perfiles específicos del estándar GSS-API, como SESAME, respuesta europea a DCE, que a menudo conforman la infraestructura en la que se apoyan este tipo de productos.

La gestión distribuida de permisos cobra relevancia. Los datos de control de accesos (permisos, ACLs) se almacenan localmente, pero deben ser gestionados de forma centralizada. Aparecen una nueva clase de herramientas, directamente encaminadas no ya a proporcionar seguridad, sino a facilitar la administración de los múltiples sistemas de seguridad existentes.

Y la actual 'Edad de Hierro': Las PKI

Entonces surge la Internet, las arquitecturas de objetos y componentes distribuidas (CORBA, EJB, DCOM). El lenguaje Java cobra un éxito sin precedentes por su promesa de lenguaje independiente de plataforma. Todas estas plataformas ofrecen sistemas de seguridad que recogen la experiencia previa. Así, el servicio de seguridad CORBA se basa en un paradigma que se parece sospechosamente al de DCE. El modelo de seguridad Java, en cuanto a autorización, se basa en un modelo de dominios protegidos, donde los permisos de asignan en el sistema local para un dominio que agrupa las clases Java cargadas desde unos determinados sitios y firmados por unos determinados individuos.

Pero lo más visible y novedoso en el presente quizá sea el fenómeno PKI. Ya no es posible controlar un grupo más o menos numeroso de empleados: en los negocios electrónicos se requiere controlar la seguridad en los accesos de usuarios bajo los que no se tiene control administrativo, como proveedores, clientes, consumidores... La PKI es, sobre todo, infraestructura, que las aplicaciones tanto orientadas a Internet como orientadas al 'mundo interior' (bases de datos, sistemas operativos) están tan sólo comenzando a aprovechar.

Bien, ya tenemos una PKI... ¿Y qué? ¿Qué aporta de cara al control de accesos? La tecnología de clave pública ofrece grandes ventajas en cuanto a autenticación fuerte de usuarios (su combinación con dispositivos como las tarjetas inteligentes, de hecho, constituye el estado del arte en cuanto a autenticación de usuarios). Protocolos como SSL o IPSEC se apoyan en la PKI para ofrecer servicios añadidos de confidencialidad e integridad en las comunicaciones. La cuestión es: ¿tienen las PKI algo que ofrecer en cuanto al control de accesos? El resto del artículo examinará esta cuestión.

Los certificados de atributos

Los certificados de atributos no son sino la respuesta de clave pública a los 'certificados de atributos de privilegio' usados en el pasado. La idea es simple: 'Demos al César lo que es del César'. Los certificados de clave pública X.509 proporcionan evidencia de la identidad de una persona (aunque incluso esto puede ponerse en cuestión). Pero en entornos de comercio electrónico, se precisa más información que la mera identidad, en especial cuando las partes involucradas en una transacción no han tenido contacto previo. En este caso, la información sobre los atributos de privilegio de una persona (por ejemplo, su capacidad de firmar un contrato, o su límite de crédito) es mucho más relevante que su mera identidad.

X.509 v3 intodujo el útil concepto de extensión. Lo más lógico pareció en ese momento añadir al certificado de identidad extensiones que recogieran estos atributos. Pero es como mezclar agua y aceite. Los atributos de privilegio cambian mucho más a menudo que la identidad de los individuos, lo cual obliga a revocar el certificado antiguo y emitir uno nuevo. Y la validación del certificado, que ya era tema delicado por las revocaciones debidas, se convierte en esta situación en tema trascendental (evidentes cuando se otorga un certificado al director de compras, y a continuación se le despide). Las extensiones dedicadas al control de accesos son propietarias, y dificultan la interoperabilidad. Y, por si fuera poco, tenemos un problema de jurisdicción: el certificado de identidad podrá ser emitido por una autoridad de certificación que dé fe de la identidad del usuario (como FNMT/MAP/Correos); pero, ¿puede la FNMT erigirse como depositaria de la concesión de privilegios de utilización de los recursos de información de mi empresa X?

La respuesta a estas dificultades es inmediata: ¿Por qué no dividir el certificado X.509 en dos, uno para la información de identidad - -certificado de identidad, y el otro para la información ligada con el control de accesos -certificado de atributos? Esto simplifica el proceso de emisión y, si los certificados de atributos se emiten con una duración limitada, eliminar en ciertas circunstancias el problema de revocación. Si los certificados de atributos duran un día, o una hora, podría no ser necesaria su revocación: simplemente expiran.

¿Cuáles pueden ser los atributos encerrados en un certificado de esta clase? Roles, grupos, identidades de acceso y/o auditoría (para aplicaciones de sign-on único), restricciones... Por ejemplo, un atributo puede expresar el límite de crédito concedido a un determinado suscriptor a un servicio de tienda virtual. Las posibilidades son ilimitadas. Podemos contemplar así los certificados de atributos como un 'manojo de llaves' que se añaden a un certificado de identidad ('pasaporte digital') para abrir determinadas puertas.

Ejemplos de aplicaciones de esta tecnología son:

* Servicios de suscripción ('pago por visión'). Los usuarios se registrarían de forma gratuita, pero sólo obtendrían un certificado de atributos tras el pago de una cuota de subscripción. La duración del certificado correspondería a la de disfrute del servicio subscrito.

* Control de accesos basado en roles a servicios en red cuya autenticación se realiza usando una PKI (web, FTP, SMTP...). El protocolo SSL autentica al cliente; un certificado de atributos permite al servicio determinar qué puede hacer el usuario dentro del mismo.

* Control de accesos a redes privadas virtuales (RPV). Piénsese en los usuarios 'itinerantes' de una gran organización. En vez de mantener controles de acceso replicados en cada puerta de acceso RPV, mediante un servicio centralizado se concede al usuario un certificado de atributos que le franquee el acceso a través del puerto de acceso.

* Sign-on único basado en autenticación fuerte mediante tarjeta inteligente. Las credenciales necesarias para el acceso a aplicaciones (usuario / password) pueden ir cifradas en el certificado de atributos concedido al usuario tras el proceso de autenticación basado en la posesión de la clave privada en tarjeta inteligente.

Certificación cruzada y traducción de políticas

Otro medio de controlar el acceso a servicios de alto nivel mediante una PKI lo tenemos en el concepto de 'políticas de utilización' y 'traducción de políticas'. A menudo la autoridad de certificación emisora sí puede hacer establecer condiciones sobre la utilización de las claves y el certificado emitido, a través de las extensiones de política de uso. El banco X puede emitir un certificado para un cliente, y establecer a nivel de certificado de identidad el tipo de servicio al que el cliente tiene derecho ('tarjeta oro' y 'superlibretón', por ejemplo). Esto no es tan flexible como los certificados de atributos, pero puede ser perfectamente aprovechable bajo ciertas condiciones.

Imaginemos que el banco X firma un acuerdo de colaboración (o se fusiona, según cierta moda imperante) con el banco Y, que tiene su propio servicio de banca virtual y emite certificados para dos tipos de servicios, denominados sin demasiada imaginación 'tarjeta platino' y 'supersuperlibretón'. Ambos bancos emiten certificados cruzados que, algún día, las aplicaciones de banca virtual de cada entidad aprovecharán para otorgar su confianza a los poseedores de certificados emitidos por el otro banco. El problema es: ¿Equivale el usuario de una 'tarjeta oro' del banco X a un usuario de la 'tarjeta platino' del banco Y?

Este tipo de relaciones entre políticas de uso de certificados pueden hacerse explícitas en los certificados cruzados mediante las extensiones estándar de traducción de políticas (policy mapping). Así, nuestros bancos podrán equipar las respectivas tarjetas oro y platino, y no hacer lo propio con las 'superlibretón' y 'supersuperlibretón'. ¿Aprovecharán algún día las aplicaciones esta información?

Autorización en autoridades de validación

Sin validación (comprobación de que un certificado está firmado por una cadena de autoridades entre las que se haya una en la que se confía, que el certificado esté dentro de su período de validez, y que no haya sido revocado), el receptor de un certificado digital en una transacción de comercio-e sólo podrá confiar parcialmente en la misma. En el mundo de las tarjetas de crédito, cuando uno se halla enfrente del terminal punto de venta, tiene lugar una validación en línea de la tarjeta, en la que la disponibilidad es esencial (la emisión de la tarjeta, por contra, es una función fuera de línea: poco importa que la tarjeta me llegue un día antes o un día después). Lo mismo ocurre con los certificados digitales: su emisión suele ser un proceso offline, mientras que su validación es un proceso online.

Para entornos de producción, o para aplicaciones de alta sensibilidad (no ya el pago del alquiler de una película en el videoclub de la esquina), una PKI sin validación es fundamentalmente incompleta e insegura. Para proporcionar esta función surgen las Autoridades de Validación, cuya competencia es la validación de los certificados, no su emisión; y añadir a la validación 'intrínseca' (firma correcta por una cadena de autoridades en la que se confía, validez temporal, no revocación/suspensión) una validación extrínseca: A partir de información de política de accesos se establece si un certificado es válido -si, además de ser válido intrínsecamente, verifica además las condiciones de la política de accesos impuestas por la organización. Y si el certificado no es 'válido', la aplicación se niega a ofrecer el servicio solicitado.

El imponer un punto de control de accesos en el proceso de validación tiene sustanciales ventajas: La validación es un proceso independiente de la emisión del certificado, de forma que los parámetros para la autorización pueden modificarse 'a posteriori', tras la emisión del certificado: Cambios en la política de accesos no requieren la revocación del certificado.

Conclusión

Lejos quedan ya los tiempos en los que todo se reducía a asegurar el mainframe corporativo. La evolución de los sistemas de control de accesos ha ido pareja con la de los sistemas de información. Vivimos en un mundo, mal que nos pese, dirigido a los sistemas no ya distribuidos, sino 'desparramados', y se hacen necesarios los modelos de control de accesos para estos nuevos sistemas. La tecnología de clave pública, como viene siendo habitual, tiene mucho que decir al respecto.

Reproducido de "Revista SIC", nº 37, con el permiso de su director.

Publicado en el Boletín del Criptonomicón #68 y #69.

Luis Rodríguez Berzosa es licenciado en físicas y matemáticas por la U. Complutense de Madrid. Ha trabajado en compañías del sector como consultor de Seguridad, y en la actualidad es director técnico de Ideal Objects. Sus intereses están en XML y WAP, la seguridad en objetos distribuidos, y la tecnología de clave pública.

• Control de acceso
• Cortafuegos: la mejor defensa

Puedes consultarlos por temas, o también por orden de aparición en el boletín.

Si consideras que este artículo puede interesarle a alguien que conozcas, puedes enviárselo por correo electrónico. No tienes más que indicar la dirección del destinatario, el asunto y tu nombre.

Copyright © 1997-2000 Gonzalo Álvarez Marañón, CSIC. Todos los derechos reservados.

Criptonomicón es un servicio ofrecido libremente desde el Instituto de Física Aplicada del CSIC. Para información sobre privacidad, por favor consulte la declaración de política sobre privacidad. Para sugerencias, comentarios o quejas, acuda al libro de visitas. Para contribuir al Criptonomicón, lea la página de contribuciones.