Cinco Errores Comunes de “PKI DIY” a Evitar

In the 12+ years that CSS has been helping organizations deploy Public Key Infrastructures, we frequently run into situations where PKI components are already present in the environment. Often it’s an older PKI that someone new to the organization has inherited and wants help evaluating; sometimes it’s a “temporary” deployment that an organization is looking to improve upon. In others, it may simply be a PKI design that a customer wants us to review and provide feedback before deployment. In any case, these “Do-It-Yourself” installations, like any PKI, can create problems, headaches, and occasionally even more serious issues if mistakes are made during the design, deployment, or operation of the PKI. And while it’s often quite easy to deploy PKI components, PKI does tend to be one of those technologies where you have exactly one chance to get it right: at install time. After that, many parameters are more or less set in stone, and a re-deployment becomes the only way to fix a mistake.

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»:

Sobre-arquitectura de la jerarquía de CA

With many IT systems, a picture truly is worth a thousand words, and a diagram of the architecture’s “boxes and lines” makes up a majority of the design. This is the case for network diagrams, web/database application architectures, directory structures, and many other IT components. Following this mindset, many first-time PKI architects focus almost exclusively on the hierarchy of CAs: the makeup of Offline Root(s), Policy/Intermediate CAs, and Online Issuing CAs that will comprise the PKI.

However, while the CA hierarchy of a PKI is important to the design, it’s not the whole story. In fact, it’s usually not even the majority of the story, when it comes to scalability, availability, usability, or longevity. The “boxes and lines” get all the attention, but there are SO many other design decisions that are of equal or greater importance. Policies, security controls, CRL and revocation planning, algorithms and key sizes, and validity periods are some examples of areas that can have a more significant, lasting impact on PKI usefulness than the hierarchy of CAs.

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.

Sub-arquitectura de todo lo demás

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.

PKI enjoys a well-defined structure for policy and practices definition, in the form of Certificate Policy (CP) and Certification Practices Statements (CPS). These are excellent frameworks for defining the requirements governing a PKI, and the means by which an implementation would meet those requirements. Creating these documents can be a daunting task. However, it’s important to note that simply copying someone else’s set of CP/CPS documents verbatim will not suffice; these tools only have value if they truly represent your organization’s PKI requirements and operational processes.

Falta de planificación del ciclo de vida de los certificados

Developing an issuance process – which is also secure — can take a significant amount of planning. And if the PKI is being used for embedded systems or network-enabled products or devices (the so-called “Internet of Things”), developing a secured, high-volume issuance process is also critical.

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.

This concern isn’t exclusively tied to certificate expiration, either. Depending on the application involved, planning for other certificate lifecycle events such as revocation or key archival and recovery processes can be even more important than certificate renewal planning.

Planificación de disponibilidad mal enfocada

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.

Despite this distinction, there is often still more focus on CA availability than CRL or OCSP availability, which are always at least as important. If your CRLs or OCSP servers are not available, all of your certificates can become unusable. Creating additional issuing CAs “for backup” sometimes solves a problem that doesn’t need to be solved, while placing a bigger burden on CRL and OCSP availability.

Las "plantillas de la perdición"

La mayor parte de la información de este blog se aplica a casi cualquier PKI, independientemente del software CA utilizado.
Sin embargo, este último punto se aplica más directamente a las CA basadas en Microsoft. La mayoría de nuestros clientes utilizan las CA de Microsoft como componente básico de la PKI, en parte por las características y capacidades del software y en parte porque ya poseen las licencias. Pero hay algunas áreas, especialmente en lo que respecta a las plantillas de certificados predeterminadas, en las que los usuarios pueden tener 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.