Cinco errores comunes de la PKI "hágalo usted mismo" que debe evitar

En los más de 12 años que CSS lleva ayudando a organizaciones a desplegar Infraestructuras de Clave Pública, a menudo 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 quiere ayuda para evaluarla; a veces es una implantación "temporal" que una organización quiere mejorar. En otros casos, puede tratarse simplemente de un diseño de PKI que un cliente desea que revisemos y le proporcionemos información antes de su implantación. En cualquier caso, estas instalaciones "hágalo usted mismo", como cualquier PKI, pueden crear problemas, quebraderos de cabeza y, en ocasiones, problemas aún más graves si se cometen errores durante el diseño, la implantación o el funcionamiento de la PKI. Y aunque a menudo es bastante fácil desplegar componentes 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 están más o menos grabados en piedra, y una reimplantación se convierte en la única forma de corregir un error.

Teniendo esto en cuenta, no se trata en absoluto de una lista exhaustiva, pero he aquí cinco de los errores más comunes que vemos cuando nos encontramos con PKI "hágalo usted mismo":

En muchos sistemas informáticos, una imagen 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 directorios y muchos otros componentes de TI. Siguiendo esta mentalidad, muchos arquitectos de PKI principiantes se centran casi exclusivamente en la jerarquía de CA: la composición de la(s) raíz(es) fuera de línea, las CA de políticas/intermedias y las CA emisoras en línea que compondrán la PKI.

Sin embargo, aunque la jerarquía de CA de una PKI es importante para el diseño, no lo es todo. De hecho, normalmente ni siquiera es la mayoría cuando se trata de escalabilidad, disponibilidad, usabilidad o longevidad. Las "cajas y líneas" acaparan toda la atención, pero hay TAN 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 periodos 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 las CA.

Centrarse demasiado en la jerarquía de la PKI puede llevar a una tendencia a incluir más "cajas y líneas", lo que da lugar a diseños que implican más CA de las necesarias. Estas CA adicionales tienen un coste: servidor y HSM hardware, licencias de SO, además del gasto operativo de tener más sistemas que supervisar.

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

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

• Nombres de certificados de CA, tamaños de clave y algoritmos de firma: Forman parte del certificado de cada CA y no pueden modificarse. Y dado que los componentes de la PKI existen desde hace muchos años, las ramificaciones de las elecciones pueden ser muy significativas.
• Puntos de distribución de CRL (CDP): Las ubicaciones CRL se ponen en los certificados emitidos, por lo que cambiarlas significa que tienes que volver a emitir cada certificado.
• Políticas operativas y niveles de garantía específicos: En el momento en que emite su primer certificado, lo haya planeado o no, acaba de establecer la política de emisión de su CA. Y una vez que ha fijado el listón en un determinado nivel, sólo puede bajarlo.

Demasiadas PKI se implantan con controles de seguridad inferiores a los deseados, en aras de ahorrar tiempo o evitar esfuerzos operativos. Es importante encontrar un buen equilibrio entre la facilidad de uso y un nivel de seguridad suficientemente alto.

La PKI goza de una estructura bien definida para la definición de políticas y prácticas, en forma de Declaraciones de Política de Certificación (CP) y Prácticas de Certificación (CPS). Se trata de marcos excelentes para definir los requisitos que rigen una PKI y los medios por los que una implementación cumpliría dichos requisitos. Crear estos documentos puede ser una tarea desalentadora. Sin embargo, es importante tener en cuenta que no basta con copiar literalmente el conjunto de documentos CP/CPS de otra persona; estas herramientas sólo tienen valor si representan realmente su PKI de su organización y sus procesos operativos.

El desarrollo de un proceso de emisión, que además sea seguro , puede requerir una gran cantidad de planificación. Y si la PKI se utiliza para sistemas integrados o productos o dispositivos conectados a la red (la llamada "Internet de los objetos"), también es fundamental desarrollar un proceso de emisión seguro y de gran volumen.

Sin embargo, un error común a la hora de desplegar aplicaciones con certificados es centrarse sólo en la puesta en marcha y en las tareas relacionadas con el despliegue 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 causar importantes interrupciones y gastos.

Esta preocupación tampoco está ligada exclusivamente a la caducidad de los certificados. Dependiendo de la aplicación de que se trate, 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 del certificado.

La disponibilidad es un área clave para cualquier diseño de TI, pero en cierto modo, PKI da un "giro" a la disponibilidad que a veces no se comprende bien. Del mismo modo que el carné de conducir sigue siendo válido y utilizable cuando el Departamento de Tráfico 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 deja de funcionar es emitir nuevos certificados, lo que para la mayoría de las organizaciones no es tan importante como asegurarse de que los certificados existentes siguen funcionando.

A pesar de esta distinción, a menudo se sigue prestando más atención a la disponibilidad de CA que a la disponibilidad de CRL u OCSP , que siempre son al menos igual de importantes. Si sus servidores CRL u OCSP no están disponibles, todos los certificados pueden quedar inutilizables. La creación de CA emisoras adicionales "como copia de seguridad" a veces resuelve un problema que no es necesario resolver, al tiempo que supone una carga mayor para la disponibilidad de CRL y OCSP.

La mayor parte de la información de este blog se aplica a casi cualquier PKI, independientemente de la CA software utilizada.
Este último punto, sin embargo, se aplica más directamente a las CA basadas en Microsoft. Vemos que la mayoría de nuestros clientes utilizan las CA de Microsoft como bloque de construcción de la PKI, en parte por las características y capacidades de software, y en parte porque ya poseen las licencias. Pero hay algunas áreas, en particular en relación con las plantillas de certificados por defecto, en las que los usuarios pueden tener problemas.

Una instalación "siguiente, siguiente, siguiente" de Microsoft CA dará como resultado una CA que ya está configurada para emitir una serie de certificados diferentes; una de estas plantillas es "Domain Controller" (Controlador de dominio), que utilizan los Controladores de dominio para autenticar las comunicaciones entre sí. Curiosamente, los Controladores de Dominio son especiales, en el sentido de que están preprogramados para buscar continuamente CAs 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 CA en un bosque de Active Directory, cada controlador de dominio del bosque tendrá un certificado en 90 minutos.

Otra plantilla por defecto que puede tener consecuencias adversas es la plantilla de certificado "Usuario". Tiene un nombre tentadoramente atractivo, y a menudo se configura para su emisión a un gran número de usuarios de la empresa. Sin embargo, esta plantilla combina varios casos de uso diferentes, como la autenticación, Microsoft EFS y el cifrado de correo electrónico. Estos certificados permiten a los usuarios cifrar archivos y correo electrónico, pero no incluyen ninguna disposició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.