Guía de seguridad práctica de Zendesk Suite

Lectura: 7 minutos

Aquí ofrecemos una descripción de las mejores prácticas que Zendesk recomienda a los suscriptores de Zendesk Suite que deseen aplicar en su propia instancia mecanismos de seguridad ampliamente aceptados. Lo ideal es que las prácticas se introduzcan en el mismo momento en que se adopta la instancia de Zendesk. También es importante revisar sistemáticamente la configuración y las mejores prácticas de la compañía para asegurarse de que sean apropiadas y de que los empleados las están aplicando correctamente.

Zendesk ofrece una amplia gama de controles diseñados para ayudarle a garantizar la seguridad de su información y la de sus clientes. Es imprescindible capacitar a agentes y administradores para que asuman las mejores prácticas de seguridad y las apliquen con el objeto de reducir al mínimo los riesgos de exposición de conformidad con nuestro Modelo de responsabilidad compartida. Este marco especifica las responsabilidades de cada suscriptor de Zendesk a la hora de garantizar la seguridad de su instancia. Si desea más información, consulte el Modelo de responsabilidad compartida de Zendesk. 

Este artículo contiene las siguientes secciones sobre las mejores prácticas relacionadas con Zendesk Suite:

• En general 
• Control del acceso
• Acceso a sistemas, redes y dominios
• Administración de datos
• Correo electrónico
• API
• Monitoreo
• Recuperación ante desastres

Mejores prácticas de seguridad para Zendesk Talk

En general

• Usar un sandbox para realizar pruebas y actividades de desarrollo y dejar intacta la instancia de producción.
• Limitar el uso de aplicaciones para dispositivos móviles a los flujos de trabajo de agentes o a determinados casos de uso. 
• Activar la función de moderación del contenido en el centro de ayuda de Guide y los hilos del foro con el fin de evitar spam o contenido no deseado en la comunidad de Gather.
• Verificar que todas y cada una de las funciones automáticas encargadas de enviar notificaciones notifiquen a las personas correctas.

Control del acceso

En general

• Cuando se usa la autenticación nativa de Zendesk: 
  • Personalizar el nivel de seguridad de las contraseñas en función de las políticas internas de la compañía. 
  • Fijar el tiempo de vencimiento de sesión más bajo posible para agentes y administradores. 
  • Desactivar todos los inicios de sesión con redes sociales de usuarios finales que ya no sean necesarios.
• Si se usa el inicio de sesión único (SSO):
  • Utilizar el SSO nativo del producto o bien el SSO empresarial para poder centralizar la administración de las configuraciones. 
  • Asociar cualquier método de autenticación multifactor (MFA) que esté utilizando con su SSO para que los inicios de sesión de Zendesk queden cubiertos.
  • Si opta por permitir la autenticación con contraseña a través de la autenticación nativa de Zendesk por si le preocupa que el SSO deje de funcionar en algún momento, recomendamos que deje la opción para no desactivar la autenticación con contraseña.  Si, por el contrario, desea eliminar la capacidad de utilizar contraseña una vez configurado el SSO, tendrá que desactivar el uso de contraseña.  Tenga en cuenta que, al desactivar el acceso con contraseña, finalizan todas las sesiones abiertas en las que se han utilizado contraseñas como método de autenticación.
• Mantener desactivada la opción Adopción de identidad de cuenta a menos que sea realmente necesario que un empleado de Zendesk ingrese en la cuenta (por ejemplo, para atender un asunto a través de defensores, servicios profesionales u otros representantes de Zendesk Support).

Usuarios

• Revisar los dispositivos conectados que estén asociados con el perfil de agente y eliminar aquellos que no se usan o que pueden parecer sospechosos. Solo los agentes, administradores y dueños tienen acceso a esta funcionalidad. 
• Si se crea una instancia “cerrada” de Zendesk, es necesario exigir que los usuarios finales se registren y verificar sus correos electrónicos antes de que puedan enviar tickets, con lo que se reducen las posibilidades de recibir spam. 
• Asignar roles personalizados a los agentes para limitar el acceso de los usuarios solo a lo indispensable para desempeñar su función.
• Tomar en cuenta los segmentos de usuarios o el acceso privilegiado en función de la marca cuando se use Guide.
• Utilizar la lista autorizada para seleccionar a los usuarios o los grupos de usuarios que pueden tener acceso a una cuenta o enviar solicitudes o chats.
• Utilizar una lista bloqueada cuando sea necesario para impedir que determinados usuarios interactúen con los servicios de Zendesk (suspendiéndolos o bloqueándolos) o bien para prohibir su acceso.
• Verificar a los usuarios de una cuenta y suspender o bajar de categoría a aquellos que ya no necesiten acceder al sistema. 

Contraseñas

• La autenticación de dos factores (2FA) es el estándar que se recomienda usar para el inicio de sesión de agentes y administradores en Zendesk.
• Cuando las necesidades de seguridad varían según los usuarios, se puede personalizar un nivel de seguridad por contraseña para los usuarios finales y otro para los agentes y administradores mediante la autenticación nativa de Zendesk.
• Crear una contraseña única para la cuenta de Zendesk (que no sea la misma que se usa para iniciar sesión en sistemas o aplicaciones externos).
• Activar alertas por correo electrónico que se encarguen de advertir a los agentes de cualquier inicio de sesión a través de dispositivos nuevos (y no autorizados). Consulte Seguimiento de los dispositivos y las aplicaciones que acceden a su cuenta en la Guía del agente de Zendesk.

Acceso a sistemas, redes y dominios

• Usar espacios de trabajo contextuales con dos fines: optimizar los flujos de trabajo y mostrar únicamente las herramientas necesarias (p. ej., macros, aplicaciones o formularios); y asegurarse de que solo los agentes tienen acceso a las funciones del sistema y a los flujos de trabajo necesarios para completar una tarea.
• Restringir el acceso de agentes o usuarios finales según sus direcciones IP.
• Utilizar una lista bloqueada cuando sea necesario para impedir que determinados usuarios interactúen con los servicios de Zendesk (suspendiéndolos o bloqueándolos) o bien para prohibir su acceso.
• Cuando se necesiten URL que no sean de Zendesk, se recomienda generar certificados SSL propios o certificados SSL proporcionados por Zendesk con mapeo de host y proporcionar acceso seguro al centro de ayuda.  En caso de proporcionar un certificado SSL propio, hay que asegurarse de mantenerlo al día.

Administración de datos

• Uso de datos 
  • Capturar solo los datos que sean necesarios para un determinado caso de uso con el objeto de reducir el riesgo de exponer datos confidenciales o de uso interno.
• Borrado y supresión 
  • Consultar las guías sobre el cumplimiento de la ley sobre privacidad y protección de datos para obtener recomendaciones de supresión en este contexto.
  • Considere no grabar las llamadas o borrar las grabaciones automáticamente a la hora de usar la funcionalidad de Talk cuando tales grabaciones puedan llegar a entorpecer el cumplimiento de normativas del sector o disposiciones legales. 
  • Activar la supresión automática para proteger los datos confidenciales de los clientes en tickets o chats. Nota: Esta función utiliza una verificación Luhn que suprime casi todos (pero no todos) los números de tarjetas de crédito.
  • Suprimir manualmente la información de tarjetas de crédito del espacio de trabajo de agente de Zendesk siempre que los permisos lo permitan. Tenga en cuenta que los datos borrados pueden permanecer hasta por 30 días en los registros. 
• Cumplimiento
  • En los casos de proveedores de atención médica o administradores de datos de atención médica que entren en contacto con información médica personal (“PHI”), se recomienda firmar un Business Associate Agreement (Acuerdo de socio comercial, BAA) con Zendesk, además de realizar las configuraciones de seguridad exigidas en el marco de la Health Insurance Portability and Accountability Act (Ley de portabilidad y responsabilidad de seguros de salud, HIPAA) en lo que se refiere a la administración de información médica personal (PHI) e información médica personal en formato electrónico (ePHI), según sea necesario.
  • Si se usan números de tarjetas de crédito con fines de identificación, es aconsejable agregar un campo de tarjeta de crédito al formulario de ticket que satisfaga los requisitos del Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS). Este campo no guarda ni revela el número de tarjeta de crédito completo ni se puede usar para realizar pagos ni transacciones.
  • La sección que sigue se aplica a quienes deben cumplir las exigencias del tratamiento de la información médica personal en formato ordinario o electrónico, la ley HIPAA o los requisitos del Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS). 
• Privacidad 
  • En el centro de ayuda, consultar la sección Cumplimiento de la ley sobre privacidad y protección de datos del producto pertinente. 
  • El Programa de privacidad global de Zendesk que encontrará en el centro de confianza ayuda a velar por el cumplimiento, sin importar dónde se encuentre ni los socios comerciales que tenga.

Correo electrónico

• Archivar el correo electrónico cuando la compañía necesite archivar las comunicaciones con sus clientes fuera de los servicios de Zendesk para cumplir disposiciones normativas o jurídicas. 
• Desactivar la función para chat Dirigir por correo electrónico a menos que sea necesaria a la hora de usar Chat.
• Usar contenido enriquecido en los correos electrónicos entrantes únicamente cuando sea necesario para el flujo de trabajo.  
• Activar la autenticación de correo electrónico con SPF, DKIM y DMARC para reducir el spam y el correo electrónico de suplantación (spoofing) en su cuenta. 
• Firmar digitalmente el correo electrónico que sale de Zendesk como una forma de probar que se ha originado dentro de su organización. 
• Utilizar respuestas de correo electrónico personalizadas y alias de agentes para ser transparentes ante los usuarios finales que se comunican con los agentes a través de un sistema de gestión de tickets. 
• Retirar las direcciones de soporte no utilizadas o innecesarias para reducir al mínimo el riesgo de suplantación de identidad (spoofing).

API

• Utilizar tokens en lugar de contraseñas para impedir el acceso no autorizado por contraseña a la API. 
• Desplegar OAuth para autenticar y limitar la cantidad de acceso otorgado a los tokens en la API. Desactivarla cuando no se necesite.
• Proteger los tokens de API en un lugar seguro fuera de la aplicación. Recomendamos usar tokens OAuth y no tokens de API siempre que sea posible.

Monitoreo

• Verificar y monitorear constantemente los registros de auditoría de la cuenta que muestren cambios en una cuenta. Sugerencia útil: la API también puede utilizarse para exportar registros de auditoría según se necesite.

Recuperación en caso de desastre

Zendesk mantiene un programa llamado Global Business Resilience para asegurarse de contar con la capacidad de adaptarse rápidamente a las interrupciones del negocio y responder con prontitud; proteger a las personas y los bienes; y garantizar la continuidad de las operaciones comerciales. Fuera de esto, existen varios pasos destinados a asegurar aún más la continuidad del negocio. 

• Participar en un programa de Recuperación ante desastres mejorada para conseguir una redundancia de seguridad que incluya la réplica de datos en tiempo real, la priorización de tráfico, la redundancia de zonas de disponibilidad y la planificación de recuperación prioritaria.
• Si se usa la funcionalidad de Voice, activar un número de failover para Talk para permitir la continuidad del negocio.
• Si desea permitir el acceso con contraseña en caso de que se produzca una interrupción externa del sistema SSO, pregúntese si le convendría no desactivar la autenticación nativa de Zendesk (el SSO puede configurarse de modo estricto o permitiendo eludir la contraseña). 
• Aplicar una API de exportación incremental o descargas masivas de los datos de servicio si necesita que los almacenes de datos no editables se conserven dentro de su propio entorno.
• Activar el reenvío de correo electrónico automático de la dirección de correo electrónico personal de un tercero a Zendesk Support para conservar una copia del correo electrónico fuera de Zendesk.
• Participar en un programa de Recuperación ante desastres mejorada para obtener una redundancia de seguridad mejorada que incluya la réplica de datos en tiempo real, la priorización de tráfico, la redundancia de disponibilidad de zonas y la planificación de recuperación prioritaria.
• Usar la API de exportación incremental para recuperar elementos de Zendesk Support que hayan cambiado desde la última solicitud de llamada API. Consulte API Reference (Referencia de las API) si desea más información. 

Si sospecha que un incidente de seguridad en su instancia de Zendesk fue ocasionado directamente por nuestro propio servicio, le rogamos que envíe un ticket a [e-mail]. Si desea aclarar dudas sobre cuándo contactar a Zendesk acerca de las responsabilidades relacionadas con la seguridad, consulte el Modelo de responsabilidad compartida de Zendesk.