Política de Respaldo y Recuperación
Política operativa interna. Define los requisitos de respaldo (backup) y recuperación de los sistemas y datos de Lawra, S.R.L. Garantiza la resiliencia ante pérdida de datos, corrupción, y eventos de desastre. Aprobada por la Asamblea en [__]. Versión: 1.0.
1. Propósito y Alcance
1.1. Esta política establece qué datos e infraestructura deben respaldarse, con qué cadencia, por cuánto tiempo se retienen los backups, cómo se protegen, y cómo se verifica que los backups son recuperables.
1.2. Soporta los controles SOC 2 CC9.2 (Identificación y mitigación de riesgos de pérdida de datos de procesamiento) y A1.2 (Capacidad y disponibilidad de datos para cumplir compromisos de procesamiento).
1.3. — Aplica a:
- Base de datos de producción (Firestore).
- Repositorios de código fuente (GitHub).
- Datos corporativos (Google Workspace: Gmail, Drive, Calendar).
- Datos de clientes procesados como Encargado, conforme a los DPAs correspondientes.
- Configuraciones críticas de infraestructura (Firebase, reglas de Firestore, variables de entorno documentadas).
1.4. — No aplica a: Datos de entornos de desarrollo o staging, salvo que contengan datos de producción.
2. Activos en Alcance y Clasificación
| Activo | Descripción | Criticidad | Responsable |
|---|---|---|---|
| Firestore (producción) | Conversaciones, simulaciones de juicio, suscripciones de newsletter, envíos de formularios, historial de conversaciones de usuarios registrados | Crítica | CTO |
| Repositorios GitHub | Código fuente, workflows de CI/CD, configuraciones de infraestructura, reglas de Firestore | Alta | CTO |
| Google Workspace (Drive) | Documentación corporativa, contratos, documentos legales, políticas internas | Alta | Gerente |
| Google Workspace (Gmail) | Comunicaciones corporativas | Media | Gerente |
| Firebase Authentication | No contiene datos propietarios de Lawra (es gestionado por Google); el catálogo de usuarios sí puede exportarse como medida adicional | Media | CTO |
| Variables de entorno y configuraciones | Documentación de configuraciones de producción (sin secrets, que se gestionan en GitHub Secrets / KMS) | Alta | CTO |
3. Cadencia de Respaldo
3.1. — Firestore:
| Tipo de backup | Frecuencia | Retención | Método |
|---|---|---|---|
| Backup diario completo | Diario (automatizado, 2:00 AM UTC) | 30 días | Firebase Scheduled Export a Google Cloud Storage |
| Backup semanal completo | Cada domingo | 60 días | Firebase Scheduled Export a GCS (bucket separado) |
| Backup mensual completo | Primer domingo del mes | 365 días | Firebase Scheduled Export a GCS (bucket de archivo) |
3.2. — GitHub (repositorios):
| Tipo de backup | Frecuencia | Retención | Método |
|---|---|---|---|
| Mirror automático | Continuo (cada push) | Mientras el repositorio exista | GitHub mirror a un segundo servicio de Git (GitLab o Bitbucket, repositorio privado) — si está configurado; si no, backup semanal manual |
| Backup semanal de repositorios | Semanal | 90 días | Script automatizado que clona todos los repositorios de la organización y los archiva en GCS o Drive |
3.3. — Google Workspace:
| Tipo de backup | Frecuencia | Retención | Método |
|---|---|---|---|
| Google Vault | Continuo (si activo) | Según política de retención de Vault | Google Vault (E-Discovery + retención) |
| Backup de Drive | Semanal | 60 días | Google Takeout automatizado o herramienta de backup de Workspace |
| Backup manual de documentos críticos | Trimestral | 3 años | Exportación manual de contratos, políticas, libros de actas a PDF y almacenamiento en GCS cifrado |
3.4. — Datos de clientes (conforme DPAs): Los datos de clientes almacenados en Firestore como Encargado (datos procesados en nombre del Responsable cliente) se respaldan conforme a la cadencia de Firestore indicada en la sección 3.1. La retención de datos de cliente en backups se alinea con los plazos acordados en el DPA correspondiente; en ausencia de plazo específico, aplica la retención por defecto de esta política.
4. Retención de Backups
4.1. Los plazos de retención son:
| Tier de retención | Plazo | Aplica a |
|---|---|---|
| Operacional (30 días) | 30 días | Backups diarios de Firestore; logs de acceso generales |
| Extendido (60 días) | 60 días | Backups semanales de Firestore; Drive corporativo |
| Trimestral (90 días) | 90 días | Backups de repositorios GitHub; logs de seguridad |
| Anual (365 días) | 365 días | Backups mensuales de Firestore; documentos legales y contratos |
| Largo plazo (3 años) | 3 años | Documentos societarios, contratos firmados, evidencia de auditoría SOC 2 |
4.2. Al vencimiento de los plazos de retención, los datos se eliminan de forma segura. Para datos de clientes, la eliminación al vencimiento del DPA se ejecuta conforme al procedimiento de terminación establecido en el DPA correspondiente.
4.3. Los plazos de retención pueden extenderse por:
- Requerimiento de una investigación legal o regulatoria activa.
- Solicitud documentada de un cliente dentro del plazo de su DPA.
- Orden judicial o administrativa.
5. Protección de Backups
5.1. — Cifrado en tránsito: Toda transferencia de backups hacia y desde el almacenamiento utiliza TLS 1.3. Los backups de Firestore a Google Cloud Storage están cifrados en tránsito por defecto.
5.2. — Cifrado en reposo: Los backups almacenados en Google Cloud Storage se cifran en reposo con AES-256 mediante las claves gestionadas por Google (CMEK opcional para mayor control). Los backups de documentos en Drive heredan el cifrado en reposo de Google Workspace.
5.3. — Control de acceso a backups:
- Los buckets de GCS que contienen backups tienen acceso restringido a la cuenta de servicio del proceso de backup y al CTO.
- Los backups no son accesibles públicamente. Las reglas de bucket prohíben acceso público (
allUsers/allAuthenticatedUsers). - El acceso a buckets de backup queda registrado en Cloud Audit Logs.
5.4. — Redundancia geográfica: Los buckets de GCS se configuran con Multi-Region (us o eur) para garantizar que los backups sobreviven la pérdida de una región de Google Cloud.
5.5. — Inmutabilidad: Se recomienda configurar Object Versioning en los buckets de backup y, para los backups de largo plazo, Retention Locks de GCS para prevenir borrado accidental o malicioso.
6. Procedimiento de Restauración
6.1. — Tipos de restauración:
| Escenario | Procedimiento | Autorización requerida |
|---|---|---|
| Restauración completa de Firestore (pérdida total) | Importar el export más reciente desde GCS usando gcloud firestore import | CTO + Gerente |
| Restauración parcial de colección (corrupción de datos) | Importar export a un proyecto de staging; extraer colección específica; importar a producción | CTO |
| Restauración de repositorio GitHub | Clonar desde el mirror o el backup archivado; verificar integridad con git fsck | CTO |
| Restauración de documento de Drive | Recuperar desde historial de versiones de Drive o desde el backup de Takeout | Gerente |
6.2. — Documentación post-restauración: Toda restauración de datos de producción se documenta con: fecha y hora, razón, sistemas afectados, backup utilizado (fecha del backup), resultado de la verificación, y persona que ejecutó la restauración.
7. Verificación y Prueba de Restauración
7.1. — Prueba de restauración trimestral: El CTO (o persona designada) verifica trimestralmente que los backups son recuperables ejecutando una restauración de prueba en un ambiente aislado. La prueba incluye:
- Restaurar el export más reciente de Firestore en un proyecto de Firebase de prueba.
- Verificar que los datos son íntegros y consultables.
- Verificar que el backup de repositorio GitHub es cloneable y compilable (
npm run buildexitoso). - Documentar el resultado de la prueba.
7.2. Si una prueba de restauración falla, el CTO escala inmediatamente al Gerente y revisa el proceso de backup para identificar y corregir el fallo. No se declara un backup “válido” hasta que la prueba de restauración es exitosa.
7.3. Los resultados de las pruebas de restauración se archivan como evidencia de cumplimiento SOC 2 (control A1.2 / CC9.2).
7.4. — Flujo de Verificación de Backups: El workflow backup-verification en GitHub Actions ejecuta semanalmente una verificación ligera de que los backups de Firestore se completaron exitosamente (verificación de existencia y tamaño del archivo en GCS) y envía una alerta al CTO si no encuentra el backup esperado.
8. Roles y Responsabilidades
8.1.
| Responsabilidad | Responsable primario | Suplente |
|---|---|---|
| Configuración y mantenimiento de procesos de backup | CTO (Luishy Medina) | Gerente |
| Monitoreo de alertas de backup fallido | CTO | Gerente |
| Ejecución de pruebas de restauración | CTO | Segundo ingeniero designado |
| Autorización de restauraciones de producción | Gerente + CTO | Asamblea (para restauraciones mayores) |
| Revisión anual de esta política | CTO | Oficial de Cumplimiento |
9. Referencias Normativas y Técnicas
- SOC 2 Trust Services Criteria: CC9.2 (Identificación y mitigación de riesgo de pérdida de datos), A1.2 (Capacidad y disponibilidad)
- NIST SP 800-34 Rev. 1 — Contingency Planning Guide
- ISO/IEC 27001:2022 — Anexo A, Control 8.13 (Information Backup)
- Ley No. 172-13 (R.D.) — Protección de Datos Personales (obligaciones de integridad y disponibilidad de datos personales)
- GDPR Art. 32 — Seguridad del tratamiento (disponibilidad y acceso a datos personales en tiempo oportuno)
business-continuity-dr-policy— Política de Continuidad de Negocio y Recuperación ante Desastresencryption-policy— Política de Cifrado de Lawra
10. Revisión y Modificación
Esta política se revisa anualmente o ante cambios materiales en la infraestructura de datos o los compromisos con clientes. Modificaciones requieren aprobación del CTO; modificaciones materiales requieren aprobación de la Asamblea.
Próxima revisión: [fecha de adopción + 12 meses].
Adoptada por la Asamblea General de Socios de LAWRA, S.R.L. en fecha [__], conforme consta en el Libro de Actas.
Por LAWRA, S.R.L. — Gerente
Comments
Loading comments...