Cinco Errores Comunes de “PKI DIY” a Evitar

En los más de 12 años que CSS ha estado ayudando a las organizaciones a implementar infraestructuras de clave pública, frecuentemente nos encontramos con situaciones en las que los componentes de PKI ya están presentes en el entorno. A menudo, se trata de una PKI antigua que alguien nuevo en la organización ha heredado y para la cual busca ayuda en su evaluación; a veces, es una implementación «temporal» que una organización busca mejorar. En otros casos, puede ser simplemente un diseño de PKI que un cliente desea que revisemos y sobre el cual proporcionemos comentarios antes de la implementación. En cualquier caso, estas instalaciones «hágalo usted mismo», como cualquier PKI, pueden generar problemas, dolores de cabeza y, ocasionalmente, incluso problemas más graves si se cometen errores durante el diseño, la implementación o la operación de la PKI. Y aunque a menudo es bastante fácil implementar componentes de PKI, la PKI tiende a ser una de esas tecnologías en las que se tiene exactamente una oportunidad de hacerlo bien: en el momento de la instalación. Después de eso, muchos parámetros quedan más o menos establecidos, y una nueva implementación se convierte en la única forma de corregir un error.

Teniendo esto en cuenta, esta no es de ninguna manera una lista exhaustiva, pero aquí hay cinco de los errores más comunes que vemos al encontrarnos con PKI «hágalo usted mismo»:

En muchos sistemas de TI, una imagen realmente vale más que mil palabras, y un diagrama de las «cajas y líneas» de la arquitectura constituye la mayor parte del diseño. Este es el caso de los diagramas de red, las arquitecturas de aplicaciones web/base de datos, las estructuras de directorio y muchos otros componentes de TI. Siguiendo esta mentalidad, muchos arquitectos de PKI primerizos se centran casi exclusivamente en la jerarquía de CA: la composición de las CA raíz sin conexión, las CA de política/intermedias y las CA emisoras en línea que conformarán la PKI.

Sin embargo, si bien la jerarquía de CA de una PKI es importante para el diseño, no es toda la historia. De hecho, generalmente ni siquiera es la mayor parte de la historia, cuando se trata de escalabilidad, disponibilidad, usabilidad o longevidad. Las «cajas y líneas» acaparan toda la atención, pero hay MUCHAS otras decisiones de diseño que son de igual o mayor importancia. Las políticas, los controles de seguridad, la planificación de CRL y revocación, los algoritmos y tamaños de clave, y los períodos de validez son algunos ejemplos de áreas que pueden tener un impacto más significativo y duradero en la utilidad de la PKI que la jerarquía de CA.

Un nivel de enfoque excesivamente alto en la jerarquía de PKI puede llevar a la tendencia a incluir más «cajas y líneas», lo que resulta en diseños que involucran más CA de las necesarias. Estas CA adicionales conllevan un costo: Hardware de servidor y HSM, licencias de SO, además del gasto operativo de tener más sistemas que monitorear.

A veces, es demasiado fácil hacer clic en «Siguiente».

Desafortunadamente, con la PKI, hay un gran número de aspectos de diseño que, una vez configurados, no pueden cambiarse sin una nueva implementación completa y, como se mencionó anteriormente, muchos de ellos pueden tener un impacto significativo en la utilidad a largo plazo de su PKI. Estos incluyen:

• Nombres de certificados de CA, tamaños de clave y algoritmos de firma: Estos forman parte del certificado de cada CA y no se pueden modificar. Y dado que los componentes de PKI perduran durante muchos años, las ramificaciones de estas decisiones pueden ser muy significativas.
• Puntos de distribución de CRL (CDP): Las ubicaciones de las CRL se incluyen en los certificados emitidos, por lo que modificarlas implica la reemisión de cada certificado.
• Políticas operativas y niveles de garantía específicos: En el momento en que emite su primer certificado —lo haya planificado o no—, establece la política de emisión para su CA. Y una vez que ha establecido el estándar en un determinado nivel, solo puede rebajarlo.

Demasiadas PKI se implementan con controles de seguridad inferiores a los deseados, con el fin de ahorrar tiempo o evitar esfuerzos operativos. Es crucial encontrar un equilibrio adecuado entre la facilidad de operación y un nivel de garantía suficientemente alto.

La PKI cuenta con una estructura bien definida para la definición de políticas y prácticas, en forma de Política de Certificados (CP) y Declaraciones de Prácticas de Certificación (CPS). Estos son marcos excelentes para definir los requisitos que rigen una PKI y los medios por los cuales una implementación cumpliría dichos requisitos. La creación de estos documentos puede ser una tarea desalentadora. Sin embargo, es importante señalar que la simple copia literal de los documentos CP/CPS de otra entidad no será suficiente; estas herramientas solo tienen valor si realmente representan los requisitos de PKI y los procesos operativos de su organización.

Desarrollar un proceso de emisión —que además sea seguro— puede requerir una cantidad considerable de planificación. Y si la PKI se utiliza para sistemas embebidos o productos o dispositivos habilitados para la red (el llamado "Internet de las Cosas"), desarrollar un proceso de emisión seguro y de alto volumen también es fundamental.

Sin embargo, un error común al implementar aplicaciones habilitadas para certificados es centrarse únicamente en el despliegue y en las tareas relacionadas con la implementación inicial de la aplicación. Pero los certificados caducan, y si la planificación no incluye todo el ciclo de vida del certificado, pueden surgir problemas importantes. La caducidad inesperada y no gestionada de los certificados puede provocar interrupciones significativas y gastos elevados.

Esta preocupación no se limita exclusivamente a la caducidad de los certificados. Dependiendo de la aplicación involucrada, la planificación de otros eventos del ciclo de vida del certificado, como la revocación o los procesos de archivo y recuperación de claves, puede ser incluso más importante que la planificación de la renovación de certificados.

La disponibilidad es un área clave en cualquier diseño de TI, pero en ciertos aspectos, la PKI introduce una "particularidad" en la disponibilidad que a veces no se comprende bien. Del mismo modo que su licencia de conducir sigue siendo válida y utilizable cuando el DMV está cerrado, los certificados digitales siguen siendo válidos y utilizables cuando una CA deja de funcionar. Lo único que no se puede hacer cuando una CA está inactiva es emitir nuevos certificados, lo cual, para la mayoría de las organizaciones, no es tan importante como asegurar que los certificados existentes sigan funcionando.

A pesar de esta distinción, a menudo se presta más atención a la disponibilidad de la CA que a la disponibilidad de CRL u OCSP, las cuales son siempre al menos igual de importantes. Si sus CRL o servidores OCSP no están disponibles, todos sus certificados pueden volverse inutilizables. La creación de CA emisoras adicionales "para respaldo" a veces resuelve un problema que no necesita ser resuelto, al tiempo que impone una mayor carga sobre la disponibilidad de CRL y OCSP.

La mayor parte de la información de este blog se aplica a casi cualquier PKI, independientemente del Software de CA utilizado.
Este último punto, sin embargo, se aplica más directamente a las Microsoft CA. Vemos que la mayoría de nuestros clientes utilizan Microsoft CA como un componente fundamental de PKI, en parte debido a las características y capacidades del Software, y en parte porque ya poseen las licencias. Pero hay algunas áreas, particularmente en lo que respecta a las plantillas de certificados predeterminadas, donde los usuarios pueden encontrarse con problemas.

Una instalación de "siguiente, siguiente, siguiente" de una Microsoft CA resultará en una CA ya configurada para emitir una serie de certificados diferentes; una de estas plantillas es "Controlador de Dominio", utilizada por los Controladores de Dominio para autenticar las comunicaciones entre sí. Curiosamente, los Controladores de Dominio son especiales, ya que están preprogramados para buscar continuamente CA en el entorno que puedan emitir certificados de Controlador de Dominio, y cuando encuentran una, se inscriben automáticamente. Esto puede o no ser un problema, pero a menudo no es el comportamiento esperado. A menos que se tomen medidas para evitarlo, después de la primera instalación de una CA en un bosque de Active Directory, cada Controlador de Dominio en el bosque tendrá un certificado en un plazo de 90 minutos.

Otra plantilla predeterminada que puede tener consecuencias adversas es la plantilla de certificado "Usuario". Esta tiene un nombre tentadoramente atractivo y a menudo se configura para la emisión a un gran número de usuarios empresariales. Sin embargo, esta plantilla combina varios casos de uso diferentes, incluyendo autenticación, Microsoft EFS y cifrado de correo electrónico. Estos certificados permiten a los usuarios cifrar archivos y correos electrónicos, pero no incluyen ninguna provisión para el archivo de claves, lo que puede poner a su organización en riesgo de pérdida de datos si los certificados se pierden o eliminan posteriormente.