Vigilancia de seguridadImplementación de una PKI confiable globalmente

John Morello

Esta columna incluye información preliminar que está sujeta a cambios.

Una infraestructura de claves públicas, o PKI, es un elemento fundamental para crear confianza entre diferentes aplicaciones, sistemas operativos y dominios de identidad. Se crea a partir de un modelo de confianza jerárquico en el que las entidades finales confían en una clave común del nivel raíz más alto y, por lo tanto, se confía implícitamente en cualquier otra clave firmada por dicha raíz.

Gracias a esta estructura, una PKI bien diseñada puede ampliarse fácilmente agregando entidades emisoras de certificados (CA), sin introducir cambios en las entidades finales.

Normalmente, las PKI se implementan de una de estas dos formas. El enfoque más común consiste en adquirir los certificados necesarios de uno de los proveedores de raíces globales en los que se confíe implícitamente, como por ejemplo, Cybertrust o VeriSign. Estos certificados se usan con frecuencia para proteger el tráfico de los sitios Web, pero también pueden usarse para cifrar redes privadas virtuales (VPN), firmar correo electrónico y tareas similares. Dado que estas raíces globales están integradas en todos los exploradores Web y sistemas operativos modernos, este método puede ampliar fácilmente una relación de confianza a través de límites organizativos. No obstante, puesto que estos certificados sólo se adquieren si son necesarios, puede resultar costoso implementar este enfoque ampliamente dentro de una gran organización.

El modelo de PKI interna ha pasado a ser recientemente más común. Tal como sugiere el nombre, una PKI interna sólo es confiable dentro de la propia red de una organización. Este modelo proporciona a las organizaciones una forma más barata de asignar recursos a los usuarios y los dispositivos informáticos de su red usando certificados. Este enfoque se suele usar para facilitar tecnologías como el inicio de sesión con una tarjeta inteligente, el sistema de cifrado de archivos (EFS) y la protección de conexiones de redes inalámbricas. La desventaja es que como estos certificados no son confiables globalmente, no resultan apropiados para aplicaciones que se comunican con el exterior. Por consiguiente, la mayoría de las organizaciones que han implementado PKI internas suelen adoptar un enfoque híbrido mediante la compra de certificados para aplicaciones públicas de una de las raíces confiables globalmente.

Pero, ¿y si pudiera obtener lo mejor de ambos métodos? ¿Qué le parecería si su organización pudiera ejecutar su propia PKI (con el ahorro de costos que supone la emisión de certificados internos) y al mismo tiempo proporcionara certificados confiables públicamente, todo esto desde su propio sistema local? Una solución de este tipo ofrecería las ventajas de una PKI interna (como la integración de Active Directory®, la inscripción automática y el soporte de TI traducido), así como la ventaja clave de una raíz confiable globalmente. La universidad estatal de Louisiana (LSU) tiene exactamente este sistema. En esta entrega de Vigilancia de seguridad, examino la solución que implementamos en LSU, explico su diseño técnico y resalto las prácticas recomendadas que deben usarse al implementar un sistema similar. Debe tenerse en cuenta que la solución que voy a describir satisfacía nuestras necesidades concretas, con un entorno y unos recursos y unos requisitos empresariales determinados. Debe evaluar de antemano todos estos aspectos de su empresa a fin de determinar el tipo de solución que sea adecuado para usted.

Forma en que LSU crea una PKI

LSU es una universidad en la que se realizan importantes investigaciones y que cuenta con más de 40.000 estudiantes, profesores y empleados. Tiene muchos sitios Web a disposición del público, y muchos de estos sitios requieren Seguridad de la capa de transporte (TLS), que es el término adecuado para los certificados de capa de sockets seguros (SSL). LSU solía invertir miles de dólares anualmente en certificados de los proveedores de raíces confiables globalmente.

Al mismo tiempo, LSU tenía otros objetivos de seguridad de TI que podían mejorarse enormemente con una PKI interna bien diseñada. Dados los objetivos y los requisitos de LSU, se podía suponer que elegiríamos un modelo híbrido. Sin embargo, optamos por un enfoque que creímos más innovador.

Trabajamos con una de las raíces confiables globalmente, Cybertrust, para implementar una CA en las instalaciones de LSU que fuera subordinada de una CA raíz de Cybertrust (consulte la figura 1). Cybertrust ofrece este servicio en su programa OmniRoot. En este escenario, LSU crea y usa una CA que se ejecuta localmente en equipos que son propiedad de LSU. No obstante, a diferencia del modelo interno descrito anteriormente, la CA de LSU no está autofirmada y su clave (así como las claves que ésta firme) es confiable implícitamente en casi todos los sistemas operativos y exploradores modernos. Técnicamente, este diseño es una extensión lógica de la apertura de los estándares x.509. Dado que una PKI se crea a partir de estos estándares, se pueden conectar sistemas creados por distintos proveedores en la misma jerarquía general. Dicho esto, lo que resulta particularmente interesante acerca de la solución OmniRoot son las condiciones de uso para el servicio.

Figura 1** Certificado de raíz global de Cybertrust **(Hacer clic en la imagen para ampliarla)

El servicio OmniRoot está específicamente diseñado para el tipo de implementación de PKI que llevamos a cabo en LSU. En el programa OmniRoot, las organizaciones pagan a Cybertrust una cuota anual fija por participar en éste, y después pagan una cuota por certificado sólo en el caso de los certificados creados para uso público. En otras palabras, LSU puede emitir tantos certificados como necesite para uso interno sin preocuparse por el aumento de costo debido a las cuotas por certificado. Mientras tanto, el costo de los certificados a disposición del público es ahora significativamente más barato de lo que se pagaba cuando la universidad adquiría certificados en los casos necesarios.

Para ser más precisos, los certificados internos y los certificados públicos son idénticos desde un punto de vista técnico. Se emiten desde la misma cadena de CA, tienen la misma eficacia criptográfica y se suministran a través del mismo sistema de autoridad de registro. La única diferencia entre ambos son los términos de la licencia.

Finalmente, hemos podido ampliar y mejorar la plataforma de seguridad de TI de LSU a un costo más bajo. Este logro creó una gran razón empresarial para este tipo de solución PKI en LSU. Ahora echaremos un vistazo a los detalles más técnicos de la implementación.

Jerarquía PKI

La jerarquía PKI de LSU se crea mediante un diseño de dos niveles en el que Cybertrust administra el nivel raíz y una CA emisora en línea se ejecuta en LSU (consulte la figura 2). El nivel raíz forma el delimitador de confianza en la jerarquía. En otras palabras, la relación de confianza de todos los certificados emitidos por cualquier CA de la jerarquía se encuentra bajo la CA raíz (consulte la figura 3). Por lo tanto, la CA raíz forma el enlace común entre todas las CA, los certificados y las entidades finales de la jerarquía. Como la raíz global de Cybertrust ya está integrada en Windows® y casi todos los sistemas informáticos modernos, este enlace común se extiende automáticamente más allá de la red de LSU.

Figure 2 Jerarquía PKI de dos niveles

Figura 3** Certificado emitido desde la CA emisora de LSU **(Hacer clic en la imagen para ampliarla)

Cybertrust administra la CA raíz en uno de los servicios de alojamiento seguros. El servicio de alojamiento usa eficaces controles de seguridad física, en los que se incluyen capturas manuales, bloqueos biométricos y una cámara de almacenamiento totalmente revestida de cobre. Cybertrust sólo emite certificados a las CA emisoras de las organizaciones que han demostrado cumplir sus directivas de seguridad y certificado.

La CA emisora de LSU es un sistema orientado a entidades finales que es responsable de proporcionar certificados a la población de usuarios y equipos de LSU. Su certificado lo firma la CA de Cybertrust que se encuentra por encima en la jerarquía y ésta emite certificados que se enlazan a través de ella misma con la CA raíz de Cybertrust (consulte la figura 3).

El SO y hardware emisores

LSU usa Windows Server® 2003 Enterprise Edition con Service Pack 1 para la CA emisora. El servicio de la entidad emisora de certificados de Windows Server 2003 ofrece muchas funciones, como por ejemplo, el archivo de claves, las listas de revocación de certificados (CRL) delta y las plantillas de la "versión 2". La instancia de Windows que se usa como CA emisora se crea de acuerdo con la directiva de creación estándar de Windows Server de LSU. Se actualiza con todas las actualizaciones de seguridad pertinentes y se administra mediante las prácticas de administración de cambios estándar de LSU y las herramientas de actualización y de inventario de software. En resumen, aunque existen algunos aspectos únicos en la administración del mismo servicio CA, el sistema operativo y el hardware de servidor base se integran fácilmente en las operaciones de TI existentes en la organización.

Además de seguir las prácticas recomendadas estándar de LSU para la instalación del servidor, empleamos el Asistente de configuración de seguridad (SCW), que está disponible en Windows Server 2003 Service Pack 1. SCW usa una base de datos que contiene matrices de dependencia de las distintas cargas de trabajo que pueden ejecutarse en Windows Server y la configuración de seguridad que requieren estas cargas de trabajo. Esta base de datos incluye las dos funciones principales que proporcionará la CA: el mismo servicio CA e IIS (que proporciona el sitio Web de autoservicio de PKI).

Con ayuda de SCW, creamos fácilmente una plantilla de seguridad que deshabilitó todos los servicios que no eran necesarios para ejecutar estas cargas de trabajo y reforzamos la pila de red del servidor. Después usamos scwcmd.exe para transformar esta plantilla en un objeto de directiva de grupo (GPO) de forma que pudiéramos aplicarlo al servidor en el nivel de unidad organizativa. Este enfoque simplifica la ampliación y la recuperación de desastres, ya que la configuración de seguridad basada en funciones de una CA de LSU se almacena actualmente en Active Directory, en lugar de ser específica de un equipo.

La CA emisora de LSU se incorpora a un servidor IBM xSeries 346 con dos procesadores Intel Xeon a 3,2 GHz, 4 GB de RAM y cinco discos duros SCSI de 146 GB. Teniendo en cuenta las exigencias de rendimiento del servicio CA y el hecho de que LSU usa un módulo de seguridad de hardware, esta plataforma deberá proporcionar una duración y un espacio en cabeza considerables para el crecimiento.

Seguimos prácticas recomendadas estándar para separar bases de datos y archivos de registro en ejes físicos independientes creando dos matrices RAID 1. El quinto disco duro se reserva como "reposición en directo" y está disponible para cualquiera de estas matrices. Montamos la primera matriz como nuestro volumen de sistema, que es donde guardamos la base de datos de CA. La segunda matriz se usa para archivos de registro y para otros tipos de archivos de datos, como por ejemplo, las CRL. La base de datos de CA se basa en la misma tecnología Jet que existe en otras partes de Windows, como Active Directory; por lo tanto, aquí se aplican las mismas prácticas recomendadas de mantenimiento y configuración de discos que en otras soluciones de almacenamiento basadas en Jet.

Un módulo de seguridad de hardware (HSM) es un dispositivo de hardware dedicado que se administra independientemente del sistema operativo. Los HSM, normalmente, se suministran como adaptadores PCI, pero también están disponibles como dispositivos basados en redes. Estos módulos proporcionan un almacenamiento de hardware seguro para las claves de CA, así como un procesador criptográfico dedicado para acelerar las operaciones de firma y cifrado. Windows usa los HSM a través de las interfaces CryptoAPI; se considera que el HSM es como un dispositivo CSP (proveedor de servicios criptográficos). El programa OmniRoot requiere que cada CA use al menos un HSM certificado por FIPS 140-2 de nivel 3 (los dispositivos de nivel 4 son bastante poco frecuentes) para la generación y el almacenamiento de claves. Al tratarse de un dispositivo único y altamente seguro, HSM supone una importante inversión financiera. Los precios de venta de los HSM basados en PCI se encuentran generalmente entre los 10.000 y los 15.000 dólares.

En el diseño de LSU, se usa un nCipher nShield 500 TPS (modelo de 500 transacciones por segundo) como un HSM conectado directamente. ("Conectado directamente" significa que está en el interior del servidor y que sólo está disponible para el uso de dicho servidor, en lugar de ser un HSM basado en redes que pueda ser compartido por varios hosts. El HSM es un dispositivo FIPS 140-2 de nivel 3 y proporciona protección K de N del material de claves. HSM ofrece una protección significativa frente a la posibilidad de que las claves privadas vean comprometida su seguridad: para que un atacante pueda tener acceso a la clave, necesitaría poseer tanto el almacenamiento de HSM como un número concreto de símbolos de acceso y los PIN correspondientes.

Es esencial destacar que los HSM están diseñados para impedir que personas malintencionadas puedan alterar su contenido. Por lo tanto, los HSM limitan estrictamente el número de intentos de inicio de sesión fallidos consecutivos. En el diseño de LSU, el almacenamiento se borra de forma irrevocable después de 10 intentos fallidos consecutivos.

Tenemos una sola CA en nuestra instalación, así que el recargo en precio para un HSM basado en redes no es justificable. Ahora bien, si una organización planea implementar dos o más CA, puede resultar considerablemente más barato adquirir un único HSM basado en redes y compartirlo entre las CA. Este enfoque también facilita la administración de símbolos, ya que el mismo conjunto de símbolos puede proteger todo el almacenamiento de claves.

Active Directory e inscripción

Una de las principales ventajas de una solución PKI basada en Windows es que el suministro de certificados se realiza sin necesidad de instalar software adicional en las entidades que participan en la PKI. En lugar de eso, la mayor parte del suministro de certificados se puede administrar autónomamente y sin que lo advierta el usuario final a través de una combinación de la inscripción automática y directivas de grupo. LSU usa esta tecnología para distribuir automáticamente certificados de equipo a equipos que son miembros de su Active Directory. Además, usamos un sitio Web personalizado para proporcionar funciones de solicitud de certificados de autoservicio para hosts que no sean de Windows.

Como mencionamos anteriormente, el programa OmniRoot distingue entre los certificados de uso público y los certificados de uso interno. Los certificados se consideran públicos si son usados por sistemas y usuarios que no forman parte de la organización de LSU (por ejemplo, cuando un posible estudiante envía un formulario de admisión a través de un sitio Web protegido por SSL). Los certificados usados dentro de la organización de LSU (como los que se usan para cifrar datos en los servidores de LSU) se consideran internos.

Dado que el costo del programa OmniRoot se basa en el número de certificados orientados al público, necesitamos poder hacer un seguimiento del número de certificados públicos que se envían y a quién se envían. De este modo, en cualquier certificado cuyo fin sea público, el nombre distintivo de la plantilla empieza por "PublicCertificate" y el nombre para mostrar empieza por "Public Certificate". Por ejemplo, la plantilla de certificado TLS de LSU orientada al público se basa en la plantilla de Windows Web Server predeterminada y se denomina Public Certificate LSU Web Server (servidor Web de LSU de certificados públicos). Para los servidores Web que se usan internamente, tenemos una segunda plantilla denominada Internal Certificate LSU Web Server (servidor Web de LSU de certificados internos). Técnicamente, las dos plantillas son idénticas; las diferencias de nombre sólo sirven para facilitar la contabilidad.

En el caso de que sea necesario realizar inscripciones masivas, como por ejemplo, la inscripción de departamentos enteros para la obtención de certificados que se puedan usar con IPSec, se usa la inscripción automática. Se trata de una herramienta sencilla y muy eficaz incorporada en Windows. Desde el punto de vista de un administrador de PKI, la única acción necesaria consiste en cambiar la lista de control de acceso de la plantilla para otorgar a cualquier grupo de usuarios o equipos que necesitan certificados el derecho de inscribirse automáticamente. A continuación, estas entidades podrán comprobar automáticamente Active Directory, enumerar las plantillas a las que tienen acceso de inscripción automática, buscar las CA con esas plantillas e inscribirse automáticamente para obtener certificados. Además, la característica de la inscripción automática garantiza la sustitución de los certificados si se sustituye una plantilla y se renueva automáticamente antes de que caduque.

Cuando no se trate de una inscripción masiva, como el suministro de certificados a los servidores Web, usamos un sitio Web de autoservicio que permite a los usuarios solicitar certificados a través de un explorador Web. Este sitio es una versión personalizada de las páginas de inscripción Web que se entregan con Windows Server 2003 (el directorio virtual /certsrv); nuestra implementación incluye la aplicación de marcas Web estándar de LSU y completa de forma previa las entadas predeterminadas correctas en la página de solicitud. Además, usamos el módulo de salida predeterminada del servicio CA de Windows para enviar un mensaje por correo electrónico automáticamente a nuestro equipo de administración de PKI cuando una solicitud enviada a través de este sitio requiere aprobación.

Diseño de revocación

Todos los certificados tienen un período de validez. De vez en cuando, LSU tiene que invalidar algunos certificados antes de que finalice su período de validez (por ejemplo, si se da a un empleado un certificado con un período de validez que caduca en mayo de 2007, pero ese empleado deja LSU en enero de 2007). Este tipo de revocación se lleva a cabo con CRL, que son archivos que contienen una lista de números de serie de certificados firmados por una CA. Los números de serie incluidos en una CRL hacen referencia a certificados cuyo período de validez no ha caducado, pero en los que LSU ya no confía. Los clientes pueden descargar esta CRL y comprobarla para determinar la validez de los certificados.

Todos los certificados x.509 v3 (excepto el mismo certificado CA raíz) deben tener un puntero hacia una CRL válida. Este puntero se conoce como punto de distribución CRL o CDP. El punto de distribución CRL se incluye en el mismo certificado (consulte la figura 4) y no se puede modificar una vez emitido un certificado. La CRL es fundamental a la hora de garantizar que los certificados de una CA son válidos. Por lo tanto, nos aseguramos de que las CRL de LSU sean físicamente redundantes, altamente disponibles y que las organizaciones externas pueden tener acceso a ellas.

Figura 4** Punto de distribución CRL de LSU **(Hacer clic en la imagen para ampliarla)

Una CA basada en Windows Server que esté integrada en Active Directory (como la de LSU) publica automáticamente su CRL en Active Directory con lo que hace que sea accesible a través del Protocolo ligero de acceso a directorios (LDAP). La ubicación de publicación predeterminada es el contenedor CDP (consulte la figura 5) que se encuentra dentro del contenedor de servicios de claves públicas del bosque. Esta ubicación de publicación es una opción excelente, ya que proporciona la creación de réplicas automática, tolerancia a errores y una ubicación para las búsquedas de CDP.

Figura 5** El contenedor CDP **(Hacer clic en la imagen para ampliarla)

No obstante, en el diseño de LSU hay muchos equipos que no tienen Windows ni Active Directory pero que emplean la PKI. Y aunque LSU es una gran organización, la gran mayoría de los usuarios se encuentran en la misma red del campus universitario (con una red troncal de 10 Gbps), lo que minimiza las ventajas de la publicación de CDP basada en Active Directory.

Por consiguiente, sólo publicamos nuestra CRL en una ruta de acceso HTTP, lo que facilita la creación de una plataforma de alojamiento redundante (nuestro sitio Web principal ya está reflejado). Esto también elimina las posibles complicaciones asociadas a la habilitación de búsquedas LDAP de cliente. Publicamos nuestra CRL diariamente y las CRL delta cada hora.

Futuros desarrollos

Mientras nuestra PKI proporciona una robusta solución de seguridad para la comunidad universitaria, planeamos la mejora de sus posibilidades. Windows Vista™ y la siguiente versión de Windows Server (cuyo nombre de código es "Longhorn") proporcionarán numerosas posibilidades de administración de claves nuevas que planeamos investigar. Estamos particularmente interesados en el cliente OCSP (Certificate Status Protocol) planeado y en las posibilidades de respondendor, en la compatibilidad con la criptografía de curva elíptica y los algoritmos SHA-256, así como en una interfaz de inscripción automática mucho más mejorada. Asimismo, está programado que Windows XP Service Pack 3 incluya una característica conocida como movilidad de credenciales, que proporcionará una movilidad segura a los pares de claves sin la sobrecarga asociada a los perfiles móviles. Finalmente, estamos investigando el uso del Certificate Lifecycle Manager (actualmente está disponible en beta) a fin de mejorar nuestras capacidades de administración y generación de informes.

En resumen, la PKI de LSU proporciona a la universidad un servicio de seguridad base que se usa para muchas funciones de TI fundamentales. Con el servicio OmniRoot de Cybertrust podemos ejecutar una PKI que esté bien integrada con otros sistemas de TI de LSU, pero cuya confiabilidad se extienda globalmente. Asimismo, mediante la integración de la solución en el servicio CA de Windows, contamos con eficaces capacidades de administración y suministro de certificados, así como una excelente integración con nuestro sistema de administración de identidades y directorio existentes. En resumen, la visión de PKI basada en una sólida seguridad y una confianza perfecta ya está convirtiéndose en realidad en LSU.

John Morello se graduó Summa Cum Laude en la universidad estatal de Louisiana y trabajó seis años en Microsoft como consultor senior en los Servicios de consultoría de Microsoft. Durante el tiempo que estuvo en MCS, creó varias PKI para clientes estratégicos como Deloitte, GE y varias organizaciones federales. Actualmente actúa como jefe de seguridad de la información (CISO) en la universidad estatal de Louisiana.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.