Sicurezza e fiducia

1. Riepilogo di una pagina

Il nostro onesto stato attuale, a partire da 2026-07-08: horsenose è un prodotto in fase iniziale gestito da un operatore solista. Oggi NON disponiamo della certificazione SOC 2 o ISO 27001 e non abbiamo ancora effettuato un test di penetrazione esterno. Questa pagina descrive cosa facciamo, cosa abbiamo e cosa non abbiamo ancora. Preferiamo dirvi chiaramente la nostra posizione piuttosto che esagerarla.

• Chi siamo. horsenose è un software per la gestione di una scuola di equitazione: programmazione delle lezioni, monitoraggio delle presenze e delle modalità di pagamento dei cavalieri, gestione di pacchetti lezioni e buoni regalo, calcolo dei guadagni degli istruttori e offerta ai clienti di un maneggio una visione delle proprie prenotazioni. È gestito da DF Daniel Fojcik, una ditta individuale polacca (NIP 6472592229 / REGON 387798601, Marklowice), che opera come Nose / horsenose.
• I nostri due ruoli. Siamo il titolare del trattamento per i nostri dati di account, analisi e sicurezza e un responsabile del trattamento che agisce in base alle istruzioni di ciascun maneggio per i dati del cavaliere/cliente immessi dal maneggio. Il rapporto con il responsabile del trattamento è regolato dal nostro Accordo sul trattamento dei dati (DPA). Vedere la sezione "Inquadramento della conformità" di seguito.
• Cosa conserviamo. E-mail dell'account e nome/telefono del profilo opzionale; indirizzi email di invito; i registri operativi che un maneggio inserisce sui propri cavalieri (nomi, contatti, partecipazione alle lezioni, pacchetti lezioni/buoni regalo, etichette per il tracciamento dei pagamenti, note di testo libero); PIN di pianificazione con hash bcrypt; Token di invito con hash SHA-256. Non conserviamo dati bancari o di carte di pagamento e nemmeno dati sanitari. Inventario completo nella sezione "Dati in nostro possesso" di seguito.
• Cosa lo protegge. TLS ovunque con precarico HSTS; crittografia a riposo (AES-256); sicurezza a livello di riga applicata dal database che isola ogni maneggio; convalida della sessione lato server; potenziare la riautenticazione per azioni distruttive e amministrative; una rigorosa politica di sicurezza dei contenuti; limitazione della velocità e protezione dei bot; e un registro di controllo di sola aggiunta. Elenco completo nella sezione "Misure tecniche" di seguito.
• Dove viene eseguito. Su più di una regione, e aggiungiamo regioni man mano che cresciamo — la regione primaria attuale di ciascun fornitore è elencata in "Infrastruttura: chi gestisce cosa e dove" di seguito e può cambiare man mano che ci espandiamo. Oggi, la maggior parte del trattamento principale avviene nel SEE (database, posta elettronica, analisi, monitoraggio degli errori e archivio con limite di velocità), con alcuni componenti già al di fuori di esso (l'edge globale di Cloudflare; l'accesso Google e parti di Stripe negli Stati Uniti; Dodo Payments a livello globale). Ogni percorso tra regioni è coperto da un meccanismo di trasferimento appropriato — il EU-U.S. Data Privacy Framework, lo Standard Contractual Clauses dell'UE, l'addendum del Regno Unito, o l'equivalente richiesto da una regione aggiunta.
• Ciò che non abbiamo ancora. Nessun SOC 2, ISO 27001, test di penetrazione esterna o programma bug-bounty. Se oggi il vostro processo di approvvigionamento richiede SOC 2, non siamo ancora la soluzione giusta.
• Come contattarci in merito alla sicurezza. Invia un'e-mail a support@horsenose.eu con "Sicurezza" nella riga dell'oggetto. Vedere "Risposta all'incidente (notifica di violazione entro 72 ore)" e "Divulgazione responsabile" di seguito.

2. Dati in nostro possesso

Raccogliamo il minimo necessario per eseguire il Servizio. Le categorie seguenti sono i dati personali che toccano horsenose.

Ciò che non tratteniamo

• Nessuna carta di pagamento o dati bancari. horsenose non è mai parte di un pagamento e non gestisce mai i dati della carta. I metodi offline ("contanti", "pacchetto", "buono regalo", "bonifico") sono etichette di tracciamento registrate da un maneggio — non transazioni eseguite da horsenose. Per la fatturazione dell'abbonamento del maneggio (Stripe per i maneggi polacchi, Dodo Payments come Merchant of Record per i maneggi non polacchi) e per i pagamenti online dei cavalieri, quando un maneggio li attiva (Stripe, con liquidazione sull'account proprio del maneggio), i dati della carta vengono gestiti interamente sul checkout del fornitore di servizi di pagamento e non ci raggiungono mai — quindi rimaniamo fuori dall'ambito PCI DSS (vedere "Framing di conformità" di seguito).
• Nessun documento d'identità o indirizzo. Non raccogliamo indirizzi di casa, numeri di documenti d'identità o identificatori governativi.
• Nessun dato di categoria speciale (salute). Non intendiamo raccogliere dati ai sensi dell'articolo 9 GDPR e il prodotto non è progettato per memorizzarli. Ai maneggi viene richiesto (nel DPA) non di inserire dati di categorie speciali nei campi di testo libero. Le note su un cavallo riguardano un animale, non una persona, e non rientrano in GDPR.
• Nessun profilo pubblicitario, identificatore di retargeting o tracciamento tra siti. Nessun pixel Meta/LinkedIn/X/TikTok; nessuna impronta digitale del browser.
• Nessun dato venduto, affittato o prestato a terzi.
• Nessun addestramento dei modelli AI/ML sui tuoi dati. Non addestriamo, perfezioniamo o valutiamo alcun modello di intelligenza artificiale o di apprendimento automatico sui dati personali estratti da horsenose. L'estensione "pgvector" è abilitata nel nostro Postgres per futuri casi d'uso di ricerca interna ma, oggi, non è popolata con alcun incorporamento derivato da dati personali.

3. Infrastruttura: chi gestisce cosa e dove

horsenose è un'applicazione Next.js ospitata su Vercel, supportata da un database Postgres Supabase, con un piccolo insieme di provider specializzati ("sottoprocessori"), ciascuno dei quali gestisce una fetta ristretta. Nessuno ha accesso end-to-end a tutto. Operiamo su più di una regione e aggiungiamo regioni man mano che cresciamo, quindi descriviamo dove si trovano le cose oggi anziché promettere un'unica posizione permanente: la maggior parte del trattamento principale — il database, la posta elettronica, l'analisi dei prodotti e il monitoraggio degli errori — avviene nel SEE, mentre alcuni componenti sono già eseguiti al di fuori di esso (l'edge globale di Cloudflare; l'accesso Google opzionale e parti di Stripe negli Stati Uniti; Dodo Payments su base globale di Merchant of Record). La regione primaria attuale di ciascun fornitore è nella tabella qui sotto e viene mantenuta aggiornata man mano che cambia; ogni percorso tra regioni è coperto da un meccanismo di trasferimento appropriato (il EU-U.S. Data Privacy Framework, lo Standard Contractual Clauses, l'addendum del Regno Unito, o l'equivalente richiesto da una regione aggiunta).

La versione canonica e sempre aggiornata di questa tabella, con le categorie di dati personali per fornitore e i meccanismi di trasferimento, è mantenuta nella pagina dei Subresponsabili del trattamento; l'Informativa sulla privacy e il DPA si collegano alla stessa fonte anziché conservare copie divergenti.

4. Misure tecniche

Questi sono i controlli effettivamente in atto oggi. Questa è anche la sostanza alla base del DPA → "Riservatezza, sicurezza e sub-responsabili del trattamento", che indica qui le nostre misure tecniche e organizzative.

Rete e trasporti

• TLS per tutto il traffico, applicato da Vercel e Supabase. HSTS è impostato con `max-age=63072000; includeSottodomini; precarico`.
• Nessun contenuto misto: la politica di sicurezza dei contenuti rifiuta le risorse "http://`".

Isolamento e autorizzazione dell'inquilino

• Sicurezza a livello di riga (RLS) limitata a ciascun maneggio su ogni tabella operativa, applicata nel database stesso: i dati di un maneggio non possono essere letti da un altro anche se il codice dell'applicazione presenta un bug. Questa è la principale difesa tra tenant.
• Cancelli di ruolo a livello di applicazione (autenticati/con ambito maneggio/istruttore o amministratore/super amministratore) come difesa approfondita sopra RLS, mai come unica linea.
• I controlli a livello di percorso richiedono una sessione attiva per i percorsi protetti e lo stato di super amministratore per la superficie di amministrazione.

Autenticazione

• Accesso senza password: collegamento magico via e-mail (gestito da Supabase Auth) o accesso Google opzionale (OAuth). Nessuna password viene memorizzata.
• Convalida della sessione lato server su ogni richiesta protetta: il solo cookie di accesso non è mai considerato attendibile.
• Riautenticazione step-up per azioni distruttive e amministrative: è richiesto un cookie step-up di breve durata e firmato separatamente per operazioni quali l'eliminazione dell'account, le modifiche al ruolo dell'ultimo amministratore, la disattivazione collettiva, l'archiviazione maneggio e tutte le scritture dei super amministratori; Lo step-up mancante o scaduto non viene chiuso.
• La superficie di amministrazione della piattaforma restituisce 404 quando non è configurato alcun super amministratore, quindi la sua esistenza non viene trapelata.

Segreti e gestione delle credenziali

• I PIN di pianificazione vengono archiviati come hash bcrypt; I token di invito vengono archiviati come hash SHA-256: monouso, limitati nel tempo (scadenza di 7 giorni) e destinati all'e-mail; i token grezzi non vengono mai persistenti.
• La chiave del ruolo del servizio database è solo server: non viene mai inclusa nel JavaScript del client; un validatore in fase di compilazione fallisce la compilazione se una variabile sensibile ha un prefisso errato.

Gestione degli input e degli output

• Convalida dello schema a ogni limite di input del server: la convalida lato client viene trattata solo come UX; il server è il confine di fiducia.
• Una rigorosa policy di sicurezza dei contenuti con un nonce per richiesta, oltre a un set di intestazioni di sicurezza bloccate (`X-Content-Type-Options`, `X-Frame-Options` / `frame-ancestors`, `Referrer-Policy`, intestazioni di isolamento multiorigine e una `Policy di autorizzazione` restrittiva).
• Fuga automatica dell'uscita; in questa fase il contenuto creato dall'utente è testo semplice.

Protezione da abusi e bot

• Limitazione della velocità su accesso, registrazione, collegamento magico, accettazione invito, esportazione/cancellazione e altri endpoint sensibili (per e-mail, per IP, per utente o per maneggio a seconda dell'azione; ogni policy è di tipo fail-open o fail-close in base alla progettazione).
• Cloudflare Turnstile protezione dai bot nel modulo di accesso, nel modulo di iscrizione, nella richiesta di collegamento magico, nella pagina di accettazione dell'invito e nell'immissione del PIN di pianificazione pubblica.

Dati archiviati e traccia di controllo

• Crittografia a riposo tramite Supabase (AES-256).
• Un registro di controllo di sola aggiunta registra eventi rilevanti per la sicurezza (autenticazione, modifiche di ruolo e appartenenza, eventi finanziari, esportazioni, eliminazioni). È sempre scritto ed è distinto dalla telemetria operativa.
• Monitoraggio degli errori con la pulizia dei dati personali: prima che qualsiasi errore venga inviato a Sentry, uno scrubber personalizzato elimina indirizzi email, numeri di telefono, corpi dei messaggi, note e qualsiasi campo che assomigli a un token. Ciò che rimane è il contesto tecnico più un UUID utente pseudonimo, l'identificatore maneggio, la locale e il nome dell'operazione non riuscita.

Backup e ripristino

• Supabase fornisce backup giornalieri automatizzati (conservazione di 7 giorni al livello attuale; è prevista una conservazione più lunga man mano che il Servizio matura). Vercel conserva le distribuzioni precedenti per il rollback quasi istantaneo di una versione non valida.

5. Misure organizzative

• Operatore singolo. horsenose è gestito da una persona (Daniel Fojcik). Al momento non sono presenti dipendenti con accesso alla produzione. Se ciò cambia, ad esempio se viene assunto un appaltatore con accesso alla produzione, questa pagina verrà aggiornata e i maneggi attivi verranno informati.
• I dati di produzione rimangono sull'infrastruttura gestita. I dump del database di produzione non vengono archiviati sulle macchine locali; lo sviluppo locale utilizza un database separato con dati sintetici.
• Privilegio minimo per gli account di servizio. La chiave del ruolo di servizio del database è limitata al solo utilizzo lato server; l'accesso al database del browser utilizza una chiave limitata dietro la sicurezza a livello di riga.
• Gestione dei segreti. I segreti risiedono nella configurazione dell'ambiente del provider di hosting e in un file locale gitignorato, mai salvato nel repository. I segreti di produzione non vengono copiati sui computer locali.
• Registrazione degli accessi lato provider. Le azioni amministrative sui nostri provider vengono registrate da tali provider; li esaminiamo su base ad hoc.
• Riservatezza. Il Personale (attualmente il Titolare) è tenuto alla riservatezza in merito ai dati personali trattati attraverso il Servizio, come indicato nella DPA.
• Modifica disciplina. Le modifiche al codice superano un rigoroso controllo di tipo, lanugine e test automatizzati prima della distribuzione, mentre le migrazioni dei database vengono applicate a un ambiente di staging prima della produzione.

6. Risposta all'incidente (notifica di violazione entro 72 ore)

Monitoraggio. Gli errori vengono inviati a Sentry (con la cancellazione dei dati personali descritta in "Misure tecniche" sopra); la diagnostica a livello di richiesta è disponibile nei log di hosting; un monitoraggio del tempo di attività e avvisi sul tasso di errore fanno parte della linea di base del rafforzamento. Il registro di controllo di sola aggiunta fornisce una registrazione duratura degli eventi rilevanti per la sicurezza a scopo di indagine.

Il nostro impegno di notifica delle violazioni. Se si verifica una violazione dei dati personali che potrebbe comportare un rischio per i diritti e le libertà delle persone interessate, noi:

• Informare l'autorità di controllo competente — il presidente di UODO in Polonia — senza indebito ritardo e, ove possibile, entro 72 ore dal venire a conoscenza della violazione (articolo 33 GDPR).
• *Laddove la violazione possa comportare un rischio elevato* per le persone interessate, informarle senza indebito ritardo, descrivendo la natura della violazione, le categorie di dati coinvolti, le probabili conseguenze e le misure adottate (articolo 34 GDPR**).
• Quando agiamo in qualità di responsabili del trattamento per un maneggio, informa tale maneggio (il titolare del trattamento) senza indebito ritardo in modo che possa adempiere ai propri obblighi ai sensi dell'articolo 33/34 nei confronti dei suoi cavalieri.

Ciò rispecchia l'Informativa sulla privacy e il DPA. Indica come intendiamo attuare un obbligo già imposto dallo GDPR: non si tratta di una promessa contrattuale aggiuntiva oltre allo GDPR. Nella tabella di marcia è presente un runbook di risposta agli incidenti formalmente documentato; fino ad allora un team composto da una sola persona risponde ad hoc entro le tempistiche sopra indicate.

Contatto. Non urgente: support@horsenose.eu. Sicurezza (urgente): invia un'e-mail a support@horsenose.eu con "Sicurezza" nella riga dell'oggetto.

7. Inquadramento della conformità

GDPR (Regolamento 2016/679). horsenose opera sotto un doppio ruolo: titolare del trattamento per i dati di cui determina scopi e mezzi (visitatori di siti di marketing, dati di account/contatto di amministratori e istruttori di maneggio, analisi dei prodotti soggetti a consenso e dati di sicurezza/prevenzione di abusi) e responsabile del trattamento dei dati operativi del cavaliere/cliente immessi in un maneggio: lì, il maneggio è il titolare del trattamento e processi horsenose sulle istruzioni documentate del maneggio ai sensi del DPA (articolo 28 GDPR). I subresponsabili del trattamento operano in base ai contratti previsti dall'articolo 28 (DPA + SCCs/DPF, l'addendum del Regno Unito o un meccanismo equivalente laddove un trasferimento attraversa le regioni) — consultare la pagina dei subresponsabili del trattamento.

Dati dei bambini. I maneggi insegnano regolarmente ai bambini, quindi horsenose elabora consapevolmente i dati dei minori per conto di un maneggio (ad esempio, un bambino inserito come partecipante alla lezione, spesso da un genitore cliente del maneggio). Il maneggio è responsabile della base legale e di qualsiasi consenso o autorità dei genitori richiesta (articolo 8 GDPR); horsenose minimizza ciò che si ritiene riguardo ai bambini e non si rivolge né commercializza direttamente ai bambini. Consulta la Privacy Policy → “Privacy dei bambini”.

Sono supportati i diritti dell'interessato, incluso l'accesso/portabilità self-service tramite un'esportazione JSON su /account/export e la cancellazione tramite /account/delete (si applicano un periodo di grazia reversibile di 30 giorni e una riautenticazione graduale; in caso di cancellazione eliminiamo gli identificatori diretti anziché eliminarli definitivamente — pseudonimizzazione ai sensi dell'articolo 4, paragrafo 5, GDPR, non anonimizzazione completa ai sensi del considerando 26; consultare la tabella di conservazione nella Privacy Policy → “Per quanto tempo conserviamo i dati” per il dettaglio a livello di campo). Per i dati del cavaliere, il titolare del trattamento è il maneggio, quindi un cavaliere esercita diritti nei confronti del suo maneggio e horsenose lo assiste come responsabile del trattamento.

PCI DSS: non applicabile a horsenose. Non gestiamo, archiviamo o trasmettiamo i dati della carta. Per la fatturazione dell'abbonamento del maneggio, il percorso dei dati della carta viene effettuato interamente dal fornitore di servizi di pagamento sul suo checkout ospitato — Stripe (processore dei pagamenti) per i maneggi polacchi, con horsenose come commerciante, e Dodo Payments come Merchant of Record per i maneggi non polacchi. Per i pagamenti online dei cavalieri, quando un maneggio li attiva, i dati di carta, portafoglio o BLIK vengono trasmessi interamente da Stripe (tramite Stripe Connect) e si liquidano sull'account Stripe proprio del maneggio — il maneggio è il commerciante e Stripe è il processore dei pagamenti conforme allo standard PCI, mentre horsenose si limita a trasmettere le istruzioni e non riceve mai i dati della carta. In ogni caso horsenose non riceve mai i dati della carta e rimane fuori dall'ambito PCI.

Legge UE sull'intelligenza artificiale: non applicabile. horsenose è uno strumento operativo per i maneggi; non addestra, sviluppa o distribuisce modelli di intelligenza artificiale e nessun componente utilizza l'apprendimento automatico o l'intelligenza artificiale generativa per elaborare i dati personali. L'estensione "pgvector" Postgres è abilitata per possibili futuri casi d'uso di ricerca interna, ma oggi non è popolata con incorporamenti derivati ​​​​da dati personali; se ciò dovesse cambiare, pubblicheremo una posizione sulla legge UE sull'intelligenza artificiale e un impegno a "nessuna formazione sui dati personali" prima della pubblicazione del servizio.

ePrivacy/cookie. Analisi facoltativa (PostHog) caricamento solo su consenso; i cookie strettamente necessari sono esenti ai sensi dell'articolo 5, paragrafo 3, della direttiva e-Privacy. Consulta la Politica sui cookie.

8. Divulgazione responsabile

Se ritieni di aver trovato una vulnerabilità di sicurezza in horsenose:

• Invia un'e-mail a [support@horsenose.eu](mailto:support@horsenose.eu) con `Sicurezza` nella riga dell'oggetto. (Sono previsti un indirizzo `security@` dedicato e una chiave PGP.)
• Includi dettagli sufficienti per riprodurre il problema.
• Concedeteci un periodo ragionevole per indagare e porre rimedio prima di qualsiasi divulgazione pubblica.

Cosa puoi aspettarti da noi:

• Un riconoscimento e una valutazione iniziale non appena ragionevolmente possibile. horsenose è un servizio gestito da un solo operatore e non può garantire una risposta in giornata; non lasceremo che un rapporto credibile resti incustodito.
• Lo stato viene aggiornato a intervalli ragionevoli durante la valutazione o la risoluzione del problema.
• Se lo desideri, aggiungi credito a qualsiasi divulgazione post-correzione (facoltativo).

Ciò che non possiamo ancora offrire: non paghiamo ricompense monetarie per i bug in questa fase. Lo diremo chiaramente se e quando un programma di taglie sarà disponibile.

Ambito e porto sicuro. La ricerca sulla sicurezza in buona fede che segue questa politica, rimane all'interno dei tuoi account, evita di degradare il Servizio per altri e non accede a dati diversi dai tuoi non sarà trattata come una violazione della nostra Politica di utilizzo accettabile o dei Termini di servizio. Non tentare di accedere ai dati di un altro maneggio o di un altro cavaliere e non eseguire test automatizzati di scraping o di negazione del servizio sul Servizio.

9. Modifica registro