Anexo Técnico de Seguridad de MyFincaLink

1. Arquitectura y separación de la información

MyFincaLink utiliza una arquitectura multigestoría y multicomunidad. La información operativa de cada comunidad se mantiene en su ámbito de datos y las relaciones centrales identifican la gestoría y comunidad autorizadas. La aplicación valida ese contexto antes de resolver conexiones o ejecutar operaciones.

2. Control de acceso a bases de datos

Las conexiones se resuelven en el servidor y no se exponen al navegador. Los procesos usan credenciales asociadas a su función y las consultas sensibles se realizan mediante sentencias preparadas. El acceso funcional se limita mediante roles y permisos de módulo.

3. Protección de credenciales y datos sensibles

Las contraseñas se almacenan mediante funciones de hash adecuadas, nunca en texto plano. Los campos sensibles implementados por la aplicación emplean cifrado autenticado; cuando es necesario buscar sin revelar el valor original se utilizan índices criptográficos no reversibles. Las claves se mantienen separadas de los datos cifrados.

Los documentos gestionados por el sistema de almacenamiento se cifran antes de guardarse y se verifican mediante SHA-256 durante las migraciones.

4. Comunicaciones seguras HTTPS/TLS

El despliegue público debe servirse mediante HTTPS/TLS y certificados válidos. La aplicación genera URLs dentro del contexto seguro y aplica cabeceras defensivas en sus puntos públicos. La configuración y renovación de certificados corresponde a la infraestructura de despliegue.

5. Seguridad del servidor

Los archivos de configuración, conexiones y scripts operativos se protegen frente al acceso web. Los procesos de mantenimiento se ejecutan fuera del flujo público y la aplicación registra errores y actividad relevante sin mostrar detalles internos al usuario final.

6. Copias de seguridad de la aplicación

La recuperación debe incluir el código versionado, las dependencias declaradas y la configuración externa necesaria. Los secretos, logs, documentos privados y copias no forman parte de paquetes públicos de código.

7. Copias de seguridad de las bases de datos

La operación del servicio contempla copias de la base central y de las bases operativas. La periodicidad, retención y cifrado de esas copias deben definirse y supervisarse en cada despliegue según su nivel de riesgo.

8. Almacenamiento externo de las copias

Las copias operativas deben conservarse fuera de la infraestructura principal. Las migraciones de almacenamiento exigen una ruta de backup fuera del directorio web y conservan originales y copia hasta su revisión.

9. Verificación y pruebas de restauración

Las migraciones documentales generan un manifiesto, comparan integridad mediante SHA-256 y actualizan referencias únicamente cuando el lote se ha verificado. Las restauraciones de bases de datos y aplicación deben probarse periódicamente en un entorno controlado.

10. Automatización y supervisión de las copias

Los trabajos de migración y mantenimiento pueden ejecutarse mediante procesos programados y mantienen estados, progreso, elementos verificados, fallos y último error. La automatización no sustituye la revisión de resultados ni las pruebas de recuperación.

11. Actualizaciones de seguridad

El código, las dependencias y el sistema anfitrión deben revisarse periódicamente. Las correcciones se prueban antes de desplegarse y las migraciones de esquema se aplican mediante scripts versionados.

12. Seguridad desde el diseño

Los controles de autorización, separación por cliente, cifrado, validación de entradas, escape de salidas y trazabilidad forman parte del diseño de las funcionalidades que tratan información privada.

13. Revisión y mejora continua

Los controles se revisan conforme evoluciona la plataforma. Cualquier medida dependiente del servidor, proveedor de almacenamiento o política operativa debe comprobarse en el despliegue concreto y documentarse como parte de su mantenimiento.