Estás viendo la documentación de Apigee Edge.
Ve a la
documentación de Apigee X. info
Para que un cliente cumpla con las normas de PCI en la nube pública de Apigee Edge, existen algunas acciones y procesos que pertenecen al “Modelo de responsabilidad compartida”. Los clientes que compraron el paquete de cumplimiento de PCI y deben cumplir con las PCI deben revisar los siguientes elementos. Estos elementos son de autoservicio en Edge y deben abordarse para que la organización del cliente (org) cumpla con la PCI. El concepto general es “Google protege la plataforma, el cliente protege sus datos”.
Matriz de responsabilidad del cliente
Los clientes deben consultar la Matriz de responsabilidad de Google Apigee para PCI-DSS 3.2.1 y compartirla con su asesor de seguridad calificado de PCI cuando realicen su propia auditoría de PCI.
Asignación de requisitos de PCI
| Requisito de PCI | Sección |
|---|---|
| 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: Realizar 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 datos del titular de la tarjeta a través de redes públicas abiertas | |
| Requisito 3: Proteger los datos almacenados del titular de la tarjeta | |
| Requisito 4: Encriptar la transmisión de datos del titular de la tarjeta a través de redes públicas abiertas |
Para obtener una Certificación de cumplimiento (AOC) estándar de la seguridad de los datos de PCI, abre un ticket con el equipo de asistencia de Apigee o comunícate con el equipo de ventas de Apigee.
Seguimiento o depuración
El seguimiento o la depuración 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 en el procesador de mensajes de Apigee. Trace y Debug son dos nombres para el mismo servicio, pero se accede a ellos a través de mecanismos diferentes. 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. El uso del término seguimiento en este documento es válido para Trace y Debug.
Durante una sesión de seguimiento, se aplica el "enmascaramiento de datos". Esta herramienta puede bloquear la visualización de los datos durante un seguimiento. Consulta la sección Enmascaramiento de datos a continuación.
Los mapas de clave-valor (KVM) encriptados se pueden usar para clientes de PCI. Si se usa una KVM encriptada, es posible que se siga usando Trace, pero algunas variables no serán visibles en la pantalla de Trace. Es posible seguir pasos adicionales para mostrar estas variables durante un seguimiento.
Las instrucciones detalladas sobre el uso de Trace están disponibles en Usa la herramienta de seguimiento.
Los detalles sobre las KVM, incluidas las KVM encriptadas, están disponibles en Cómo trabajar con mapas de clave-valor.
Uso/autorizaciones
El acceso a Trace se administra a través del sistema RBAC (control de acceso basado en roles) para las cuentas de usuario en Edge. Las instrucciones detalladas sobre el uso del sistema de RBAC para otorgar y revocar privilegios de registro están disponibles en Cómo asignar roles y Cómo crear roles personalizados en la IU. Los permisos de registro permiten al usuario iniciar un registro, detenerlo y acceder al resultado de una sesión de registro.
Dado que el registro tiene acceso a la carga útil de las llamadas a la API (denominada anteriormente “Cuerpo del mensaje”), es importante considerar quién tiene acceso para ejecutar un registro. Debido a que la administración de usuarios es una responsabilidad del cliente, la asignación de permisos de registro también es una responsabilidad del cliente. Apigee, como propietario de la plataforma, puede agregar un usuario a una organización de clientes y asignarle los privilegios. Esta función solo se usa cuando el cliente solicita asistencia en una situación en la que parece que el servicio de atención al cliente falla y se cree que revisar una sesión de seguimiento proporciona la mejor información sobre la causa raíz.
Enmascarar datos
El enmascaramiento de datos evita que se muestren datos sensibles durante una sesión de seguimiento o depuración, tanto en el seguimiento (IU de Edge) como en el backend de depuración (API de Edge). Los detalles sobre cómo configurar el enmascaramiento están disponibles en Enmascaramiento y ocultamiento de datos. El enmascaramiento de datos sensibles es parte del Requisito 3 de PCI: Protege los datos almacenados del titular de la tarjeta.
El enmascaramiento de datos NO evita que los datos sean visibles en archivos de registro, caché, 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 caché ni en estadísticas sin una justificación comercial sólida y una revisión por parte de los equipos de seguridad y jurídico del cliente.
Caché L1 y L2
La caché está disponible para los clientes de PCI para usarla solo con datos no regulados. No se debe usar la caché para los datos del titular de la tarjeta (CHD) de PCI; la auditoría de cumplimiento de PCI de Apigee no la aprueba como ubicación de almacenamiento para CHD. Según la guía de PCI (Requisito 3: Proteger los datos almacenados del titular de la tarjeta) , los datos de PCI deben almacenarse solo en una ubicación que cumpla con las PCI. El uso de la caché L1 también usará automáticamente la caché L2. La caché de L1 es “solo memoria”, mientras que la caché de L2 escribe datos en el disco para sincronizarse en varias cachés de L1. La caché L2 es lo que mantiene sincronizados varios procesadores de mensajes dentro de una región y a nivel global. Actualmente, no es posible tener habilitada la caché L1 sin una caché L2 detrás. La caché 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é de 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 sean de CHD y otros datos no restringidos. No inhabilitamos la caché de forma predeterminada para los clientes de PCI, ya que algunos ejecutan llamadas a la API relacionadas y no relacionadas con PCI a través de una sola organización. Debido a que la función aún está habilitada para los clientes de PCI, es responsabilidad del cliente usar el servicio de manera adecuada y entrenar a sus usuarios para que no usen la caché cuando es probable que los datos de PCI estén en la llamada a la API. La auditoría de cumplimiento de PCI de Apigee no admite CHD almacenados en la caché.
Las instrucciones detalladas para usar la caché están disponibles en Cómo agregar almacenamiento en caché y persistencia.
Registro de auditoría
Los clientes tienen la capacidad de revisar el registro de auditoría de todas las actividades administrativas que se realizan dentro de la organización del cliente, incluido el uso de Trace. Las instrucciones detalladas están disponibles aquí y en Cómo usar la herramienta de seguimiento. (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 que tengan requisitos de contraseña específicos deben usar SAML para cumplir con sus requisitos individuales. Consulta Habilita la autenticación de SAML para Edge. Edge también ofrece autenticación de varios factores (Requisito 8 de PCI: 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 necesarios para el cumplimiento de PCI (Requisito 11: Prueba de forma periódica los sistemas y procesos de seguridad). En Edge Cloud, los clientes son responsables del análisis y las pruebas de sus extremos de la API (a veces denominados “componentes del entorno de ejecución”) en Edge. Las pruebas de clientes deben abarcar los servicios de proxy de API reales alojados en Edge, en los que el tráfico de la API se envía a Edge antes de procesarse y, luego, entregarse 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 abarca las pruebas de los servicios compartidos está disponible para los clientes en virtud de un acuerdo de confidencialidad y cuando se lo solicite).
Los clientes deben probar sus extremos de API y se recomienda que lo hagan. Tu acuerdo con Apigee no prohíbe las pruebas de los extremos de la API, pero no te permitimos probar la IU de administración compartida. Sin embargo, si necesitas más aclaraciones, abre una solicitud de asistencia en la que hagas referencia a las pruebas que planificaste. Agradeceremos que notifiques a Apigee con anticipación para que podamos estar al tanto del tráfico de prueba.
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 que se encuentre relacionado con los servicios de Apigee debe comunicarse a Apigee a través de una solicitud de asistencia.
La mayoría de los elementos relacionados con el extremo son elementos de autoservicio del cliente y se pueden corregir con una revisión de la documentación de Edge. Si no tienes claro cómo solucionar ciertos elementos, 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 API de cada cliente y las cargas útiles de datos, los clientes tienen la responsabilidad de determinar la encriptación adecuada para los datos en tránsito. Las instrucciones detalladas sobre la configuración de TLS están disponibles en TLS/SSL.
Almacenamiento de datos
No es necesario almacenar los datos dentro de Edge para que funcione de forma correcta. Sin embargo, hay servicios disponibles para el almacenamiento de datos en Edge. Los clientes pueden elegir usar caché, mapas de clave-valor o estadísticas para el almacenamiento de 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 de PCI (Proteger los datos almacenados del titular de la tarjeta), los datos de PCI deben almacenarse solo en ubicaciones que cumplan con las PCI. El uso de estos servicios está disponible para los clientes a fin de almacenar datos que no sean de PCI u otros datos no restringidos sujetos 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 no capturar ni almacenar los CHD. Se recomienda que los administradores del cliente revisen las configuraciones, las políticas y las implementaciones para evitar el uso accidental o malicioso de los servicios de almacenamiento de datos en Edge, lo que infringe las normas .
Encriptación de datos
Las herramientas de encriptación de datos no se ofrecen a los clientes para su uso dentro de Edge. Sin embargo, los clientes son libres de encriptar sus datos de PCI antes de enviarlos a Edge. El Requisito 4 de PCI (encriptar la transmisión de datos del titular de la tarjeta a través de redes públicas abiertas) 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 evitan 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 no están disponibles para que Edge los cambie. Sin embargo, otras políticas y paquetes creados por el cliente funcionarán incluso si la carga útil de los datos está encriptada.