Ricerche recenti


Nessuna ricerca recente

Craig Lima's Avatar

Craig Lima

Data ingresso 14 apr 2021

·

Ultima attività 02 gen 2025

Seguiti

0

Follower

0

Attività totali

11

Voti

0

Abbonamenti

3

PANORAMICA ATTIVITÀ

Ultima attività di Craig Lima

Craig Lima ha commentato,

CommentoZendesk policies and agreements

Dec 27th, 2024, added section XII to incorporate Workforce Management “WFM” into HIPAA BAA scope

Visualizza commento · Data ultimo post: 02 gen 2025 · Craig Lima

0

Follower

0

Voti

0

Commenti


Craig Lima ha commentato,

CommentoZendesk policies and agreements

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

Visualizza commento · Data ultimo post: 17 dic 2024 · Craig Lima

0

Follower

0

Voti

0

Commenti


Craig Lima ha creato un articolo,

ArticoloPolicy Zendesk
Le funzionalità Zendesk WFM (Tymeshift), Zendesk QA (Klaus) e Ultimate sono ospitate da Google Cloud Platform (GCP) e potrebbero non essere disponibili nelle regioni elencate in questa pagina.

Regioni AWS in cui Zendesk ospita i dati del servizio per gli abbonati

Attualmente ospitiamo i dati dei servizi per gli abbonati nelle seguenti regioni AWS:

  • Stati Uniti orientali (Virginia settentrionale)
  • Stati Uniti orientali (Ohio)
  • Stati Uniti occidentali (Oregon)
  • SEE (Irlanda)
  • SEE (Francoforte)
  • Regno Unito (Londra)
  • Asia-Pacifico (Tokyo)
  • Asia-Pacifico (Osaka)
  • Asia-Pacifico (Sydney)

Accordi sulla località dei dati

Tieni presente che Zendesk si impegna solo per l’ubicazione di hosting dei dati di servizio degli abbonati in cui gli abbonati hanno acquistato ilcomponente aggiuntivo Ubicazione data center (un acquisto autonomo del componente aggiuntivo per la posizione del data center o quando il componente aggiuntivo per la posizione del data center è incluso nel piano di servizio acquistato). Consulta le Norme regionali sull’hosting dei datiqui per informazioni sulle eccezioni a questo impegno.

Per bilanciare la domanda, migliorare le prestazioni e fornire il miglior servizio, potremmo spostare i dati degli account tra le regioni senza preavviso.  Se un account ha acquistato il componente aggiuntivo Data Location, ci assicureremo che gli spostamenti regionali rientrino nel Paese o nei limiti legali richiesti.

Come ottenere l’indirizzo fisico in cui sono ospitati i dati del servizio

Su richiesta, possiamo comunicare la regione Amazon Web Services (AWS) (un’area generica che AWS può essere descritta come un Paese, una regione geografica all’interno di un Paese, uno stato e/o una città) in cui ospitiamo i Dati del servizio.

Non siamo in grado di fornire gli indirizzi fisici esatti in cui sono ospitati i dati del servizio a causa del modo in cui AWS opera a livello tecnico.  Si basa sull’architettura di AWS stessa.  AWS ha “regioni” in tutto il mondo.  All'interno di queste regioni esiste il concetto di "zone di disponibilità" o "AZ".  Quando si crea un asset in AWS, questo si trova in una o più zone alla disponibilità in una determinata regione.  Indipendentemente dalla scelta del proprietario dell'asset di replicare i dati all'interno di una regione o tra regioni, AWS stessa può replicare i dati all'interno della regione in altre AZ.  Il risultato è che i dati del servizio per gli abbonati Zendesk sono disponibili in numerose strutture in una determinata regione.  Inoltre, per motivi di sicurezza, AWS non autorizza ufficialmente la comunicazione dell'ubicazione specifica degli edifici del data center o delle strutture associate.

Se hai bisogno di sapere in quale regione AWS è ospitato il tuo sottodominio Zendesk,contatta l’assistenza clienti Zendesk.

REGISTRO CAMBIAMENTI:

Aprile 2024 - Aggiunta di un avvertimento per Zendesk WFM (Tymeshift) e Zendesk QA (Klaus)

Luglio 2024 - Aggiunta di un avvertimento per Ultimate

Luglio 2024 - Aggiunta di due nuove località di hosting: Regno Unito (Londra), Asia-Pacifico (Osaka)

 

Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.

Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.

Data ultima modifica: 02 lug 2024 · Craig Lima

5

Follower

1

Voto

0

Commenti


Craig Lima ha creato un articolo,

ArticoloPolicy Zendesk

Il modello di responsabilità condivisa Zendesk

Zendesk offre una piattaforma di assistenza clienti altamente configurabile e rapidamente scalabile a molte delle aziende leader a livello mondiale in un'ampia gamma di settori industriali.  Aiutando i nostri abbonati a sfruttare la nostra piattaforma cloud per le loro esigenze di assistenza clienti, consentiamo loro di ridurre le spese generali, di scalare per soddisfare la domanda e di fornire interazioni meravigliosamente semplici con i loro clienti.  

Lo spostamento dell’azienda nel cloud non solo offre i vantaggi descritti sopra, ma può includere ambiguità in merito a quale parte è responsabile del controllo.  Non preoccuparti, per semplificare le cose, di seguito troverai il nostro modello di responsabilità condivisa.  Questo framework chiarisce quale parte è responsabile di quali controlli relativi alla sicurezza e alla privacy dei tuoi dati.  Che tu sia un amministratore coscienzioso, un responsabile della sicurezza aziendale, della conformità o della privacy o chiunque altro abbia il compito di impostare i controlli appropriati per l'uso dei servizi Zendesk nel tuo ambiente, questo standard dovrebbe tracciare chiaramente i limiti di cui devi essere a conoscenza. 

Per riassumere in una frase, “Zendesk ha il compito di garantire la sicurezza del Servizio stesso, mentre a te è affidato il compito di garantire la sicurezza all’interno di particolari istanze del Servizio”. 

  1. Controlli di accesso e igiene
  2. Integrazioni
  3. Considerazioni su dati, privacy, conformità e normative
  4. Monitoraggio
  5. Manutenzione
  6. Incidenti di sicurezza (ruoli e responsabilità)
  7. Link utili
  8. Registro modifiche

Tieni presente che i termini in maiuscolo hanno il significato loro attribuito nell’Accordo sui servizi principali Zendesk (“MSA”).   

I. Controlli di accesso e igiene
Il controllo dell’accesso ai sistemi sensibili e ai dati al loro interno è fondamentale per i principi di sicurezza. 

  1. L’abbonato è responsabile di tutti i controlli di accesso alle proprie istanze del servizio, tra cui:
    1. Fornitura, modifica, igiene continua, mantenimento dell’accuratezza dei privilegi e rimozione del provisioning di tutti gli utenti, inclusi utenti finali e agenti (sia che si tratti di personale locale, remoto o di terzi) 
    2. Scelta e configurazione del metodo di autenticazione nel servizio tra le offerte supportate (possono includere password, MFA, SSO, ecc.)
    3. Configurazione e monitoraggio di aspetti della gestione delle sessioni come logout, dispositivi connessi, ecc.
    4. Consentire o impedire al nostro staff di assistenza di accedere alla tua istanza Support per assistenza
    5. Configurazione dell’accesso e comprensione delle implicazioni dell’uso dei servizi API REST di Zendesk (ove applicabile, incluse integrazioni, uso di Zendesk Sunshine Service, ecc.)
    6. Configurazione di qualsiasi limitazione IP supportata dal prodotto, se lo si desidera
    7. Considerando altri controlli di accesso non correlati ai prodotti, come i tipi di dispositivi che gli agenti possono usare per accedere alle istanze, nonché eventuali controlli fisici, logici o di policy applicabili agli utenti o ai dispositivi consentiti
  2. Zendesk è responsabile di tutti i controlli di accesso ai sistemi alla base del servizio, tra cui:
    1. Mantenimento di policy e procedure per il provisioning sicuro, la modifica, l’igiene continua, il mantenimento dell’accuratezza dei privilegi e l’annullamento del provisioning di tutti gli utenti (inclusa la forza lavoro locale, remota e di terzi)
    2. Applicazione del controllo degli accessi basato sui ruoli “RBAC”, il principio dei privilegi minimi “PLP”, sicurezza delle credenziali adeguata, inclusa l’autenticazione a più fattori “MFA” per tutti gli accessi di dipendenti e appaltatori a sistemi e applicazioni critici contenenti i dati di servizio dell’abbonato
    3. Esecuzione di controlli periodici su quanto sopra

II. Integrazioni 
L’uso di terzi può migliorare notevolmente l’efficienza, ma introduce anche considerazioni sulla sicurezza.

  1. L’Abbonato è tenuto a considerare le implicazioni sulla sicurezza derivanti dallo sfruttamento di tutte le integrazioni di terzi effettuate con il Servizio, tra cui:
    1. Integrazioni effettuate tramite API e/o SDK
    2. Integrazioni effettuate tramite l’installazione di app del Marketplace o l’abilitazione di canali di terzi
    3. Integrazioni con qualsiasi abbonato di terze parti che fornisce personale, strumenti, codice o assistenza diretta per le istanze Zendesk
  2. Zendesk è responsabile dell’attenta integrazione nel servizio di terze parti affidabili, tra cui:
    1. Verifica ed esercizio della due diligence continua per tutti i sub-responsabili del trattamento
    2. Integrazione sicura delle acquisizioni nel Servizio
    3. Garantire che eventuali partnership di prodotti e/o integrazioni di servizi con terzi abbiano le dovute considerazioni di sicurezza 

III. Considerazioni su dati, privacy, conformità e normative
È fondamentale tenere conto dei dati in uso, del loro corretto trattamento, di eventuali quadri normativi pertinenti e dell’importanza delle assicurazioni di terzi.

  1. L’abbonato è responsabile del corretto trattamento dei dati che acquisisce e usa, tra cui:
    1. Informazioni sui tipi di dati coinvolti nel loro caso d’uso particolare
    2. Trattare tali dati in conformità con la classificazione dei dati e le politiche sulla privacy della propria azienda, le leggi applicabili relative ai dati stessi, gli utenti che li forniscono, il settore degli abbonati e qualsiasi giurisdizione pertinente
    3. Scegliere quali canali consentire per la comunicazione con le proprie istanze del servizio
    4. Conservazione delle istanze e dei dati di servizio in conformità con qualsiasi quadro normativo, legale o normativo applicabile per il quale il settore, gli utenti o il caso d’uso dell’abbonato potrebbero rientrare
    5. Fornitura a Zendesk di certificati TLS alternativi quando si desidera mappare l’host a un dominio principale non Zendesk per la crittografia del traffico da e verso l’interfaccia utente o l’API Zendesk
    6. Comprendere dove i dati potrebbero non essere crittografati durante il transito e trattare di conseguenza tali canali o protocolli (principalmente email, SMS o integrazioni di terzi effettuate a esclusiva discrezione dell’abbonato che non supportano la crittografia)
    7. Garantire che i tipi di dati coinvolti nell’istanza dell’abbonato non violino i termini e le condizioni dell’Accordo sui servizi principali di Zendesk (consulta Zendesk MSA)
    8. Garantire che il livello di uptime e ripristino di emergenza scelto dall’abbonato sia conforme alle policy o alle normative a cui gli abbonati sono tenuti
  2. Zendesk è responsabile di: 
    1. Protezione adeguata di tutti i dati di servizio dalla divulgazione a livello di servizio (ad es. infrastruttura o codice) 
    2. Crittografia dei dati in transito da o verso la nostra interfaccia utente o API su reti pubbliche 
    3. Crittografia di tutti i dati di servizio inattivi
    4. Fornire agli abbonati informazioni sui dati raccolti dai cookie interni al prodotto e sull’uso predefinito dei servizi 
    5. Descrivendo accuratamente come utilizziamo i Dati dei servizi, inclusi i Dati personali, in modo anonimo e non per fornire i nostri Servizi o in altro modo.
    6. Fornire agli abbonati strumenti e funzionalità che li aiutano a adempiere ai propri obblighi in merito al corretto trattamento dei dati personali o regolamentati.
    7. Conformità alle leggi e ai quadri normativi applicabili relativi alle nostre offerte di servizi e alle sedi delle nostre attività
    8. Ottenere e fornire garanzie di conformità di terzi indipendenti pertinenti alle nostre offerte di servizi

IV. Monitoraggio
Una sicurezza adeguata richiede informazioni dettagliate su processi e attività.  

  1. L’abbonato è responsabile del monitoraggio di tutte le attività all’interno delle proprie istanze del servizio, tra cui:
    1. Monitoraggio delle attività degli utenti (tramite viste dell’interfaccia utente o registri API)
    2. Due diligence sulle comunicazioni con persone sconosciute o contenuti non attendibili derivati dal servizio
    3. Gestione dei registri o dei dati estratti dal Servizio in conformità con le normative applicabili
  2. Zendesk è responsabile del monitoraggio dei processi e delle attività del servizio stesso, tra cui:
    1. Accesso privilegiato e attività all’interno della rete di produzione
    2. Traffico in ingresso per allertare o bloccare invii o indirizzi IP non validi
    3. Tempo di attività del servizio
    4. Comportamento anomalo negli asset della rete aziendale o di produzione
    5. La sicurezza del codice, dell’infrastruttura, del traffico e del personale pertinente dei dipendenti o degli appaltatori

V. Manutenzione
Mantenere i sistemi e il codice aggiornati e corretti può prevenire molti problemi di sicurezza. 

  1. L’abbonato è responsabile della manutenzione e dell’applicazione di patch a qualsiasi sistema o codice oltre i limiti architetturali e/o contrattuali Zendesk*, inclusi:
    1. La propria infrastruttura, inclusi gli endpoint dei dipendenti, le reti, l’infrastruttura personalizzata o il middleware di terzi che usa per accedere ai servizi Zendesk e/o per elaborare ulteriormente i dati del servizio prima dell’ingresso o dell’uscita dai sistemi Zendesk  
    2. Il proprio codice non standard viene sfruttato per fornire funzionalità aggiuntive ai Servizi Zendesk, incluso il codice sviluppato internamente o da terzi che l’Abbonato ha sviluppato o acquistato per l’uso con i Servizi Zendesk. Ciò include anche qualsiasi codice personalizzato sviluppato da Zendesk Professional Services su richiesta degli Abbonati, a condizione che la responsabilità di tale codice e della relativa manutenzione sia stata trasferita all’Abbonato come parte del coinvolgimento personalizzato.
  2. Zendesk è responsabile della manutenzione e dell’aggiornamento di tutti i sistemi e del codice entro i suoi limiti architetturali e/o contrattuali, tra cui:
    1. La propria infrastruttura gestita logicamente all’interno delle strutture del provider di hosting usata per fornire i Servizi, inclusi i sistemi operativi, l’infrastruttura di sicurezza e i sistemi sotto il suo controllo diretto, i sistemi di container e di orchestrazione, ecc.
    2. La propria infrastruttura gestita fisicamente e/o logicamente usata nell’ambiente aziendale Zendesk, come gli endpoint dei dipendenti, l’infrastruttura di rete aziendale, ecc.
    3. Le basi di codice proprietarie alla base dei servizi Zendesk.

* Tieni presente che, sebbene le app del Marketplace vengano eseguite all’interno dei limiti dell’architettura Zendesk, non sono coperte dal Master Services Agreement standard di Zendesk, ma sono coperte da termini specifici tra l’abbonato e gli sviluppatori di app stessi, come indicato nelle Condizioni d’uso delle app del Marketplace. La manutenzione delle app del Marketplace è responsabilità degli sviluppatori terzi delle app del Marketplace.

VI. Incidenti di sicurezza
Nonostante i migliori sforzi, a volte le cose possono andare storte.  Il modo in cui riconosci, rispondi e risolvi un incidente di sicurezza è fondamentale per mitigare con successo e mantenere la fiducia dei clienti.  Questa sezione descrive i ruoli e le responsabilità di ciascuna parte durante gli incidenti di sicurezza. 

  1. L’abbonato è responsabile di qualsiasi incidente o violazione della sicurezza nelle sue istanze particolari, che non sia stato causato o causato da vulnerabilità o incidenti all’interno del servizio stesso, inclusi 
    1. Indagine e soluzione di qualsiasi violazione sospetta o effettiva all’interno della propria istanza specifica causata da (i) controllo degli accessi o igiene insufficienti (incluso l’uso di credenziali pubbliche deboli o sfruttabili), (ii) monitoraggio insufficiente delle attività degli utenti, (iii) mancata esecuzione diligenza sulle comunicazioni o sui contenuti non attendibili derivanti dalle interazioni con gli utenti, o (iv) qualsiasi incidente o violazione causato dall’integrazione con terzi, laddove tale integrazione sia stata effettuata a esclusiva discrezione dell’abbonato.
    2. Invio delle notifiche richieste al governo o alle forze dell’ordine o agli utenti finali in relazione a violazioni causate da azioni degli abbonati, terze parti integrate o relative a notifiche di violazione dei dati del servizio ricevute da Zendesk in merito all’istanza dell’abbonato
  2. Zendesk è responsabile dei controlli per le indagini sugli incidenti di sicurezza e della notifica agli abbonati interessati delle violazioni dei dati del servizio che si verificano tramite il servizio stesso, tra cui 
    1. Disporre di una policy di risposta agli incidenti di sicurezza documentata e di personale con ruoli e responsabilità di sicurezza pertinenti
    2. Indagine su attività anomale
    3. Contenente qualsiasi violazione dei dati del servizio confermata
    4. Notifica agli abbonati interessati o alle autorità competenti o alle forze dell’ordine ove richiesto dalla legge.
    5. Garantire che vengano implementati e testati processi di backup e ripristino di emergenza affidabili

VII. Link utili

Proteggi il servizio clienti con Zendesk Security

Best practice per la sicurezza Zendesk

Portale Zendesk Legal

Controlli di accesso e igiene

Gestione della sicurezza e dell’accesso degli utenti in Zendesk Support (link aggregati)

Ruoli utente in Chat

Autenticazione utente in Chat

Concedere a Zendesk l’accesso temporaneo al tuo account

Integrazioni

API Zendesk

App Zendesk Marketplace

Subprocessori Zendesk

Subprocessori Zendesk Connect

Partner Zendesk

Considerazioni su dati, privacy, conformità e normative

Informativa sui cookie interni al prodotto Zendesk

Accordo sui servizi principali Zendesk

Protezione dei dati e della privacy Zendesk

Monitoraggio

Log di verifica modifiche istanza Support (UI / API)

API del registro di verifica degli eventi dei ticket Support

Dashboard di Chat

Interfaccia utente Cronologia chat

Esportazioni incrementalidi Chat e API in tempo reale

Dashboard Talk

API Talk incrementale

API per oggetti, eventi e profili personalizzati Sunshine

API Sell in tempo reale/Firehose

 

In caso di ulteriori domande, non esitare a contattarci all’indirizzo security@zendesk.com  

VIII. Registro modifiche
16 giugno 2023

  1. Aggiunta di un registro delle modifiche
  2. Aggiunta della Sezione V Manutenzione
  3. Chiarire i dettagli degli incidenti causati dall’uso di credenziali deboli o sfruttabili pubblicamente usate dagli abbonati e/o dai loro utenti finali come responsabilità dell’abbonato nella sezione VI "Incidenti di sicurezza"

Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.

Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.

Data ultima modifica: 08 mag 2024 · Craig Lima

0

Follower

1

Voto

0

Commenti


Craig Lima ha creato un articolo,

ArticoloPolicy Zendesk

Quale piano sto usando?

Tutte le suite

Ci vuole molta fiducia per mettere i dati nel cloud. In cambio, vuoi sapere che i partner con cui condividi queste informazioni considerano la sicurezza una priorità assoluta. I nostri abbonati usano standard e framework diversi per gestire le informazioni sensibili, quindi abbiamo implementato i seguenti benchmark ISO (International Organization for Standardization) nei nostri servizi per garantire la sicurezza e la conformità dei dati.

ISO 27001 

Gli standard ISO/IEC 27000 forniscono una serie di framework per aiutare le organizzazioni a confrontare il trattamento dei dati. Il più comune di questi standard, “ISO/IEC 27001”, fornisce i requisiti per un sistema di gestione della sicurezza delle informazioni (ISMS) e garantisce che i requisiti siano soddisfatti per le organizzazioni che completano con successo un audit.

ISO 27018 

La norma ISO/IEC 27018 fornisce linee guida basate sulla norma ISO/IEC 27002 ed è incentrata sulla protezione delle informazioni di identificazione personale (PII) per i fornitori di servizi cloud, come Zendesk.

ISO 27701 

La norma ISO/IEC 27701:2019 specifica i requisiti e le linee guida per stabilire, implementare, mantenere e migliorare continuamente un sistema di gestione delle informazioni sulla privacy (PIMS). Serve come complemento a ISO/IEC 27001 e ISO/IEC 27002 per la gestione della privacy all'interno di un'organizzazione. Ciò definisce un quadro per la gestione dei dati personali usati dai titolari del trattamento e dagli incaricati del trattamento dei dati, allineando i controlli di sicurezza e privacy.

Servizi e processi Zendesk nell’ambito di questi controlli

L’ambito delle certificazioni ISO/IEC 27001:2013, ISO/IEC 27018:2014 e ISO/IEC 27701:2019 è limitato dall’infrastruttura di rete globale di Zendesk, Inc. e dai prodotti e servizi corrispondenti, tra cui la gestione dello sviluppo, delle operazioni, manutenzione e consegna di Support, Guide, Chat, Connect, Inbox ed Explore, che sono gestiti centralmente dalla sede centrale di Zendesk e supportati dalle seguenti sedi: San Francisco, CA e Madison, WI (Stati Uniti d'America), Copenhagen (Danimarca), Dublino (Irlanda), Manilla (Filippine), Melbourne (Australia), Montpellier (Francia) e Singapore.

Inoltre, viene usato un provider di data center Infrastructure-as-a-Service (IaaS) per proteggere l’infrastruttura che esegue tutti i servizi offerti in IaaS Cloud. I controlli di sicurezza di Zendesk per la gestione dell’ambiente IaaS sono inclusi in scopo del presente certificato, ad eccezione dei controlli fisici e ambientali.

Il nostro sub-responsabile del trattamento per i servizi di hosting è attualmente AWS, che ha diverse certificazioni ISO. Per ulteriori informazioni, consulta la loro pagina di conformità qui.

Che cosa significa per i clienti

Internamente, eseguiamo questi controlli indipendenti per garantire che le nostre funzioni di gestione della sicurezza e privacy siano conformi ai principali standard del settore. Per i nostri clienti, questi standard di conformità convalidati esternamente confermano che stiamo rispettando i nostri obblighi nei tuoi confronti in termini di trattamento dei dati. Inoltre, la norma ISO/IEC 27701 richiede alle organizzazioni di dichiarare le leggi e i regolamenti applicabili come parte dei propri criteri di verifica, consentendo a questo standard di essere associato a requisiti come il Regolamento generale sulla protezione dei dati (GDPR), il California Consumer Privacy Act (CCPA) e altre leggi .

Tutti i clienti che usano prodotti inclusi nell’ambito ricevono questa protezione

Queste certificazioni riguardano i nostri servizi elencati sopra. Non devi pagare alcun extra o configurare la tua istanza in alcun modo per essere protetta da loro.

Certificazioni ISO 27001, ISO 27018 e ISO 27701 di Zendesk e certificazioni dei clienti

Le nostre certificazioni ISO 27001, ISO 27018 e ISO 27701 coprono i processi di gestione della sicurezza e della privacy in un ambito specifico dei servizi Zendesk. Se vuoi ottenere una di queste certificazioni mentre gestisci una parte del tuo servizio usando Zendesk, tieni presente che non riceverai automaticamente la certificazione per associazione. Tuttavia, le nostre certificazioni potrebbero aiutarti a ottenere queste certificazioni per la tua istanza.

Ottenimento delle certificazioni ISO di Zendesk

Puoi accedere gratuitamente ai nostri certificati ISO in qualsiasi momento, senza NDA, compilando il seguente modulo: https://www.zendesk.com/product/zendesk-security/#anchor-security-resources

 

 

Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.

Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.

Data ultima modifica: 08 mag 2024 · Craig Lima

3

Follower

1

Voto

0

Commenti


Craig Lima ha creato un articolo,

ArticoloPolicy Zendesk

Account abilitati HIPAA e HDS (collettivamente “Account abilitati per l’assistenza sanitaria”):

Tutti i termini in maiuscolo usati nel presente documento hanno il significato loro attribuito nell’Accordo di società in affari ("BAA") di Zendesk o nell’Allegato ai termini HDS dell’Accordo quadro di abbonamento Zendesk ("Allegato HDS"), a seconda del tipo di account (collettivamente, “Accordo sanitario”).

Ai fini degli account abilitati HIPAA , “PHI” significa “Informazioni sanitarie protette” e ai fini degli account abilitati HDS, “PHI” significa “Informazioni sanitarie personali”.

Zendesk e l’abbonato hanno stipulato un Accordo sanitario che raccomanda all’abbonato di valutare e implementare, a seconda del caso d’uso, le seguenti configurazioni o alternative valutate dall’abbonato per soddisfare altrimenti i requisiti di conformità ai sensi della legge applicabile, per qualsiasi account abilitato per il settore sanitario (s) prima di introdurre qualsiasi PHI nei Servizi.

Se l’Abbonato sceglie, a sua esclusiva discrezione, di rinunciare a implementare una qualsiasi delle configurazioni consigliate elencate di seguito, l’Abbonato si assume la responsabilità esclusiva per qualsiasi accesso non autorizzato o uso improprio della divulgazione dei Dati del servizio dell’Abbonato, incluse le PHI, risultante da qualsiasi tali deviazioni dalle configurazioni consigliate dall’abbonato.

L’abbonato deve aver acquistato piani di servizio del livello appropriato e disporre dei componenti aggiuntivi necessari (in caso di dubbi, consulta il tuo rappresentante commerciale).

Se l’abbonato ha un account abilitato per HDS, l’abbonato deve fare clic sul pulsante “Segui” nella policy dei sub-responsabili Zendesk per ricevere notifiche di eventuali modifiche ai sub-responsabili usati per fornire i Servizi.

Le seguenti Configurazioni di sicurezza minime per i servizi Zendesk devono essere implementate e sono indicate nel Contratto sanitario per qualsiasi account abilitato per il settore sanitario

I. Zendesk Support:

  1. Autenticazione Secure Agent tramite uno dei due metodi seguenti:
    1. Utilizzo di Zendesk Support nativo con impostazioni della password: (i) impostato su “Consigliato”; o (ii) personalizzati dall’Abbonato in modo da stabilire requisiti non meno sicuri di quelli stabiliti nell’impostazione “Consigliati”. Inoltre, in base all'opzione in questa sottosezione, l'Abbonato deve anche abilitare e applicare l'autenticazione a due fattori ("2FA") in modo nativo all'interno del Servizio; e i controlli amministrativi che consentono agli amministratori di impostare le password per gli utenti finali devono essere disabilitati; o
    2. Utilizzo di una soluzione Single Sign-On ("SSO") esterna con requisiti consolidati non meno sicuri di quelli stabiliti nell'impostazione della password "Consigliata" di Zendesk e abilitazione e applicazione dell'autenticazione a 2 fattori all'interno della soluzione selezionata per l'accesso di tutti gli agenti. I controlli amministrativi che consentono agli amministratori di impostare le password per gli utenti finali devono essere disabilitati.
    3. Tutte le opzioni di autenticazione che usano SSO come metodo di autenticazione devono disabilitare l’accesso con password.
  2. La crittografia Secure Socket Layer ("SSL") negli account abilitati per il settore sanitario deve rimanere sempre abilitata. Gli account abilitati per il settore sanitario che utilizzano un dominio diverso da zendesk.com devono stabilire e mantenere SSL in hosting.
  3. Ove possibile, l’accesso degli agenti dovrebbe essere limitato a specifici indirizzi IP sotto il controllo dell’abbonato a meno che l’Abbonato non abiliti l’autenticazione a più fattori per gli agenti come descritto sopra nei requisiti 1.a o 1.b (in modo nativo all’interno del Servizio o nell’ambiente dell’Abbonato in combinazione con Enterprise SSO).  A scanso di equivoci, “Accesso agente” indica l’accesso concesso a un agente umano che accede ai Dati del servizio tramite l’interfaccia utente (“UI”).
  4. Nella misura in cui l’account abilitato per il settore sanitario dell’abbonato consente le chiamate alle interfacce di programmazione delle applicazioni Zendesk ("API"), l’abbonato si assume tutta la responsabilità di comprendere le implicazioni sulla sicurezza di tutti gli abbonati o di entità di terzi autorizzate a creare, accedere, modificare o eliminare Dati di servizio e PHI tramite tale accesso e/o integrazioni. Per l’accesso a tale API, Zendesk offre vari metodi descritti qui e l’abbonato deve implementare le seguenti best practice di sicurezza in base al modello API usato:
    1. Approccio OAuth 2.0.  Questo modello fornisce le funzionalità di sicurezza più granulari, ma richiede che i diritti siano accettati da un utente finale.  Ove possibile, l’abbonato deve utilizzare l’approccio e lo schema di autenticazione OAuth 2.0. L’abbonato deve assegnare a ciascun client OAuth un nome client descrittivo e univoco e una funzione di designazione di un identificatore univoco. Le autorizzazioni concesse per ciascun token OAuth dovrebbero consentire il privilegio minimo necessario per svolgere le attività richieste.
    2. Approccio token API REST.  Questo modello è il più ampio e consente a un token API di utilizzare tutte le funzionalità del modello API. Per sua natura, fornisce l’accesso e le funzionalità più ampi e deve essere usato con cautela. Quando usa questo approccio, l’abbonato deve (i) usare un token univoco per ciascun servizio e assegnare al token una funzione descrittiva di designazione del nome; (ii) non condividere token API con terzi a meno che non sia ragionevolmente richiesto e in base a metodi di trasmissione crittografati end-to-end; (iii) riconosce che se il token API è condiviso con terzi e l’abbonato viene informato di una violazione dei dati di terzi, l’abbonato deve ruotare immediatamente il token associato; e (iv) come minimo, ruotare frequentemente il token in base alle politiche dell’organizzazione dell’abbonato.  
    3. Quando possibile, l’abbonato deve disabilitare l’accesso tramite password all’API, in quanto questo approccio invia le credenziali dell’utente con ogni richiesta che le espone ampiamente, rendendole più facilmente intercettabili da parte di malintenzionati.  
  5. L’abbonato deve abilitare “Richiedi autenticazione per il download” per richiedere l’autenticazione per accedere agli allegati. In caso contrario, chiunque abbia accesso all’URL corretto per tale allegato può accedere a qualsiasi allegato senza limitazioni. In tali casi, l’Abbonato si assume tutta la responsabilità del contenuto e dell’accesso a tali dati allegati.
  6. L’abbonato deve applicare sistematicamente, a tutti gli endpoint a cui accedono agenti, amministratori e proprietari, uno screensaver bloccato con password o una schermata di avvio impostata per un massimo di quindici (15) minuti di inattività del sistema.
  7. L’abbonato non deve modificare le autorizzazioni di visualizzazione che consentono a un utente di vedere gli aggiornamenti per un’intera istanza/brand/organizzazione o modificare l’impostazione predefinita che consente l’accesso al di fuori dei ticket o del gruppo dell’utente (a meno che l’abbonato non si assuma tutta la responsabilità di garantire che tali utenti siano approvati dall’abbonato a accedere a tutti i dati successivi). L’abbonato riconosce che le autorizzazioni dell’organizzazione degli utenti finali possono essere impostate nel profilo utente e nell’organizzazione stessa e, in caso di conflitto, l’impostazione più permissiva ha la precedenza su quella meno permissiva.
  8. L’abbonato riconosce che Zendesk non è responsabile della protezione delle trasmissioni email degli utenti finali e dei relativi Dati di servizio prima che vengano ricevuti nell’istanza Zendesk Support dell’abbonato. Sono incluse le PHI che possono essere inoltrate via email tramite risposte ai ticket Zendesk Support , inclusi, a titolo esemplificativo, commenti o allegati ai ticket.
  9. L’abbonato riconosce che Zendesk Support invia un’email a un utente finale in varie circostanze, ad esempio quando l’agente di un abbonato risponde a un ticket Zendesk Support tramite il canale email o quando viene avviato da un’automazione o da un trigger. Per impostazione predefinita, questa email contiene la corrispondenza dei ticket più recente o altre informazioni configurate per essere incluse in una notifica automatizzata, che potrebbe includere PHI. Per proteggere ulteriormente l’abbonato, la sua istanza Zendesk Support dovrebbe esserlo configurato per avvisare solo l’utente finale della risposta di un agentee richiedere all’utente finale di autenticarsi in Zendesk Support per vedere il contenuto del messaggio.
  10. L’Abbonato riconosce che qualsiasi funzionalità di SMS sfruttata a sua esclusiva discrezione in qualsiasi Servizio Zendesk è supportata da SMS e/o protocolli correlati, il che può comportare la trasmissione non crittografata di messaggi inviati o usciti dai Servizi.  Pertanto, la funzionalità degli SMS dovrebbe:
    1. non può essere usato in un account abilitato Healthcare*, oppure
    2. se utilizzato, l’Abbonato si assume tutta la responsabilità dell’uso di tale funzionalità
  11. L’Abbonato riconosce che l’uso della funzionalità legacy Sondaggi sulla soddisfazione dei clienti (" CSAT legacy") del Servizio invia via email i Dati del servizio (che possono contenere PHI) associati al ticket Support al fine di ottenere la valutazione dell’utente, il cui stato di crittografia non è controllato di Zendesk. Pertanto, la funzionalità CSAT legacy dovrebbe:
    1. non può essere usato in un account abilitato Healthcare*, oppure
    2. se utilizzato, l’Abbonato si assume tutta la responsabilità dell’uso di tale funzionalità
  12. L’Abbonato prende atto dell’uso della funzionalità Sondaggi sulla soddisfazione dei clienti ("CSAT") del Servizio per il canale di ticketing, se non configurato di conseguenza, invia via email i dati del servizio (che potrebbero contenere PHI) associati al ticket Support per ottenere la valutazione dell’utente, il cui stato di crittografia non è controllato da Zendesk. Inoltre, chiunque abbia l’URL CSAT specifico ha accesso alle risposte fornite per un ticket specifico. Pertanto, quando si usa la funzionalità CSAT per il canale di ticketing, l’abbonato dovrebbe
    1. Configura il corpo dell’email di automazione CSAT in modo da non includere potenziali PHI e usa il file {{satisfaction.survey_url}} esclusivamente segnaposto
    2. Non usare la funzionalità delle domande aperte

* A scanso di equivoci, le avvertenze sui dati relative alle PHI nella sezione 10 relativa agli SMS non si applicano all’uso dell’autenticazione 2FA all’interno del prodotto (come descritto nella sezione 1.a), in quanto tale funzionalità invia semplicemente una stringa numerica per la verifica dell’identità.

II. Zendesk Guide and Gather:

  1. L’Abbonato riconosce che i Servizi Guide e Gather sono pubblici per natura (se non sfruttano articoli soggetti a limitazioni o un’istanza chiusa o limitata) e pertanto l’Abbonato deve assicurarsi che gli articoli in Zendesk Guide o Gather Service non includano PHI, sia attraverso il testo di l’articolo o come allegato o immagine all’interno dell’articolo.
  2. L’abbonato deve disabilitare la possibilità per gli utenti finali di aggiungere commenti in Zendesk Guide oppure deve moderare e assumersi la responsabilità della rimozione delle PHI da tutti i commenti (come indicato nella sezione 3 di seguito).
  3. Laddove il servizio Zendesk Guide sia Guide Professional o Enterprise, gli abbonati devono, quando possibile, disabilitare la possibilità per gli utenti finali di creare nuovi post disattivando la funzionalità Gather con Zendesk Guide oppure quando le funzioni Gather non possono essere utilizzate a causa delle intenzioni dell’abbonato caso d’uso, gli abbonati devono abilitare la moderazione dei contenuti in Zendesk Guide Service e impostarla su “Modera tutti i contenuti”. Nessun invio contenente PHI deve essere approvato.
  4. L’uso di “Moderatori della community” non dipendenti dall’abbonato all’interno del servizio Gather non dovrebbe essere consentito, a meno che l’abbonato non si assuma la responsabilità del potenziale accesso di tali utenti ai dati, incluse eventuali PHI (ove applicabile).
  5. L’abbonato riconosce che le “@menzioni” dei membri della community Gather sono possibili quando consentono agli utenti finali di avere profili pubblici e se questa funzionalità è considerata un rischio nel loro caso d’uso, i profili pubblici dovrebbero essere disattivati o le @menzioni dovrebbero essere disabilitate.

III. Messaggistica Zendesk:

  1. L’abbonato non deve abilitare le integrazioni dei canali di messaggistica sui social media a meno che non si assuma la piena responsabilità di (i) garantire che non siano presenti PHI nei messaggi sui social media o (ii) concludere il proprio BAA con piattaforme di messaggistica integrate.
  2. L’abbonato deve disabilitare la possibilità per gli utenti finali di allegare file alle conversazioni di messaggistica e si assume la piena responsabilità di (i) abilitare gli allegati sicuri o (ii) garantire che gli agenti non alleghino file contenenti ePHI alle conversazioni di messaggistica. In caso contrario, chiunque abbia accesso all’URL corretto per tale allegato può accedere a qualsiasi allegato senza limitazioni.  In tali casi, l’Abbonato si assume tutta la responsabilità del contenuto e dell’accesso a tali URL e/o dati degli allegati.
  3. L’abbonato si assume la responsabilità di garantire che tutti gli agenti e gli agenti interni possano visualizzare tutti i messaggi in ingresso da tutti gli utenti finali.
  4. Se l’abbonato o i suoi agenti accedono o sviluppano integrazioni (ad es. come parte di un flusso creato per gli agenti AI ) per API e webhook o personalizzano l’esperienza di messaggistica, l’abbonato si assume la piena responsabilità di comprendere le implicazioni sulla privacy e sulla sicurezza di tutti i workflow personalizzati e per tutti Gli abbonati o le entità di terzi (inclusi i provider di chatbot) sono autorizzati a creare, accedere, modificare o eliminare i Dati di servizio e le ePHI tramite tale accesso e/o integrazioni.
  5. Se l’Abbonato desidera rimuovere l’autorizzazione di un agente a partecipare a una conversazione di messaggistica mentre la conversazione di messaggistica è attiva, l’Abbonato si assume tutta la responsabilità di forzare la cessazione dell’accesso di tale agente a Zendesk.
  6. Per impostazione predefinita, le conversazioni dei widget web con gli utenti finali sono persistenti e saranno visibili all’utente finale quando torna alla chat web dallo stesso dispositivo. L’abbonato può disabilitare questa funzione o assumersi la responsabilità di garantire che gli utenti finali non condividano i dispositivi.
  7. Se l’Abbonato desidera implementare l’autenticazione per gli Utenti finali, l’Abbonato si assume la responsabilità di implementarla in modo sicuro secondo le migliori pratiche e gli standard del settore.
    1. Quando usa questo approccio, l’abbonato deve (i) usare una chiave di firma JWT univoca per ciascun canale di autenticazione e assegnare al token una funzione di designazione del nome descrittivo; (ii) non condividere le chiavi di firma JWT con terzi a meno che non sia ragionevolmente necessario e in base a metodi di trasmissione crittografati end-to-end; (iii) riconosce che se la chiave di firma JWT è condivisa con terzi e l’abbonato viene informato di una violazione dei dati di terzi, l’abbonato deve ruotare immediatamente la chiave di firma JWT associata; e (iv) come minimo, ruotare frequentemente la chiave di firma JWT in conformità con le politiche dell’organizzazione dell’abbonato.
    2. L’abbonato deve usare l’attributo JWT di scadenza e impostarne il valore su non più di 15 minuti.
  8. L’abbonato riconosce che le interazioni tra gli utenti finali e gli agenti AI che non vengono trasferite a un agente umano e trasferite in un ticket sono ancora memorizzate nel sistema ed è responsabilità dell’abbonato eliminarle in conformità ai propri obblighi (ad es. webhook che avvisa l’abbonato quando tali conversazioni vengono memorizzate e ne attiva (automaticamente) l’eliminazione tramite l’API Sunshine Conversations ). 
  9. L’abbonato riconosce che le conversazioni tra gli utenti finali e gli agenti AI sono state trasformate al momento in un ticket non può essere rimosso. L’eliminazione è possibile eliminando il ticket. 
  10. L’abbonato riconosce che gli allegati degli utenti finali sui canali di messaggistica non sono attualmente sottoposti a scansione per rilevare eventuali malware in Zendesk. L’Abbonato si assume la piena responsabilità di mettere in atto procedure e politiche per ridurre il rischio per le risorse dell’Abbonato. 
  11. L’abbonato riconosce che l’uso della funzionalità “Conversazione laterale” può comportare la creazione o l’invio di messaggi “ticket secondari” e/o “conversazioni laterali” dall’istanza Support dell’abbonato ai destinatari tramite ticket, email, Slack o integrazioni (a discrezione dell’agente). . Se l’abbonato sceglie di usare questa funzionalità in un account abilitato per il settore sanitario, l’abbonato si assume la responsabilità di (i) garantire che non siano presenti PHI in tali messaggi o (ii) se le PHI potrebbero essere presenti nei messaggi, l’abbonato è l’unico responsabile per qualsiasi responsabilità, costo, danno o danno relativo all’acquisizione, all’accesso, all’uso o alla divulgazione non autorizzati di PHI derivanti dallo scambio di messaggi tramite la funzionalità “Conversazione laterale”.

IV. Zendesk Sunshine Conversations:

  1. L’abbonato non deve abilitare le integrazioni dei canali di terzi a meno che non si assuma la piena responsabilità di garantire che (i) non siano presenti PHI nei messaggi dei canali di terzi o (ii) conclude il proprio BAA con piattaforme di messaggistica integrate.
  2. L’abbonato si assume tutta la responsabilità di comprendere le implicazioni sulla sicurezza di tutti gli abbonati o di entità di terzi autorizzati a creare, accedere, modificare o eliminare i dati di servizio e le PHI tramite le interfacce di programmazione delle applicazioni Sunshine Conversations ("API"). Per l’accesso a tali API, l’abbonato deve implementare le seguenti best practice di sicurezza in base al modello API utilizzato:
    1. Approccio OAuth 2.0.  Questo modello fornisce le funzionalità di sicurezza più granulari, ma richiede che i diritti siano accettati da un utente finale.  Ove possibile, l’abbonato dovrebbe utilizzare l’approccio e lo schema di autenticazione OAuth 2.0. L’abbonato deve assegnare a ciascun client OAuth un nome client descrittivo e univoco e una funzione di designazione di un identificatore univoco. 
    2. Approccio token API REST.  Questo modello è il più ampio e consente a un token API di utilizzare tutte le funzionalità del modello API.  Per sua natura, fornisce l’accesso e le funzionalità più ampi e deve essere usato con cautela. Quando usa questo approccio, l’abbonato deve (i) usare un token univoco per ciascun servizio e assegnare al token una funzione descrittiva di designazione del nome; (ii) non condividere token API con terzi a meno che non sia ragionevolmente richiesto e in base a metodi di trasmissione crittografati end-to-end; (iii) riconosce che se il token API è condiviso con terzi e l’abbonato viene informato di una violazione dei dati di terzi, l’abbonato deve ruotare immediatamente il token associato; e (iv) ruotare frequentemente il token in conformità con la policy dell’organizzazione dell’abbonato.  
    3. Se l’abbonato o i suoi agenti accedono o sviluppano integrazioni per API e webhook o personalizzano l’esperienza Sunshine Conversations , l’abbonato si assume la piena responsabilità di comprendere le implicazioni sulla privacy e sulla sicurezza di tutti i workflow personalizzati e di tutti gli abbonati o entità di terzi (inclusi i provider di chatbot) consentiti per creare, accedere, modificare o eliminare Dati di servizio e PHI tramite tale accesso e/o integrazioni.
  3. L’abbonato riconosce che le limitazioni IP configurate per Zendesk Support non si estendono all’API Sunshine Conversations . Gli abbonati si assumono la piena responsabilità di limitare l’accesso all’API Sunshine Conversations e ai token API come descritto in 2.b. e in conformità con le politiche dell’abbonato. 
  4. L’abbonato deve disabilitare la possibilità per gli utenti finali di allegare file alle conversazioni Sunshine Conversations e si assume la piena responsabilità dell’abilitazione degli allegati sicuri o assicurando che gli agenti non alleghino file contenenti PHI alle conversazioni di messaggistica. In caso contrario, chiunque abbia accesso all’URL corretto per tale allegato può accedere a qualsiasi allegato senza limitazioni. In tali casi, l’Abbonato si assume tutta la responsabilità del contenuto e dell’accesso a tali dati allegati.
  5. Se l’abbonato desidera implementare l’autenticazione per gli utenti finali, si assume la responsabilità di implementarla in modo solido in base alle best practice di sicurezza e agli standard del settore.
    1. Quando usa questo approccio, l’abbonato deve (i) usare una chiave di firma JWT univoca per ciascun canale di autenticazione e assegnare al token una funzione di designazione del nome descrittivo; (ii) non condividere le chiavi di firma JWT con terzi a meno che non sia ragionevolmente necessario e in base a metodi di trasmissione crittografati end-to-end; (iii) riconosce che se la chiave di firma JWT è condivisa con terzi e l’abbonato viene informato di una violazione dei dati di terzi, l’abbonato deve ruotare immediatamente la chiave di firma JWT associata; e (iv) come minimo, ruotare frequentemente la chiave di firma JWT in conformità con le politiche dell’organizzazione dell’abbonato.
    2. L’abbonato deve usare l’attributo JWT di scadenza e impostarne il valore su non più di 15 minuti.
  6. L’abbonato riconosce che le interazioni tra gli utenti finali e gli agenti AI che non vengono trasferite a un agente umano e trasferite in un ticket sono ancora memorizzate nel sistema ed è responsabilità dell’abbonato eliminarle in conformità ai propri obblighi, ad esempio implementando un webhook che avvisa l’abbonato quando tali conversazioni vengono memorizzate e ne attiva (automaticamente) l’eliminazione tramite l’API Sunshine Conversations 
  7. L’abbonato riconosce che le conversazioni tra gli utenti finali e gli agenti AI che si sono trasformate in un ticket al momento non possono essere eliminate. L’eliminazione è possibile eliminando il ticket. 
  8. L’abbonato riconosce che i messaggi eliminati tramite l’API Sunshine Conversations vengono eliminati solo per gli utenti finali ma non nello Spazio di lavoro agente Zendesk. Ciò può essere ottenuto eliminando il ticket stesso o usando la funzionalità di rimozione (per le limitazioni, vedere 7.). 
  9. L’abbonato riconosce che tutti gli allegati sui canali Sunshine Conversation non sono attualmente sottoposti a scansione alla ricerca di malware in Zendesk. L’Abbonato si assume la piena responsabilità di mettere in atto procedure e politiche per ridurre il rischio per i dipendenti dell’Abbonato. 

V. Zendesk Chat:

  1. L’abbonato deve limitare l’accesso degli agenti a Zendesk Chat Service tramite l’associazione e l’autenticazione tramite Zendesk Support Service.
  2. L’abbonato non deve inviare trascrizioni di Chat via email (a) disabilitando il piping email, (b) disabilitando l’opzione di trascrizione email della chat nel Web Widget classico e (c) non condividendo le esportazioni via email dal dashboard di Chat
  3. L’abbonato si assume la piena responsabilità di garantire (i) che non siano presenti PHI in Chat e/o (ii) che tutti gli agenti siano autorizzati dall’abbonato a visualizzare tali dati.

VI. Servizio Zendesk Explore :

L’abbonato riconosce che le PHI possono essere visualizzate nel prodotto Explore tramite nomi utente, titoli dei ticket, scelte di campi e moduli e qualsiasi contenuto trovato nei campi di testo dei moduli gratuiti.

  1. Per qualsiasi istanza del servizio inclusa nell’ambito che contiene PHI, l’abbonato deve (i) concedere l’accesso all’interfaccia Explore solo agli agenti che possono accedere a tutti i ticket/chiamate/chat che possono contenere PHI nelle istanze del servizio principali e (ii) dovrebbe concedere tale accesso tenendo conto del minor numero di privilegi necessari per l'uso di Explore nel proprio ambiente. Per ulteriori informazioni sulla configurazione dei livelli di accesso in Explore, consulta qui.
  2. Laddove sfruttando la funzionalità di “esportazione”, (i) l’Abbonato riconosce che le PHI possono essere trasferite al dispositivo autorizzato dall’Abbonato ad accedere all’interfaccia dell’agente e che tutti i controlli relativi su tali dispositivi sono responsabilità dell’Abbonato e (ii) l’Abbonato deve negare l’uso della funzionalità di esportazione nativa via email per detti report esportati, a meno che non si assuma la responsabilità di (a) garantire che non contengano PHI in tali esportazioni, oppure (b) che i servizi email usati per tali trasferimenti possano supportare la crittografia tramite il protocollo di crittografia minimo consentito dagli attuali standard PCI.

* Considerazioni speciali sull’uso di Explore Enterprise:

L’abbonato riconosce che l’uso del servizio Explore Enterprise può comportare una maggiore condivisione dei dati e funzionalità di esportazione. L’abbonato deve:

  1. (i) assicurarsi che non esistano PHI in tali dashboard e/o (ii) condividere i dashboard solo con agenti, gruppi, elenchi o utenti finali autorizzati a visualizzare e ricevere tali dati.
  2. sfruttare le limitazioni IP
  3. in caso di condivisione di dashboard tramite URL (Uniform Resource Locator), l’abbonato riconosce che, anziché condividere con account utente individuali o di gruppo, i dati devono essere condivisi tramite un link di accesso. Pertanto, l’abbonato deve (i) abilitare la protezione con password, (ii) garantire che la complessità, la rotazione, l’archiviazione e la distribuzione delle password scelte alla parte ricevente siano conformi alle policy relative alle password dell’abbonato per la protezione dei dati contenuti in tali dashboard e (iii) sia ruotata senza indebito ritardo in caso di sospetto o conferma di esposizione

VII. Avviso sulle funzionalità interne al prodotto per i servizi associati distribuiti ("Componenti aggiuntivi"):

  1. Servizio associato distribuito in collaborazione: “Conversazioni laterali”. L’abbonato riconosce che l’uso della funzionalità “Conversazione laterale” può comportare la creazione o l’invio di messaggi “ticket secondari” e/o “conversazioni laterali” dall’istanza Support dell’abbonato ai destinatari tramite ticket, email, Slack o integrazioni (a discrezione dell’agente). . Se l’abbonato sceglie di usare questa funzionalità in un account abilitato per il settore sanitario, l’abbonato si assume la responsabilità di (i) garantire che non siano presenti PHI in tali messaggi o (ii) se le PHI potrebbero essere presenti nei messaggi, l’abbonato è l’unico responsabile per qualsiasi responsabilità, costo, danno o danno relativo all’acquisizione, all’accesso, all’uso o alla divulgazione non autorizzati di PHI derivanti dallo scambio di messaggi tramite la funzionalità “Conversazione laterale”.

VIII. Applicazioni mobili Zendesk (o accesso tramite dispositivi mobili come smartphone o tablet):

  1. L’uso include la crittografia a livello di dispositivo
  2. È necessario sfruttare l’accesso biometrico o PIN impostato sul dispositivo più alto consentito
  3. Le notifiche che consentono di visualizzare i commenti dei ticket nelle schermate di blocco di tali dispositivi devono essere disabilitate
  4. I blocchi di inattività dello schermo devono essere abilitati e configurati in modo da bloccare a non più di 15 minuti di inattività.
  5. L’abbonato riconosce che la funzionalitàdi rimozione non è disponibile nell’applicazione per dispositivi mobili Support e che gli agenti devono accedere tramite browser se desiderano usare la funzionalità di rimozione.
  6. Se l’abbonato sceglie di autenticare gli utenti finali per la messaggistica Zendesk, l’abbonato riconosce che lo stato di autenticazione di un utente finale non viene visualizzato nell’applicazione Support Mobile.

IX. Zendesk Insights: l’assistenza per questo servizio è stata ritirata a partire dal 5 febbraio 2021.   

X. Avviso sulle funzionalità AI di Zendesk (“ AI Zendesk”, “Intelligenza artificiale avanzata”, “Intelligenza artificiale generativa”, e altri):

  1. L’abbonato riconosce che le funzioni AI di Zendesk hanno lo scopo di aumentare la produttività dei Servizi Zendesk e non devono essere usate in un modo che potrebbe essere interpretato come (i) fornire consulenza medica o sanitaria, (ii) fornire una diagnosi di una condizione o sintomi, (iii) prescrivere un trattamento o (iv) impedire in qualsiasi modo a un Utente di chiedere consiglio, diagnosi o trattamento a un operatore sanitario, (v) o fornire in altro modo a un Utente informazioni o prendere decisioni in merito a tali sintomi. qualsiasi piano sanitario, programma di trattamento, servizio di test o qualsiasi altro servizio sanitario che potrebbe influire sulla ricerca o sulla ricezione di servizi sanitari (a meno che l’Abbonato non si assuma la piena responsabilità di questa decisione in base al suo caso d’uso unico e alle interazioni con i propri Utenti, nonché come le potenziali implicazioni dell’uso AI in questo modo).
  2. L’abbonato riconosce che, se si usa una qualsiasi funzione AI generativa, gli output AI generati sono generati dal computer e non dall’uomo e potrebbero produrre output imprecisi. Zendesk non garantisce l'accuratezza di questi output.
  3. L’abbonato prende atto che se un messaggio di saluto bot conversazionale degli agenti AI viene usato per fornire un messaggio di limitazione di responsabilità agli utenti finali dell’abbonato, la funzionalità “Genera varianti” non sarà attivata per garantire l’integrità del contenuto del messaggio. 
  4. L’abbonato riconosce che l’attivazione della funzionalità di scrittura avanzata nel Centro amministrativo abiliterà questa funzionalità per tutti gli agenti nella sua istanza, indipendentemente dai ruoli e dalle autorizzazioni. 

XI. Zendesk QA

  1. L’abbonato riconosce che le funzioni AI Zendesk QA hanno lo scopo di aumentare la produttività dei Servizi Zendesk e non devono essere usate in un modo che potrebbe essere interpretato come (i) fornire consulenza medica o sanitaria, (ii) fornire una diagnosi della condizione o sintomi, (iii) prescrivere un trattamento, o (iv) impedire in qualsiasi modo a un Utente di chiedere consiglio, diagnosi o trattamento a un operatore sanitario, (v) o fornire in altro modo a un Utente informazioni o prendere decisioni in merito a tale scopo o meno di qualsiasi piano sanitario, programma di trattamento, servizio di test o qualsiasi altro servizio sanitario che potrebbe influire sulla ricerca o sulla ricezione di servizi sanitari (a meno che l’Abbonato non si assuma la piena responsabilità di questa decisione in base al suo caso d’uso unico e alle interazioni con i propri Utenti, in quanto nonché le potenziali implicazioni dell’uso AI in questo modo).
  2. L’abbonato riconosce che l’eliminazione o la rimozione nella propria istanza Zendesk non viene sincronizzata immediatamente con il Zendesk QA , ma verrà trasferita nelle 3-6 ore successive.
  3. Quando si usa la funzionalità Sondaggi, l’abbonato deve (i) disabilitare la funzionalità di assistenza AI Zendesk QA (o garantire che tutti gli agenti che svolgono attività QA siano autorizzati a vedere eventuali dati all’interno di tale transazione, oltre a garantire che i principi di cui al punto 1 siano in vigore) ( ii) assicurarsi di configurare il sondaggio in modo da non rivelare le PHI nelle domande o nelle descrizioni del sondaggio (o assumersi la responsabilità di tali dati nelle email inviate tramite StartTLS opportunistico)
  4. Quando si usa l'integrazione personalizzata "Zendesk Chat", l'abbonato dovrebbe considerare di impostare un periodo di conservazione dei dati in linea con le politiche dell'abbonato per assicurarsi che i dati non vengano conservati per un tempo illimitato.
  5. L’abbonato riconosce che quando si usa l’API Sunshine Conversations per eliminare parti di una conversazione di messaggistica Zendesk, questa modifica non si riflette nel Zendesk QA. Invece, le informazioni dovrebbero essere rimosse dal ticket originale tramite rimozione o l’intera conversazione dovrebbe essere rimossa.
  6. L’abbonato riconosce che al momento il Zendesk QA non supporta la funzione “Allegati privati” di Zendesk. Ciò significa che chiunque abbia accesso all’URL corretto per tale allegato può accedere agli allegati e non deve essere usato con dati sensibili, incluse le PHI. L’abbonato si assume tutta la responsabilità del contenuto e dell’accesso a tali URL e/o dati degli allegati.
  7. L’abbonato riconosce che, in base alle disposizioni iniziali del Zendesk QA, la configurazione della connessione avanzata è possibile solo dopo la prima sincronizzazione.

XII. Gestione del personale (WFM) Zendesk "WFM":

  1. L’abbonato lo riconosce
    1. Il ruolo di amministratore WFM predefinito ha accesso a tutte le attività e alle impostazioni degli agenti applicabili al servizio WFM (inclusi i tag menzionati al punto 2 di seguito).
    2. Il ruolo agente predefinito ha accesso alle attività dell’agente, a meno che non sia configurato dagli amministratori per avere un accesso diverso tramite la creazione di ruoli personalizzati , come descritto qui
  2. L’abbonato riconosce che i tag applicati da agenti, amministratori o la logica di sistema predefinita nei ticket in Support saranno visibili all’interno del prodotto WFM a qualsiasi utente autorizzato a vedere tale attività nei ticket. Se i tag sono ritenuti sensibili dall’abbonato, l’accesso deve essere configurato in modo appropriato.

Dichiarazione di non responsabilità: A causa di modifiche legislative o regolamentari o di modifiche al Servizio Zendesk, le configurazioni di sicurezza in questo documento potrebbero cambiare di volta in volta. Questo documento contiene le raccomandazioni di Zendesk per le configurazioni di sicurezza minime efficaci per la protezione delle PHI nei prodotti Zendesk descritte sopra. Questo documento non costituisce un modello esaustivo per tutti i controlli su tali dati né costituisce una consulenza legale. Ogni abbonato Zendesk deve rivolgersi al proprio consulente legale in merito ai requisiti di conformità HIPAA o HDS e apportare ulteriori modifiche alle proprie configurazioni di sicurezza in base all’analisi indipendente di ciascun abbonato, a condizione che tali modifiche non contrastino o riducano la sicurezza di le configurazioni descritte in questo documento.

 


Registro modifiche:

24 gennaio 2025

  • Configurazioni HIPAA e HDS consolidate

27 dicembre 2024

  • Aggiunta la sezione XII per incorporare Gestione del personale (WFM) Zendesk ("WFM") nell'ambito

16 dicembre 2024

  • Aggiunta la sezione XI per incorporare il Zendesk QA nell’ambito
  • Diverse istanze di "Answer Bot" sono state modificate in " Agenti AI " per indicare le modifiche alle convenzioni di denominazione e un ambito più ampio.

10 ottobre 2024

  • Aggiunta la sezione I, Support, numero 12 (CSAT) e modificata la sezione I, Support, numero 11 ( CSAT legacy ) per adattarsi alle nuove funzionalità. 

7 marzo 2024

  • Aggiunta la sezione X, Avviso sulle funzionalità AI di Zendesk
  • Sezione I, Support, numero 7 (autorizzazioni di visualizzazione):
    • È stato chiarito che le "autorizzazioni di visualizzazione" riguardano un'intera "istanza/brand/organizzazione" anziché solo "organizzazione".
    • Aggiunta una nuova disposizione per il comportamento dell’organizzazione specifico degli utenti finali. 
  • Sezione I, Support, numero 9 (email):  
    • Sono state ampliate le circostanze in cui Zendesk Support invia un’email a un utente finale per includere le risposte tramite il canale email o quelle avviate da un’automazione o da un trigger, anziché solo un agente che risponde a un ticket.
    • Ha specificato che, per impostazione predefinita, le notifiche automatizzate possono contenere la corrispondenza dei ticket più recente o altre informazioni configurate, che potrebbero includere le PHI.

25 ottobre 2023

  • Introduzione: Chiarito il linguaggio di introduzione per gli account abilitati HIPAA
  • Sezione II, Guide and Gather, numero 1 (Restrizioni del centro assistenza): ha sostituito le limitazioni della PI con articoli riservati per chiarimenti

13 aprile 2023

  • Sezione I, Support, numero 4 (API): 
    • Aggiunto link ai metodi di autenticazione per maggiore chiarezza 
    • b) Rimossi i consigli sull’intervallo di tempo esatto per la rotazione per allinearli alle best practice del settore e rimossi i riferimenti ai Termini di servizio dell’API REST (ridondanza)
    • aggiunto c) per avvertire dell’uso dell’autenticazione di base per l’API 
  • Sezione II, Guida:
    • Numero 1 (Limitazioni per i centri assistenza): aggiunto riferimento ai centri assistenza chiusi o con limitazioni per allinearlo alle funzionalità del prodotto
    • Numero 5 (@menzioni): Aggiunta opzione per disabilitare le @menzioni per allinearle al prodotto funzionalità 
  • Sezione III, Messaggistica: 
    • Numero 1 e 2 (canali di terzi e allegati privati): aggiunti gli identificatoridi sezione (i) e (ii) per maggiore chiarezza
    • Numero 2 (allegati privati): aggiunto “URL e/o” per chiarimenti
    • Numero 7-10 (Autenticazione utente finale, eliminazione conversazioni Answerbot, rimozione, scansione malware): sezioni complete aggiunte per trasparenza
  • Sezione IV, Sunshine Conversations : l’intera sezione è stata aggiunta a causa dell’inclusione nel BAA di Sunshine Conversations in Zendesk Suite 
  • Sezione V, Chat, numero 3 (Spazio di lavoro agente): piccole correzioni di fraseggio
  • Sezione VIII, applicazioni mobili, numero 5-7 (scansione malware, rimozione malware, autenticazione degli utenti finali): intere sezioni aggiunte per trasparenza

24 febbraio 2023

  • Sezione I. Support, numero 3: è stata rimossa la distinzione separata tra le limitazioni IP Support e Chat in quanto l’interfaccia utente è ora unificata.
  • Sezione I. Support, numero 5: chiarimenti aggiunti sul mancato rispetto del requisito 
  • Sezione I. Support, numero 7: “L’abbonato non deve” è cambiato in “L’abbonato non deve”.
  • Sezione IV. Chat, numero 2: chiarisce che tutte le funzionalità di esportazione dei dati da Chat tramite email sono vietate e non riguardano solo trascrizioni e piping. 
  • Sezione III. messaggistica: aggiunta dell’intera sezione all’account della funzionalità di messaggistica Zendesk che si aggiunge all’ambito del Contratto di società in affari di Zendesk.

9 luglio 2021

  • Aggiunge il punto 3. nella sezione Chat per le responsabilità relative all’utilizzo Spazio di lavoro agente .

21 gennaio 2021

  • L’aggiunta del numero 1.11 non consente CSAT a meno che l’abbonato non si assuma la responsabilità dei dati inviati via email nell’ambito del sondaggio. 
  • Avvertenza nel numero 1.7 per consentire agli abbonati di alterare le autorizzazioni di visualizzazione a causa del fatto che gli utenti hanno già l’autorizzazione ad accedere a tali dati.
  • Intero documento aggiornato in modo che corrisponda allo stileaziendale dei link incorporati nel testo anziché agli URL incorporati (nessun impatto sul contenuto della configurazione).

Agosto 2020

  • Aggiunta di Explore Enterprise che copre maggiori capacità di condivisione dei dashboard
  • Rimozione del divieto di allegati Chat (ora sono coperti i requisiti di autenticazione Support )
  • Disambigua: il divieto di ePHI nei campi personalizzati si applicava specificamente all’uso di Insights e non a livello globale
  • Aggiunta di una nuova sezione relativa ai componenti aggiuntivi ai servizi distribuiti, con la prima aggiunta di "Conversazioni laterali"
  • Varie modifiche alla grammatica e alla formattazione (senza conseguenze per il contenuto)

13 luglio 2020:

  • Disambiguazione dell’uso degli SMS tramite il Servizio rispetto all’uso nativo degli SMS per l’autenticazione 2FA all’interno del prodotto. * A scanso di equivoci, le avvertenze sui dati relative a ePHI nella sezione 10 relativa agli SMS non si applicano all’uso dell’autenticazione 2FA all’interno del prodotto (come descritto nella sezione 1.a), in quanto tale funzionalità invia semplicemente una stringa numerica per la verifica dell’identità.

13 dicembre 2019 

  • consente di eliminare le limitazioni IP degli agenti laddove il caso d'uso non consente tali limitazioni, a condizione che venga applicata l'autenticazione a più fattori dell'accesso degli agenti.

17 dicembre 2019 

  • consente di inserire i commenti degli utenti finali in Guide, a condizione che gli agenti moderano tali commenti e rimuovano tutte le PHI.

6 novembre 2019

  • Articolo aggiornato per riflettere la modifica che gli abbonati possono scegliere a loro esclusiva discrezione di rinunciare o sostituire qualsiasi configurazione particolare purché si assumano la responsabilità di tale decisione.

"La mancata implementazione e osservanza da parte dell'abbonato di una particolare configurazione elencata di seguito o di qualsiasi serie di configurazioni richieste elencate di seguito, sarà

a proprio rischio e a esclusiva discrezione dell’Abbonato; e tale inadempimento esonera Zendesk e i suoi dipendenti, agenti e affiliati da qualsiasi responsabilità in relazione a qualsiasi accesso non autorizzato o uso o divulgazione impropri dei Dati di servizio dell’abbonato, incluse le informazioni sanitarie protette elettroniche, risultante da tale errore da parte dell’abbonato . "

  • Altre modifiche includono
    • 1. la possibilità di usare gli SMS a condizione che l’abbonato si assuma la responsabilità di garantire che non siano presenti PHI in tali trasmissioni.
    • 2. La possibilità di usare gli allegati in Chat a condizione che l’abbonato si assuma la responsabilità di garantire che non siano presenti PHI in tali allegati.

6 marzo 2019 

  • aggiornato per includere le impostazioni per Zendesk Explore

17 gennaio 2019

  •  aggiornato per non consentire gli allegati in Chat.

Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.

Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.

Data ultima modifica: 28 gen 2025 · Craig Lima

0

Follower

1

Voto

0

Commenti


Craig Lima ha commentato,

CommentoZendesk policies and agreements

July 9th 2021 edit:

1. Adds point 3. under Chat section for responsibilities around Agent Workspace usage.

Visualizza commento · Data ultimo post: 09 lug 2021 · Craig Lima

0

Follower

0

Voti

0

Commenti


Craig Lima ha commentato,

CommentoZendesk policies and agreements

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). 

Visualizza commento · Data ultimo post: 21 gen 2021 · Craig Lima

0

Follower

0

Voti

0

Commenti