CA privada del administrador de certificados de AWS

AWS Private CA (anteriormente ACM Private CA) es un servicio de autoridad de certificación privada totalmente administrado que permite a los equipos de seguridad crear y operar una jerarquía PKI privada dentro de AWS sin necesidad de adquirir ni administrar hardware de CA. Emite certificados X.509 para TLS interno, mTLS, firma de código, identidad de dispositivos IoT y autenticación de usuarios. El punto de partida recomendado para la mayoría de los equipos es una jerarquía de dos niveles con una CA raíz dentro de AWS Private CA y una o más CA subordinadas por entorno, utilizando claves administradas por el cliente de AWS KMS para la protección de claves de CA, con un modelo híbrido (raíz local, CA subordinada de AWS) para organizaciones con requisitos estrictos de soberanía de claves.

Respuesta rápida: ¿Qué es AWS Private CA y cuándo debería utilizarlo?

AWS Private CA es la opción ideal cuando necesita emitir certificados privados X.509 para cargas de trabajo internas, requiere una jerarquía de CA que su equipo no tenga que ejecutar en hardware físico y opera principalmente en AWS. No reemplaza los certificados TLS públicos (AWS Certificate Manager los gestiona de forma gratuita para servicios integrados). Utilice AWS Private CA para la autenticación de servicios internos, mTLS entre microservicios, certificados de dispositivos IoT, certificados VPN de usuario y escenarios de firma de código donde una CA de confianza pública es innecesaria e indeseable. El servicio cuesta $400 por CA al mes para uso general y $50 por CA al mes para certificados de corta duración (válidos durante 7 días o menos), con tarifas escalonadas por certificado adicionales.

Puntos Clave

• AWS ofrece dos servicios distintos: AWS Certificate Manager (ACM) ofrece certificados TLS públicos gratuitos que se utilizan con los servicios integrados de AWS, y AWS Private CA proporciona certificados X.509 privados de confianza interna que se pueden exportar con su clave privada y utilizar en cualquier lugar.
• Existen dos modelos de jerarquía de CA disponibles: Nube privada (CA raíz y subordinadas en AWS Private CA, claves protegidas por AWS KMS) y nube híbrida (CA raíz local en su propio HSM, CA subordinadas en AWS Private CA). El modelo híbrido le otorga la custodia directa de la clave de la CA raíz; el modelo de nube privada le brinda automatización completa de la nube.
• Dos modos de funcionamiento modifican significativamente el coste: El modo de uso general, con un coste de 400 $/CA/mes, admite cualquier periodo de validez del certificado. El modo de certificado de corta duración, con un coste de 50 $/CA/mes, solo admite certificados con una validez de 7 días o menos, lo que lo convierte en una solución específica y rentable para mallas de servicios, identidades de carga de trabajo de estilo SPIFFE y entornos mTLS de alta frecuencia.
• El control de las llaves es una decisión de diseño, no una configuración predeterminada: AWS Private CA utiliza AWS KMS para proteger las claves de CA. Con las claves predeterminadas administradas por AWS, AWS mantiene la custodia operativa. Con las claves KMS administradas por el cliente (BYOK), usted conserva el material de la clave de origen y puede revocar la capacidad de firma de la CA al instante eliminando la clave importada. Un modelo HYOK completo requiere una arquitectura de nube híbrida con una CA raíz local.
• El foro CA/B SC-081v3 favorece el modo de corta duración para los certificados accesibles al público: La validez máxima de los certificados TLS públicos se reduce a 200 días a partir de marzo de 2026, a 100 días a partir de marzo de 2027 y a 47 días a partir de marzo de 2029. Las CA privadas emitidas a través de AWS Private CA ya pueden ajustarse a cualquier período de validez; combinarlas con la automatización del ciclo de vida de los certificados es fundamental a medida que aumenta la frecuencia de renovación.

AWS Certificate Manager frente a AWS Private CA: dos servicios diferentes

La confusión entre estos dos servicios es común y tiene consecuencias. Cumplen funciones diferentes, tienen modelos de precios distintos y no son intercambiables.

AWS Certificate Manager (ACM) proporciona y renueva certificados SSL/TLS públicos para su uso con servicios integrados de AWS, como Amazon CloudFront, Application Load Balancer, Amazon API Gateway y AWS Elastic Beanstalk. Los certificados públicos a través de ACM son gratuitos para su uso con estos servicios integrados. ACM gestiona la renovación automáticamente. La limitación principal es que no se puede exportar un certificado público gestionado por ACM ni su clave privada. Los certificados de ACM no se pueden instalar directamente en instancias EC2, servidores locales ni sistemas que no sean de AWS. Tampoco pueden emitir certificados para nombres de host internos o direcciones IP privadas que no superen la validación de dominio público.

AWS Private CA es un servicio administrado para operar una autoridad de certificación privada. Los certificados que emite son de confianza privada (los dispositivos y servicios de su organización deben estar configurados para confiar en la jerarquía de la CA). La clave privada se puede exportar con el certificado, lo que permite su instalación en cualquier lugar: instancias EC2, servidores locales, contenedores, dispositivos IoT y aplicaciones personalizadas. AWS Private CA admite nombres de host privados, direcciones IP internas y campos de asunto personalizados que las CA públicas no pueden emitir. Cobra una tarifa mensual de operación de CA más tarifas por emisión de certificado.

Dimensión	Administrador de certificados de AWS (ACM)	CA privada de AWS
fideicomiso de certificados	De confianza pública (almacenes de confianza del navegador y del sistema operativo)	Confianza privada (solo su jerarquía de CA)
Exportación de clave privada	No está permitido	Permitido (certificado + clave exportables)
Válido para nombres de host internos	No	Sí:
Costo	Gratuito para servicios integrados de ACM	$400/CAD/mes (uso general) o $50/CAD/mes (corta duración)
Auto renovación	Sí (gestionado por AWS)	Requiere automatización de CLM o renovación manual.
Casos de uso	HTTPS público para sitios web y API en servicios de AWS	TLS interno, mTLS, IoT, firma de código, VPN, autenticación de usuario
Custodia de llaves de CA	Gestionado por AWS (sin acceso para el cliente)	AWS KMS (compatible con claves gestionadas por el cliente)

Modelos de jerarquía de CA: Nube privada frente a nube híbrida

AWS Private CA admite dos arquitecturas de jerarquía de CA fundamentales. Elegir entre ellas es la decisión de diseño más importante, ya que determina quién custodia la clave raíz de la CA y el nivel de complejidad operativa que se acepta.

Modelo 1: Nube privada (CA raíz y subordinadas en AWS)

En este modelo, se crea una CA raíz dentro de AWS Private CA y una o más CA subordinadas (emisoras) bajo ella, todo dentro de AWS. La clave de la CA raíz está protegida por AWS KMS. AWS se encarga de la alta disponibilidad, la replicación y la protección de claves. La interacción con la CA se realiza completamente a través de la consola, el SDK y la CLI de AWS.

Este modelo ofrece todas las ventajas de la automatización en la nube: no requiere la gestión de hardware ni el aprovisionamiento de HSM, ofrece alta disponibilidad automática en todas las zonas de disponibilidad y la emisión de certificados mediante API se integra de forma nativa con los servicios de AWS. La desventaja es que la clave raíz de la CA reside en AWS KMS bajo el modelo de responsabilidad compartida. AWS tiene acceso operativo al material de la clave como parte del servicio gestionado. Para las organizaciones con requisitos normativos que exigen que la clave raíz de la CA esté exclusivamente en poder del cliente, este modelo no cumple con dichos requisitos a menos que se utilicen claves KMS gestionadas por el cliente (BYOK).

AWS Private CA admite hasta cinco niveles en una jerarquía de CA: una CA raíz con hasta cuatro niveles de CA subordinadas. Puede crear varias jerarquías independientes, cada una con su propia raíz. Para la mayoría de las empresas, una jerarquía de dos niveles (CA raíz más una CA emisora ​​por entorno) es suficiente y más fácil de auditar.

Modelo 2: Nube híbrida (CA raíz local, CA subordinada de AWS)

En este modelo, la CA raíz se aloja en las instalaciones del cliente, normalmente en un HSM dedicado bajo su control físico y lógico directo. La CA subordinada se crea en AWS Private CA, y usted firma la solicitud de firma de certificado (CSR) de la CA subordinada utilizando su CA raíz local. El certificado de la CA subordinada firmado resultante se importa de nuevo a AWS Private CA, activando así la CA subordinada para la emisión de certificados operativos.

Este modelo le otorga la custodia directa de la clave de la CA raíz. La clave de la CA raíz nunca ingresa a AWS. Si la CA subordinada de AWS Private CA se ve comprometida, un atacante no puede emitir nuevos certificados desde el nivel raíz, y usted puede revocar el certificado de la CA subordinada utilizando su CA raíz local sin depender de AWS. Las ventajas y desventajas son reales: debe operar y mantener la infraestructura de la CA raíz local, realizar ceremonias documentadas de la CA raíz para cualquier operación con la clave de la CA raíz y administrar la seguridad física y lógica del HSM local. Para las organizaciones con una PKI local existente que están migrando parcialmente a AWS, el modelo de nube híbrida proporciona un puente natural sin requerir un cambio completo del modelo de confianza.

Control de claves: KMS nativo, BYOK y HYOK para AWS Private CA

AWS Private CA protege las claves privadas de la CA mediante AWS KMS. La elección del tipo de clave KMS determina el nivel de control sobre el material de la clave de la CA y la capacidad de revocar el acceso de forma independiente.

Opción 1: Clave KMS administrada por AWS (predeterminada)

Cuando creas una CA privada sin especificar una clave KMS, AWS Private CA crea y administra una clave KMS en tu nombre. Esta clave está dedicada a tu CA, pero AWS la administra por completo. No puedes ver el material de la clave, rotarla de forma independiente ni eliminarla sin eliminar la CA. Esta es la opción más sencilla y satisface la mayoría de los requisitos operativos, pero no te permite revocar de forma independiente la capacidad de firma de la CA, salvo eliminándola a través de la consola o la API de AWS.

Opción 2: Clave KMS gestionada por el cliente (BYOK)

La opción BYOK (Bring Your Own Key) para AWS Private CA implica crear una clave administrada por el cliente (CMK) en AWS KMS, ya sea generada por AWS KMS o importada desde una fuente de claves externa, y especificar esa CMK al crear la CA privada. AWS Private CA utiliza su CMK para proteger la clave privada de la CA.

Con una clave maestra de cliente (CMK) gestionada por el cliente, puede deshabilitarla para impedir de inmediato que la CA realice operaciones de firma, sin necesidad de eliminarla. Puede consultar el uso de la clave en AWS CloudTrail. Usted controla la rotación de la clave maestra de cliente. Si utiliza material de clave importado (generando la clave externamente e importándola a KMS), conserva el material de clave de origen y puede eliminar el material de clave importado de KMS para revocar de forma permanente e inmediata la capacidad de firma de la CA, incluso sin la intervención del soporte de AWS.

BYOK es la opción adecuada para las organizaciones que necesitan un interruptor de desactivación independiente para la clave de la CA, que tienen requisitos reglamentarios para el material de clave generado por el cliente o que necesitan demostrar a los auditores que la organización conserva la procedencia de todas las claves criptográficas que protegen su infraestructura de CA.

Opción 3: HYOK (Hold Your Own Key) mediante arquitectura híbrida.

Para una CA raíz con verdadera seguridad de clave pública (HYOK), donde la clave de CA nunca ingresa a AWS bajo ninguna circunstancia, se requiere la arquitectura de nube híbrida descrita anteriormente: la CA raíz y su clave residen en un HSM local que usted controla, y solo las CA subordinadas se alojan en AWS Private CA. La CA subordinada dentro de AWS Private CA sigue utilizando una clave respaldada por KMS (que puede convertir en una CMK administrada por el cliente), pero la clave de nivel raíz está completamente fuera de la infraestructura de AWS.

Esto proporciona la máxima seguridad de clave a nivel de CA raíz. AWS no puede acceder ni ejercer la clave de la CA raíz bajo ninguna circunstancia, ni siquiera ante una orden judicial. La contrapartida es la mayor complejidad operativa que supone mantener una CA raíz local y la latencia del flujo de trabajo de firma entre entornos para las operaciones de las CA subordinadas.

Dimensión	Clave KMS administrada por AWS	Clave KMS gestionada por el cliente (BYOK)	HYOK (CA raíz local)
Ubicación de la llave CA	AWS KMS (gestionado por AWS)	AWS KMS (gestionado por el cliente)	Clave raíz: su HSM local; Clave subordinada: AWS KMS
Acceso de AWS a la clave raíz	Sí (operativo)	Sí (operacional, el cliente controla la rotación y la eliminación)	No para la clave raíz de CA
Interruptor de apagado independiente	Eliminar solo CA (mediante AWS)	Deshabilitar o eliminar CMK (inmediato, independiente)	Revocar el certificado de CA subordinado de la raíz local (inmediato)
Control de procedencia clave	AWS genera material clave	El cliente genera o importa el material clave.	El cliente genera y posee la clave raíz exclusivamente.
Complejidad operativa	Bajo	Media	Alto (requiere infraestructura local de HSM y ceremonias)
Ideal para	La mayoría de las cargas de trabajo nativas de AWS; prioridad a la simplicidad operativa.	Sectores regulados; requisito de control de claves independiente	Mandatos de soberanía estrictos; entornos clasificados o aislados

Modelo IAM para AWS Private CA: Diseño de privilegios mínimos

El control de acceso de AWS Private CA utiliza políticas de identidad de IAM y políticas basadas en recursos. Diseñar un acceso con privilegios mínimos requiere separar los roles que administran la CA de los roles que emiten certificados bajo su control.

Función de administrador de CA: Necesita permisos para crear, actualizar, etiquetar y eliminar CA, y para importar certificados de CA. Permisos clave: acm-pca:CreateCertificateAuthority, acm-pca:UpdateCertificateAuthority, acm-pca:DeleteCertificateAuthority, acm-pca:ImportCertificateAuthorityCertificate, acm-pca:TagCertificateAuthorityEste rol no debe ser otorgado acm-pca:IssueCertificate para mantener la separación de funciones.

Función de emisor del certificado: Necesita permisos para emitir y recuperar certificados y para configurar la revocación. Permisos clave: acm-pca:IssueCertificate, acm-pca:GetCertificate, acm-pca:RevokeCertificate, acm-pca:ListCertificateAuthorities. A este rol no se le deben otorgar permisos de administración de CA.

Emisión de certificados entre cuentas: Cuando una CA subordinada en una cuenta de AWS necesita emitir certificados para cargas de trabajo en otra cuenta de AWS, una política basada en recursos en la CA privada debe otorgar explícitamente acm-pca:IssueCertificate al principal de la cuenta solicitante. Este es el patrón correcto para los equipos de plataforma que operan un servicio PKI compartido en varias cuentas de AWS dentro de una estructura de AWS Organizations.

Integración de políticas clave de KMS: Si utiliza una clave KMS administrada por el cliente para la protección de la clave CA, la política de clave KMS debe otorgar al principal de servicio de AWS Private CA permiso para usar la clave para kms:Sign operaciones. Separar al administrador de claves KMS (quien puede gestionar la política de claves) del usuario de claves KMS (el servicio de CA privada) impide que una sola entidad principal controle la clave y emita certificados.

Modo de propósito general frente a modo de certificado de corta duración.

AWS Private CA introdujo un segundo modo de funcionamiento específicamente para cargas de trabajo de certificados de alta frecuencia y corta validez. Elegir el modo adecuado para cada CA en su jerarquía afecta significativamente tanto al costo como a la arquitectura.

El modo de uso general (400 $/CA/mes) admite la emisión de certificados con cualquier periodo de validez, desde segundos hasta años. Es adecuado para casos de uso tradicionales de PKI: certificados de servidor TLS, certificados de autenticación de usuario, certificados de firma de código y certificados de identidad de dispositivo con periodos de validez de varios años o meses. Admite todas las plantillas de certificados y la gama completa de algoritmos de clave (RSA 2048, RSA 4096, ECDSA P-256, ECDSA P-384).

El modo de certificado de corta duración (50 $/CA/mes) restringe la validez del certificado a 7 días o menos. Esta limitación es una característica para entornos que utilizan identidad de carga de trabajo estilo SPIFFE/SPIRE, mTLS de malla de servicios (Istio, Linkerd) o credenciales efímeras basadas en certificados, donde la corta duración elimina por completo la necesidad de comprobar la revocación. Con un coste equivalente a una octava parte del modo de propósito general, el modo de corta duración supone una optimización de costes significativa para entornos de emisión de certificados automatizados y de alta frecuencia. La combinación de una CA en modo de corta duración con un protocolo de inscripción ACME o EST y una plataforma CLM para la automatización de certificados constituye la arquitectura de producción para la infraestructura de clave pública (PKI) nativa de la nube moderna.

Qué puede emitir una CA privada de AWS: Tipos de certificados y casos de uso

AWS Private CA admite los siguientes tipos de certificados a través de plantillas configurables que imponen el uso correcto de la clave y extensiones de uso de clave extendidas:

• Certificados de servidor TLS: Servidores web internos, API y microservicios que requieren HTTPS con confianza privada. El certificado incluye la EKU de autenticación de servidor TLS (OID 1.3.6.1.5.5.7.3.1) y es validado por clientes que confían en su jerarquía de CA privada.
• Certificados de cliente mTLS: Autenticación TLS mutua entre servicios en arquitecturas de microservicios y mallas de servicios. Ambas partes presentan certificados; se incluye la EKU de autenticación de cliente TLS (OID 1.3.6.1.5.5.7.3.2). El modo de certificado de corta duración es óptimo para certificados de identidad de carga de trabajo mTLS que se renuevan en ciclos inferiores a 24 horas.
• Certificados de dispositivos IoT: Aprovisionamiento de identidad de dispositivos en tiempo de fabricación y autenticación de dispositivos de campo. AWS Private CA se integra con AWS IoT Core para la emisión de certificados a escala de flota. Los patrones IEEE 802.1AR IDevID y LDevID se pueden implementar mediante la API.
• Certificados de firma de código: Firma interna de artefactos de software para canalizaciones de CI/CD y distribución de firmware. La firma de código a través de AWS Private CA requiere la EKU de firma de código (OID 1.3.6.1.5.5.7.3.3) y la protección de clave adecuada para la clave de firma.
• Protección de correo electrónico (S/MIME): Correo electrónico interno cifrado mediante certificados con Email Protection EKU (OID 1.3.6.1.5.5.7.3.4). Para S/MIME empresarial a gran escala, Encryption Consulting Administrador de CertSecure Proporciona la capa CLM para la inscripción y la gestión del ciclo de vida.
• Certificados de firma OCSP: Obligatorio si configura el respondedor OCSP administrado de AWS Private CA. El EKU de firma OCSP (OID 1.3.6.1.5.5.7.3.9) se incluye automáticamente en los certificados de firma OCSP emitidos por el servicio.

OCSP y revocación de certificados en AWS Private CA

AWS Private CA admite dos mecanismos de revocación que se pueden habilitar de forma independiente para cada CA.

OCSP administrado es el respondedor del Protocolo de estado de certificados en línea (OCSP) alojado por AWS. Cuando está habilitado, AWS Private CA emite automáticamente certificados de firma OCSP, publica la URL del respondedor OCSP en la extensión de Acceso a la información de la autoridad (AIA) de los certificados emitidos y responde a las consultas OCSP sobre el estado del certificado. OCSP administrado tiene un costo de $0.06 por certificado al mes si se generaron respuestas OCSP para ese certificado, más $0.20 por cada 100,000 consultas OCSP. En entornos mTLS de alto volumen, donde cada conexión activa una verificación OCSP, estos costos se acumulan rápidamente. El modo de certificado de corta duración evita OCSP por completo, ya que los certificados caducan antes de que la revocación sea relevante.

La CRL (Lista de Revocación de Certificados) es el mecanismo de revocación alternativo. AWS Private CA puede publicar CRL en un bucket de Amazon S3 según una programación configurable. La distribución de la CRL requiere que el bucket de S3 sea accesible para todas las partes que dependen del certificado, lo que generalmente implica configurar el bucket para acceso público o restringido. La verificación de la CRL agrega una latencia al establecer la conexión equivalente al tiempo necesario para descargar y verificar la CRL.

Para la mayoría de las implementaciones de PKI privadas empresariales, el mecanismo de revocación preferido es OCSP administrado, ya que proporciona información de estado en tiempo real sin que los clientes tengan que descargar y almacenar en caché archivos CRL potencialmente grandes. Para entornos aislados o altamente sensibles donde no se desean consultas OCSP salientes, la alternativa adecuada es una CRL con un período de validez corto (publicación diaria o por hora).

Desglose de costos de la CA privada de AWS

Para comprender el costo total de AWS Private CA, es necesario considerar la operación de la CA, la emisión de certificados, OCSP y las operaciones de clave KMS que protegen la clave privada de la CA. La cifra original de $400/mes solo incluye el costo de operación de la CA en modo de uso general.

componente de costo	Modo de uso general	Modo de certificado de corta duración
Operación de CA (por CA por mes)	$400	$50
Certificados de 1 a 1,000 (por certificado)	$0.75	$0.058 (tarifa fija)
Certificados de 1,001 a 10,000 (por certificado)	$0.35	$0.058 (tarifa fija)
Certificados 10,001 o más (por certificado)	$0.001	$0.058 (tarifa fija)
OCSP (por certificado por mes, si se consulta)	$0.06	No aplica (los certificados caducan antes de que se necesite OCSP)
Consultas OCSP (por cada 100,000)	$0.20	N/A
Prueba gratis	30 días para la primera CA por cuenta y por región (solo operación de CA; se aplican tarifas de certificado).	30 días para la primera CA por cuenta por región

Como ejemplo práctico: una jerarquía de dos CA (CA raíz más una CA emisora) en modo de propósito general que emite 2,000 certificados al mes con OCSP habilitado cuesta aproximadamente 800 $ (operación de CA) más 1,025 $ en tarifas de certificados (1,000 x 0.75 $ más 1,000 x 0.35 $) más los costos de OCSP (2,000 x 0.06 $ = 120 $), lo que suma aproximadamente 1,945 $ al mes antes de los cargos de KMS. La proliferación de CA, donde cada entorno tiene su propia CA subordinada, multiplica la tarifa de operación de CA de 400 $ al mes en todas las CA. Consolidar los entornos bajo una única CA subordinada, cuando la política de seguridad lo permite, reduce significativamente el costo.

Para consultar la página de precios actual, visite aws.amazon.com/private-ca/pricing/.

Integración de la gestión del ciclo de vida de los certificados

AWS Private CA proporciona la infraestructura de CA, pero la gestión del ciclo de vida de los certificados (CLM) requiere herramientas adicionales. Dado que el informe SC-081v3 del Foro CA/B reduce la validez máxima de los certificados TLS públicos a 200 días a partir de marzo de 2026, a 100 días a partir de marzo de 2027 y a 47 días a partir de marzo de 2029, la renovación automática ya no es opcional, ni siquiera para los certificados privados que funcionan junto con los públicos.

AWS Private CA se integra de forma nativa con varios mecanismos de inscripción:

• Integración con AWS Certificate Manager: ACM puede usar una CA privada como su CA emisora ​​para los certificados que se implementan automáticamente en los servicios integrados de ACM. Esto le brinda confianza privada con la automatización de renovación e implementación gestionada por ACM.
• Protocolo ACME: El conector AWS Private CA para ACME (lanzado en 2023) permite que los clientes compatibles con ACME (cert-manager, certbot, acme.sh) soliciten certificados a su CA privada mediante el protocolo ACME estándar. Esta es la ruta de integración correcta para la automatización de certificados nativa de Kubernetes y las cadenas de herramientas de DevOps.
• Integración con Active Directory (AD CS): El conector AWS Private CA para Active Directory se integra con entornos Windows unidos a Microsoft AD, lo que permite que las máquinas y los usuarios unidos al dominio reciban certificados de AWS Private CA a través de los mecanismos de inscripción habituales de AD Certificate Services (inscripción automática, SCEP).
• API y SDK directos: La API de AWS Private CA admite la emisión programática de certificados a través del SDK en cualquier lenguaje compatible con AWS, lo que permite flujos de trabajo de inscripción personalizados para sistemas no estándar.

Para las organizaciones que gestionan certificados en AWS Private CA y otras fuentes de CA (Microsoft AD CS, PKI local, CA de proveedores en la nube), CertSecure Manager de Encryption Consulting ofrece detección unificada de certificados, automatización del ciclo de vida y supervisión de la caducidad, independientemente de la CA. Los volúmenes de AWS Private CA deben incluirse en cualquier inventario CLM empresarial.

Arquitectura PKI híbrida y multinube

Las organizaciones que utilizan AWS Private CA junto con Azure, GCP o entornos locales se enfrentan al mismo problema de coherencia entre nubes que con cualquier servicio de gestión de claves nativo de la nube: AWS Private CA es específico de AWS. Los certificados que emite son de confianza para los sistemas que confían en su jerarquía de CA privada, pero el plano de gestión de la CA, el registro de auditoría y la automatización del ciclo de vida son nativos de AWS y no se extienden automáticamente a otras nubes.

Existen tres patrones para abordar este problema en la infraestructura de clave pública (PKI) multi-nube:

• Jerarquía única de CA privada de AWS como raíz empresarial: Todos los entornos (AWS, Azure, GCP, locales) confían en la misma CA raíz alojada en AWS Private CA. Las CA subordinadas emiten certificados para cada entorno. La distribución de certificados entre nubes se gestiona mediante la implementación del certificado de la CA raíz en los almacenes de confianza de todos los sistemas. Este es el modelo más sencillo para organizaciones que se basan principalmente en AWS y tratan los demás entornos como implementaciones satélite.
• Autoridad de certificación raíz local con autoridades de certificación subordinadas en la nube: Una CA raíz local firma los certificados de CA subordinadas para AWS Private CA (para cargas de trabajo de AWS), CA subordinadas basadas en Azure (para cargas de trabajo de Azure) y cualquier otro entorno de nube. Todas las CA subordinadas comparten la misma raíz de confianza, pero operan de forma independiente dentro de sus respectivas plataformas de nube. Este es el modelo de nube híbrida extendido a múltiples nubes. La CA raíz local es el ancla de confianza definitiva.
• Sistema multi-CA unificado de CLM: Cada nube utiliza su servicio de CA nativo (AWS Private CA para AWS, Azure Active Directory Certificate Services o CA integradas en Azure para Azure, GCP Certificate Authority Service para GCP), y una plataforma CLM independiente de la nube agrega el inventario de certificados, supervisa la caducidad y aplica la política de rotación en todas las fuentes. Esto evita la complejidad de la jerarquía de CA entre nubes a costa de requerir una plataforma CLM capaz de integrarse con múltiples API de CA. Administrador de CertSecure Se integra con AWS Private CA y otras fuentes de CA para proporcionar esta capa de visibilidad unificada.

Mejores prácticas de ACM Private CA

1. Diseñe su jerarquía de CA antes del aprovisionamiento: Decida cuántos niveles de CA necesita (se recomienda un sistema de dos niveles para la mayoría de las empresas: CA raíz más CA emisora ​​por entorno), cuántas CA subordinadas crear y qué entornos compartirán una CA emisora ​​y cuáles tendrán CA dedicadas. La proliferación de CA aumenta los costos operativos mensuales y complica la revocación.
2. Documente su política y prácticas de certificación: Defina los períodos máximos de validez por tipo de certificado, los algoritmos y tamaños de clave permitidos, los usos extendidos de clave permitidos por plantilla de certificado y el flujo de trabajo de aprobación para cada categoría de certificado. AWS Private CA aplica estas normas mediante plantillas y controles de API; el documento de política es el que revisan los auditores.
3. Utilice claves KMS gestionadas por el cliente para la protección de claves de CA: Las claves administradas por AWS funcionan, pero ofrecen menos control. Las claves administradas por el cliente proporcionan una función independiente para deshabilitarlas o eliminarlas, además de un registro de auditoría más claro para las operaciones con claves en CloudTrail.
4. Habilitar CloudTrail para toda la actividad de la API de CA privada: Cada emisión o revocación de certificado, creación de CA y cambio de configuración de CA genera un evento de CloudTrail. Dirija estos eventos a un SIEM y configure alertas para la emisión de certificados de entidades principales inesperadas, solicitudes de eliminación de CA y eventos de desactivación de claves KMS para las claves que protegen las claves privadas de la CA.
5. Automatice la renovación de certificados antes de su vencimiento: AWS Private CA no renueva automáticamente los certificados que emite (a diferencia de ACM para los certificados públicos). Utilice el conector ACME, la integración con ACM o una plataforma CLM para automatizar la renovación. Con una validez de 47 días para los certificados públicos (a partir de marzo de 2029), la renovación manual resulta inviable. Implemente la automatización ahora.
6. Separe los roles de IAM del administrador de la CA y del emisor del certificado: Ningún principal de IAM debe tener permisos de administración de CA y de emisión de certificados simultáneamente. Configure roles separados y, para las CA sensibles, exija la autenticación multifactor (MFA) para todas las operaciones de administración de CA.
7. Mantenga la CA raíz inactiva cuando no esté en uso: Si su CA raíz en AWS Private CA no necesita emitir certificados de CA subordinados con regularidad, desactívela tras la configuración inicial de la jerarquía. Una CA raíz deshabilitada no puede utilizarse para emitir certificados, lo que reduce la superficie de ataque. Vuelva a activarla únicamente durante la renovación de las CA subordinadas o los cambios en la jerarquía.
8. Plan para el despliegue en múltiples regiones: AWS Private CA es un servicio regional. Si su conjunto de certificados abarca varias regiones de AWS, cree CA subordinadas en cada región donde la latencia de emisión de certificados sea importante. La CA raíz puede permanecer en una región; las CA subordinadas en otras regiones incurren cada una en su propia tarifa de operación de CA de $400/mes (o $50/mes).

Responsabilidad compartida en AWS Private CA

AWS Private CA opera bajo el modelo de responsabilidad compartida de AWS, con una clara división entre lo que pertenece a AWS y lo que pertenece al cliente.

Las responsabilidades de AWS incluyen la seguridad física de los centros de datos que alojan los HSM de KMS que protegen las claves de CA, la disponibilidad y durabilidad del propio servicio AWS Private CA, la validación FIPS 140-2 Nivel 3 de los HSM que protegen las claves administradas por KMS, la replicación automática de la configuración y las claves de CA en las zonas de disponibilidad dentro de una región, la seguridad de la infraestructura de respuesta OCSP administrada y la aplicación de parches y el mantenimiento de la infraestructura de servicio subyacente.

Las responsabilidades del cliente incluyen las decisiones de diseño de la jerarquía de CA, la configuración de la política de IAM (quién puede emitir certificados, quién puede administrar las CA), la elección del tipo de clave KMS (administrada por AWS o administrada por el cliente), la selección y configuración de la plantilla de certificado para cada CA, la configuración de revocación (habilitación de OCSP, acceso al bucket S3 de CRL), la configuración de supervisión y alertas para eventos de certificados, la automatización de la renovación de certificados, la distribución del certificado raíz de CA privado a todos los almacenes de confianza de las partes que confían en él, y la documentación de la Política de certificados y la Declaración de prácticas de certificación requeridas para los programas de cumplimiento.

Cómo puede ayudar la consultoría de cifrado

Encryption Consulting es una empresa de criptografía aplicada y seguridad en la nube con certificaciones ISO/IEC 27001:2022 y SOC 2. Ayudamos a las organizaciones a diseñar, implementar y gestionar implementaciones de AWS Private CA, desde el diseño inicial de la jerarquía hasta la automatización del ciclo de vida de los certificados y la recopilación de evidencia de cumplimiento.

• Infraestructura de clave pública como servicio: Para las organizaciones que desean PKI administrada sin la complejidad operativa de administrar AWS Private CA por sí mismas, Encryption Consulting ofrece PKI como servicio Ofrecemos una CA privada totalmente administrada con protección de claves HSM validada por FIPS, facilitación de la ceremonia de la CA raíz, documentación CP/CPS y monitoreo 24/7. Nos integramos con las cargas de trabajo de AWS, liberando a su equipo de la carga operativa de la CA.
• Administrador de CertSecure (CLM): AWS Private CA proporciona infraestructura de CA, pero no gestión del ciclo de vida de los certificados que emite. Administrador de CertSecure Proporciona detección de certificados, supervisión de caducidad, automatización de renovaciones mediante ACME y EST, e inventario unificado de certificados en AWS Private CA, Microsoft AD CS y otras fuentes de CA. Dado que el estándar CA/B Forum SC-081v3 reduce la validez de los certificados a 47 días, la gestión automatizada de certificados (CLM) se vuelve esencial.
• Servicios y asesoramiento sobre infraestructura de clave pública (PKI): Si está diseñando una jerarquía de CA para AWS Private CA, evaluando las ventajas y desventajas de la nube privada frente a la nube híbrida, o necesita una política de certificados y un documento CPS para una auditoría de cumplimiento, Encryption Consulting Servicios de PKI Abarca el diseño de la jerarquía de CA, la facilitación de ceremonias clave para implementaciones híbridas y el desarrollo de CP/CPS para cualquier marco de cumplimiento de PKI (NIST, WebTrust, ETSI).
• HSM como servicio: Para implementaciones híbridas que requieren una CA raíz local respaldada por un HSM dedicado validado por FIPS, Encryption Consulting ofrece HSM como servicio Proporciona la infraestructura HSM gestionada para su clave CA raíz sin necesidad de inversión en hardware HSM.
• CBOM Seguro: Las implementaciones de AWS Private CA que han crecido orgánicamente a menudo contienen más CA, certificados y tipos de claves de los que los equipos de seguridad pueden rastrear manualmente. CBOM seguro Descubre e inventaría todos los activos criptográficos de su entorno AWS, incluidos los certificados emitidos por la CA privada de AWS, las claves KMS y los certificados ACM, y genera una lista de materiales criptográficos (CBOM) en formato CycloneDX para fines de cumplimiento y auditoría.
• Preparación para PQC: El NIST finalizó los estándares de criptografía post-cuántica FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) en agosto de 2024. El informe IR 8547 del NIST apunta a la desaprobación de RSA y ECC para nuevos usos alrededor de 2030. Si su jerarquía de CA privada de AWS utiliza claves de CA RSA o ECDSA en la actualidad, la planificación de la migración debería comenzar ahora. Preparación para PQC El servicio evalúa su jerarquía de CA privada de AWS en función del cronograma de migración post-cuántica y diseña la ruta de transición del algoritmo.

Para hablar sobre el diseño de su CA privada de AWS, la automatización de CLM o los requisitos de cumplimiento, póngase en contacto con Encryption Consulting.

Conclusión

AWS Private CA elimina la necesidad de adquirir hardware, el espacio físico que ocupa un centro de datos y la complejidad operativa de gestionar una autoridad de certificación privada, al tiempo que conserva todos los controles de seguridad importantes: la elección del algoritmo de clave, el diseño de la jerarquía de la CA, la separación de roles impuesta por IAM, la protección de claves respaldada por KMS con control del cliente y un registro de auditoría completo de CloudTrail de cada operación de certificado.

Las decisiones clave que determinan si una implementación de AWS Private CA es segura, rentable y auditable no son predeterminadas: el modelo de jerarquía de nube privada frente a nube híbrida, el tipo de clave KMS (administrada por AWS frente a BYOK administrada por el cliente), el modo operativo (de propósito general a 400 $/CA/mes frente a de corta duración a 50 $/CA/mes para certificados de menos de 7 días), la separación de roles de IAM entre los administradores de CA y los emisores de certificados, y la capa de automatización de CLM que gestiona la renovación a medida que los períodos de validez de los certificados se reducen hacia los 47 días.

Las organizaciones que migran de una infraestructura de clave pública (PKI) local a una CA privada de AWS deben considerarlo una oportunidad para rediseñar su PKI, no una simple migración. El modelo de nube híbrida preserva la soberanía de la clave raíz de la CA, al tiempo que ofrece las ventajas operativas de la nube para la emisión de certificados. La opción BYOK (Bring Your Own Key) con claves KMS gestionadas por el cliente proporciona un interruptor de desactivación independiente y una procedencia de claves que los auditores pueden verificar. El modo de certificado de corta duración, con un coste operativo equivalente a una octava parte del de la CA, es la arquitectura idónea para cualquier caso de uso de mTLS de alta frecuencia o de identidad de carga de trabajo.

Preguntas frecuentes

¿Qué es AWS Private CA y en qué se diferencia de AWS Certificate Manager (ACM)?

AWS Private CA (anteriormente ACM Private CA) es un servicio de autoridad de certificación privada administrada que emite certificados X.509 de confianza privada para cargas de trabajo internas. AWS Certificate Manager (ACM) proporciona certificados TLS públicos gratuitos para su uso con los servicios de AWS integrados con ACM. Los certificados de ACM no se pueden exportar; los certificados de Private CA se pueden exportar con su clave privada para su uso en cualquier lugar. Los certificados de ACM son de confianza pública; los certificados de Private CA solo son de confianza para los sistemas que usted configure para que confíen en su jerarquía de CA.

¿Cuál es la diferencia entre los modelos de nube privada y nube híbrida en AWS Private CA?

En el modelo de nube privada, tanto la CA raíz como las CA subordinadas se encuentran en AWS Private CA, con las claves almacenadas en AWS KMS. En el modelo de nube híbrida, la CA raíz se encuentra en las instalaciones del cliente, en un HSM que usted controla, y solo las CA subordinadas están en AWS Private CA. El modelo híbrido le otorga la custodia directa de la clave de la CA raíz; el modelo de nube privada proporciona automatización completa de la nube sin necesidad de infraestructura local.

¿Cuánto cuesta AWS Private CA al mes?

AWS Private CA cobra $400 por CA al mes para el modo de propósito general y $50 por CA al mes para el modo de certificado de corta duración (certificados válidos por 7 días o menos). La emisión de certificados se realiza por niveles: $0.75 cada uno para los primeros 1,000, $0.35 cada uno para los certificados del 1,001 al 10 000 y $0.001 cada uno por encima de los 10 000 por región al mes para las CA de propósito general. Los certificados de corta duración tienen un precio fijo de $0.058 cada uno. OCSP añade $0.06 por certificado al mes si se consulta, más $0.20 por cada 100 000 consultas. AWS ofrece una prueba gratuita de 30 días para la operación de CA para la primera CA privada por cuenta y por región.

¿AWS Private CA admite BYOK (Bring Your Own Key)?

Sí. AWS Private CA utiliza AWS KMS para proteger las claves de CA. Por defecto, utiliza claves KMS administradas por AWS. Al crear la CA, puede especificar una clave KMS administrada por el cliente (con material de clave importado). Con el material de clave importado, conserva la clave de origen y puede eliminarla de KMS para impedir de inmediato que la CA firme nuevos certificados. El verdadero HYOK (donde la clave de CA nunca ingresa a AWS en ningún nivel) requiere una arquitectura de nube híbrida con una CA raíz local.

¿Qué permisos de IAM requiere AWS Private CA?

Los administradores de CA necesitan los permisos acm-pca:CreateCertificateAuthority, acm-pca:UpdateCertificateAuthority, acm-pca:DeleteCertificateAuthority y acm-pca:ImportCertificateAuthorityCertificate. Los emisores de certificados necesitan los permisos acm-pca:IssueCertificate, acm-pca:GetCertificate y acm-pca:RevokeCertificate. Estos roles deben ser independientes: ninguna entidad principal debe tener permisos tanto de administración de CA como de emisión de certificados. La emisión entre cuentas requiere una política basada en recursos en la CA privada que otorga el permiso IssueCertificate a la entidad principal de la cuenta solicitante.

¿Qué tipos de certificados puede emitir AWS Private CA?

AWS Private CA puede emitir certificados X.509 para autenticación de servidor TLS, autenticación de cliente TLS (mTLS), firma de código, protección de correo electrónico (S/MIME), firma OCSP y usos personalizados específicos de la aplicación. Admite los algoritmos de clave RSA 2048, RSA 4096, ECDSA P-256 y ECDSA P-384. Las plantillas de certificado aplican los usos de clave permitidos y extendidos para cada tipo de certificado, impidiendo la emisión de tipos de certificado no definidos en la plantilla.