La postura de seguridad está en el esquema. Integración vía el mismo OpenAPI que usa la UI.
Lo que TI evalúa cuando aprueba un ERP — aislamiento, secretos, auditoría, API — lo puede leer en el código y en los objetos de SQL. No está prometido, está configurado.
Los cuatro dolores del director de TI al evaluar un ERP
- Postura SOC 2 que depende de la aplicación. La mayoría de los ERPs confían el bloqueo de auditoría al código — un ingeniero con acceso a la base puede reescribir la historia. cifraHQ aplica
DENY UPDATE/DELETEa nivel principal SQL sobreAuditEvents; tres principales por tenant (app_rw,audit_admin,readonly_investigator) separan roles de una forma que el auditor puede verificar. - Aislamiento de datos que no se puede evidenciar. Row-level security con
WHERE TenantId = ?no pasa una revisión de cumplimiento rigurosa.DB-per-tenantsobre Azure SQL elastic pools entrega una base SQL física por cliente, con backup y restore punto-en-tiempo independientes. Un isolation fuzzer en CI verifica que ningún query cruza la barrera entre tenants. - API que "existe" pero no está documentada ni versionada. El integrador promete REST y entrega un endpoint por request. cifraHQ publica
OpenAPI 3.0— el mismo spec que consume el frontend — con concurrencia optimista víaRowVersion, auto-save por PATCH, webhooks firmados HMAC y transiciones de estado como sub-recursos POST. - Secretos en appsettings y jobs que corren in-process. Cadenas de conexión y claves en archivos de configuración es una falla de auditoría. Trabajo de fondo en el proceso web es una falla de disponibilidad. Todos los secretos viven en Azure Key Vault; Hangfire corre el trabajo asíncrono (provisioning, FOREX diario, webhooks, envío de correo) fuera del request-reply path.
Tres mecanismos específicos
DB-per-tenant
Base SQL física por cliente sobre Azure elastic pools. Backup, restore y baja limpia por tenant. Isolation fuzzer en CI valida la barrera cada commit.
OpenAPI 3.0 público
El spec que consume la UI es el que usted consume. Concurrencia con <code>RowVersion</code>, auto-save por PATCH, transiciones como <code>POST</code> sub-recursos, webhooks HMAC.
Key Vault + Hangfire
Secretos fuera del código; trabajo asíncrono fuera del request-reply. Retries con backoff exponencial por categoría; auditoría de delivery de webhooks visible.
El paquete de revisión técnica
- Spec
OpenAPI 3.0público. El contrato completo, el mismo que usa nuestro frontend. Con sandbox para probar flujos de integración sin tocar su tenant productivo. - Cuestionario de seguridad respondido. SIG Lite, CAIQ o el formato que use su proceso de vendor review. Le contestamos con referencias a controles concretos (
CC6.1,CC7.2,CC8.1,A1.2,P1/P3), no con generalidades. - Demo del isolation fuzzer. El test de CI que prueba cross-tenant. Le mostramos el pipeline, las pruebas y el resultado del último build.
- Arquitectura de provisioning. La saga Hangfire (
crear DB → migrar esquema → seed COA → blob → admin → email). Cómo se da de alta un tenant nuevo y cómo se da de baja un cliente que termina contrato. - Dashboard de salud por tenant. Métricas por tenant — DTU usados, storage, jobs Hangfire fallidos, últimos despliegues. Integrable con Azure Monitor para alertas.
- Política de despliegue. Pipeline CI/CD firmado; migraciones de esquema versionadas; cada despliegue registrado en
CiferaHQ_master. Rollback auditado.
Habla con ventas para TI
Le respondemos el SIG Lite, le compartimos el OpenAPI público y recorremos la arquitectura con su equipo en una reunión de 45 minutos.