siti Web di pagamento per le migliori pratiche / valutazione dei rischi

1

Ho due siti web che accettano entrambi pagamenti su un sottodominio. Il sottodominio è un sistema indipendente dal sito Web principale.

Ho una domanda riguardante le migliori pratiche per decidere quale delle seguenti impostazioni è la più sicura (ovviamente, ogni sito Web deve essere conforme a PCI DSS ecc., ma questo non dovrebbe essere argomento in questo momento)

Versione 1: entrambi i siti Web di pagamento sono ospitati sullo stesso server indipendente. Posso vedere il vantaggio di essere in grado di rendere il server più sicuro, in quanto è possibile disattivare più sistemi non necessari (ad esempio la webmail utilizzata dal sito Web principale, l'accesso ftp, ecc.), È possibile stabilire regole firewall più rigide (ad es. , nessuna porta 80 connessioni ecc, nessun servizio di posta elettronica). Tuttavia, quando qualcuno riesce ad accedere al server, potrebbe manomettere entrambi i siti web contemporaneamente.

Versione 2: ogni sito web di pagamento è ospitato sullo stesso server del dominio principale. Il vantaggio / lo svantaggio sono invertiti rispetto alla versione 1.

C'è una buona pratica? Presumo che il rischio di avere entrambi i siti Web compromessi è minimo nella versione 1 e quindi il più favorevole? Oppure il rischio di avere più siti Web di elaborazione delle carte di credito violato troppo in alto?

Grazie per il tuo consiglio!

    
posta Tom 13.04.2017 - 18:11
fonte

1 risposta

1

Anche se ci saranno molte opinioni su questo punto, dal punto di vista dei numeri, credo che avere un sito di pagamento comune indipendente dai tuoi altri siti web sia più economico e sicuro.

  1. Superficie d'attacco ridotta. Il singolo sito dovrebbe avere un'API molto semplice da utilizzare per gli altri siti: "Il cliente X vuole pagare l'importo Y per l'ordine Z", quel genere di cose. Ciò limita i possibili modi in cui un intruso può violare il sistema. Poiché è necessario esaminare ogni singolo input per un difetto, ci sono semplicemente meno input da esaminare.

  2. Ambito di controllo ridotto. Quando inizi a gestire i pagamenti, devi gestire la conformità PCI. I sistemi di pagamento sono davvero onerosi per certificare. Non vuoi dover pagare gli auditor in più per eseguire la scansione su tutti i server delle app solo perché potrebbero contenere alcuni dati di pagamento.

  3. Una violazione può facilmente essere più dirompente di quanto immagini. Se stai pensando di esporre o X account hosting su un server ciascuno, o 2X account hosting su un server comune, o la violazione ha il potenziale di essere così dannoso per il tuo business comune che entrambe le entità potrebbero uscire. affari interamente. Vediamo se riesco a disegnare questo:

    Number of     |
accounts breached | Progressively larger impact to business
                  |
    10^1          | Small fines, increased auditing
    10^2          | Larger fines, greatly increased auditing expense
    10^3          | Internet/Yelp impact to brand reputation, lawsuits
    10^4          | Local newsworthy impact to brand
    10^5          | Class action lawsuits, regional impact to brand
    10^6+         | National/international impact to brand

In ogni punto della scala la tua stessa sopravvivenza è a maggior rischio. Rischiare un account 2X perché includi due siti web cambia il potenziale impatto? Non così tanto.

Penso che tu stia meglio mettendo in comune le tue risorse e assicurando un singolo sito di pagamento. E più guardi a questo problema per i rivenditori più piccoli, più ti consiglio di contrattare con un gateway di pagamento e di scaricare il rischio dalla tua attività principale di vendere widget o gadget. Se un fornitore di servizi di pagamento viene violato, questo generalmente non si riflette in modo negativo sui siti Web che li hanno utilizzati. Se aiuta, pensa al costo aggiuntivo come investimento nell'assicurazione sulla reputazione.

Anche se scegli di seguire la tua "versione 2", consiglierei comunque a ciascun sito web di mantenere il proprio gateway di pagamento come architettonicamente indipendente dal resto del sito web il più possibile. Ciò significa che i server di pagamento separati dai server Web, i database separati per i dati di pagamento e così via, per gli stessi motivi: ridurre le superfici di attacco e ridurre l'ambito di controllo.

    
risposta data 13.04.2017 - 20:37
fonte

Leggi altre domande sui tag