cifraHQ Enterprise
Cumplimiento

SOC 2 no es una casilla. Está en el esquema.

La evidencia de auditoría vive en el principal SQL, no en la capa de aplicación. Cuatro mecanismos aseguran que nadie — ni un ingeniero — pueda alterar la historia.

Solicitar demo Ver arquitectura
Los cuatro mecanismos

Cómo garantizamos la inmutabilidad

Trazabilidad

Dual audit trail

Temporal tables en cada entidad de negocio mutable + tabla append-only <code>AuditEvents</code>. Unificados en una vista "Cambios…".

Inmutabilidad

DENY UPDATE/DELETE

El principal SQL de la aplicación tiene <code>DENY</code> sobre <code>AuditEvents</code>. Solo <code>audit_admin</code> puede purgar.

Secretos

Azure Key Vault

Cadenas de conexión, claves de API, credenciales SMTP — nunca en código, nunca en appsettings, nunca en la base.

Dual audit trail

Dos registros, dos propósitos

  • Temporal tables de SQL Server sobre cada entidad mutable. Cada UPDATE deja una fila histórica con ValidFrom/ValidTo. Transparente al código de aplicación.
  • AuditEvents append-only para eventos de negocio discretos: "Invoice 12345 posted", "Period 2026-03 closed", "User X granted Approve permission". No UPDATE, no DELETE.
  • Vista unificada en la UI. Cada detalle de documento tiene "Cambios…" que merge ambas fuentes cronológicamente.
  • Razones obligatorias. Transiciones reversas (reverse-close, void) requieren un texto de razón mínimo 20 caracteres, logueado al AuditEvents.
DENY a nivel principal

Por qué esto importa

Un sistema que confía en el código de aplicación para bloquear escrituras no es defendible en SOC 2. Un ingeniero con acceso a la base puede alterar la historia. Nosotros cerramos esa puerta en el motor.

  • Tres principales SQL por tenant: app_rw (solo lecturas/escrituras normales), audit_admin (único que puede purgar auditoría), readonly_investigator (consola de investigación).
  • Consola de investigación. Cada consulta del administrador en el dashboard pasa por readonly_investigator y se registra en AuditEvents.
  • Posting irreversible. Una factura posted no se edita; se anula con void y se emite una nota de crédito. El motor de posting verifica ActualPostingDate y rechaza UPDATEs.
Postura SOC 2

Controles concretos, no promesas

  • CC6.1 Acceso lógico. Modelo RBAC con permisos como constantes nombradas (Permissions.Invoice.Approve). Sin cadenas mágicas.
  • CC7.2 Monitoreo. Pistas de auditoría duales + logs de Hangfire. Integración Azure Monitor con alertas por salud de tenant.
  • CC8.1 Cambios. Pipeline CI/CD firmado. Migraciones de esquema versionadas; cada despliegue registra la versión en CiferaHQ_master.
  • A1.2 Integridad de procesamiento. Temporal tables + AuditEvents + DENY UPDATE demuestran integridad sin confiar en la aplicación.
  • P1/P3 Privacidad. Base por tenant = aislamiento físico de datos personales. Borrado del cliente elimina la base.

Revisemos su cuestionario de seguridad

Le respondemos su SIG Lite, CAIQ o proceso de vendor review en una reunión de 30 minutos.

Agendar