En esta guía se explica cómo implementar el estándar de seguridad de los datos del sector de las tarjetas de pago (PCI DSS) en tu empresa en Google Cloud. Esta guía va más allá de las directrices de cloud computing del PCI SSC (PDF) para ofrecer información general sobre el estándar, explicar tu papel en el cumplimiento de los requisitos en la nube y, a continuación, proporcionarte las directrices para diseñar, implementar y configurar una aplicación de procesamiento de pagos con PCI DSS. En el tutorial también se explican métodos para monitorizar, registrar y validar tu aplicación.
En este documento se hace referencia a los requisitos de PCI DSS 4.0 cuando procede.
El estándar de seguridad de datos del PCI, creado por el PCI Security Standards Council, es un estándar de seguridad de la información para las empresas que gestionan información de tarjetas de pago (tanto de crédito como de débito). El Consejo de Estándares de Seguridad de PCI incluye a todas las principales empresas de tarjetas de pago. Las empresas que aceptan Visa, MasterCard, Discover, American Express, JCB o UnionPay deben cumplir el estándar PCI DSS. De lo contrario, pueden recibir multas o sanciones.
La normativa PCI DSS incluye clasificaciones para varios tipos de comercios, desde los que recogen información de pago en persona hasta los que subcontratan por completo el procesamiento de los pagos. Esta guía abarca los tipos de comerciantes SAQ A, SAQ A-EP y SAQ D.
Objetivos
- Revisa la arquitectura de la aplicación de procesamiento de pagos.
- Configura tu entorno de procesamiento de pagos.
- Implementa y configura tus servidores de aplicaciones.
- Configura el almacenamiento de registros y la monitorización.
- Valida tu entorno de procesamiento de pagos.
Definiciones
En esta guía se usan muchas frases únicas. A continuación, se indican algunos de los más habituales. Para obtener más información, consulta el glosario de PCI DSS.
CDE acrónimo de cardholder data environment. Esta sigla hace referencia a cualquier parte de tu aplicación que contenga o transfiera datos de titulares de tarjetas, incluido el número de cuenta de pago o cualquier información personal identificable relacionada con la tarjeta.
Controles compensatorios: soluciones alternativas que se pueden considerar si una entidad no puede cumplir un requisito de forma explícita, debido a limitaciones técnicas legítimas o a limitaciones empresariales documentadas. Las entidades deben mitigar suficientemente el riesgo asociado al requisito cuando implementen estos otros controles. Consulta los apéndices B y C de "Controles compensatorios" en el documento Requisitos y procedimientos de evaluación de seguridad de PCI DSS para obtener información sobre el uso de controles compensatorios.
PAN: acrónimo 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 acrónimo de Qualified Security Assessor (evaluador de seguridad cualificado). El Consejo de Estándares de Seguridad de PCI (SSC) cualifica a los QSAs para llevar a cabo evaluaciones in situ de PCI DSS. En los requisitos de cualificación para evaluadores de seguridad cualificados (QSA) se detallan los requisitos que deben cumplir las empresas y los empleados de QSA.
Cuestionario de autoevaluación (SAQ): acrónimo de Self-Assessment Questionnaire, la herramienta de informes que se usa para documentar los resultados de la autoevaluación de una entidad según el estándar PCI DSS. Esto solo se aplica a las entidades que pueden hacer una autoevaluación.
Ámbito: los sistemas, los procedimientos y las personas que se incluirán en una evaluación del PCI DSS.
Tokenización: proceso que sustituye el número de cuenta principal (PAN) por un valor sustituto llamado token. A continuación, el PAN se almacena en una búsqueda segura. La destokenización es el proceso inverso de buscar un PAN por su token. Un token puede ser un hash o un valor asignado.
Fondo
PCI DSS proporciona una lista de requisitos diseñada para mejorar la seguridad de los titulares de tarjetas. Estos requisitos se dividen en doce partes principales numeradas y muchas subpartes. En este documento se hace referencia a estos números de pieza para añadir contexto, pero las referencias de sección no son una lista exhaustiva de los requisitos aplicables.
Los requisitos de cumplimiento de PCI DSS varían en función de cómo gestione tu empresa las transacciones con tarjetas de pago (tipo) y del número de transacciones que realice cada año (nivel).
A medida que aumenta el número de transacciones, también lo hace el nivel de cumplimiento de PCI DSS de su comercio, y las directrices de cumplimiento de PCI DSS se vuelven más estrictas. En el nivel de comerciante más alto, el nivel 1, PCI DSS requiere una auditoría. Los niveles varían según la marca de la tarjeta. American Express define el nivel 1 como 2, 5 millones de transacciones anuales, mientras que Visa, Mastercard y Discover lo definen como 6 millones de transacciones anuales. Cada marca de tarjeta tiene requisitos de nivel adicionales que no se incluyen en este documento. Asegúrate de que tu entorno de procesamiento de pagos se audite para admitir tu nivel de comercio.
Como Google Cloud es un proveedor de servicios que cumple el nivel 1 del estándar PCI DSS 4.0, puede ayudarte a cumplir los requisitos de este estándar, independientemente del nivel de comerciante de tu empresa. En la sección Comprometidos con el cumplimiento se indica qué áreas cubre Google.
La otra variable fundamental es el tipo de SAQ. El cuestionario de autoevaluación describe los criterios que debes cumplir para cumplir el estándar PCI DSS si cumples los requisitos para realizar una autoevaluación. El tipo de cuestionario de autoevaluación se determina en función de la arquitectura de tu aplicación y de la forma precisa en que gestionas los datos de las tarjetas de pago. La mayoría de los comerciantes de la nube son de uno de los siguientes tipos:
Tipo de SAQ | Descripción |
---|---|
A | Comerciantes que han externalizado por completo el procesamiento de tarjetas de pago a un sitio de terceros. Los clientes abandonan tu dominio (incluso a través de un <iframe> formulario web), completan el pago y vuelven a tu aplicación. En otras palabras, tu empresa no puede acceder a los datos de las tarjetas de los clientes de ninguna manera. |
A-EP | Comerciantes que subcontratan el procesamiento de pagos a un proveedor externo, pero que pueden acceder a los datos de las tarjetas de los clientes en cualquier momento del proceso. Entre los comerciantes que pueden acceder a los datos de las tarjetas se incluyen los elementos de la página controlados por el comerciante, como JavaScript o CSS, que están insertados en la página de pago de terceros. Es decir, tu aplicación de procesamiento de pagos reenvía los datos de la tarjeta a un procesador del lado del cliente, o bien el procesador renderiza el contenido que alojes. |
D | Comercios que aceptan pagos online y no cumplen los requisitos de los cuestionarios de autoevaluación A o A-EP. Este tipo incluye a todos los comerciantes que llaman a una API de procesador de pagos desde sus propios servidores, independientemente de la tokenización. Es decir, si no eres SAQ A ni SAQ A-EP, eres SAQ D. El cuestionario de autoevaluación D distingue entre comerciantes y proveedores de servicios. En este documento no se habla de los proveedores de servicios y todas las referencias a la SAQ D se dirigen a los comerciantes tal como se definen en el estándar PCI DSS. |
Compromiso con el cumplimiento
Google utiliza diversas tecnologías y procesos para proteger la información que se almacena en los servidores de Google. Google ha validado de forma independiente los requisitos de PCI DSS que se aplican a las Google Cloud tecnologías y la infraestructura que gestiona Google. Puedes descargar los informes de cumplimiento de PCI DSS de Google desde el Administrador de informes de cumplimiento. Aunque Google ofrece a los comerciantes un gran control sobre sus instancias de computación que se ejecutan en la infraestructura de Google, Google no controla la seguridad del sistema operativo, los paquetes ni las aplicaciones que los comerciantes implementan en Google Cloud. Es tu responsabilidad cumplir los requisitos de PCI DSS para los paquetes y las aplicaciones del sistema operativo que implementes, así como otras personalizaciones que requiera tu arquitectura.
Google Cloud cumple los requisitos del PCI DSS establecidos para los proveedores de servicios de nivel 1 y todos los requisitos aplicables a los proveedores de servicios. LaGoogle Cloud matriz de responsabilidades compartidas describe las obligaciones de cumplimiento del PCI DSS. La matriz de responsabilidades puede ser una referencia útil para cumplir el estándar PCI DSS y realizar tus propias auditorías de PCI DSS.
Guía de productos
En esta sección se incluyen directrices para los servicios de Google Cloud que se suelen usar en arquitecturas empleadas en entornos PCI DSS.
App Engine
Usa las reglas de cortafuegos de entrada y los controles de tráfico de salida de App Engine.
Cloud Run
Usa la configuración de entrada de Cloud Run, Controles de Servicio de VPC y controles de salida en conectores de VPC. Si es necesario, configura una dirección IP de salida estática.
Cloud Run Functions
Usa la configuración de red de entrada y salida de las funciones de Cloud Run.
Cloud Logging
Registra las interacciones con Cloud Logging.
Cloud Monitoring
Monitoriza las interacciones con Cloud Monitoring.
Google Kubernetes Engine
Para obtener información sobre cómo usar Google Kubernetes Engine en entornos de PCI DSS, consulta Cumplimiento del PCI DSS en GKE.
Cloud Storage
El requisito 3.5 estipula que el número de cuenta principal (PAN) debe protegerse dondequiera que se almacene. Aunque Google ofrece automáticamente el cifrado en reposo, no realiza automáticamente los hashes unidireccionales, la truncación ni la tokenización que también requieren las reglas.
Ejemplos de arquitecturas
En esta sección se ilustran los enfoques para implementar un entorno que cumpla los requisitos de los cuestionarios de autoevaluación A, A-EP y D.
Información general sobre la arquitectura
SAQ A
El cuestionario de autoevaluación A es la arquitectura de procesamiento de pagos más básica. Los pagos los procesa un tercero y las aplicaciones o páginas del comerciante no acceden a los datos de las tarjetas.
A grandes rasgos, el flujo de procesamiento de pagos es el siguiente:
El cliente hace sus selecciones y procede a tramitar la compra.
La aplicación de tramitación de la compra redirige al cliente a un procesador de pagos externo.
El cliente introduce la información de su tarjeta de pago en un formulario de pago que el procesador externo posee y mantiene.
El procesador de pagos externo comprueba la información de la tarjeta de pago y, a continuación, la carga o la rechaza.
Después de procesar la transacción, el procesador de pagos externo envía al cliente de vuelta a la aplicación del comerciante junto con los detalles de la transacción.
La aplicación del comerciante 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.
Cuestionario de autoevaluación A - EP
La arquitectura de procesamiento de pagos del cuestionario de autoevaluación A-EP se centra en una aplicación 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 que están fuera de la red.
A grandes rasgos, el flujo de procesamiento de pagos es el siguiente:
El cliente introduce los datos de su tarjeta de pago en un formulario de pago que tu empresa posee y mantiene.
Cuando el cliente envía su información, los datos del formulario se transfieren de forma segura a un procesador de pagos de terceros.
El procesador de pagos externo comprueba la información de la tarjeta de pago y, a continuación, la carga o la rechaza.
El procesador de pagos envía una respuesta a tu aplicación de pagos, que a su vez envía un mensaje a tu aplicación principal.
Todas estas interacciones se registran y monitorizan con Cloud Logging y Cloud Monitoring.
SAQ D
La arquitectura de procesamiento de pagos de la SAQ D se centra en una aplicación 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 que están fuera de la red.
A grandes rasgos, el flujo de procesamiento de pagos es el siguiente:
El cliente introduce los datos de su tarjeta de pago en un formulario de pago que tu empresa posee y mantiene.
Cuando el cliente envía su información, tu aplicación de pagos recibe la información del formulario.
Tu aplicación de pagos valida la información para pagos y la transfiere de forma segura a un procesador de pagos externo a través de una API backend.
El procesador de pagos externo comprueba la información de la tarjeta de pago y, a continuación, la carga o la rechaza.
El procesador de pagos envía una respuesta a tu aplicación de pagos, que a su vez envía un mensaje a tu aplicación principal.
Todas estas interacciones se registran y monitorizan con Logging y Monitoring.
Flujo visible para el cliente del procesamiento de pagos
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 aplicación.
Cuando tu cliente accede al formulario de pago, la aplicación presenta un <iframe>
alojado por el procesador de pagos. Tu aplicación no puede acceder ni monitorizar el contenido de <iframe>
debido a las limitaciones de intercambio de recursos entre orígenes.
Cuando el cliente envía la información de su tarjeta de pago, el procesador de pagos acepta o rechaza la tarjeta y, a continuación, devuelve al cliente a tu aplicación. Después, tu aplicación comprueba la respuesta de la transacción del procesador de pagos y actúa en consecuencia. Tu aplicación no ha accedido a información de tarjetas de pago ni la ha gestionado.
Cuestionario de autoevaluación A - EP
En esta sección se describe el mismo flujo de procesamiento de pagos interno que se ha explicado anteriormente, pero desde la perspectiva de los clientes que usan tu aplicación.
Cuando tu cliente accede a la URL de tu formulario de pago, el sitio muestra un formulario alojado por tu aplicación de pagos. Cuando el cliente envía la información de su tarjeta de pago, el formulario se envía directamente al procesador de pagos. El procesador acepta o rechaza la tarjeta y, a continuación, devuelve al cliente a tu aplicación. Después, tu aplicación comprueba la respuesta de la transacción del procesador de pagos y actúa en consecuencia. Es posible que el cliente no vea el procesador de pagos externo, pero tu aplicación no ha accedido a ninguna información de tarjeta de pago en el lado del servidor.
SAQ D
En esta sección se describe el flujo interno del procesamiento de pagos desde la perspectiva de los clientes que usan tu aplicación.
Cuando tu cliente accede a la URL de tu formulario de pago, se le redirige de forma segura al formulario a través de un balanceador de carga HTTPS. Cuando el cliente envía la información de su tarjeta de pago, tu aplicación de procesamiento de pagos envía la información de forma segura a un procesador de pagos externo. El procesador de pagos externo acepta o rechaza la tarjeta y, a continuación, devuelve una respuesta a tu aplicación de procesamiento de pagos.
Flujo interno de procesamiento de pagos
Cuestionario de autoevaluación 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 aplicación.
Tu aplicación de procesamiento de pagos recibe y analiza la respuesta devuelta por el procesador de pagos externo y, a continuación, envía algunos o todos los datos de la respuesta a la aplicación principal. En este punto, tu aplicación de procesamiento de pagos habrá completado la transacción. La aplicación principal se encarga de notificar a tus clientes.
SAQ D
En esta sección se describe el flujo interno de procesamiento de pagos desde la perspectiva de los servidores que ejecutan tu aplicación.
Tu aplicación de procesamiento de pagos valida la información de la tarjeta de pago que ha enviado el cliente y, a continuación, la envía al procesador de pagos a través de una API backend. El procesador intenta realizar el cargo y responde con los detalles de la transacción. Tu aplicación recibe y procesa la respuesta y, a continuación, envía algunos o todos los datos de la respuesta a la aplicación principal. En este punto, tu aplicación de procesamiento de pagos ha terminado con la transacción. La aplicación principal se encarga de notificar al cliente y de entregar el producto.
Monitorizar y registrar el flujo de datos
El flujo de monitorización y registro se ha diseñado de la siguiente manera:
Configurar el entorno de procesamiento de pagos
En esta sección se describe cómo configurar el entorno de procesamiento de pagos. La configuración incluye lo siguiente:
- Crear una cuenta Google Cloud para aislar tu entorno de procesamiento de pagos del entorno de producción.
- Restringir el acceso a tu entorno.
- Configuración de los recursos virtuales.
- Diseñar la imagen base de Linux que usarás para configurar tus servidores de aplicaciones.
- Implementar una solución de gestión de paquetes segura.
Configurar una cuenta
Para simplificar la restricción de acceso y la auditoría de cumplimiento, crea un entorno de procesamiento de pagos de calidad de producción que esté totalmente aislado de tu entorno de producción estándar y de cualquier entorno de desarrollo y control de calidad (requisito 6.5.3). Para garantizar el aislamiento, crea y usa una cuenta de Google Cloud que esté separada de tu cuenta de entorno de producción principal. Los usuarios con experiencia en la configuración de gestión de identidades y accesos (IAM) pueden conseguir un aislamiento equivalente usando proyectos independientes para el trabajo incluido en el ámbito.
Restringir el acceso a tu entorno
Permita el acceso al entorno de procesamiento de pagos solo a las personas que implementen el código de su sistema de pagos o gestionen las máquinas de su sistema de pagos (sección 7.2 y requisito 8.2.1). Este concepto se conoce como principio de mínimos accesos. Usa roles de gestión de identidades y accesos para restringir el acceso. Entre las prácticas recomendadas se incluyen el uso de roles siempre que sea posible, la concesión únicamente de los permisos necesarios para realizar el trabajo esperado y la concesión del rol Propietario solo a las entidades de seguridad que realmente necesiten acceso raíz completo a tus servicios. Para obtener más información, consulta la guía de seguridad de gestión de identidades y accesos.
El acceso automatizado a cualquier servicio gestionado debe basarse en cuentas de servicio. Las cuentas de servicio simplifican el ciclo de vida de la gestión de aplicaciones, ya que te permiten gestionar la autenticación y la autorización de las aplicaciones. Estas cuentas te ofrecen una forma flexible y segura de agrupar instancias de máquinas virtuales con aplicaciones y funciones similares que tienen una identidad común. Puedes aplicar medidas de seguridad y control de acceso a nivel de cuenta de servicio mediante roles de gestión de identidades y accesos y reglas de cortafuegos de VPC.
Las reglas de gestión de identidades y accesos que apliques a las carpetas se heredarán a todos los elementos que contenga esa carpeta. Los permisos predeterminados son de denegación total (requisito 7.2.3) y cada regla que apliques solo añade 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 seguras en la sección 5.1.1 de NIST SP800-63B. Google recomienda seguir las directrices de identidad digital del NIST siempre que sea posible.
La sección 12.7 del cuestionario de autoevaluación D de PCI DSS requiere que las personas que tengan acceso a tu entorno incluido en el ámbito de aplicación superen una comprobación de antecedentes, de conformidad con las leyes locales, antes de que se les conceda acceso al entorno. Para reducir el riesgo de incumplimiento, te recomendamos que hagas estas comprobaciones de antecedentes penales y referencias de cada persona, independientemente del tipo de cumplimiento que tengas.
Proteger tu red
Para proteger el tráfico entrante y saliente hacia y desde la red de tu aplicación de procesamiento de pagos, debes crear lo siguiente:
- Políticas de Cloud Next Generation Firewall o reglas de cortafuegos de Compute Engine
- Un túnel de Cloud VPN
- Un balanceador de carga de aplicación externo
Para crear tu VPC, también te recomendamos Cloud NAT para añadir una capa adicional de seguridad de red. Hay muchas opciones eficaces disponibles para proteger las redes de las instancias de Compute Engine y GKE.
Crear reglas de cortafuegos
Usa políticas de Cloud Next Generation Firewall o reglas de cortafuegos de VPC para restringir el tráfico entrante a cada una de tus instancias de Compute Engine (requisitos 1.3 y 1.4). Permite solo el tráfico entrante de las siguientes tres fuentes:
- HTTPS público para que los clientes puedan acceder a tu página de pago.
- La red de tu aplicación para que tu aplicación de procesamiento de pagos pueda recibir respuestas de tu procesador de pagos externo.
- Tu red de oficina interna para que puedas acceder a las instancias con fines de auditoría y gestión.
Usa reglas de cortafuegos en instancias concretas para restringir el tráfico saliente. Puedes implementar estas reglas de forma local con iptables o, de forma más general, usando reglas de cortafuegos de VPC y etiquetas de red. Permite solo el tráfico saliente de tu formulario de pagos al procesador de pagos externo. Esta conexión debe ser solo HTTPS. Para probar tu trabajo, consulta la sección sobre registro de reglas de cortafuegos más adelante en este documento.
Cloud DNS ofrece zonas DNS privadas para que puedas asignar nombres de host de forma segura en tu CDE sin que se filtre información sensible sobre la topología de la red al público.
Restringe el tráfico de la siguiente manera:
Fuente | Destino | Puerto | Dirección y motivo |
---|---|---|---|
Balanceador de carga público | Formulario de pagos de terceros | tcp:443 | Entrante Acceso público a la aplicación de procesamiento de pagos |
Formulario de pago de terceros | Procesador de pagos externo | tcp:443 | Saliente Reenvío de solicitudes AUTH al proveedor de servicios de pago |
Procesador de pagos externo | Tu aplicación de procesamiento de pagos | tcp:5480 | Entrante Aceptar solicitudes AUTH de sistemas de pago (no contiene datos de titulares de tarjetas) |
La red de la oficina de tu empresa | vpn-gateway | tcp:8000 | Entrante Acceso al entorno de procesamiento de pagos para acceder a los registros y a las máquinas de desarrollo |
Además, el siguiente tráfico se produce de forma segura en la red interna de tu aplicación de procesamiento de pagos:
Fuente | Destino | Puerto | Motivo |
---|---|---|---|
Formulario de tarjeta | Proxy PCI | tcp:5480 | Intercambio de datos de tarjetas cifrados por un token de instrumento de pago |
Todos los anfitriones | Servidores NTP de Google | udp:123 | Sincronización de la hora |
Pasarela VPN | Todos los anfitriones | tcp:22 | Conexiones Secure Shell (SSH) |
Establecer un túnel VPN seguro
Puedes usar Cloud VPN para establecer un túnel VPN seguro entre tu entorno on-premise y tu entorno de procesamiento de pagos (secciones 2.2.7 y 4.2).
Crear un balanceador de carga de aplicación externo
Para asegurarte de que el tráfico de clientes entrante sea seguro, puedes crear un balanceador de carga de aplicaciones externo (secciones 2.2.7 y 4.2). Para crear un balanceador de carga de aplicación externo, necesitas lo siguiente:
- Un subdominio de su sitio web que se utiliza para su 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.
Comprueba que tu dominio sea válido consultando su configuración de DNS en la interfaz de configuración de dominio de tu registrador web.
Crear una imagen base de Linux
La normativa PCI DSS contiene requisitos que describen cómo configurar máquinas que forman parte de una arquitectura de procesamiento de pagos que cumple los estándares. Puedes implementar estos requisitos de varias formas, pero la más sencilla es la siguiente:
Crea una lista del software y las bibliotecas que deben instalarse en cada servidor que esté incluido en el ámbito de tu aplicación de procesamiento de pagos. Para evitar introducir vulnerabilidades innecesarias en tu sistema (requisito 2.2.4), incluye solo el software y las bibliotecas mínimos que necesites para ejecutar tu aplicación. Entre los candidatos se pueden incluir la CLI de Google Cloud, los tiempos de ejecución y las bibliotecas específicos de cada lenguaje, o un servidor web.
Crea una instancia de Compute Engine que utilice una de las imágenes de sistema operativo preconfiguradas de Compute Engine.
Instala las bibliotecas y el software que has indicado antes.
Instala y configura
ntp
para mantener sincronizados los relojes del sistema. Gestionar los relojes del servidor con el protocolo de tiempo de red asegura la integridad de las marcas de tiempo de los registros (sección 10.6).Asegúrate de que la imagen siga las prácticas recomendadas para crear una imagen de Compute Engine segura (toda la sección 2.2).
Una vez que hayas configurado tu imagen base, crea una imagen de disco de Compute Engine personalizada a partir de tu imagen. Esta imagen te permite usar tu imagen de Linux base cuando creas instancias de máquina virtual.
Usar la gestión de paquetes segura
La gestión de paquetes es un componente clave de un entorno de alojamiento con seguridad reforzada. De acuerdo con la sección 2.2, debe implementar estándares de protección aceptados en el sector. A menos que uses Container-Optimized OS de Google, es probable que tengas instalado un gestor de paquetes como RPM, Yum o Apt. Es posible que tu aplicación use su propio gestor de paquetes específico de un lenguaje de programación, como NPM, PyPi o Composer, y descargue las dependencias en la primera ejecución.
Si tu aplicación puede obtener actualizaciones de Internet, debes tratar las fuentes de actualización como un posible riesgo de seguridad. Los ataques del lado de la oferta o upstream, que se incluyen de forma maliciosa en paquetes alojados públicamente, son cada vez más frecuentes. Imagina los efectos de instalar una actualización de SSH que contenga código malicioso.
Puedes mitigar el riesgo de ataques del lado de la oferta creando una lista de destinatarios seguros para tus paquetes y verificando que coincidan con la lista. Mantén una lista de los números de versión probados y aprobados de cada paquete que utilices. Registre el número de versión junto con su hash o firma. Asegúrate de que el gestor de paquetes valida el hash o la firma antes de instalar o actualizar una aplicación.
La mayoría de los sistemas de gestión de paquetes permiten el alojamiento privado. Si es posible, lanza tu propio servidor de gestión de paquetes privado y aloja solo software probado y aprobado. Bloquea el gestor de paquetes para que no pueda comunicarse con otros servidores para obtener actualizaciones.
Lo ideal es que el proceso de compilación de tu aplicación obtenga y valide todos los paquetes y, a continuación, cree una revisión de la imagen de disco personalizada que incluya todo lo que necesite el contenedor. De esta forma, tus servidores se inician y se escalan sin retrasos en la instalación, y hay menos probabilidades de que se produzcan errores aleatorios en el momento del inicio. También puedes volver a cualquier versión anterior de tu aplicación tal como estaba en producción. Para ello, inicia su imagen. Esto puede ser útil para hacer diagnósticos y análisis forenses.
Implementación y configuración
A continuación, configura la implementación y la configuración de tus instancias a partir de tu imagen base.
Desplegar un entorno
Para cumplir los requisitos de PCI DSS, asegúrate de implementar la aplicación correcta cada vez, de hacerlo de forma segura y de no instalar ningún otro paquete de software durante la implementación. Para simplificar el proceso de implementación, puedes crear una implementación automatizada para tu aplicación con Terraform. Terraform te permite describir todo tu entorno de procesamiento de pagos, incluidas sus reglas de firewall, pasarelas, balanceadores de carga e instancias, en código.
En una implementación automatizada, debes verificar la integridad del software que se va a implementar, ya sea de un tercero o propio. Puedes verificar tu software ejecutando un hash automatizado en cada paquete a medida que se instala. Una vez que se haya verificado un hash, puedes usar un framework de pruebas automatizadas para ejecutar pruebas de seguridad y de otro tipo, así como para comprobar que se han superado.
Por último, al implementar instancias de Compute Engine, diseña un plan de recuperación por si fallan tus instancias. Si el tiempo de inactividad aceptable es lo suficientemente largo, un plan de recuperación manual puede ser suficiente. De lo contrario, debes diseñar un plan de recuperación automatizado. Para obtener más información, consulta la guía de planificación para la recuperación tras fallos, el artículo sobre diseño de sistemas sólidos y el artículo sobre creación de aplicaciones web escalables y resilientes.
Configurar el entorno
Una vez que se hayan implementado las instancias, asegúrate de que estén configuradas correctamente. Instala software y bibliotecas adicionales sobre la imagen base de cada instancia según sea necesario. Para evitar la complejidad, la sobrecarga y el riesgo general de la configuración manual, usa una herramienta de gestión de la configuración automatizada, como Skaffold, Chef, Puppet, Ansible o Salt.
Implementar el registro de auditoría inmutable
El registro genera registros de auditoría automáticamente para una gran variedad de actividades en muchos productos. A largo plazo, puedes almacenar de forma segura registros inmutables mediante bloqueos de segmentos de Cloud Storage (sección 10.3). Los bloqueos de contenedores le permiten definir una política para que todos los objetos sean inmutables y no se puedan eliminar durante un periodo que usted especifique, que puede ir de segundos a años.
Implementar registros de flujo de nube privada virtual
El servicio Registros de flujo de VPC se ha diseñado para registrar los flujos de red enviados o recibidos por instancias de máquinas virtuales. Puede usar estos registros para monitorizar la red, realizar análisis forenses y hacer análisis de seguridad en tiempo real (sección 10.2).
Instalar el agente de Logging
Después de configurar iptables en tus servidores, cada servidor registra todas las actividades en el almacenamiento en bloques del servidor. Consulta la página de precios de Logging para obtener información sobre la asignación gratuita y los precios de transferencia de datos. Para conservar estos registros y generar alertas basadas en actividad sospechosa, envíalos a Logging y Monitoring instalando el agente de Logging en cada servidor (sección 10.3).
Integrar 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.5, utiliza un sistema de detección de intrusos (IDS) para saber cuándo intentan atacar el sistema agentes malintencionados. 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 del punto 11.5, instala un IDS en cada servidor. Después de investigar y elegir el software IDS que vas a usar, incluye la instalación de IDS en la secuencia de comandos de instalación inicial de cada servidor.
Sistema de Detección de Intrusos de Cloud (Cloud IDS) es un servicio de detección de intrusos que permite detectar amenazas de intrusiones, malware, software espía y ataques de comando y control en tu red. Cloud IDS ofrece una visibilidad total del tráfico de red, tanto si es de tráfico norte-sur como este-oeste, lo que te permite monitorizar la comunicación entre máquinas virtuales para detectar el movimiento lateral. También puedes usar Cloud IDS para simplificar el cumplimiento del requisito 11.5.
Los registros de IDS están incluidos en el ámbito del cumplimiento de PCI DSS y deben enviarse a Logging and Monitoring para generar informes, alertas y auditorías.
Implementar Security Command Center
Security Command Center ayuda a los equipos de seguridad a recopilar datos, identificar amenazas y responder a ellas antes de que provoquen daños o pérdidas en la empresa. Ofrece información detallada sobre los riesgos de las aplicaciones y los datos para que puedas mitigar rápidamente las amenazas a tus recursos en la nube y evaluar el estado general. Con Security Command Center, puedes consultar y monitorizar el inventario de tus recursos en la nube, buscar datos sensibles en los sistemas de almacenamiento, detectar vulnerabilidades web comunes y, además, revisar los derechos de acceso a tus recursos esenciales. Y todo ello con un solo panel central. Puede ayudarte a cumplir varios requisitos, incluidas las secciones 5 y 6.4.
Automatizar el despliegue de aplicaciones
Crea tu herramienta de gestión de configuración para recuperar y lanzar de forma segura la versión más reciente de tu aplicación. Tu aplicación se puede recuperar desde cualquier ubicación, como Cloud Storage, siempre que sea segura.
Muchas de las herramientas de gestión de la configuración mencionadas anteriormente admiten flujos de trabajo de integración y despliegue continuos (CI/CD), que también se pueden usar para realizar análisis automatizados (sección 11.3) y para asegurarse de que el código se revisa (requisito 6.2.3).
Obtener registros del gestor de configuración
Al configurar el gestor de configuración, asegúrese de que registre todos los detalles de la instalación. Una vez completado el proceso de configuración, asegúrate de que envía los registros a Logging y Monitoring.
Almacenamiento de registros y monitorización
Para cumplir la normativa PCI DSS en la sección 10, asegúrese de que se monitoriza y registra cada paso que se da en su entorno de procesamiento de pagos. Se debe registrar toda la actividad del servidor en cada instancia y se debe poder examinar cada acción del usuario en un momento posterior.
Habilitar Transparencia de acceso
Con Transparencia de acceso, Logging ahora ofrece registros casi en tiempo real cuando los administradores acceden a tu contenido.Google Cloud Los registros de auditoría de Cloud ya te permiten ver las acciones de tus propios administradores. No obstante, este registro de auditoría normalmente excluye las acciones realizadas por el personal de asistencia o de ingeniería de tu proveedor de la nube. Por ejemplo, antes de que existieran los registros de Aprobación de acceso, si se creaba una incidencia de asistencia de Google para la que era necesario tener acceso a los datos, esta no quedaba registrada en los registros de auditoría de Cloud. Para solventar esta carencia de datos, Aprobación de acceso captura casi en tiempo real los registros de los accesos del personal de asistencia o de ingeniería.
Aprobación de acceso te permite aprobar explícitamente el acceso a tus datos o configuraciones en Google Cloud antes de que se produzca. Aprobación de acceso también proporciona información valiosa sobre los accesos de la asistencia y la ingeniería de Google.
Habilitar el almacenamiento de registros de reglas de cortafuegos
Almacenamiento de registros de reglas de cortafuegos te permite habilitar el registro a nivel de regla individual. Puede registrar conexiones TCP y UDP en una VPC para las reglas que crees. Se trata de una función que puede servir para auditar el acceso a la red o generar alertas tempranas si la red se usa de una forma no aprobada.
Usar Controles de Servicio de VPC
Controles de Servicio de VPC te permite definir un perímetro de seguridad alrededor de los Google Cloud recursos, como los segmentos de Cloud Storage, las instancias de Bigtable y los conjuntos de datos de BigQuery, para acotar los datos de una red de VPC y mitigar los riesgos de filtración externa (requisitos 1.3.1 y 1.3.2). Con Controles de Servicio de VPC, puede mantener la confidencialidad de sus datos sensibles y, al mismo tiempo, beneficiarse de las ventajas que ofrecen las funciones de almacenamiento y tratamiento de datos totalmente gestionadas deGoogle Cloud.
Configurar registros de flujo de VPC
Los registros de flujo de VPCs registran los flujos de tráfico de red enviados o recibidos por las instancias de VM. Los registros son útiles en el contexto de PCI DSS para monitorizar, auditar, realizar análisis forenses y hacer análisis de seguridad en tiempo real. Los registros de flujo se pueden habilitar o inhabilitar de forma independiente en cada subred de la red de VPC. Puedes minimizar la cantidad de datos de registro habilitando únicamente los registros de flujo en tu CDE. Los registros de flujo, combinados con las reglas de cortafuegos de salida, te permiten limitar el tráfico saliente a los endpoints autorizados de una forma auditable y difícil de eludir (requisitos 1.2.1 y 1.3.4).
En el siguiente diagrama se muestra cómo registran los registros de flujo de VPC el tráfico de red enviado o recibido por las instancias de VM."
Si necesitas datos más detallados de los que pueden proporcionar los registros de flujo, como el registro de solicitudes HTTP individuales, puedes implementar controles en tu aplicación o en las solicitudes salientes de proxy. Para ello, debes usar tu propio servidor proxy inverso configurado para reenviar los registros de acceso a Logging. Para obtener instrucciones sobre cómo configurar un servidor proxy Squid en Compute Engine, consulta el artículo Configurar un proxy de red. Para evitar cuellos de botella, configura al menos dos servidores proxy redundantes.
Registrar datos de acceso interno
Además de registrar las amenazas externas, también debe monitorizar y registrar la actividad de las personas que tengan acceso de administrador a su entorno de procesamiento de pagos (sección 10.2). Para ello, puedes registrar los comandos de shell. Hay varias herramientas de código abierto que pueden auditar los comandos de shell y enviarlos a los registros. Entre las opciones más populares para esta tarea se incluyen OSSEC y Tripwire.
Configurar alertas de monitorización
Configure Monitoring para enviar alertas si hay algún problema en su entorno de procesamiento de pagos (sección 10.6). Asegúrate de que tus alertas cubran eventos de aplicaciones internos, de auditoría y relacionados con el entorno. Basa tu estrategia de alertas en los posibles riesgos o vectores de ataque de cada componente de tu aplicación de procesamiento de pagos. Por ejemplo, activa alertas de monitorización si tu sistema de detección de intrusiones detecta algún intento de intrusión, tanto si tiene éxito como si no. También puede usar el almacenamiento de registros de reglas de cortafuegos para activar alertas en respuesta a intentos de infringir políticas de red específicas.
Transmitir registros a BigQuery
Si quieres, puedes enrutar los registros de Logging a BigQuery para analizarlos más adelante. Consulta Información general sobre el enrutamiento y el almacenamiento: sumideros para obtener más información. BigQuery está optimizado para consultar grandes conjuntos de datos, por lo que es una herramienta ideal para analizar registros a gran escala. El registro incluso puede registrarse directamente en BigQuery para los registros que requieran un análisis casi en tiempo real (requisito 10.4.1).
Usar Protección de Datos Sensibles para anonimizar datos
Hay muchos motivos para usar partes de los datos incluidos en el ámbito de tu aplicación que no están en el ámbito, como para analíticas o desarrollo. Concede a las aplicaciones acceso a los datos de PCI solo después de que se hayan anonimizado con Protección de datos sensibles (requisito 6.5.1).
Seguridad de las aplicaciones
Para proteger tu aplicación, primero debes evaluar la interfaz de administrador. También puedes usar Cloud Key Management Service.
Evaluar la interfaz de administrador
La mayoría de las aplicaciones de comercio electrónico tienen su propia interfaz de administrador que no es una consola, como un portal de facturación de atención al cliente. Esta herramienta debe tener controles de acceso sólidos, acceso individualizado que utilice la autenticación multifactor (sección 8.4) y registro de auditoría (sección 10.2).
Los registros que crees deben responder a estas preguntas: ¿quién ha hecho qué? ¿Dónde lo hicieron? ¿Cuándo lo hicieron? De acuerdo con la sección 2.2.7, todo acceso a dicha herramienta debe usar un cifrado de transporte seguro. Utiliza Protección de Datos Sensibles para filtrar la información sensible antes de mostrarla en cualquier herramienta de administración.
Usar Cloud Key Management Service (Cloud KMS)
Cloud KMS es un servicio que te permite gestionar claves de encriptado. Puede generar, usar, rotar y eliminar claves de cifrado AES-256, RSA 2048, RSA 3072, RSA 4096, EC P256 y EC P384. Cloud KMS te permite eliminar las contraseñas sin cifrar almacenadas en el código o en los archivos de configuración, lo que simplifica el cumplimiento de las secciones 2.2.2, 3.6, 3.7 y 8.2.
Validar el entorno
Una vez que hayas implementado el entorno, pero antes de que fluya tráfico de producción a través de él, debes validar el entorno:
- Si eres un comercio de nivel 1, un asesor de seguridad cualificado (QSA) debe validar tu entorno. Un QSA es una empresa o una persona aprobada por el PCI Security Standards Council para validar entornos PCI y dar el visto bueno.
- Si eres un comerciante de nivel 2 o inferior, puedes validar tu entorno rellenando el cuestionario de autoevaluación.
Siguientes pasos
- Biblioteca de documentos de PCI DSS
- Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Centro de arquitectura de Cloud.