Fiducia e sicurezza

1. Dove risiedono i dati

La nostra applicazione, i suoi database, l'archiviazione a oggetti e i backup sono eseguiti su Amazon Web Services nella regione eu-west-2 (Londra). Tre elementi si trovano fuori da quella regione, e tutti e tre compaiono nella tabella qui sotto: la posta in entrata è ricevuta da Amazon SES in eu-west-1 (Irlanda); il modello che scrive una risposta in chat è invocato tramite un profilo di inferenza cross-region dell'UE, quindi l'inferenza può essere servita da una qualsiasi regione AWS compresa in quel profilo; e un messaggio WhatsApp attraversa la WhatsApp Business Platform di Meta prima ancora di arrivare a noi. Il modello di embedding che indicizza i contenuti di un cliente non è su un profilo cross-region ed è eseguito in eu-west-2.

Non ti diremo che i dati non lasciano mai il Regno Unito, perché non sarebbe vero. Possiamo però dirti che non escono da AWS per raggiungere un fornitore di modelli. I modelli coinvolti sono due e non si trovano nello stesso posto. Quello che scrive le risposte è Claude di Anthropic, invocato su Amazon Bedrock tramite un profilo di inferenza cross-region dell'UE — il suo identificativo inizia con eu. — quindi una richiesta può essere servita da una qualsiasi regione AWS coperta da quel profilo. Quello che trasforma il testo in vettori, perché una domanda trovi la pagina giusta, è Titan Text Embeddings V2 di Amazon, che non è su un profilo cross-region ed è eseguito in eu-west-2. Entrambi girano su Bedrock all'interno del nostro account AWS, ed è per questo che Anthropic non è un nostro sub-responsabile del trattamento. Lo è AWS.

Se la residenza esclusivamente nel Regno Unito o esclusivamente nell'UE è una condizione per il tuo acquisto, sollevala prima della firma e non durante un audit. È una decisione di deployment e preferiamo affrontarla per tempo.

2. Sub-responsabili del trattamento

Questi sono i terzi che trattano i dati dei clienti per nostro conto. Dove la colonna del luogo del trattamento non indica una regione, è perché non ne abbiamo confermata una per iscritto — oppure, in un caso, perché non siamo in grado di stabilirla. Preferiamo lasciare la lacuna in evidenza piuttosto che stampare una supposizione su una pagina su cui un team di sicurezza farà affidamento.

Diamo un preavviso di almeno 30 giorni prima di aggiungere o sostituire un sub-responsabile, in modo che ci sia il tempo di opporsi. Per essere avvisato quando questo elenco cambia, scrivi a privacy@puglieseweb.com e chiedi di essere aggiunto all'elenco di notifica dei sub-responsabili.

3. Non addestriamo modelli sui tuoi contenuti

I contenuti delle email dei clienti, i messaggi in chat e su WhatsApp e i contenuti acquisiti dai siti web dei clienti non vengono utilizzati per addestrare o perfezionare alcun modello, né nostro né di altri. Non è soltanto un nostro impegno: l'inferenza è eseguita su Amazon Bedrock e le condizioni di AWS per Bedrock prevedono che input e output non siano usati per addestrare i modelli sottostanti né condivisi con il fornitore del modello. Non vendiamo tali contenuti, non li condividiamo e non li rendiamo altrimenti disponibili ad alcuno per tale finalità.

I contenuti vengono inviati al modello solo per rispondere al messaggio in questione, e solo per la durata di quella richiesta. I messaggi provenienti dal widget del sito passano inoltre attraverso un guardrail di Bedrock — un filtro per attacchi al prompt e per i contenuti — prima che il modello li veda.

4. Crittografia

I dati sono cifrati a riposo, ovunque, con AES-256, e in transito con TLS sugli endpoint web e API: la CDN davanti al sito reindirizza a HTTPS una richiesta in chiaro e le API rispondono soltanto su TLS. Un endpoint però non è come gli altri, e preferiamo dirlo piuttosto che lasciarti leggere «ogni endpoint pubblico» e dare per scontato che lo comprenda: la posta in entrata. La nostra regola di ricezione SES accetta TLS opportunistico — un server di posta che offre TLS lo ottiene, e uno che non lo offre viene comunque accettato anziché rifiutato — quindi un messaggio può raggiungerci attraversando un tratto che non controlliamo e non possiamo cifrare. È il consueto compromesso di chi riceve posta da tutta la rete. Anche la cifratura a riposo non è tutta sotto la stessa chiave, e preferiamo la precisione all'apparente ordine: le nostre tabelle DynamoDB sono cifrate con chiavi custodite in AWS Key Management Service e gestite da AWS, mentre i nostri bucket S3 — la posta in entrata con i suoi allegati e le immagini caricate dai visitatori — sono cifrati con chiavi gestite da S3. I backup ereditano la cifratura dell'archivio da cui provengono. Oggi non utilizziamo una chiave gestita dal cliente e non sosteniamo il contrario.

Questa è l'intera affermazione, formulata senza aggettivi. «Bank-grade» e «military-grade» sono termini di marketing privi di significato tecnico e la loro presenza in una pagina sulla sicurezza non dice al lettore nulla di verificabile.

5. Conservazione ed eliminazione

Per quanto tempo ciascun archivio conserva ciò che contiene. Le finestre sono diverse, e indicarne una sola per tutti sarebbe più semplice e sbagliato:

• I contenuti acquisiti dal sito web di un cliente non hanno una data di scadenza. Vengono sostituiti quando il sito viene scansionato di nuovo — una pagina che non è più sul sito viene archiviata alla successiva scansione completa — e vengono eliminati quando l'account viene eliminato, operazione che cancella insieme i contenuti di quel cliente, la sua configurazione di scansione e lo storico delle scansioni.
• Le trascrizioni delle conversazioni provenienti dal widget di chat e da WhatsApp scadono 90 giorni dopo essere state scritte. Tre precisazioni, perché il numero da solo direbbe più del vero. La scadenza è impressa su ciascun record nel momento in cui viene scritto, quindi vale per i record scritti d'ora in avanti: una conversazione memorizzata prima che la finestra fosse impostata — o, su WhatsApp, prima che questo canale ne imprimesse una — conserva ciò che le è stato assegnato allora, e nessun processo automatico torna sui record già scritti. Le conversazioni create dal nostro portale interno anziché da un visitatore non portano alcuna scadenza. E una conversazione che un operatore fissa — il pin della console — è deliberatamente esente, ed è così che si conserva oltre la finestra una conversazione che conta: il pin rimuove la scadenza dalla registrazione della conversazione, e toglierlo la reimposta a 90 giorni da quel momento. Va però detto con precisione fin dove arriva: il pin azzera la scadenza della registrazione della conversazione e delle risposte scritte mentre è attivo, mentre i messaggi già memorizzati mantengono la data di scadenza ricevuta quando sono stati scritti.
• La corrispondenza email conservata nella nostra casella è mantenuta per 24 mesi dall'ultima attività sul thread, dopodiché una procedura giornaliera la elimina del tutto: il thread, i suoi messaggi e i suoi allegati insieme. Una sola eccezione: un blocco di conservazione registrato sul thread lo mantiene finché non è trascorsa la data indicata nel blocco, o a tempo indeterminato finché è in corso un blocco per ragioni legali. Il messaggio grezzo che Amazon SES archivia al momento della ricezione scade dopo 30 giorni.
• A fronte di una richiesta scritta di cancellazione eliminiamo i dati entro 30 giorni e confermiamo per iscritto una volta completata l'operazione. Un record eliminato può restare presente nei backup point-in-time fino a 35 giorni dopo, che è la finestra di backup che manteniamo; quelle copie scadono da sole e l'applicazione non può leggerle.

6. Notifica delle violazioni

Se veniamo a conoscenza di una violazione dei dati personali che riguarda i dati di un cliente, la notifichiamo a quel cliente senza ingiustificato ritardo e comunque entro 72 ore dal momento in cui ne siamo venuti a conoscenza. La prima comunicazione contiene ciò che sappiamo in quel momento — che cosa è accaduto, quali dati sono coinvolti e che cosa stiamo facendo — ed è seguita da aggiornamenti man mano che il quadro si chiarisce. Non aspettiamo la fine dell'indagine per informarti.

7. Autenticazione e controllo degli accessi

• L'accesso dei clienti è gestito da un unico user pool di Amazon Cognito, con email e password oppure accesso con Google o Apple.
• L'autorizzazione è delimitata per tenant: il token contiene il tenant e il ruolo per cui è stato emesso e l'API lo verifica a ogni richiesta.
• Nulla viene rilasciato in produzione con una chiave AWS di lunga durata: le pipeline assumono un ruolo di deploy tramite il provider OIDC di GitHub, e la trust policy del ruolo elenca i repository autorizzati ad assumerlo. L'accesso amministrativo umano è limitato a persone nominate: questo però attiene a come gestiamo l'account e non è un controllo che possiamo mostrarti nel codice, quindi va pesato di conseguenza.
• Le azioni di gestione eseguite sul nostro account AWS di produzione sono registrate in AWS CloudTrail dal trail dell'organizzazione, che le consegna in un account separato di archiviazione dei log anziché nell'account sottoposto ad audit.

8. Il crawler

Ema legge il sito web del cliente per potervi attingere le risposte. Una scansione viene eseguita solo dopo che quel cliente ha dimostrato di controllare il dominio — con un record DNS TXT, un file token servito dal sito, un token nella homepage oppure un'attestazione registrata da un membro del nostro staff quando l'autorizzazione è conservata su carta. L'identità del crawler, i suoi limiti di frequenza, il suo comportamento quando robots.txt non è leggibile e tutti i modi per bloccarlo sono documentati per esteso qui: EmaIngestBot.

9. Segnalare una vulnerabilità

I nostri recapiti e le nostre preferenze di divulgazione sono pubblicati su /.well-known/security.txt. Segnala in privato a security@puglieseweb.com e concedici un periodo ragionevole per correggere il problema prima di divulgarlo.

Questo impegno non è un ornamento. Il Computer Misuse Act 1990 qualifica l'accesso non autorizzato a un sistema informatico come reato e non prevede alcuna esimente di interesse pubblico per la ricerca sulla sicurezza: un ricercatore nel Regno Unito si espone quindi personalmente per il solo fatto di dirci che il nostro servizio ha un difetto. Se non dichiariamo chiaramente che non lo perseguiremo, la cosa razionale per lui è tacere — e il difetto resta nel nostro prodotto. Preferiamo di gran lunga esserne informati.

/.well-known/security.txt

10. Assicurazione

PuglieseWeb LTD mantiene una copertura assicurativa di responsabilità civile professionale e cyber adeguata ai servizi che eroga.

11. Contatti

Per domande su quanto riportato in questa pagina, o per un questionario di sicurezza da compilare: