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 Certificate Manager y Certificate Authority Service (CA Service). 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 conocer las páginas de descripción general de Certificate Manager y descripción general de 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 el ciclo de vida completo de tus certificados. Estas decisiones afectan el costo, la sobrecarga operativa y la facilidad con la que se implementan 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, asegúrate 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 ser 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 certificadora (CA) raíz en su propio proyecto de Google. La CA raíz firma algunas CA intermedias, y esas CA luego 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 errores de configuración. Aunque el servicio de CA es regional, una CA raíz en una región puede firmar CA 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 proyecto Google Cloud para firmar la CA emisora.

  • Crea CAs emisoras en grupos de CA alojados en proyectos separados. Aloja estos grupos en proyectos separados y segméntalos 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 CA emisora que pueda emitir certificados de confianza privada para los recursos admitidos.

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

Usa una cobertura integral del nombre de host

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

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

Si planeas agregar nuevos subdominios o servicios 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 los certificados públicos y una mayor facilidad de uso, te recomendamos que uses certificados administrados por Google. Este enfoque reduce significativamente la sobrecarga operativa, ya que 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 otrosGoogle Cloud servicios. Los certificados administrados por Google son válidos durante 90 días, y el proceso de renovación comienza aproximadamente un mes antes de que venzan.

Expande y mejora el rendimiento de tu certificado

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.

Aplica la implementación descentralizada para 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 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, como las cuotas y los límites se aplican a nivel del proyecto Google Cloud , implementar Certificate Manager 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 el tipo de clave recomendado para la mayoría de los certificados TLS, ya que 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 posibles motivos 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 los certificados ECDSA P-256.
  • Si tienes requisitos de cumplimiento específicos que exigen 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 la 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-3072.
  • Una clave ECDSA de 384 bits proporciona un mayor nivel de seguridad que cualquier tamaño de clave RSA ampliamente compatible.

Beneficios clave de ECDSA:

  • Rendimiento: Las operaciones de firma ECDSA requieren significativamente menos recursos de procesamiento que las operaciones 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 alto rendimiento 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 recursos limitados, 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 AC (certificados administrados con confianza privada), no a los certificados autoadministrados ni a los certificados administrados por Google con 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 AC es un conjunto de varias AC 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 por segundo (QPS) efectivas totales, ya que balancea la carga y distribuye las solicitudes de certificados entrantes entre 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 tus CA de forma segura 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 escalar, ya que 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 devuelve 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 Solo puedes aprovisionar certificados después de que el balanceador de cargas esté completamente configurado y preste servicio al 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 manualmente antes de que venzan. Te recomendamos que automatices este proceso con las ofertas de administración del ciclo de vida de los certificados (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 coordinar una rotación de certificados sin problemas. En este proceso, se incluyen los siguientes pasos:

  1. Supervisa el vencimiento de los certificados con Cloud Monitoring y las 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 tu clave privada a la CA y, luego, recupera el certificado nuevo.

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

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

    Importante: Debes completar este proceso en una sola llamada a la API sin que se produzca 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, considera 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 de Certificate Manager 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 quienes tienen el rol de emisor o solicitante de certificados. Para ello, crea grupos separados de administradores y solicitantes 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 la CA
  • Configurar plantillas de certificados
  • Administra tu lista de revocación de certificados (CRL) y los respondedores del protocolo de estado de certificados en línea (OCSP).
  • Implementa políticas de seguridad para tu CA.

En el caso de los proyectos que alojan una AC raíz, evita asignar roles básicos, como Propietario (roles/owner), Editor (roles/editor) y Administrador del servicio de AC (roles/privateca.admin), a cualquier usuario o grupo. Esta práctica evita la eliminación accidental, la configuración incorrecta y la sobreexposición. En su lugar, usa Privileged Access Manager (PAM) para el acceso just-in-time (JIT) según sea necesario con justificación y aprobaciones después de que se instale y configure 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 la emisión de certificados basados en plantillas predefinidas.

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

Arquetipo Descripción Funciones de IAM
Administradores de certificados Configurar y administrar la infraestructura de certificados y de la CA Propietario del Administrador de certificados (roles/certificatemanager.owner),
Administrador del Servicio de CA (roles/privateca.admin)
Solicitante del certificado Solicita certificados para cargas de trabajo. Solicitante del certificado del servicio de CA (roles/privateca.certificateRequester)
Cargas de trabajo (cuentas de servicio de automatización) Las cargas de trabajo o las canalizaciones lo usan para solicitar certificados. Solicitante de certificados de cargas de trabajo del Servicio de la entidad certificadora (roles/privateca.workloadCertificateRequester)
Ingenieros de seguridad o propietarios de PKI Administrar 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 servicio de la entidad certificadora (roles/privateca.certificateManager)
Ingenieros de DevOps o de plataformas Administrar la implementación de certificados en balanceadores de cargas y mucho más Editor del Administrador de certificados (roles/certificatemanager.editor)
Auditor o cumplimiento Supervisar los certificados y su uso Visualizador del Administrador de certificados (roles/certificatemanager.viewer), Auditor del servicio de la entidad certificadora (roles/privateca.auditor)

Usa la autorización de DNS por proyecto para las 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 múltiples regiones, múltiples nubes y en todo el ciclo de vida de 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 y permisos de DNS. Este nivel de control permite que cada proyecto administre 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 se produzca un impacto negativo en los sistemas de producción o 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 brindan a los propietarios de dominios el control completo para configurar las autoridades certificadoras (CA) públicas que pueden emitir certificados para sus dominios. Este control es importante para evitar la emisión no autorizada de certificados. Con la CAA implementada, se reduce la superficie de ataque para los certificados fraudulentos, lo que hace que los sitios web sean más seguros.

En el caso de los certificados administrados por Google, te recomendamos que autorices manualmente lo siguiente para garantizar 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 la supervisión del uso y la fecha de 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 de todos los servicios, incluido Certificate Manager, 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 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.

Supervisa el uso y el vencimiento de los certificados

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

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

Requisitos de cumplimiento

Por lo general, los marcos de cumplimiento especifican expectativas y objetivos generales 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) exigen 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 los certificados de firma de confianza que protegen los datos de los titulares de tarjetas.

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

¿Qué sigue?