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.
En este documento, se hace referencia a los requisitos de las PCI DSS 4.0 cuando corresponda.
Las Normas de seguridad de datos de la PCI, creadas por PCI Security Standards Council, 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, JCB o UnionPay 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 que se pueden considerar si una entidad no puede cumplir con un requisito explícito, debido a restricciones comerciales legítimas o documentadas. Las entidades deben mitigar lo suficiente el riesgo asociado con el requisito cuando implementan estos otros controles. Consulta “Controles de compensación”, Apéndices B y C, en Requisitos y procedimientos de evaluación de la seguridad de las PCI DSS para obtener orientación sobre el uso de los controles de compensación.
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. Los Requisitos de calificación para los evaluadores de seguridad calificados (QSA) proporcionan detalles sobre los requisitos para las empresas y los empleados de 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. Esto solo se aplica a las entidades que son aptas para realizar una autoevaluación.
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 4.0 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. En la sección Compromiso con el cumplimiento, se 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 si eres apto para la autoevaluación. 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. |
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. Puedes descargar los informes de cumplimiento de las PCI DSS de Google desde el Administrador de informes de cumplimiento. 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
En esta sección, se proporciona orientación para los servicios de Google Cloud más utilizados en arquitecturas usadas para entornos de PCI DSS.
App Engine
Usa las reglas de firewall de entrada de App Engine y los controles de tráfico de salida.
Cloud Run
Usa la configuración de entrada de Cloud Run, los Controles del servicio de VPC y los controles de salida en los conectores de VPC. Si es necesario, configura una dirección IP saliente estática.
Cloud Functions
Usa la configuración de red de entrada y salida de Cloud Functions.
Cloud Logging
Registra las interacciones con Cloud Logging
Cloud Monitoring
Supervisa las interacciones con Cloud Monitoring.
Google Kubernetes Engine
Si deseas obtener información sobre el uso de Google Kubernetes Engine para entornos de PCI DSS, consulta Cumplimiento de PCI DSS en GKE.
Cloud Storage
El requisito 3.5 estipula que un número de cuenta principal (PAN) está protegido donde sea que esté almacenado. 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:
El cliente realiza sus selecciones y procede a pagar.
La app de pagos redirecciona al cliente a un procesador de pagos de terceros.
El cliente ingresa la información de su tarjeta de pago en un formulario de pago que posee y mantiene el procesador de terceros.
El procesador de pagos de terceros verifica la información de la tarjeta de pago y, luego, cobra o rechaza la tarjeta.
Después de procesar la transacción, redirige al cliente a la app del comercio junto con los detalles de la transacción.
La app del comercio envía una solicitud de verificación al procesador de pagos para confirmar la transacción.
El procesador de pagos responde para verificar los detalles de la transacción.
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:
El cliente ingresa la información de su tarjeta de pago en un formulario de pago que posee y mantiene tu empresa.
Cuando el cliente envía sus datos, la información del formulario se pasa de manera segura a un procesador de pagos de terceros.
El procesador de pagos de terceros verifica la información de la tarjeta de pago y, luego, cobra o rechaza la tarjeta.
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.
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:
El cliente ingresa la información de su tarjeta de pago en un formulario de pago que posee y mantiene tu empresa.
Cuando el cliente envía sus datos, tu app de pagos recibe la información del formulario.
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.
El procesador de pagos de terceros verifica la información de la tarjeta de pago y, luego, cobra o rechaza la tarjeta.
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.
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.
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.
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.
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.
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.
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:
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.5.3). 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.2 y requisito 8.2.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.3.6 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:
- Políticas de firewall de nueva generación de Cloud o reglas de firewall de Compute Engine
- Un túnel VPN de Cloud
- Un balanceador de cargas de aplicaciones externo
Para crear una VPC, también recomendamos Cloud NAT para 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 políticas de firewall de nueva generación de Cloud o reglas de firewall de VPC para restringir el tráfico entrante a cada una de las instancias de Compute Engine (requisitos 1.3 y 1.4). 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. Para probar tu trabajo, consulta la sección Registro de reglas de firewall más adelante en este documento.
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
Puedes usar Cloud VPN para establecer un túnel VPN seguro entre el entorno local y el entorno de procesamiento de pagos (secciones 2.2.7 y 4.2).
Crea un balanceador de cargas de aplicaciones externo
Para ayudar a garantizar que el tráfico de clientes entrante sea seguro, puedes crear un balanceador de cargas de aplicaciones externo (secciones 2.2.7 y 4.2). Para crear un balanceador de cargas de aplicaciones externo, 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:
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.4), incluye solo el mínimo de software y bibliotecas que necesitas para ejecutar la app. Los candidatos pueden incluir Google Cloud CLI, los entornos de ejecución y las bibliotecas específicos del lenguaje, o un servidor web.
Crea una instancia de Compute Engine que use una de las imágenes de sistema operativo preconfiguradas de Compute Engine.
Instala las bibliotecas y el software que enumeraste antes.
Instala y configura
ntppara 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.6).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).
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; para ello, lanza 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. Para simplificar el proceso, considera crear una implementación automatizada para tu app a través de Terraform. Terraform te permite describir todo el entorno de procesamiento de pagos, incluidas las reglas de firewall, las puertas de enlace, los balanceadores de cargas y las instancias en el código.
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.
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; para ello, usa los bloqueos de buckets de Cloud Storage (sección 10.3). 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.
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, detección de intrusiones y análisis de seguridad en tiempo real (sección 10.2).
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 sospechosas, transmítelos a Logging y Monitoring a través de la instalación del agente de Logging en cada servidor (sección 10.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.5, usa un sistema de detección de intrusiones (IDS) para saber cuándo las entidades que actúan de mala fe 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.
El Sistema de detección de intrusiones de Cloud (IDS de Cloud), un servicio de detección de intrusiones, proporciona detección de amenazas para intrusiones, software malicioso, software espía y ataques de comando y control en tu red. También proporciona visibilidad total del tráfico de red, incluido el tráfico norte-sur y este-oeste, lo que te permite supervisar la comunicación de VM a VM para detectar movimientos laterales. También puedes usar IDS de Cloud para simplificar el cumplimiento del requisito 11.5.
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
Security Command Center 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.4.
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 configuraciones 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 (sección 11.3) y garantizar que el código se revise (requisito 6.2.3).
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.
Habilitar la Transparencia de acceso
A través de la 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 Aprobación 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 Aprobación 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.
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. La Aprobación de acceso también proporciona estadísticas sobre los accesos de Atención al cliente y de Ingeniería de Google.
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 te permiten definir un perímetro de seguridad alrededor de los recursos de Google Cloud, como los buckets de Storage, las instancias de Cloud Bigtable y los conjuntos de datos de BigQuery, para restringir los datos en una red de VPC y ayudar a mitigar los riesgos de robo de datos (requisitos 1.3.1 y 1.3.2). 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.
Configura los registros de flujo de VPC
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).
En el siguiente diagrama, se muestra cómo los registros de flujo de VPC registran los flujos de tráfico de red que envían o reciben las instancias de VM.
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
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.4.1).
Usa Sensitive Data Protection 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 Sensitive Data Protection (requisito 6.5.1).
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 sólidos; acceso individualizado que use autenticación de varios factores (sección 8.4); 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.2.7, todo el acceso a una herramienta de este tipo debe usar una encriptación de transporte fuerte. Usa Sensitive Data Protection para filtrar 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 las secciones 2.2.2, 3.6, 3.7 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?
- Biblioteca de documentos de las PCI DSS
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.