PKI, acrónimo de Infraestructura de Clave Pública , es un conjunto de roles, procedimientos y políticas necesarios para crear, distribuir, administrar, usar y revocar certificados digitales, así como para gestionar el cifrado de clave pública. PKI se utiliza para confirmar la identidad de un usuario al proporcionar la propiedad de una clave privada. Es un servicio de confianza que verifica que el remitente o receptor de datos sea quien dice ser.

La PKI se basa en componentes y procedimientos para gestionar los pares de claves (pares de claves públicas y privadas).

Una PKI típica se compone de los siguientes componentes:

Autoridad de certificación (CA): Un confiable CA Es la única entidad en PKI que puede emitir certificados digitales confiables. La CA acepta solicitudes de certificados y verifica la información proporcionada por los solicitantes basándose en... gestión de certificados Política. La CA firmará los certificados con su clave privada y los emitirá a los solicitantes si la información es legal.
Autoridad de registro (RA): La RA se encarga de recibir las solicitudes de firma de certificados para la inscripción inicial o renovación de certificados de usuarios, servidores y otras aplicaciones. La RA verifica la identidad de una entidad final y reenvía la solicitud a una autoridad de certificación (CA).
Clave pública: La clave pública se puede distribuir ampliamente y no requiere almacenamiento seguro. Su clave privada correspondiente solo puede descifrar mensajes o datos cifrados por la clave pública.
Llave privada: El destinatario utiliza las claves privadas para descifrar el mensaje o los datos cifrados con su clave pública correspondiente. Esto establece la propiedad del par de claves, garantizando así que el mensaje solo sea leído por las partes autorizadas.
Autoridad de certificación raíz (CA raíz): Un certificado se considera válido cuando lo firma una CA raíz de confianza. Una CA raíz tiene derecho a verificar la identidad de una persona y firma el certificado raíz que se distribuye al usuario.
Autoridad de certificación intermediaUna CA intermedia también es una CA de confianza y funciona como enlace entre la CA raíz y el certificado de cliente que el usuario solicita. Dado que la CA raíz ha firmado y confía en la CA intermedia, los certificados generados por esta también son de confianza.
Módulo de seguridad de hardware: A Módulo de seguridad de hardware No es un componente obligatorio de una PKI, pero mejora su seguridad al implementarse. Este dispositivo protege y gestiona las claves digitales y sirve como base para construir una infraestructura segura. PKI empresarial Infraestructura. El HSM gestiona el ciclo de vida completo de las claves criptográficas, incluyendo la creación, rotación, eliminación, auditoría y soporte para API Para integrar con varias aplicaciones.

Ahora que tenemos una idea bastante clara sobre algunos de los componentes de PKI, hablemos de los diferentes proveedores de PKI y sus mejores prácticas:

PKI de Microsoft

A continuación se presentan algunas prácticas recomendadas para utilizar Microsoft PKI de manera eficaz.

Haga un plan detallado de su infraestructura PKI antes de la implementación.
Evite instalar ADCS en un controlador de dominio.
La CA raíz debe ser independiente y sin conexión.
No emita certificados a la entidad final desde una CA raíz.
Habilitar eventos de auditoría tanto para la CA raíz como para la CA emisora.
Proteja la clave privada con HSM (FIPS 140-2 nivel 3)
Instale Enterprise CA solo si su CA emite un certificado para dispositivos o usuarios.
No se recomienda utilizar plantillas de certificado predeterminadas.
El punto de distribución de CRL debe tener alta disponibilidad.
Publicar la CRL de CA raíz en el directorio activo.
El algoritmo hash debe ser al menos SHA-2 (SHA de 256 bits).
El período de validez del certificado de entidad final debe ser de un máximo de 2 años.

Administrador de certificados de AWS

Estas son las 10 mejores prácticas que identificamos para AWS Certificate Manager (ACM):

Comprobación de caducidad del certificado ACM: garantizar la eliminación de los certificados caducados Certificados SSL/TLS Gestionado por ACM. Esto elimina el riesgo de implementar un certificado SSL/TLS no válido en recursos que activan el front-end. Esto también podría causar una pérdida de credibilidad para la empresa.
Comprobación de validez del certificado ACM: asegúrese de que las solicitudes que llegan durante el proceso de emisión o renovación del certificado SSL/TLS se validen periódicamente.
Uso de la Autoridad de Certificación Raíz (CA): Se recomienda minimizar su uso. Amazon recomienda crear una cuenta independiente para la CA raíz.
La protección de la capa de transporte es vital para garantizar la seguridad. Se recomienda usar solo TLS versión 1.1 o superior y no usar SSL, ya que ya no es seguro.
Siempre que importe certificados en lugar de certificados emitidos por ACM, asegúrese de que las claves utilizadas para generar claves privadas de certificados SSL/TLS tengan una alta solidez de clave para evitar una violación de datos.
Evite usar certificados de dominio comodín. En su lugar, intente emitir un certificado de dominio único ACM para cada dominio y subdominio con su propia clave privada.
Permita el uso de certificados importados únicamente de socios autenticados y de confianza de su organización en ACM. Al importar certificados comodín a AWS Certificate Manager (ACM), el riesgo de amenazas a la seguridad es alto, ya que el usuario podría tener una copia sin cifrar de la clave privada del certificado.
La mejor práctica recomendada es utilizar siempre un nombre de dominio completo (FQDN) en los certificados SSL/TLS ACM.
Para evitar el uso indebido de los certificados generados, realice auditorías frecuentes del entorno de AWS para verificar que no haya certificados confiables y valide los informes de auditoría.
Activar las alarmas de AWS CloudTrail y CloudWatch: El registro de CloudTrail permite rastrear el historial de llamadas a la API de AWS y supervisar las implementaciones de AWS. CloudTrail se puede integrar con aplicaciones para realizar actividades automatizadas de registro y supervisión. Activar la función de alarma de CloudWatch permite recibir notificaciones cuando se producen infracciones en las métricas configuradas.

CA privada de AWS ACM (ACM PCA)

A continuación, se presentan las mejores prácticas recomendadas que pueden ayudarlo a utilizar AWS ACM PCA de manera más efectiva.

AWS recomienda documentar todas sus políticas y prácticas para operar su CA, incluida la jerarquía de CA, el diagrama de arquitectura, las políticas del período de validación de CA, la longitud de la ruta, etc.
La estructura y las políticas de la CA mencionadas anteriormente se pueden recopilar en dos documentos: Política de Certificación (CP) y Declaración de Prácticas de Certificación (CPS). Consulte la RFC 3647 para obtener un marco que le permita recopilar información importante sobre las operaciones de su CA.
En general, la CA raíz solo debe utilizarse para emitir un certificado para CA intermedias.
La mejor práctica recomendada es crear una CA raíz y una CA subordinada en dos cuentas de AWS diferentes.
El rol de administrador de CA debe ser independiente de los usuarios que necesitan acceso solo para emitir certificados de entidad final.
Active el registro de CloudTrail antes de crear y empezar a operar una CA privada. Con CloudTrail, puede recuperar el historial de llamadas a la API de AWS de su cuenta para supervisar sus implementaciones de AWS.
Se recomienda actualizar periódicamente la clave privada de su CA privada. Puede actualizar una clave importando un nuevo certificado de CA o reemplazando la CA privada por una nueva.
Eliminar la CA privada no utilizada de forma permanente.
La CA privada de ACM recomienda usar la función de acceso público bloqueado (BPA) de Amazon S3 en los buckets que contienen CRL. Esto evita exponer innecesariamente los detalles de su PKI privada a posibles enemigos. BPA es una práctica recomendada de S3 y está habilitada de forma predeterminada en los buckets nuevos.

Servicios de autoridad de certificación de Google Cloud

Este tema describe algunas de las mejores prácticas que pueden ayudarle a utilizar el Servicio de autoridad de certificación de forma más eficaz.

Control de roles y acceso: No se debe asignar más de un rol a cada persona a la vez. Todas las personas con un rol asignado deben recibir la información y la capacitación adecuadas sobre sus responsabilidades y prácticas de seguridad. Si desea asignar diversos permisos a una persona, se recomienda crear un rol personalizado mediante IAM.
En la mayoría de los casos, se recomienda utilizar el nivel Enterprise para crear un grupo de autoridades de certificación (CA) que emitan certificados a otras CA y entidades finales.
Al crear un grupo de CA, se recomienda considerar cuidadosamente el nivel de DevOps, ya que no admite la revocación de certificados.
Proteja las claves de firma de CA aprovechando Cloud HSM.
Habilite los registros de auditoría en la nube para monitorear el acceso y el uso de las claves de firma de Cloud HSM.
Se recomienda no importar una CA externa existente con certificados emitidos al servicio de CA.
Para una CA raíz y una CA subordinada, se recomienda utilizar el tamaño de clave más significativo disponible para esa familia de algoritmos.
- Para RSA, el tamaño de clave más grande admitido es 4096 bits.
- Para ECDSA, el tamaño de clave más grande admitido es 384 bits.
(Para las CA subordinadas con una vida útil más corta, basta con utilizar tamaños de clave más pequeños, como 2048 bits para RSA o 256 bits para ECDSA ).
Se recomienda que los autores de la plantilla de certificado otorguen el rol de usuario del servicio de CA a los miembros de la organización que puedan usar esa plantilla de certificado.

#	Categorías	PKI de Microsoft	Administrador de certificados de AWS (ACM)	CA privada de AWS ACM (ACM PCA)	Google Cloud – Servicios de autoridad de certificación (CAS)
1	CA raíz	La CA raíz se implementa localmente y se mantiene fuera de línea	AWS Certificate Manager es un servicio mediante el cual puede aprovisionar, administrar e implementar fácilmente certificados SSL/TLS públicos/privados para usar con servicios de AWS y recursos internos conectados.	La CA raíz se puede implementar en la nube de AWS o la CA raíz externa puede firmar la CSR de la CA emisora.	La CA raíz se puede implementar en la nube de Google: los servicios de autoridad de certificación o la CSR de la CA emisora pueden ser firmados por la CA raíz externa.
2	Plantilla de certificado	No se recomienda usar la plantilla de certificado predeterminada. Las plantillas de certificado se pueden configurar.	Utilice plantillas de AWS CloudFormation para emitir certificados privados mediante AWS Certificate Manager (ACM).	ACM Private CA admite cuatro variedades de plantillas de certificado. Plantilla base: plantillas predefinidas en las que no se permiten parámetros de paso. Plantillas CSRPassthrough: plantillas que amplían sus versiones de plantilla base correspondientes al permitir el paso de CSR. Plantillas APIPassthrough: plantillas que amplían sus versiones de plantilla base correspondientes al permitir el paso a través de API. Plantillas APICSRPassthrough: plantillas que amplían sus versiones de plantilla base correspondientes al permitir el paso directo tanto de API como de CSR.	Se puede crear una nueva plantilla de certificado en cada proyecto y ubicación en el servicio Google Cloud CAS.
3	algoritmo clave y tamaño de clave	Microsoft PKI admite el tamaño de clave según los estándares NIST 800. El tamaño mínimo de clave es de 2048 bits. Sin embargo, para cualquier CA cuyo certificado caduque en más de 15 años, se recomienda usar RSA (4096 o superior) o, si la clave de la CA usa ECC, la curva P-384 o P-521.	ACM admite los siguientes algoritmos de clave pública y tamaños de clave: RSA de 2048 bits (RSA_2048) RSA de 3072 bits (RSA_3072) RSA de 4096 bits (RSA_4096) Curva prima elíptica de 256 bits (EC_prime256v1) Curva prima elíptica de 384 bits (EC_secp384r1) Curva prima elíptica de 384 bits (EC_secp384r1)	AWS ACM Private CA admite los siguientes algoritmos criptográficos y tamaños de clave para la generación de claves privadas. Con la opción avanzada, están disponibles los siguientes algoritmos: (Esta lista solo aplica a los certificados emitidos directamente por ACM Private CA a través de su consola, API o línea de comandos). RSA 2048 RSA 4096 ECDSA P256 ECDSA P384	En Google Cloud se utilizan el siguiente algoritmo y tamaño de clave: RSA de 2048 bits (RSA_2048) RSA de 3072 bits (RSA_3072) RSA de 4096 bits (RSA_4096) ECDSA P256 ECDSA P384 Para una nueva CA raíz o una CA subordinada con una vida útil estimada de varios años, Google recomienda usar el tamaño de clave más grande disponible para esa familia de algoritmos. (Para RSA, el tamaño de clave máximo admitido es de 4096 bits y para ECDSA, de 384 bits).
4	Algoritmo de hash	Se recomienda utilizar el algoritmo hash avanzado (SHA 256 y superior) para la nueva implementación y la PKI existente.	Los certificados administrados en AWS Certificate Manager utilizan claves RSA con un módulo de 2048 bits y SHA-256. Actualmente, ACM no puede administrar otros certificados, como los ECDSA.	ACM Private CA admite el siguiente algoritmo de firma de certificados. Esta lista solo aplica a los certificados emitidos directamente por ACM Private CA a través de su consola, API o línea de comandos. SHA256CONCDSA SHA384CONCDSA SHA512CONCDSA SHA256CONHRSA SHA384CONHRSA SHA512CONHRSA	Los servicios de autoridad de certificación de Google Cloud admiten SHA256 y SHA384.
5	Cumplimiento de RFC	Los certificados de CA dentro de la PKI de TI de Microsoft deben ser X.509 versión 3 y deben cumplir con el RFC 5280: Certificado de infraestructura de clave pública de Internet X.509 y perfil CRL, con fecha de mayo de 2008. Según corresponda al tipo de certificado, los certificados se ajustan a la versión actual de los Requisitos básicos del CA/Browser Forum para la emisión y administración de certificados de confianza pública.	El Administrador de Certificados de AWS es responsable de proteger la infraestructura que ejecuta los servicios de AWS en la nube. AWS también proporciona servicios que se pueden usar de forma segura. Auditores externos prueban y verifican periódicamente la eficacia de la seguridad como parte de los Programas de Cumplimiento de AWS.https://aws.amazon.com/compliance/programs/)	Ciertas restricciones apropiadas para una CA privada se aplican según el RFC 5280. Sin embargo, la CA privada de ACM no aplica todas las restricciones definidas en el RFC 5280.	El Servicio de Autoridad de Certificación utiliza la herramienta ZLint para garantizar que los certificados X.509 sean válidos según las normas RFC 5280. Sin embargo, el Servicio de Autoridad de Certificación no cumple todos los requisitos de RFC 5280, y es posible que una CA creada con él emita un certificado no conforme.
6	Punto de distribución de CRL (Lista de revocación de certificados)	Microsoft PKI deposita la CRL bajo LDAP (protocolo ligero de acceso a directorios) y HTTP.	El Centro de soporte de AWS puede ayudarle a revocar un certificado en AWS Certificate Manager. Para ello, debe generar un ticket o caso de soporte.	ACM Private CA deposita automáticamente la CRL en el bucket de Amazon S3 que usted designe.	La publicación de CRL debe estar habilitada en un grupo de CA para que pueda publicarse. La publicación de CRL se puede habilitar durante la creación de un grupo de CA.
7	Almacenamiento de claves privadas	Se recomienda almacenar las claves privadas en un HSM compatible con FIPS 140-2 nivel 3	AWS Certificate Manager almacena el certificado y su clave privada correspondiente y utiliza AWS Key Management Service (AWS KMS) para ayudar a proteger la clave privada.	De forma predeterminada, las claves privadas de las CA privadas se almacenan en modelos de seguridad de hardware (HSM) administrados por AWS. Estos HSM cumplen con los requisitos de seguridad FIPS PUB 140-2 para módulos criptográficos.	Las claves de CA se almacenan en Cloud HSM, validado según FIPS 140-2 Nivel 3 y disponible en regiones de América, Europa y Asia Pacífico.
8	Informes de auditoria	Se puede habilitar la auditoría en una CA en el servidor Windows para proporcionar un registro de auditoría para todas las tareas de administración de servicios de certificados.	AWS Certificate Manager (ACM) está integrado con AWS CloudTrail, un servicio que registra las acciones realizadas por un usuario, un rol o un servicio de AWS en ACM. CloudTrail está habilitado de forma predeterminada en su cuenta de AWS.	Se crean informes de auditoría para enumerar todos los certificados emitidos o revocados por la CA privada de ACM. El informe se guarda en un bucket de S3 nuevo o existente.	Los registros de auditoría de la nube se pueden usar en los servicios de autoridad de certificación. Los registros de auditoría de la nube proporcionan los siguientes registros de auditoría para cada proyecto, carpeta y organización de la nube: Registros de auditoría de actividad administrativa Registros de auditoría de acceso a datos Registros de auditoría de eventos del sistema Registros de auditoría de política denegada
9	Mejores prácticas (de alto nivel)	Haga un plan detallado de su infraestructura PKI antes de la implementación. Evite instalar ADCS en un controlador de dominio. La CA raíz debe ser independiente y sin conexión. No emita certificados a la entidad final desde una CA raíz. Habilitar eventos de auditoría tanto para la CA raíz como para la CA emisora. Proteja la clave privada con HSM (FIPS 140-2 nivel 3) (Más detalles en la sección anterior)	Comprobación de caducidad de certificados de ACM: Asegúrese de eliminar los certificados SSL/TLS caducados administrados por ACM. Esto elimina el riesgo de implementar un certificado SSL/TLS no válido en recursos que activan el front-end. Esto también podría causar una pérdida de credibilidad para la empresa. Comprobación de validez del certificado ACM: asegúrese de que las solicitudes que llegan durante el proceso de emisión o renovación del certificado SSL/TLS se validen periódicamente. Uso de la Autoridad de Certificación Raíz (CA): Se recomienda minimizar su uso. Amazon recomienda crear una cuenta independiente para la CA raíz. La protección de la capa de transporte es vital para garantizar la seguridad. Se recomienda usar solo TLS versión 1.1 o superior y no usar SSL, ya que ya no es seguro. (Más detalles en la sección anterior)	Mejores prácticas recomendadas para utilizar ACM PCA de manera eficaz: Documentar la estructura y políticas de CA. Minimizar el uso de CA raíz. Proporcione a la CA raíz su propia cuenta de AWS. Separar roles de administradores y emisores. Activar el inicio de sesión de CloudTrail. Rotar la clave privada de CA. Eliminar una CA no utilizada (AWS le factura una CA hasta que se elimine).	Control de roles y acceso: No se debe asignar más de un rol a cada persona a la vez. Todas las personas con un rol asignado deben recibir la información y la capacitación adecuadas sobre sus responsabilidades y prácticas de seguridad. Si desea asignar diversos permisos a una persona, se recomienda crear un rol personalizado mediante IAM. En la mayoría de los casos, se recomienda utilizar el nivel Enterprise para crear un grupo de autoridades de certificación (CA) que emitan certificados a otras CA y entidades finales. Al crear un grupo de CA, se recomienda considerar cuidadosamente el nivel de DevOps, ya que no admite la revocación de certificados. (Más detalles en la sección anterior)
10	Jerarquía de CA	En una PKI jerárquica (una implementación típica), generalmente hay tres tipos de jerarquías: de un nivel, de dos niveles y de tres niveles.	AWS Certificate Manager es un servicio mediante el cual puede aprovisionar, administrar e implementar fácilmente certificados SSL/TLS públicos/privados con servicios de AWS y recursos internos conectados.	Con ACM PCA, puede diseñar y crear una jerarquía de autoridades de certificación con hasta cinco niveles.	Al crear una CA subordinada que se conecta a una CA raíz externa, las propiedades incluidas en la CSR generada por el Servicio de CA deben conservarse en el certificado de CA firmado por la CA raíz externa. La CA externa puede añadir extensiones adicionales si conserva las propiedades en la CSR. Por ejemplo, el certificado de CA subordinada firmado también debe incluir la misma restricción de longitud de ruta si la CSR contiene una restricción de longitud de ruta.
11	Redundancia y recuperación ante desastres	Los planes de redundancia y recuperación ante desastres deben completarse durante la fase de planificación de diseño e implementación de una implementación de PKI.	ACM no tiene un SLA. El servicio de CA privada gestionado por la Autoridad de Certificación Privada de ACM sí lo tiene.	ACM Private CA está disponible en varias regiones, lo que permite al usuario crear CA redundantes. El servicio ACM Private CA opera con un acuerdo de nivel de servicio (SLA) con una disponibilidad del 99.9 %.	Los servicios de autoridad de certificación (CAS) de Google Cloud están disponibles en varias regiones, lo que permite redundancia. Google Cloud (CAS) opera con un acuerdo de nivel de servicio (SLA) con una disponibilidad del 99.9 %.

Conclusión

La infraestructura de clave pública (PKI) desempeña un papel fundamental para garantizar la seguridad de las comunicaciones mediante el uso de certificados digitales. La combinación de componentes clave como las autoridades de certificación (CA) y las autoridades de registro (RA) trabajan conjuntamente para autenticar entidades y gestionar el ciclo de vida de los certificados. Mediante el cifrado con pares de claves públicas y privadas, la PKI garantiza la confidencialidad y autenticidad de los datos, asegurando así la seguridad de la infraestructura.

Los distintos proveedores ofrecen soluciones PKI personalizadas , cada una con ventajas diferentes que se adaptan a casos de uso específicos. Microsoft PKI promueve la gestión segura de claves con CA raíz sin conexión y módulos de seguridad de hardware (HSM). AWS Certificate Manager (ACM) ofrece gestión automatizada de certificados, centrándose en la validación y la seguridad de los recursos en la nube. El servicio de autoridad de certificación de Google Cloud hace hincapié en el control de acceso basado en roles y el uso de claves de cifrado robustas. Estas recomendaciones específicas de cada proveedor garantizan una implementación de PKI altamente segura en diversas plataformas y entornos.

¿Cómo puede ayudar Encryption Consulting?

En Encryption Consulting , nos especializamos en el diseño y la migración de infraestructuras PKI que se adaptan perfectamente a las necesidades de seguridad específicas de su organización. Ofrecemos servicios integrales de diseño e implementación de PKI, tanto para infraestructuras existentes como para nuevas. Nuestras soluciones locales incluyen Microsoft PKI, mientras que nuestras soluciones en la nube utilizan proveedores líderes como AWS Certificate Manager, AWS Certificate Manager Private CA (ACM-PCA), Azure PKI y Google Cloud Certificate Authority Manager.