Desarrollo de un plan de implantación, política y gestión de PKI

Una infraestructura de clave pública (PKI) es un conjunto de hardware, software, personas, políticas y procedimientos necesarios para crear, gestionar, distribuir, almacenar y revocar certificados digitales y gestionar el cifrado de clave pública. A menudo se dice (especialmente en la comunidad de consultores) que las implantaciones de PKI siguen la regla 80/20... 80% planificación y 20% ejecución. No se puede exagerar este concepto. Pero se aplica con más frecuencia a los puntos de decisión específicos de la PKI y relacionados con la criptografía, como los espacios de nombres, la longitud de las claves, los algoritmos hash de firma, etc. Son aspectos críticos, sin duda. Estos son críticos, sin duda... y difíciles, si no imposibles, de cambiar a posteriori. Pero igualmente importantes -especialmente en el espacio de la mediana y gran empresa- son los aspectos no técnicos y organizativos de la PKI.

Esta entrada del blog se centrará en las organizaciones de la empresa que son partes interesadas en la PKI, lo sepan o no, y en sus puntos de contacto que pueden aprovecharse para lograr una implantación óptima y, en última instancia, un ROI óptimo.

Antes de tomar decisiones de diseño técnico como las enumeradas anteriormente, deben analizarse detenidamente los casos de uso y desarrollarse, solicitarse, revisarse, revisarse si es necesario y, en última instancia, publicarse una política. Siguiendo la norma Certificate Policy/Certificate Practice Statement del RFC3647, las políticas especifican -entre otras muchas cosas- los suscriptores de certificados, el uso aceptable, los requisitos de revocación y las condiciones de control de acceso físico y lógico. La creación y adopción satisfactorias de una CPS aprobada, así como el cumplimiento de la misma, son las claves para poder afirmar que la PKI es auditable.

Si la PKI en cuestión está orientada al público y proporcionará algún nivel de confianza entre su organización y otras, debe especificarse por adelantado a nivel de proyecto que los departamentos jurídico y de control y auditoría/cumplimiento de la empresa participan en un proceso formal de revisión y aprobación. En nuestra opinión, incluso en el caso de una PKI exclusivamente interna, es una buena práctica que estos grupos participen en el desarrollo, revisión y aprobación de dichas políticas.

Dos organizaciones que pueden desempeñar papeles vitales en el espacio de la PKI empresarial son la gestión de cambios y la gestión de problemas. Aunque es improbable que necesiten participar en los procesos de toma de decisiones sobre el diseño técnico, una o dos horas de visión general de la implantación de la PKI y una sesión de preguntas y respuestas adjunta con estos grupos pueden resultar muy valiosas.

Los debates sobre PKI con el grupo de gestión de cambios deben centrarse en:

• Cambios necesarios en el entorno para la aplicación
• Definición y programación de cambios permanentes/recurrentes
• Tipos de cambio en estado estacionario y niveles de riesgo asociados

Estos son ejemplos de eventos PKI que, de conformidad con las normas formales de gestión de cambios de la empresa, deben presentarse, revisarse, aprobarse y registrarse.

• Publicación de certificados de CA raíz y despliegue de CA emisoras (estas tareas suelen requerir acceso a nivel de administrador de empresa)
• Implementación del control de acceso basado en funciones de PKI (por ejemplo, administradores de servidores locales, cambios en la configuración de registros de auditoría, delegación de plantillas de certificados, etc.)
• Publicación de la CRL de la CA raíz: Para esta tarea se puede establecer una solicitud de cambio "permanente" o recurrente. Si la CRL de una CA raíz fuera de línea debe generarse y publicarse manualmente, como suele ser el caso, contar con un proceso formal de gestión de cambios en torno a ella ofrece un par de ventajas.
  • Permite rastrear y notificar a las partes apropiadas (en el caso de la autenticación multiparte requerida y los controles de acceso físico segregados para los materiales criptográficos).
  • Permite que toda la empresa tenga un "par de ojos" en el proceso, reduciendo las posibilidades de que la tarea se pase por alto si se gestiona, por ejemplo, en los calendarios de una o dos personas.
• Revocación de cualquier autoridad de certificación en la jerarquía PKI
• Cualquier cambio en el modelo de seguridad de la PKI o en los controles de acceso
• Cualquier cambio en el límite de confianza de la PKI (en cualquier dirección)
• Cualquier cambio en toda la empresa necesario para las operaciones de PKI, como la activación de la autoinscripción de certificados en la política "Controladores de dominio predeterminados".
• Despliegue de nuevas plantillas de certificados; cambios (o supresiones) de plantillas existentes

Por lo general, las operaciones cotidianas de PKI, como las solicitudes y emisiones de certificados, se consideran fuera del ámbito de la gestión de cambios empresariales, a menos que las circunstancias específicas dicten lo contrario.

El equipo de gestión de problemas suele estar al tanto de quién es responsable de qué en toda la organización de TI. La razón para tenerlos en una visión general de PKI/Q&A (como se mencionó anteriormente) es hacer que esto también sea cierto para el entorno PKI.

Si se implanta una PKI empresarial sin la participación previa de esta organización, se pueden añadir retrasos significativos a la resolución de problemas y a los esfuerzos de análisis de la causa raíz. Por ejemplo, si el entorno Wi-Fi de la oficina de una empresa depende de la autenticación de certificados de extremo a extremo, debería saberse que se comprueba la validez de un certificado de servidor RADIUS NPS de Microsoft en caso de que todo el sitio se vea afectado por un corte de Wi-Fi.

Esto puede extenderse a otras áreas también (mucho más allá de la longitud de este blog), como las organizaciones corporativas de Help Desk y Desktop Support, especialmente donde la PKI y sus componentes se vuelven más críticos para la misión del usuario final.

En la política, el diseño, la aplicación, las pruebas y el apoyo, la implicación y la concienciación son fundamentales. La documentación (y mantenerla actualizada) es fundamental. Como idea final, el responsable del proyecto PKI de la empresa podría crear una lista de distribución de correo electrónico PKI que abarque todas estas organizaciones para, entre otras cosas, recibir actualizaciones periódicas sobre lo que se ha implantado, los problemas que han surgido (y cómo se han resuelto) y lo que está por venir... ¿necesitarán todos los servidores web internos SSL en una fecha determinada? ¿Se exigirán certificados de cliente el próximo trimestre para Wi-Fi o Direct Access? Hacia el final del periodo de validez de una CA, ¿ha llegado el momento de rodear los vagones y empezar a planificar la renovación?

Cuestiones todas ellas en las que Certified Security Solutions (CSS) puede ayudarle en lo que respecta a la definición de sus requisitos, la planificación y el planteamiento de la implantación.