Por lo tanto, se le ha asignado la tarea cada vez más importante de crear una nueva PKI para su organización. Probablemente se esté preguntando: “¿Cuáles son los estándares de la industria para ejecutar una PKI?” ¡Pues usted ha venido al lugar correcto! Bueno, a menos que quieras leer El diseño PKI de 128 páginas que deben seguir las autoridades de certificación públicas Por suerte para todos los demás, lo he leído, así que tú no tienes que hacerlo. Y no te preocupes, no voy a hacer una lista larga para asustarte y contratar a un consultor de PKI. Sin embargo, es posible que me salte algunas definiciones y, para ello, le recomiendo que primero vea nuestra serie Conceptos básicos de PKI en YouTube.
Al crear una nueva Autoridad de Certificación hay muchas partes móviles que debemos considerar. Lo primero es lo primero: existe la infraestructura necesaria para ejecutar la CA (tenga en cuenta la disponibilidad del sistema). A continuación, ¿cómo vamos a distribuir los certificados? Aún más importante, ¿cómo vamos a rotar los certificados?
El primer paso para diseñar su sistema es decidir Qué jerarquía de CA necesita. Recomendamos tener una PKI de dos niveles. Esto le permite tener una CA raíz y luego tener varias CA emisoras para diferentes usos (recuerde, incluso si en este momento solo necesita una CA emisora, las CA raíz pueden ser válidas por hasta 20 años. Por lo tanto, planificar con anticipación siempre es bueno en PKI).
Si bien crear una CA puede parecer tan simple como seguir una guía y hacer clic en un asistente en Windows, las CA tienen muchos componentes:
El primero es un módulo de seguridad de hardware. Los HSM están diseñados para proteger sus claves de los hackers. Son tan seguros que incluso si los hackers logran ingresar a su CA, no podrán extraer las claves ya que están en un HSM a prueba de manipulaciones. Si bien los HSM pueden ser complicados de administrar y son más costosos que un automóvil, ahora puede crear HSM administrados en Azure o incluso crear una CA usando Key Vault para poner esta tecnología a disposición de todos. Si es usuario de Azure, no hay excusa para no configurar esto como parte de su PKI.
El segundo actor clave aquí es la autoridad certificadora, la entidad que emitirá los certificados. La CA debe ser un servidor altamente custodiado, con acceso restringido, parcheado diligente y se recomienda que este servidor se utilice únicamente para este propósito. Esto reduce la superficie de ataques al limitar los servicios disponibles en el servidor. Un buen consejo para esto es que si lo hace en su centro de datos local, puede usar una pequeña máquina virtual para la CA.
Una vez que haya configurado la CA, le recomendamos configurar pruebas automatizadas que emitirán un certificado cada pocos minutos para garantizar que la CA esté activa y emita certificados (Nota: asegúrese de que la plantilla para este certificado de prueba no almacene el certificado en la base de datos). Las CA antiguas no pueden escalar a tantos certificados.
A continuación tenemos que configurar la lista de revocación de certificados (CRL). Esta es una lista donde se enumeran los certificados revocados y se verifica cada vez que se autentica utilizando un certificado. Las CA de Webtrust tienen una vida útil de la lista de revocación de 7 días, esto significa que cada 7 días se emite una nueva. Antes de ejecutar y configurar el suyo en 1 día para asegurarse de tener siempre la lista más reciente, tengo una pregunta para usted: ¿con qué frecuencia revoca un certificado? Si normalmente no revoca los certificados, dejarlos en aproximadamente 7 días ahorra interrupciones relacionadas con la CRL, ya que sus dispositivos pueden almacenar en caché la CRL durante 7 días en lugar de obtener una nueva cada día.
Si bien el tiempo de actividad es importante para la CA, no es la parte más crítica del sistema. Si la CA está inactiva, no podrá emitir certificados durante el tiempo que esté inactiva. Sin embargo, si la CRL o el OCSP están inactivos, todos sus certificados no podrán autenticarse hasta que se restablezcan la CRL o el OCSP. Le recomendamos que tenga una configuración de CRL con redundancia geográfica más sólida. Por ejemplo, para EZCA utilizamos una CDN con redundancia geográfica y el probador la llama cada pocos minutos y, si la CRL está inactiva, tiene propiedades de recuperación automática que Indique a EZCA que cree una nueva CRL para reducir el tiempo de inactividad causado por errores de CRL.
CRLs can get very long, this can take its toll on and strain your network. This is the case even on some devices such as network adapters that cannot hold such large files. To help with this, the PKI industry came up with OCSP. This is a protocol where the device asks the OCSP server whether a certificate is valid or not and the server responds with a yes or no. This reduces the overhead of verifying certificates on the client side. While OCSP is great, not all devices support it, so make sure your devices do.
Las CRL pueden ser muy largas, lo que puede pasarle factura y sobrecargar su red. Este es el caso incluso en algunos dispositivos, como adaptadores de red, que no pueden contener archivos tan grandes. Para ayudar con esto, la industria PKI creó OCSP. Este es un protocolo en el que el dispositivo pregunta al servidor OCSP si un certificado es válido o no y el servidor responde sí o no. Esto reduce la sobrecarga de verificar certificados en el lado del cliente. Si bien OCSP es excelente, no todos los dispositivos lo admiten, así que asegúrese de que sus dispositivos sí lo admitan.
El uptime de OCSP es primordial para la autenticación de su certificado, ya que en la mayoría de los casos (no hablaremos de engrapado de OCSP ya que no sabemos cómo está utilizando sus certificados). La verificación de OCSP es en tiempo real, lo que significa que si su servidor OCSP no funciona, sus certificados no serán validados, teniendo una menor tolerancia a errores que las CRL que se pueden almacenar en caché. Recomendamos tener una implementación con redundancia geográfica y ejecutar ejecutores cada pocos segundos para garantizar que todos sus servidores OCSP estén en funcionamiento.
Ahora que hemos planificado el lado de la infraestructura, debemos descubrir cómo va a distribuir sus certificados. Al planificar esto, intente utilizar métodos que puedan automatizarse, nadie quiere rotar los certificados manualmente, no solo es aburrido, pero también es una acción muy costosa que puede provocar cortes.
La inscripción web es donde el usuario va a un sitio web y solicita un certificado. Si bien es posible que sea fanático de los clásicos como inscripción web de ADCS mediante Internet Explorer, existen PKI modernas que tienen portales web donde puede administrar certificados de autoservicio e incluso integrarse con servicios de Azure como Key Vault para permitir la rotación automática de certificados.
Mientras que en el pasado tenía todos sus dispositivos en una red y podía usar GPO para enviar certificados, con la fuerza laboral distribuida de hoy necesita un MDM como Intune para emitir certificados usando SCEP. Esto permite a sus usuarios obtener los certificados en sus dispositivos sin tener que hacer nada. Intune también se encargará de la rotación automática de los certificados.
Durante nuestro tiempo en Keytos, hemos visto a muchas personas usar certificados para el desarrollo desde autenticación de certificado de Azure IoT hasta autenticación basada en cliente en Azure . Para habilitar esto, deberá utilizar una CA que tenga API y guías y ejemplos de código fáciles de seguir para ayudarlo a comenzar y reducir su tiempo de desarrollo.
ACME se ha convertido en la forma más popular de crear certificados para sitios web. Sin embargo, los proveedores de PKI heredados como ADCS no son compatibles con ACME. Recomendamos utilizar una autoridad de certificación privada que admita acme para permitir que sus sitios internos utilicen las mismas herramientas que sus sitios externos para automatizar la emisión de su certificado.
Ahora que hemos analizado las mejores prácticas para crear una autoridad de certificación, está listo para crear su propia CA. Sin embargo, si no tiene ganas de construir toda esta infraestructura y prefiere una CA en la nube, lo invitamos a consultar EZCA, nuestra CA basada en la nube con funciones nativas de administración de certificados de Azure que le permite crear y administrar sus autoridades de certificación en minutos y no preocuparse por la seguridad y el tiempo de actividad, nosotros ocúpate de eso también. ¿La mejor parte? Comienza en $200 por CA por mes (más barato que ejecutar todos estos servidores en Azure), si desea obtener más información al respecto o simplemente desea conversar sobre PKI, puede hablar con nuestros expertos en PKI y obtenga más información sobre cómo puede modernizar su PKI.
