Seguridad y confianza

1. Resumen de una página

Nuestro honesto estado actual, a partir del 8 de julio de 2026: el hocico de caballo es un producto en etapa inicial administrado por un operador en solitario. Hoy NO contamos con SOC 2 o ISO 27001 y aún no hemos tenido una prueba de penetración externa. Esta página describe lo que hacemos, lo que tenemos y lo que aún no tenemos. Preferiríamos decirle claramente cuál es nuestra posición que exagerar.

• Quiénes somos. horsenose es un software para administrar una escuela de equitación: programar lecciones, realizar un seguimiento de la asistencia y cómo pagaron los jinetes, administrar pases y vales de regalo, calcular las ganancias de los instructores y brindar a los clientes del centro ecuestre una vista de sus propias reservas. Está operado por DF Daniel Fojcik, una empresa unipersonal polaca (NIP 6472592229 / REGON 387798601, Marklowice), que comercializa como Nose / horsenose.
• Nuestras dos funciones. Somos el responsable del tratamiento de datos de nuestra propia cuenta, análisis y datos de seguridad, y un encargado del tratamiento de datos que actúa según las instrucciones de cada centro ecuestre para los datos del usuario/cliente que ingresa al centro ecuestre. La relación del encargado del tratamiento se rige por nuestro Acuerdo de procesamiento de datos (DPA). Consulte el “Marco de cumplimiento” a continuación.
• Lo que tenemos. Correo electrónico de la cuenta y nombre/teléfono del perfil opcional; direcciones de correo electrónico de invitación; los registros operativos que ingresa un centro ecuestre sobre sus jinetes (nombres, contactos, participación en lecciones, pases/vales, etiquetas de seguimiento de pagos, notas de texto libre); PIN de programación con hash bcrypt; Tokens de invitación con hash SHA-256. No tenemos datos bancarios o de tarjetas de pago ni datos de salud. Inventario completo en "Datos que tenemos" a continuación.
• Qué lo protege. TLS en todas partes con precarga HSTS; cifrado en reposo (AES-256); seguridad a nivel de fila aplicada por la base de datos que aísla cada centro ecuestre; validación de sesión del lado del servidor; intensificar la reautenticación para acciones destructivas y administrativas; una estricta Política de seguridad de contenidos; limitación de velocidad y protección contra bots; y un registro de auditoría de solo anexar. Lista completa en “Medidas técnicas” a continuación.
• Dónde se ejecuta. En más de una región, y agregamos regiones a medida que crecemos; la región principal actual para cada proveedor aparece en "Infraestructura: quién ejecuta qué y dónde" a continuación y puede cambiar a medida que nos expandimos. Hoy en día, la mayor parte del procesamiento central se realiza en el EEE (base de datos, correo electrónico, análisis, monitoreo de errores y almacén de límite de tarifas), con algunos componentes ya fuera de él (la ventaja global de Cloudflare; el inicio de sesión de Google y partes de Stripe en los EE. UU.; Dodo Payments a nivel mundial). Cada ruta entre regiones está cubierta por un mecanismo de transferencia adecuado: la UE-EE.UU. Marco de Privacidad de Datos, las Cláusulas Contractuales Estándar de la UE, el Anexo del Reino Unido o el equivalente que requiera una región agregada.
• Lo que aún no tenemos. No hay SOC 2, ISO 27001, prueba de penetración externa ni programa de recompensas por errores. Si su proceso de adquisición requiere SOC 2 hoy, todavía no somos la opción adecuada.
• Cómo comunicarse con nosotros sobre seguridad. Envíe un correo electrónico a support@horsenose.eu con "Seguridad" en la línea de asunto. Consulte "Respuesta a incidentes (notificación de incumplimiento de 72 horas)" y "Divulgación responsable" a continuación.

2. Datos que tenemos

Recopilamos el mínimo necesario para ejecutar el Servicio. Las categorías siguientes son los datos personales que tocan a caballo.

Lo que no conservamos

• Sin tarjeta de pago ni datos bancarios. horsenose nunca participa en un pago y nunca maneja datos de tarjetas. Los métodos fuera de línea ("efectivo", "pase", "vale", "transferencia") son etiquetas de seguimiento y registros estables, no transacciones ejecutadas. Para la facturación de suscripción del centro ecuestre (Stripe para los centros ecuestres polacos, Dodo Payments como comerciante de registro para los centros ecuestres no polacos) y para los pagos de jinetes en línea cuando un centro ecuestre los permite (Stripe, que se establece en la propia cuenta del centro ecuestre), los datos de la tarjeta se manejan completamente en el proceso de pago del propio proveedor de pagos y nunca nos llegan, por lo que permanecemos fuera del alcance de PCI DSS (consulte “Marco de cumplimiento” a continuación).
• Sin documentos de identidad ni direcciones. No recopilamos direcciones particulares, números de documentos de identificación ni identificadores gubernamentales.
• Sin datos de categoría especial (salud). No pretendemos recopilar datos del artículo 9 del RGPD y el producto no está diseñado para almacenarlos. A los centros ecuestres se les indica (en el DPA) no que ingresen datos de categorías especiales en campos de texto libre. Las notas sobre un caballo son sobre un animal, no sobre una persona, y quedan fuera del RGPD.
• Sin perfiles publicitarios, identificadores de retargeting ni seguimiento entre sitios. Sin píxeles Meta/LinkedIn/X/TikTok; sin huellas dactilares del navegador.
• No se venden, alquilan ni prestan datos a terceros.
• No entrenamos modelos de IA/ML con sus datos. No entrenamos, ajustamos ni evaluamos ningún modelo de IA o aprendizaje automático con datos personales extraídos de horsenose. La extensión `pgvector` está habilitada en nuestro Postgres para futuros casos de uso de búsqueda interna, pero hoy en día no incluye incrustaciones derivadas de datos personales.

3. Infraestructura: quién gestiona qué y dónde

horsenose es una aplicación Next.js alojada en Vercel, respaldada por una base de datos Supabase Postgres, con un pequeño conjunto de proveedores especializados ("subencargados del tratamiento"), cada uno de los cuales maneja una porción estrecha. Ninguno tiene acceso de extremo a extremo a todo. Operamos en más de una región y agregamos regiones a medida que crecemos, por lo que describimos dónde están las cosas hoy en lugar de prometer una única ubicación permanente: la mayor parte del procesamiento central (la base de datos, el correo electrónico, el análisis de productos y el monitoreo de errores) está en el EEE, mientras que algunos componentes ya se ejecutan fuera de él (la ventaja global de Cloudflare; el inicio de sesión opcional de Google y partes de Stripe en los EE. UU.; Dodo Payments como comerciante de registro global). La región principal actual de cada proveedor se encuentra en la siguiente tabla y se mantiene actualizada a medida que cambia; cada ruta entre regiones está cubierta por un mecanismo de transferencia apropiado (el Marco de Privacidad de Datos UE-EE. UU., las Cláusulas Contractuales Estándar, el Anexo del Reino Unido o el equivalente que requiera una región agregada).

La versión canónica y siempre actualizada de esta tabla, con categorías de datos personales y mecanismos de transferencia por proveedor, se mantiene en la página Subencargados del tratamiento; la Política de Privacidad y el enlace DPA a la misma fuente en lugar de mantener copias divergentes.

4. Medidas técnicas

Estos son los controles realmente vigentes hoy. Esta es también la sustancia detrás de la DPA → “Confidencialidad, seguridad y subencargados del tratamiento”, que señala aquí nuestras medidas técnicas y organizativas.

Red y transporte

• TLS para todo el tráfico, aplicado por Vercel y Supabase. HSTS se establece con `max-age=63072000; incluirSubDominios; precarga`.
• Sin contenido mixto: la Política de seguridad de contenido rechaza los recursos `http://`.

Aislamiento y autorización de centros

• Seguridad a nivel de fila (RLS) con alcance para cada centro ecuestre en cada tabla operativa, aplicada en la propia base de datos: los datos de un centro ecuestre no pueden ser leídos por otro incluso si el código de la aplicación tuviera un error. Esta es la principal defensa contra centros.
• Puertas de rol de la capa de aplicación (autenticadas/de ámbito del centro ecuestre/instructor o administrador/superadministrador) como defensa en profundidad además de RLS, nunca como la única línea.
• Las comprobaciones de la capa de ruta requieren una sesión activa para las rutas protegidas y el estado de superadministrador para la superficie de administración.

Autenticación

• Inicio de sesión sin contraseña: enlace mágico de correo electrónico (gestionado por Supabase Auth) o inicio de sesión opcional de Google (OAuth). No se almacenan contraseñas.
• Validación de sesión del lado del servidor en cada solicitud protegida: nunca se confía en la cookie de inicio de sesión por sí sola.
• Reautenticación intensificada para acciones destructivas y administrativas: se requiere una cookie intensificadora de corta duración y firmada por separado para operaciones como la eliminación de cuentas, cambios de función del último administrador, desactivación masiva, archivado del centro ecuestre y todas las escrituras de superadministrador; El paso a paso faltante o caducado falla cerrado.
• La superficie de administrador de plataforma devuelve 404 cuando no se configura ningún superadministrador, por lo que no se filtra su existencia.

Secretos y manejo de credenciales

• Los PIN programados se almacenan como hashes bcrypt; Los tokens de invitación se almacenan como hashes SHA-256: de un solo uso, de tiempo limitado (vencimiento de 7 días) y vinculados por correo electrónico; los tokens sin procesar nunca persisten.
• La clave de función de servicio de base de datos es solo para servidor: nunca se incluye en el JavaScript del cliente; un validador en tiempo de compilación falla la compilación si una variable sensible tiene un prefijo incorrecto.

Manejo de entradas y salidas

• Validación de esquema en cada límite de entrada del servidor: la validación del lado del cliente se trata solo como UX; el servidor es el límite de confianza.
• Una política de seguridad de contenido estricta con un nonce por solicitud, además de un conjunto de encabezados de seguridad bloqueados (`X-Content-Type-Options`, `X-Frame-Options`/`frame-ancestors`, `Referrer-Policy`, encabezados de aislamiento de origen cruzado y una restrictiva `Política de permisos`).
• Salida automática de escape; El contenido escrito por el usuario es texto sin formato en esta etapa.

Protección contra abusos y bots

• Limitación de velocidad en el inicio de sesión, el registro, el enlace mágico, la aceptación de invitación, la exportación/borrado y otros puntos finales sensibles (por correo electrónico, por IP, por usuario o por estable, según la acción; cada política se abre o se cierra por error por diseño).
• Cloudflare Turnstile protección contra bots en el formulario de inicio de sesión, el formulario de registro, la solicitud de enlace mágico, la página de aceptación de invitación y la entrada de PIN de programación pública.

Datos en reposo y pista de auditoría

• Cifrado en reposo mediante Supabase (AES-256).
• Un registro de auditoría de solo agregar registra eventos relevantes para la seguridad (autenticación, cambios de rol y membresía, eventos financieros, exportaciones, eliminaciones). Siempre está escrito y es distinto de la telemetría operativa.
• Monitoreo de errores con depuración de datos personales: antes de enviar cualquier error a Sentry, un depurador personalizado elimina direcciones de correo electrónico, números de teléfono, cuerpos de mensajes, notas y cualquier campo que parezca un token. Lo que queda es el contexto técnico más un UUID de usuario seudónimo, el identificador del centro ecuestre, la configuración regional y el nombre de la operación fallida.

Copias de seguridad y recuperación

• Supabase proporciona copias de seguridad diarias automatizadas (retención de 7 días en el nivel actual; se planea una retención más prolongada a medida que el Servicio madure). Vercel conserva las implementaciones anteriores para una reversión casi instantánea de una versión incorrecta.

5. Medidas organizativas

• Operador en solitario. horsenose está dirigido por una sola persona (Daniel Fojcik). No hay empleados con acceso a producción en este momento. Si eso cambia (por ejemplo, se incorpora un contratista con acceso a producción), esta página se actualizará y se notificarán los centros ecuestres activos.
• Los datos de producción permanecen en la infraestructura administrada. Los volcados de bases de datos de producción no se almacenan en las máquinas locales; el desarrollo local utiliza una base de datos separada con datos sintéticos.
• Mínimo privilegio para cuentas de servicio. La clave de la función de servicio de la base de datos está destinada únicamente al uso del lado del servidor; El acceso a la base de datos del navegador utiliza una clave limitada detrás de la seguridad a nivel de fila.
• Gestión de secretos. Los secretos residen en la configuración del entorno del proveedor de hosting y en un archivo local ignorado por git, que nunca se envía al repositorio. Los secretos de producción no se copian a las máquinas locales.
• Registro de acceso del lado del proveedor. Las acciones administrativas de nuestros proveedores son registradas por esos proveedores; los revisamos ad hoc.
• Confidencialidad. El personal (actualmente el propietario) está obligado a guardar confidencialidad respecto de los datos personales procesados ​​a través del Servicio, tal y como se refleja en la DPA.
• Cambiar disciplina. Los cambios de código pasan por un estricto tipo, pelusa y puerta de prueba automatizada antes de la implementación, y las migraciones de bases de datos se aplican a un entorno de prueba antes de la producción.

6. Respuesta a incidentes (notificación de infracción cada 72 horas)

Monitoreo. Los errores fluyen a Sentry (con la depuración de datos personales descrita en “Medidas técnicas” más arriba); los diagnósticos a nivel de solicitud están disponibles en los registros de alojamiento; un monitor de tiempo de actividad y alertas de tasa de error son parte de la base de fortalecimiento. El registro de auditoría de solo anexar proporciona un registro duradero de eventos relevantes para la seguridad para su investigación.

Nuestro compromiso de notificación de violaciones. Si se produce una violación de datos personales que pueda resultar en un riesgo para los derechos y libertades de las personas afectadas, haremos lo siguiente:

• Notificar a la autoridad supervisora ​​competente (el presidente de la UODO en Polonia) sin demoras indebidas y, cuando sea posible, dentro de las 72 horas de tener conocimiento de la infracción (Artículo 33 del RGPD).
• *Cuando sea probable que la violación resulte en un riesgo alto* para las personas afectadas, notifiquelos sin demora indebida, describiendo la naturaleza de la violación, las categorías de datos involucrados, las posibles consecuencias y las medidas tomadas (Artículo 34 GDPR**).
• Cuando actuemos como encargado del tratamiento de un centro ecuestre, notificar a ese centro ecuestre (el responsable del tratamiento) sin demora indebida para que pueda cumplir con sus propias obligaciones del Artículo 33/34 para con sus jinetes.

Esto refleja la Política de Privacidad y la DPA. Indica cómo pretendemos implementar una obligación que el RGPD ya impone; no es una promesa contractual adicional más allá del RGPD. En la hoja de ruta se encuentra un manual de respuesta a incidentes documentado formalmente; hasta entonces, un equipo de una sola persona responde ad hoc dentro de los plazos mencionados anteriormente.

Contacto. No urgente: support@horsenose.eu. Seguridad (urgente): envíe un correo electrónico a support@horsenose.eu con "Seguridad" en la línea de asunto.

7. Marco de cumplimiento

GDPR (Reglamento 2016/679). horsenose opera bajo una doble función: responsable del tratamiento de los datos cuyos propósitos y medios determina (visitantes del sitio de marketing, datos de cuenta/contacto de administradores e instructores de centros ecuestres, análisis de productos controlados por consentimiento y datos de seguridad/prevención de abuso), y encargado del tratamiento de los datos operativos del jinete/cliente que ingresa un estable; allí, el centro ecuestre es el responsable del tratamiento y horsenose procesa según las instrucciones documentadas del centro ecuestre según la DPA (artículo 28 del RGPD). Los subencargados del tratamiento operan según los contratos del Artículo 28 (DPA + SCC/DPF, el Anexo del Reino Unido o un mecanismo equivalente cuando una transferencia cruza regiones); consulte la página de Subencargados del tratamiento.

Datos de niños. Las escuelas de equitación enseñan regularmente a niños, por lo que horsenose procesa a sabiendas los datos de menores en nombre de un centro ecuestre (por ejemplo, un niño ingresado como participante de una lección, a menudo por un padre que es cliente del centro ecuestre). El centro ecuestre es responsable de la base legal y de cualquier consentimiento o autoridad de los padres requerido (Artículo 8 GDPR); horsenose minimiza lo que se dice sobre un niño y no se dirige ni comercializa directamente a los niños. Consulte la Política de Privacidad → “Privacidad de los niños”.

Se admiten los derechos de los interesados, incluido el acceso/portabilidad de autoservicio a través de una exportación JSON en /account/export y el borrado a través de /account/delete (se aplica un período de gracia reversible de 30 días y una reautenticación progresiva; al borrar, eliminamos los identificadores directos en lugar de eliminarlos por completo: seudonimización según el artículo 4(5) del RGPD, no anonimización completa según el considerando 26; consulte la tabla de retención en la Política de privacidad → “Durante cuánto tiempo conservamos los datos” para obtener detalles a nivel de campo). Para los datos del jinete, el responsable del tratamiento es el centro ecuestre, por lo que un jinete ejerce derechos contra su centro ecuestre y el caballo ayuda como encargado del tratamiento.

PCI DSS: no aplicable a horsenose. No manejamos, almacenamos ni transmitimos datos de tarjetas. Para la facturación de suscripción del centro ecuestre, la ruta de los datos de la tarjeta la lleva en su totalidad el proveedor de pagos en su caja alojada: Stripe (encargado del tratamiento de pagos) para los centros ecuestres polacos, con horsenose como comerciante, y Dodo Payments como Comerciante de registro para los centros ecuestres no polacos. Para pagos de jinetes en línea, cuando un centro ecuestre los permite, la tarjeta, la billetera o los datos BLIK son transportados en su totalidad por Stripe (a través de Stripe Connect) y se depositan en la propia cuenta de Stripe del centro ecuestre: el centro ecuestre es el comerciante y Stripe es el encargado del tratamiento compatible con PCI, mientras que horsenose solo transmite instrucciones y nunca recibe datos de la tarjeta. En todos los casos, horsenose nunca recibe datos de la tarjeta y permanece fuera del alcance de PCI.

Ley de IA de la UE: no aplicable. horsenose es una herramienta operativa para escuelas de equitación; no entrena, desarrolla ni implementa modelos de IA, y ningún componente utiliza aprendizaje automático o IA generativa para procesar datos personales. La extensión de Postgres `pgvector` está habilitada para posibles casos de uso de búsqueda interna en el futuro, pero actualmente no incluye incrustaciones derivadas de datos personales; Si eso cambia, publicaremos una posición de la Ley de IA de la UE y un compromiso de "no capacitación sobre datos personales" antes de que se lance la función.

ePrivacy/cookies. Carga de análisis opcional (PostHog) solo con consentimiento; Las cookies estrictamente necesarias están exentas según el artículo 5, apartado 3, de la Directiva ePrivacy. Consulte la Política de cookies.

8. Divulgación responsable

Si cree que ha encontrado una vulnerabilidad de seguridad en horsenose:

• Envíe un correo electrónico a [support@horsenose.eu](mailto:support@horsenose.eu) con "Seguridad" en la línea de asunto. (Está prevista una dirección dedicada "seguridad@" y una clave PGP).
• Incluya suficientes detalles para reproducir el problema.
• Danos un período razonable para investigar y remediar antes de cualquier divulgación pública.

Qué puedes esperar de nosotros:

• Un reconocimiento y una evaluación inicial tan pronto como sea razonablemente posible. horsenose es un servicio operado individualmente y no puede garantizar una respuesta el mismo día; No dejaremos que un informe creíble quede sin atención.
• El estado se actualiza a intervalos razonables mientras se clasifica o soluciona el problema.
• Crédito en cualquier divulgación posterior a la reparación, si lo desea (opcional).

Lo que aún no podemos ofrecer: no pagamos recompensas monetarias por errores en esta etapa. Lo diremos claramente cuando esté disponible un programa de recompensas.

Alcance y puerto seguro. La investigación de seguridad de buena fe que sigue esta política, permanece dentro de sus propias cuentas, evita degradar el Servicio para otros y no accede a datos que no sean los suyos no se considerará una violación de nuestra Política de uso aceptable o Términos de servicio. No intente acceder a los datos de otro centro ecuestre o de otro usuario, y no ejecute pruebas automáticas de raspado o denegación de servicio contra el Servicio.

9. Registro de cambios