Panoramica sulla sicurezza / Whitepaper sulla sicurezza

Ultimo aggiornamento: 25 ottobre 2026 (versione 1.0).

Cadenza di revisione: annuale, nonché in occasione di ogni modifica sostanziale dell'architettura della piattaforma

1. Introduzione

PassportScan Cloud è una piattaforma Software-as-a-Service gestita da GlobeID Limited ("GlobeID") che consente alle strutture ricettive di acquisire i documenti di identità degli ospiti, raccogliere consensi e firme e adempiere agli obblighi di legge in materia di registrazione degli ospiti (autorità di polizia, di statistica e di frontiera), oltre all'integrazione con i sistemi PMS.

Il presente documento descrive l'architettura di sicurezza e le misure tecniche e organizzative che proteggono la piattaforma e i dati personali ivi trattati. È destinato a clienti, potenziali clienti e revisori, integra l'Accordo sul trattamento dei dati (DPA) e l'Elenco dei sub-responsabili e costituisce il riferimento per le risposte ai questionari di sicurezza. Descrive la piattaforma di produzione così come implementata alla data di entrata in vigore del presente documento.

2. Programma di sicurezza e conformità

• GlobeID gestisce un Sistema di Gestione della Sicurezza delle Informazioni (ISMS) allineato alla norma ISO/IEC 27001:2022, con un Chief Information Security Officer designato, un registro dei rischi e una Dichiarazione di Applicabilità; l'ISMS è sottoposto a revisione mediante audit interni e riesami della direzione pianificati con cadenza annuale.
• GDPR: GlobeID agisce in qualità di responsabile del trattamento per i dati degli ospiti ai sensi del DPA e ha nominato un Responsabile della protezione dei dati esterno. Sono mantenuti i registri delle attività di trattamento, una DPIA per i dati di identità degli ospiti e una procedura per l'esercizio dei diritti degli interessati.
• I dati delle carte di pagamento sono gestiti esclusivamente da Stripe; PassportScan non gestisce un Cardholder Data Environment e non riceve mai numeri di carta, CVV o date di scadenza.
• Il monitoraggio dei controlli è continuo grazie a una piattaforma di automazione della conformità connessa ai provider cloud, di codice sorgente e di identità; vengono periodicamente commissionati penetration test indipendenti e i rilievi sono monitorati fino alla loro risoluzione.

3. Hosting e architettura

4. Sicurezza di rete

• Privato per impostazione predefinita: ogni servizio è eseguito in sottoreti private di una VPC dedicata. Soltanto i front-end rivolti ai clienti, la console di amministrazione del personale e due API pubbliche sono raggiungibili da Internet, tramite Amazon API Gateway e un Application Load Balancer pubblico. La console di amministrazione è protetta da AWS WAF e da un proprio sistema di autenticazione con account del personale assegnati individualmente e autenticazione a più fattori obbligatoria. Tutti i microservizi interni, il motore di automazione e il motore OCR sono raggiungibili esclusivamente dall'interno della VPC o tramite la VPN aziendale.
• Web application firewall: il perimetro pubblico (gli stage di API Gateway e il load balancer pubblico) è protetto da AWS WAF. I gruppi di regole gestiti da AWS Amazon IP Reputation List e Known Bad Inputs bloccano origini e payload dannosi, il Core Rule Set di AWS (allineato a OWASP) viene valutato su ogni richiesta e la limitazione della frequenza (rate limiting) blocca le origini abusive, con limiti più severi sugli endpoint di autenticazione.
• Crittografia in transito: gli endpoint pubblici accettano esclusivamente TLS 1.2 e TLS 1.3 (policy di sicurezza di API Gateway TLS_1_2; policy del load balancer ELBSecurityPolicy-TLS13-1-2-2021-06 con suite di cifratura moderne ECDHE-GCM). HTTP viene reindirizzato a HTTPS e sul load balancer pubblico è applicato HTTP Strict Transport Security (HSTS). I certificati sono emessi e rinnovati automaticamente da AWS Certificate Manager.
• Accesso amministrativo: gli ingegneri accedono ai servizi interni esclusivamente tramite una VPN zero-trust vincolata alla loro identità individuale; non esiste alcun accesso SSH o RDP esposto a Internet, né alcun bastion host.
• Registrazione delle attività di rete: i VPC Flow Log (tutto il traffico) e i log di accesso al server S3 sono conservati per 90 giorni.

5. Sicurezza dei dati

5.1 Crittografia

5.2 Ubicazione e residenza dei dati

• I servizi principali della piattaforma e i database primari sono ospitati esclusivamente in AWS eu-west-1 (Irlanda); non è configurata alcuna replica dei database tra regioni diverse.
• Qualora un cliente attivi l'archiviazione delle immagini dei documenti, le immagini vengono conservate nella regione S3 corrispondente alla giurisdizione della struttura. Regioni predisposte: eu-west-1 (Europa), us-east-1 (Nord America), sa-east-1 (Sud America), ap-southeast-1 (Asia-Pacifico) e ap-southeast-2 (Australia). Ogni bucket regionale applica la medesima configurazione di crittografia, versioning e registrazione degli accessi.
• I trasferimenti al di fuori dello SEE sono coperti dall'AWS Data Processing Addendum e dalle Clausole Contrattuali Standard, come descritto nel DPA.

5.3 Segreti e chiavi

• I segreti applicativi, le chiavi API e le chiavi di crittografia sono archiviati in AWS Systems Manager Parameter Store (SecureString) e iniettati nei container all'avvio; non vengono mai inseriti nel codice sorgente né incorporati nelle immagini.
• Le credenziali dei database sono generate e ruotate da AWS (segreti gestiti da RDS in AWS Secrets Manager) oppure archiviate come SecureString in AWS Systems Manager Parameter Store e iniettate nei container come segreti all'avvio.
• Le modifiche ai segreti in produzione vengono eseguite tramite un flusso di lavoro operativo sottoposto ad audit, non manualmente dalla console. Le password dei database applicativi vengono ruotate secondo una pianificazione dalla nostra piattaforma operativa interna, senza alcuna interruzione del servizio.

5.4 Backup e conservazione

• Aurora MySQL: backup giornalieri automatizzati con conservazione di 15 giorni e ripristino point-in-time continuo; protezione dall'eliminazione attivata; prima di qualsiasi eliminazione del cluster viene effettuato uno snapshot finale.
• Object storage: versioning con conservazione delle versioni precedenti per 90 giorni, a protezione da eliminazioni o sovrascritture accidentali.
• Al termine del contratto, i dati del cliente vengono restituiti al cliente e/o cancellati su sua richiesta, entro 30 giorni dalla richiesta, come previsto dal DPA; le copie di backup scadono successivamente secondo il ciclo di conservazione sopra indicato.

6. Gestione delle identità e degli accessi

• Utenti dei clienti: si autenticano tramite l'identity provider della piattaforma (Clerk) con verifica dell'indirizzo e-mail, gestione delle sessioni e autenticazione a più fattori opzionale; l'accesso all'interno dell'account di un cliente è basato sui ruoli.
• Personale GlobeID: l'accesso al codice sorgente, alla CI/CD e alla console di gestione interna avviene tramite l'organizzazione GitHub con autenticazione a due fattori obbligatoria. Nessun ingegnere dispone di accesso permanente all'account AWS di produzione e nessuna credenziale detenuta da una persona può assumere un ruolo al suo interno: la produzione viene modificata e gestita esclusivamente attraverso la nostra piattaforma operativa interna e flussi di lavoro operativi sottoposti ad audit, senza alcun percorso tramite console o riga di comando per gli ingegneri. Gli sviluppatori dispongono di un accesso secondo il principio del privilegio minimo esclusivamente agli account di sviluppo e staging. Il monitoraggio e le operazioni utilizzano ruoli dedicati a privilegio minimo; le limitate azioni operative disponibili sulla nostra piattaforma operativa (ad esempio riavvio progressivo, modalità di manutenzione, rotazione programmata delle credenziali, attività una tantum sui dati previamente approvate e snapshot dei database) sono circoscritte a risorse specificamente individuate, subordinate al ruolo e, per le operazioni sui dati di produzione, all'approvazione di un secondo amministratore, e sono sottoposte ad audit. Una procedura di emergenza documentata (break-glass) è riservata ai proprietari dell'organizzazione appositamente designati, viene eseguita esclusivamente attraverso il nostro sistema CI/CD ed è registrata e riesaminata a ogni utilizzo.
• Accesso al database di produzione: non è concesso in via permanente agli ingegneri; viene richiesto just-in-time attraverso la nostra piattaforma operativa interna con indicazione della motivazione, approvato da un secondo amministratore (mai il richiedente), fornito come utente di database circoscritto a un singolo database e a un singolo livello di accesso, mai con diritti di modifica dello schema, limitato nel tempo (in produzione al massimo 4 ore per l'accesso in lettura e 1 ora per l'accesso in scrittura) e rimosso automaticamente alla scadenza; le credenziali sono mostrate esclusivamente al richiedente. Ogni richiesta, approvazione e revoca viene registrata. L'esportazione di dati di produzione verso le postazioni di lavoro è vietata.
• I dati di produzione restano in produzione: gli ambienti di sviluppo e staging utilizzano esclusivamente dati sintetici o anonimizzati. Gli snapshot dei database vengono ripristinati solo in un nuovo database all'interno dell'ambiente dal quale sono stati acquisiti, cosicché i dati di produzione non vengono mai ripristinati in ambienti di sviluppo o di test; un ripristino in produzione richiede l'indicazione della motivazione e l'approvazione di un secondo amministratore. Le correzioni ai dati di produzione vengono effettuate esclusivamente mediante attività previamente dichiarate, sottoposte a revisione del codice, testate prima in staging e approvate da un secondo amministratore — mai mediante SQL ad hoc.
• Registro di audit delle attività degli operatori: tutte le operazioni privilegiate eseguite attraverso la piattaforma operativa, incluso l'accesso al contenuto dei log di produzione — richieste di accesso e relative approvazioni, promozioni e rollback dei rilasci, modifiche dello stato di alimentazione degli ambienti, modifiche di configurazione, approvazioni di documenti e firme elettroniche — vengono registrate con l'identità dell'operatore (SSO GitHub, 2FA obbligatoria), la marca temporale e l'esito, e sono disponibili come evidenze per i revisori.
• CI/CD verso AWS: l'autenticazione avviene tramite federazione GitHub OpenID Connect con un ruolo di deployment dedicato per ciascun ambiente, limitato ai repository specificamente individuati della piattaforma.
• Le procedure di ingresso, cambio di ruolo e uscita del personale, lo screening e gli impegni di riservatezza fanno parte della procedura di sicurezza delle risorse umane; le revisioni degli accessi vengono effettuate periodicamente.

7. Sviluppo sicuro e gestione delle modifiche

• Ogni modifica raggiunge la produzione attraverso Git: pull request, revisione indipendente del codice (approvazione da parte di una persona diversa dall'autore), controlli automatizzati e un flusso di promozione branch-per-ambiente (sviluppo → staging → produzione). Ogni promozione verso staging e verso la produzione viene richiesta da un amministratore e approvata da un amministratore diverso attraverso la piattaforma operativa, con esplicita presa d'atto di eventuali migrazioni di database incluse; la promozione in produzione richiede inoltre un'approvazione QA sul rilascio in staging. Ogni insieme di modifiche è tracciabile dal ticket fino alla versione distribuita, e i deployment in produzione effettuati al di fuori della piattaforma operativa vengono rifiutati, salvo il ricorso alla procedura break-glass.
• Le immagini dei container vengono compilate una sola volta e sottoposte a scansione per vulnerabilità note al momento del push nel registro; i tag del registro di produzione sono immutabili (un tag rilasciato non può mai essere sostituito in modo silente) e la produzione utilizza esattamente il digest dell'immagine convalidata in staging — nulla viene ricompilato per la produzione.
• Le modifiche all'infrastruttura seguono lo stesso percorso (Terraform plan sulla pull request, apply al momento del merge), garantendo un registro di audit completo e verificabile delle modifiche in produzione.
• I rilasci possono essere ripristinati per singolo componente; la versione distribuita di ogni componente viene registrata prima di ciascuna promozione.

8. Registrazione dei log, monitoraggio e risposta agli incidenti

• Log centralizzati: i log applicativi e di accesso di ogni servizio vengono inviati a Datadog (sito UE, datadoghq.eu) e ad Amazon CloudWatch; i log applicativi sono conservati per un massimo di 90 giorni. I dati personali e i segreti vengono mascherati nei servizi prima dell'invio dei log a Datadog, e nuovamente al momento della visualizzazione: tramite la nostra piattaforma operativa, il personale diverso dagli amministratori visualizza il contenuto dei log di produzione con i valori personali mascherati in loco, e gli strumenti automatizzati e di IA non ricevono alcun payload di richiesta o risposta, mentre le informazioni necessarie alla diagnosi (messaggi di errore, identificatori delle richieste, codici di stato) restano visibili. Ogni accesso al contenuto dei log di produzione è sottoposto ad audit.
• Audit cloud e rilevamento delle minacce: AWS CloudTrail registra ogni chiamata API di gestione effettuata nell'account di produzione, in tutte le regioni, con convalida dell'integrità dei file di log e archiviazione con versionamento; Amazon GuardDuty analizza continuamente CloudTrail, i VPC Flow Logs e l'attività DNS in ogni regione in cui operiamo alla ricerca di minacce quali l'uso improprio di credenziali, attività di ricognizione e comunicazioni con host noti come malevoli; i rilevamenti sono esaminati dal team operativo.
• Allerta: gli allarmi di CloudWatch su database, cache, bilanciatori di carico, API Gateway ed eventi del ciclo di vita dei task ECS notificano il team operativo tramite SNS; le prestazioni applicative sono monitorate in Datadog; lo stato dell'infrastruttura, le code, i costi e gli avvisi di deprecazione per ciascun ambiente sono consolidati nella console di monitoraggio della piattaforma operativa.
• Pagina di stato pubblica: la disponibilità della piattaforma è monitorata esternamente e pubblicata all'indirizzo https://status.passportscan.net, con comunicazione automatica di incidenti e manutenzioni.
• Risposta agli incidenti: una Procedura di risposta agli incidenti e alle violazioni dei dati documentata definisce livelli di gravità, ruoli ed escalation. Le violazioni di dati personali vengono notificate ai clienti interessati senza ingiustificato ritardo e in ogni caso entro 48 ore, come stabilito nel DPA, e all'autorità di controllo entro 72 ore ove richiesto (art. 33 del GDPR).
• Divulgazione delle vulnerabilità: i ricercatori di sicurezza possono segnalare problemi ai sensi della Vulnerability Disclosure Policy (security@passportscan.net).

9. Continuità operativa e disaster recovery

• L'ambiente di produzione funziona su servizi gestiti AWS distribuiti su tre zone di disponibilità in eu-west-1: lo storage Aurora è replicato sei volte sulle tre zone, i servizi principali eseguono almeno due task distribuiti tra le zone con scalabilità automatica in base al carico, ed ECS sostituisce automaticamente un task guasto in una zona integra dietro i bilanciatori di carico. I deployment utilizzano un circuit breaker che esegue automaticamente il rollback quando una nuova versione non supera i controlli di integrità.
• I database possono essere ripristinati a qualsiasi momento entro la finestra di conservazione di 15 giorni; la procedura di ripristino fa parte dell'esercitazione annuale di disaster recovery.
• Una Business Impact Analysis e un Piano di continuità operativa e disaster recovery definiscono gli obiettivi di ripristino per la piattaforma (recovery time objective inferiore a due ore per il servizio di check-in principale; recovery point objective nell'ordine di minuti grazie al ripristino point-in-time).
• Le dipendenze da terze parti (fornitore cloud, fornitore di identità, fornitore di servizi di pagamento, gestione dei log, protezione dai bot e servizi di comunicazione aziendale) sono valutate nel processo di sicurezza dei fornitori ed elencate nell'Elenco dei sub-responsabili.

10. Sub-responsabili

Le terze parti che trattano dati personali dei clienti per conto di GlobeID sono elencate, con la relativa finalità e il luogo di trattamento, nell'Elenco pubblico dei sub-responsabili disponibile all'indirizzo https://www.passportscan.net/sub-processor/. Le aggiunte vengono notificate ai clienti conformemente al DPA.

11. Responsabilità condivisa

GlobeID è responsabile della sicurezza della piattaforma come descritto sopra. I clienti restano responsabili di: gestire i propri utenti e le proprie credenziali (inclusa l'attivazione dell'MFA), proteggere i dispositivi e le reti utilizzati per accedere alla piattaforma, configurare in modo lecito le opzioni di conservazione e di archiviazione regionale, fornire informative sulla privacy agli ospiti, nonché della sicurezza di qualsiasi PMS o sistema di terze parti da essi collegato.

12. Contatti

Domande e questionari sulla sicurezza: security@passportscan.net Privacy e DPO: privacy@passportscan.net GlobeID Limited, The Black Church, St. Mary's Place, Dublin 7, D07 P4AX, Irlanda (CRO 559612)