Mejores prácticas / sitios web de pago de evaluación de riesgos

1

Tengo dos sitios web que aceptan pagos en un subdominio. El subdominio es un sistema independiente del sitio web principal.

Tengo una pregunta con respecto a la mejor práctica para decidir cuál de las siguientes configuraciones es la más segura (por supuesto, cada sitio web individual tiene que cumplir con PCI DSS, etc. pero este no debería ser un tema en este momento)

Versión 1: ambos sitios web de pago están alojados en el mismo servidor independiente. Puedo ver la ventaja de poder hacer que el servidor sea más seguro, ya que se pueden apagar sistemas más innecesarios (por ejemplo, el correo web utilizado por el sitio web principal, el acceso ftp, etc.), se pueden establecer reglas de firewall más estrictas (por ejemplo, no ftp , no hay conexiones de puerto 80, etc., no hay servicio de correo electrónico). Sin embargo, cuando alguien logra acceder al servidor, puede manipular ambos sitios web al mismo tiempo.

Versión 2: cada sitio web de pago está alojado en el mismo servidor que el dominio principal. La ventaja / desventaja se invierte en comparación con la versión 1.

¿Existe una mejor práctica? ¿Asumo que el riesgo de que ambos sitios web sean pirateados es mínimo en la Versión 1 y, por lo tanto, el más favorable? ¿O es el riesgo de que varios sitios web de procesamiento de tarjetas de crédito sean pirateados al mismo tiempo?

¡Gracias por tu consejo!

    
pregunta Tom 13.04.2017 - 18:11
fuente

1 respuesta

1

Aunque habrá muchas opiniones sobre esto, desde un punto de vista de los números, creo que tener un sitio de pago común independiente de sus otros sitios web es más económico y seguro.

  1. Superficie de ataque reducida. El sitio único debe tener una API muy simple para que otros sitios la consuman: "El cliente X quiere pagar la cantidad Y para el pedido Z", ese tipo de cosas. Esto limita las formas posibles para que un intruso viole el sistema. Como necesita examinar cada entrada individual por un defecto, simplemente hay menos entradas para examinar.

  2. Ámbito de auditoría reducido. Cuando comienza a tratar con los pagos, debe tratar con el cumplimiento de PCI. Los sistemas de pago son realmente onerosos para certificar. No quiere tener que pagar a los auditores extra para rastrear todos los servidores de sus aplicaciones solo porque pueden tener algunos datos de pago en ellos.

  3. Una infracción puede ser más perturbadora de lo que imaginas. Si piensa que va a exponer las cuentas X que alojan en un servidor cada una, o las cuentas 2X que hospedan en un servidor común, cualquiera de las violaciones puede ser tan perjudicial para su negocio común que ambas entidades pueden salir de negocio en su totalidad. A ver si puedo dibujar esto:

    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

En cada punto de la escala, la supervivencia misma de su empresa está en mayor riesgo. ¿El riesgo de cuentas 2X porque incluye dos sitios web cambiaría el impacto potencial? No tanto.

Creo que es mejor que junte sus recursos y asegure un solo sitio de pago. Y cuanto más se mire este problema para los minoristas más pequeños, más recomiendo contratar con una pasarela de pago y descargar ese riesgo de su negocio principal de venta de widgets o artilugios. Si se incumple a un proveedor de pagos, eso generalmente no se reflejará tan mal en los sitios web que los usaron. Si le ayuda, piense en el costo adicional como una inversión en un seguro de reputación.

Incluso si elige ir con su "versión 2", recomendaría que cada sitio web mantenga su propia pasarela de pago de forma arquitectónicamente independiente del resto del sitio web como sea posible. Eso significa servidores de pago separados de los servidores web, bases de datos separadas para datos de pago, etc., por las mismas razones: para reducir las superficies de ataque y reducir el alcance de la auditoría.

    
respondido por el John Deters 13.04.2017 - 20:37
fuente

Lea otras preguntas en las etiquetas