La clave privada de tu certificado en tu propio HSM de nube: qué es firma remota y qué no
Piensa en una empresa que factura con agente automatizado y tiene su ERP corriendo en AWS desde hace dos años: una función Lambda arma el XML, lo firma con el certificado que compraron para eso y lo manda a su OSE. La clave privada vive hoy en un archivo .pfx dentro de Secrets Manager, con una contraseña que conoce el equipo de infraestructura. En la última auditoría de seguridad alguien hizo la pregunta obvia: si todo lo demás ya está en AWS, ¿por qué no metemos la clave privada en AWS CloudHSM, que es justamente el servicio hecho para esto?
Es una pregunta razonable, y la respuesta se cruza con otra cosa que ya está regulada en Perú: la firma remota acreditada ante INDECOPI. Conviene separarlas antes de decidir nada, porque son dos servicios distintos que resuelven problemas distintos.
Lo que distingue a la firma remota no es que la clave privada esté lejos
El D.S. 029-2021-PCM, del 19 de febrero de 2021, modificó el artículo 35 del reglamento de la Ley 27269 y definió así la modalidad acreditable:
«Sistema de creación de firma remota, que permite efectuar operaciones de creación de firma digital utilizando claves privadas que se encuentran localizadas remotamente y son gestionadas por un tercero».
La condición no es la distancia. Es «gestionadas por un tercero». Un HSM en tu propia cuenta de AWS, con tus propias credenciales de administrador y sin que nadie de AWS tenga acceso a lo que hay dentro, no encaja en esa frase de la misma forma que un servicio de firma remota contratado a un proveedor. AWS lo dice así en las preguntas frecuentes de CloudHSM: «AWS has no access to any keys or data inside your CloudHSM Cluster and cannot perform any operations other than those allowed for an HSM appliance user». Quien gestiona la clave privada sigues siendo tú, aunque el fierro esté en un centro de datos que no es tuyo.
Por eso la Resolución 175-2024/DGI-INDECOPI, del 24 de junio de 2024, que ya cubrimos entera en qué exige INDECOPI para acreditar la firma remota, pide su acreditación a «las entidades privadas o públicas que quieran obtener su acreditación como Prestadores de Servicios de Valor Añadido en la modalidad de Firma Remota». Eso describe a quien ofrece el servicio a otros, con una póliza que cubra «expresamente el servicio de firma remota» y domicilio en el país. No describe a la empresa que solo firma sus propias facturas y decide dónde guardar su propia clave privada.
Qué exige el reglamento a quien firma, sea cual sea el HSM
El artículo 7 del D.S. 052-2008-PCM, sin tocar desde 2008, pone la condición en términos simples: «Su generación está bajo el control exclusivo del suscriptor». Ese artículo no distingue token, HSM propio ni servicio de terceros. Pide una cosa: que el control sea tuyo.
El artículo 6, modificado por el D.S. 029-2021-PCM, la matiza para cuando la firma se crea a distancia: exige medios «que garantizan que éste mantiene bajo su control con un elevado grado de confianza». Y el artículo 8 a), modificado el mismo día, presume «que el suscriptor del certificado digital tiene el control de la clave privada asociada, con un elevado grado de confianza, incluso cuando la misma es gestionada por un Prestador de Servicios de Valor Añadido acreditado en la modalidad de sistema de creación de firma remota».
Fíjate en la última cláusula: la presunción reforzada está escrita para el caso del proveedor acreditado. Si tu clave privada vive en tu propio HSM de nube, esa presunción específica no te aplica tal cual, porque no hay un PSVA de por medio. Lo que te queda es la regla general del artículo 7: control exclusivo, sin más. Un HSM que tú administras, con logs que tú controlas y sin acceso del proveedor de nube, es un candidato razonable para sostener esa exclusividad. No es una certeza automática: no hemos comprobado que INDECOPI o un juez peruano hayan tenido que resolver un caso así. Qué obligaciones cambian cuando la clave privada sí la guarda un proveedor acreditado está en las obligaciones del reglamento cuando tu clave privada la guarda otro.
Los tres servicios, con lo que cada uno certifica de verdad
Qué es un HSM y en qué se diferencia de un token o de la firma remota lo contamos en firma remota y HSM: dónde vive tu clave privada. Aquí va lo específico de la nube. Las tres nubes venden dos productos distintos bajo el nombre de HSM: uno administrado donde tú no tocas el módulo (AWS KMS, Cloud KMS de Google, el Key Vault estándar de Azure), y otro donde alquilas un HSM dedicado o de un solo inquilino y lo administras tú (AWS CloudHSM, Google Cloud HSM, Azure Managed HSM).
En AWS se puede comprobar con nombre y apellido. Su página de validación FIPS de CloudHSM enlaza el certificado CMVP #4218 para las instancias hsm1.medium, FIPS 140-2 nivel 3, y avisa de que ese certificado pasaba a la lista histórica el 4 de enero de 2026. En el sitio de NIST, hoy, el #4218 figura como Historical («Moved to historical list due to sunsetting»). La instancia que AWS recomienda ahora, hsm2m.medium, usa el certificado #4703, FIPS 140-3 nivel 3, Active, con vencimiento el 5 de junio de 2029. Su servicio administrado, AWS KMS, corre sobre un módulo distinto, el certificado #3009, FIPS 140-2, también Historical hoy, por la transición al estándar SP 800-56A revisión 3. Que un certificado pase a histórico no significa que el HSM sea inseguro: la ficha de NIST aclara que la recomendación de no usarlo en nuevas adquisiciones aplica a agencias federales de Estados Unidos. Sí significa que «tu proveedor tiene FIPS» caduca, y que conviene comprobar el certificado vigente antes de citarlo en un contrato.
Azure y Google publican el nivel sin el número de certificado. Azure Key Vault Managed HSM dice que usa «Marvell LiquidSecurity HSM adapters» validados FIPS 140-3 nivel 3, de un solo inquilino por cliente. Google Cloud HSM dice que opera en «a cluster of FIPS 140-2 Level 3 certified HSMs». Ninguna de las dos páginas enlaza el certificado de NIST correspondiente, y no encontramos una ficha en csrc.nist.gov que ambas empresas atribuyan de forma explícita a ese servicio. Con AWS se pudo verificar el número exacto; con Azure y Google, el nivel FIPS que declaran queda sin verificar aquí.
Exportar la clave privada, o no poder
La otra diferencia práctica es si puedes sacar la clave privada del HSM. En AWS CloudHSM, salvo que la generes como «no exportable», puedes envolverla y moverla a otro clúster o a un HSM comercial compatible, dice su propio FAQ. En AWS KMS, en cambio, las claves privadas que el servicio genera no salen del módulo bajo ninguna operación normal. Azure Managed HSM permite importar claves privadas desde tu HSM local, y su «Secure Key Release» solo entrega una clave privada marcada como exportable, y bajo atestación previa.
Para un certificado de firma digital esto importa poco en el día a día, porque no vas a mover esa clave privada salvo que cambies de HSM. Importa el día que tengas que demostrar, ante un peritaje, que nadie más pudo haber firmado con ella. Un CloudHSM administrado por ti, con la clave privada marcada no exportable desde que se generó dentro del módulo, es un argumento más limpio que un .pfx que viajó por correo alguna vez.
Lo que no resuelve el HSM: dónde vive el certificado
Meter la clave privada en tu propio HSM de nube no cambia quién te emitió el certificado. Sigue siendo una Entidad de Certificación acreditada dentro de la Infraestructura Oficial de Firma Electrónica, y el procedimiento de emisión sigue pasando por ella. No hemos revisado la Declaración de Prácticas de Certificación de ninguna EC peruana para confirmar si admiten generar la solicitud de firma directamente dentro de un HSM cloud o si exigen recibir la clave privada en otro formato. No lo afirmamos porque no lo comprobamos: pregúntaselo por escrito a la EC antes de montar nada.
Tampoco hay región de ninguna de las tres nubes en el Perú. Lo comprobamos en las páginas oficiales: la infraestructura de AWS en Sudamérica más cercana a Lima es un punto de presencia de CloudFront, que es una caché de contenido, no una región con cómputo. Azure lista Brasil y Chile como sus únicas geografías sudamericanas. Google Cloud tiene southamerica-east1 en São Paulo y southamerica-west1 en Santiago. La Resolución 175-2024 exige domicilio en el país a quien se acredita como prestador, no que los servidores estén aquí, así que esto no bloquea nada legalmente. Si te importa la latencia o dónde queda alojado el dato, es un motivo aparte para elegir región, no uno que toque el reglamento de firmas.
Cuándo compensa
Si tu sistema ya corre en una nube pública y firma sin que una persona intervenga, mover la clave privada a un HSM administrado por ti dentro de esa misma cuenta es mejor que dejarla en un archivo con contraseña, y no exige nada nuevo de INDECOPI porque sigues siendo tú quien la gestiona. Si en cambio necesitas que varias personas firmen desde el navegador con OTP, o quieres ofrecerle firma a otras empresas, ahí entras en el terreno de la firma remota acreditada, con su propia póliza y los estándares CEN y ETSI de la resolución. Confundir las dos cosas lleva a pedirle a un proveedor de nube una acreditación que no ofrece, o a saltarte una que sí necesitabas.
Lo que no afirmamos
Que Azure o Google usen un certificado CMVP concreto para su HSM administrado. Sus páginas declaran el nivel FIPS sin enlazar el número de certificado, y no encontramos una ficha de NIST que ellos mismos atribuyan a ese servicio.
Que una EC peruana acreditada permita generar o importar un certificado directamente en un HSM de nube. No revisamos su CPS para confirmarlo.
Que un HSM propio en una nube pública equivalga jurídicamente a estar acreditado como firma remota. Son cosas distintas por definición, y esta página explica por qué, no que una sustituya a la otra si lo que necesitas es ofrecer el servicio a terceros.
Fuentes de esta página
- Ley 27269, Ley de Firmas y Certificados Digitales.
- D.S. 052-2008-PCM: artículo 7 (texto original, sin modificar).
- D.S. 029-2021-PCM, de 19 de febrero de 2021: Segunda Disposición Complementaria Modificatoria, artículos 6, 8 y 35 del reglamento de la Ley 27269.
- Resolución 175-2024/DGI-INDECOPI, de 24 de junio de 2024: artículo primero.
- AWS CloudHSM: preguntas frecuentes y validación FIPS.
- NIST CMVP: certificados #4218, #4703 y #3009.
- Azure Key Vault Managed HSM, documentación oficial.
- Google Cloud HSM, documentación oficial.
- Páginas de regiones: AWS, Azure, Google Cloud.
Todas se descargaron el 25 de septiembre de 2026.
En mifirmadigital.pe emitimos certificados de persona jurídica y de agente automatizado dentro de la Infraestructura Oficial de Firma Electrónica. Si tu sistema ya corre en una nube pública y quieres revisar si un HSM propio te resuelve algo real, o si lo que necesitas es firma remota acreditada, escríbenos con tu caso.
Última revisión: 25 de septiembre de 2026.