Prácticas recomendadas de Certificate Manager

En esta página se describen varias prácticas recomendadas para configurar y gestionar certificados en Google Cloud mediante Certificate Manager y el Servicio de Autoridades de Certificación (CA Service). En esta página se describe cómo diseñar la arquitectura de gestión de certificados.

Antes de leer esta página, asegúrate de que conoces la descripción general de Gestor de certificados y la descripción general del Servicio de Autoridades de Certificación.

Diseñar la arquitectura de gestión de certificados

Al diseñar una estrategia de gestión de certificados empresariales, debes tener en cuenta los principales casos prácticos de tu organización y todo el ciclo de vida de tus certificados. Estas decisiones afectan al coste, a los gastos operativos y a la facilidad de implementar funciones de gestió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 seleccionar un tipo que se adapte a tu caso práctico en función de los requisitos de tu aplicación y de las políticas de seguridad de tu organización.

Para analizar el tipo de certificado que mejor se adapte a tus necesidades, consulta el siguiente diagrama de flujo:

Evalúa qué tipo de certificado elegir.
Evalúa qué tipo de certificado elegir (haz clic en la imagen para ampliarla).

Aquí tienes algunos enlaces a documentación útil sobre los temas mencionados en el diagrama de flujo:

Simplificar la jerarquía del Servicio de Autoridades de Certificación privadas

Te recomendamos que mantengas la jerarquía de tu servicio de CA lo más sencilla posible para que las operaciones y la solución de problemas se realicen sin complicaciones. Debes almacenar tu autoridad de certificación (CA) raíz en su propio proyecto de Google. La CA raíz firma algunas CA intermedias, que a su vez 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 que se produzcan errores de configuración. Aunque el Servicio de AC es un servicio regional, una AC raíz de una región puede firmar ACs subordinadas ubicadas en otras regiones.

Sigue estas prácticas recomendadas en tu jerarquía de servicios de CA, tal como se muestra en el diagrama:

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

  • Crea ACs emisoras en grupos de ACs alojados en proyectos independientes. Aloja estos grupos en proyectos independientes y segmenta los grupos 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 Certificate Manager para que use un grupo de AC emisoras que pueda emitir certificados de confianza privada para los recursos admitidos.

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

Usar una cobertura de nombres de host completa

Te recomendamos que te asegures de que tus certificados proporcionan una cobertura de nombre de host suficiente para todos los dominios y subdominios que tus servicios necesiten proteger. Una cobertura de nombre de host inadecuada puede provocar que los usuarios reciban advertencias de seguridad, que se interrumpan los servicios y que la experiencia de usuario sea negativa.

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

Si tienes previsto añadir nuevos subdominios o servicios más adelante, utiliza 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.

Usar certificados gestionados por Google

Para gestionar los certificados públicos de forma eficiente y sencilla, te recomendamos que uses certificados gestionados por Google. Este enfoque reduce significativamente la sobrecarga operativa, automatiza tareas como la rotación de certificados y elimina los riesgos asociados a las renovaciones manuales.

Además, los certificados gestionados por Google se integran perfectamente con otrosGoogle Cloud servicios. Los certificados gestionados por Google tienen una validez de 90 días y el proceso de renovación empieza aproximadamente un mes antes de que caduquen.

Ampliar y mejorar el rendimiento de los certificados

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

Aplicar el despliegue descentralizado en Certificate Manager

Usa Certificate Manager 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 fiabilidad, ya que evita que se reutilicen certificados en distintas regiones y minimiza el impacto en el improbable caso de que se produzca una interrupción regional.

Además, como las cuotas y los límites se aplican a nivel de proyecto, desplegar Certificate Manager en varios proyectos aumenta las cuotas generales. Google Cloud Esto se debe a que el uso de un recurso en un proyecto no afecta a la cuota disponible en otro proyecto.

Usar certificados con claves ECDSA

En esta sección se explica 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 el tipo de clave recomendado para la mayoría de los certificados TLS, ya que ofrece una seguridad criptográfica sólida, un rendimiento excelente para las operaciones de firma y un uso eficiente del ancho de banda de la red.

Estos son algunos de los motivos por los que se pueden usar otros tipos de claves de certificado:

  • Si necesitas admitir clientes antiguos que no admitan certificados ECDSA, puedes proporcionar certificados RSA-2048 además de certificados ECDSA P-256.
  • Si tienes requisitos de cumplimiento específicos que te obligan a usar tamaños de clave más grandes o tipos de clave concretos, 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 es su capacidad para 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 ventajas tangibles en cuanto al rendimiento y los recursos. Una clave más pequeña no implica una seguridad menor. ECDSA se basa en el problema del logaritmo discreto de curva elíptica, que proporciona una mayor seguridad 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 al de una clave RSA de 3072 bits.
  • Una clave ECDSA de 384 bits proporciona un nivel de seguridad mayor que cualquier tamaño de clave RSA ampliamente admitido.

Ventajas principales de ECDSA:

  • Rendimiento: las operaciones de firma ECDSA requieren muchos menos recursos computacionales que las operaciones RSA, pero ofrecen un nivel de seguridad equivalente. De esta forma, se reduce la carga de la CPU y la latencia, lo que es fundamental para los sistemas de alto rendimiento o sensibles a la latencia.

  • Eficiencia: las claves y las firmas más pequeñas requieren menos ancho de banda y almacenamiento, lo que resulta especialmente útil en entornos con recursos limitados, como los dispositivos móviles y de IoT.

Puedes crear la siguiente política de organización personalizada para aplicar el uso de tipos de clave específicos en tus certificados. Esto solo se aplica a los certificados gestionados por Google del servicio de AC (certificados gestionados de confianza privada), no a los certificados autogestionados ni a los certificados gestionados 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.

Usar un grupo de ACs para emitir certificados de ACs privadas

Te recomendamos que uses grupos de CAs para tus CAs emisoras. Un grupo de ACs es una colección de varias ACs con una política de emisión de certificados y una política de gestión de identidades y accesos (IAM) comunes. Si usas un grupo de autoridades de certificación, aumentará el total de consultas efectivas por segundo (CPS), ya que se realizará un balanceo de carga y se distribuirán las solicitudes de certificados entrantes entre todas las autoridades de certificación habilitadas del grupo. De esta forma, se mejora el rendimiento sin que se vean afectados ni la carga de trabajo ni los cambios del lado del cliente.

Los grupos de ACs proporcionan un único endpoint para la emisión y la recuperación de certificados. Puedes usar grupos de ACs para rotar tus ACs de forma segura sin que se produzcan tiempos de inactividad debido a que los certificados caduquen o se vean comprometidos.

Usar mapas de certificados

Para garantizar una escalabilidad óptima, te recomendamos que uses mapas de certificados con recursos compatibles. Los mapas de certificados se han diseñado para escalarse, ya que admiten miles de entradas de certificados de forma predeterminada y pueden gestionar millones de certificados. Cuando los balanceadores de carga los usan, las entradas de mapas 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 una negociación, si el nombre de host de un cliente no coincide con ninguna entrada del mapa de certificados aprovisionado, el balanceador de carga devuelve el certificado principal.

Elegir el tipo de autorización de dominio correcto

Para emitir certificados gestionados por Google, puedes demostrar que eres el propietario del dominio mediante la autorización del balanceador de carga o la autorización de DNS.

En la siguiente tabla se describen las consideraciones de cada enfoque:

Función Autorización del balanceador de carga Autorización de DNS
Dificultad de la configuración No requiere ningún paso de configuración adicional ni cambios en la configuración de DNS. Requiere que crees una autorización de DNS y añadas su registro CNAME correspondiente a tu configuración de DNS.
Seguridad de la red Se debe poder acceder al balanceador de carga a través de Internet en el puerto 443, incluida la configuración de DNS de todos los dominios a los que dé servicio un certificado. La autorización del balanceador de carga 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. Solo puedes aprovisionar certificados una vez que el balanceador de carga esté configurado por completo y esté sirviendo tráfico de red. Puedes aprovisionar certificados con antelación, antes de que el proxy de destino esté listo para servir tráfico de red.
Certificados comodín No es compatible. Compatible.

Automatizar la rotación de certificados autogestionados

A diferencia de los certificados gestionados por Google, los certificados autogestionados deben sustituirse manualmente antes de que caduquen. Te recomendamos que automatices este proceso con las ofertas de gestión del ciclo de vida de los certificados (CLM) que elijas. Esto ayuda a reducir los errores y el tiempo de inactividad, así como a garantizar la eficiencia operativa.

También puedes usar mapas de certificados para organizar una rotación de certificados fluida. Este proceso incluye los siguientes pasos:

  1. Monitoriza la caducidad de los certificados con Cloud Monitoring y las alertas. Te recomendamos que crees una alerta para los certificados que caduquen en los próximos 15-30 días.
  2. Genera una solicitud de firma de certificado (CSR) y una clave privada para enviarlas a tu AC.
  3. Envía tu CSR y tu clave privada a tu AC y, a continuación, recupera el nuevo certificado.

  4. Sube el nuevo certificado a Gestor de certificados en un mapa de certificados adecuado.

    • Si los nombres de dominio del nuevo certificado coinciden con los de un certificado que está a punto de caducar, utiliza el método UpdateCertificate en el recurso del certificado.
    • Si el nuevo certificado tiene nombres de dominio diferentes, primero usa el método CreateCertificateRequest con los nuevos archivos PEM (privacy-enhanced mail) para crearlo. A continuación, usa el método UpdateCertificateMapEntry para sustituir la referencia del certificado antiguo en el mapa de certificados por la del nuevo.

    Importante: Debes completar este proceso en una llamada a la API sin que se produzca ningún tiempo de inactividad.

Aplicar los controles de acceso adecuados

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

Aplica el principio de mínimos accesos

Cuando asignes permisos para gestionar certificados, ten en cuenta el principio de mínimos accesos y concede los permisos mínimos necesarios para realizar una tarea. Te recomendamos que no uses los roles básicos de gestión de identidades y accesos. En su lugar, concede roles predefinidos o personalizados de Gestor de certificados y Servicio de Autoridades de Certificación para mitigar cualquier riesgo de incidentes de seguridad relacionados con el acceso con demasiados privilegios.

Plan de separación de funciones

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

Asegúrate de que tu grupo de administradores sea responsable de llevar a cabo las siguientes acciones:

  • Gestionar y mantener tu infraestructura de certificados, como el aprovisionamiento de ACs.
  • Configura las plantillas de certificados.
  • Gestiona tu lista de revocación de certificados (CRL) y los servidores de respuesta del protocolo de estado de certificados online (OCSP).
  • Implementa políticas de seguridad para tu CA.

En los proyectos que alojan una AC raíz, no asignes roles básicos, como Propietario (roles/owner), Editor (roles/editor) y Administrador del Servicio de Autoridades de Certificación (roles/privateca.admin), a ningún usuario ni grupo. De esta forma, se evitan eliminaciones accidentales, errores de configuración y una exposición excesiva. En su lugar, usa Gestor de acceso privilegiado (PAM) para el acceso justo a tiempo (JIT) según sea necesario, con justificación y aprobaciones después de instalar y configurar la AC raíz.

Asegúrate de que el grupo solicitante 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 indican los roles de IAM que suelen estar asociados a varias funciones de tareas:

Perfil ficticio Descripción Roles de gestión de identidades y accesos
Administradores de certificados Configurar y gestionar la infraestructura de AC y certificados. Propietario de Certificate Manager (roles/certificatemanager.owner)
Administrador del Servicio de Autoridades de Certificación (roles/privateca.admin)
Solicitante de certificados Solicita certificados para cargas de trabajo. Solicitante de certificados del servicio de Autoridades de Certificación (roles/privateca.certificateRequester)
Cargas de trabajo (cuentas de servicio de automatización) Usado por cargas de trabajo o en pipelines para solicitar certificados. Solicitante de certificados de carga de trabajo del servicio de Autoridades de Certificación (roles/privateca.workloadCertificateRequester)
Ingenieros de seguridad o propietarios de PKI Gestionar la política, la revocación y el ciclo de vida de los certificados. Gestor operativo del Servicio de Autoridades de Certificación (roles/privateca.caManager) Administrador de certificados del Servicio de Autoridades de Certificación (roles/privateca.certificateManager)
Ingenieros de DevOps o de plataformas Gestionar la implementación de certificados en balanceadores de carga y más. Editor de Certificate Manager (roles/certificatemanager.editor)
Auditor o cumplimiento Monitoriza los certificados y su uso. Visor de Certificate Manager (roles/certificatemanager.viewer) Auditor del servicio de Autoridades de Certificación (roles/privateca.auditor)

Usar la autorización de DNS por proyecto para las implementaciones multirregionales y multinube

Te recomendamos que uses el enfoque de autorización de DNS por proyecto para gestionar de forma independiente varias autorizaciones de 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 asegurar que cada proyecto mantenga su propio conjunto de registros y permisos de DNS. Este nivel de control permite que cada proyecto gestione sus configuraciones de DNS de forma autónoma, sin interferir en 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 correr el riesgo de que esto afecte negativamente a los sistemas de producción u otros proyectos en curso.

Usar registros CAA para proteger tus dominios

Los registros de autorización de autoridad de certificación (CAA) son un mecanismo de seguridad del sistema de nombres de dominio (DNS). Los registros CAA proporcionan a los propietarios de dominios un control total para configurar las autoridades de certificación (CAs) públicas 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 de los certificados fraudulentos, lo que hace que los sitios web sean más seguros.

En el caso de los certificados gestionados por Google, te recomendamos que autorices manualmente lo siguiente para que tus solicitudes de emisión y renovación de certificados sean lo más fiables posible:

Cloud Logging, Cloud Monitoring y visibilidad

En las siguientes secciones se describen las prácticas recomendadas para el registro de auditoría y para monitorizar el uso y la caducidad de los certificados.

Habilitar y agregar el registro de auditoría

Para monitorizar todos los recursos de tu organización, agrega los registros de auditoría de actividad de administración de todos los servicios, incluido Certificate Manager, en una ubicación centralizada.

De esta forma, tu equipo de seguridad o auditor puede revisar toda la actividad relacionada con la creación o modificación de recursos de Certificate Manager y CA Service en un solo lugar. Para obtener más información sobre cómo configurar los registros agregados, consulta Agrega y almacena los registros de tu organización.

Monitorizar el uso y la caducidad de los certificados

Te recomendamos que configures alertas basadas en registros para eventos importantes de Gestor de certificados, como el uso de una autoridad de certificación raíz, la caducidad de un certificado y la eliminación de un certificado. Estas alertas te ayudan a priorizar las operaciones, como una tasa alta de errores de creación de certificados, y pueden activar un proceso posterior para solicitar un nuevo certificado o aumentar la cuota.

Configura las siguientes alertas y políticas de registro 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 gestión de certificados, en lugar de productos o configuraciones específicos.

Por ejemplo, la normativa de seguridad de datos de la industria de tarjetas de pago de Estados Unidos (PCI DSS) y el Instituto Nacional de Estándares y Tecnología (NIST) exigen que las organizaciones documenten e implementen periodos de rotación para las claves de firma. También exigen la monitorizació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 pueden ayudar los servicios a cumplir varios requisitos de los marcos de cumplimiento, consulta los siguientes recursos: Google Cloud

Siguientes pasos