Prácticas recomendadas para Certificate Manager

En esta página, se describen varias prácticas recomendadas para configurar y administrar certificados en Google Cloud con el Administrador de certificados y Certificate Authority Service (servicio de CA). En esta página, se describe cómo diseñar tu arquitectura de administración de certificados.

Antes de leer esta página, asegúrate de estar familiarizado con las páginas de descripción general del Administrador de certificados y del Certificate Authority Service.

Diseña tu arquitectura de administración de certificados

Cuando diseñes una estrategia de administración de certificados empresariales, debes tener en cuenta los casos de uso clave de tu organización y todo el ciclo de vida de tus certificados. Estas decisiones afectan el costo, la sobrecarga operativa y la facilidad de implementar capacidades de administración de certificados, como la emisión, la revocación y la rotación.

En las siguientes secciones, se explican nuestras recomendaciones para cada opción de diseño.

Elige un tipo de certificado

Cuando crees un certificado, debes asegurarte de seleccionar un tipo de certificado adecuado para tu caso de uso según los requisitos de tu aplicación y las políticas de seguridad de tu organización.

Para analizar el tipo de certificado que podría funcionar mejor para ti, consulta el siguiente diagrama de flujo:

Evalúa qué tipo de certificado elegir.
Evalúa qué tipo de certificado elegir (haz clic para ampliar).

Estos son algunos vínculos útiles a la documentación sobre los temas mencionados en el diagrama de flujo:

Optimiza la jerarquía de tu servicio de CA privada

Te recomendamos que mantengas la jerarquía de tu servicio de CA lo más sencilla posible para garantizar operaciones y solución de problemas sin inconvenientes. Debes almacenar tu autoridad de certificación raíz (CA) en su propio proyecto de Google. La CA raíz firma algunas CA intermedias, y esas CA emiten los certificados finales.

Esta estructura jerárquica plana mejora la transparencia, simplifica los procesos de revocación de certificados y reduce la probabilidad de configuraciones incorrectas. Aunque el servicio de CA es un servicio regional, una CA raíz en una región puede firmar AC subordinadas ubicadas en otras regiones.

Sigue estas prácticas recomendadas en la jerarquía de tu servicio de CA como se muestra en el diagrama:

  • Aísla tu CA raíz en su propio Google Cloud proyecto para firmar la CA emisora.

  • Crea CA emisoras en grupos de CA alojados en proyectos separados. Aloja estos grupos en proyectos separados y segmenta por ubicación geográfica (región), ciclo de vida del desarrollo de software (desarrollo, producción, prueba) o un caso de uso específico.

  • Configura el Administrador de certificados para usar un grupo de CA emisoras que pueda emitir certificados de confianza privada para los recursos compatibles.

Diseño de jerarquía de AC recomendado.
Diseño recomendado para tu jerarquía de CA (haz clic para ampliar).

Usa una cobertura integral de nombres de host

Te recomendamos que te asegures de que tus certificados proporcionen una cobertura de nombres de host suficiente para todos los dominios y subdominios que tus servicios necesitan proteger. Una cobertura de nombres de host inadecuada puede generar advertencias de seguridad para los usuarios, interrupciones del servicio y una experiencia de usuario negativa.

Evita usar un solo certificado para varios dominios. Si el certificado único no se renueva o se borra por accidente, todos los dominios que cubre dejan de ser seguros. Te recomendamos que crees certificados distintos para diferentes dominios.

Si planeas agregar subdominios o servicios nuevos más adelante, usa caracteres comodín para incluirlos en tu certificado desde el principio. Por ejemplo, un certificado comodín para *.myorg.example.com solo protege el primer nivel de subdominio, pero no los niveles de subdominio más profundos, como sub.subdomain.myorg.example.com.

Usa certificados administrados por Google

Para una administración eficiente de certificados públicos y facilidad de uso, te recomendamos que uses certificados administrados por Google. Este enfoque reduce significativamente la sobrecarga operativa, automatiza tareas como la rotación de certificados y elimina los riesgos asociados con las renovaciones manuales.

Además, los certificados administrados por Google ofrecen una integración perfecta con otros Google Cloud servicios. El Administrador de certificados solo admite la Public Certificate Authority (pki.goog) y la CA de Let's Encrypt (letsencrypt.org) para emitir certificados administrados por Google de confianza pública. El Administrador de certificados aprovisiona certificados administrados por Google con un período de validez de 45 o 90 días, según la CA emisora:

  • Los certificados emitidos por Public CA están pasando gradualmente de un período de validez de 90 días a uno de 45 días. Los certificados existentes de 90 días seguirán siendo válidos durante 90 días hasta su próxima renovación.
  • Los certificados emitidos por la CA de Let's Encrypt tienen un período de validez de 90 días.

El Administrador de certificados inicia automáticamente el proceso de renovación cuando queda aproximadamente un tercio del período de validez del certificado. La renovación comienza unos 15 días antes del vencimiento para los certificados de 45 días y unos 30 días antes del vencimiento para los certificados de 90 días.

Expande y mejora el rendimiento de tus certificados

En las siguientes secciones, se describen las prácticas recomendadas para expandir tus certificados y mejorar el rendimiento de las acciones relacionadas con los certificados, como el aprovisionamiento y la renovación.

Aplica la implementación descentralizada para el Administrador de certificados

Usa el Administrador de certificados por proyecto y por ubicación, lo que significa que tus certificados se almacenan en el mismo proyecto que sus recursos asociados en la misma región. Esta estrategia mejora la confiabilidad, ya que evita la reutilización de certificados en diferentes regiones y minimiza de manera eficaz el impacto en el improbable caso de una interrupción regional.

Además, debido a que las cuotas y los límites se aplican a nivel del Google Cloud proyecto, implementar el Administrador de certificados en varios proyectos aumenta tus cuotas generales. Esto se debe a que el uso de un recurso en un proyecto no afecta tu cuota disponible en otro proyecto.

Usa certificados con claves ECDSA

En esta sección, se analiza por qué recomendamos ECDSA en lugar de RSA como práctica recomendada para las claves de firma de certificados.

Qué tipo de clave usar

ECDSA P-256 es la opción recomendada de tipo de clave para la mayoría de los certificados TLS, ya que ECDSA P-256 ofrece una sólida seguridad criptográfica, un excelente rendimiento para las operaciones de firma y un uso eficiente del ancho de banda de la red.

Estos son algunos de los motivos posibles para usar otros tipos de claves de certificado:

  • Si necesitas admitir clientes heredados que no admiten certificados ECDSA, puedes proporcionar certificados RSA-2048 además de certificados ECDSA P-256.
  • Si tienes requisitos de cumplimiento específicos que requieren que uses tamaños de clave más grandes o tipos de clave particulares, puedes usar claves ECDSA P-384, RSA-2048, RSA-3072 y RSA-4096.

Por qué elegir ECDSA en lugar de RSA

La principal ventaja de ECDSA radica en su capacidad de proporcionar un nivel de seguridad criptográfica equivalente con claves significativamente más pequeñas en comparación con RSA. Esta eficiencia se traduce en beneficios tangibles de rendimiento y recursos. Una clave más pequeña no implica una seguridad más débil: ECDSA se basa en el problema del logaritmo discreto de curva elíptica, que proporciona una seguridad más sólida por unidad de clave y, en algunos casos, una mejor eficiencia computacional en comparación con RSA.

Por ejemplo:

  • Una clave ECDSA de 256 bits proporciona un nivel de seguridad similar a una clave RSA-3072.
  • Una clave ECDSA de 384 bits proporciona un nivel de seguridad mayor que cualquier tamaño de clave RSA ampliamente compatible.

Beneficios clave de ECDSA:

  • Rendimiento: Las operaciones de firma de ECDSA son significativamente menos intensivas en términos de procesamiento que las operaciones de RSA que proporcionan un nivel de seguridad equivalente. Esto reduce la carga y la latencia de la CPU, lo que es fundamental para los sistemas de alta capacidad de procesamiento o sensibles a la latencia.

  • Eficiencia: Las claves y firmas más pequeñas requieren menos ancho de banda y almacenamiento, lo que es especialmente beneficioso para los entornos con restricciones de recursos como los dispositivos móviles y de IoT.

Puedes crear la siguiente política de la organización personalizada para aplicar el uso de tipos de claves específicos en tus certificados. Esto solo se aplica a los certificados administrados por Google del servicio de CA (certificados administrados de confianza privada), no a los certificados autoadministrados ni a los certificados administrados por Google de confianza pública.

    name: organizations/ORGANIZATION_ID/customConstraints/custom.restrictAlgorithm \
    resourceTypes: \
    - certificatemanager.googleapis.com/CertificateIssuanceConfig \
    methodTypes: \
    - CREATE \
    - UPDATE \
    condition: "resource.keyAlgorithm == 'ECDSA_P256'" \
    actionType: ALLOW \
    displayName: Allow only ECDSA_P256 in Certificate Issuance configs \
    description: Only ECDSA_P256 certificates are allowed from CA Service.

Usa un grupo de CA para emitir certificados de CA privadas

Te recomendamos que uses grupos de CA para tus CA emisoras. Un grupo de CA es un conjunto de varias CA con una política común de emisión de certificados y de administración de Identity and Access Management (IAM). El uso de un grupo de CA aumenta las consultas efectivas totales por segundo (QPS) mediante el balanceo de cargas y la distribución de las solicitudes de certificados entrantes en todas las CA habilitadas dentro del grupo. Esto mejora el rendimiento sin afectar la carga de trabajo ni los cambios del cliente.

Los grupos de CA proporcionan un solo extremo para la emisión y recuperación de certificados. Puedes usar grupos de CA para rotar de forma segura tus CA sin causar tiempo de inactividad debido al vencimiento o la vulneración de certificados.

Usa mapas de certificados

Para garantizar una escalabilidad óptima, te recomendamos que uses mapas de certificados con recursos compatibles. Los mapas de certificados están diseñados para escalarse, admiten miles de entradas de certificados de forma predeterminada y pueden controlar millones de certificados. Cuando los usan los balanceadores de cargas, las entradas del mapa de certificados tienen prioridad sobre otros certificados, como los certificados SSL de Compute Engine.

Los mapas de certificados también te permiten configurar la lógica de selección de certificados. Por ejemplo, durante un protocolo de enlace, si el nombre de host de un cliente no coincide con ninguna entrada en el mapa de certificados aprovisionado, el balanceador de cargas muestra el certificado principal.

Elige el tipo de autorización de dominio correcto

Para emitir certificados administrados por Google, puedes demostrar la propiedad de tu dominio con la autorización del balanceador de cargas o la autorización de DNS.

En la siguiente tabla, se describen las consideraciones para cada enfoque:

Función Autorización del balanceador de cargas Autorización de DNS
Complejidad de la configuración No requiere pasos de configuración adicionales ni cambios en la configuración de DNS. Requiere que crees una autorización de DNS y agregues su registro CNAME correspondiente a tu configuración de DNS.
Seguridad de red Se debe poder acceder por completo al balanceador de cargas a través de Internet en el puerto 443, incluida la configuración de DNS para todos los dominios que entrega un certificado. La autorización del balanceador de cargas no funciona con otras configuraciones. La autorización de DNS funciona con configuraciones muy complejas , como puertos distintos del 443 y capas de CDN delante del proxy de destino.
Velocidad de aprovisionamiento Velocidad de aprovisionamiento más rápida. Puedes aprovisionar certificados solo después de que el balanceador de cargas esté completamente configurado y entregue tráfico de red. Puedes aprovisionar certificados con anticipación, antes de que el proxy de destino esté listo para entregar tráfico de red.
Certificados comodín No compatible. Compatible.

Automatiza la rotación de certificados autoadministrados

A diferencia de los certificados administrados por Google, los certificados autoadministrados deben reemplazarse de forma manual antes de que venzan. Te recomendamos que automatices este proceso con las ofertas de Certificate Lifecycle Management (CLM) que elijas. Esto ayuda a reducir los errores y el tiempo de inactividad, y garantiza la eficiencia operativa.

También puedes usar mapas de certificados para organizar una rotación de certificados sin inconvenientes. En este proceso, se incluyen los siguientes pasos:

  1. Supervisa el vencimiento de los certificados con Cloud Monitoring y alertas. Te recomendamos que crees una alerta para los certificados que vencen en los próximos 15 a 30 días.
  2. Genera una solicitud de firma de certificado (CSR) y una clave privada para enviarlas a tu CA.
  3. Envía tu CSR y clave privada a tu CA y, luego, recupera el certificado nuevo.

  4. Sube el certificado nuevo al Administrador de certificados a un mapa de certificados adecuado.

    • Si los nombres de dominio del certificado nuevo coinciden con un certificado a punto de vencer, usa el UpdateCertificate método en el recurso de certificado existente.
    • Si el certificado nuevo tiene nombres de dominio diferentes, primero usa el CreateCertificateRequest método con los archivos PEM (correo electrónico con privacidad mejorada) nuevos para crearlo. Luego, usa el UpdateCertificateMapEntry método para reemplazar la referencia del certificado antiguo en el mapa de certificados por la nueva

    Importante: Debes completar este proceso en una llamada a la API sin generar tiempo de inactividad.

Aplica los controles de acceso adecuados

Te recomendamos que tengas en cuenta los principios de privilegio mínimo y separación de obligaciones cuando configures tus controles de acceso. En las siguientes secciones, se explican estas recomendaciones con más detalle.

Aplica el principio de privilegio mínimo

Cuando asignes permisos para administrar certificados, evalúa usar el principio de privilegio mínimo y otorga los permisos mínimos necesarios para realizar una tarea. Te recomendamos que evites usar roles básicos de IAM. En su lugar, otorga roles predefinidos o personalizados del Administrador de certificados y del servicio de CA para mitigar cualquier riesgo de incidentes de seguridad relacionados con el acceso con privilegios excesivos.

Planifica la separación de obligaciones

Te recomendamos que mantengas identidades y permisos distintos para los administradores de certificados y aquellos que tienen el rol de emisor o solicitante de certificados. Para ello, crea grupos de administradores y solicitantes separados en la parte superior de la jerarquía de recursos para tus usuarios.

Asegúrate de que tu grupo de administradores sea responsable de realizar las siguientes acciones:

  • Administrar y mantener tu infraestructura de certificados, como el aprovisionamiento de CA.
  • Configurar plantillas de certificados.
  • Administrar tu lista de revocación de certificados (CRL) y los respondedores del protocolo de estado de certificados en línea (OCSP).
  • Implementar políticas de seguridad para tu CA.

Para los proyectos que alojan una CA raíz, evita asignar roles básicos, como Propietario (roles/owner), Editor (roles/editor) y Administrador del servicio de CA (roles/privateca.admin) a cualquier usuario o grupo. Esta práctica evita la eliminación accidental, la configuración incorrecta y la exposición excesiva. En su lugar, usa Privileged Access Manager (PAM) para el acceso justo a tiempo (JIT) según sea necesario con justificación y aprobaciones después de que se instale y configure la CA raíz.

Asegúrate de que el grupo de solicitantes sea responsable de las operaciones diarias de procesamiento de solicitudes de certificados y de emisión de certificados basados en plantillas predefinidas.

En la siguiente tabla, se enumeran los roles de IAM que suelen asociarse con varias funciones laborales:

Personificación Descripción Roles de IAM
Administradores de certificados Configuran y administran la infraestructura de CA y certificados. Propietario del Administrador de certificados (roles/certificatemanager.owner),
Administrador del servicio de CA (roles/privateca.admin)
Solicitante de certificados Solicita certificados para cargas de trabajo. Solicitante de certificados del Certificate Authority Service (roles/privateca.certificateRequester)
Cargas de trabajo (cuentas de servicio de automatización) Las cargas de trabajo o las canalizaciones las usan para solicitar certificados. Solicitante de certificados de cargas de trabajo del Certificate Authority Service (roles/privateca.workloadCertificateRequester)
Ingenieros de seguridad o propietarios de PKI Administran la política, la revocación y el ciclo de vida de los certificados. Administrador de operaciones del servicio de CA (roles/privateca.caManager), Administrador de certificados del Certificate Authority Service (roles/privateca.certificateManager)
Ingenieros de DevOps o de plataformas Administran la implementación de certificados en balanceadores de cargas, y mucho más. Editor del Administrador de certificados (roles/certificatemanager.editor)
Auditor o cumplimiento Supervisan los certificados y su uso. Visualizador del Administrador de certificados (roles/certificatemanager.viewer), Auditor del Certificate Authority Service (roles/privateca.auditor)

Usa la autorización de DNS por proyecto para implementaciones multirregionales y de múltiples nubes

Te recomendamos que uses el enfoque de autorización de DNS por proyecto para administrar de forma independiente varias autorizaciones para proyectos en varias regiones, varias nubes y en todo el ciclo de vida del desarrollo de software (SDLC).

La compartimentación de las autorizaciones de DNS ayuda a garantizar que cada proyecto mantenga su propio conjunto distinto de registros DNS y permisos. Este nivel de control permite que cada proyecto administre sus configuraciones de DNS de forma autónoma, sin interferir con las operaciones de otros proyectos ni verse afectado por ellas. Por ejemplo, un equipo de desarrollo puede experimentar con nuevas configuraciones de DNS para su aplicación específica sin arriesgar ningún impacto negativo en los sistemas de producción ni en otros proyectos en curso.

Usa registros CAA para proteger tus dominios

Los registros de autorización de la autoridad certificadora (CAA) son un mecanismo de seguridad en el sistema de nombres de dominio (DNS). Los registros CAA proporcionan a los propietarios de dominios un control completo para configurar las Public Certificate Authority (CA) que pueden emitir certificados para sus dominios. Este control es importante para evitar la emisión no autorizada de certificados. Con CAA, se reduce la superficie de ataque para los certificados fraudulentos, lo que hace que los sitios web sean más seguros.

Para los certificados administrados por Google, te recomendamos que autorices manualmente lo siguiente para obtener la mejor confiabilidad de tus solicitudes de emisión y renovación de certificados:

Cloud Logging, Cloud Monitoring y visibilidad

En las siguientes secciones, se describen las prácticas recomendadas para el registro de auditoría y para supervisar el uso y el vencimiento de los certificados.

Habilita y agrega registros de auditoría

Para supervisar todos los recursos de tu organización, agrega los registros de auditoría de actividad del administrador para todos los servicios, incluido el Administrador de certificados, en una ubicación centralizada.

Esto permite que tu equipo de seguridad o auditor revise toda la actividad relacionada con la creación o modificación de recursos del Administrador de certificados y del servicio de CA en un solo lugar. Para obtener más información sobre la configuración de registros agregados, consulta Agrega y almacena los registros de tu organización.

Supervisa el uso y el vencimiento de los certificados

Te recomendamos que configures alertas basadas en registros para eventos importantes del Administrador de certificados, como el uso de la CA raíz, el vencimiento de los certificados y la eliminación de certificados. Estas alertas te ayudan a priorizar operaciones, como una tasa alta de fallas en la creación de certificados, y pueden activar un proceso descendente para solicitar un certificado nuevo o aumentar la cuota.

Configura las siguientes alertas y políticas de registros para las operaciones relacionadas con los privilegios:

Requisitos de cumplimiento

Por lo general, los marcos de cumplimiento especifican expectativas y objetivos de alto nivel para la administración de certificados en lugar de productos o configuraciones específicos.

Por ejemplo, las Normas de seguridad de datos de la industria de tarjetas de pago (PCI DSS) y el Instituto Nacional de Estándares y Tecnología (NIST) requieren que las organizaciones documenten e implementen períodos de rotación para las claves de firma. También exigen la supervisión continua del inventario y de todas las claves y certificados de firma de confianza que protegen los datos de los titulares de tarjetas.

Para obtener más información sobre cómo Google Cloud los servicios de pueden ayudar a satisfacer varios requisitos del marco de cumplimiento, consulta los siguientes recursos:

¿Qué sigue?