Definire il perimetro reale del pagamento
Mappa il percorso dell’acquirente dalla pagina prodotto alla conferma. Segna l’inserimento della carta, i reindirizzamenti, i frame, gli script, le API, i plugin, i tag manager, le CDN e gli account amministrativi che possono influenzarlo. Includi log correlati, strumenti di supporto e analytics. Questo è un record iniziale per il tuo fornitore o valutatore, non una decisione di conformità.
Registra il dominio che serve ogni elemento della pagina di pagamento. PCI SSC dice che l’eleggibilità per SAQ A richiede che tutti gli elementi della pagina di pagamento provengano esclusivamente da fornitori conformi a PCI DSS e che non provengano dal sito del merchant. Per SAQ A-EP, ogni elemento può provenire dal merchant o da un fornitore conforme, ma non da un’altra origine. Restano applicati tutti gli altri criteri.
Un repository può non mostrare le iniezioni del tag manager e le impostazioni di piattaforma. Rivedi script, frame, domini e header in una normale sessione di checkout nel browser.
Controlla log, analytics e workflow di supporto per i campi di pagamento. Non usare mai dati reali di carta in ticket di test o evidenze condivise.
Ridurre l’esposizione con un modello di pagamento spiegabile
Quando praticabile, usa un’integrazione in cui un fornitore conforme a PCI DSS raccoglie i dati della carta anziché la tua applicazione che li riceve o li memorizza. Un reindirizzamento completamente ospitato dal fornitore è spesso più semplice di un modulo personalizzato, ma campi incorporati e iframe possono comunque permettere al tuo sito di influenzare il pagamento. Documenta l’integrazione reale invece di fare affidamento sull’etichetta “ospitato”.
Evita di conservare numeri di conto primari, codici di sicurezza, screenshot di errori di checkout o dettagli di pagamento copiati a meno che un design approvato non lo richieda. La cifratura aiuta a proteggere i dati, ma PCI SSC avverte che la cifratura da sola generalmente non rimuove un ambiente dall’ambito. Conferma token, chiavi, webhook, rimborsi e gestione delle responsabilità con il fornitore e i revisori qualificati.
Conserva la guida di integrazione, le informazioni sulle responsabilità, la documentazione di conformità rilevante e il processo di notifica delle modifiche insieme al record dell’architettura.
Non aggiungere esperimenti di marketing, strumenti di replay, widget di chat o librerie opzionali senza un proprietario nominato e una revisione di ciò che possono accedere.
Controllare script, tag e header
Il codice del browser di terze parti può introdurre cambi non controllati, esecuzione arbitraria di codice e divulgazione ad altre parti. Mantieni un inventario del checkout con il dominio di ciascuno script, lo scopo, il proprietario, l’approvazione e la posizione di caricamento. Includi regole del tag manager e codice caricato dal fornitore, non solo i file nell’albero delle sorgenti.
PCI SSC si concentra su script autorizzati, integrità, monitoraggio delle manomissioni e header HTTP che impattano la sicurezza. Approva una baseline, limita le modifiche, rileva le differenze e indagale. Una Content Security Policy (CSP) può limitare le origini delle risorse. Dove opportuno, testala in modalità report-only prima dell’applicazione. La CSP è difesa in profondità, non un sostituto della scrittura sicura del codice o della revisione.
Subresource Integrity può rifiutare uno script esterno modificato, ma richiede una configurazione cross-origin compatibile e può interrompersi dopo aggiornamenti del fornitore.
Limita i ruoli di pubblicazione, richiedi autenticazione forte, rivedi la capacità di codice personalizzato e conserva una traccia di audit.
Limitare gli accessi e rendere recuperabili le modifiche al checkout
Separa la pubblicazione dei contenuti di routine dal codice del checkout, dall’amministrazione del fornitore di pagamento, dall’hosting, dal DNS e dalla gestione dei tag. Usa account nominativi, il principio del privilegio minimo e l’autenticazione a più fattori dove supportata. Rivedi gli accessi dopo i cambi ruolo e rimuovi ex dipendenti, fornitori e agenzie. L’esatta applicabilità di PCI DSS dipende dall’ambiente, ma ridurre privilegi condivisi e permanenti diminuisce il rischio.
Usa un processo di rilascio per il checkout: proprietario nominato, revisione, test quando possibile, metodo di rollback e controllo post-rilascio nel browser. Testa i percorsi di successo e di errore, i reindirizzamenti e il comportamento mobile. Status Is UP supporta la prontezza proattiva al lancio, l’ottimizzazione delle prestazioni e la pianificazione del rollback attorno ai rilasci; non determina la conformità PCI DSS.
Conserva credenziali, codici di backup e istruzioni di rollback in sistemi approvati con controllo degli accessi, mai in ticket, screenshot o repository pubblici.
Dopo il rilascio, confronta script, domini e header visibili dal browser con l’inventario approvato.
Aggiorna lo stack e verifica il risultato
Mantieni un inventario della piattaforma di commercio, plugin, temi, componenti server, librerie, SDK di pagamento, template dei tag e servizi che influenzano il checkout. Iscriviti alle comunicazioni critiche dei fornitori. NIST descrive la gestione delle patch come l’identificazione, la prioritarizzazione, l’acquisizione, l’installazione e la verifica degli aggiornamenti. Registra la modifica, testa il percorso di pagamento e conferma ciò che è stato distribuito.
Stabilisci una via di emergenza per problemi ad alto rischio e una finestra di manutenzione per i cambi routinari. Prioritizza i componenti di checkout esposti, ma non applicare patch ciecamente in produzione e rompere i pagamenti. Usa un approccio di rollback testato e le linee guida del fornitore per i rilasci. Un componente obsoleto senza proprietario noto è un rischio da risolvere.
Conserva insieme l’avviso, la decisione sul rischio, il risultato del test, il record di deployment e la verifica finale.
Conservare evidenze e usare aiuti qualificati
Conserva diagrammi, informazioni sulle responsabilità del fornitore, motivazione dell’eleggibilità SAQ, inventari di script e header, revisioni degli accessi, approvazioni, risultati dei test, modifiche e contatti dei fornitori in una posizione controllata. Aggiornale quando cambiano architettura, proprietà, script o fornitori. Le evidenze dovrebbero aiutare un revisore autorizzato senza esporre dati delle carte, segreti o record dei clienti.
Il tuo acquirer o il brand di pagamento definisce le aspettative di validazione applicabili. PCI SSC identifica i Qualified Security Assessor come organizzazioni indipendenti qualificate a eseguire valutazioni PCI DSS e gli Approved Scanning Vendor come fornitori qualificati di scansione esterna sotto i requisiti applicabili. Cerca aiuto qualificato per checkout personalizzati, ambito non chiaro, sospette compromissioni o selezione dell’SAQ.
Conserva il modello di checkout, i proprietari tecnici, i contatti di escalation, la data dell’ultima revisione e i link alle evidenze insieme.