PCI DSS per una directory di annunci per adulti: cosa decide davvero quanto lavoro di conformita' ti tocca

Farsi accettare da un sistema di pagamento per un sito di annunci per adulti e' gia' una battaglia a se', e una volta vinta quasi tutti gli operatori pensano che la parte difficile sia finita. Non e' cosi'. Il conto che finalmente dice di si' porta con se' un obbligo permanente che non ha niente a che vedere con la verifica dell'eta', la moderazione o le regole imposte da uno stato o da un motore di ricerca. E' uno standard di sicurezza scritto dai circuiti delle carte stessi, e si applica dal momento in cui un numero di carta tocca una qualunque parte della tua attivita', per quanto piccola.

Quello che segue non e' una consulenza legale, e chiunque tocchi davvero i dati di una carta dovrebbe farsi rivedere il caso da un Qualified Security Assessor. E' la forma di una decisione che quasi nessun operatore si accorge di aver preso, perche' a prenderla per lui e' di solito uno sviluppatore che vuole costruire una pagina di pagamento piu' curata, molto prima che la domanda arrivi alla parte commerciale dell'azienda.

La regola che hai firmato senza leggerla

Il PCI DSS, lo standard di sicurezza dei dati dell'industria delle carte di pagamento, non e' una norma di legge e nessuna agenzia statale lo fa rispettare. E' un obbligo contrattuale scritto nell'accordo che ogni esercente firma con una banca acquirer o un intermediario di pagamento, e nasce dal fatto che Visa, Mastercard e gli altri circuiti impongono ai loro acquirer di trasferirlo a ogni attivita' che memorizza, elabora o trasmette un numero di carta. Lo stesso organismo che gestisce lo standard e' esplicito: si applica a chiunque tratti dati di una carta, che lo faccia direttamente o tramite terzi, senza eccezioni legate alla dimensione o al volume di transazioni.

E' una domanda diversa da quella che un fornitore di pagamenti fa prima di aprirti un conto. Cosa vuole sapere un fornitore prima di accettare di lavorare con te riguarda l'attivita' in se': chi la possiede, come vengono controllati gli annunci, come vengono verificati gli inserzionisti. Il PCI DSS comincia dopo che quel conto esiste, e non finisce davvero mai. Si rinnova ogni anno finche' l'attivita' accetta carte, e cambia forma ogni volta che cambia il modo in cui le carte vengono accettate.

Il volume delle transazioni conta, ma non nel modo in cui si immagina di solito. Determina un "livello" dell'esercente, da uno a quattro, e quel livello decide come viene verificata la conformita': un piccolo operatore compila un questionario di autovalutazione, un'attivita' che elabora milioni di transazioni l'anno ha bisogno di un revisore esterno. Quello che il volume non fa e' esentare nessuno. Un esercente ad alto rischio che elabora poche centinaia di transazioni al mese e' vincolato esattamente allo stesso standard di fondo di una grande catena, solo verificato con un modulo piu' corto.

La decisione unica che ti definisce il carico per anni

Il modulo che si applica a una determinata attivita' non si sceglie liberamente. E' determinato interamente da un fatto tecnico: il numero di carta, in qualche punto del percorso, passa o no da un sistema controllato dall'operatore. Mandare il cliente su una pagina di pagamento ospitata dal fornitore, o inserire un iframe di pagamento correttamente isolato fornito da quel fornitore, fa si' che il numero di carta non tocchi mai il server dell'operatore. Costruire invece un modulo di pagamento che raccoglie il numero di carta e lo invia al proprio backend prima di inoltrarlo, anche solo per un istante, lo fa toccare.

Questo singolo fatto separa il questionario piu' leggero da quello piu' pesante di un ordine di grandezza. Il percorso completamente esternalizzato, noto come SAQ A, arriva a circa venti requisiti. Il percorso in cui la pagina dell'operatore consegna o influenza parte del processo di pagamento, anche senza toccare direttamente il numero di carta, come un modulo ospitato in proprio i cui campi inoltrano i dati altrove, finisce nel SAQ A-EP, vicino ai duecento requisiti. Memorizzare, elaborare o trasmettere davvero i dati della carta sui propri sistemi finisce nel SAQ D, che copre l'intero insieme di controlli dello standard: cifratura, gestione delle chiavi, segmentazione della rete, registrazione degli accessi, controllo degli accessi, tutto quanto, per diverse centinaia di voci.

Vale la pena chiarire subito un equivoco comune. Usare un iframe fornito da un provider conforme non fa automaticamente scivolare un sito nella fascia piu' pesante del SAQ A-EP: un iframe di terzi correttamente isolato, in cui la pagina dell'operatore non contribuisce con nessun codice capace di vedere o toccare i campi di pagamento, resta in genere ammesso al percorso leggero del SAQ A. Cio' che fa salire un'attivita' di fascia e' il codice dell'operatore che arriva dentro quella pagina, che sia un modulo costruito in proprio, uno script aggiunto per "migliorare" il pagamento, o un'integrazione vecchio stile in cui il browser invia i dati della carta attraverso codice scritto dall'operatore invece che dal fornitore.

Cosa richiede ancora il percorso leggero, da un anno a questa parte

Vale la pena correggere una convinzione che una volta era vera e ora non lo e' piu'. Gli operatori che hanno scelto la via esternalizzata hanno imparato, giustamente, che questo li teneva fuori dalla maggior parte dell'onere tecnico dello standard, e alcuni pensano ancora che questo significhi nessun controllo di sicurezza ricorrente. Dalla versione 4.0.1 del PCI DSS, esigibile dall'aprile 2025, non e' piu' cosi'. Il SAQ A oggi include un requisito di scansioni trimestrali di vulnerabilita' esterne da parte di un Approved Scanning Vendor, eseguite sul sito dell'operatore stesso, quello che ospita il reindirizzamento o l'iframe, anche se quel sito non vede mai un numero di carta.

Il ragionamento dietro il cambiamento e' semplice una volta detto ad alta voce: la pagina che manda il cliente verso il fornitore di pagamenti resta comunque parte della superficie d'attacco. Una pagina di pagamento compromessa puo' reindirizzare un cliente verso un posto diverso dal vero fornitore di pagamenti, oppure caricare uno script malevolo che legge i dati della carta direttamente dal browser prima ancora che l'iframe si carichi, uno schema d'attacco che ha gia' colpito esercenti veri. Dalla stessa logica derivano due requisiti collegati: l'operatore deve tenere un inventario di ogni script che gira sulla pagina di pagamento, e rilevare modifiche non autorizzate al contenuto di quella pagina, obblighi che valgono nel SAQ A proprio perche' la pagina di pagamento e' dell'operatore, anche quando il numero di carta non lo e' mai stato.

Quello che il percorso leggero evita ancora, ed e' questo il divario che conta davvero, e' il test di intrusione annuale richiesto dal SAQ A-EP e dal SAQ D, insieme ai controlli interni profondi che quelle fasce richiedono: cifrare i dati di carta memorizzati, gestire le chiavi che li proteggono, segmentare la rete intorno a ogni sistema che li tocca, registrare in dettaglio ogni accesso. Scegliere il percorso esternalizzato non significa niente lavoro di sicurezza. Significa poche ore di scansioni e di igiene degli script all'anno invece di un programma di sicurezza permanente costruito intorno a dati che altrimenti l'attivita' si troverebbe a memorizzare.

Cosa costa sbagliare questa parte

Niente di tutto questo viene fatto rispettare da un tribunale o da un regolatore, ed e' anche per questo che e' facile sottovalutarlo. I circuiti multano la banca acquirer quando un esercente del suo portafoglio non e' conforme, e l'acquirer scarica quel costo direttamente sull'esercente attraverso il contratto, di solito partendo da cifre contenute e salendo quanto piu' a lungo dura la non conformita'. Non esiste una tabella pubblica che fissi queste cifre per ogni acquirer, perche' l'accordo sta dentro contratti privati e non regole pubbliche, ma la direzione e' costante: la multa cresce col tempo, non con quanto bene l'attivita' spiega il ritardo.

Questo e' il costo del semplice non essere conformi. Una violazione vera e propria, in cui numeri di carta memorizzati vengono esposti perche' un operatore stava trattando dati che il SAQ A era pensato per evitargli, e' una spesa di tutt'altro ordine. I circuiti possono imporre un'indagine forense da parte di una societa' specializzata prima che chiunque sia autorizzato a riaprire il conto, pagata dall'esercente indipendentemente dall'esito, e le carte coinvolte vengono riemesse a spese dell'esercente. Un'assicurazione per la responsabilita' informatica raramente copre questo tipo di buco per un'attivita' come questa, dato che i contenuti per adulti compaiono nell'elenco dei settori esclusi da piu' di una polizza cyber di grandi compagnie: il che significa che l'esposizione descritta qui e' molto spesso non assicurata, non semplicemente costosa.

La conseguenza piu' duratura non e' la multa e nemmeno l'indagine. E' la decisione dell'acquirer, una volta che una violazione o una non conformita' prolungata risulta agli atti, di chiudere il conto invece di continuare ad assumersi il rischio, e di registrare quella chiusura in un modo che gli altri acquirer possono vedere prima di aprirne uno nuovo. Un rapporto con un fornitore di pagamenti che ha richiesto mesi per essere costruito la prima volta e' molto piu' difficile da ricostruire con quella storia attaccata all'attivita'.

Cosa fare questo mese

Comincia scoprendo, per iscritto, quale questionario si applica davvero oggi. Chiedilo direttamente al fornitore di pagamenti invece di dare per scontato la risposta: conferma se il pagamento attuale e' un reindirizzamento, un iframe correttamente isolato, oppure qualcosa che tocca il server dell'operatore in un qualunque punto del percorso, perche' la risposta a questa domanda e' l'intero programma di conformita' racchiuso in una frase. Fattelo scrivere in un'email, non al telefono, perche' e' il punto di riferimento per ogni decisione che segue.

Tratta ogni richiesta di cambiare come vengono raccolte le carte come una questione di conformita' prima ancora che una questione di design. Uno sviluppatore che vuole costruire un modulo di pagamento personalizzato perche' la pagina ospitata sembra generica, o che aggiunge una chat o uno script di analisi alla stessa pagina che ospita l'iframe di pagamento, sta prendendo una decisione PCI, che qualcuno la inquadri cosi' oppure no. Rivedi quel tipo di cambiamento prima che vada online, non dopo che una scansione lo segnala.

Presenta l'attestazione annuale nei tempi previsti e conserva i risultati di ogni scansione trimestrale, anche quelle noiose in cui non cambia niente, perche' un'attestazione scaduta si legge, agli occhi di un acquirer, esattamente come non averla mai presentata. Niente di tutto questo e' difficile quando l'architettura di base e' quella giusta. Un pagamento costruito una volta intorno a una pagina ospitata o a un iframe correttamente isolato trasforma tutto questo in un pomeriggio di scartoffie, da ripetere una volta l'anno. Un pagamento che ha lentamente preso l'abitudine di toccare i dati della carta trasforma lo stesso obbligo in un programma di sicurezza permanente che l'attivita' non aveva mai pianificato di gestire.