Utilizza repository esterni conformi a PCI-DSS

2

Stiamo pensando di utilizzare BitBucket invece di ospitare internamente i nostri repository Git. Qualcuno sa se questo infrange le regole della conformità PCI? Non sono stato in grado di trovare molte informazioni su questo.

    
posta William W 04.02.2014 - 01:52
fonte

1 risposta

7

Sto basando questo fuori dalla versione 3.0 ( link ) anche se ammetterò che potrei mancarmi qualcosa (ho più familiarità con 2.0).

Dai "highlight" pdf link c'è qualcosa che attira la mia attenzione, sebbene io possa trovare i requisiti corrispondenti nel DSS:

Enhanced requirements for system development processes including periodic security reviews, verifying integrity of source code, a versioning methodology, use of application threat-modeling techniques, and a formal authorization process before final release.

Sebbene questo sia un aggiornamento proposto , noterò che la verifica dell'integrità del codice sorgente e della metodologia di controllo della versione sono ... interessanti.

Quando lavori con un host esterno (o anche con un host interno), probabilmente devi convalidare che è stato tu che ha eseguito il commit del codice e non qualcos'altro che qualcuno ha detto che eri tu. Ti indicherò Cosa sono i vantaggi e gli svantaggi della firma crittografica dei commit e dei tag in Git? , che va in questo un po 'e in particolare link

In teoria, lo stai già facendo. Lavorando con repository esterni diventa ancora più critico il fatto che il codice sorgente possa essere verificato. Non sono sicuro del motivo per cui stai migrando a uno strumento esterno per ospitare il codice, anche se potresti voler indagare su uno strumento interno più "lucido" come Atlassian Stash

La sezione 6 è dove i problemi di sviluppo sono a portata di mano e sembra essere per lo più invariato da 2.0. Principalmente è necessario verificare che il codice (6.3.2). Avere un hosting esterno, diventa ancora più critico.

Non c'è nulla nei requisiti che dicano dove è necessario o impossibile ospitare il codice sorgente. L'unica cosa a cui prestare attenzione in questo (che diventa molte cose) è la domanda "è il server in cui il codice è ospitato un componente di sistema". Se lo è, allora una serie di requisiti vengono sollevati come le cose che devi osservare ed essere in grado di dimostrare a un auditor che stai facendo le cose correttamente. Questi includono 7.2, 8.1, 5. *. potrebbe essere in grado di chiedere al fornitore "stai installando patch di sicurezza entro 30 giorni dalla disponibilità". Non tiene i dati dei titolari di carta, ma ... se li considerano un componente di sistema, ti diverti un po '.

A seconda della familiarità con le cose del revisore, questo potrebbe andare in molti modi diversi (chi ha familiarità con esso vorrebbe verificare che tu stia firmando tag o impegni e lascialo andare, quelli che stanno rintracciando ogni cosa e non posso dire a un codice sorgente di produzione che ospita l'ambiente da un ambiente di dati di titolari di carta di produzione potrebbe voler vedere i registri di accesso di controllo da BitBucket). Ed è qui che le cose possono diventare difficili.

La mia lettura di PCI DSS 3.0 e l'hosting remoto del codice:

  • Sei bravo a firmare commit e / o tag e creare solo da queste code line.

È potrebbe necessario modificare il modo in cui si lavora con git per fare ciò (push branch e merge vs fork, tag, pull request - sospetto che più tardi sarebbe considerato migliore per spiegando come funziona ad un auditor - che "verifica l'integrità del codice sorgente e del bit della metodologia di versioning" nei requisiti proposti)

    
risposta data 04.02.2014 - 02:21
fonte

Leggi altre domande sui tag