Cumplimiento de las Normas de seguridad de datos de la PCI

En esta guía, se muestra cómo implementar las Normas de seguridad de datos de la Industria de tarjetas de pago (PCI DSS) en tu empresa en Google Cloud Platform (GCP). La guía va más allá de los lineamientos de computación en la nube del PCI SSC (PDF) para proporcionar información sobre las normas, explicar tu función en el cumplimiento basado en la nube y brindarte las pautas para diseñar, implementar y configurar una app de procesamiento de pagos con las PCI DSS. El instructivo también describe los métodos para supervisar, registrar y validar tu app.

Las Normas de seguridad de datos de la PCI, creadas por el Consejo sobre Normas de Seguridad de la PCI, son normas de seguridad de la información para empresas que manejan información de tarjetas de pago (crédito y débito). El Consejo sobre Normas de Seguridad de la PCI incluye las principales empresas de tarjetas de pago. Se espera que las empresas que aceptan Visa, MasterCard, Discover, American Express o JCB cumplan con las PCI DSS, ya que pueden ser multadas o penalizadas si no lo hacen.

Las PCI DSS incluyen clasificaciones para varios tipos de comercios, desde los que recopilan información de pago en persona hasta los que externalizan por completo el procesamiento de pagos. Esta guía abarca los tipos de comercios SAQ A, SAQ A-EP y SAQ D.

Objetivos

  • Revisar la arquitectura de la app de procesamiento de pagos
  • Configurar tu entorno de procesamiento de pagos
  • Implementar y configurar tus servidores de app
  • Configurar el registro y la supervisión
  • Validar tu entorno de procesamiento de pagos

Definiciones

Esta guía usa muchas frases únicas. Aquí están algunas de las más comunes. Para obtener más información, consulta el glosario de las PCI DSS.

CDE: Sigla de cardholder data environment (entorno de datos del titular de la tarjeta). Esta sigla se refiere a cualquier parte de tu app que contiene o transfiere datos del titular de la tarjeta, lo que incluye el número de la cuenta de pagos o cualquier información de identificación personal relacionada con la tarjeta.

Controles de compensación: Soluciones alternativas a cualquier requisito dado que cumplan con la intención y el rigor del requisito original y que brinden un nivel de defensa similar. La definición oficial dice que los controles de compensación deben ir “más allá” que los otros requisitos de las PCI DSS y deben ser acordes con el riesgo adicional que se impone cuando no se adhiere al requisito original.

PAN: Sigla de primary account number (número de cuenta principal), también denominado número de cuenta. Es el número único de la tarjeta de pago que identifica a la entidad emisora y a la cuenta del titular de la tarjeta.

QSA: Sigla de Qualified Security Assessor (Asesor de Seguridad Calificado). Los QSA están calificados por el Consejo sobre Normas de Seguridad (SSC) de la PCI para realizar evaluaciones de las PCI DSS en las instalaciones. Consulta los Requisitos de calificación de QSA a fin de obtener detalles sobre los requisitos para los empleados y empresas QSA.

SAQ: Sigla de Self-Assessment Questionnaire (Cuestionario de autoevaluación), la herramienta de informes que se usa para documentar los resultados de la autoevaluación a partir de la evaluación de las PCI DSS de una entidad.

Alcance: Los sistemas, procedimientos y personas que se incluyen en una evaluación de las PCI DSS.

Asignación de token: un proceso que reemplaza el número de cuenta principal (PAN) por un valor subrogado llamado token. El PAN luego se almacena en una búsqueda segura. La desasignación de token es el proceso inverso, buscar un PAN según su token. Un token puede ser un hash o un valor asignado.

Fondo

Las PCI DSS proporcionan una lista de requisitos diseñados para mejorar la seguridad del titular de la tarjeta. Estos requisitos se dividen en doce partes numeradas principales y muchas subpartes. Este documento hace referencia a los números de estas partes para agregar contexto, pero las referencias de sección no son una lista exhaustiva de los requisitos aplicables.

Tus requisitos de cumplimiento de las PCI DSS varían según la forma en que tu empresa maneja las transacciones con tarjeta de pago (tipo) y la cantidad de transacciones que realiza cada año (nivel).

A medida que aumenta el número de transacciones, aumenta tu nivel de comercio de las PCI DSS y los lineamientos de cumplimiento de las PCI DSS se vuelven más estrictos. En el nivel de comercio más alto, el Nivel 1, las PCI DSS requieren una auditoría. Los niveles varían según la marca de la tarjeta. American Express define el Nivel 1 en 2.5 millones de transacciones anuales, mientras que Visa, Mastercard y Discover lo definen en 6 millones. Cada marca de tarjeta tiene requisitos de nivel adicionales que están más allá del alcance de este documento. Asegúrate de que tu entorno de procesamiento de pagos sea auditado para admitir tu nivel de comercio.

Debido a que GCP es un proveedor de servicios que cumple con las PCI DSS 3.2 de Nivel 1, puede satisfacer tus necesidades de cumplimiento de las PCI DSS sin importar cuál sea el nivel de comercio de tu empresa. La sección Compromiso con el cumplimiento establece qué áreas cubre Google por ti.

La otra variable fundamental es tu tipo de SAQ. El SAQ describe los criterios que debes satisfacer para cumplir con las PCI DSS. A tu tipo de SAQ lo determinan la arquitectura de tu app y la forma precisa en que manejas los datos de las tarjetas de pago. La mayoría de los comercios en la nube pertenecen a uno de los siguientes tipos:

Tipo de SAQ Descripción
A Los comercios que subcontratan por completo el procesamiento de tarjetas de pago a un sitio de terceros. Los clientes dejan tu dominio (incluso a través de un formulario web <iframe>), completan el pago y luego regresan a tu app.

En otras palabras, tu empresa no puede tocar los datos de la tarjeta del cliente de ninguna manera.
A-EP Comercios que subcontratan el procesamiento de pagos a un proveedor de terceros, pero que pueden acceder a los datos de la tarjeta del cliente en cualquier momento del proceso. Los comercios que pueden acceder a los datos de la tarjeta incluyen elementos de página controlados por el comercio, como JavaScript o CSS, que están incorporados en la página de pago del tercero.

En otras palabras, tu app de procesamiento de pagos reenvía los datos de la tarjeta a un procesador en el lado del cliente, o el procesador se encarga de cualquier contenido que alojes.
D Comercios que aceptan pagos en línea y no califican para SAQ A o SAQ A-EP. Este tipo incluye a todos los comerciantes que llaman a una API de procesador de pagos desde sus propios servidores, más allá de la asignación de token.

En otras palabras, si no eres SAQ A o SAQ A-EP, eres SAQ D.

SAQ D distingue entre Comercios y Proveedores de servicios. Los proveedores de servicios no se tratan en este documento y todas las referencias de SAQ D se dirigen a los comercios según lo definido en las PCI DSS.
Diagrama de Venn de requisitos de SAQ.SAQ A-EP es un superconjunto de SAQ A, mientras que SAQ D es un superconjunto de SAQ A-EP.
Diagrama de Venn de requisitos de SAQ. SAQ A-EP es un superconjunto de SAQ A, mientras que SAQ D es un superconjunto de SAQ A-EP.

Los comercios pueden ser de cualquier combinación de nivel y tipo, y tus requisitos de cumplimiento varían mucho según tus circunstancias.

Compromiso con el cumplimiento

Google usa una variedad de tecnologías y procesos para proteger la información que se almacena en sus servidores. Google valida de forma independiente los requisitos de las PCI DSS que se aplican a la infraestructura y las tecnologías de GCP que administra. Aunque Google ofrece a los comercios un gran control sobre sus instancias de procesamiento que se ejecutan en la infraestructura de Google, no controla la seguridad del sistema operativo, los paquetes o las apps que los comercios implementan en GCP. Es tu responsabilidad cumplir con los requisitos de las PCI DSS para los paquetes de sistema operativo y las apps que implementas, además de otras personalizaciones que requiera tu arquitectura.

GCP sigue los requisitos de las PCI DSS establecidos para un proveedor de servicios de Nivel 1 y todos los requisitos de proveedores de servicios aplicables. La Matriz de responsabilidad del cliente de GCP describe las obligaciones de cumplimiento de las PCI DSS. La matriz de responsabilidad puede ser una referencia útil para cumplir con las PCI DSS y realizar tus propias auditorías de las PCI DSS.

Orientación sobre productos

App Engine

En la actualidad, las reglas de firewall de ingreso de App Engine están disponibles, pero las de salida no. De acuerdo con los requisitos 1.2.1 y 1.3.4, debes asegurarte de que todo el tráfico saliente esté autorizado. Los comercios de tipo SAQ A-EP y SAQ D deben proporcionar controles de compensación o usar un producto de GCP diferente. Compute Engine y GKE son las alternativas recomendadas.

Cloud Functions

Al igual que App Engine, Cloud Functions en la actualidad no admite reglas de firewall de salida. Los comercios de tipo SAQ A-EP y SAQ D deben proporcionar controles de compensación o usar un producto de GCP diferente. Compute Engine y GKE son las alternativas recomendadas.

Google Kubernetes Engine

Trata los nodos y pods en un clúster de GKE de la misma manera que a cualquier servidor administrado por un comercio. Implementa el registro, la instrumentación y la aplicación de parches a nivel de nodo y de pod. No conserves los datos del titular de la tarjeta en el nivel de nodo; sin embargo, los nodos seguirán dentro del alcance si contienen o pueden contener algún pod que esté dentro del alcance.

Para restringir el acceso a tu instancia principal de clúster, usa redes autorizadas a fin de bloquear las direcciones IP no confiables desde fuera de GCP. Estas reglas CIDR son compatibles con clústeres privados y actúan como una lista blanca.

Implementa políticas de red en el clúster de GKE cuando tus proyectos dentro del alcance contienen diferentes tipos de pods. Las políticas de red funcionan de manera similar a los firewalls de la nube privada virtual (VPC) con los que quizás ya estés familiarizado. Puedes permitir o denegar el tráfico según las etiquetas o reglas de IP.

El requisito 2.2.1 estipula que solo se puede implementar una función principal por servidor. Este requisito no prohíbe el caso de un solo clúster de GKE que aloje más de un tipo de pod. La función principal de los nodos de GKE es entregar y administrar contenedores. Si se diseñan de forma correcta, los pods individuales también pueden adherirse a esta regla de función primaria en un solo clúster.

Cloud Storage

El requisito 3.4 estipula que un PAN debe ser ilegible en cualquier lugar donde se almacene. Si bien Google ofrece de forma automática la encriptación en reposo, no realiza de forma automática el truncamiento, la asignación de token o los hashes unidireccionales que también requieren las reglas.

Arquitecturas de ejemplo

Esta sección ilustra los enfoques para implementar un entorno que cumpla con SAQ A, SAQ A-EP y SAQ D.

Descripción general de la arquitectura

SAQ A

SAQ A es la arquitectura de procesamiento de pagos más básica. Un tercero procesa los pagos y las apps o páginas del comercio no acceden a los datos de la tarjeta.

En un nivel alto, el flujo de procesamiento de pagos es el siguiente:

  1. El cliente realiza sus selecciones y procede a pagar.

  2. La app de pagos redirecciona al cliente a un procesador de pagos de terceros.

  3. El cliente ingresa la información de su tarjeta de pago en un formulario de pago que posee y mantiene el procesador de terceros.

  4. El procesador de pagos de terceros verifica la información de la tarjeta de pago y luego cobra o rechaza la tarjeta.

  5. Después de procesar la transacción, redirige al cliente a la app del comercio junto con los detalles de la transacción.

  6. La app del comercio envía una solicitud de verificación al procesador de pagos para confirmar la transacción.

  7. El procesador de pagos responde para verificar los detalles de la transacción.

Arquitectura de un entorno de procesamiento de pagos de terceros SAQ A

SAQ A-EP

La arquitectura de procesamiento de pagos SAQ A-EP se centra en una app de procesamiento de pagos que se ejecuta en instancias de máquinas virtuales de Compute Engine. Estas instancias se encuentran en una red privada segura y usan canales seguros para comunicarse con servicios fuera de la red.

En un nivel alto, el flujo de procesamiento de pagos es el siguiente:

  1. El cliente ingresa la información de su tarjeta de pago en un formulario de pago que posee y mantiene tu empresa.

  2. Cuando el cliente envía sus datos, la información del formulario se pasa de manera segura a un procesador de pagos de terceros.

  3. El procesador de pagos de terceros verifica la información de la tarjeta de pago y luego cobra o rechaza la tarjeta.

  4. El procesador de pagos envía una respuesta a tu app de pagos, que, a su vez, pasa un mensaje a tu app principal.

Todas estas interacciones se registran y supervisan con Stackdriver Logging y Stackdriver Monitoring.

Arquitectura de un entorno de procesamiento de pagos SAQ A-EP
Arquitectura de un entorno de procesamiento de pagos SAQ A-EP

SAQ D

La arquitectura de procesamiento de pagos SAQ D se centra en una app de procesamiento de pagos que se ejecuta en instancias de máquinas virtuales de Compute Engine. Estas instancias se encuentran en una red privada segura y usan canales seguros para comunicarse con servicios fuera de la red.

En un nivel alto, el flujo de procesamiento de pagos es el siguiente:

  1. El cliente ingresa la información de su tarjeta de pago en un formulario de pago que posee y mantiene tu empresa.

  2. Cuando el cliente envía sus datos, tu app de pagos recibe la información del formulario.

  3. Tu app de pagos valida la información de pago y la pasa de manera segura a un procesador de pago de terceros mediante una API de backend.

  4. El procesador de pagos de terceros verifica la información de la tarjeta de pago y luego cobra o rechaza la tarjeta.

  5. El procesador de pagos envía una respuesta a tu app de pagos, que, a su vez, pasa un mensaje a tu app principal.

Todas estas interacciones se registran y supervisan con Logging y Monitoring.

Arquitectura de un entorno de procesamiento de pagos SAQ D
Arquitectura de un entorno de procesamiento de pagos SAQ D

Flujo de procesamiento de pagos orientado al cliente

SAQ A

En esta sección, se describe el flujo de procesamiento de pagos de terceros desde la perspectiva de los clientes que usan tu app.

Flujo orientado al cliente del procesamiento de pagos de terceros SAQ A
Flujo orientado al cliente del procesamiento de pagos de terceros SAQ A

Cuando tu cliente accede a tu formulario de pago, la app presenta un <iframe> que aloja el procesador de pagos. Tu app no puede acceder a o supervisar el contenido del <iframe> debido a las limitaciones del uso compartido de recursos multiorigen. Cuando el cliente envía la información de su tarjeta de pago, el procesador de pagos acepta o rechaza la tarjeta y luego redirige al cliente a tu app. Tu app verifica la respuesta de transacción del procesador de pagos y actúa en consecuencia. Tu app no maneja información de la tarjeta de pago ni accede a ella.

SAQ A-EP

En esta sección, se describe el mismo flujo de procesamiento de pagos interno que se describió antes, pero desde la perspectiva de los clientes que usan tu app.

Flujo orientado al cliente del procesamiento de pagos de terceros SAQ A-EP
Flujo orientado al cliente del procesamiento de pagos de terceros SAQ A-EP

Cuando tu cliente accede a la URL de tu formulario de pago, el sitio presenta un formulario que aloja tu app de pagos. Cuando el cliente envía la información de su tarjeta de pago, el formulario va directamente al procesador de pagos. El procesador acepta o rechaza la tarjeta y luego envía al cliente de vuelta a tu app. Tu app verifica la respuesta de transacción del procesador de pagos y actúa en consecuencia. Aunque el cliente no vea el procesador de pagos de terceros, tu app no accede a la información de la tarjeta de pago en el lado del servidor.

SAQ D

En esta sección, se describe el flujo de procesamiento de pagos interno desde la perspectiva de los clientes que usan tu app.

Flujo orientado al cliente del procesamiento de pagos de terceros SAQ D
Flujo orientado al cliente del procesamiento de pagos de terceros SAQ D

Cuando tu cliente accede a la URL de tu formulario de pago, se lo enruta de forma segura al formulario a través de un balanceador de cargas HTTPS. Cuando el cliente envía la información de su tarjeta de pago, tu app de procesamiento de pagos envía de forma segura la información a un procesador de pagos de terceros. El procesador de pagos de terceros acepta o rechaza la tarjeta y luego muestra una respuesta a tu app de procesamiento de pagos.

Flujo interno del procesamiento de pagos

SAQ A y A-EP

En esta sección, se describe el flujo de procesamiento de pagos desde la perspectiva de los servidores que ejecutan tu app.

Flujo interno de SAQ A y SAQ A-EP
Flujo interno de SAQ A y SAQ A-EP

Tu app de procesamiento de pagos recibe y analiza la respuesta que muestra el procesador de pagos de terceros y luego envía algunos o todos los datos de respuesta a la app principal. En este punto, tu app de procesamiento de pagos finaliza con la transacción. La app principal se encarga de notificar a tus clientes.

SAQ D

En esta sección, se describe el flujo de procesamiento de pagos interno desde la perspectiva de los servidores que ejecutan tu app.

Flujo interno de SAQ D
Flujo interno de SAQ D

Tu app de procesamiento de pagos valida la información de la tarjeta de pago que ingresa el cliente y luego la envía al procesador de pagos a través de una API de backend. El procesador intenta cobrar y responde con los detalles de la transacción. Tu app recibe y procesa la respuesta, y luego envía algunos o todos los datos de respuesta a la app principal. En este punto, tu app de procesamiento de pagos finaliza con la transacción. La app principal se encarga de notificar a tu cliente y entregar el producto.

Flujo de supervisión y registro de datos

El flujo de supervisión y registro está diseñado de la siguiente manera:

Flujo de supervisión y registro
Flujo de supervisión y registro

Configura tu entorno de procesamiento de pagos

En esta sección, se describe cómo configurar tu entorno de procesamiento de pagos. La configuración incluye los siguientes pasos:

  • Crear una nueva cuenta de GCP para aislar tu entorno de procesamiento de pagos de tu entorno de producción
  • Restringir el acceso a tu entorno
  • Configurar tus recursos virtuales
  • Diseñar la imagen base de Linux que usarás para configurar tus servidores de apps
  • Implementar una solución segura de administración de paquetes

Configura una nueva cuenta

Para simplificar la restricción de acceso y la auditoría de cumplimiento, crea un entorno de procesamiento de pagos con calidad de producción que esté aislado por completo de tu entorno de producción estándar y cualquier entorno de desarrollo o de control de calidad (requisito 6.4.1). Para garantizar el aislamiento, crea y usa una cuenta de GCP que esté separada de tu cuenta de entorno de producción principal. Los usuarios que tengan experiencia con la configuración de Cloud Identity and Access Management (Cloud IAM) pueden lograr un aislamiento equivalente mediante proyectos separados para el trabajo dentro del alcance.

Restringe el acceso a tu entorno

Permite el acceso al entorno de procesamiento de pagos solo a las personas que implementan tu código de sistema de pago o administran tus máquinas de sistema de pagos (sección 7.1 y requisito 8.1.1). Esto se conoce como el principio de privilegio mínimo. Usa las funciones de Cloud IAM para restringir el acceso. Las recomendaciones incluyen usar funciones siempre que sea posible, otorgar solo los permisos necesarios para realizar el trabajo esperado y solo otorgar la función de Propietario a los miembros que de verdad necesitan acceso completo a tus servicios. Consulta la guía de seguridad de Cloud IAM para obtener más información.

El acceso automatizado a cualquier servicio administrado debe depender de las cuentas de servicio. Las cuentas de servicio simplifican el ciclo de vida de la administración de la app porque te brindan una manera de administrar la autenticación y autorización de la app. Estas cuentas te brindan una manera flexible y segura de agrupar las instancias de máquinas virtuales con apps y funciones similares que tienen una identidad común. Puedes aplicar la seguridad y el control de acceso en el nivel de la cuenta de servicio a través de las funciones de Cloud IAM y las reglas de firewall VPC.

A las reglas de Cloud IAM que apliques a las carpetas las heredan todos los elementos contenidos en esa carpeta. Los permisos predeterminados son deny-all (requisito 7.2.3), y cada regla que apliques solo agrega permisos.

El requisito 8.2.3 proporciona algunas reglas básicas para las contraseñas de los usuarios. El Instituto Nacional de Normas y Tecnología (NIST) define un conjunto de reglas más seguro para las contraseñas en la sección 5.1.1 de NIST SP800-63B. Google recomienda seguir los lineamientos de Identidad Digital del NIST siempre que sea posible.

La sección 12.7 de las PCI DSS SAQ D requiere que las personas con acceso a tu entorno dentro del alcance pasen una verificación de antecedentes, de conformidad con las leyes locales, antes de que se les otorgue acceso al entorno. Para reducir el riesgo de violaciones de cumplimiento, considera realizar estas verificaciones de antecedentes penales y de referencias en cada persona, sin importar tu tipo de cumplimiento.

Protege tu red

Para proteger el tráfico entrante y saliente desde y hacia tu red de apps de procesamiento de pagos, debes crear lo siguiente:

  • Reglas de firewall de Compute Engine
  • Un túnel de red privada virtual (VPN) de Compute Engine
  • Un balanceador de cargas HTTPS de Compute Engine

Para crear tu VPC, recomendamos Cloud NAT (Beta) a fin de tener una capa adicional de seguridad de red. Hay muchas opciones potentes disponibles para proteger las redes de las instancias de Compute Engine y GKE.

Crea reglas de firewall

Usa reglas del firewall para restringir el tráfico entrante a cada una de tus instancias de Compute Engine (requisitos 1.2.1 y 1.3.2). Solo debes permitir el tráfico entrante de las tres fuentes siguientes:

  • HTTPS público, para que los clientes puedan llegar a tu página de pago
  • Tu red de apps, de modo que tu app de procesamiento de pagos pueda recibir respuestas de tu procesador de pagos de terceros
  • La red interna de tu oficina, para que puedas acceder a las instancias con fines de auditoría y administración

Usa reglas de firewall en instancias individuales para restringir el tráfico saliente. Puedes implementar estas reglas de forma local con iptables o de forma más amplia con etiquetas de red y reglas de firewall VPC. Solo debes permitir el tráfico saliente desde tu formulario de pagos al procesador de pagos de terceros. Esta conexión debe ser solo HTTPS. Consulta la sección sobre Registro de reglas de firewall a continuación para probar tu trabajo.

Cloud DNS ofrece zonas DNS privadas para que puedas nombrar hosts de forma segura dentro de tu CDE sin riesgos de filtrar al público datos sensibles de topología de red.

Restringe el tráfico de la siguiente manera:

Fuente Destino Puerto Dirección y razón
Balanceador de cargas público Formulario de pagos de terceros tcp:443 Entrante
Acceso público a la app de procesamiento de pagos
Formulario de pago de terceros Procesador de pagos de terceros tcp:443 Saliente
Reenvío de solicitudes AUTH al proveedor de servicios de pago
Procesador de pagos de terceros Tu app de procesamiento de pagos tcp:5480 Entrante
Aceptar solicitudes AUTH de sistemas de pago (no contiene ningún dato del titular de la tarjeta)
Red de oficinas de tu empresa vpn-gateway tcp:8000 Entrante
Acceso al entorno de procesamiento de pagos para acceder a registros y máquinas de desarrollo

Además, el siguiente tráfico se realiza de forma segura en la red interna de tu app de procesamiento de pagos:

Fuente Destino Puerto Motivo
Formulario de tarjeta Proxy PCI tcp:5480 Intercambio de datos de tarjetas encriptados para token de instrumentos de pago
Todos los hosts Servidores de Google NTP udp:123 Sincronización temporal
Puerta de enlace VPN Todos los hosts tcp:22 Conexiones Secure Shell (SSH)

Establece un túnel VPN seguro

Compute Engine proporciona un servicio de VPN que puedes usar para establecer un túnel VPN seguro entre tu entorno local y tu entorno de procesamiento de pagos (secciones 2.3 y 4.1).

Crea un balanceador de cargas HTTPS

Puedes ayudar a garantizar que el tráfico de clientes entrantes sea seguro mediante un balanceador de cargas HTTP(S) de Compute Engine (secciones 2.3 y 4.1). Para crear un balanceador de cargas HTTPS, necesitas lo siguiente:

  • Un subdominio de tu sitio web que se usa para tu formulario de procesamiento de pagos, por ejemplo, payments.your-domain-name.com
  • Un certificado SSL válido y firmado que se haya registrado para tu subdominio

Para asegurarte de que tu dominio sea válido, mira su configuración de DNS en la interfaz de configuración de dominio de tu registrador web.

Crea una imagen base de Linux

Las PCI DSS contienen requisitos que describen cómo configurar máquinas que forman parte de una arquitectura de procesamiento de pagos compatible. Puedes implementar estos requisitos de varias maneras, pero el enfoque más sencillo es el siguiente:

  1. Crea una lista del software y las bibliotecas que deben instalarse en cada servidor que esté dentro del alcance de tu app de procesamiento de pagos. Para evitar la introducción de vulnerabilidades innecesarias en tu sistema (requisito 2.2.2), incluye solo el mínimo de software y bibliotecas que necesitas para ejecutar tu app. Los candidatos pueden incluir el SDK de Cloud, los entornos de ejecución y bibliotecas específicos del lenguaje, o un servidor web.

  2. Crea una instancia de Compute Engine que use una de las imágenes de sistema operativo preconfiguradas de Compute Engine.

  3. Instala las bibliotecas y el software que enumeraste antes.

  4. Instala y configura ntp para mantener los relojes del sistema sincronizados. La administración de los relojes del servidor con el Protocolo NTP garantiza la integridad de las marcas de tiempo en los registros (sección 10.4).

  5. Asegúrate de que la imagen siga las recomendaciones para crear una imagen segura de Compute Engine (toda la sección 2.2).

  6. Una vez que configures tu imagen base, crea una imagen de disco personalizada de Compute Engine a partir de ella. Esta imagen te permite usar tu imagen base de Linux cuando creas instancias de máquinas virtuales.

Usa la administración segura de paquetes

La administración de paquetes es un componente clave de un entorno de hosting con seguridad endurecida. Según la sección 2.2, debes implementar los estándares de endurecimiento que acepte la industria. A menos que uses el SO optimizado para contenedores de Google, es probable que tengas un administrador de paquetes instalado como RPM, Yum o Apt. Tu app podría usar su propio administrador de paquetes específico del lenguaje de programación, como NPM, PyPi o Composer, y descargar las dependencias en la primera ejecución.

Si tu app puede obtener actualizaciones desde Internet, debes tratar las fuentes de actualización como un riesgo potencial de seguridad. Los ataques en el lado del suministro, o ataques anteriores, que se incluyen de forma maliciosa en paquetes alojados de manera pública, son cada vez más comunes. Imagina los efectos de instalar una actualización de SSH que contiene código malicioso.

Puedes mitigar el riesgo de ataques del lado del suministro si creas una lista de destinatarios seguros para tus paquetes y verificas que coinciden con la lista. Mantén una lista de los números de versión probados y aprobados para cada paquete que uses. Registra el número de versión junto con su hash o firma. Asegúrate de que el administrador de paquetes valide el hash o la firma antes de instalar o actualizar una app.

La mayoría de los sistemas de administración de paquetes permiten el hosting privado. Si es posible, inicia tu propio servidor privado de administración de paquetes y aloja solo el software probado y aprobado. Bloquea el administrador de paquetes de modo que no pueda comunicarse con otros servidores para obtener actualizaciones.

Lo ideal es que el proceso de compilación de tu app obtenga y valide todos los paquetes, y luego cree una revisión de la imagen de disco personalizada que incluya todo lo que el contenedor necesita. De esta manera, los servidores se lanzan y escalan sin demoras de instalación, y se reduce la posibilidad de errores aleatorios en el momento del lanzamiento. También puedes revisar cualquier versión anterior de tu app tal como estaba en producción con solo lanzar su imagen, lo cual puede ser útil para diagnósticos y análisis forense.

Implementación y configuración

A continuación, establece la implementación y configuración de tus instancias desde tu imagen base.

Implementa tu entorno

Para cumplir con los requisitos de las PCI DSS, asegúrate de que implementas la app correcta cada vez, de que lo haces de manera segura y de que no se implemente ningún otro paquete de software durante el proceso. A fin de simplificar el proceso, considera crear una implementación automatizada para tu app con Cloud Deployment Manager.

Cloud Deployment Manager te permite describir todo tu entorno de procesamiento de pagos, lo que incluye sus reglas de firewall, puertas de enlace, instancias y balanceadores de cargas. Cloud Deployment Manager también puede ayudarte a construir un registro de auditoría que muestre cómo se creó cada entorno de app y te permite controlar las versiones de los entornos a medida que los mejoras y modificas.

En una implementación automatizada, debes verificar la integridad del software que se implementa, ya sea tuyo o de un tercero. Puedes verificar tu software mediante la ejecución de un hash automatizado en cada paquete a medida que se instala. Una vez que se verifica un hash, puedes usar un marco de trabajo de pruebas automatizado para ejecutar las pruebas de seguridad y de otro tipo, y luego verificar que se hayan aprobado.

Por último, cuando implementas instancias de Compute Engine, debes diseñar un plan de recuperación en caso de que tus instancias fallen. Si tu ventana para un tiempo de inactividad aceptable es lo bastante grande, un plan de recuperación manual podría ser suficiente; en caso contrario, debes diseñar un plan de recuperación automatizado. Consulta Guía de planificación de recuperación ante desastres, Diseña sistemas robustos y Compila apps web escalables y resilientes para obtener orientación.

Configura tu entorno

Una vez implementadas las instancias, asegúrate de que estén configuradas de forma correcta. Instala software y bibliotecas adicionales encima de cada imagen base de instancia según sea necesario. Para evitar la complejidad, la sobrecarga y el riesgo general de la configuración manual, usa una herramienta de administración de configuración automatizada como Skaffold, Chef, Puppet, Ansible, o Salt.

Los ataques en la cadena de suministro en fuentes anteriores se están convirtiendo en una preocupación mayor, por lo que además de usar imágenes base de Linux, también deberías usar una herramienta como la API de Grafeas para auditar el código anterior.

Implementa Forseti Security

Forseti Security es una colección de herramientas de código abierto impulsadas por la comunidad que te ayudan a mejorar la seguridad de tus entornos de GCP. Su arquitectura modular te permite habilitar componentes individuales, varios de los cuales pueden abordar requisitos específicos dentro de las PCI DSS.

Inventory crea una instantánea de inventario de tus recursos de GCP para que tengas un registro histórico de tu arquitectura.

Scanner usa la información que recopila Forseti Inventory a fin de comparar de forma periódica las políticas de acceso basadas en funciones para tus recursos de GCP. Scanner aplica reglas para auditar recursos de GCP como los siguientes:

  • Políticas de Cloud Identity and Access Management (Cloud IAM) para organizaciones, carpetas y proyectos
  • LCA de depósitos
  • LCA de conjuntos de datos de BigQuery
  • Redes autorizadas de Cloud SQL

Con Scanner, puedes especificar usuarios, grupos y dominios permitidos, obligatorios o excluidos de los recursos, y puedes garantizar que estas políticas de acceso permanezcan coherentes. Si Scanner encuentra alguna política de acceso que no coincide con tus reglas de Scanner, puede guardar información sobre esas violaciones de las reglas en Cloud SQL o Cloud Storage. Esto ayuda a protegerte contra cambios inseguros o involuntarios.

Enforcer usa las políticas que creas para comparar el estado actual de tu firewall de Compute Engine con un estado específico. Enforcer es una herramienta de línea de comandos bajo demanda que compara las políticas en modo de lotes en todos los proyectos administrados o en los proyectos seleccionados. Si Enforcer encuentra alguna diferencia en las políticas, usa las API de GCP para realizar cambios y mostrar los resultados.

El módulo de complemento Explain proporciona visibilidad de tus Políticas de Cloud IAM. Explain puede ayudarte a comprender lo siguiente:

  • Quién tiene acceso a qué recursos y cómo ese usuario puede interactuar con el recurso.
  • Por qué un principal tiene permiso sobre un recurso, o por qué no lo tiene y cómo solucionarlo.
  • Qué funciones otorgan un permiso y cuáles no están sincronizadas con los cambios recientes.

También puedes configurar el envío de notificaciones por correo electrónico para Inventory y Scanner.

Implementa un registro de auditoría inmutable

Stackdriver produce registros de auditoría de forma automática para una amplia variedad de actividades en muchos productos. A largo plazo, puedes almacenar de forma segura los registros inmutables mediante los bloqueos de depósitos de Cloud Storage (sección 10.5). Los bloqueos de depósitos te permiten establecer una política para que todos los objetos sean inmutables y no se puedan borrar durante un período que especifiques, desde segundos hasta años. Si necesitas acceder al programa de acceso anticipado, comunícate con tu representante de GCP.

Implementa registros de flujo de nube privada virtual

El servicio de registros de flujo de VPC está diseñado para registrar los flujos de red que envían o reciben las instancias de máquinas virtuales. Puedes usar estos registros para supervisión de redes (sección 10.2), análisis forense (requisito 10.6.3) y análisis de seguridad en tiempo real.

Instala el agente de Logging

Después de configurar iptables en tus servidores, cada uno registra todas las actividades en el almacenamiento en bloque del servidor. Consulta la página de precios de Stackdriver para obtener detalles sobre la asignación gratuita y los precios de transferencia de datos. Para conservar estos registros y generar alertas basadas en actividades anormales, transmítelas a Logging y Monitoring mediante la instalación del Agente de Logging en cada servidor (requisito 10.5.3).

Integra un sistema de detección de intrusiones

Para ayudar a garantizar la seguridad de tu entorno de procesamiento de pagos, descrito en la sección 11.4, usa un sistema de detección de intrusiones (IDS) para saber cuándo los actores maliciosos intentan atacar el sistema. Hay dos formas de colocar un IDS en un entorno de procesamiento de pagos: colocar un IDS en cada punto de entrada o instalar un IDS en cada servidor.

Para reducir la complejidad de la arquitectura de tu entorno y simplificar el cumplimiento con 11.5, instala un IDS en cada servidor. Después de investigar y elegir el software de IDS que usarás, haz que la instalación del IDS forme parte de las secuencias de comandos de instalación de inicio para cada servidor.

Los registros de IDS se encuentran dentro del alcance del cumplimiento de las PCI DSS y deben enviarse a Logging y Monitoring para informes, alertas y auditorías.

Implementa Cloud Security Command Center

El servicio de Cloud SCC (Beta) ayuda a los equipos de seguridad a recopilar datos, identificar amenazas y responder a ellas antes de que causen daños o pérdidas en la empresa. Ofrece información detallada sobre el riesgo de las apps y los datos para que puedas mitigar con rapidez las amenazas a tus recursos en la nube y evaluar el estado general. Con Cloud SCC, puedes ver y supervisar un inventario de tus activos en la nube, analizar sistemas de almacenamiento en busca de datos sensibles, detectar vulnerabilidades web comunes y revisar los derechos de acceso a tus recursos vitales, todo desde un único panel centralizado. Puede ayudarte a cumplir con varios requisitos, incluidas las secciones 5 y 6.6.

Automatiza la implementación de tu app

Compila tu herramienta de administración de configuración para recuperar y luego iniciar de manera segura la última versión de tu app. Tu app se puede recuperar desde cualquier ubicación, como Cloud Storage, siempre que esa ubicación sea segura.

Muchas de las herramientas de administración de configuración mencionadas antes admiten flujos de trabajo de integración continua y de implementación continua (IC/EC), que también se pueden usar para realizar análisis automáticos (requisito 11.2.3) y garantizar que el código se revise (requisito 6.3.2).

Captura los registros del administrador de configuración

Cuando configuras tu administrador de configuración, asegúrate de que registre todos los detalles de la instalación. Después de completar el proceso de configuración, asegúrate de que los registros se entreguen a Logging y Monitoring.

Registros y supervisión

Para garantizar el cumplimiento de las PCI DSS en la sección 10, asegúrate de que se supervise y registre cada paso realizado en tu entorno de procesamiento de pagos. Se debe registrar cada actividad del servidor en cada instancia, y cada acción del usuario debe poder examinarse más adelante.

Habilita la Transparencia de acceso

A través de una característica llamada Transparencia de acceso, Stackdriver ahora ofrece registros casi en tiempo real cuando los administradores de GCP acceden a tu contenido. Los registros de Cloud Audit Logging ya proporcionan visibilidad de las acciones de tus propios administradores. Sin embargo, este registro de auditoría por lo general excluye las acciones que realiza el equipo de asistencia o de ingeniería de tu proveedor de servicios en la nube. Por ejemplo, antes del registro de Transparencia de acceso, si se abría una solicitud de Atención al cliente de Google que requería acceso a los datos, no se registraba en Cloud Audit Logging. La Transparencia de acceso resuelve esta disparidad, ya que captura registros casi en tiempo real de los accesos manuales orientados de los equipos de asistencia o de ingeniería.

Google lanzó hace poco la Aprobación de acceso (que se encuentra en la etapa de lanzamiento Acceso anticipado). Si bien la Transparencia de acceso proporciona información sobre los accesos de Atención al cliente de Google y de Ingeniería, la Aprobación de acceso te permite aprobar de forma explícita el acceso a tus datos o configuraciones en GCP antes de que se produzca ese acceso. Para obtener más detalles y solicitar acceso anticipado, consulta la página vinculada.

Habilita el Registro de reglas de firewall

El Registro de reglas de firewall te permite habilitar el registro en el nivel de las reglas individuales. Puede registrar conexiones TCP y UDP dentro de una VPC para cualquier regla que crees. Esto puede ser útil para auditar el acceso a la red o proporcionar una advertencia temprana de que la red se está usando de manera no aprobada.

Usa Controles del servicio de VPC

Los Controles del servicio de VPC (Beta) te permiten definir un perímetro de seguridad alrededor de los recursos de Google Cloud Platform, como los depósitos de Cloud Storage, las instancias de Cloud BigTable y los conjuntos de datos de BigQuery, para restringir los datos en una VPC y ayudar a mitigar los riesgos de robo de datos (requisitos 1.2.1 y 1.3.4). Con los Controles del servicio de VPC, puedes conservar la privacidad de tus datos sensibles mientras aprovechas las capacidades de procesamiento de datos y almacenamiento completamente administradas de Google Cloud Platform. Solicita acceso anticipado para obtener más información.

Configura los Registros de flujo de VPC

Entorno de datos del titular de la tarjeta con los Registros de flujo de VPC habilitados
CDE con los Registros de flujo de VPC habilitados

Los Registros de flujo de VPC registran los flujos de tráfico de red que envían o reciben las instancias de VM. Los registros son útiles bajo las PCI DSS para supervisión, auditoría, análisis forense y análisis de seguridad en tiempo real. Cada subred de una red de VPC puede tener los Registros de flujo habilitados o inhabilitados de manera independiente. Puedes minimizar la cantidad de datos de registro si solo habilitas Registros de flujo en tu CDE dentro del alcance.

Los Registros de flujo, combinados con las reglas de firewall de salida, te permiten limitar el tráfico saliente a los extremos autorizados de una manera auditable y difícil de eludir (requisitos 1.2.1 y 1.3.4).

Si necesitas datos más detallados que los que pueden proporcionar los Registros de flujo, como el registro de solicitudes HTTP individuales, puedes implementar controles en tu app o solicitudes de salida de proxy. Esto se hace través de tu propio servidor proxy inverso configurado para reenviar los registros de acceso a Stackdriver. Para obtener instrucciones sobre cómo configurar un servidor proxy de Squid en Compute Engine, consulta Configura un proxy de red. Para evitar los cuellos de botella, configura al menos dos servidores proxy redundantes.

Registra los datos de acceso interno

Además de registrar amenazas externas, debes supervisar y registrar la actividad de las personas que tienen acceso de administrador a tu entorno de procesamiento de pagos (sección 10.2). Para eso, puedes registrar comandos de shell. Varias herramientas de código abierto pueden auditar los comandos de shell y enviarlos al registro. Las opciones populares para esta tarea incluyen OSSEC o Tripwire.

Configura alertas de supervisión

Configura Monitoring para que envíe alertas si algo sale mal en tu entorno de procesamiento de pagos (sección 10.6). Asegúrate de que tus alertas abarquen eventos de entorno, de auditoría y eventos internos de las apps. Basa tu estrategia de alerta en el riesgo potencial o los vectores de ataque para cada componente de tu app de procesamiento de pagos. Por ejemplo, puedes activar las alertas de Monitoring si tu IDS detecta cualquier intento de intrusión, ya sea que tenga éxito o no. También puedes usar el Registro de reglas de firewall para activar alertas en respuesta a los intentos de violar políticas de red específicas.

Transmite los registros a BigQuery

Transmisión de los registros desde Stackdriver hacia Cloud Storage y BigQuery
Transmisión de los registros desde Stackdriver hacia Cloud Storage y BigQuery

De forma opcional, puedes exportar los registros de Stackdriver a BigQuery para analizarlos más adelante. Debido a que BigQuery está optimizado a fin de consultar grandes conjuntos de datos, es una herramienta ideal para el análisis de registros a gran escala. Stackdriver puede incluso acceder a BigQuery de forma directa para los registros que requieren un análisis casi en tiempo real (requisito 10.6.1).

Usa Cloud Data Loss Prevention para limpiar datos

Hay muchas razones, como las estadísticas o el desarrollo, para usar partes de los datos que no están dentro del alcance, pero están contenidos en tu app, que sí se encuentra dentro del alcance. Solo debes permitir que las apps accedan a los datos de PCI después de limpiarlos con Cloud Data Loss Prevention (requisito 6.4.3).

Seguridad de apps

Para ayudar a proteger tu app, primero debes evaluar la interfaz de administrador. También puedes usar Cloud Key Management Service.

Evalúa la interfaz de administrador

La mayoría de las apps de comercio electrónico tienen su propia interfaz de administrador que no es de consola, como un portal de facturación de atención al cliente. Esta herramienta debe tener controles de acceso robustos; acceso individualizado que use autenticación multifactor (sección 8.3); y estar equipada con un registro de auditoría (sección 10.2).

Cualquier registro que crees debe responder estas preguntas: ¿Quién hizo qué? ¿Dónde lo hicieron? ¿Cuándo lo hicieron? Según la sección 2.3, todo acceso a una herramienta de este tipo debe usar una encriptación de transporte fuerte. Usa Cloud Data Loss Prevention para filtrar la información sensible antes de mostrarla en cualquier herramienta de administración.

Usa Cloud Key Management Service (Cloud KMS)

Cloud KMS es un sistema de almacenamiento administrado para secretos. Puede generar, usar, rotar y destruir claves de encriptación AES-256. También puede almacenar y administrar otros secretos de hasta 64 KB. Cloud KMS te permite quitar las contraseñas almacenadas en archivos de configuración o código, lo que simplifica el cumplimiento de los requisitos 3.5, 3.6, 6.3.1 y 8.2.

Valida tu entorno

Debes validar tu entorno después de implementarlo, pero antes de que el tráfico de producción fluya a través de él:

  • Si eres un comercio de Nivel 1, a tu entorno debe validarlo un Asesor de Seguridad Calificado (QSA). Un QSA es una firma o una persona que tiene la aprobación del Consejo sobre Normas de Seguridad de la PCI para validar los entornos de PCI y otorgar el sello de aprobación.
  • Si eres un comercio de Nivel 2 o inferior, puedes llenar el Cuestionario de autoevaluación para validar tu entorno.

Pasos siguientes