eviav
LoginCrear cuenta

Política de Seguridad — Eviav

Última actualización: 2026-05-28

Eviav opera infraestructura de mapas e información geoespacial para empresas en LATAM. La seguridad de los datos de nuestros clientes y de sus usuarios finales es responsabilidad permanente del equipo.

1. Arquitectura y aislamiento

  • Multi-tenancy estricto por organización (org_id). Cada API key, request, evento de uso y dataset privado lleva un org_id que se filtra explícitamente en cada query a la base de datos. Cross-tenant lookups son imposibles por design en el código del gateway.
  • API keys hasheadas en reposo (SHA-256). El texto plano se muestra UNA sola vez al crear la key y nunca se guarda.
  • Scopes por key: cada API key puede limitarse a un subconjunto de los 18 servicios. Una key con scope geocode no puede llamar a /v1/grounding, etc.
  • Rate limit en 4 capas (per-IP/min, per-key/min, per-key/seg burst, per-key/month quota). Bloquea abuse y protege upstreams.

2. Encryption

  • In transit: TLS 1.3 obligatorio en todos los endpoints públicos (eviav.com, api.eviav.com, tiles.eviav.com, status.eviav.com). Cloudflare Full(Strict) mode entre Cloudflare y origen. HSTS habilitado.
  • At rest:
    • PostgreSQL/PostGIS con volúmenes encriptados a nivel disco (LUKS en host Linux).
    • Redis con requirepass + AUTH; no se persiste a disco datos sensibles.
    • Backups offsite encriptados con restic (AES-256) antes de subir a Vultr Object Storage.

3. Autenticación y autorización

  • Cuentas de usuario via Better Auth + verificación email obligatoria + reset password con tokens efímeros (1h).
  • 2FA TOTP (Google Authenticator, 1Password, Authy compatible) disponible — obligatorio para cuentas business como opción del owner.
  • Para enterprise: SSO/SAML con Okta, Azure AD, Google Workspace (en roadmap, Pilar 7 L1).

4. Audit logs

Eventos sensibles registrados append-only en tabla admin_events con: timestamp, user_id, org_id, action, client_ip, user_agent, status. Visible al owner desde /dashboard/auditoria y retenido 24 meses.

Eventos cubiertos: signup/login/logout, 2FA enable/disable, API key create/revoke/rotate, billing payment_method attach/detach, invoice paid/failed, plan changes, tileset create/delete, login fallidos.

5. Hardening operacional

  • SSH: solo key-based, password disabled, root login prohibit-password, max 3 retries, ClientAliveInterval 5min.
  • Firewall: ufw default deny incoming, solo SSH/80/443 abiertos.
  • fail2ban: ban 1h tras 4 intentos fallidos.
  • Unattended security upgrades automatizadas (Ubuntu).
  • Headers seguridad en el gateway: HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy. Helmet.js configurado.

6. Vulnerability scanning

  • Dependabot + Snyk monitorean dependencias automáticamente.
  • GitHub Code Scanning en cada push.
  • Penetration test anual por firma externa (próximo: 2026 Q3, parte del SOC 2 readiness).

7. Incident response

Si detectamos un incidente de seguridad:

  1. T+0: detección automática (alertas Prometheus/Slack) o reporte externo.
  2. T+15min: triage por on-call engineer. Severity assignment (P0/P1/P2/P3).
  3. T+1h: contención inicial — rotar credenciales comprometidas, bloquear vectores, snapshot forense.
  4. T+24h: comunicación a clientes afectados via email y status.eviav.com.
  5. T+7d: post-mortem público con root cause, impacto, remediación.

Reporte responsable de vulnerabilidades: [email protected]. Respondemos en <24h hábiles. Bug bounty program en roadmap (HackerOne).

8. Compliance roadmap

  • ✅ GDPR / LGPD — minimal compliance baseline: derechos de acceso/eliminación, política de cookies, DPA template.
  • 🔄 SOC 2 Type II — en preparación 2026, target Q3-Q4 (auditor independent + Vanta para compliance automation).
  • 📅 ISO 27001 — planificado 2027 (después de SOC 2).

9. Sub-procesadores

Lista pública mantenida en SUBPROCESSORS.md. Incluye Stripe (pagos), Cloudflare (CDN+DNS+WAF), Vultr (hosting), OpenAI (AI grounding).

10. Contacto