01 · Transporte y almacenamiento
Cifrado de datos en tránsito y almacenados
En tránsito · TLS 1.3
Toda comunicación entre el navegador del usuario y los servidores de Ethoz utiliza TLS 1.3. Cloudflare actúa como capa de terminación TLS, con certificados gestionados automáticamente y renovación antes de vencimiento.
At-rest · AES-256
Los datos almacenados en la base Postgres (Cloud SQL) están cifrados con AES-256. Las claves son gestionadas por Google Cloud en la región Santiago (southamerica-west1). Un acceso físico no autorizado al servidor no permite leer datos en texto plano.
02 · Control de acceso
Row-Level Security
Row-Level Security es el mecanismo de control de acceso más granular disponible en bases de datos relacionales. En Ethoz, cada consulta es evaluada por una política RLS antes de retornar cualquier resultado.
Sin autenticación válida, RLS retorna cero filas, independientemente de la tabla consultada.
Cómo funciona en la práctica
- Un docente consulta asistencia → RLS retorna solo los registros de sus propios cursos.
- Un inspector consulta asistencia global → RLS retorna datos del establecimiento completo, sin informes psicológicos.
- Un sostenedor consulta métricas → RLS retorna datos agregados de todos sus colegios, sin datos individuales de estudiantes.
- Solicitud sin autenticación → cero filas, sin importar la tabla.
Esta arquitectura garantiza el principio de mínimo privilegio exigido implícitamente por la Ley 21.719 y explícitamente por las buenas prácticas de protección de datos.
03 · Identidad
Autenticación y sesiones
- Autenticación con JWT (Firebase Auth)
- La autenticación usa Firebase Auth con JSON Web Tokens firmados en RS256. Cada token contiene el identificador del usuario y su rol, verificado por RLS en cada consulta.
- Sesiones con expiración automática
- Los tokens de acceso tienen expiración corta (1 hora por defecto). Los refresh tokens permiten renovación silenciosa mientras la sesión está activa, y se invalidan al cerrar sesión o tras inactividad.
- Rotación de tokens
- Cada renovación genera un nuevo refresh token e invalida el anterior. Esto limita el impacto de un token comprometido: la ventana de uso es acotada.
- Multi-factor authentication (roadmap)
- MFA mediante TOTP está en el roadmap para cuentas de directivos y sostenedores.
04 · Trazabilidad
Audit log
Cada acción sensible queda registrada en un log de auditoría inmutable. No es posible eliminar entradas sin acceso directo a la base de datos con privilegios de administrador.
Estructura de una entrada del audit log
{
"id": "uuid",
"timestamp": "2026-04-07T14:32:11.000Z",
"user_id": "uuid-del-usuario",
"user_role": "docente",
"action": "UPDATE",
"resource": "libro_clases.asistencia",
"record_id": "uuid-del-registro",
"old_value": { "presente": true },
"new_value": { "presente": false },
"ip_address": "192.168.1.xxx",
"user_agent": "Mozilla/5.0 ..."
}- Qué acciones se registran
- Modificaciones al libro de clases
- Retiros de estudiantes
- Cambios de contraseña
- Acceso a datos sensibles
- Exportaciones de datos
- Quién puede consultar el log
- Director del establecimiento
- Sostenedor (vista agregada)
- Autoridades de fiscalización
- Ethoz (soporte técnico)
- Retención
- Mínimo 5 años por defecto
- Configurable por sostenedor
- Cumple plazos Ley 21.719
- Exportable en CSV/JSON
05 · Tenancy
Aislamiento de datos por colegio
Cada colegio y cada sede tienen sus datos aislados mediante políticas RLS. No existe mecanismo por el cual un usuario de un colegio pueda acceder a datos de otro establecimiento, incluso si ambos pertenecen al mismo sostenedor.
Jerarquía de aislamiento
- Sostenedor
- ve métricas agregadas de todos sus colegios
- Colegio
- ve solo sus propios datos, sin cruce con otros
- Sede
- para sostenedores multi-sede, cada sede es un ámbito independiente
- Rol
- cada usuario accede solo a lo que su rol permite dentro de su colegio
06 · Continuidad
Respaldo y recuperación
Respaldos diarios automáticos
Cloud SQL realiza respaldos automáticos diarios de la base de datos, cifrados en reposo, gestionados por Google Cloud.
Point-in-time recovery
Es posible restaurar la base a cualquier punto en el tiempo dentro de la ventana de retención (hasta 30 días). Crítico ante ransomware o eliminación accidental.
RTO y RPO
Recovery Time Objective: menos de 4 horas para incidentes mayores. Recovery Point Objective: máximo 24 horas de pérdida (un ciclo de backup).
Plan de continuidad
Ethoz mantiene un plan de recuperación ante desastres documentado. Los colegios son notificados ante cualquier incidente que afecte la disponibilidad.
07 · Stack
Infraestructura
Ethoz opera sobre infraestructura de clase empresarial, seleccionada por su madurez en seguridad, disponibilidad geográfica en la región y compliance con estándares internacionales.
Componente
Ubicación
Función
Cloud SQL (Postgres)
Google Cloud Santiago (southamerica-west1)
Base de datos principal con RLS multi-colegio
Firebase Hosting
CDN global (Google)
Hosting del frontend y autenticación (Firebase Auth)
Cloudflare
Red global edge
DNS, DDoS protection, WAF, TLS termination
Los datos de los colegios chilenos se almacenan en la región Google Cloud Santiago, en territorio chileno, con latencia mínima para colegios en el país.
08 · Marco normativo
Cumplimiento normativo
- Ley 21.719 by design
- Privacidad incorporada desde el diseño. Control de acceso, audit log y minimización de datos son nativos, no añadidos.
- GDPR-compatible
- Derechos de acceso, rectificación, supresión y portabilidad implementados. Consentimiento granular y trazable.
- Circular N°30
- Trazabilidad e integridad del libro de clases digital cumplidas mediante audit log inmutable y autenticación robusta.
- SOC 2 roadmap
- Proceso de certificación SOC 2 Type II planificado para 2027. Controles técnicos ya implementados.
09 · Reporte
Divulgación responsable
Si descubre una vulnerabilidad de seguridad en Ethoz, le pedimos que la reporte de forma responsable antes de divulgarla públicamente.
- Cómo reportar
- Envíe un correo a security@ethoz.cl con descripción del hallazgo, pasos para reproducirlo y el impacto estimado.
- Nuestro compromiso
- Respuesta en máximo 48 horas
- Comunicación del estado de la corrección
- Reconocimiento público si el investigador lo desea
- Bug bounty en evaluación