Estás consultando la documentación de Apigee Edge.
Consulta la
documentación de Apigee X. Información
Para que un cliente cumpla con la PCI en la nube pública de Apigee Edge, existen algunas acciones y procesos que posee en el “Modelo de responsabilidad compartida”. Los clientes que compraron el paquete de cumplimiento de PCI deben revisar los siguientes elementos y deben cumplir con la PCI. Estos elementos son de autoservicio en Edge y se deben abordar para que la organización del cliente (organización) cumpla con la PCI. El concepto general es "Google protege la plataforma y el cliente protege sus datos".
Matriz de responsabilidad del cliente
Los clientes deben consultar la Matriz de responsabilidad de PCI-DSS 3.2.1 de Google Apigee y compartirla con su asesor de seguridad calificado por la PCI cuando realicen su propia auditoría de PCI.
Asignación de requisitos de PCI
| Requisito de PCI | Section |
|---|---|
| Requisito 7: Restringir el acceso a los datos del titular de la tarjeta por parte de la empresa | |
| Requisito 3: Proteger los datos almacenados del titular de la tarjeta | |
| Requisito 10: hacer un seguimiento y supervisar todo el acceso a los recursos de red y los datos del titular de la tarjeta | |
| Requisito 8: Asignar un ID único a cada persona con acceso a la computadora | |
| Requisito 11: Probar periódicamente los sistemas y procesos de seguridad | |
| Requisito 4: Encriptar la transmisión de los datos del titular de la tarjeta a través de redes abiertas y públicas | |
| Requisito 3: Proteger los datos almacenados del titular de la tarjeta | |
| Requisito 4: Encriptar la transmisión de los datos del titular de la tarjeta a través de redes abiertas y públicas |
Para obtener una certificación de cumplimiento (AOC) de las normas de seguridad de datos de la PCI, abre un ticket con la asistencia de Apigee o comunícate con tu equipo de ventas de Apigee.
Seguimiento y depuración
Trace/Debug es una herramienta de solución de problemas que permite al usuario ver el estado y el contenido de una llamada a la API mientras se procesa a través de Apigee Message Processor. Trace y Debug son dos nombres para el mismo servicio, pero a los que se accede mediante mecanismos distintos. Trace es el nombre de este servicio dentro de la IU de Edge. Debug es el nombre del mismo servicio cuando se usa a través de llamadas a la API. En este documento, el término Trace es válido tanto para Trace como para Debug.
Durante una sesión de Trace, se aplica de manera forzosa el "Enmascaramiento de datos". Esta herramienta puede bloquear los datos para que no se muestren durante un seguimiento. Consulta la sección Enmascaramiento de datos a continuación.
Los mapas de clave-valor encriptadas (KVM) se pueden usar para los clientes de PCI. Si se está usando un KVM encriptado, es posible que Trace se siga usando, pero algunas variables no se podrán ver en la pantalla de visualización de Trace. Es posible realizar pasos adicionales para mostrar también estas variables durante un seguimiento.
Las instrucciones detalladas sobre cómo usar Trace están disponibles en Cómo usar la herramienta Trace.
Puedes encontrar detalles sobre los KVM, incluidos los KVM encriptados, en el artículo Trabaja con mapas de pares clave-valor.
Uso/autorizaciones
El acceso a Trace se administra a través del sistema de RBAC (control de acceso basado en funciones) para las cuentas de usuario dentro de Edge. Las instrucciones detalladas sobre el uso del sistema de RBAC para otorgar y revocar privilegios de Trace están disponibles en Asigna funciones y Crea funciones personalizadas en la IU. Los permisos de Trace permiten al usuario iniciar un seguimiento, detener un seguimiento y acceder al resultado de una sesión de Trace.
Dado que Trace tiene acceso a la carga útil de las llamadas a la API (formalmente denominado “Cuerpo del mensaje”), es importante considerar quién tiene acceso para ejecutar un seguimiento. Dado que la administración de usuarios es una responsabilidad del cliente, otorgar los permisos de Trace también lo es. Apigee, como propietario de la plataforma, tiene la capacidad de agregar un usuario a una organización del cliente y asignar los privilegios. Esta función solo se utiliza cuando el cliente solicita asistencia en una situación en la que parece que falla el servicio de atención al cliente y se cree que la revisión de una sesión de Trace proporciona la mejor información sobre la causa raíz.
Enmascarar datos
El enmascaramiento de datos evita que se muestren datos sensibles solo durante una sesión de Trace o Debug, tanto en Trace (IU de Edge) como en el backend de Debug (API de Edge). Los detalles para configurar el enmascaramiento están disponibles en Enmascaramiento y ocultamiento de datos. Enmascarar datos sensibles forma parte del requisito 3 de PCI: proteger los datos almacenados del titular de la tarjeta
El enmascaramiento de datos NO impide que los datos sean visibles en los archivos de registro, la caché, las estadísticas, etc. Para obtener ayuda con el enmascaramiento de datos en los registros, considera agregar un patrón de regex al archivo logback.xml. Por lo general, los datos sensibles no se deben escribir en la caché ni en las estadísticas sin una justificación empresarial sólida y los equipos legales y de seguridad del cliente deben revisarlos.
Caché L1 y L2
El almacenamiento en caché está disponible para los clientes de PCI solo con datos no regulados. No se debe usar la caché para los datos de titulares de tarjetas PCI (CHD), ya que la auditoría de cumplimiento de la PCI de Apigee no lo aprobó como ubicación de almacenamiento para CHD. Según los lineamientos de la PCI (Requisito 3: Protege los datos almacenados del titular de la tarjeta) , los datos de PCI deben almacenarse solo en una ubicación que cumpla con la PCI. El uso de la caché L1 también usará automáticamente la caché L2. La caché L1 funciona "solo memoria", mientras que la L2 escribe datos en el disco para sincronizarse en varias cachés L1. La caché de L2 es lo que mantiene sincronizados varios procesadores de mensajes sincronizados dentro de una región y globalmente. Actualmente, no es posible tener habilitada la caché L1 sin una caché L2 detrás de ella. La caché de L2 escribe datos en el disco para que se puedan sincronizar con otros procesadores de mensajes de la organización del cliente. Debido a que la caché L2 escribe los datos en el disco, no se admite el uso de la caché para CHD ni otros datos restringidos.
Los clientes pueden usar la caché para datos que no son de CHD y otros datos sin restricciones. No inhabilitamos la caché de forma predeterminada para los clientes de PCI, ya que algunos ejecutan llamadas a la API relacionadas con PCI y no PCI a través de una sola organización. Debido a que la capacidad sigue habilitada para los clientes de PCI, es responsabilidad del cliente usar el servicio de forma adecuada y entrenar a sus usuarios a fin de que no usen la caché cuando es probable que haya datos de PCI en la llamada a la API. La auditoría de cumplimiento de la PCI de Apigee no admite los CHD almacenados en la caché.
Puedes encontrar instrucciones detalladas sobre el uso de la caché en Cómo agregar almacenamiento en caché y persistencia.
Registro de auditoría
Los clientes pueden revisar el registro de auditoría de todas las actividades administrativas realizadas dentro de su organización, incluido el uso de Trace. Las instrucciones detalladas están disponibles aquí y en Cómo usar la herramienta Trace. (Requisito 10 de PCI: Realizar un seguimiento y supervisar todo el acceso a los recursos de red y los datos del titular de la tarjeta)
Requisitos de contraseña compleja o SAML
Los clientes con requisitos de contraseña específicos deben usar SAML para cumplir con sus requisitos individuales. Consulta Habilita la autenticación SAML para Edge. Edge también ofrece autenticación de varios factores (Requisito de PCI 8: Asigna un ID único a cada persona con acceso a la computadora). Consulta Habilita la autenticación de dos factores para tu cuenta de Apigee.
Seguridad de extremos
Análisis de extremos
El análisis y las pruebas de hosts son obligatorios para el cumplimiento de la PCI (Requisito 11: Probar con regularidad los sistemas y procesos de seguridad). En Edge Cloud, los clientes son responsables del análisis y la prueba de los extremos de la API (a veces llamados “componentes del entorno de ejecución”) en Edge. Las pruebas del cliente deben abarcar los servicios de proxy de la API reales alojados en Edge, en el que el tráfico de la API se envía a Edge antes de que se procese y, luego, se entregue al centro de datos del cliente. Las pruebas de recursos compartidos, como la IU del portal de administración, no están aprobadas para clientes individuales (un informe de terceros que cubre las pruebas de los servicios compartidos está disponible para los clientes bajo un acuerdo de confidencialidad y a pedido).
Los clientes deben probar sus extremos de API y se recomienda que lo hagan. Tu acuerdo con Apigee no prohíbe probar los extremos de tu API, pero no te permitimos probar la IU de administración compartida. Sin embargo, si necesitas una aclaración adicional, abre una solicitud de asistencia en la que se haga referencia a las pruebas que planeaste. Agradecemos que te comuniques con Apigee por adelantado para que podamos conocer el tráfico de las pruebas.
Los clientes que prueban sus extremos deben buscar cualquier problema específico de la API, cualquier problema relacionado con los servicios de Apigee y, también, verificar la TLS y otros elementos configurables. Cualquier elemento relacionado con los servicios de Apigee se debe comunicar a Apigee a través de una solicitud de asistencia.
La mayoría de los elementos relacionados con el extremo son de autoservicio para el cliente y se pueden corregir si se revisa la documentación de Edge. Si hay elementos en los que no está claro cómo solucionarlos, abre una solicitud de asistencia.
Configuración de TLS
Según los estándares de PCI, SSL y las primeras versiones de TLS deben migrarse a versiones seguras. Los clientes son responsables de definir y configurar sus propios extremos de TLS para proxies de API. Esta es una función de autoservicio en Edge. Los requisitos del cliente en cuanto a las selecciones de encriptación, protocolo y algoritmo son muy variables y específicos de cada casos de uso. Debido a que Apigee no conoce los detalles del diseño de la API y las cargas útiles de datos de cada cliente, estos tienen la responsabilidad de determinar la encriptación adecuada para los datos en tránsito. En TLS/SSL, encontrarás instrucciones detalladas sobre la configuración de TLS.
Almacenamiento de datos
No se requiere el almacenamiento de datos en Edge para que Edge funcione correctamente. Sin embargo, existen servicios disponibles para el almacenamiento de datos en Edge. Los clientes pueden optar por usar la caché, mapas de pares clave-valor o estadísticas para almacenar datos. Ninguno de estos servicios está autorizado para el almacenamiento de CHD según la auditoría de PCI de Apigee. Según el requisito 3 del estándar PCI (protección de los datos almacenados del titular de la tarjeta), los datos de PCI solo deben almacenarse en ubicaciones que cumplan con el estándar PCI. El uso de estos servicios está disponible para los clientes para almacenar datos que no sean PCI o cualquier otro dato sin restricciones, sujeto a los requisitos legales y de seguridad del cliente. Estos servicios son elementos de autoservicio para los clientes, por lo que es responsabilidad del cliente configurarlos para que no capten ni almacenen CHD. Se recomienda que los administradores del cliente revisen la configuración, las políticas y las implementaciones para evitar un uso accidental o malicioso de los servicios de almacenamiento de datos en Edge de una manera que no satisfaga las políticas .
Encriptación de los datos
Las herramientas de encriptación de datos no se ofrecen a los clientes para que las usen dentro de Edge. Sin embargo, los clientes tienen la libertad de encriptar sus datos de PCI antes de enviarlos a Edge. Requisito 4 de PCI: Encriptar la transmisión de datos del titular de la tarjeta en redes abiertas y públicas: Se recomienda encriptar los datos del titular de la tarjeta en redes públicas abiertas. Los datos encriptados en la carga útil (o el cuerpo del mensaje) no impiden que Edge funcione. Es posible que algunas políticas de Edge no puedan interactuar con los datos si el cliente los recibe encriptados. Por ejemplo, no es posible realizar una transformación si los datos en sí no están disponibles para que Edge los cambie. Sin embargo, otras políticas, así como las políticas y los paquetes creados por el cliente, funcionarán incluso si la carga útil de datos está encriptada.