Conformità PCI DSS per sistemi di trasferimento file sicuri

PCI DSS 4.0 (obbligatorio dal 31 marzo 2025) impone 12 requisiti a qualsiasi sistema che conserva, elabora o trasmette dati del titolare della carta. Per i sistemi di trasferimento file, i controlli chiave sono: Requisito 3 (proteggere i dati account archiviati con AES-256 o superiore e adeguata gestione delle chiavi), Requisito 4 (cifrare le trasmissioni con TLS 1.2 come minimo, TLS 1.3 consigliato), Requisito 8 (MFA per tutti gli accessi all'ambiente dei dati del titolare, il CDE), Requisito 10 (registrare ogni accesso al CDE per almeno 12 mesi) e Requisito 12 (governance e gestione dei fornitori di servizi). Un sistema di trasferimento file che tocca anche un solo .csv contenente PAN rientra nell'ambito di applicazione completo dello standard.

Cosa determina l'applicabilità del PCI DSS

Il PCI DSS si applica a qualsiasi componente di sistema che elabora, conserva o trasmette dati del titolare della carta (CHD) o dati di autenticazione sensibili (SAD). Il CHD comprende il numero di conto primario (PAN), il nome del titolare, la scadenza e il codice di servizio. Il SAD include il CVV, i dati di traccia completi e i PIN — mai conservati dopo l'autorizzazione. Uno strumento di trasferimento file che riceve da una banca partner un foglio di calcolo con PAN rientra nell'ambito. Uno strumento usato per inviare un report riepilogativo con sole ultime quattro cifre, no. I PAN tokenizzati o troncati (massimo prime sei e ultime quattro cifre) sono fuori scope. La riduzione del perimetro è l'attività PCI con il ROI più alto: tokenizza il prima possibile.

Le novità di PCI DSS 4.0 da conoscere

La versione 4.0 (pubblicata a marzo 2022, obbligatoria da aprile 2024 con requisiti a scadenza futura fino a marzo 2025) ha introdotto: approccio personalizzato (alternativa all'approccio definito, che richiede un'analisi del rischio mirata), requisiti MFA estesi a tutti gli accessi al CDE (non solo gli admin), regole password più stringenti (12+ caratteri da gennaio 2025 per il requisito 8.3.6), maggiore frequenza di molte attività (scansioni trimestrali, penetration test annuali) e requisiti espliciti per le pagine di pagamento lato client (6.4.3 e 11.6.1 per il rilevamento di skimming). I sistemi di trasferimento file risentono soprattutto dei requisiti 8.3.6 e 10: autenticazione più rigorosa e logging più dettagliato.

Requisito 3: proteggere i PAN archiviati

Il Requisito 3 vieta la conservazione del SAD dopo l'autorizzazione e impone una protezione forte per i PAN archiviati. Metodi accettabili: hash one-way con salt robusto (SHA-256 con salt per-PAN di almeno 128 bit), troncamento (non più di prime sei e ultime quattro cifre), token indice con pad conservati in modo sicuro, oppure crittografia forte con gestione delle chiavi associata. Per i sistemi di trasferimento file, la soluzione più pulita è la tokenizzazione prima che il file entri nella pipeline: usa un servizio di tokenizzazione certificato PCI (Braintree, Stripe Radar, VGS) e trasferisci solo token. Se i PAN grezzi devono transitare, usa AES-256-GCM con chiavi in un HSM FIPS 140-2 Livello 2+.

Requisito 4: crittografia della trasmissione

Il punto 4.2.1 richiede crittografia forte per la trasmissione di PAN su reti aperte e pubbliche. "Crittografia forte" secondo il glossario PCI fa riferimento a NIST SP 800-57: AES-256 per la simmetrica, RSA 3072+ per l'asimmetrica, TLS 1.2+ per il trasporto. Disabilita completamente TLS 1.0 e 1.1 (deprecati nel 2018 e vietati dalla versione 4.0). Usa SSL Labs o Qualys SSL Test per verificare la configurazione ogni trimestre. La posta elettronica è esplicitamente problematica: il 4.2.2 richiede che i PAN inviati tramite tecnologie di messaggistica per l'utente finale siano resi illeggibili prima della trasmissione. Un PAN in chiaro in una email non supera il PCI. Invia invece un link sicuro a un download cifrato.

Requisito 8: MFA in tutto il CDE

I punti 8.4 e 8.5 del PCI DSS 4.0 richiedono l'MFA per: (a) tutti gli accessi non console al CDE da parte del personale amministrativo e (b) tutti gli accessi remoti al CDE da parte di qualsiasi persona. "Tutti" è la parola chiave rispetto alle versioni precedenti — terzisti, auditor, utenti del supporto, non solo admin. Fattori MFA accettabili: qualcosa che sai (password), qualcosa che hai (token hardware, app su telefono), qualcosa che sei (biometrico). I due fattori devono essere indipendenti; due password non bastano. Le chiavi hardware (YubiKey, Feitian) su FIDO2 soddisfano il requisito 8.5 in modo pulito. L'OTP via SMS è sconsigliato: il NIST SP 800-63B ne ha ridotto il livello di garanzia nel 2016.

Requisito 10: logging e conservazione per 12 mesi

Il 10.2 richiede log di audit che registrino: accesso individuale ai CHD, azioni degli utenti con privilegi admin, accesso alle tracce di audit, tentativi di accesso logico non validi, meccanismi di identificazione e autenticazione, inizializzazione dei log di audit, creazione ed eliminazione di oggetti a livello di sistema. Il 10.5.1 richiede la conservazione per almeno 12 mesi con tre mesi immediatamente disponibili. Il 10.7 ha aggiunto l'obbligo di rilevare e rispondere ai guasti dei controlli di sicurezza critici entro 24 ore. Per i sistemi CDE di trasferimento file, usa un archivio di log immutabile: AWS CloudWatch Logs con CloudTrail, Azure Monitor con policy immutabili, o Splunk con configurazione write-once a livello di indexer.

Requisito 12: governance dei fornitori di servizi

Il 12.8 copre la gestione dei fornitori di servizi. Mantieni un elenco dei fornitori con descrizione dei servizi e dell'ambito PCI DSS, stipula un accordo scritto con ciascuno che riconosca la loro responsabilità nella sicurezza dei CHD, documenta quali requisiti PCI sono gestiti da ognuno e monitora annualmente lo stato di conformità. Per i fornitori di trasferimento file, richiedi l'Attestation of Compliance (AOC) PCI DSS. Livelli: i fornitori di Livello 1 (che conservano/elaborano/trasmettono 300k+ transazioni/anno) sono sottoposti a valutazione annuale in loco; i fornitori più piccoli possono auto-valutarsi. I principali vendor di trasferimento file nel settore dei pagamenti (Globalscape EFT, IBM Sterling) detengono AOC di Livello 1.

Riduzione del perimetro tramite crittografia lato client

Se il tuo fornitore di trasferimento file non vede mai i PAN in chiaro perché la cifratura avviene nel client prima del caricamento, il fornitore potrebbe essere fuori dall'ambito PCI. Le linee guida PCI su questo punto sono articolate: le PCI SSC Cloud Computing Guidelines (2019) riconoscono la riduzione del perimetro tramite crittografia a condizione che (a) il cloud provider non abbia accesso alle chiavi, (b) il cliente detenga in modo dimostrabile la custodia delle chiavi e (c) la crittografia sia forte. Servizi con architettura AES-256-GCM lato client — HexaTransfer e simili — possono fungere da canali di trasferimento al di fuori del CDE del commerciante se implementati correttamente. Documenta l'architettura nel tuo System of Record.

Penetration test e gestione delle vulnerabilità

Il 11.4 richiede penetration test annuali e dopo modifiche significative. Per i sistemi di trasferimento file, l'ambito del test comprende: gli endpoint di upload e download, il flusso di autenticazione, il segmento di rete CDE e qualsiasi API usata per le operazioni sui file. Affidati a un tester certificato CREST o approvato PCI. Il 11.3 richiede scansioni trimestrali delle vulnerabilità da parte di un Approved Scanning Vendor (ASV) per i componenti esposti all'esterno. Le scansioni interne si eseguono autonomamente ogni trimestre. Rimedi i risultati critici e gravi entro 30 giorni; le criticità minori secondo la tua analisi del rischio.

Segmentazione di rete e perimetro del CDE

La segmentazione di rete isola il CDE dalle reti non-CDE, riducendo il perimetro. La segmentazione deve essere verificata annualmente (11.4.5) con test che dimostrano l'isolamento anche in condizioni di guasto. Per un sistema di trasferimento file che gestisce PAN, segmenta la pipeline di upload, l'archivio oggetti cifrato, gli endpoint KMS e la pipeline di logging in un VPC dedicato senza connettività est-ovest verso le reti aziendali generali. Usa subnet private, security group con default-deny e VPC endpoint verso i servizi cloud. Documenta la segmentazione nei diagrammi di rete come parte delle prove PCI.

Controlli compensativi e approccio personalizzato

L'approccio personalizzato del PCI DSS 4.0 consente controlli alternativi se soddisfano l'obiettivo di un requisito standard. Richiede un'analisi del rischio mirata (TRA) che documenti il rischio, il controllo personalizzato, come soddisfa l'obiettivo e come viene testato. Per i sistemi di trasferimento file, l'approccio personalizzato emerge spesso nella gestione delle chiavi crittografiche: un'organizzazione potrebbe usare una configurazione HSM non standard con sicurezza equivalente. L'approccio personalizzato richiede il via libera del QSA; non è un esercizio fai-da-te. L'approccio definito è più semplice; usa quello personalizzato solo dove il definito non si adatta alla tecnologia.

Prepararsi alla valutazione

Una valutazione QSA per un sistema di trasferimento file comprende: interviste di definizione del perimetro (1-2 giorni), campionamento delle prove (2-3 settimane), interviste ai responsabili dei controlli (3-5 giorni), test tecnici (1 settimana) e redazione del report (2-4 settimane). Prepara: diagrammi di rete, diagrammi del flusso dei dati, inventario dei sistemi CDE, campioni di revisione degli accessi, report di scansione trimestrali, report annuale del penetration test, procedure di gestione delle chiavi, piano di risposta agli incidenti con prove di test e lista dei fornitori con AOC. Prevedi un budget di 50.000-150.000 € per il solo incarico QSA.

La conformità PCI a livello di trasferimento si riduce principalmente alla riduzione del perimetro e a una buona igiene crittografica. Tokenizza i PAN il prima possibile. Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.