Seguridad

1. Identidad, sesiones y roles

• Las personas acceden con cuentas individuales administradas mediante Supabase Auth.
• Los roles de cliente, colaborador y administrador limitan qué proyectos y operaciones puede ver cada persona.
• El aislamiento se refuerza en la base de datos mediante Row Level Security y asignaciones explícitas de dominio.
• Una notificación solo es visible por su destinatario. Los hallazgos altos o críticos se distribuyen a los tres perfiles únicamente dentro del proyecto al que cada persona tiene acceso.
• Las sesiones se mantienen mediante cookies técnicas; su renovación y cierre se gestionan desde la capa de autenticación.
• Las acciones administrativas sensibles no se delegan automáticamente a una IA.

2. Credenciales, Vault y revelación

Las credenciales operativas se custodian mediante la relación entre recursos del proyecto, referencias de secretos y Supabase Vault. CredentialService es el punto autorizado de acceso de la aplicación y no expone el identificador interno del secreto.

• El cliente puede crear, reemplazar o eliminar secretos, pero no revelar su valor guardado.
• El administrador y el colaborador asignado pueden revelar una credencial individual cuando su rol lo permite.
• La revelación es temporal, se entrega con cabeceras no-store, se oculta automáticamente y queda auditada.
• No existe una función de “mostrar todas” ni una exportación masiva de credenciales.
• El registro de auditoría de credenciales es append-only: se añaden eventos y no se modifica el historial desde la operativa normal.

3. Integraciones y tokens

Analytics y Search Console solicitan permisos de lectura. Google Business Profile puede requerir el alcance que Google define para administrar la conexión, aunque Órbita limita su uso a las funciones habilitadas. Los alcances se muestran durante la autorización del proveedor.

Los tokens OAuth persistidos se cifran con AES-256-GCM y una clave de entorno separada del código. El flujo OAuth utiliza estado aleatorio, cookie temporal segura, validación de usuario y dominio y eliminación del estado al finalizar. Las conexiones pueden revocarse desde el proveedor y desconectarse de Órbita.

4. Aislamiento y protección de datos

• Los datos pertenecen a un dominio o proyecto y las consultas sensibles comprueban el contexto de acceso.
• Las claves administrativas permanecen en servidor y no deben incorporarse al navegador ni al repositorio.
• Las respuestas con secretos o tokens no se cachean.
• Las migraciones son incrementales, idempotentes cuando corresponde y no reescriben el historial aplicado.
• Los informes distinguen visibilidad interna, de cliente y pública.

5. Soporte y datos introducidos por usuarios

Los tickets y sus respuestas se guardan vinculados al dominio para conservar el historial de soporte. Las políticas de acceso limitan su consulta al solicitante y a los perfiles de soporte autorizados; los avisos automáticos por correo no sustituyen ese registro. Cada intento de entrega usa SMTP desde el servidor y se audita mediante una clave de evento única, sin guardar otra copia del mensaje o de la dirección destinataria.

No deben incluirse contraseñas, tokens, claves privadas, códigos de recuperación ni categorías especiales de datos en tickets, comentarios o campos de texto. Si una incidencia requiere una credencial, se utiliza el recurso protegido correspondiente.

6. IA y código de terceros

Órbita no ofrece acceso libre de IA a repositorios, servidores o secretos. Cualquier futura capacidad de análisis de código deberá habilitarse expresamente para un proyecto y una fuente concretos, con permisos mínimos y preferentemente de solo lectura.

• El cliente debe confirmar que puede autorizar el análisis de activos propios o de terceros.
• Se excluirán credenciales, archivos de entorno y contenido ajeno a la finalidad.
• Se documentará el proveedor, la retención, las transferencias y el uso de datos aplicable antes de activarlo.
• La IA analiza y propone; no revela Vault, publica, borra, cambia responsables ni cierra acciones por defecto.
• Las intervenciones deben conservar origen, fecha, actor y resultado revisable.
• Las interacciones o contenidos generados se identificarán cuando resulte exigible conforme al Reglamento (UE) 2024/1689.

7. Auditoría, continuidad e incidentes

Órbita registra operaciones relevantes como conexiones, cambios de estado, accesos a credenciales y acciones del proyecto. Las novedades urgentes mantienen el vínculo con la acción y su origen, y se deduplican por destinatario, acción y nivel para evitar repeticiones de una misma alerta. Estos registros permiten investigar incidencias y atribuir cambios.

Las copias, restauración y continuidad dependen también de los proveedores de infraestructura y de la configuración operativa del servicio. Ante un incidente se priorizan contención, evaluación de alcance, recuperación, documentación y, cuando resulte exigible, notificación a clientes, interesados o autoridades dentro de los plazos aplicables.

8. Cambios y controles de publicación

Las modificaciones de datos se publican mediante migraciones trazables y compatibles con el histórico. Antes de desplegar se revisan permisos por rol, aislamiento entre proyectos, ausencia de duplicados, estados de carga, vacío y error, comportamiento responsive y compilación de producción. Después de una migración se revisan los avisos de seguridad y rendimiento disponibles.

Estos controles reducen el riesgo, pero no sustituyen la vigilancia continua ni permiten prometer una disponibilidad o seguridad absolutas. Los controles se ajustan cuando cambian la arquitectura, los proveedores o el nivel de riesgo. Esta página describe prácticas operativas y no equivale a una certificación ISO, ENS u otra acreditación que no se haya indicado expresamente.

9. Responsabilidad compartida

• Usa contraseñas únicas y protege el correo asociado.
• No compartas sesiones, enlaces de recuperación ni credenciales fuera de los canales acordados.
• Concede solo los permisos necesarios y revoca accesos al terminar una colaboración.
• Verifica que puedes conectar cuentas, código, documentos y datos de terceros.
• Revisa el centro de novedades del proyecto: una alerta interna no sustituye una comunicación externa ni ejecuta por sí misma la acción.
• Comunica de inmediato accesos sospechosos, pérdidas de dispositivo o resultados inesperados a contacto@grupodeboss.com.

10. Divulgación responsable

Si detectas una vulnerabilidad, informa de forma confidencial, incluyendo la URL, una descripción reproducible y el impacto, sin acceder a datos ajenos ni interrumpir el servicio. No publiques detalles antes de que podamos evaluar y corregir el problema.