Cumplimiento y configuración de la HIPAA con Apigee Edge

Estás consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X.
Información

Cumplimiento de la HIPAA con Apigee Edge

Asegurarnos de que los datos de nuestros clientes estén seguros y siempre disponibles para ellos es una de nuestras principales prioridades. Para demostrar nuestro cumplimiento de los estándares de seguridad de la industria, Google solicitó y recibió certificaciones de seguridad como la certificación ISO 27001 y las auditorías SOC 2 y SOC 3 Tipo II. Para los clientes que están sujetos a los requisitos de la Ley de Responsabilidad y Portabilidad de Seguros Médicos (HIPAA), Apigee Edge también puede cumplir con esta ley.

Conforme a la HIPAA, cierta información sobre los servicios de salud o atención médica de una persona se clasifica como Información de salud protegida (PHI). Los clientes de Apigee Edge que están sujetos a la HIPAA y desean usar Apigee Edge con PHI deben firmar un Acuerdo entre Socios Comerciales (BAA) con Google.

Los clientes de Apigee Edge son responsables de determinar si están sujetos a los requisitos de la HIPAA y si usan o pretenden usar los servicios de Google en relación con la PHI. Los clientes que no hayan firmado un BAA con Google no deben usar los servicios de Google en relación con la PHI.

Los administradores deben revisar y aceptar el BAA antes de usar los servicios de Google con PHI.

En este tema, publicamos nuestra Guía de configuración de la HIPAA de Apigee para ayudar a los clientes a comprender cómo organizar los datos en los servicios de Google cuando manejan la PHI. Esta guía está dirigida a empleados de organizaciones responsables de la implementación y el cumplimiento de la ley HIPAA con Apigee Edge.

Guía de configuración de la HIPAA para la nube pública perimetral

Esta guía solo tiene fines informativos. Apigee no pretende que la información ni las recomendaciones de esta guía se consideren asesoramiento legal. Cada cliente es responsable de evaluar de forma independiente el uso particular que hace de los servicios según corresponda para satisfacer las obligaciones de cumplimiento legal.

Los clientes que hayan comprado el paquete de cumplimiento de la HIPAA y deben revisar los siguientes puntos, incluida la Ley HITECH de Responsabilidad y Portabilidad de Seguros Médicos (conocida como HIPAA, y sus enmiendas, incluida la Ley HITECH de Tecnología de la Información de Salud Económica y Clínica). Estos elementos son de autoservicio en Edge y pueden ayudar a la organización (organización) del cliente a cumplir con sus obligaciones de cumplimiento de la HIPAA. El concepto general es "Google protege la plataforma y el cliente protege los datos".

Requisitos de la HIPAA Secciones
Cumplimiento de la HIPAA: Seguridad y control de acceso Uso/autorizaciones
Cumplimiento de la HIPAA: Proceso de administración de seguridad: revisión de la actividad del sistema de información Registro de auditoría
Cumplimiento de la HIPAA: Administración de contraseñas de seguridad Requisitos de contraseña complejos o SAML
Cumplimiento de la HIPAA: Seguridad: proceso de administración de la seguridad Análisis de extremos
Cumplimiento de la HIPAA: Seguridad (transmisión) Configuración de TLS

Seguimiento y depuración

Trace/Debug es una herramienta de solución de problemas que le permite al usuario ver el estado y el contenido de una llamada a la API mientras se procesa mediante 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 distintos mecanismos. 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" si el cliente lo habilita y configura. 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 usan para los clientes que exigen el cumplimiento de la HIPAA. Aunque se esté usando un KVM encriptado, es posible que se siga usando Trace, pero algunas variables no serán visibles en la pantalla de Trace. Es posible realizar pasos adicionales para mostrar estas variables durante un seguimiento.

Las instrucciones detalladas sobre cómo usar Trace están disponibles en Cómo usar la herramienta Trace.

Los detalles sobre los KVM, incluidos los KVM encriptados, están disponibles 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 (cumplimiento de la HIPAA: Seguridad y control de acceso). Las instrucciones detalladas sobre el uso del sistema de RBAC para otorgar y revocar privilegios de Trace están disponibles en Asigna roles y Crea roles personalizados 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. Debido a que la administración de usuarios es una responsabilidad del cliente, otorgar los permisos de Trace también es una responsabilidad del cliente. Como propietario de la plataforma, Apigee puede agregar un usuario a una organización de cliente y asignar los privilegios. Esta habilidad solo se utiliza cuando el cliente solicita asistencia en una situación en la que parece que el servicio de atención al cliente está fallando y se cree que la revisión de una sesión de Trace proporciona la mejor información sobre la causa raíz.

Enmascaramiento de datos

El enmascaramiento de datos evita que se muestren datos sensibles solo durante una sesión de Trace/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.

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 comercial sólida y sin que los equipos de seguridad y legales los revisen.

Caché L1 y L2

El uso de la caché L1 también usará automáticamente la caché L2. La caché L1 es "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. En Agrega almacenamiento en caché y persistencia, puedes encontrar instrucciones detalladas sobre el uso de la caché.

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 (Cumplimiento de la HIPAA: Proceso de administración de seguridad: Revisión de la actividad del sistema de información). Las instrucciones detalladas están disponibles aquí y en Usa la herramienta de seguimiento.

Requisitos de contraseña compleja o SAML

En el caso de los clientes de la HIPAA, las contraseñas de usuario están configuradas para cumplir con requisitos avanzados, como longitud, complejidad y esperanza de vida. (Cumplimiento de la ley HIPAA: Administración de contraseñas de seguridad)

Edge también ofrece autenticación de varios factores, que se describe en Habilita la autenticación de dos factores en tu cuenta de Apigee, y SAML, que se describe en Habilita la autenticación SAML para Edge, como alternativas a los controles de autenticación.

Seguridad de extremos

Análisis de extremos

Los clientes de Edge Cloud 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 ( cumplimiento de la HIPAA: Proceso de administración de seguridad y seguridad). Las pruebas del cliente deben abarcar los servicios de proxy de la API reales alojados en Edge, donde 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 sobre 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 la API, pero te solicita que no pruebes la IU de administración compartida. Sin embargo, si se requieren más aclaraciones, abre un ticket de asistencia en el 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 problemas específicos de la API o problemas relacionados con los servicios de Apigee. Además, deben verificar la TLS y otros elementos configurables. Se debe comunicar a Apigee todos los elementos que se encuentren y se relacionen con los servicios de Apigee a través de un ticket 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

Los clientes son responsables de definir y configurar sus propios extremos TLS para los proxies de API. Esta es una función de autoservicio de Edge. Los requisitos de los clientes en torno a la encriptación, el protocolo y las selecciones de algoritmos son muy variables y son específicos de cada caso de uso. Debido a que Apigee no conoce los detalles del diseño de la API de cada cliente ni de las cargas útiles de datos, estos tienen la responsabilidad de determinar la encriptación adecuada para los datos en tránsito ( cumplimiento de la HIPAA: Seguridad, Transmisión).

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é o las estadísticas para almacenar datos. 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 datos de la carga útil

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 los datos antes de enviarlos a Edge. 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.

PII en URIs

La plataforma de estadísticas unificada (UAP) de Apigee captura datos de estadísticas, incluidos PHI, o bien otros datos sensibles incluidos en el identificador uniforme de recursos (URI) de una llamada a la API en Apigee Edge, y los retiene durante 13 meses. La PHI en el URI es compatible con los estándares de Fast Healthcare Interoperability Resources (FHIR) y, por lo tanto, es compatible con Apigee. Los datos de Analytics en el UAP se encriptan en reposo de forma predeterminada.

Actualmente, Apigee no admite los siguientes elementos:

  • Enmascaramiento de datos a UAP
  • Cambia el ciclo de retención
  • Cómo inhabilitar la UAP
  • Eliminación del URI de la recopilación de datos de UAP