Il Payment Card Industry Data Security Standard (PCI DSS) richiede alle attività di proteggere i dati dei titolari di carta quando vengono memorizzati e quando si spostano attraverso una rete. Ciò significa richiedere una crittografia forte, oltre a una serie di regole di supporto che coprono tutto, dalla robustezza del certificato alla generazione, conservazione e al ritiro delle chiavi crittografiche.

Soddisfare questi requisiti di crittografia PCI non influisce solo sul tuo elenco di controllo per la conformità. Può aiutarti a ridurre la superficie di attacco e a determinare l'esposizione della tua attività in caso di violazione. Il costo medio di una violazione dei dati ha raggiunto 4,44 milioni di dollari a livello globale nel 2025, il che sottolinea l'importanza di proteggere i record sensibili. Di seguito, spieghiamo cosa richiede effettivamente il PCI DSS per la crittografia, quali algoritmi e protocolli soddisfano oggi questi requisiti e come la crittografia interagisce con le strategie correlate, come la tokenizzazione e la segmentazione della rete.

In sintesi

• Il PCI DSS richiede una crittografia forte per i dati dei titolari di carta sia inattivi che in transito, con Advanced Encryption Standard (AES) con chiave a 256 bit e Transport Layer Security (TLS) 1.2 o superiore come impostazione di base accettata.

• Poiché la crittografia e la tokenizzazione risolvono problemi diversi, puoi ridurre l'ambito della conformità PCI combinando la crittografia da punto a punto (P2PE) con la tokenizzazione.

• La scarsa gestione delle chiavi è uno dei motivi più comuni per cui le attività falliscono la valutazione del PCI DSS, nonostante la solidità degli algoritmi crittografici sottostanti.

Quali sono i requisiti di crittografia PCI?

Le regole di crittografia del PCI DSS sono definite nel Requisito 3 dell'elenco di controllo della conformità, che copre i dati dei titolari di carta archiviati, e nel Requisito 4, che copre i dati in movimento attraverso le reti. Gli auditor PCI verificano entrambe queste aree durante la valutazione della gestione dei dati delle carte.

In base al Requisito 3, se si archivia il numero di conto principale (PAN), è necessario renderlo illeggibile ovunque compaia, sia in un database, in un file di log o in un backup. Sebbene la crittografia forte sia il principale metodo di protezione, anche il troncamento e l'hashing sono opzioni, in particolare per mascherare i PAN sulle ricevute o sulle schermate rivolte ai clienti. Il Requisito 4 stabilisce che tutti i dati delle carte che attraversano reti pubbliche e aperte devono essere crittografati da un'estremità all'altra. Non sono previste eccezioni per comodità interne o ambienti preesistenti antecedenti allo standard.

I dati di autenticazione sensibili (SAD) adottano un approccio diverso che include l'intera striscia magnetica o i dati del chip, il codice di verifica della carta (CVV) e il blocco PIN. Il PCI DSS non consente di memorizzare nessuna di queste informazioni dopo il completamento dell'autorizzazione, indipendentemente dal loro stato di crittografia.

Quali standard e protocolli crittografici approva il PCI DSS per la crittografia?

Il PCI DSS richiede una "crittografia forte", definita dal PCI Security Standards Council come qualsiasi metodo che fornisca almeno 112 bit di forza effettiva della chiave. In pratica, questa definizione rimanda a un breve elenco di scelte accettate:

• Dati inattivi: l'AES-256 è lo standard comune. Supera la soglia di robustezza ed è ampiamente supportato da fornitori di servizi cloud e infrastrutture di pagamento. Il Triple DES (3DES) è tecnicamente ancora qualificato in alcune configurazioni, ma il PCI Security Standards Council lo ha segnalato per il ritiro, e la maggior parte dei nuovi sistemi lo ignora del tutto.

• Crittografia asimmetrica: utilizzata per lo scambio di chiavi simmetriche o la firma di certificati, in genere indica il Rivest-Shamir-Adleman (RSA) a 2048 bit o superiore, o la crittografia a curva ellittica (ECC) a 224 bit o superiore.

• Dati in transito: il TLS 1.2 è il livello di base, con il TLS 1.3 sempre più considerato l'impostazione predefinita in ambito pratico. L'SSL, in ogni sua versione, e le prime versioni TLS (1.0 e 1.1) sono esplicitamente vietate.

• Suite di cifratura: le suite qualificanti non devono presentare vulnerabilità note; ciò esclude la RC4 (Rivest Cipher 4) e qualsiasi crittografia di tipo export rimasta in configurazioni precedenti.

• Robustezza del certificato: i certificati per il pubblico devono avere un RSA a 2048 bit o superiore, date di scadenza in vigore ed essere emessi da un'autorità di certificazione attendibile.

• Negoziazione del protocollo: i server devono rifiutare i tentativi di connessione che ripiegano su versioni del protocollo non consentite anziché autorizzarli in silenzio.

In che modo la crittografia riduce l'ambito di conformità PCI?

In termini di PCI DSS, per ambito di conformità si intendono tutti i sistemi che archiviano, elaborano o trasmettono dati dei titolari di carta, oltre a qualsiasi elemento connesso a tali risorse che potrebbe comprometterne la sicurezza. Questo è noto collettivamente come ambiente dei dati del titolare della carta (CDE).

Se un sistema gestisce i dati del titolare della carta crittografati senza accedere ai mezzi per decrittografarli, il PCI Security Standards Council lo considera fuori ambito o almeno in una categoria ad ambito ridotto. È qui che entra in gioco il P2PE. Una soluzione P2PE certificata PCI crittografa i dati della carta nel punto di interazione, all'interno di un hardware validato. La decrittazione è limitata all'ambiente sicuro del fornitore della soluzione P2PE, anziché all'infrastruttura dell'attività.

Una soluzione P2PE validata in genere si qualifica per un Questionario di autovalutazione P2PE (SAQ), uno dei SAQ PCI più brevi, poiché il P2PE restringe in modo sostanziale l'ambito della valutazione. La segmentazione lo restringe ulteriormente. Quando i sistemi di dati delle carte sono isolati sul proprio segmento di rete, separati dai sistemi aziendali generali, i sistemi che non vedono mai i dati dei titolari di carta possono essere tenuti del tutto fuori dalla valutazione.

Crittografia o tokenizzazione: quale strategia soddisfa meglio le tue esigenze di crittografia PCI?

La crittografia trasforma il PAN in testo cifrato illeggibile, ma il numero originale esiste ancora da qualche parte. Chiunque possieda la chiave giusta può invertire il processo. La tokenizzazione rimuove completamente il PAN dall'ambiente dell'attività e lo sostituisce con un token che non ha alcuna relazione matematica con il numero originale e nessun valore in caso di furto.

Quando è necessario fare riferimento a un metodo di pagamento del cliente dopo la transazione iniziale, come nel caso degli abbonamenti, dei metodi di pagamento salvati o del checkout con un solo clic, la tokenizzazione fa la differenza. Se un PAN crittografato viene archiviato internamente, l'utente è ancora in possesso di un numero di carta completo e di tutto ciò che ne consegue, compresi i compiti di gestione delle chiavi, l'ambito di controllo ampliato e l'esposizione in caso di compromissione della chiave associata. Se invece memorizzi un token generato e conservato da un fornitore di servizi di pagamento come Stripe, il valore sensibile non toccherà mai i tuoi sistemi. Molte configurazioni combinano le due cose, utilizzando la tokenizzazione per tutto ciò che viene archiviato a lungo termine e la crittografia per tutto ciò che si sposta attraverso una rete.

Perché la gestione delle chiavi è una parte trascurata della crittografia PCI?

La crittografia dipende dalla protezione delle sue chiavi, ma spesso queste pratiche vengono trascurate. Fai attenzione a quanto segue:

• Condivisione della conoscenza e doppio controllo: una chiave crittografica completa non deve essere accessibile a una sola persona. Suddividendo i componenti delle chiavi tra più persone e richiedendo a più persone di ricostruire una chiave, si evita che un singolo individuo possa compromettere l'ambiente di sua iniziativa.

• Archiviazione sicura delle chiavi: le chiavi devono essere archiviate separatamente dai dati che proteggono, in genere in un modulo di sicurezza hardware (HSM) o in un sistema di gestione delle chiavi equivalente; non devono essere conservate nello stesso database o file system in cui sono memorizzati i valori crittografati.

• Periodi di crittografia definiti: per ogni chiave occorre documentare la durata utile, al termine della quale verrà ritirata e sostituita, in base a fattori quali la quantità di dati che protegge e la frequenza di utilizzo.

• Responsabilità dei custodi delle chiavi documentate: le procedure scritte devono individuare chi è responsabile delle attività di gestione delle chiavi; tali custodi devono assumersi formalmente questa responsabilità.

In base al PCI DSS 4.0, le attività devono rivedere la propria architettura crittografica almeno una volta ogni 12 mesi per confermare che gli algoritmi, i protocolli e le lunghezze delle chiavi utilizzati soddisfino ancora gli standard correnti e non siano diventati obsoleti.

Cosa succede se la tua attività non soddisfa i requisiti di crittografia PCI?

Il mancato rispetto dei requisiti di crittografia del PCI DSS cambia ciò che accade prima e dopo una violazione. Prima di qualsiasi incidente, la non conformità emerge nel processo di revisione annuale. Le banche acquirenti e i circuiti delle carte di credito potrebbero segnalare un'attività come non conforme, incidendo sulla sua capacità di continuare a elaborare pagamenti con carta e richiedendo un monitoraggio più attento o ulteriori requisiti di revisione in futuro.

Le conseguenze si aggravano se si verifica una violazione e un'indagine scopre che tali controlli non erano stati soddisfatti in quel momento. In genere è richiesta un'indagine forense dopo una violazione confermata che coinvolge i dati dei titolari di carta. Esaminerà nello specifico se il PAN era stato adeguatamente crittografato durante l'archiviazione e il transito. In caso contrario, la responsabilità non sarà condivisa con il fornitore di servizi di pagamento o con la banca acquirente, ma si sposterà maggiormente sull'attività.

Può essere difficile ricostruire la fiducia con una banca acquirente o un fornitore di pagamenti dopo un risultato di questo tipo. Poiché i fallimenti crittografici tendono anche a far emergere altri punti deboli nella gestione dei dati interni, è probabile che una banca non si accontenti della correzione di un singolo controllo isolato quando ha riscontrato lacune in altri.

In che modo Stripe Payments può essere d'aiuto

Stripe Payments offre una soluzione di pagamento unificata e globale che aiuta qualsiasi attività, dalle start-up in fase di espansione alle multinazionali, ad accettare pagamenti online, di persona e in tutto il mondo.

Con Stripe Payments puoi:

• Ottimizza l'esperienza di checkout: crea un'esperienza cliente senza attriti e risparmia tempo di sviluppo con le interfacce utente predefinite, l'accesso a oltre 125 metodi di pagamento e Link, un wallet integrato in Stripe.

• Espanderti più rapidamente in nuovi mercati: raggiungi clienti in tutto il mondo e riduci le complessità e i costi della gestione multivaluta con opzioni di pagamento transfrontaliere, disponibili in 195 Paesi e in oltre 135 valute.

• Unificare i pagamenti di persona e online: crea un'esperienza di commercio unificata su canali online e di persona per personalizzare le interazioni, premiare la fedeltà e aumentare i ricavi.

• Migliorare le prestazioni dei pagamenti: aumenta i ricavi con una gamma di strumenti di pagamento personalizzabili e facili da configurare, che includono anche la protezione antifrode non basata su codice e funzionalità avanzate per migliorare le percentuali di autorizzazione.

• Operare più velocemente con una piattaforma flessibile e affidabile per la crescita: utilizza una piattaforma progettata per crescere insieme a te, con tempi di operatività del 99,999% e un'affidabilità leader nel settore.

Scopri di più su come Stripe Payments può supportare i tuoi pagamenti online e di persona oppure inizia oggi stesso.