Seguridad
Arquitectura y controles de seguridad de la plataforma SatGo | Última actualización: Agosto 2026
¿Preguntas sobre seguridad? Escríbenos a security@sat-go.com
Nuestro principio fundamental: Zero-Knowledge Architecture
SatGo actúa exclusivamente como intermediario de tránsito entre tu sistema y el portal gubernamental correspondiente (SAT, IMSS, INFONAVIT, entre otros). Los documentos que descargamos en tu nombre nunca tocan un disco. Existen únicamente en memoria RAM durante el tiempo que tarda el request, y son descartados inmediatamente después de entregártelos.
Esto significa que incluso ante una orden judicial, una brecha de seguridad, o cualquier otro evento, no existe ningún repositorio de documentos fiscales de nuestros clientes que pueda ser comprometido, porque simplemente no lo tenemos.
Bring Your Own Key (BYOK) — Credenciales en tu infraestructura
Para clientes del plan Empresarial, SatGo ofrece un modelo donde las credenciales de acceso al SAT (CIEC) nunca salen de tu propia infraestructura. En lugar de enviarnos tus credenciales, las almacenas en tu propio Azure Key Vault y otorgas a SatGo un permiso de solo lectura mediante un App Registration en Azure AD.
Modelo estándar (todos los planes)
- Tu sistema envía la solicitud con RFC
- SatGo accede al SAT con credenciales en memoria
- Documento entregado y credencial descartada
Modelo BYOK (plan Empresarial)
- CIEC guardada en tu Azure Key Vault
- SatGo la lee vía RBAC — sin que transite por internet
- Usada en memoria y descartada. Tú controlas el acceso.
Con BYOK, SatGo nunca "posee" tus credenciales. Puedes revocar nuestro acceso en cualquier momento desde tu propio portal de Azure, sin depender de nosotros. Azure registra cada lectura en tu propio audit log, visible directamente en tu suscripción.
Guía paso a paso: monta BYOK en tu propio Azure Key Vault →
Desde crear la suscripción de Azure hasta registrar la llave, sin conocimientos previos. Incluye la variante en la que SatGo custodia el vault por ti.
e.firma — Tú eliges cómo se maneja tu llave
Para operaciones que requieren e.firma (firma electrónica avanzada del SAT), tú decides cuál de estas tres modalidades usar. La responsabilidad de cada una se detalla en la Cláusula 4.5 de los Términos de Servicio:
- Transmisión directa: envías tu e.firma a SatGo; se usa únicamente en memoria durante la operación y no se persiste al concluir. Es la opción más simple y la decides tú. Opcionalmente puedes cifrarla en tu propio dispositivo antes de enviarla (ver el recuadro abajo), de modo que SatGo nunca la reciba en claro.
- Key Vault propio (BYOK): la llave privada (.key) nunca sale de tu infraestructura; SatGo la lee vía RBAC sin almacenarla. Tú controlas y revocas el acceso.
- Key Vault administrado por SatGo: a solicitud tuya, SatGo custodia tu e.firma cifrada en un Azure Key Vault administrado por SatGo, para no tener que reenviarla cada vez. Puedes pedir su eliminación en cualquier momento.
En términos prácticos: si eliges el modelo BYOK (Key Vault propio), incluso ante un compromiso total de los sistemas de SatGo, un atacante no podría obtener tu llave privada ni firmar en tu nombre sin acceso a tu propia infraestructura. En las otras modalidades, la protección se basa en el cifrado, el uso en memoria y los controles de acceso descritos en esta página.
Cifrado de la e.firma en tu dispositivo (opcional)
Como capa adicional para la modalidad de transmisión directa, puedes cifrar la llave privada (.key/.pfx) y su contraseña en tu propio navegador o sistema antes de enviarlas, usando el estándar abierto JWE (RSA-OAEP-256 + A256GCM) con una llave pública que publica SatGo. Así, la e.firma viaja siempre cifrada y SatGo solo la descifra en memoria, en el instante de usarla, con una llave privada que reside en su Azure Key Vault. El certificado .cer es público y va en claro.
Beneficio: ni siquiera durante el tránsito o en registros/proxies intermedios se expone tu llave o contraseña en claro — solo la llave privada de SatGo (que nunca sale de su Key Vault) puede abrir el sobre. Es una opción a tu elección: la activas por petición con el header X-Fiel-Encryption: JWE. Ver la guía para cifrar tu e.firma (desde el navegador o por línea de comandos) o los detalles técnicos en la documentación de la API.
Cómo fluyen tus datos
Paso a paso
- 1Tu sistema llama a nuestra API enviando el RFC y el tipo de documento solicitado, autenticado con tu API key, sobre una conexión TLS 1.3.
- 2SatGo recibe la solicitud en memoria y valida tu API key y los permisos del RFC solicitado.
- 3SatGo llama al portal gubernamental correspondiente utilizando las credenciales en memoria (nunca escritas a disco), sobre TLS.
- 4El portal responde con el documento, que SatGo mantiene en RAM.
- 5SatGo entrega el documento directamente a tu sistema via stream, sin escribirlo a ningún sistema de almacenamiento.
- 6El dato es descartado de RAM al terminar el request. No queda ninguna copia en nuestros sistemas.
¿Qué SÍ almacenamos?
Solo lo estrictamente necesario para operar el servicio:
| Dato | Propósito | Dónde |
|---|---|---|
| RFC registrado | Identificador de cuenta | Base de datos Azure Mexico Central |
| Correo electrónico | Acceso y notificaciones | Base de datos Azure Mexico Central |
| Historial de operaciones | Auditoría (tipo, fecha, resultado — sin contenido) | Base de datos Azure Mexico Central |
| Datos de facturación | Emisión de CFDI | Base de datos Azure Mexico Central |
¿Qué NO almacenamos?
- Contenido de CFDIs, constancias, declaraciones ni ningún documento fiscal
- Credenciales del SAT (CIEC, e.firma), salvo cuando eliges expresamente la modalidad de Key Vault administrado por SatGo, en cuyo caso las custodiamos cifradas hasta que solicites su eliminación
- Datos sensibles de ningún tipo
El manejo de tus credenciales del SAT depende de la modalidad que elijas (transmisión directa, Key Vault propio o Key Vault administrado por SatGo). Ver el detalle y la responsabilidad de cada una en la Cláusula 4.5 de los Términos de Servicio.
Controles de seguridad
Transporte y cifrado
| Control | Detalle | Estado |
|---|---|---|
| TLS en todos los endpoints | TLS 1.2 mínimo, TLS 1.3 preferente | ✅ Activo |
| Calificación SSL Labs | Evaluación pública e independiente | ✅ Calificación A |
| HSTS | HTTP Strict Transport Security con preload | 🔄 En implementación |
| Cifrado en tránsito | Todos los canales API y portal web | ✅ Activo |
Autenticación y acceso
| Control | Detalle | Estado |
|---|---|---|
| API keys rotables | Generación y revocación desde el portal sin intervención de SatGo | ✅ Activo |
| Autenticación de usuarios | Gestionada por Clerk (magic link por email + OAuth2 con Google) | ✅ Activo |
| MFA | Código por email en cada acceso + Google 2FA | ✅ Activo |
| Principio de mínimo privilegio | Acceso a datos restringido por rol | ✅ Activo |
| Revocación de acceso | Inmediata desde el portal web | ✅ Activo |
| BYOK — Credenciales en Key Vault del cliente | CIEC/e.firma almacenada en Azure Key Vault del cliente; SatGo accede vía RBAC con rol de solo lectura, sin almacenarla | ✅ Plan Empresarial |
| e.firma — Modalidad a elección del cliente | Transmisión directa (uso en memoria, sin persistencia), Key Vault propio (la llave nunca sale de tu infraestructura) o Key Vault administrado por SatGo (custodia cifrada). Ver Cláusula 4.5 de los Términos | ✅ Activo |
| e.firma — Cifrado en el dispositivo del cliente (opcional) | La llave y la contraseña se pueden cifrar en el navegador/sistema del cliente (JWE RSA-OAEP-256 + A256GCM) antes de enviarse; SatGo solo descifra en memoria con una llave privada en su Key Vault | ✅ Activo |
Infraestructura
| Control | Detalle | Estado |
|---|---|---|
| Proveedor de nube | Microsoft Azure | ✅ Activo |
| Región | Mexico Central (datos en territorio mexicano) | ✅ Activo |
| Transferencias internacionales | No aplica para datos de operación (solo pagos vía Stripe) | ✅ Confirmado |
| Segmentación de red | Controles de acceso por red en Azure | ✅ Activo |
| Monitoreo continuo | Alertas y detección de anomalías 24/7 | ✅ Activo |
Auditoría y transparencia
| Control | Detalle | Estado |
|---|---|---|
| Log de auditoría por cliente | Visible desde el portal: RFC, operación, fecha, resultado | ✅ Activo |
| Status page público | Uptime histórico e incidentes en tiempo real | ✅ sat-go.com/status |
| Notificación de incidentes | Compromiso de notificación al cliente en 72 horas | ✅ Documentado en DPA |
| RTO (Recovery Time Objective) | Tiempo máximo de recuperación ante caída | 4 horas |
| RPO (Recovery Point Objective) | Máxima pérdida de datos aceptable (datos de cuenta) | 24 horas |
Cumplimiento legal
| Marco | Descripción | Estado |
|---|---|---|
| LFPDPPP | Ley Federal de Protección de Datos Personales en Posesión de los Particulares | ✅ Cumplimiento activo |
| Aviso de Privacidad | Publicado y actualizado | ✅ sat-go.com/privacidad |
| Términos y Condiciones | Publicados y actualizados | ✅ sat-go.com/terminos |
| DPA (Data Processing Agreement) | Disponible para clientes del plan Empresarial | ✅ Disponible bajo solicitud |
| PCI DSS (pagos) | Procesamiento de tarjetas delegado a Stripe (Nivel 1) | ✅ Vía Stripe |
Proveedores y subencargados
SatGo utiliza los siguientes proveedores para la prestación del servicio. Todos fueron seleccionados por sus estándares de seguridad reconocidos internacionalmente:
| Proveedor | Función | País / Región | Certificaciones |
|---|---|---|---|
| Microsoft Azure | Infraestructura en la nube | Mexico Central | ISO 27001, SOC 2, CSA STAR |
| Stripe, Inc. | Procesamiento de pagos | Estados Unidos | PCI DSS Nivel 1 |
| Clerk | Autenticación e identidad | Estados Unidos | SOC 2 Type II |
| Portales gubernamentales (SAT, IMSS, INFONAVIT) | Fuentes de datos oficiales | México | — |
Para clientes enterprise
DPA (Acuerdo de Tratamiento de Datos)
Los clientes del plan Empresarial pueden solicitar la firma de un Data Processing Agreement (DPA) que formaliza:
- Las categorías de datos tratados y la base legal
- Los subencargados autorizados
- El compromiso de notificación de incidentes en 72 horas
- Los derechos de auditoría anual
- Los procedimientos de eliminación de datos al término del servicio
Para solicitar el DPA: legal@sat-go.com
Cuestionario de seguridad
Contamos con un cuestionario de seguridad pre-llenado (formato SIG Lite) disponible bajo NDA para agilizar el proceso de evaluación de vendor. Solicítalo en: security@sat-go.com
Reporte de vulnerabilidades
Si encuentras una vulnerabilidad de seguridad en nuestros sistemas, te pedimos reportarla de forma responsable antes de divulgarla públicamente:
Correo: security@sat-go.com
Asunto: [Vulnerability Report] Descripción breve
Incluye: Descripción del hallazgo, pasos para reproducirlo, impacto potencial estimado
Nos comprometemos a:
- Confirmar la recepción en 48 horas hábiles
- Mantener comunicación contigo durante la investigación
- Notificarte cuando el hallazgo sea resuelto
- Reconocer tu contribución (si lo deseas) en nuestro hall de agradecimientos
No iniciaremos acciones legales contra investigadores de seguridad que actúen de buena fe conforme a estas directrices.
Contacto de seguridad
| Canal | Uso |
|---|---|
| security@sat-go.com | Reporte de vulnerabilidades, cuestionarios de seguridad, auditorías |
| legal@sat-go.com | Solicitud de DPA, contratos enterprise |
| privacidad@sat-go.com | Derechos ARCO, aviso de privacidad |
| sat-go.com/status | Status page y uptime histórico |
SatGo — Hebert Ricardo Peña Serna — RFC: PESH8805072Q5
Última actualización: Agosto 2026 | security@sat-go.com