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. La guía va más allá de los temas que se tratan en PCI SSC Cloud Computing Guidelines (Lineamientos de computación en la nube de las PCI SSC) (PDF) para proporcionar información sobre las normas, explicar tu función en el cumplimiento basado en la nube y brindarte los lineamientos pertinentes al diseño, la implementación y la configuración de una app de procesamiento de pagos mediante las PCI DSS. En el instructivo, también se analizan los métodos de supervisión, registro y validación de la 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, si no lo hacen, se las puede multar o penalizar.

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 el entorno de procesamiento de pagos
  • Implementar y configurar los servidores de la app
  • Configurar el registro y la supervisión
  • Validar el entorno de procesamiento de pagos

Definiciones

En esta guía, se usan muchas frases únicas. Estas son algunas de las más comunes. Para obtener más información, consulta el glosario de las PCI DSS.

CDE: Sigla de entorno de datos del titular de la tarjeta. Esta sigla se refiere a cualquier parte de la app que contiene o transfiere datos del titular de la tarjeta, lo que incluye el número de 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 número de cuenta principal, también conocido como 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 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 QSA Qualification Requirements (Requisitos de calificación de los QSA) a fin de obtener detalles sobre los requisitos para las empresas y los empleados de los QSA.

SAQ: Sigla de 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, los procedimientos y las 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. Luego, el PAN se almacena en una búsqueda segura. La desasignación de token es el proceso inverso a buscar un PAN según su token. Un token puede ser un hash o un valor asignado.

Segundo plano

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 principales numeradas y muchas subpartes. En este documento, se 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.

Los 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 en 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 Google Cloud es un proveedor de servicios que cumple con las PCI DSS 3.2.1 de Nivel 1, puede satisfacer tus necesidades de cumplimiento de las PCI DSS sin importar cuál sea el nivel de comercio de la 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. El tipo de SAQ está determinado por la arquitectura de la 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 el dominio (incluso a través de un formulario web <iframe>), completan el pago y, luego, regresan a la app.

En otras palabras, la empresa no puede tocar los datos de la tarjeta del cliente de ninguna manera.
A-EP Los 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, la app de procesamiento de pagos reenvía los datos de la tarjeta a un procesador del lado del cliente, o el procesador renderiza todo el contenido que alojes.
D Los comercios que aceptan pagos en línea y no califican para SAQ A ni SAQ A-EP. Este tipo incluye a todos los comercios 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 ni 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, y 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, y SAQ D es un superconjunto de SAQ A-EP.

Los comercios pueden ser de cualquier combinación de nivel y tipo, y los requisitos de cumplimiento varían mucho según las 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 validó de forma independiente los requisitos de las PCI DSS que se aplican a la infraestructura y las tecnologías de Google Cloud administradas por Google. 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 ni las apps que los comercios implementan en Google Cloud. Es tu responsabilidad cumplir con los requisitos de las PCI DSS para el sistema operativo, los paquetes y las apps que implementas, además de otras personalizaciones que requiera tu arquitectura.

Google Cloud 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. En la Matriz de responsabilidad compartida de Google Cloud, se describen las obligaciones de cumplimiento de 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 entrada 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 Google Cloud diferente. Compute Engine y GKE son las alternativas recomendadas.

Cloud Functions

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

Google Kubernetes Engine

Trata los nodos y los 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 plano de control (instancia principal del clúster), usa redes autorizadas para bloquear las direcciones IP no confiables desde fuera de Google Cloud. Estas reglas CIDR son compatibles con los clústeres privados y funcionan como una lista de entidades permitidas (también denominada lista blanca).

Implementa políticas de red en el clúster de GKE cuando los proyectos dentro del alcance contienen diferentes tipos de Pods. Las políticas de red funcionan de manera similar a los firewalls de 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 en el que 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 ni los hashes unidireccionales que también las reglas requieren.

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 ni las apps ni las páginas de comercios 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.

Información de procesamiento entre el navegador del cliente, el sitio del comercio, el procesador de pagos y la puerta de enlace de pago.
Arquitectura de un entorno de procesamiento de pagos de terceros de SAQ A

SAQ A-EP

La arquitectura de procesamiento de pagos de 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 se supervisan mediante Cloud Logging y Cloud Monitoring.

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

SAQ D

La arquitectura de procesamiento de pagos de 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 pagos 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 mediante Logging y Monitoring.

Arquitectura de un entorno de procesamiento de pagos de SAQ D
Arquitectura de un entorno de procesamiento de pagos de 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 de SAQ A
Flujo orientado al cliente del procesamiento de pagos de terceros de SAQ A

Cuando el cliente accede al formulario de pago, la app presenta un <iframe> alojado por el procesador de pagos. La app no puede acceder al contenido del <iframe> o supervisarlo debido a las limitaciones del uso compartido de recursos entre dominios. 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 la app. Esta verifica la respuesta de la 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 de SAQ A-EP
Flujo orientado al cliente del procesamiento de pagos de terceros de SAQ A-EP

Cuando el cliente accede a la URL del formulario de pago, el sitio presenta un formulario alojado por 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, redirige al cliente a la app. Luego, esta verifica la respuesta de la 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 de SAQ D
Flujo orientado al cliente del procesamiento de pagos de terceros de SAQ D

Cuando el 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 de HTTPS. Cuando el cliente envía la información de la 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, la app de procesamiento de pagos finaliza 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. La app recibe y procesa la respuesta y, luego, envía algunos o todos los datos de respuesta a la app principal. En este punto, la app de procesamiento de pagos finaliza 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 el entorno de procesamiento de pagos. La configuración incluye los siguientes pasos:

  • Crear una cuenta de Google Cloud nueva para aislar el entorno de procesamiento de pagos del entorno de producción
  • Restringir el acceso al entorno
  • Configurar los 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 cuenta nueva

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 Google Cloud distinta de la cuenta de entorno de producción principal. Los usuarios que tengan experiencia en la configuración de administración de identidades y accesos (IAM) pueden lograr un aislamiento equivalente mediante proyectos distintos para el trabajo dentro del permiso.

Restringe el acceso al 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 funciones de IAM para restringir el acceso. Las prácticas recomendadas 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 raíz completo a tus servicios. Consulta la guía de seguridad de 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 a nivel de la cuenta de servicio a través de funciones de IAM y reglas de firewall de VPC.

Cuando aplicas reglas de IAM a las carpetas, todos los elementos contenidos en ellas las heredan. 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.

En la sección 12.7 de las PCI DSS SAQ D, se requiere que las personas con acceso a tu entorno dentro del alcance pasen una verificación de antecedentes, en 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 tu red de apps de procesamiento de pagos y hacia ella, 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 una VPC, recomendamos Cloud NAT a fin de tener una capa de seguridad de red adicional. Hay muchas opciones potentes disponibles para proteger las redes de las instancias de Compute Engine y de 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 la página de pago
  • Tu red de apps, de modo que tu app de procesamiento de pagos pueda recibir respuestas del 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, mediante etiquetas de red y reglas de firewall de 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 de DNS privado 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:

Origen Destino Puerto Dirección y motivo
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
Aceptación de solicitudes AUTH de sistemas de pago (no contiene ningún dato del titular de la tarjeta)
Red de las 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:

Origen Destino Puerto Motivo
Formulario de tarjeta Proxy PCI tcp:5480 Intercambio de datos de tarjetas encriptados para token de instrumentos de pagos
Todos los hosts Servidores NTP de Google udp:123 Sincronización temporal
Puerta de enlace de 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 de HTTPS

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

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

Para asegurarte de que tu dominio sea válido, mira su configuración de DNS en la interfaz de configuración de dominio del 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 el sistema (requisito 2.2.2), incluye solo el mínimo de software y bibliotecas que necesitas a fin de ejecutar la app. Los candidatos pueden incluir el SDK de Cloud, los entornos de ejecución y las 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 prácticas recomendadas para crear una imagen segura de Compute Engine (toda la sección 2.2).

  6. Una vez que configures la imagen base, crea una imagen de disco personalizada de Compute Engine a partir de ella. Esta imagen te permite usar la 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 Container-Optimized OS 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 ascendentes, 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 coincidan 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 recupere y valide todos los paquetes, y 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 del instalador, 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 detección de intrusiones.

Implementación y configuración

A continuación, establece la implementación y configuración de las instancias desde la 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 mediante Cloud Deployment Manager.

Deployment Manager te permite describir todo el entorno de procesamiento de pagos, que incluye las reglas de firewall, las puertas de enlace, las instancias y los balanceadores de cargas. Deployment Manager también puede ayudarte a construir un registro de auditoría que muestre cómo se creó el entorno de cada 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 framework de pruebas automatizado para ejecutar las pruebas de seguridad y de otro tipo, y 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 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 aplicaciones web escalables y resilientes para obtener orientación.

Configura el 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 ascendentes se están convirtiendo en una preocupación mayor, por lo que además de usar imágenes base de Linux, recomendamos usar una herramienta como la API de Grafeas para auditar el código ascendente.

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 Google Cloud. 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 Google Cloud para que tengas un registro histórico de la 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 Google Cloud. Scanner aplica reglas para auditar recursos de Google Cloud como los siguientes:

  • Políticas de administración de identidades y accesos (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 a pedido 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 Google Cloud para realizar cambios y mostrar los resultados.

El módulo de complemento Explain proporciona visibilidad en tus políticas de 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é una cuenta 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

Logging 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 Google Cloud.

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), detección de intrusiones (requisito 10.6.3) y análisis de seguridad en tiempo real.

Instala el agente de Logging

Después de configurar iptables en los servidores, cada uno registra todas las actividades en el almacenamiento en bloque del servidor. Consulta la página de precios de Logging para obtener detalles sobre los precios de la asignación gratuita y la transferencia de datos. Para conservar estos registros y generar alertas basadas en actividades anormales, transmítelos 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 del entorno de procesamiento de pagos, descrito en la sección 11.4, usa un sistema de detección de intrusiones (IDS) a fin de saber cuándo las entidades maliciosas 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 del entorno y simplificar el cumplimiento de 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 Security Command Center

El servicio de Security Command Center (Beta) ayuda a los equipos de seguridad a recopilar datos, identificar amenazas y tomar medidas al respecto antes de que se produzcan daños o pérdidas en las empresas. 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 Security Command Center, puedes ver y supervisar un inventario de los elementos en la nube, analizar los sistemas de almacenamiento en busca de datos sensibles, detectar vulnerabilidades comunes de la Web y revisar los derechos de acceso a los recursos esenciales, todo desde un solo panel centralizado. Puede ayudarte a cumplir con varios requisitos, incluidas las secciones 5 y 6.6.

Automatiza la implementación de tu app

Compila la herramienta de administración de configuración para recuperar e iniciar de manera segura la última versión de tu app. La 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 (CI/CD), 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.

Registro 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 que se realiza 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 función llamada Transparencia de acceso, Logging ahora ofrece registros casi en tiempo real cuando los administradores de Google Cloud acceden al contenido. Los registros de auditoría de Cloud 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 un ticket de Atención al cliente de Google que requería acceso a los datos, no se registraba en los registros de auditoría de Cloud. 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. La aprobación de acceso se encuentra en la etapa de lanzamiento de acceso anticipado. Si bien la Transparencia de acceso proporciona información sobre los accesos de Ingeniería y de Atención al cliente de Google, la aprobación de acceso te permite aprobar de forma explícita el acceso a tus datos o configuraciones en Google Cloud 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 a nivel de las reglas individuales. Puede registrar conexiones de 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 los 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, 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 los datos sensibles mientras aprovechas las capacidades de procesamiento de datos y almacenamiento completamente administradas de Google Cloud. 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, detección de intrusiones 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 en las solicitudes de salida del proxy. Esto se hace través de tu propio servidor proxy inverso configurado para reenviar los registros de acceso a Logging. 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. Entre las opciones populares para esta tarea, se 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 las alertas abarquen eventos de entorno, de auditoría y eventos internos de las apps. Basa tu estrategia de alertas en el riesgo potencial o los vectores de ataque para cada componente de tu app de procesamiento de pagos. Por ejemplo, activa las alertas de Monitoring si el IDS detecta cualquier intento de intrusión, 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

Registros de transmisión de Logging hacia Cloud Storage y BigQuery
Registros de transmisión de Logging hacia Cloud Storage y BigQuery

De forma opcional, puedes enrutar los registros de Logging a BigQuery para analizarlos más adelante. Consulta Descripción general del enrutamiento y el almacenamiento: Receptores para obtener más información. 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. Incluso, Logging puede acceder a BigQuery directamente 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 permiso. 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 las apps

Para ayudar a proteger la 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 de varios factores (sección 8.3); y debe 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 servicio que te permite administrar claves de encriptación. Puede generar, usar, rotar y destruir claves de encriptación AES-256, RSA 2048, RSA 3072, RSA 4096, EC P256 y EC P384. Cloud KMS te permite quitar las contraseñas de texto sin formato 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 evaluador de seguridad certificado (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 completar el cuestionario de autoevaluación para validar tu entorno.

¿Qué sigue?