¿PCI DSS coloca el servidor títere (o chef)?

3

Estoy desconcertado en cuanto a si puedo configurar un servidor Puppet en un entorno PCI DSS, y si lo estoy, ¿dónde debería estar ubicado?

Estaba planeando instalarlo en la puerta de enlace, y todos los hosts se conectarán a la puerta de enlace https / 8140 para recoger los manifiestos de nodo.

¿Esto violaría los requisitos de PCI DSS y, si lo hiciera, hay un lugar mejor para ponerlo? Tal vez DMZ?

¿Cuáles son sus experiencias Puppet / Chef / Salt en entornos PCI DSS?

Gracias

    
pregunta Jakov Sosic 06.03.2016 - 15:09
fuente

1 respuesta

3

Trabajé para una compañía de QSA durante 2 años, por lo que aquí hay una visión del ex asesor de su caso.

Es absolutamente correcto usar herramientas de administración de configuración (CM) desde la perspectiva de PCI DSS. En resumen, para estar bien con el cumplimiento estándar, debe hacer que este sistema cumpla con las normas DSS de PCI y alinear sus procesos de soporte y administración de configuración con los requisitos de PCI DSS.

En primer lugar, trate con el alcance de las PCI DSS. Mientras que las herramientas como Puppet / Chef no están directamente involucradas en el procesamiento de datos de tarjetas de pago, están afectando la seguridad de dichos componentes del sistema. No se considerará parte del entorno de datos del titular de la tarjeta (CDE), por lo que no es necesario que se encuentre dentro de un segmento de red aislado. Cualquier dependencia de servicio de Puppet / Chef que afecte a su propia seguridad también estará dentro del alcance de la revisión de PCI DSS. Estos pueden incluir: servidor AV, servidor de registro, autenticación, control de versiones, servidores de repositorio de paquetes, etc. Por lo tanto, en caso de que tenga dicha infraestructura dentro del alcance de PCI DSS, es una buena idea reutilizarla (por ejemplo, reenviando los registros a un servidor de registro de alcance PCI ya existente).

En general, existen dos patrones recomendados cuando incorporas herramientas CM en tu entorno:

  1. Instale un servidor autocontenido dentro de CDE y utilícelo solo para administrar componentes de sistema relacionados con PCI. De esta manera, está minimizando el impacto en su alcance de PCI DSS existente pero perdiendo flexibilidad.
  2. Use la arquitectura multiservidor e instale parte de ella en CDE. De esta manera, obtiene más flexibilidad, pero algunos sistemas de su red "PCI" no PCI también estarán dentro del alcance.

En cualquier caso, debe trabajar en estrecha colaboración con su QSA para determinar si su alcance previsto está correctamente definido y no quedan sistemas importantes.

Una vez que entienda qué cambios se realizarán en el ámbito de las PCI DSS incorporando herramientas de administración de configuración, puede planificar cómo implementar los requisitos de PCI técnicos y de procedimiento para este ámbito modificado. No describiré el proceso aquí, ya que es demasiado largo y no es diferente de lo que ya debería estar haciendo con su infraestructura existente de todos modos.

Sin embargo, quiero señalar un punto importante: la introducción de herramientas de CM generalmente tiene un gran impacto en las rutinas de gestión de cambios establecidas. Según los requisitos enumerados en la cláusula 6.4, hay muchas tareas que se deben realizar al aplicar cambios. Esto significa, literalmente, que todo lo que haga con su sistema CM debe planificarse / probarse / revisarse / aprobarse de la manera prescrita por PCI. Y esa es la razón por la que muchas tiendas DevOps terminan utilizando un sistema CM completamente aislado para administrar sistemas relacionados con PCIDSS. De todos modos, asegúrese de tener actualizados los procedimientos de administración de cambios.

Espero que esto ayude: es difícil abordar este problema y no escribir un artículo largo con muchos condicionales "si no".

    
respondido por el Artem Bychkov 06.04.2016 - 17:48
fuente

Lea otras preguntas en las etiquetas