¿Cómo asegurarnos de que nuestro proceso de implementación del entorno de producción sea compatible con PCI cuando necesitamos realizar actualizaciones de código en vivo?

6

Al planificar la siguiente fase de nuestra plataforma, estoy tratando de asegurar que el proceso de implementación de producción sea compatible con PCI.

Tenemos una plataforma central que actúa como un CMS, que sirve contenido personalizado basado en un tipo de evento, que residirá en un entorno / servidor IIS reforzado.

Cada nuevo evento tiene una pantalla de inicio básica y un nombre de dominio personalizado, es decir, www.myevent1.com, www.myevent2.com, etc.

El problema es que necesitaremos agregar nuevos nombres de dominio con frecuencia. Al ser compatible con PCI, no podemos tener desarrolladores que accedan a servidores de producción.

estados PCI-DSS 6.4:

  

Una separación de funciones entre el personal asignado a la   entornos de desarrollo / prueba y aquellas personas asignadas a la   entorno de producción.

Estoy tratando de mantener la separación de tareas según las especificaciones de cumplimiento.

Por lo tanto, mi opinión era mantener el servidor CMS tal como está, completamente reforzado, sin acceso de desarrollador. Luego, tenga un servidor IIS secundario donde los desarrolladores puedan agregar nuevos dominios según sea necesario y cargue las páginas de inicio estáticas que enlazan con el contenido del CMS.

¿Pensamientos?

- ACTUALIZACIÓN -

Utilizaremos el cumplimiento del nivel 4 de PCI-DSS, por lo que no tendremos ningún dato del titular de la tarjeta en nuestros servidores. El procesador de pagos tendrá esta información.

    
pregunta ElHaix 29.05.2017 - 22:52
fuente

2 respuestas

4

¿Hay una necesidad real de tener CMS dentro del entorno de CHD (datos del titular de la tarjeta)? Siempre recomendamos mantener el CHD lo más pequeño posible. ¿No es posible diseñarlo de otra manera donde su entorno PCI DSS solo procesará / transferirá / almacenará el CHD y pasará algo como "tokens" fuera (es decir, a CMS) en lugar de almacenar el CHD directamente en el CMS?

Es difícil recomendar algo aquí, ya que no tengo ni idea de dónde almacena el CHD, cuál es su propósito y muchas otras cosas ...

Como dijo @ISMSDEV, ¿por qué los desarrolladores deberían acceder a esa área de producción? El desarrollador desarrolla el código mientras el administrador de la aplicación lo implementa y mantiene. No veo ninguna razón por la que los desarrolladores deberían tener acceso a la producción ...

Por cierto, si diseña un entorno PCI DSS y planea certificarlo, le recomendaría contratar a una empresa / persona de consultoría con un conocimiento profundo de este. Te ayudará mucho y vale la pena, ya que realmente no es fácil hacer que todo sea compatible. Si bien considero que las PCI DSS son el mejor estándar de seguridad que he visto, es muy difícil cumplir con todos sus requisitos. A veces, incluso si crees que estás haciendo las cosas bien, el auditor te dice que no puede ser así. Simplemente porque entendió mal el requisito o no puede ver todos los aspectos del mismo. Y si él le dice esto una vez que haya terminado el diseño completo del entorno, se hayan desarrollado las aplicaciones, se haya escrito la documentación y se tenga evidencia de todo lo difícil y costoso de volver a trabajar ...

Si no almacena, procesa ni transfiere la CHD, NO NECESITA SER compatible con PCI DSS de ninguna manera. Por lo tanto, estás perdido.

    
respondido por el Fis 29.05.2017 - 23:52
fuente
0

En esta situación, cada nuevo dominio tiene una página de inicio estática que apunta al contenido del CMS al que solo se puede acceder después de la autenticación del usuario. También podemos servir esas páginas estáticas directamente desde el CMS, lo que es mejor, no hay necesidad de separar las cosas.

Por lo tanto, cuando registramos un nuevo dominio, podríamos usar el reenvío oculto para cada dominio: www.ourcmsserver.com/SiteContent1, www.ourcmsserver.com/SiteContent2, www.ourcmsserver.com/SiteContent3, etc. o parametrizado www .ourcmsserver.com? sitecontentID = 1, etc.

Como los usuarios tienen que iniciar sesión, no deberían marcar páginas específicas de todos modos, y la URL nunca mostrará el directorio / subestructura del sitio, solo www.misitio.com, www.misitio.com.

¿Algún comentario sobre este enfoque?

    
respondido por el ElHaix 01.06.2017 - 22:37
fuente

Lea otras preguntas en las etiquetas