Sicurezza

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 sia per il database sia per l'archiviazione dei file (foto e documenti), con chiavi gestite dal fornitore.

3. Modello di autorizzazione

Ogni richiesta proveniente da una sessione del browser 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. Un numero ristretto di percorsi server-side attendibili utilizza una chiave service role che aggira le RLS: i job pianificati di retention, il webhook Stripe, il controllo di stato, l'invio delle notifiche email per le richieste degli acquirenti, il feed calendario autenticato tramite token, i link firmati a breve scadenza che servono i documenti pubblicati da un venditore su una pagina di vendita e una dashboard di amministrazione riservata all'operatore. Tale chiave è esclusivamente lato server, limitata da variabile d'ambiente e mai 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

Il progetto Supabase è attualmente sul piano Free, che non include backup automatici né il ripristino point-in-time. L'operatore dispone di un comando manuale di dump del database, ma oggi non esiste alcun backup pianificato né alcuna procedura di backup off-site. Prima del lancio dei piani a pagamento il progetto passerà al piano Pro di Supabase, che offre 7 giorni di backup giornalieri; il ripristino point-in-time è un componente aggiuntivo a pagamento separato che valuteremo in quella sede. Lo storage dei file è replicato all'interno della regione eu-central-1. Se le garanzie di backup sono rilevanti per la Sua valutazione, ce lo chieda e Le diremo esattamente cosa è in essere quel giorno.

6. Posizione GDPR

Trattiamo il GDPR come requisito di prodotto di base, non come funzionalità. Ogni utente di AlpacaKeep può esportare in CSV i propri insiemi di dati principali (animali, eventi, mostre, movimenti finanziari, risultati della fibra), 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.