Hasta el momento, se ha presentado un Web que ofrece un acceso abierto a un conjunto de información que explícitamente se hace pública. Sin embargo, en determinadas circunstancias, es interesante poder limitar el acceso a documentos reservados o útiles para un conjunto restringido de personas. Se pueden establecer dos tipos de restricciones:

1. Limitación de acceso en función de direcciones IP o dominio. Sólo los usuarios de un dominio u organización tendrán acceso a la información.
2. Limitación de acceso por nombres de usuario y claves de acceso. Sólo los usuarios que conozcan una clave de acceso válida pueden acceder a la información.

Otro aspecto que está cobrando especial importancia es la seguridad de la información que se intercambia en el Web. La explotación comercial de Internet exige disponer de sistemas de comunicación seguros, capaces de adaptarse a las necesidades de los nuevos servicios, como la compra electrónica o la banca a distancia. En estos servicios, se manejan dos conceptos fundamentales, la autentificación (garantizar que tanto el usuario de un cliente Web como un determinado servidor de información son quienes dicen ser) y la confidencialidad (hacer que la información intercambiada no pueda ser interceptada por terceros).

Con los sistemas de comunicación actualmente en uso, es técnicamente posible ‘pinchar’ un enlace de comunicaciones e interceptar el contenido de las comunicaciones TCP/IP que por él se transmiten. Cuando se envía información privada, por ejemplo un número de tarjeta de crédito en un formulario de compra, es vital garantizar que la información sea recibida exclusivamente por su destinatario, y que la identidad es la esperada.

Control de acceso a la información

Se utiliza para limitar el acceso a determinados documentos de un servidor Web, en función del origen y tipo de petición. La forma de hacerlo varía con el entorno en el que se publican las páginas (sistema operativo y servidor HTTP, principalmente); en general, todas las soluciones pasan por definir un fichero que contiene las diferentes limitaciones de acceso, en un formato característico del servidor HTTP. En algunos casos se utiliza un fichero global con las restricciones de acceso o bien un fichero por cada directorio al que se quiere limitar el acceso.

Cuando un cliente Web accede a un fichero protegido, el servidor devuelve un código de error asociado a la falta de permisos para realizar la operación (código 401). Si el acceso se realiza desde un dominio o dirección IP prohibida, no será posible acceder a la información desde ese sistema. Cuando la protección se basa en nombres y claves de acceso, el browser solicitará estos datos y los enviará al servidor para que sean verificados. Las claves de acceso se envían al servidor por diferentes sistemas, sin codificar (sencillo pero inseguro) o codificadas (DES o Kerberos, por ejemplo). Será el propio servidor HTTP el que informe sobre la manera en que se deben enviar estas claves de acceso.

Para conocer cómo se especifican estas listas de control de acceso, se puede emplear la documentación de los respectivos servidores HTTP. En la bibliografía se incluyen enlaces a estas páginas. En los siguientes apartados, se hace un breve repaso de las posibilidades de tres servidores muy utilizados.

Control de acceso en un servidor CERN

La versión 3.0 del servidor desarrollado por el CERN permite limitar el acceso a documentos o grupos de documentos, en función de nombres de usuario o direcciones de origen. El control de acceso se puede realizar para todo el servidor, modificando los ficheros globales de configuración o para un directorio concreto. Como este método está disponible para cualquier usuario, sin necesidad de tener privilegios de administración, será el comentado aquí.

El control de acceso al contenido de un directorio se realiza creando un fichero de nombre .www_acl, en el mismo directorio que los ficheros cuyo acceso se quiere controlar. Un ejemplo aclarará más el formato de este fichero:

  secret*.html : GET,POST : trusted_people

    minutes*.html : GET,POST : secretaries

    *.html : GET : willy,kenny

Está formado por líneas, cada una de ellas fijando una limitación de acceso diferente. Para cada especificación de ficheros, se indica los comandos HTTP permitidos y los usuarios o grupos de usuarios que pueden acceder. Cuando se añade un control de acceso, automáticamente se deshabilita el acceso para los usuarios o grupos no incluidos. Se utiliza el mecanismo de autentificación básica, en la cual las claves de acceso son transferidas por la red sin codificar.

Se pueden crear usuarios o grupos de usuarios con la aplicación htadm, a través de la cual se generan nuevos usuarios y se les asigna claves de acceso. Además, a través de la configuración global del servidor, es posible fijar permisos de acceso por defecto, o restringir el uso del servidor a determinadas direcciones (o rangos de direcciones) IP.

NOTA
Se puede encontrar más información sobre el uso de los controles de acceso en http://www.w3.org/pub/WWW/Daemon/User/Config/AccessAuth.html.

Los clientes Web tienen una pequeña base de datos con las claves públicas de diversas autoridades de certificación, a partir de las cuales se pueden verificar las claves públicas de otros servidores. De esta forma, si se codifica un mensaje con la clave pública de un determinado servicio Web, la información enviada sólo podrá ser interpretada por el destinatario del mensaje.

A partir de la criptografía de clave pública se ha desarrollado SSL (Secure Sockets Layer), un sistema de codificación de información propuesto por Netscape que codifica toda la información transferida al nivel de conexiones TCP, por lo que es compatible con todos los protocolos y servicios de Internet. SSL está incluido en los clientes Web de Netscape, Microsoft, IBM... El establecimiento de una conexión SSL consta de las siguientes fases:

1. El cliente y el servidor intercambian sus certificados de autenticidad (el cliente no tiene necesariamente uno). Estos certificados se validan con una autoridad de certificación. Este procedimiento es el llamado ‘sistema de autentificación de RSA’ (ver www.rsa.com)
2. El cliente genera una clave aleatoria, que envía al servidor tras codificarla con la clave pública de este; el servidor hace un proceso similar. De esta forma, las claves de encriptación sólo pueden ser conocidas por el cliente y el servidor.
3. Esas llaves se utilizan para encriptar todos los datos intercambiados. El sistema criptográfico empleado en este punto es elegido como el más seguro entre todos los conocidos por el cliente y el servidor (por ejemplo, RC2, RC5, DES o IDEA). Adicionalmente, se puede utilizar un sistema de firma digital de los contenidos, como MD5.

Como puede verse, SSL combina criptografía de clave pública, para el intercambio de las claves de cifrado, y criptografía de clave privada, para el intercambio de información. Esto es necesario porque la criptografía de clave pública implica muchos más cálculos que la otra, por lo que no es factible para mantener una conexión cifrada.

La base de cualquier sistema de codificación es el tamaño de la llave empleada para encriptar el contendido de los mensajes. Con SSL, se pueden utilizar varios tamaños de llave desde 40 bits. En la actualidad, las llaves de 40 bits pueden ser desencriptadas en un tiempo razonablemente corto empleando sistemas informáticos de alto rendimiento, cosa mucho más complicada con las llaves de 128 bits o más. Sin embargo, Estados Unidos impone restricciones para exportar fuera de su país aplicaciones que utilicen codificación de más de 40 bits. Estas restricciones no se aplican a los sistemas de autentificación de identidad, que pueden utilizar llaves de cualquier longitud.

Otro sistema bastante utilizado es S-HTTP, una versión de HTTP que incorpora criptografía de clave pública para la autentificación y el intercambio seguro de datos. Sin embargo, S-HTTP sólo puede utilizarse para intercambiar datos entre clientes y servidores Web, mientras que SSL actúa de forma transparente para cualquier aplicación de comunicaciones TCP/IP.

Los siguientes enlaces proporcionan más información sobre temas relacionados con la seguridad y la criptografía en Internet:

• El RSA FAQ about cryptography, un extenso manual de referencia, muy actualizado, que describe el funcionamiento de la mayoría de los sistemas de cifrado y autentificación que se utilizan en la actualidad. Se puede encontrar en http://www.rsa.com/rsalabs/newfaq/.
• Netscape dispone de información detallada sobre el funcionamiento de SSL, y la forma de integrar este sistema en nuestros propios desarrollos. Se puede consultar una introducción general a SSL, los certificados de servidores y otros temas relacionados en http://search.netscape.com/newsref/ref/128bit.html.
• El W3 Consortium dispone de material de referencia sobre seguridad, en http://www.w3.org/Security/.

Los clientes Web muestran avisos de advertencia cuando la conexión pasa de modo normal a modo seguro y viceversa (el candado o llave abiertos de la esquina inferior izquierda de Netscape Navigator o Internet Explorer). A partir de este momento se puede asegurar la identidad del servidor remoto, y la total privacidad de los datos intercambiados. La siguiente pantalla muestra los detalles de una conexión segura establecida con una tienda electrónica.

Location: https://www.aberdeeninc.com/abcatg/sidecheck.htm

File MIME Type: text/html

Source: Currently in memory cache

Local cache file: none

Last Modified: 7 de noviembre de 1997 23:15:04 Local time

Last Modified: 7 de noviembre de 1997 22:15:04 GMT

Content Length: 27076

Expires: No date given

Charset: iso-8859-1

Security: This is a secure document that uses a medium-grade encryption key suited for U.S. export (RC4-Export, 128 bit with 40 secret).

Certificate: This Certificate belongs to:

www.aberdeeninc.com

Aberdeen LLC

Santa Fe Springs, California, US

This Certificate was issued by:

Secure Server Certification Authority

RSA Data Security, Inc.

US

Serial Number: 02:F3:00:1C:48

This Certificate is valid from Tue Aug 12, 1997 to Sat Aug 15, 1998

Certificate Fingerprint:

D6:26:95:63:07:90:F2:E2:21:50:AA:EE:4C:45:43:AF

Los clientes Web modernos disponen de una base de datos con los datos de varias autoridades de certificación, que se utilizarán para verificar las ‘identidades digitales’ de los servidores HTTP con los que se trate de establecer una conexión segura. El siguiente ejemplo muestra las características de la autoridad de certificación de Verisign.

Autor: Luis F. Romero
http://cdec.unican.es/libro/SeguridadCGI.htm

Escribe un comentario

Expresa tu opinión sobre este recurso y compártela con los demás.