Firmar software con certificados confiables ya no es sinónimo de mover toda la cadena de compilación a la nube. Con la estrategia de Cloud‑based Trusted Signing puedes conservar tus servidores locales y, al mismo tiempo, aprovechar la validación centralizada y la custodia segura de claves que ofrece el proveedor cloud.
Compatibilidad con entornos on‑premises
El servicio está diseñado con una API first que permite interactuar desde cualquier infraestructura, ya sea un clúster de compilación local, un pipeline de CI de terceros o incluso un script de automatización. El único requisito indispensable es la salida a Internet para comunicarse con el extremo de Trusted Signing, lo que evita desplegar HSM caros o mantener certificados raíz en tus propias instalaciones.
Arquitectura de referencia
A continuación se describe un flujo típico al firmar un ejecutable desde un servidor on‑premises:
- Generación del hash local. El servidor de compilación calcula un hash SHA‑256 del binario o del componente que va a distribuirse.
- Petición de firma. Ese hash se envía por HTTPS a la API de Trusted Signing junto con el identificador del certificado deseado.
- Procesamiento cloud. El servicio verifica políticas, aplica el sello de tiempo y realiza la firma criptográfica empleando las claves alojadas en un módulo HSM de nivel FIPS 140‑2.
- Respuesta a la red interna. El blob de firma (o la cadena PKCS #7) se devuelve al servidor local.
- Inyección de firma. El pipeline integra la firma en el archivo final antes de publicarlo en repositorios internos o portales de descarga.
Ventajas principales
- Seguridad reforzada. Las claves privadas nunca abandonan el HSM en la nube, minimizando el riesgo de compromiso interno.
- Auditoría centralizada. Todas las peticiones de firma quedan registradas con detalle (quién, cuándo, artefacto, resultado), facilitando el cumplimiento de normas como ISO 27001 o SOC 2.
- Elasticidad. Picos de tráfico —por ejemplo, la generación masiva de parches— se absorben automáticamente sin dimensionar hardware local.
- Facilidad de integración. SDK oficiales para PowerShell, CLI, .NET y REST simplifican la llamada desde scripts o plataformas de DevOps como GitHub Actions, Jenkins o Azure DevOps.
Escenarios de uso frecuentes
Firmas de código para Windows
Al compilar controladores, instaladores MSI o ejecutables de línea de comandos, la firma Authenticode obtenida del servicio cloud garantiza que los usuarios no verán advertencias SmartScreen y que el binario no ha sido manipulado.
Contenedores y microservicios
Trusted Signing también admite firmar .tar o manifestos OCI de imágenes Docker. Así tus registros internos pueden rechazar contenedores sin firma válida, endureciendo la cadena de suministro.
Firmware y dispositivos IoT
Los fabricantes de hardware que mantienen plantas de ensamblaje desconectadas pueden enviar únicamente el hash del firmware y recibir la firma sin exponer el código fuente completo.
Requisitos previos
| Elemento | Detalle |
|---|---|
| Conectividad | Salida HTTPS (puerto 443) desde los servidores de compilación al dominio del servicio |
| Autenticación | Token de aplicación o identidad administrada con permisos Signer |
| Compatibilidad OS | Windows Server 2012 R2 o posterior, macOS 11+, Linux kernel 3.10+ |
| Herramientas | Signtool, jarsigner, elementos equivalentes o SDK oficial |
Buenas prácticas de implementación
Separar entornos
Crea perfiles de firma distintos para desarrollo, ensayo y producción. Así podrás emitir certificados provisionales que no se mezclen con la cadena de confianza definitiva.
Uso de identidades de carga de trabajo
Configura identidades administradas por el proveedor cloud para evitar el almacenamiento de secretos en variables de entorno o archivos de configuración.
Políticas de aprobación múltiple
Habilita flujos de doble control en la consola del servicio. Un artefacto no se firmará hasta que dos personas —o un sistema y una persona— aprueben la solicitud, reduciendo riesgos de insider threat.
¿Qué ocurre si la conexión se interrumpe?
El servicio devuelve códigos de estado transitorios (429 o 503) acompañados de cabeceras Retry‑After. Implementa reintentos exponenciales. Para eventos prolongados, mantén un clúster HSM local como respaldo o planifica ventanas fuera de línea.
Cálculo de costes
El modelo de precios suele basarse en “firmas por mes” y almacenamiento de certificados. Al centralizar la clave raíz se eliminan licencias de HSM on‑premises que suelen superar las cinco cifras anuales. Considera además:
- Transferencia de datos (normalmente marginal, al enviarse solo hashes de pocos kilobytes).
- Eventos de sello de tiempo, que en algunos planes se facturan aparte.
- Cargos por soporte, si requieres SLA crítico de menos de una hora.
Comparación con un HSM local
| Criterio | HSM local | Trusted Signing cloud |
|---|---|---|
| Inversión inicial | Alta (hardware + licencias) | Baja (pago por uso) |
| Escalabilidad | Limitada al chasis adquirido | Lineal, bajo demanda |
| Mantenimiento | Firmware, parches, auditorías in situ | Delegado al proveedor |
| Control físico | Total en la sala segura | Custodia externa en centros de datos certificados |
| Onboarding | Semanás de aprovisionamiento | Horas o minutos |
Pasos de implementación rápida
# 1. Autenticarse
az login
2. Registrar la aplicación que firmará
az signtool app create --name "build-agent-prod"
3. Subir tu certificado (opcional, si no usas uno gestionado)
az signtool cert upload --file .\cert.pfx --password \$PFXPASS
4. Firmar un binario desde PowerShell
\$signed = az signtool sign --file .\miApp.exe --app build-agent-prod
Write-Output "Firma guardada en: \$signed"Preguntas frecuentes
¿Puedo funcionar sin conexión en absoluto?
No. La premisa de Trusted Signing es que la clave raíz reside en la nube. Para entornos completamente aislados necesitas un HSM físico o un sistema de air‑gapped signing.
¿Se exponen mis binarios al subirlos?
No subes el binario completo, solo el hash. Eso significa que ningún código ejecutable viaja a la nube, preservando la confidencialidad de tu propiedad intelectual.
¿Qué algoritmos de firma admite?
RSA‑2048/3072/4096, ECC P‑256/P‑384 y SHA‑256/384. La compatibilidad con SHA‑1 ha sido retirada.
¿Cómo revoco una firma comprometida?
Puedes añadir el certificado a la lista de revocación (CRL) y volver a firmar los artefactos con uno nuevo. El proveedor emite automáticamente un sello de tiempo actualizado.
Conclusiones
Adoptar la firma de confianza basada en la nube en entornos on‑premises conjuga lo mejor de ambos mundos: mantienes tu control sobre la producción local y eliminas la complejidad de proteger claves sensibles. Con conectividad mínima y una integración API, Cloud‑based Trusted Signing se erige como la solución más eficiente para organizaciones que demandan seguridad de nivel empresarial sin trasladar toda su carga de trabajo a la nube.