Pesquisas recentes
Sem pesquisas recentes

Craig Lima
Entrou em 14 de abr. de 2021
·
Última atividade em 02 de jan. de 2025
Seguindo
0
Seguidores
0
Atividade total
11
Votos
0
Assinaturas
3
VISÃO GERAL DA ATIVIDADE
MEDALHAS
ARTIGOS
PUBLICAÇÕES
COMENTÁRIOS NA COMUNIDADE
COMENTÁRIOS EM ARTIGOS
VISÃO GERAL DA ATIVIDADE
Atividade mais recente por Craig Lima
Craig Lima comentou,
Dec 27th, 2024, added section XII to incorporate Workforce Management “WFM” into HIPAA BAA scope
Exibir comentário · Publicado 02 de jan. de 2025 · Craig Lima
0
Seguidores
0
Votos
0
Comentários
Craig Lima comentou,
Dec 16th 2024
1. Added section XI to incorporate Zendesk QA into scope
2. Changed various instances of "Answer Bot" to "AI Agents" to denote naming convention changes and broader scope.
3. Changed various instances of “must” and “shall” to “should” to denote best practices philosophy of configs, as well as to reinforce the Subscriber responsibility for interpretation of HIPAA compliance vis-a-vis Admin / Owner configurations and use case implementation https://support.zendesk.com/hc/en-us/articles/4408833510938-The-Zendesk-Shared-Responsibility-Model
Exibir comentário · Publicado 17 de dez. de 2024 · Craig Lima
0
Seguidores
0
Votos
0
Comentários
Craig Lima criou um artigo,
Regiões da AWS em que a Zendesk hospeda Dados de Serviço do Assinante
Atualmente, hospedamos os Dados de Serviço do Assinante nas seguintes regiões da AWS:
- Leste dos EUA (Virgínia do Norte)
- Leste dos EUA (Ohio)
- Oeste dos EUA (Oregon)
- EEE (Irlanda)
- EEE (Frankfurt)
- Reino Unido (Londres)
- Ásia-Pacífico (Tóquio)
- Ásia-Pacífico (Osaka)
- Ásia-Pacífico (Sydney)
Acordos de localidade dos dados
A Zendesk se compromete com a localização da hospedagem dos Dados de Serviço do Assinante apenas quando os Assinantes adquiriram nosso complemento Localização do data center, seja em uma aquisição individual do complemento ou quando o complemento Localização do data center está incluído com a aquisição do plano de serviço. Leia a Política Regional de Hospedagem de Dados aqui para saber sobre as exceções a esse compromisso.
Para equilibrar a demanda, otimizar o desempenho e fornecer um serviço melhor, podemos mover os dados da conta entre as regiões sem aviso. Se uma conta adquiriu o complemento Localização dos dados, garantiremos que as movimentações regionais permaneçam dentro do país ou das fronteiras legais exigidos.
Obtenção do endereço físico onde seus Dados de Serviço estão hospedados
Mediante solicitação, podemos comunicar a região da Amazon Web Services (AWS), uma área geral que pode ser descrita pela AWS como um país, uma região geográfica em um país, um estado e/ou uma cidade, em que hospedamos seus Dados de Serviço.
Não podemos fornecer endereços físicos exatos de onde seus Dados de Serviço estão hospedados devido ao modo como a AWS opera em nível técnico. Isso está baseado na própria arquitetura da AWS, que tem “regiões” ao redor do mundo. Nessas regiões, existe o conceito de “zonas de disponibilidade” ou “AZs”, do inglês “availability zones”. Quando um ativo é criado na AWS, ele fica localizado em uma ou mais AZs em uma determinada região. Independentemente da escolha do responsável pelo ativo de replicar os dados dentro de uma região ou entre regiões, a própria AWS pode replicar os dados dentro da região em outras AZs. O resultado é que os Dados de Serviço do Assinante da Zendesk existem em várias instalações dentro de uma determinada região. Além disso, por motivos de segurança, a AWS não sanciona oficialmente a comunicação das localizações específicas dos edifícios de seus data centers e instalações associadas.
Caso precise saber em qual região da AWS seu subdomínio do Zendesk está hospedado, entre em contato com o Suporte ao cliente Zendesk.
REGISTRO DE ALTERAÇÕES:
Abril de 2024 – adição de advertência para o Zendesk WFM (Tymeshift) e o Zendesk QA (Klaus)
Julho de 2024 – adição de advertência para a funcionalidade Ultimate
Julho de 2024 – adição de dois novos locais de hospedagem: Reino Unido (Londres), Ásia-Pacífico (Osaka)
Editado 26 de jul. de 2024 · Craig Lima
5
Seguidores
1
Votos
0
Comentários
Craig Lima criou um artigo,
Modelo de responsabilidade compartilhada da Zendesk
A Zendesk fornece uma plataforma de atendimento ao cliente altamente configurável e capaz de se adaptar rapidamente a algumas das maiores empresas do mundo de vários setores. Ajudamos os assinantes a aproveitar a nossa plataforma na nuvem a fim de fornecer serviços de atendimento ao cliente. Assim, os assinantes podem reduzir a sobrecarga, se adaptar para cumprir a demanda e fornecer interações elegantemente simples com os clientes.
Ao migrar seus negócios para a nuvem, você não só obtém os benefícios descritos acima, mas pode incluir ambiguidade com relação a qual parte terá o controle do quê. Não se preocupe. Vamos compartilhar a seguir o nosso Modelo de Responsabilidade Compartilhada para simplificar tudo. Essa estrutura esclarece qual parte fica responsável por quais controles relacionados à segurança e à privacidade dos seus dados. Você pode ser um administrador consciente, ser responsável pela segurança corporativa, conformidade ou privacidade, ou ainda estar encarregado de configurar os controles necessários para usar os Serviços Zendesk no seu ambiente, essa estrutura define muito bem o que você precisa saber.
Resumindo em uma frase, “a Zendesk cuida da segurança do Serviço em si, enquanto você cuida da segurança das suas instâncias do Serviço”.
- Higienização e controles de acesso
- Integrações
- Dados, privacidade, conformidade e considerações regulatórias
- Monitoramento
- Manutenção
- Incidentes de segurança (funções e responsabilidades)
- Links úteis
- Registro de alterações
Observe que os termos em letras maiúsculas são definidos no Contrato Principal de Serviços da Zendesk (“MSA”).
I. Higienização e controles de acesso
Controlar o acesso a sistemas sensíveis e aos dados contidos neles é fundamental por princípios de segurança.
-
O Assinante é responsável por todos os controles de acesso às suas instâncias do serviço, incluindo:
- Provisionamento, modificação, higiene regular, manutenção da precisão de privilégio e desprovisionamento de todos os usuários, incluindo usuários finais e agentes (locais, remotos ou da força de trabalho de terceiros)
- Escolha e configuração do método de autenticação no serviço a partir de ofertas aceitas (podem ser senhas, MFA, SSO etc.)
- Configuração e monitoramento dos aspectos que fazem parte da sessão, tais como saída, dispositivos conectados etc.
- Permissão ou veto de entrada à nossa equipe de suporte para fornecer ajuda na instância do Support
- Configuração de acesso e compreensão das implicações do uso dos serviços REST API do Zendesk (quando aplicável, por exemplo, integrações, uso do Zendesk Sunshine Service etc.)
- Configuração de quaisquer restrições de IP de produtos compatíveis quando quiser
- Consideração de outros controles de acesso não relacionados a produtos, como quais tipos de dispositivos você permite que os agentes usem ao acessar as suas instâncias, bem como quaisquer controles físicos, lógicos ou de política aplicáveis aos usuários ou dispositivos permitidos
-
A Zendesk é responsável por todos os controles de acesso aos sistemas que sustentam o serviço, incluindo:
- Manter as políticas e os procedimentos de provisionamento seguro, modificação, higiene regular, manutenção da precisão de privilégio e desprovisionamento de todos os usuários, incluindo usuários (locais, remotos e da força de trabalho de terceiros)
- Aplicar um Controle de acesso baseado em função (RBAC), o Princípio de privilégio mínimo (PLP), credenciais de segurança adequadas, como Autenticação multifatorial (MFA) em todos os acessos por funcionários e contratados a sistemas e aplicações críticos que contenham Dados de Serviço de um assinante
- Realizar verificações periódicas nos itens acima
II. Integrações
Contratar terceiros pode aumentar bastante a eficiência, mas também apresentar considerações sobre segurança.
-
O Assinante é responsável por levar em conta as implicações de segurança ao utilizar integrações de terceiros com o Serviço, como:
- Integrações feitas por API e/ou SDK
- Integrações feitas com a instalação de aplicativos do Marketplace ou a ativação de canais de terceiros
- Integrações com qualquer terceiro para auxiliar assinantes que envolve o fornecimento de equipes, ferramentas, códigos ou instâncias de serviço direto do Zendesk
-
A Zendesk é responsável por uma integração cuidadosa de terceiros reconhecidos ao serviço, como:
- Vetar e realizar auditoria regular em todos os subprocessadores
- Integrar aquisições ao Serviço com segurança
- Garantir quais parcerias com terceiros relacionadas a produtos e/ou integrações do Serviço tiveram a segurança avaliada
III. Dados, privacidade, conformidade e considerações regulatórias
Explicar os dados estão em uso, se eles são tratados corretamente, quaisquer quadros regulatórios e a importância de garantias de terceiros é imprescindível.
-
O Assinante é responsável por tratar adequadamente os dados que eles coletam e usam, inclusive:
- Entender os tipos de dados em seus respectivos casos de uso
- Tratar esses dados de acordo com a sua classificação e as políticas de privacidade da sua empresa, com as leis aplicáveis aos dados, aos usuários que fornecem os dados, ao setor do assinante e a outras jurisdições competentes
- Escolher quais canais podem se comunicar com as suas instâncias do serviço
- Manter as instâncias e Dados de Serviço de acordo com o enquadramento de conformidade, legal ou regulatório pertinente do setor do assinante, dos usuários ou dos casos de uso pode ser necessário
- Fornecer à Zendesk outros certificados TLS em que o mapeamento do host a um domínio pai que não seja da Zendesk é necessário para criptografar o tráfego entre suas UI e APIs
- Entender quando os dados não podem ser criptografados em trânsito e tratar devidamente esses canais ou protocolos (sobretudo e-mail, SMS ou integrações de terceiros feitas a critério exclusivo do assinante quando a criptografia não é possível)
- Garantir que os tipos de dados envolvidos na instância do assinante não violam os termos e condições do Contrato Principal de Serviços (consulte o MSA da Zendesk)
- Garantir o nível de tempo de atividade e a recuperação de desastres escolhidos pelo assinante de acordo com quaisquer políticas e regulações às quais os assinantes estejam vinculados
-
A Zendesk é responsável por:
- Proteger adequadamente todos os Dados de Serviço contra qualquer divulgação (por exemplo, infraestrutura e código)
- Criptografar dados em trânsito entre UIs e APIs em redes públicas
- Criptografar todos os Dados de Serviço em repouso
- Fornecer informações aos assinantes sobre os dados coletados por cookies de produtos e o uso padrão dos serviços
- Descrever corretamente como usamos os Dados de Serviço, inclusive Dados Pessoais, de forma anonimizada ou não, para fornecer os nossos Serviços.
- Fornecer ferramentas e recursos que ajudem os assinantes a cumprir as suas obrigações e tratar adequadamente dados pessoais ou regulados.
- Cumprir as leis e marcos regulatórios aplicáveis às nossas ofertas de serviços e localizações das empresas
- Obter e fornecer garantias de conformidade de terceiros independentes relevantes às nossas ofertas de serviços
IV. Monitoramento
Uma segurança adequada necessita de insight sobre processos e atividades.
-
O Assinante é responsável por monitorar todas as atividades em suas instâncias de serviço, inclusive:
- Monitorar as atividades dos usuários (por visualizações da UI ou registros da API)
- Realizar uma auditoria nas comunicações com indivíduos desconhecidos ou em conteúdo não confiável por meio do serviço
- Manter registros e dados extraídos do Serviço de acordo com quaisquer regulações aplicáveis
-
A Zendesk é responsável por monitorar processos e atividades do serviço em si, inclusive:
- Acesso privilegiado e atividades na rede de produção
- Tráfego recebido para alertar ou bloquear envios com erros conhecidos ou endereços IP
- Disponibilidade do serviço
- Comportamento anormal nos ativos de rede de produção ou corporativos
- A segurança do código, da infraestrutura, do tráfego e de pessoal relevante do contratado ou de funcionários
V. Manutenção
Sistemas e códigos sempre atualizados e corrigidos podem impedir vários problemas de segurança.
-
O Assinante é responsável por manter e corrigir quaisquer sistemas ou códigos além dos limites arquitetônicos e/ou contratuais da Zendesk*, inclusive:
- Sua própria infraestrutura, incluindo pontos de extremidade de funcionários, redes, infraestrutura personalizada ou middleware de terceiros usados para acessar os Serviços Zendesk e/ou manter o processamento dos Dados do Serviço antes que ingressem ou saiam dos sistemas da Zendesk
- Seus próprios códigos não padronizados utilizados para fornecer funcionalidade adicional aos Serviços Zendesk, incluindo códigos desenvolvidos pela equipe interna do Assinante ou por terceiros, ou ainda códigos que o Assinante adquiriu para usar com os Serviços Zendesk. Também estão incluídos códigos personalizados desenvolvidos pelos Serviços profissionais da Zendesk a pedido dos Assinantes, desde que a responsabilidade por esses códigos e a manutenção deles tenha sido transferida para o Assinante como parte de um contrato personalizado.
-
A Zendesk é responsável por manter e corrigir todos os sistemas e códigos no seu âmbito contratual e de arquitetura, inclusive:
- Sua própria infraestrutura gerenciada logicamente nas instalações do provedor de hospedagem para fornecer os Serviços, incluindo sistemas operacionais, sistemas e infraestrutura de segurança sob seu controle direto, sistemas de armazenamento e orquestração etc.
- Uso de uma infraestrutura física própria e/ou gerenciada logicamente no ambiente corporativo da Zendesk, como pontos de extremidade de funcionários, infraestrutura de rede corporativa etc.
- A base de código exclusivo sustentando os Serviços da Zendesk.
* Observe que embora sejam executados no âmbito da arquitetura da Zendesk, os aplicativos do Marketplace não são contemplados pelo Contrato Principal de Serviços padrão da Zendesk, mas sim por termos específicos entre o Assinante e os próprios desenvolvedores dos aplicativos, conforme indicado em nossos Termos de Uso de Aplicativos do Marketplace. A manutenção dos aplicativos do Marketplace é de responsabilidade dos desenvolvedores terceirizados desses aplicativos.
VI. Incidentes de segurança
Mesmo com todos os esforços, nem sempre as coisas dão certo. A forma como você reconhece, responde e se recupera de um incidente de segurança é essencial para mitigar e manter a confiança de um cliente. Esta seção define as funções e responsabilidades de cada parte em caso de incidentes de segurança.
- O Assinante é responsável por qualquer incidente ou violação de segurança em suas instâncias específicas que não tenha sido causado ou possibilitado por vulnerabilidades ou incidentes dentro do serviço em si, inclusive
- Investigar e corrigir qualquer violação suspeita ou real em sua instância específica causada por (i) um controle insuficiente de acesso ou higienização (incluindo o uso de credenciais públicas fracas ou com vulnerabilidades), (ii) um monitoramento insuficiente das atividades dos usuários, (iii) a não realização de auditoria sobre comunicações ou conteúdo não confiável derivado de interações com usuários, ou (iv) qualquer incidente ou violação ocorrido pela interação com terceiros, em que tal integração foi realizada a critério exclusivo do assinante.
- Enviar notificações obrigatórias a autoridades do governo ou policiais, ou a usuários finais sobre violações causadas por ações do Assinante, terceiros integrados, ou relacionadas a notificações de Violações de Dados do Serviço recebidas da Zendesk com relação à instância do Assinante
-
A Zendesk é responsável por controles para investigar incidentes de segurança, bem como notificar os assinantes afetados por Violações de Dados do Serviço ocorridas por meio do próprio serviço, inclusive
- Contar com uma Política de Resposta a Incidentes de Segurança documentada e uma equipe com funções e responsabilidades de segurança
- Investigar atividades anormais
- Controlar qualquer Violação de Dados do Serviço confirmada
- Notificar quaisquer assinantes afetados ou órgãos governamentais ou policiais competentes quando exigido por lei.
- Garantir que processos de backup e recuperação de dados robustos sejam implementados e testados
VII. Links úteis
Atendimento ao cliente seguro com a segurança do Zendesk
Práticas recomendadas de segurança do Zendesk
Higienização e controles de acesso
Gerenciamento de segurança e acesso do usuário no Zendesk Support (links agregados)
Autenticação de usuário no Chat
Concessão de acesso temporário à sua conta para a Zendesk
Integrações
Aplicativos do Marketplace da Zendesk
Subprocessadores do Zendesk Connect
Dados, privacidade, conformidade e considerações regulatórias
Política de cookies de produtos da Zendesk
Contrato Principal de Serviços da Zendesk
Proteção de dados e privacidade da Zendesk
Monitoramento
Registro de auditoria de alterações nas instâncias do Support (UI / API)
API de registro de auditoria de eventos de ticket do Support
Exportações incrementais e API em tempo real do Chat
Objetos personalizados, eventos e API de perfis do Sunshine
Firehose API/tempo real do Sell
Em caso de dúvidas, contate-nos pelo e-mailsecurity@zendesk.com
VIII. Registro de alterações
16 de junho de 2023
- Inclusão de um registro de alterações
- Inclusão da Seção V Manutenção
- Explicação de incidentes causados pelo uso de credenciais fracas ou com vulnerabilidades públicas por Assinantes e/ou seus Usuários finais sob a responsabilidade do Assinante no âmbito da seção VI “Incidentes de Segurança”
Aviso sobre a tradução: este artigo foi traduzido por um software de tradução automática para oferecer a você uma compreensão básica do conteúdo. Medidas razoáveis foram tomadas para fornecer uma tradução precisa, no entanto, a Zendesk não garante a precisão da tradução.
Em caso de dúvidas relacionadas à precisão das informações contidas no artigo traduzido, consulte a versão oficial do artigo em inglês.
Editado 08 de mai. de 2024 · Craig Lima
0
Seguidores
2
Votos
0
Comentários
Craig Lima criou um artigo,
É preciso muita confiança para colocar seus dados na nuvem. Em troca, você quer saber se os parceiros com quem você compartilha essas informações consideram a segurança uma prioridade máxima. Nossos assinantes usam diversos padrões e estruturas para gerenciar informações confidenciais, por isso implementamos os seguintes benchmarks da Organização Internacional para Padronização (ISO) em nossos serviços para manter seus dados seguros e em conformidade.
ISO 27001
Os padrões ISO/IEC 27000 fornecem uma série de estruturas para ajudar as organizações a comparar seu tratamento de dados. O mais comum desses padrões, o “ISO/IEC 27001”, fornece requisitos para um Sistema de Gerenciamento de Segurança da Informação (ISMS) e garantia de que os requisitos são atendidos para organizações que concluem uma auditoria com êxito.
ISO 27018
O ISO/IEC 27018 fornece diretrizes com base no ISO/IEC 27002 e enfatiza a proteção de informações de identificação pessoal (PII) para prestadores de serviço na nuvem, como a Zendesk.
ISO 27701
A ISO/IEC 27701:2019 especifica requisitos e orientações para o estabelecimento, implementação, manutenção e melhoria contínua de um Sistema de Gerenciamento de Informações de Privacidade (PIMS). Ela é um complemento da ISO/IEC 27001 e da ISO/IEC 27002 para o gerenciamento da privacidade dentro de uma organização. Isso estabelece uma estrutura para o gerenciamento de dados pessoais usados por controladores e processadores de dados, alinhando os controles de segurança e privacidade.
Serviços e processos da Zendesk dentro do escopo dessas auditorias
O escopo das certificações ISO/IEC 27001:2013, ISO/IEC 27018:2014 e ISO/IEC 27701:2019 é limitado pela infraestrutura de rede global da Zendesk, Inc. e pelos produtos e serviços correspondentes, incluindo o gerenciamento de desenvolvimento, operações, manutenção e entrega do Support, Guide, Chat, Connect, Inbox e Explore, que são gerenciados centralmente fora da sede da Zendesk e têm suporte dos seguintes escritórios no escopo: San Francisco, CA e Madison, WI (Estados Unidos da América), Copenhagen (Dinamarca), Dublin (Irlanda), Manilla (Filipinas), Melbourne (Austrália), Montpellier (França) e Cingapura.
Além disso, um provedor de data center de Infraestrutura como Serviço (IaaS) é usado para proteger a infraestrutura que executa todos os serviços oferecidos na IaaS Cloud. Os controles de segurança do Zendesk para o gerenciamento do ambiente de IaaS estão incluídos no escopo deste certificado, com exceção dos controles físicos e ambientais.
Atualmente, nosso subprocessador para serviços de hospedagem é a AWS, que possui várias certificações ISO próprias. Para obter mais informações, consulte a página de conformidade aqui.
O que isso significa para os clientes
Internamente, buscamos essas auditorias independentes para garantir que nossas funções de gerenciamento de segurança e privacidade obedeçam aos principais padrões do setor. Para nossos clientes, esses padrões de conformidade validados externamente confirmam que estamos cumprindo nossas obrigações em termos de como gerenciamos os dados de clientes. Além disso, a ISO/IEC 27701 exige que as organizações declarem as leis e regulamentos aplicáveis como parte de seus critérios de auditoria, permitindo que esse padrão mapeie requisitos como o Regulamento Geral de Proteção de Dados (RGPD), a Lei de Privacidade do Consumidor da Califórnia (CCPA) e outras legislações .
Todos os clientes que usam produtos que estão no escopo recebem essa proteção
Essas certificações são para os nossos serviços listados anteriormente. Você não precisa pagar nada a mais ou configurar sua instância para ter essa proteção.
Certificações ISO 27001, ISO 27018 e ISO 27701 do Zendesk versus certificações de clientes
Nossas certificações ISO 27001, ISO 27018 e ISO 27701 abrangem os processos de gerenciamento de segurança e privacidade em um escopo específico de serviços da Zendesk. Se você deseja obter alguma dessas certificações enquanto opera parte de seu serviço usando o Zendesk, observe que você não será certificado automaticamente por associação. No entanto, nossas certificações podem facilitar a obtenção dessas certificações para sua própria instância.
Obtenção de certificações ISO da Zendesk
Você pode acessar livremente nossos certificados ISO a qualquer momento, sem custos, sem NDA, preenchendo o formulário a seguir: https://www.zendesk.com/product/zendesk-security/#anchor-security-resources
Aviso sobre a tradução: este artigo foi traduzido por um software de tradução automática para oferecer a você uma compreensão básica do conteúdo. Medidas razoáveis foram tomadas para fornecer uma tradução precisa, no entanto, a Zendesk não garante a precisão da tradução.
Em caso de dúvidas relacionadas à precisão das informações contidas no artigo traduzido, consulte a versão oficial do artigo em inglês.
Editado 08 de mai. de 2024 · Craig Lima
3
Seguidores
2
Votos
0
Comentários
Craig Lima criou um artigo,
Contas habilitadas para HIPAA e HDS (coletivamente "Contas habilitadas para a área de saúde"):
Todos os termos em letras maiúsculas usados neste documento terão os significados atribuídos a eles no Business Associate Agreement ("BAA") da Zendesk ou no Anexo de Termos da HDS ao Contrato Principal de Assinatura da Zendesk ("Anexo HDS"), conforme aplicável ao tipo de conta (coletivamente, “Contrato de assistência médica”).
Para fins de contas com HIPAA , "PHI" significa "Informações de saúde protegidas" e, para fins de contas com HDS, "PHI" significa "informações pessoais de saúde".
A Zendesk e o Assinante firmaram um Contrato de assistência médica que recomenda que o Assinante avalie e implemente, conforme apropriado para seu caso de uso, as seguintes configurações ou alternativas avaliadas pelo Assinante para atender aos requisitos de conformidade sob a lei aplicável, para toda e qualquer Conta Habilitada para a Saúde (s) antes de introduzir qualquer PHI no(s) Serviço(s).
Se o Assinante escolher, a seu exclusivo critério, renunciar à implementação de qualquer uma das configurações recomendadas listadas abaixo, o Assinante assumirá a responsabilidade por qualquer acesso não autorizado ou uso indevido de divulgação dos Dados de Serviço do Assinante, incluindo qualquer PHI, que resulte de qualquer tais desvios das configurações recomendadas pelo Assinante.
O assinante deve ter adquirido planos de serviço no nível apropriado e ter os complementos associados necessários (consulte seu representante de vendas em caso de dúvida).
Se o Assinante tiver uma Conta com HDS ativado, o Assinante deve clicar no botão "Seguir" na Política de Subprocessador do Zendesk para receber notificações de quaisquer alterações nos subprocessadores usados para fornecer os Serviços.
As configurações de segurança mínimas a seguir para os serviços do Zendesk devem ser implementadas e são reconhecidas no Contrato de assistência médica para qualquer conta habilitada para a área de saúde
I. Zendesk Support:
-
Proteja a autenticação do agente por um dos dois métodos a seguir:
- Empregando o Zendesk Support nativo com configurações de senha: (i) definido como “Recomendado”; ou (ii) personalizado pelo Assinante de maneira que estabeleça requisitos não menos seguros do que os estabelecidos na configuração “Recomendado”. Além disso, de acordo com a opção nesta subseção, o Assinante também deve ativar e aplicar a Autenticação de Dois Fatores ("2FA") nativamente dentro do Serviço; e os controles administrativos que permitem que os administradores definam senhas para os usuários finais devem ser desativados; ou
- Usar uma solução externa de Single Sign On (SSO") com requisitos estabelecidos não menos seguros do que os estabelecidos na configuração de senha "Recomendado" do Zendesk e ativar e aplicar a autenticação de dois fatores dentro da solução selecionada para o acesso de todos os agentes. Os controles administrativos que permitem que os administradores definam senhas para os usuários finais devem ser desativados.
- Todas as opções de autenticação que utilizam SSO como método de autenticação devem desativar o acesso por senha.
- A criptografia Secure Socket Layer ("SSL") nas contas com suporte para assistência médica deve permanecer sempre ativada. Contas habilitadas para a área de saúde que utilizam um domínio diferente de zendesk.com devem estabelecer e manter SSL hospedado.
- Sempre que possível, o acesso do agente deve ser restrito a endereços IP específicos sob o controle do Assinante a menos que o Assinante habilite a autenticação multifator para agentes conforme descrito acima nos requisitos 1.a ou 1.b (nativamente dentro do Serviço ou dentro do ambiente do Assinante, juntamente com o Enterprise SSO). Para evitar dúvidas, "Acesso de agente" deve denotar o acesso concedido a um agente humano que acessa os Dados de Serviço por meio da Interface do Usuário ("IU").
-
Na medida em que a Conta Habilitada para Saúde do Assinante permita chamadas para as Interfaces de Programação de Aplicativos do Zendesk ("APIs"), o Assinante assumirá toda a responsabilidade por entender as implicações de segurança de todas as entidades do Assinante ou de terceiros com permissão para criar, acessar, modificar ou apagar Dados de Serviço e PHI por meio desse acesso e/ou integrações. Para acessar essas APIs, o Zendesk oferece vários métodos, conforme descrito aqui , e o Assinante deve implementar as seguintes práticas recomendadas de segurança com base no modelo de API usado:
- Abordagem OAuth 2.0. Esse modelo fornece os recursos de segurança mais granulares, mas requer que os direitos sejam aceitos por um usuário final. Sempre que possível, o Assinante deve utilizar a abordagem e o esquema de autenticação OAuth 2.0. O Assinante deve dar a cada cliente OAuth uma função de designação de Nome do Cliente e Identificador Exclusivo descritivo e exclusivo. As permissões concedidas para cada token OAuth devem permitir o mínimo de privilégios necessários para realizar as tarefas necessárias.
- Abordagem do token da REST API. Esse modelo é o mais amplo e permite que um token da API utilize toda a funcionalidade do modelo da API. Por sua natureza, ele fornece acesso e recursos mais amplos e deve ser usado com cautela. Ao usar essa abordagem, o Assinante deve (i) usar um token exclusivo para cada serviço e dar ao token um nome descritivo que designe a função; (ii) não compartilhar tokens da API com terceiros, a menos que seja razoavelmente necessário e de acordo com métodos de transmissão que são criptografados de ponta a ponta; (iii) reconhecer que, se o token da API for compartilhado com terceiros e o Assinante for informado de uma violação de dados de terceiros, o Assinante deve alternar o token associado imediatamente; e (iv) no mínimo, alterne o token com frequência de acordo com as políticas da organização do Assinante.
- Quando possível, o Assinante deve desativar a senha de acesso à API, pois essa abordagem envia credenciais de usuário a cada solicitação, o que as expõe de maneira ampla, facilitando a interceptação por terceiros mal-intencionados.
- O assinante deve ativar a opção "Solicitar autenticação para download" para solicitar autenticação para acessar anexos. Não fazer isso significa que qualquer anexo irrestrito pode ser acessado por qualquer pessoa com acesso à URL correta do referido anexo. Nesses casos, o Assinante assumirá toda a responsabilidade pelo conteúdo e acesso a esses dados de anexo.
- O Assinante deve aplicar sistematicamente, em todos os pontos de extremidade acessados por Agentes, Administradores e Proprietários, um protetor de tela bloqueado por senha ou uma tela de inicialização configurada para interagir com, no máximo, quinze (15) minutos de inatividade do sistema.
- O Assinante não deve alterar as permissões de visualização que permitem que um usuário veja atualizações de uma instância/marca/organização inteira ou alterar a configuração padrão que permite acesso além dos tickets ou grupo do próprio usuário (a menos que o Assinante assuma toda a responsabilidade por garantir que esses usuários sejam aprovados pelo Assinante para acessar todos os dados subsequentes). O Assinante reconhece que as permissões da organização do Usuário Final podem ser definidas no perfil do usuário e na própria organização e, se as configurações forem conflitantes, a configuração mais permissiva anula a configuração menos permissiva.
- O Assinante reconhece que a Zendesk não é responsável por proteger as transmissões de e-mail dos Usuários Finais e os Dados de Serviço relacionados antes de serem recebidos na instância do Zendesk Support do Assinante. Isso inclui qualquer PHI que possa ser transmitida por e-mail por meio de respostas aos tickets do Zendesk Support , incluindo, entre outros, comentários ou anexos do ticket.
- O Assinante reconhece que o Zendesk Support envia um e-mail para um Usuário Final sob várias circunstâncias, por exemplo, quando um Agente do Assinante responde a um ticket do Zendesk Support pelo canal de e-mail ou iniciado por uma automação ou gatilho. Por padrão, esse email contém a correspondência de ticket mais recente ou outras informações configuradas para serem incluídas em uma notificação automatizada, que pode incluir PHI. Para proteger ainda mais o Assinante, sua instância do Zendesk Support deve ser configurado para alertar apenas o usuário final que um agente respondeue solicitar que o usuário final se autentique no Zendesk Support para ver o conteúdo da mensagem.
-
O Assinante reconhece que qualquer funcionalidade de mensagem de texto utilizada a seu exclusivo critério em qualquer Serviço da Zendesk é sustentada por SMS e/ou protocolos relacionados, que podem envolver a transmissão não criptografada de mensagens enviadas para ou fora do(s) Serviço(s). Como tal, a funcionalidade de mensagem de texto deve:
- não pode ser usado em uma conta habilitada para a área de saúde* ou
- se usado, o Assinante assume toda a responsabilidade pelo uso de tal funcionalidade
- O Assinante reconhece que o uso da funcionalidade legada das Pesquisas de satisfação do cliente (" CSAT legadas") do Serviço envia os Dados do Serviço (que podem conter PHI) associados ao ticket do Support por e-mail para obter a classificação do usuário, cujo status de criptografia não é controlado por Zendesk. Como tal, a funcionalidade CSAT legada deve:
- não pode ser usado em uma conta habilitada para a área de saúde* ou
- se usado, o Assinante assume toda a responsabilidade pelo uso de tal funcionalidade
-
O Assinante reconhece que o uso da funcionalidade Pesquisas de Satisfação do Cliente ("CSAT") do Serviço para o canal de tickets, se não estiver configurado adequadamente, enviará os Dados do serviço (que podem conter PHI) associados ao ticket do Support por email para obter a classificação do usuário, cujo status de criptografia não é controlado pela Zendesk. Além disso, qualquer pessoa com a URL de CSAT específica tem acesso às respostas fornecidas para um ticket específico. Assim, ao usar a funcionalidade de CSAT para o canal de tickets, o Assinante deve
- Configure o corpo do email de automação de CSAT para não incluir possíveis PHI e use o {{satisfaction.survey_url}} placeholder exclusivamente
- Não usar a funcionalidade de perguntas abertas
* Para evitar dúvidas, as advertências de dados relacionadas a PHI na seção 10 sobre SMS não se aplicam ao uso de 2FA no produto (conforme descrito na seção 1.a), pois essa funcionalidade envia apenas uma sequência numérica para verificação de identidade.
II. Zendesk Guide e Gather:
- O Assinante reconhece que os Serviços do Guide e Gather são públicos por natureza (onde não é possível aproveitar artigos restritos ou usar uma instância fechada ou restrita) e, portanto, o Assinante deve garantir que quaisquer artigos no Zendesk Guide ou no Serviço Gather não incluam PHI, seja por meio do texto de artigo ou como anexo ou imagem dentro do artigo.
- O Assinante deve desativar a capacidade de os Usuários Finais adicionarem comentários no Zendesk Guide ou deve moderar e assumir a responsabilidade pela remoção de PHI de todos os comentários (conforme indicado na seção 3 abaixo).
- Onde o Serviço do Zendesk Guide for Guide Professional ou Enterprise, os Assinantes devem, quando possível, desativar a capacidade de os usuários finais criarem novas publicações desativando a funcionalidade Gather com o Zendesk Guide ou quando os recursos do Gather não puderem ser usados devido à intenção do Assinante caso de uso, os assinantes devem ativar a moderação de conteúdo no Zendesk Guide Service e definir como "Moderar todo o conteúdo". Nenhum envio contendo PHI deve ser aprovado.
- O uso por Assinante de “Moderadores da Comunidade” que não sejam funcionários no Serviço Gather não deve ser permitido, a menos que o Assinante assuma a responsabilidade pelo acesso potencial desses Usuários aos dados, incluindo possíveis PHI (quando aplicável).
- O Assinante reconhece que "@menções" de membros da comunidade do Gather são possíveis quando os usuários finais têm perfis públicos e, caso essa funcionalidade seja considerada um risco em seu caso de uso, os perfis públicos devem ser desativados ou as @menções devem ser desativadas.
III. Mensagens do Zendesk:
- O Assinante não deve ativar as integrações de canais de mensagens em redes sociais, a menos que assuma total responsabilidade por (i) garantir que nenhuma PHI esteja presente nas mensagens de redes sociais ou (ii) conclua seu próprio BAA com plataformas de mensagens integradas.
- O Assinante deve desativar a capacidade de os Usuários Finais anexarem arquivos a conversas por mensagens e deve assumir total responsabilidade por (i) ativar anexos seguros ou (ii) garantir que os Agentes não anexem arquivos contendo ePHI a conversas por mensagem. Não fazer isso significa que qualquer anexo irrestrito pode ser acessado por qualquer pessoa com acesso à URL correta do referido anexo. Nesses casos, o Assinante assumirá toda a responsabilidade pelo conteúdo e acesso a essas URLs e/ou dados de anexo.
- O Assinante assumirá toda a responsabilidade por garantir que todos os Agentes e Agentes light tenham permissão para visualizar todas as mensagens recebidas de todos os Usuários Finais.
- Se o Assinante ou seus Agentes acessarem ou desenvolverem integrações (por exemplo, como parte de um fluxo criado para Agentes de IA ) para APIs e webhooks ou personalizarem a experiência de mensagens, o Assinante assumirá total responsabilidade por entender as implicações de privacidade e segurança de todos os fluxos de trabalho personalizados e por todos Assinantes ou entidades terceirizadas (incluindo provedores de chatbots) têm permissão para criar, acessar, modificar ou apagar Dados do Serviço e ePHI por meio desse acesso e/ou integrações.
- Se o Assinante desejar remover a permissão de um Agente para participar de uma conversa por mensagem enquanto a conversa por mensagem estiver ativa no momento, o Assinante assumirá toda a responsabilidade por forçar o encerramento do acesso do referido Agente ao Zendesk.
- Por padrão, as conversas do Web Widget com os Usuários Finais são permanentes e poderão ser visualizadas pelo Usuário Final quando ele retornar ao web chat a partir do mesmo dispositivo. O Assinante deve desativar esse recurso ou assumir toda a responsabilidade por garantir que os Usuários Finais não compartilhem dispositivos.
-
Se o Assinante desejar implementar a autenticação para Usuários Finais, o Assinante assumirá toda a responsabilidade por implementá-la de maneira segura, de acordo com as práticas recomendadas e os padrões do setor.
- Ao usar essa abordagem, o Assinante deve (i) usar uma chave de assinatura JWT exclusiva para cada canal de autenticação e dar ao token um nome descritivo que designe a função; (ii) não compartilhar chaves de assinatura JWT com terceiros, a menos que seja razoavelmente necessário e de acordo com métodos de transmissão que são criptografados de ponta a ponta; (iii) reconhecer que, se a chave de assinatura do JWT for compartilhada com terceiros e o Assinante for informado de uma violação de dados de terceiros, o Assinante deve alternar a chave de assinatura do JWT associada imediatamente; e (iv) no mínimo, alterne a chave de assinatura do JWT com frequência de acordo com as políticas da organização do Assinante.
- O assinante deve usar o atributo JWT de validade e definir seu valor como não mais que 15 minutos.
- O Assinante reconhece que as interações entre Usuários Finais e Agentes de IA que não são entregues a um Agente humano e transferidas para um ticket ainda estão armazenadas no sistema e é responsabilidade do Assinante apagá-las de acordo com suas obrigações (por exemplo, implementando uma webhook que alerta o Assinante quando essas conversas são armazenadas e (automaticamente) aciona a exclusão pela API do Sunshine Conversations ).
- O Assinante reconhece que as conversas entre Usuários Finais e Agentes de IA que foram transformadas em um ticket não pode ser suprimido no momento. A exclusão é possível apagando o ticket.
- O Assinante reconhece que os anexos do Usuário Final nos canais de mensagens não são verificados quanto a malware no Zendesk no momento. O Assinante deve assumir total responsabilidade por implementar procedimentos e políticas para mitigar o risco para os ativos do Assinante.
- O Assinante reconhece que o uso da funcionalidade "Conversas paralelas" pode resultar na criação de mensagens de "ticket dependente" e/ou "conversa paralela" dentro ou enviadas da instância de Support do Assinante para destinatários por ticket, e-mail, Slack ou integrações (a critério do agente de configuração) . Se o Assinante optar por usar essa funcionalidade em uma Conta Habilitada para Saúde, o Assinante assumirá toda e qualquer responsabilidade por (i) garantir que nenhuma PHI esteja presente em tais mensagens ou (ii) se PHI puder estar presente em mensagens, o Assinante é o único responsável por qualquer responsabilidade, custo, dano ou dano relacionado à aquisição, acesso, uso ou divulgação não autorizados de PHI resultantes da troca de mensagens por meio da funcionalidade “Conversas paralelas”.
IV. Zendesk Sunshine Conversations:
- O Assinante não deve ativar integrações de canais de terceiros, a menos que assuma total responsabilidade por garantir que (i) nenhuma PHI esteja presente em mensagens de canal de terceiros ou (ii) conclua seu próprio BAA com plataformas de mensagens integradas.
-
O Assinante assumirá toda a responsabilidade por entender as implicações de segurança de todas as entidades do Assinante ou de terceiros com permissão para criar, acessar, modificar ou apagar Dados de Serviço e PHI por meio das Interfaces de Programação de Aplicativos do Sunshine Conversations ("APIs"). Para acessar essas APIs, o Assinante deve implementar as seguintes práticas recomendadas de segurança com base no modelo de API usado:
- Abordagem OAuth 2.0. Esse modelo fornece os recursos de segurança mais granulares, mas requer que os direitos sejam aceitos por um usuário final. Sempre que possível, o Assinante deve utilizar a abordagem e o esquema de autenticação do OAuth 2.0. O Assinante deve dar a cada cliente OAuth uma função de designação de Nome do Cliente e Identificador Exclusivo descritivo e exclusivo.
- Abordagem do token da REST API. Esse modelo é o mais amplo e permite que um token da API utilize toda a funcionalidade do modelo da API. Por sua natureza, ele fornece acesso e recursos mais amplos e deve ser usado com cautela. Ao usar essa abordagem, o Assinante deve (i) usar um token exclusivo para cada serviço e dar ao token um nome descritivo que designe a função; (ii) não compartilhar tokens da API com terceiros, a menos que seja razoavelmente necessário e de acordo com métodos de transmissão que são criptografados de ponta a ponta; (iii) reconhecer que, se o token da API for compartilhado com terceiros e o Assinante for informado de uma violação de dados de terceiros, o Assinante deve alternar o token associado imediatamente; e (iv) alternar o token com frequência de acordo com a política da organização do Assinante.
- Se o Assinante ou seus Agentes acessarem ou desenvolverem integrações para APIs e webhooks ou personalizarem a experiência do Sunshine Conversations , o Assinante assumirá total responsabilidade por entender as implicações de privacidade e segurança de todos os fluxos de trabalho personalizados e de todas as entidades do Assinante ou de terceiros (incluindo provedores de chatbot) permitidas para criar, acessar, modificar ou apagar Dados do Serviço e PHI por meio desse acesso e/ou integrações.
- O Assinante reconhece que as restrições de IP configuradas para o Zendesk Support não se estendem à API do Sunshine Conversations . Os assinantes devem assumir total responsabilidade por restringir o acesso à API do Sunshine Conversations e aos tokens da API, conforme descrito em 2.b. e de acordo com as políticas do Assinante.
- O Assinante deve desativar a capacidade de os Usuários finais anexarem arquivos às conversas do Sunshine Conversations e deve assumir total responsabilidade por ativar anexos seguros ou garantir que os agentes não anexem arquivos contendo PHI a conversas por mensagem. Não fazer isso significa que qualquer anexo irrestrito pode ser acessado por qualquer pessoa com acesso à URL correta do referido anexo. Nesses casos, o Assinante assumirá toda a responsabilidade pelo conteúdo e acesso a esses dados de anexo.
-
Se o Assinante desejar implementar a Autenticação para Usuários Finais, o Assinante assumirá toda a responsabilidade por implementá-la de maneira robusta, de acordo com as práticas recomendadas de segurança e os padrões do setor.
- Ao usar essa abordagem, o Assinante deve (i) usar uma chave de assinatura JWT exclusiva para cada canal de autenticação e dar ao token um nome descritivo que designe a função; (ii) não compartilhar chaves de assinatura JWT com terceiros, a menos que seja razoavelmente necessário e de acordo com métodos de transmissão que são criptografados de ponta a ponta; (iii) reconhecer que, se a chave de assinatura do JWT for compartilhada com terceiros e o Assinante for informado de uma violação de dados de terceiros, o Assinante deve alternar a chave de assinatura do JWT associada imediatamente; e (iv) no mínimo, alterne a chave de assinatura do JWT com frequência de acordo com as políticas da organização do Assinante.
- O assinante deve usar o atributo JWT de validade e definir seu valor como não mais que 15 minutos.
- O Assinante reconhece que as interações entre Usuários Finais e Agentes de IA que não são entregues a um Agente humano e transferidas para um ticket ainda estão armazenadas no sistema e é responsabilidade do Assinante apagá-las de acordo com suas obrigações, por exemplo, implementando um webhook que alerta o Assinante quando essas conversas são armazenadas e (automaticamente) aciona a exclusão pela API do Sunshine Conversations
- O Assinante reconhece que as conversas entre Usuários Finais e Agentes de IA que foram transformadas em um ticket não podem ser suprimidas no momento. A exclusão é possível apagando o ticket.
- O Assinante reconhece que as mensagens apagadas pela API do Sunshine Conversations são apagadas apenas para os Usuários Finais, mas não são apagadas no Espaço de trabalho do agente do Zendesk. Isso pode ser feito com a exclusão do próprio ticket ou o uso da funcionalidade Supressão (consulte Limitações 7.).
- O Assinante reconhece que todos os anexos nos canais do Sunshine Conversation não são verificados quanto a malware no Zendesk. O Assinante deve assumir total responsabilidade por implementar procedimentos e políticas para mitigar o risco para os funcionários do Assinante.
V. Zendesk Chat:
- O Assinante deve limitar o acesso dos Agentes ao Serviço do Zendesk Chat associando e autenticando pelo Serviço do Zendesk Support .
- O assinante não deve enviar transcrições do Chat por e-mail, (a) desativando a transferência de e-mail, (b) desativando a opção de transcrição de chat por e-mail no Web Widget Clássico e (c) não compartilhando exportações por e-mail do painel do Chat
- O Assinante assume total responsabilidade por garantir que (i) nenhuma PHI esteja presente nos Chats e/ou (ii) que todos os Agentes tenham permissão para visualizar esses dados.
VI. Serviço do Zendesk Explore :
O Assinante reconhece que as PHI podem ser exibidas no produto Explore por meio de nomes de usuário, títulos de ticket, opções de campo e formulário e qualquer conteúdo encontrado em campos de texto de formato livre.
- Para quaisquer instâncias de Serviço no escopo contendo PHI, o Assinante deve (i) conceder acesso à interface do Explore apenas aos agentes que podem acessar todos os tickets/chamadas/chats que possam conter PHI nas instâncias de Serviço pai e (ii) devem conceder esse acesso levando em consideração o mínimo de privilégios necessários para o uso do Explore em seu ambiente. Para obter mais informações sobre a configuração de níveis de acesso no Explore, consulte aqui.
- Ao aproveitar a funcionalidade de "exportação", (i) o Assinante reconhece que as PHI podem ser transferidas para o dispositivo permitido pelo Assinante para acessar a interface do agente e todos os controles de atendimento nesses dispositivos são de responsabilidade do Assinante e (ii) o Assinante deve negar o uso da funcionalidade de exportação nativa por e-mail para os referidos relatórios exportados, a menos que assuma a responsabilidade de (a) garantir que nenhuma PHI esteja contida nessas exportações ou (b) que os serviços de e-mail usados para essas transferências possam acomodar a criptografia por meio do protocolo de criptografia mínimo permitido pelos padrões PCI então vigentes.
* Considerações especiais para o uso do Explore Enterprise:
O Assinante reconhece que o uso do Serviço Explore Enterprise pode implicar em mais recursos de compartilhamento e exportação de dados. O Assinante deve:
- (i) garantir que não existam PHI nesses painéis e/ou (ii) compartilhar painéis apenas com agentes, grupos, listas ou usuários finais aprovados para visualizar e receber esses dados.
- aproveitar restrições de IP
- ao compartilhar painéis por URL (Uniform Resource Locator), o Assinante reconhece que, em vez de compartilhar com contas de usuários individuais ou em grupo, os dados devem ser compartilhados por um link de acesso. Portanto, o Assinante deve (i) ativar a proteção por senha, (ii) garantir que a complexidade, a rotação, o armazenamento e a distribuição das senhas escolhidas para a parte receptora estejam em conformidade com as políticas de senha do Assinante para a proteção dos dados contidos nesses painéis e (iii) seja alternado sem demora indevida após a suspeita ou confirmação da exposição
VII. Aviso sobre a funcionalidade no produto para serviços associados implantados (“Complementos”):
- Serviço associado implantado do Collaboration: “Conversas paralelas”. O Assinante reconhece que o uso da funcionalidade "Conversas paralelas" pode resultar na criação de mensagens de "ticket dependente" e/ou "conversa paralela" dentro ou enviadas da instância de Support do Assinante para destinatários por ticket, e-mail, Slack ou integrações (a critério do agente de configuração) . Se o Assinante optar por usar essa funcionalidade em uma Conta Habilitada para Saúde, o Assinante assumirá toda e qualquer responsabilidade por (i) garantir que nenhuma PHI esteja presente em tais mensagens ou (ii) se PHI puder estar presente em mensagens, o Assinante é o único responsável por qualquer responsabilidade, custo, dano ou dano relacionado à aquisição, acesso, uso ou divulgação não autorizados de PHI resultantes da troca de mensagens por meio da funcionalidade “Conversas paralelas”.
VIII. Aplicativos para dispositivos móveis do Zendesk (ou acesso feito por dispositivos móveis, como smartphones ou tablets):
- O uso deve incluir criptografia no nível do dispositivo
- O acesso biométrico ou PIN definido para a configuração de dispositivo mais alta permitida deve ser aproveitado
- As notificações que permitem que os comentários do ticket sejam exibidos nas telas de bloqueio desses dispositivos devem ser desativadas
- Os bloqueios por inatividade de tela devem ser ativados e configurados para serem bloqueados a não mais de 15 minutos de inatividade.
- O Assinante reconhece que a funcionalidadede supressão não está disponível no aplicativo para dispositivos móveis do Support e que os agentes precisam entrar pelo navegador caso desejem usar a funcionalidade de supressão.
- Se o Assinante optar por autenticar os Usuários Finais para o recurso de mensagens do Zendesk, o Assinante reconhece que o status de autenticação de um Usuário Final não é exibido no Aplicativo para dispositivos móveis do Support .
IX. Zendesk Insights: o suporte a esse serviço foi descontinuado em 5 de fevereiro de 2021.
X. Aviso sobre a funcionalidade de IA do Zendesk (“ IA do Zendesk”, “IA avançada”, “IA generativa”, e outros):
- O Assinante reconhece que os recursos de IA do Zendesk têm como objetivo aumentar a produtividade dos Serviços do Zendesk e não devem ser usados de maneira que possa ser interpretada como (i) fornecimento de conselhos médicos ou de saúde, (ii) fornecimento de um diagnóstico de condição ou sintomas, (iii) prescrever um tratamento ou (iv) impedir de qualquer maneira que um usuário busque aconselhamento, diagnóstico ou tratamento de um profissional de saúde, (v) fornecer informações a um usuário ou tomar decisões, incluindo ou não o escopo de qualquer plano de saúde, programa de tratamento, serviço de teste ou qualquer outro serviço de saúde que possa afetar sua pesquisa ou recebimento de serviços de saúde (a menos que o Assinante assuma total responsabilidade por essa decisão com base em seu caso de uso exclusivo e interações com seus Usuários, também como as possíveis implicações do uso de IA dessa maneira).
- O Assinante reconhece que, se estiver usando recursos de IA generativa, essas saídas de IA geradas são geradas por computador e não por humanos e podem produzir saídas imprecisas. A Zendesk não garante a precisão desses resultados.
- O Assinante reconhece que, se uma saudação do bot de conversa de Agentes de IA for usada para fornecer uma mensagem de isenção de responsabilidade aos Usuários Finais do Assinante, a funcionalidade "Gerar variações" não será ativada para garantir a integridade do conteúdo da mensagem.
- O Assinante reconhece que ativar a funcionalidade de Escrita Aprimorada na Central de administração ativará essa funcionalidade para todos os agentes em sua instância, independentemente de suas funções e permissões.
XI. Zendesk QA
- O Assinante reconhece que os recursos de Zendesk QA IA do Zendesk têm como objetivo aumentar a produtividade dos Serviços do Zendesk e não devem ser usados de uma maneira que possa ser interpretada como (i) fornecimento de conselhos médicos ou de saúde, (ii) fornecimento de um diagnóstico de condição ou sintomas, (iii) prescrever um tratamento ou (iv) impedir de qualquer maneira que um usuário busque aconselhamento, diagnóstico ou tratamento de um profissional de saúde, (v) ou fornecer informações a um usuário ou tomar decisões que incluam ou excluam o escopo de qualquer plano de saúde, programa de tratamento, serviço de teste ou qualquer outro serviço de saúde que possa afetar sua pesquisa ou recebimento de serviços de saúde (a menos que o Assinante assuma total responsabilidade por essa decisão com base em seu caso de uso exclusivo e interações com seus Usuários, como bem como as possíveis implicações do uso de IA dessa maneira).
- O Assinante reconhece que a exclusão ou supressão em sua instância do Zendesk não é sincronizada imediatamente com o Zendesk QA , mas será transferida nas 3 a 6 horas seguintes.
- Ao usar a funcionalidade Pesquisas, o Assinante deve (i) desativar a funcionalidade de assistência de IA do Zendesk QA (ou garantir que todos os agentes que realizam o trabalho de QA estejam liberados para ver quaisquer dados potenciais dentro dessa transação, além de garantir que os princípios do ponto 1 estejam em vigor) ( ii) certifique-se de configurar a pesquisa de maneira a não revelar PHI nas perguntas ou descrições da pesquisa (ou assumir a responsabilidade por esses dados em e-mails enviados pelo oportunista StartTLS)
- Ao usar a integração personalizada do “Zendesk Chat”, o Assinante deve considerar a definição de um período de retenção de dados alinhado com as políticas do Assinante para garantir que os dados não sejam retidos por tempo ilimitado.
- O Assinante reconhece que, ao usar a API do Sunshine Conversations para apagar partes de uma conversa do recurso de mensagens do Zendesk, essa alteração não é refletida no Zendesk QA. Em vez disso, as informações devem ser removidas do ticket original por supressão ou toda a conversa deve ser removida.
- O Assinante reconhece que o Zendesk QA não oferece suporte ao recurso "anexos privados" do Zendesk no momento. Isso significa que os anexos podem ser acessados por qualquer pessoa com acesso à URL correta para o referido anexo e não devem ser usados com dados confidenciais, incluindo PHI. O Assinante assumirá toda a responsabilidade pelo conteúdo e acesso a tais URLs e/ou dados de anexo.
- O Assinante reconhece que, de acordo com as provisões iniciais do Zendesk QA, a configuração de conexão avançada só é possível após a primeira sincronização.
XII. Gerenciamento da força de trabalho do Zendesk "WFM":
- O Assinante reconhece que
- A função Administrador do WFM padrão tem acesso a todas as atividades e configurações do agente aplicáveis ao Serviço do WFM (incluindo as tags mencionadas no ponto 2 abaixo).
- A função de agente padrão tem acesso à atividade do agente, a menos que configurada pelos administradores para ter acesso diferente por meio da criação de funções personalizadas , conforme descrito aqui
- O Assinante reconhece que as tags aplicadas por Agentes, Administradores ou a lógica do sistema predefinida nos tickets no Support ficarão visíveis no produto WFM para qualquer Usuário com permissão para ver essa atividade do ticket. Se as tags forem consideradas confidenciais pelo Assinante, o acesso deve ser configurado adequadamente.
Isenção de responsabilidade: Devido a alterações em leis ou regulamentos ou alterações no Serviço do Zendesk, as configurações de segurança neste documento podem mudar periodicamente. Este documento contém as recomendações da Zendesk para as configurações de segurança mínimas eficazes para a proteção de PHI nos produtos Zendesk descritos acima no momento. Este documento não constitui um modelo exaustivo para todos os controles sobre esses dados nem constitui aconselhamento jurídico. Cada assinante do Zendesk deve procurar sua própria assessoria jurídica com relação aos requisitos de conformidade com HIPAA ou HDS e deve fazer alterações adicionais em suas configurações de segurança de acordo com a análise independente de cada assinante, desde que essas alterações não prejudiquem a segurança de as configurações descritas neste documento.
Registro de alterações:
24 de janeiro de 2025
- Configurações HIPAA e HDS consolidadas
27 de dezembro de 2024
- Adição da seção XII para incorporar o Gerenciamento da força de trabalho do Zendesk ("WFM") ao escopo
16 de dezembro de 2024
- Adição da seção XI para incorporar o Zendesk QA ao escopo
- Várias instâncias de "Answer Bot" foram alteradas para " Agentes de IA " para denotar alterações na convenção de nomenclatura e um escopo mais amplo.
10 de outubro de 2024
- Adição da Seção I, Support, número 12 (CSAT) e edição da Seção I, Support, número 11 ( CSAT legado) para acomodar a nova funcionalidade.
7 de março de 2024
- Seção X adicionada, Aviso sobre a funcionalidade de IA do Zendesk
-
Seção I, Support, número 7 (permissões de visualização):
- Esclareceu que as "permissões de visualização" pertencem a uma "instância/marca/organização" inteira, e não apenas à "organização".
- Adição de uma nova disposição para o comportamento específico da organização do usuário final.
-
Seção I, Support, número 9 (e-mail):
- Expandiu as circunstâncias nas quais o Zendesk Support envia um email para um usuário final para incluir respostas pelo canal de email ou aquelas iniciadas por uma automação ou gatilho, em vez de apenas um agente respondendo a um ticket.
- Especificou que, por padrão, as notificações automatizadas podem conter a correspondência de ticket mais recente ou outras informações configuradas, que podem incluir PHI.
25 de outubro de 2023
- Introdução: Linguagem de introdução mais clara para contas com HIPAA ativado
- Seção II, Guide e Gather, número 1 (Restrições da Central de Ajuda): substituição das restrições de IP por artigos restritos para esclarecimento
13 de abril de 2023
-
Seção I, Support, número 4 (APIs) :
- Link adicionado para os métodos de autenticação para fins de clareza
- b) Remoção das recomendações de período de tempo exato para rotação a fim de se alinhar às práticas recomendadas do setor e remoção da referência aos Termos de Serviço da REST API (redundância)
- adicionou c) para avisar sobre o uso da autenticação básica para a API
-
Seção II, Guide:
- Número 1 (Restrições da Central de Ajuda): adição de referência a centrais de ajuda fechadas ou restritas para alinhamento com a funcionalidade do produto
- Número 5 (@menções): Adicionada a opção de desativar @menções para alinhar com o produto funcionalidade
-
Seção III, mensagens:
- Números 1 e 2 (canais de terceiros e anexos privados): adicionados identificadoresde seção (i) e (ii) para maior clareza
- Número 2 (anexos privados): adicionado “URLs e/ou” para esclarecimento
- Número 7-10 (autenticação do usuário final, exclusão de conversas do Answerbot, supressão, verificação de malware): seções completas adicionadas para fins de transparência
- Seção IV, Sunshine Conversations: toda a seção foi adicionada devido ao Sunshine Conversations na Zendesk Suite se tornar parte do BAA
- Seção V, Chat, número 3 (Espaço de trabalho do agente): pequenas correções de frase
- Seção VIII, aplicativos para dispositivos móveis, número 5-7 (verificação de malware, supressão, autenticação do usuário final): seções inteiras adicionadas para fins de transparência
24 de fevereiro de 2023
- Seção I. Support, número 3: foi removida a distinção entre as restrições de IP do Support e do Chat, pois a interface do usuário agora está unificada.
- Seção I. Support, número 5: esclarecimento adicional sobre falha no cumprimento do requisito
- Seção I. Support, número 7: "Assinante não deve" alterado para "Assinante não deve".
- Seção IV. Chat, número 2: esclarece que toda a funcionalidade de exportação de dados do Chat usando e-mail é proibida e não está restrita apenas a transcrições e encaminhamentos.
- Seção III. mensagens: seção inteira adicionada à conta para a funcionalidade de mensagens do Zendesk, além do escopo do Business Associate Agreement da Zendesk.
9 de julho de 2021
- Adiciona o ponto 3. na seção Chat para responsabilidades relacionadas ao uso do Espaço de trabalho do agente .
21 de janeiro de 2021
- A adição do número 1.11 não permite o CSAT, a menos que o Assinante assuma a responsabilidade pelos dados enviados por email como parte da pesquisa.
- A ressalva no número 1.7 permite que os Assinantes alterem as permissões de visualização devido ao fato de os usuários já terem aprovação para acessar esses dados em suas extremidades.
- Todo o documento foi atualizado para corresponder ao estiloda empresa de links incorporados no texto, em vez de URLs incorporados (sem impacto no conteúdo da configuração).
Agosto de 2020
- Adição do Explore Enterprise, que abrange o aumento dos recursos de compartilhamento de painéis
- Remoção do banimento de anexos do Chat (aborda agora os requisitos de autenticação do Support )
- Desambiguação de que o banimento de ePHI em campos personalizados se aplicava especificamente ao uso do Insights e não globalmente
- Adição de uma nova seção que aborda complementos para serviços implantados, com "Conversas paralelas" sendo a primeira adição
- Várias edições de gramática/formatação (inconsequentes para o conteúdo)
13 de julho de 2020:
- Desambiguação feita em relação ao uso de SMS pelo Serviço em oposição ao uso nativo de SMS para 2FA no produto. * Para evitar dúvidas, as advertências de dados relacionadas ao ePHI na seção 10 sobre SMS não se aplicam ao uso de 2FA no produto (conforme descrito na seção 1.a), pois essa funcionalidade envia apenas uma cadeia de caracteres numérica para verificação de identidade."
13 de dezembro de 2019
- permite que as restrições de IP do agente sejam removidas onde o caso de uso não permite essas restrições, desde que a MFA no acesso do agente seja aplicada.
17 de dezembro de 2019
- permite comentários de usuários finais no Guide, desde que os agentes moderem esses comentários e removam todas as PHI.
6 de novembro de 2019
- Artigo atualizado para refletir a alteração de que os assinantes podem optar, a seu exclusivo critério, por abandonar ou substituir qualquer configuração específica, desde que assumam a responsabilidade por essa decisão.
"A falha do Assinante em implementar e cumprir qualquer configuração específica listada abaixo, ou qualquer série de configurações obrigatórias listadas abaixo, deve ser
risco do Assinante e a critério exclusivo do Assinante; e tal falha isentará a Zendesk e seus funcionários, agentes e afiliados de qualquer responsabilidade com relação a qualquer acesso não autorizado ou uso ou divulgação impróprios dos Dados de Serviço do Assinante, incluindo qualquer Informação de Saúde Protegida eletrônica, que resulte de tal falha pelo Assinante . "
-
Outras alterações incluem
- 1. a capacidade de usar SMS, desde que o assinante assuma toda a responsabilidade por garantir que nenhuma PHI esteja presente em tais transmissões.
- 2. A capacidade de usar anexos no Chat, desde que o assinante assuma toda a responsabilidade por garantir que nenhuma PHI esteja presente nesses anexos.
6 de março de 2019
- atualizado para incluir as configurações do Zendesk Explore
17 de janeiro de 2019
- atualizado para não permitir anexos no Chat.
Aviso sobre a tradução: este artigo foi traduzido por um software de tradução automática para oferecer a você uma compreensão básica do conteúdo. Medidas razoáveis foram tomadas para fornecer uma tradução precisa, no entanto, a Zendesk não garante a precisão da tradução.
Em caso de dúvidas relacionadas à precisão das informações contidas no artigo traduzido, consulte a versão oficial do artigo em inglês.
Editado 28 de jan. de 2025 · Craig Lima
0
Seguidores
1
Votos
0
Comentários
Craig Lima comentou,
July 9th 2021 edit:
1. Adds point 3. under Chat section for responsibilities around Agent Workspace usage.
Exibir comentário · Publicado 09 de jul. de 2021 · Craig Lima
0
Seguidores
0
Votos
0
Comentários
Craig Lima comentou,
January 21st, 2021
Addition of number 1.11 disallows CSAT unless Subscriber assumes responsibility of data sent via email as part of the survey.
Caveat in number 1.7 to make allowances for Subscribers altering viewing permissions due to users already having approval to access such data on their ends.
Updated entire document to match company stle of embedded links within text as opposed to inline URLs (no impact to configuration content).
Exibir comentário · Publicado 21 de jan. de 2021 · Craig Lima
0
Seguidores
0
Votos
0
Comentários