Come garantire che il processo di distribuzione dell'ambiente di produzione sia conforme allo standard PCI quando è necessario eseguire aggiornamenti del codice in tempo reale?

Question

Come garantire che il processo di distribuzione dell'ambiente di produzione sia conforme allo standard PCI quando è necessario eseguire aggiornamenti del codice in tempo reale?

#1 da (4 voti)
#2 da (0 voti)

6

Nella pianificazione della fase successiva della nostra piattaforma, sto cercando di garantire che il processo di implementazione della produzione sia conforme allo standard PCI.

Abbiamo una piattaforma centrale che funge da CMS, che serve contenuti personalizzati basati su un tipo di evento, che risiederà in un server / ambiente IIS consolidato.

Ogni nuovo evento ha una schermata iniziale di base e un nome di dominio personalizzato, ad esempio www.myevent1.com, www.myevent2.com, ecc.

Il problema è che avremo bisogno di aggiungere nuovi nomi di dominio frequentemente. Essendo conformi allo standard PCI, non possiamo avere sviluppatori che accedono ai server di produzione.

Gli stati della PCI-DSS 6.4:

A separation of duties between personnel that are assigned to the development/test environments and those persons assigned to the production environment.

Sto cercando di mantenere la separazione delle attività per specifiche di conformità.

Quindi, i miei pensieri erano di mantenere il server CMS così com'è, completamente potenziato, nessun accesso per gli sviluppatori. Quindi disporre di un server IIS secondario in cui gli sviluppatori possono aggiungere nuovi domini in base alle esigenze e caricare le pagine splash statiche collegate al contenuto CMS.

Pensieri?

- UPDATE -

Utilizzeremo la conformità al livello 4 PCI-DSS, quindi non avremo dati sui titolari di carta sui nostri server. Il processore di pagamento avrà queste informazioni.

cms iis pci-dss

posta ElHaix 29.05.2017 - 22:52

fonte

2 risposte

Leggi altre domande sui tag cms iis pci-dss

In che modo il recupero della cronologia chat di WhatsApp funziona insieme al loro meccanismo di crittografia? Le istruzioni AES-NI accelerano sia AES-128 che AES-256?

score 4 · Answer 1

C'è davvero bisogno di avere CMS all'interno dell'ambiente CHD (card-holder data)? Raccomandiamo sempre di mantenere il CHD il più piccolo possibile. Non è possibile progettarlo in un altro modo in cui l'ambiente PCI DSS elaborerà / trasferirà / memorizzerà il CHD e passerà qualcosa come "token" all'esterno (cioè a CMS) invece di memorizzare il CHD direttamente in CMS?

È difficile raccomandare qualcosa qui perché non ho idea di dove conservi il CHD, qual è lo scopo e molte altre cose ...

Come ha detto @ISMSDEV, perché gli sviluppatori dovrebbero accedere a tale area di produzione? Lo sviluppatore sviluppa il codice mentre l'amministratore dell'app lo distribuisce e mantiene. Non riesco a vedere alcun motivo per cui gli sviluppatori dovrebbero avere accesso alla produzione ...

A proposito, se si progetta un ambiente PCI DSS e si pianifica di certificarlo, consiglierei di assumere qualche società / persona di consulenza con una profonda conoscenza di esso. Ti aiuterà così tanto ed è degno in quanto non è davvero facile ottenere tutto conforme. Mentre considero PCI DSS il migliore standard di sicurezza che abbia mai visto, è davvero difficile soddisfare tutte le sue esigenze. A volte, anche se pensi di fare le cose bene, l'auditor ti dice che non può essere così. Semplicemente perché hai capito male il requisito o non riesci a vederne tutti gli aspetti. E se ti dice questo una volta che hai finito la progettazione completa dell'ambiente, le applicazioni sviluppate, la documentazione scritta e tieni le prove di tutto ciò che è duro e costoso per rielaborarlo ...

Se non si memorizza, elabora o trasferisce il CHD, NON È NECESSARIO ESSERE conforme allo standard PCI DSS in alcun modo. Di così, sei perso.

score 0 · Answer 2

In questa situazione, ogni nuovo dominio ha una pagina iniziale statica che punta al contenuto CMS a cui è possibile accedere solo dopo l'autenticazione dell'utente. Possiamo anche pubblicare quelle pagine statiche direttamente dal CMS, il che è meglio, non c'è bisogno di rompere le cose.

Pertanto, quando registriamo un nuovo dominio, potremmo utilizzare l'inoltro invisibile per ogni dominio: www.ourcmsserver.com/SiteContent1, www.ourcmsserver.com/SiteContent2, www.ourcmsserver.com/SiteContent3, ecc. o parametrizzato www .ourcmsserver.com? sitecontentID = 1, ecc.

Poiché gli utenti devono effettuare il login, non dovrebbero comunque aggiungere pagine specifiche ai segnalibri e l'URL non mostrerà mai la directory / sottostruttura del sito, solo www.mysite1.com, www.mysite2.com.

Qualche commento su questo approccio?