Saltar al contenido principal

Documento técnico · 03 Arquitectura de seguridad 10 min de lectura

La seguridad no es una capa sobre el producto: es el producto.

Por diseño, no por parche. Cada decisión de arquitectura en Ethoz (cifrado, aislamiento por colegio, Row-Level Security, audit log inmutable) tiene un fundamento en la protección de los datos de su comunidad escolar. Este documento describe esas decisiones con el detalle suficiente para una revisión técnica institucional.

Cifrado en tránsito
TLS 1.3
Cifrado de datos almacenados
AES-256
Aislamiento
RLS Postgres
Región datos
Santiago, Chile

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

Sesión técnica

¿Quiere revisar el modelo de seguridad en detalle?

Sesión con el equipo técnico. Respondemos preguntas específicas de su DPO o responsable de TI y evaluamos compatibilidad con los requisitos de su colegio.