1. Hosting e residenza dei dati
I dati dei clienti risiedono nell'Unione Europea, end-to-end:
- Database, autenticazione e archiviazione file su Supabase, regione eu-central-1 (Francoforte, Germania).
- Hosting web e funzioni edge su Vercel, ancorati a fra1 (Francoforte). Alcuni dati di telemetria della piattaforma transitano negli Stati Uniti sulla base delle Clausole Contrattuali Tipo (SCC) UE.
- Risoluzione DNS tramite la rete anycast globale di Cloudflare - nessun dato applicativo memorizzato.
- Email tramite Heinlein Hosting GmbH (Mailbox.org) - Berlino, Germania.
2. Cifratura
I dati in transito sono cifrati con TLS 1.2+ (HSTS abilitato; le richieste HTTP sono reindirizzate a HTTPS). I dati a riposo sono cifrati dal fornitore - Supabase utilizza AES-256, lo storage di oggetti di Vercel utilizza chiavi di cifratura gestite dal fornitore.
3. Modello di autorizzazione
Ogni interrogazione al database passa attraverso le Row-Level Security (RLS) di PostgreSQL. I controlli di permesso utilizzano una funzione helper a livelli (has_farm_permission(farm_id, tier)) per owner_only / finance_access / write_access / any_member, applicata a livello di database. L'interfaccia utente non è il confine di sicurezza - anche una richiesta client falsificata non può leggere dati negati dalla policy RLS. L'accesso con service role (utilizzato solo da webhook e cron) è limitato da variabile d'ambiente e non raggiungibile dal browser.
4. Registro delle attività
Ogni mutazione riuscita scrive esattamente una riga nella tabella activity_log. Il registro cattura chi ha fatto cosa, quando e con quale diff. Le voci di routine sono conservate per 24 mesi; le voci security/legal/finance/membership sono conservate a tempo indeterminato. Le righe soft-deleted nelle tabelle che lo supportano (animals, events, tasks, ecc.) sono hard-deleted dopo 24 mesi - ad eccezione delle tabelle dei dati finanziari, conservate dieci anni in conformità alla normativa fiscale italiana.
5. Backup e ripristino
Supabase esegue backup continui point-in-time per il database; sull'attuale piano Hobby la finestra di ripristino è di 24 ore. Una volta che il progetto passerà al piano Pro, la finestra si estenderà a 7 giorni. Lo storage dei file è replicato all'interno della regione eu-central-1. Non disponiamo oggi di una procedura di backup off-site; sarà rivista al passaggio in produzione (billing-live).
6. Posizione GDPR
Trattiamo il GDPR come requisito di prodotto di base, non come funzionalità. Ogni utente di Alpacakeep può esportare l'intero proprio insieme di dati in JSON, richiedere rettifica e richiedere cancellazione - il flusso di cancellazione include un cool-off di 30 giorni seguito da una cancellazione effettiva tramite cascade. Vedi la nostra Informativa privacy per la dichiarazione completa ai sensi degli artt. 13/14 GDPR e per la nostra procedura di gestione delle DSR.
7. Programma di responsible disclosure
Se ritiene di aver trovato una vulnerabilità di sicurezza, La preghiamo di segnalarcela prima di divulgarla pubblicamente. Ci impegniamo a confermare la ricezione della Sua segnalazione entro sette giorni di calendario e a fornire una risposta sostanziale (fix, piano di mitigazione o motivazione dettagliata) entro novanta giorni di calendario. I ricercatori che agiscono in buona fede - restando entro lo scope, senza accedere ai dati di altri utenti, senza degradare il servizio - non saranno oggetto di azioni legali da parte nostra; collaboreremo con Lei per risolvere il problema e La accrediteremo pubblicamente se lo desidera.
8. Scope
Nello scope:
- alpacakeep.com e qualsiasi locale o sotto-percorso servito dal dominio (ad es. /it/...).
- RPC pubblici leggibili in anonimo (in particolare get_public_animal).
- I flussi di registrazione, login, reset password e accettazione invito.
- La gestione dei dati dei clienti - RLS, IDOR, bypass del finance-access, ecc.
Fuori dallo scope:
- Infrastruttura dei sub-processor (Supabase, Vercel, Cloudflare, Mailbox.org) - segnali direttamente al fornitore.
- Vulnerabilità che richiedono accesso fisico al dispositivo dell'utente.
- Buone-pratiche senza chiaro impatto di sicurezza (ad es. header di sicurezza mancanti su una pagina statica, CSRF teorico su una GET senza effetti collaterali).
- Denial-of-service per volume - la prego di evitarli.
- Social engineering di personale, clienti o consulenti.
9. Come segnalare
Invii un'email a security@alpacakeep.com con:
- Una descrizione chiara della vulnerabilità e del suo impatto.
- I passi di riproduzione - idealmente un proof-of-concept minimo.
- Il Suo nome e un modo per contattarLa per i follow-up. Le segnalazioni anonime sono accettate ma più lente da gestire.
Al momento non offriamo un bug bounty monetario. Saremo lieti di accreditarLa pubblicamente in un security advisory o nelle note di rilascio se lo desidera.