Vor Kurzem aufgerufene Suchen
Keine vor kurzem aufgerufene Suchen

Craig Lima
Beigetreten 14. Apr. 2021
·
Letzte Aktivität 02. Jan. 2025
Folge ich
0
Follower
0
Gesamtaktivitäten
11
Stimmen
0
Abonnements
3
AKTIVITÄTSÜBERSICHT
BADGES
BEITRÄGE
POSTS
COMMUNITY-KOMMENTARE
BEITRAGSKOMMENTARE
AKTIVITÄTSÜBERSICHT
Neueste Aktivität von Craig Lima
Craig Lima hat einen Kommentar hinterlassen
Dec 27th, 2024, added section XII to incorporate Workforce Management “WFM” into HIPAA BAA scope
Kommentar anzeigen · Gepostet 02. Jan. 2025 · Craig Lima
0
Follower
0
Stimmen
0
Kommentare
Craig Lima hat einen Kommentar hinterlassen
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
Kommentar anzeigen · Gepostet 17. Dez. 2024 · Craig Lima
0
Follower
0
Stimmen
0
Kommentare
Craig Lima hat einen Beitrag erstellt
AWS-Regionen, in denen Zendesk Servicedaten der Abonnenten hostet
Derzeit hosten wir Servicedaten der Abonnenten in den folgenden AWS-Regionen:
- USA Ost (Nord-Virginia)
- USA Ost (Ohio)
- USA West (Oregon)
- EWR (Irland)
- EWR (Frankfurt)
- UK (London)
- Asien-Pazifikraum (Tokio)
- Asien-Pazifik (Osaka)
- Asien-Pazifikraum (Sydney)
Vereinbarungen zur Datenspeicherung
Zendesk sagt einen bestimmten Hosting-Standorte nur für Servicedaten von Abonnenten zu, die die Zusatzleistung Standort des Rechenzentrums in Anspruch genommen haben (sei es durch den Erwerb des Add-ons „Standort des Rechenzentrums“ oder eines Serviceplans, der das Add-on „Standort des Rechenzentrums“ beinhaltet). Die Ausnahmen von dieser Verpflichtung sind in der Richtlinie für das regionale Daten-Hosting aufgeführt.
Wir behalten uns vor, Kontodaten ohne vorherige Ankündigung an andere Speicherorte zu verlagern, um Lasten zu verteilen, die Leistung zu verbessern und unseren Service zu optimieren. Wenn für ein Konto das Add-on „Standort des Rechenzentrums“ erworben wurde, stellen wir dabei sicher, dass sich auch der neue Datenspeicherort in dem vom Abonnenten gewählten Land oder Rechtsraum befindet.
Abrufen der physischen Adresse, unter der Ihre Servicedaten gehostet werden
Auf Anfrage können wir Ihnen die AWS-Region mitteilen, in der wir Ihre Servicedaten hosten. Der von Amazon Web Services verwendete Begriff „Region“ bezeichnet ein Land, eine geografische Region innerhalb eines Landes, einen Staat und/oder eine Stadt.
Aufgrund der technischen Funktionsweise von AWS sind wir nicht in der Lage, die genaue physische Adresse anzugeben, unter der Ihre Servicedaten gehostet werden. Der Grund hierfür liegt in der Architektur von AWS selbst. AWS unterhält „Regionen“ auf der ganzen Welt. Diese Regionen sind in so genannte „Availability Zones“ oder „AZs“ gegliedert. Ein in AWS erstelltes Asset befindet sich in einer oder mehreren AZs einer bestimmten Region. Daten können vom Inhaber des Assets in derselben oder in einer anderen sowie von AWS selbst in einer anderen AZ derselben Region repliziert werden. Dies hat zur Folge, dass die Servicedaten der Zendesk-Abonnenten in mehreren Einrichtungen einer bestimmten Region gespeichert sein können. Darüber hinaus macht AWS aus Sicherheitsgründen keine offiziellen Angaben zum genauen Standort der Gebäude, in denen sich die Rechenzentren oder ihre zugehörigen Einrichtungen befinden.
Wenn Sie wissen möchten, in welcher AWS-Region Ihre Zendesk-Subdomäne gehostet wird, wenden Sie sich an den Zendesk-Kundensupport.
ÄNDERUNGSPROTOKOLL:
April 2024 – Hinzufügen einer Warnung für Zendesk WFM (Tymeshift) und Zendesk QA (Klaus)
Juli 2024 – Hinzufügen einer Warnung für Ultimate
Juli 2024 – Hinzufügen von zwei neuen Hosting-Standorten: UK (London), Asien-Pazifik (Osaka)
Bearbeitet 26. Juli 2024 · Craig Lima
5
Follower
1
Stimme
0
Kommentare
Craig Lima hat einen Beitrag erstellt
Das Zendesk-Modell der geteilten Verantwortung
Zendesk stellt eine hochgradig konfigurierbare und schnell skalierbare Kundenserviceplattform für viele der weltweit führenden Unternehmen in den verschiedensten Branchen bereit. Durch Nutzung unserer Cloud-Plattform für ihren Kundenservice können die Abonnenten ihren Verwaltungsaufwand verringern, ihren Dienst je nach Bedarf skalieren und mit herrlich einfachen Interaktionen ansprechende Kundenerlebnisse bieten.
Auf der anderen Seite kann der Umzug in die Cloud aber auch zu Unklarheiten über die Zuständigkeiten für die verschiedenen Aspekte der Sicherheit und des Datenschutzes führen. Doch keine Sorge, diese sind in unserem Modell der geteilten Verantwortung ganz klar und einfach geregelt. Es beschreibt, welche Partei für welche Kontrollen in Bezug auf die Sicherheit und Vertraulichkeit Ihrer Daten verantwortlich ist Ganz gleich, ob Sie als gewissenhafter Administrator, als Sicherheits-, Compliance- oder Datenschutzbeauftragter oder in einer anderen Funktion angemessene Kontrollen für die Nutzung der Zendesk-Dienste in Ihrer Umgebung einrichten müssen, in diesem Standard finden Sie genaue Vorgaben dazu.
Um es in einem Satz zusammenzufassen: „Zendesk ist für die Sicherheit des Dienstes selbst zuständig, während Sie für die Sicherheit innerhalb Ihrer eigenen Instanzen des Dienstes verantwortlich sind.“
- Zugangskontrollen und Hygiene
- Integrationen
- Überlegungen zu Daten, Datenschutz, Compliance und gesetzlichen Bestimmungen
- Überwachung
- Wartung
- Sicherheitsvorfälle (Rollen und Verantwortlichkeiten)
- Hilfreiche Links
- Änderungsprotokoll
Beachten Sie, dass Begriffe, die in dieser Richtlinie verwendet, aber nicht definiert werden, die im Zendesk-Hauptdienstleistungsvertrag festgelegte Bedeutung haben.
I Zugangskontrollen und Hygiene
Die Kontrolle des Zugangs zu sensiblen Systemen und den in ihnen enthaltenen Daten ist ein zentraler Aspekt der Sicherheitsgrundsätze.
-
Der Abonnent ist verantwortlich für die Kontrolle des Zugriffs auf seine Instanzen des Dienstes. Hierzu gehören das:
- Bereitstellen, Ändern und Entfernen aller Endbenutzer und Agenten (Mitarbeiter vor Ort, Remote-Mitarbeiter oder externe Beschäftigte) mit fortlaufender Hygiene und Berechtigungsverwaltung
- Auswählen der Authentifizierungsmethode für den Dienst aus unterstützten Angeboten (Kennwörter, MFA, SSO usw.) und Konfigurieren dieser Methode
- Konfigurieren und Überwachen von Aspekten der Sitzungsverarbeitung wie Abmeldungen, angemeldete Geräte usw.
- Erlauben oder Verweigern des Zugriffs unserer Supportmitarbeiter auf Ihre Support-Instanz
- Konfigurieren und sicheres Implementieren des Zugriffs auf die REST API-Services von Zendesk (falls zutreffend, einschließlich Integrationen, Nutzung des Zendesk Sunshine Service usw.)
- Konfigurieren aller vom Produkt unterstützten IP-Beschränkungen (falls gewünscht)
- Planen und Einrichten anderer, nicht produktbezogener Zugangskontrollen (z. B. Festlegen der für den Zugriff der Agenten auf Ihre Instanzen zulässigen Gerätetypen) sowie aller physischen, logischen oder richtlinienbasierten Kontrollen in Bezug auf Benutzer oder zugelassene Geräte
-
Zendesk ist verantwortlich für die Kontrolle des Zugriffs auf die dem Dienst zugrunde liegenden Systemen. Hierzu gehören das:
- Verwalten der Richtlinien und Verfahren für die sichere Bereitstellung, Änderung, fortlaufende Hygiene, Berechtigungsverwaltung und Entfernung aller Benutzer (Mitarbeiter vor Ort, Remote-Mitarbeiter und externe Beschäftigte)
- Umsetzen der rollenbasierten Zugangskontrolle (Role Based Access Control – RBAC), des Prinzips der geringsten Berechtigungen (Principle of Least Privilege – PLP) und eines angemessenen Schutzes der Anmeldedaten etwa durch Multi-Faktor-Authentifizierung (MFA) für den Zugriff aller Beschäftigten und externen Mitarbeiter auf kritische Systeme und Anwendungen, die Servicedaten der Abonnenten enthalten
- Regelmäßiges Überprüfen der oben genannten Sicherheitsfunktionen
II. Integrationen
Dienste von Drittanbietern können die Effizienz erheblich steigern, sind aber auch mit besonderen Sicherheitsanforderungen verbunden.
-
Der Abonnent ist verantwortlich für die Beurteilung der Sicherheitsanforderungen im Hinblick auf alle seine Integrationen von Drittanbieterdiensten in den Dienst. Hierzu gehören:
- Integrationen per API und/oder SDK
- Integrationen durch Installieren von Marketplace Apps oder Aktivieren von Drittanbieterkanälen
- Integrationen mit Drittanbietern, die den Abonnenten in Form von Mitarbeitern, Werkzeugen, Code oder direkter Wartung seiner Zendesk-Instanzen unterstützen
-
Zendesk ist verantwortlich für die umsichtige Integration seriöser Drittanbieter in den Dienst. Hierzu gehören die:
- Auswahl und sorgfältige laufende Überprüfung aller Unterauftragsverarbeiter
- Sichere Integration von Akquisitionen in den Dienst
- Einhaltung der Sicherheitsanforderungen aller Produktpartnerschaften und/oder Integrationen von Drittanbietern in den Dienst
III. Überlegungen zu Daten, Datenschutz, Compliance und gesetzlichen Bestimmungen
Der sorgfältige Umgang mit den verwendeten Daten, die Einhaltung aller einschlägigen Vorschriften und entsprechende Zusicherungen von Drittanbietern sind entscheidend.
-
Der Abonnent ist verantwortlich für die ordnungsgemäße Behandlung der erfassten und genutzten Daten. Hierzu gehören das:
- Analysieren der für den jeweiligen Anwendungsfall relevanten Datentypen
- Verarbeiten der Daten gemäß den Datenklassifizierungs- und Datenschutzrichtlinien des eigenen Unternehmens, den für die Daten selbst, die Benutzer, die sie bereitstellen, und die Branche des Abonnenten geltenden Rechtsvorschriften und den Gesetzen des jeweiligen Landes
- Auswählen der für seine Instanz des Dienstes zulässigen Kommunikationskanäle
- Verwalten der Instanzen und Servicedaten gemäß den für die Branche, die Benutzer oder den Anwendungsfall des Abonnenten geltenden Vorschriften, Gesetzen und Bestimmungen
- Bereitstellen alternativer TLS-Zertifikate für die Verschlüsselung des Datenverkehrs mit Zendesk-Benutzeroberflächen oder -APIs, wenn Host-Mapping zu einer nicht zu Zendesk gehörenden übergeordneten Domäne gewünscht wird
- Untersuchen, wo Daten möglicherweise nicht verschlüsselt übertragen werden, und die entsprechende Behandlung der betreffenden Kanäle oder Protokolle (vor allem E-Mail, SMS oder vom Abonnenten nach eigenem Ermessen eingerichtete Drittanbieter-Integrationen, die keine Verschlüsselung unterstützen)
- Sicherstellen, dass die in der Instanz des Abonnenten verwendeten Datentypen nicht gegen die Bestimmungen des Zendesk-Hauptdienstleistungsvertrags verstoßen (siehe Zendesk-Hauptdienstleistungsvertrag)
- Sicherstellen, dass die vom Abonnenten gewählte Verfügbarkeit und Disaster Recovery mit den für ihn geltenden Richtlinien und Vorschriften übereinstimmen
-
Zendesk ist verantwortlich für das:
- Ordnungsgemäße Schützen aller Servicedaten vor Offenlegung auf Dienstebene (d. h. Infrastruktur oder Code)
- Verschlüsseln der Daten bei der Übertragung zu oder von unseren Benutzeroberflächen oder APIs über öffentliche Netze
- Verschlüsseln aller Servicedaten bei der Speicherung
- Bereitstellen von Information für Abonnenten über die von produktinternen Cookies und bei der standardmäßigen Nutzen der Dienste gesammelten Daten
- Präzise Beschreiben der Nutzung von personenbezogenen Daten und anderen Servicedaten in anonymisierter und nicht-anonymisierter Form für die Bereitstellung unserer Dienste und andere Zwecke
- Bereitstellen von Werkzeugen und Funktionen, die die Abonnenten bei der Einhaltung ihrer eigenen Verpflichtungen hinsichtlich des ordnungsgemäßen Umgangs mit personenbezogenen oder regulierten Daten unterstützen
- Einhalten der für unsere Dienstangebote und Geschäftsstandorte geltenden Gesetze und Vorschriften
- Einholen und Bereitstellen von Compliance-Zusicherungen der für unsere Dienstangebote relevanten Drittanbieter
IV. Überwachung
Eine angemessene Sicherheit erfordert Einblick in Prozesse und Aktivitäten.
-
Der Abonnent ist verantwortlich für die Überwachung aller Aktivitäten innerhalb seiner Instanzen des Dienstes. Hierzu gehören das:
- Überwachen der Benutzeraktivitäten (anhand von UI-Ansichten oder API-Protokollen)
- Umsetzen angemessener Sicherheitsmaßnahmen bei der Kommunikation mit unbekannten Personen oder beim Umgang mit nicht vertrauenswürdigen Inhalten im Zusammenhang mit dem Dienst
- Protokollieren und Verwalten aus dem Dienst entnommener Daten gemäß den geltenden Vorschriften
-
Zendesk ist verantwortlich für die Überwachung der Prozesse und Aktivitäten des Dienstes selbst. Hierzu gehören:
- Privilegierter Zugang und Aktivitäten innerhalb des Produktionsnetzwerks
- Eingehender Datenverkehr zur Meldung oder Blockierung als schädlich bekannter Übertragungen oder IP-Adressen
- Dienstverfügbarkeit
- Anomales Verhalten innerhalb des Unternehmens- oder Produktionsnetzwerks
- Sicherheit von Code, Infrastruktur, Datenverkehr und relevanten Beschäftigten oder externen Mitarbeitern
V. Wartung
Durch lückenloses Aktualisieren und Patchen von Systemen und Code lassen sich viele Sicherheitsprobleme vermeiden.
-
Der Abonnent ist verantwortlich für die Wartung und das Patchen aller Systeme oder Codes außerhalb der Zendesk-Architektur und/oder des vertraglich vereinbarten Umfangs*. Hierzu gehören:
- Seine eigene Infrastruktur, einschließlich seiner eigenen Endgeräte, Netzwerke und anderen Infrastrukturkomponenten sowie der Middleware von Drittanbietern, die für den Zugriff auf die Zendesk-Dienste und/oder die Vor- und Nachverarbeitung seiner Servicedaten außerhalb von Zendesk-Systemen verwendet werden
- Sein eigener, nicht standardmäßiger Code, der zur Bereitstellung zusätzlicher Funktionen für Zendesk-Dienste verwendet wird – sei es intern oder extern entwickelter oder von Dritten entwickelter und vom Abonnenten für den Einsatz in Verbindung mit Zendesk-Diensten erworbener Code. Dies gilt auch für Code, der von Zendesk Professional Services auf Wunsch des Abonnenten für ihn entwickelt wurde, sofern die Zuständigkeit für diesen Code und seine Wartung vertraglich an den Abonnenten übertragen wurde.
-
Zendesk ist verantwortlich für die Wartung und das Patchen aller Systeme oder Codes innerhalb der Zendesk-Architektur und/oder des vertraglich vereinbarten Umfangs. Hierzu gehören:
- Seine eigene logisch verwaltete Infrastruktur innerhalb der für die Bereitstellung der Dienste verwendeten Einrichtungen des Hosting-Anbieters, einschließlich der Betriebssysteme, Sicherheitsinfrastrukturen und direkt von Zendesk kontrollierten Container-, Orchestrierungs- und sonstigen Systeme
- Seine eigene physisch und/oder logisch verwaltete Infrastruktur, die innerhalb der Zendesk-Unternehmensumgebung verwendet wird, z. B. Endgeräte von Mitarbeitern oder die Infrastruktur des Unternehmensnetzwerks
- Die den Zendesk-Diensten zugrunde liegende proprietäre Codebasis
* Beachten Sie, dass Marketplace Apps zwar innerhalb der Zendesk-Architektur ausgeführt werden, aber nicht unter den Zendesk-Hauptdienstleistungsvertrag fallen. Für diese gelten die in den Nutzungsbedingungen für Marketplace Apps ausgeführten Vereinbarungen zwischen dem Abonnenten und dem Entwickler der App selbst. Für die Wartung von Marketplace Apps ist der jeweilige App-Entwickler zuständig.
VI. Sicherheitsvorfälle
Trotz aller Bemühungen kann auch einmal etwas schief gehen. Wie Sie Sicherheitsvorfälle erkennen, behandeln und beheben, ist für die Schadensbegrenzung und das Kundenvertrauen entscheidend. In diesem Abschnitt sind die Rollen und Verantwortlichkeiten der Parteien während eines Sicherheitsvorfalls ausgeführt.
- Der Abonnent ist verantwortlich für alle Sicherheitsvorfälle und Sicherheitsverletzungen in seiner eigenen Instanz, die nicht auf Sicherheitslücken oder Vorfälle im Dienst selbst zurückzuführen sind. Hierzu gehören das:
- Untersuchen und Beheben von mutmaßlichen oder tatsächlichen Sicherheitsverletzungen in seiner eigenen Instanz, die auf (i) unzureichende Zugangskontrolle oder Hygiene (einschließlich der Verwendung schwacher oder ausnutzbarer Public Credentials), (ii) unzureichende Überwachung von Benutzeraktivitäten, (iii) mangelnde Sorgfalt im Umgang mit Kommunikationen oder nicht vertrauenswürdigen Inhalten aus Interaktionen mit Benutzern oder (iv) vom Abonnenten nach eigenem Ermessen eingerichtete Drittanbieter-Integrationen zurückzuführen sind.
- Benachrichtigen von Regierungs- oder Strafverfolgungsbehörden und Endbenutzern bei Sicherheitsverletzungen, die durch Handlungen des Abonnenten oder Drittanbieter-Integrationen verursacht wurden, oder von Zendesk gemeldeten Verletzungen der Sicherheit von Servicedaten, die die Instanz des Abonnenten betreffen
-
Zendesk ist verantwortlich für Kontrollen zur Untersuchung von Sicherheitsvorfällen und die Benachrichtigung der von Verletzungen der Sicherheit von Servicedaten im Dienst selbst betroffenen Abonnenten. Hierzu gehören das:
- Aufstellen einer dokumentierten Richtlinie für die Reaktion auf Sicherheitsvorfälle sowie das Zuweisen entsprechender Rollen und Verantwortlichkeiten an geeignete Mitarbeiter
- Untersuchen anomaler Aktivitäten
- Eindämmen bestätigter Verletzungen der Sicherheit von Servicedaten
- Benachrichtigen der betroffenen Abonnenten oder zuständigen Regierungs- oder Strafverfolgungsbehörden entsprechend den gesetzlichen Vorschriften
- Einrichten und Testen robuster Backup- und Disaster Recovery-Prozesse
VII. Hilfreiche Links
Sicherer Kundenservice dank Zendesk-Sicherheitsfunktionen
Bewährte Zendesk-Sicherheitspraktiken
Zugangskontrollen und Hygiene
Sicherheit und Benutzerzugriff in Zendesk Support (Linksammlung)
Benutzerauthentifizierung in Chat
Gewähren von temporärem Zugriff auf Ihr Konto durch Zendesk
Integrationen
Zendesk Unterauftragsverarbeiter
Zendesk Connect Unterauftragsverarbeiter
Überlegungen zu Daten, Datenschutz, Compliance und gesetzlichen Bestimmungen
Cookie-Richtlinie für Zendesk-Produkte
Zendesk-Hauptdienstleistungsvertrag
Zendesk Datensicherheit und Datenschutz
Überwachung
Auditprotokoll der Änderungen in der Support-Instanz (UI / API)
Auditprotokoll der Support-Ticketereignisse (API)
Inkrementelle Chat-Exporte und Echtzeit-API
Angepasste Sunshine-Objekte, -Ereignisse und -Profile (API)
Wenn Sie weitere Fragen haben, wenden Sie sich bitte an security@zendesk.com.
VIII. Änderungsprotokoll
16. Juni 2023
- Änderungsprotokoll hinzugefügt
- Abschnitt V. „Wartung“ hinzugefügt
- Klarstellung in Abschnitt VI. „Sicherheitsvorfälle“ zur Verantwortung des Abonnenten für Vorfälle hinzugefügt, die auf Verwendung schwacher oder ausnutzbarer Public Credentials durch den Abonnenten und/oder seine Endbenutzer zurückzuführen sind
Hinweis zur Übersetzung: Dieser Beitrag wurde mit automatischer Übersetzungssoftware übersetzt, um dem Leser ein grundlegendes Verständnis des Inhalts zu vermitteln. Trotz angemessener Bemühungen, eine akkurate Übersetzung bereitzustellen, kann Zendesk keine Garantie für die Genauigkeit übernehmen.
Sollten in Bezug auf die Genauigkeit der Informationen im übersetzten Beitrag Fragen auftreten, beziehen Sie sich bitte auf die englische Version des Beitrags, die als offizielle Version gilt.
Bearbeitet 08. Mai 2024 · Craig Lima
0
Follower
2
Stimmen
0
Kommentare
Craig Lima hat einen Beitrag erstellt
Es erfordert viel Vertrauen, Daten in die Cloud zu stellen. Umgekehrt möchten Sie aber wissen, dass die Partner, mit denen Sie diese Informationen teilen, absoluten Wert auf Sicherheit legen. Unsere Abonnenten verwenden unterschiedliche Standards und Frameworks für den Umgang mit sensiblen Informationen. Daher haben wir in allen unseren Diensten die folgenden ISO-Benchmarks (ISO) implementiert, um die Sicherheit und Compliance Ihrer Daten zu gewährleisten.
ISO 27001
Die Standards ISO/IEC 27000 bieten eine Reihe von Frameworks für die Behandlung von Daten in Unternehmen. Der gebräuchlichste dieser Standards, ISO/IEC 27001, definiert Anforderungen für ein Information Security Management System (ISMS) und gewährleistet, dass diese von entsprechend zertifizierten Organisationen eingehalten werden.
ISO 27018
ISO/IEC 27018 stellt auf ISO/IEC 27002 basierende Richtlinien für den Schutz personenbezogener Informationen durch Cloud-Serviceanbieter wie Zendesk auf.
ISO 27701
ISO/IEC 27701:2019 spezifiziert Anforderungen und Anleitungen für die Einrichtung, Implementierung, Unterhaltung und kontinuierliche Verbesserung eines Privacy Information Management System (PIMS). Sie dient als Ergänzung zu ISO/IEC 27001 und ISO/IEC 27002 für das Datenschutzmanagement in einer Organisation. Diese Vorschrift steckt einen Rahmen für die Verwaltung der von der Datenverantwortlichen und vom Datenauftragsverarbeiter verwendeten personenbezogenen Daten ab und sorgt dafür, dass sowohl die Sicherheits- als auch die Datenschutzkontrollen aufeinander abgestimmt sind.
Zendesk-Services und -Prozesse für die Zertifizierungen
Der Anwendungsbereich der Zertifizierungen ISO/IEC 27001:2013, ISO/IEC 27018:2014 und ISO/IEC 27701:2019 ist durch die globale Netzwerkinfrastruktur von Zendesk, Inc. und die entsprechenden Produkte und Services begrenzt, einschließlich Entwicklungs-, Betriebs-, Wartung und Bereitstellung von Support, Guide, Chat, Connect, Inbox und Explore. Diese Tickets werden zentral von der Zendesk-Zendesk-Hauptverwaltung aus verwaltet und von den folgenden Standorten aus unterstützt: San Francisco, CA und Madison, WI (USA), Kopenhagen (Dänemark), Dublin (Irland), Manila (Philippinen), Melbourne (Australien), Montpellier (Frankreich) und Singapur.
Darüber hinaus wirddie Infrastruktur, auf der alle im Rahmen von IaaS angebotenen Dienste ausgeführt werden , durch einen Infrastruktur-as-a-Service- (IaaS-) Rechenzentrumsanbieter geschütztServices ausgeführt werden. Die Sicherheitskontrollen von Zendesk für die Verwaltung der IaaS-Umgebung sind in der enthalten mit Ausnahme physischer und umgebungsbezogener Kontrollen.
Unser Unterauftragsverarbeiter für Hosting-Services ist derzeit AWS, ein Unternehmen, das über mehrere eigene ISO-Zertifizierungen verfügt. Weitere Informationen finden Sie auf der Compliance-Seite des Unternehmens hier.
Was das für Kunden bedeutet
Intern stellen wir durch diese unabhängigen Zertifizierungen sicher, dass unsere Sicherheitsmanagement- und Datenschutzfunktionen führenden Industriestandards entsprechen. Für unsere Kunden ist durch diese extern validierten Compliance-Standards gewährleistet, dass wir unseren Verpflichtungen im Hinblick auf die ordnungsgemäße Behandlung ihrer Daten erfüllen. Darüber hinaus verlangt ISO/IEC 27701 von Organisationen, anwendbare Gesetze und Vorschriften als Teil ihrer Auditkriterien zu deklarieren. Dadurch kann dieser Standard Anforderungen wie der Datenschutz-Grundverordnung (DSGVO), dem California Consumer Privacy Act (CCPA) und anderen Gesetzen entsprechen .
Schutz für alle Benutzer der betreffenden Produkte
Diese Zertifizierungen gelten für unsere oben aufgeführten Services. Eine zusätzliche Bezahlung oder besondere Konfiguration Ihrer Instanz ist nicht erforderlich.
ISO 27001-, ISO 27018- und ISO 27701-Zertifizierungen von Zendesk im Vergleich zu Kundenzertifizierungen
Unsere Zertifizierungen nach ISO 27001, ISO 27018 und ISO 27701 decken Sicherheits- und Datenschutzmanagementprozesse für einen bestimmten Umfang von Zendesk-Services ab. Wenn Sie eine dieser Zertifizierungen anstreben, während Sie einen Teil Ihres Dienstes mithilfe von Zendesk betreiben, beachten Sie bitte, dass Sie nicht automatisch durch einen Partner zertifiziert werden. Unsere Zertifizierungen machen es Ihnen jedoch unter Umständen leichter, diese Zertifizierungen für Ihre eigene Instanz zu erhalten.
Abrufen der Zendesk ISO-Zertifizierungen
Sie können jederzeit kostenlos – ohne Unterzeichnung einer Geheimhaltungsvereinbarung – auf unsere ISO-Zertifikate zugreifen, indem Sie das folgende Formular ausfüllen: https://www.zendesk.com/product/zendesk-security/#anchor-security-resources
Hinweis zur Übersetzung: Dieser Beitrag wurde mit automatischer Übersetzungssoftware übersetzt, um dem Leser ein grundlegendes Verständnis des Inhalts zu vermitteln. Trotz angemessener Bemühungen, eine akkurate Übersetzung bereitzustellen, kann Zendesk keine Garantie für die Genauigkeit übernehmen.
Sollten in Bezug auf die Genauigkeit der Informationen im übersetzten Beitrag Fragen auftreten, beziehen Sie sich bitte auf die englische Version des Beitrags, die als offizielle Version gilt.
Bearbeitet 08. Mai 2024 · Craig Lima
3
Follower
2
Stimmen
0
Kommentare
Craig Lima hat einen Beitrag erstellt
HIPAA und HDS-fähige Konten (zusammen „Gesundheitswesen-fähige Konten“):
Alle in diesem Dokument verwendeten Begriffe haben die im Business Associate Agreement („BAA“) oder im Rahmen-Abonnementvertrag von Zendesk vorgegebene Bedeutung für die Art des Kontos (zusammen „Gesundheitsvereinbarung“).
Bei HIPAA fähigen Konten bezieht sich „PHI“ auf „geschützte Gesundheitsdaten“ und bei HDS-fähigen Konten bezieht sich „PHI“ auf „personenbezogene Gesundheitsdaten“.
Zendesk und der Abonnent haben eine Gesundheitsvereinbarung abgeschlossen, in der dem Abonnenten empfohlen wird, je nach Anwendungsfall die folgenden Konfigurationen oder Alternativen zur Erfüllung seiner Compliance-Anforderungen nach geltendem Recht für jedes Gesundheitswesen aktivierte Konto zu prüfen und zu implementieren (s) zu aktualisieren, bevor PHI in den Dienst eingegeben wird.
Wenn der Abonnent nach eigenem Ermessen auf die Implementierung einer der unten aufgeführten empfohlenen Konfigurationen verzichten sollte, übernimmt er die alleinige Verantwortung für den unbefugten Zugriff auf oder die missbräuchliche Verwendung der Servicedaten des Abonnenten, einschließlich PHI-Daten, die sich aus beliebigen Daten ergeben solche Abweichungen von den empfohlenen Konfigurationen durch den Abonnenten vorgenommen haben.
Der Abonnent muss Servicepläne auf der entsprechenden Stufe gekauft haben und über die erforderlichen Add-ons verfügen (im Zweifelsfall wenden Sie sich an Ihren Kundenberater).
Wenn der Abonnent ein HDS-fähiges Konto hat, muss der Abonnent in der Zendesk-Richtlinie für Unterauftragsverarbeiter auf die Schaltfläche „Folgen“ klicken, um Benachrichtigungen über Änderungen der für die Bereitstellung der Dienste eingesetzten Unterauftragsverarbeiter zu erhalten.
Die folgenden Mindest-Sicherheitskonfigurationen für Zendesk-Dienste sollten eingerichtet werden und sind in der Gesundheitsvereinbarung für alle aktivierten Konten aufgeführt
I Zendesk Support:
-
Sichere Agentenauthentifizierung mit einer der beiden folgenden Methoden:
- Verwenden von Zendesk Support mit Kennworteinstellungen: (i) auf „Empfohlen“; oder (ii) vom Abonnenten auf eine Weise angepasst werden, die Anforderungen festlegt, die nicht weniger sicher sind als die in der Einstellung „Empfohlen“. Darüber hinaus muss der Abonnent unter der Option in diesem Unterabschnitt die Zwei-Faktor-Authentifizierung („2FA“) nativ im Dienst aktivieren und durchsetzen. und dass administrative Kontrollen, die es Administratoren ermöglichen, Kennwörter für Endbenutzer festzulegen, deaktiviert werden; oder
- Verwenden einer externen Single-Sign-On (SSO)-Lösung mit festgelegten Anforderungen, die nicht weniger sicher sind als die unter der „empfohlenen“ Kennworteinstellung von Zendesk festgelegten Anforderungen, und Aktivieren und Durchsetzen der Zwei-Faktor-Authentifizierung in der ausgewählten Lösung für den Zugriff aller Agenten. Die administrativen Kontrollen, die es Administratoren ermöglichen, Kennwörter für Endbenutzer festzulegen, müssen deaktiviert sein.
- Bei allen Authentifizierungsoptionen mit SSO als Authentifizierungsmethode sollte der Kennwortzugriff deaktiviert werden.
- Die SSL-Verschlüsselung (Secure Socket Layer) muss bei Konten, bei denen das Gesundheitswesen aktiviert ist, immer aktiviert bleiben. Konten, die eine andere Domäne als Zendesk.com verwenden, müssen gehostetes SSL einrichten und pflegen.
- Der Agentenzugriff sollte nach Möglichkeit auf bestimmte IP-Adressen beschränkt werden, die unter der Kontrolle des Abonnenten stehen es sei denn, der Abonnent aktiviert die Multi-Faktor-Authentifizierung für Agenten wie oben in den Anforderungen 1.a oder 1.b beschrieben (entweder nativ im Dienst oder in der Abonnentenumgebung in Verbindung mit Enterprise-SSO). Zur Klarstellung: „Agentenzugriff“ bezieht sich auf den Zugriff, der einem menschlichen Agenten gewährt wird, der über die Benutzerschnittstelle („UI“) auf Dienstdaten zugreift.
-
In dem Umfang, in dem das für das Gesundheitswesen aktivierte Konto des Abonnenten Aufrufe an Zendesk-Anwendungsprogrammierschnittstellen (APIs) ermöglicht, übernimmt der Abonnent die volle Verantwortung für das Verständnis der Sicherheitsauswirkungen aller Abonnenten oder Dritten, die Daten erstellen, aufrufen, ändern oder löschen dürfen Servicedaten und personenbezogene Gesundheitsinformationen über diesen Zugriff und/oder Integrationen. Für den Zugriff auf die genannten APIs bietet Zendesk verschiedene Methoden an, die hier beschrieben werden. Der Abonnent ist verpflichtet, die folgenden bewährten Sicherheitspraktiken basierend auf dem verwendeten API-Modell zu implementieren:
- OAuth 2.0-Ansatz verwenden. Dieses Modell bietet die granularsten Sicherheitsfunktionen, setzt aber voraus, dass die Zugriffsberechtigungen von einem Endbenutzer akzeptiert werden. Der Abonnent sollte nach Möglichkeit den Ansatz und das Authentifizierungsschema von OAuth 2.0verwenden. Der Abonnent sollte jedem OAuth Client einen aussagekräftigen und eindeutigen Clientnamen sowie eine eindeutige Kennung geben. Die für jedes OAuth -Token gewährten Berechtigungen sollten die geringsten Berechtigungen zulassen, die zur Erfüllung der erforderlichen Aufgaben erforderlich sind.
- REST-API-Token-Ansatz verwendet. Dieses Modell ist am breitesten und ermöglicht es einem API-Token, die volle Funktionalität des API-Modells zu nutzen. Sie bietet den umfassendsten Zugriff und die umfassendsten Funktionen und sollte mit Bedacht eingesetzt werden. Bei Verwendung dieses Ansatzes sollte der Abonnent (i) für jeden Dienst ein eindeutiges Token mit einer aussagekräftigen Funktion verwenden; (ii) API-Token nicht an Dritte weitergeben, es sei denn, dies ist erforderlich und es müssen Übertragungsverfahren durchgeführt werden, die durchgängig verschlüsselt sind; (ii) anerkennen, dass das zugehörige Token sofort rotiert werden muss, wenn das API-Token an einen Dritten weitergegeben wird und der Abonnent auf eine Datenschutzverletzung durch einen Dritten aufmerksam gemacht wird; und (iv) das Token mindestens häufig in Übereinstimmung mit den Organisationsrichtlinien des Abonnentenrotieren.
- Wenn möglich, sollte der Abonnent den Kennwortzugriff auf die API deaktivieren, da Benutzer bei jeder Anfrage Anmeldedaten erhalten, die allgemein sichtbar sind und somit leichter von bösartigen Parteien abgefangen werden können.
- Damit der Zugriff auf Anhänge authentifiziert werden kann, sollte der Abonnent die Option „Authentifizierung erforderlich, um Anhänge herunterzuladen“ aktivieren. Andernfalls kann jeder, der Zugriff auf die richtige URL des Anhangs hat, auf den uneingeschränkten Anhang zugreifen. In solchen Fällen übernimmt der Abonnent die gesamte Verantwortung für den Inhalt und Zugriff auf solche Anhangsdaten.
- Abonnenten sollten auf allen Endpunkten, auf die Agenten, Administratoren und Kontoinhaber zugreifen, systematisch einen kennwortgeschützten Bildschirmschoner oder Startbildschirm einrichten, der nach maximal fünfzehn (15) Minuten Inaktivität aktiviert wird.
- Der Abonnent sollte die Anzeigeberechtigungen, die es einem Benutzer ermöglichen, Aktualisierungen für eine gesamte Instanz/Marke/Organisation anzuzeigen, oder die Standardeinstellung, die einen Zugriff über die eigenen Tickets oder Gruppen des Benutzers hinaus ermöglicht, nicht ändern (es sei denn, der Abonnent übernimmt die gesamte Verantwortung dafür, sicherzustellen, dass diese Benutzer vom Abonnenten genehmigt werden auf alle nachfolgenden Daten zugreifen). Der Abonnent erkennt an, dass die Berechtigungen für Endbenutzerorganisationen im Benutzerprofil und in der Organisation selbst festgelegt werden können und dass die freizügigere Einstellung hat Vorrang vor der weniger freizügigen Einstellung.
- Der Abonnent erkennt an, dass Zendesk nicht dafür verantwortlich ist, E-Mail-Übertragungen von Endbenutzern und zugehörige Dienstdaten vor dem Eingang in seiner Zendesk Support Instanz zu schützen. Hierzu gehören alle personenbezogenen Gesundheitsinformationen, die per E-Mail über Antworten auf Zendesk Support -Tickets weitergegeben werden, einschließlich Ticketkommentare oder Anhänge.
- Der Abonnent erkennt an, dass Zendesk Support unter verschiedenen Umständen eine E-Mail an einen Endbenutzer sendet, z. B. wenn ein Agent des Abonnenten über den E-Mail-Kanal auf ein Zendesk Support -Ticket antwortet oder dies durch eine Automatisierung oder einen Auslöser ausgelöst wird. Standardmäßig enthält diese E-Mail die neuesten Tickets oder andere Informationen, die für eine automatische Benachrichtigung konfiguriert sind, darunter auch personenbezogene Informationen. Um den Abonnenten noch besser zu schützen, sollte seine Zendesk Support Instanz sein die so konfiguriert sind, dass der Endbenutzer nur benachrichtigt wird, dass ein Agent geantwortet hat, und dass der Endbenutzer sich bei Zendesk Support authentifizieren muss, um den Inhalt der Nachricht zu sehen.
-
Der Abonnent erkennt an, dass alle nach eigenem Ermessen in einem beliebigen Zendesk-Dienst eingesetzten SMS-Funktionen auf SMS und/oder verwandten Protokollen basieren, die die unverschlüsselte Übertragung von Nachrichten zwischen und in die jeweiligen Dienste ermöglichen. SMS-Funktionen sollten daher entweder:
- nicht in einem aktivierten Gesundheitsfürsorge-Konto* verwendet werden, oder
- der Abonnent übernimmt die gesamte Verantwortung für die Nutzung dieser Funktionen
- Der Abonnent erkennt an, dass bei Nutzung der Legacy-Funktionalität Umfragen zur Kundenzufriedenheit („Legacy CSAT“) mit dem Support -Ticket verknüpfte Servicedaten (möglicherweise mit PHI) per E-Mail gesendet werden, um die Bewertung des Benutzers zu erhalten, deren Verschlüsselungsstatus nicht kontrolliert wird von Zendesk entwickelt wurde. Daher sollte die Legacy- CSAT Funktion entweder:
- nicht in einem aktivierten Gesundheitsfürsorge-Konto* verwendet werden, oder
- der Abonnent übernimmt die gesamte Verantwortung für die Nutzung dieser Funktionen
-
Der Abonnent erkennt an, dass er die Kundenzufriedenheitsumfragen („CSAT“) des Dienstesgenutzt hat für den Ticketkanal konfiguriert ist, Servicedaten (die PHI enthalten können), die mit dem Support -Ticket verknüpft sind, per E-Mail sendet, um die Bewertung des Benutzers zu erhalten. Deren Verschlüsselungsstatus wird nicht von Zendesk gesteuert. Darüber hinaus hat jeder mit der entsprechenden CSAT URL Zugriff auf die Antworten auf das jeweilige Ticket. Daher sollten Sie die CSAT Funktionalität für den Ticketkanal verwenden
- Konfigurieren Sie den E-Mail-Text der CSAT Automatisierung so, dass potenzielle PHI-Informationen nicht enthalten sind, und verwenden Sie die {{satisfaction.survey_url}} exklusiv für den -Platzhalter
- Verwenden Sie nicht die Funktion „Offene Fragen“.
* Zur Klarstellung: Die in Abschnitt 10 zu SMS genannten Einschränkungen für personenbezogene Daten gelten nicht für die produktintegrierte Nutzung der 2FA (siehe Abschnitt 1.a), da diese Funktion lediglich eine numerische Zeichenfolge zur Identitätsprüfung sendet.
II. Zendesk Guide und Gather:
- Der Abonnent erkennt an, dass die Guide- und Gather-Dienste öffentlich sind (sofern keine beschränkten Beiträge genutzt oder eine geschlossene oder beschränkte Instanzverwendet werden) und der Abonnent daher sicherstellen sollte, dass Beiträge in Zendesk Guide oder Gather keine personenbezogenen Gesundheitsinformationen enthalten, auch nicht im Text von im Beitrag, als Anhang oder als Bild im Beitrag erscheinen.
- Der Abonnent sollte entweder die Möglichkeit für Endbenutzer deaktivieren, Kommentare in Zendesk Guide hinzuzufügen, oder die persönlichen Gesundheitsinformationen aus allen Kommentaren entfernen (wie in Abschnitt 3 unten beschrieben).
- Wenn der Zendesk Guide Dienst Guide Professional oder Enterprise ist, sollten Abonnenten die Möglichkeit, neue Posts zu erstellen, deaktivieren, indem sie die Gather-Funktionen mit Zendesk Guide deaktivieren bzw. Gather-Funktionen deaktivieren, weil die Absicht des Abonnenten besteht Anwendungsfall sollten Abonnenten die Inhaltsmoderation im Zendesk Guide Dienst aktivieren und die Einstellung „Alle Inhalte moderieren“ wählen. Es sollten keine Eingaben genehmigt werden, die PHI enthalten.
- Die Nutzung von Community-Moderatoren, die keine Mitarbeiter sind, sollte im Gather-Dienst nicht zulässig sein, es sei denn, der Abonnent übernimmt die Verantwortung für den potenziellen Zugriff dieser Benutzer auf Daten, einschließlich möglicher PHI-Daten (falls zutreffend).
- Der Abonnent erkennt an, dass „@Erwähnungen" von Gather-Community-Mitgliedern möglich sind, sofern Endbenutzern öffentliche Profile zugewiesen sind. Sollte diese Funktion in ihrem Anwendungsfall als Risiko eingestuft werden, sollten öffentliche Profile deaktiviert oder @Erwähnungen deaktiviert werden.
III. Zendesk Messaging:
- Der Abonnent sollte Social-Media-Messaging-Kanalintegrationen nur dann aktivieren, wenn er die volle Verantwortung dafür übernimmt, entweder (i) sicherzustellen, dass keine personenbezogenen Gesundheitsinformationen in Social-Media-Nachrichten enthalten sind, oder (ii) eine eigene BAA mit integrierten Messaging-Plattformen abzuschließen.
- Der Abonnent sollte die Fähigkeit von Endbenutzern deaktivieren, Dateien an Messaging-Konversationen anzuhängen, und muss die volle Verantwortung dafür übernehmen, entweder (i) sichere Anhänge zu aktivieren oder (ii) die Sicherstellung, dass Agenten keine Dateien mit ePHI an Messaging-Konversationen anhängen. Andernfalls kann jeder, der Zugriff auf die richtige URL des Anhangs hat, auf den uneingeschränkten Anhang zugreifen. In solchen Fällen übernimmt der Abonnent die gesamte Verantwortung für den Inhalt und den Zugriff auf solche URLs und/oder Anhangsdaten.
- Der Abonnent trägt die gesamte Verantwortung dafür, dass alle Agenten und Light Agents alle eingehenden Nachrichten von allen Endbenutzern sehen können.
- Wenn der Abonnent oder seine Agenten auf Integrationen für APIs und Webhooks zugreifen oder diese entwickeln (z. B. als Teil eines für KI Agenten erstellten Workflows) oder das Messaging-Erlebnis anpassen, übernimmt der Abonnent die volle Verantwortung, die Datenschutz- und Sicherheitsauswirkungen aller angepassten Workflows zu verstehen Abonnenten oder Drittanbieter (einschließlich Chatbot-Anbieter), die über diesen Zugriff und/oder diese Integrationen Servicedaten und ePHI erstellen, aufrufen, ändern oder löschen dürfen.
- Wenn der Abonnent einem Agenten die Berechtigung zur Teilnahme an einer Messaging-Konversation entziehen möchte, während die Messaging-Konversation aktiv ist, übernimmt er die gesamte Verantwortung für die Kündigung des Zugriffs des Agenten auf Zendesk.
- Standardmäßig werden Web-Widget-Konversationen mit Endbenutzern dauerhaft vorgenommen und können von Endbenutzern angezeigt werden, wenn sie vom selben Gerät zum Web-Chat zurückkehren. Der Abonnent ist verpflichtet, diese Funktion entweder zu deaktivieren oder dafür zu sorgen, dass Endbenutzer keine Geräte teilen.
-
Wenn der Abonnent eine Authentifizierung für Endbenutzer implementieren möchte, trägt er die gesamte Verantwortung dafür, dass dies auf sichere Weise im Einklang mit Best Practices und Industriestandards implementiert wird.
- Bei Verwendung dieses Ansatzes sollte der Abonnent (i) für jeden Authentifizierungskanal einen eindeutigen JWT-Signaturschlüssel verwenden und dem Token eine aussagekräftige Namensfunktion geben; (ii) Sie geben JWT-Signaturschlüssel nicht an Dritte weiter, es sei denn, dies ist erforderlich und es müssen Übertragungsverfahren durchgeführt werden, die durchgängig verschlüsselt sind; (ii) anerkennen, dass der Abonnent den zugehörigen JWT-Signaturschlüssel unverzüglich wechseln muss, wenn der JWT-Signaturschlüssel an einen Dritten weitergegeben wird und der Abonnent auf eine Datenschutzverletzung durch einen Dritten aufmerksam gemacht wird; und (iv) der JWT-Signaturschlüssel zumindest häufig in Übereinstimmung mit den Organisationsrichtlinien des Abonnenten rotiert wird.
- Der Abonnent sollte das JWT-Ablaufattribut verwenden und seinen Wert auf maximal 15 Minuten setzen.
- Der Abonnent erkennt an, dass Interaktionen zwischen Endbenutzern und KI -Agenten, die nicht von einem menschlichen Agenten übergeben und in ein Ticket umgewandelt werden, weiterhin im System gespeichert sind und es in der Verantwortung des Abonnenten liegen, diese Interaktionen entsprechend seinen Verpflichtungen zu löschen (z. B. durch Implementierung einer einen Webhook, der den Abonnenten benachrichtigt, wenn diese Konversationen gespeichert werden, und über die Sunshine Conversations API (automatisch) das Löschen auslöst).
- Der Abonnent erkennt an, dass die Konversationen zwischen Endbenutzern und KI Agenten umgewandeltwurden in ein Ticket umgewandelt wurde, kann derzeit nicht geschwärzt werden. Zum Löschen wird das Ticket gelöscht.
- Der Abonnent erkennt an, dass Endbenutzeranhänge in Messaging-Kanälen in Zendesk derzeit nicht auf Malware gescannt werden. Der Abonnent trägt die volle Verantwortung für die Einrichtung von Verfahren und Richtlinien zur Risikominderung für seine Vermögenswerte.
- Der Abonnent erkennt an, dass bei Nutzung der Funktionalität „Nebenkonversationen“ untergeordnete Ticket- und/oder Nebenkonversationsnachrichten in der Support -Instanz des Abonnenten erstellt oder von dort aus per Ticket, E-Mail, Slack oder Integrationen (nach Ermessen des Agenten) an Empfänger gesendet werden können (je nach Ermessen des Agenten). . Wenn der Abonnent diese Funktionalität in einem für das Gesundheitswesen aktivierten Konto nutzt, übernimmt er die alleinige Verantwortung (i) dafür, dass in diesen Nachrichten keine personenbezogenen Gesundheitsinformationen enthalten sind, oder (ii) falls in diesen Nachrichten personenbezogene Gesundheitsinformationen enthalten sein könnten für jegliche Haftung, Kosten, Schäden oder Schäden im Zusammenhang mit dem unbefugten Erwerb, Zugriff, Verwendung oder Offenlegung von PHI infolge des Nachrichtenaustauschs über die Funktion „Nebenkonversation“.
IV. Zendesk Sunshine Conversations:
- Der Abonnent sollte die Integration von Drittanbieter-Kanälen nur dann aktivieren, wenn er die volle Verantwortung dafür übernimmt, dass entweder (i) keine personenbezogenen Gesundheitsinformationen in den Nachrichten von Drittanbieter-Kanälen enthalten sind oder (ii) eine eigene BAA mit integrierten Messaging-Plattformen abgeschlossen wird.
-
Der Abonnent übernimmt die gesamte Verantwortung für das Verständnis der Sicherheitsauswirkungen aller Abonnenten oder Dritten, die über die Sunshine Conversations APIs Dienstdaten und personenbezogene Gesundheitsinformationen erstellen, abrufen, modifizieren oder löschen dürfen. Für den Zugriff auf die genannten APIs muss der Abonnent die folgenden bewährten Sicherheitspraktiken auf Grundlage des verwendeten API-Modells implementieren:
- OAuth 2.0-Ansatz verwenden. Dieses Modell bietet die granularsten Sicherheitsfunktionen, setzt aber voraus, dass die Zugriffsberechtigungen von einem Endbenutzer akzeptiert werden. Wo möglich sollte der Abonnent dies tun Der OAuth 2.0-Ansatz und das Authentifizierungsschema. Der Abonnent sollte jedem OAuth Client einen aussagekräftigen und eindeutigen Clientnamen sowie eine eindeutige Kennung geben.
- REST-API-Token-Ansatz verwendet. Dieses Modell ist am breitesten und ermöglicht es einem API-Token, die volle Funktionalität des API-Modells zu nutzen. Sie bietet den umfassendsten Zugriff und die umfassendsten Funktionen und sollte mit Bedacht eingesetzt werden. Bei Verwendung dieses Ansatzes sollte der Abonnent (i) für jeden Dienst ein eindeutiges Token mit einer aussagekräftigen Funktion verwenden; (ii) API-Token nicht an Dritte weitergeben, es sei denn, dies ist erforderlich und es müssen Übertragungsverfahren durchgeführt werden, die durchgängig verschlüsselt sind; (ii) anerkennen, dass das zugehörige Token sofort rotiert werden muss, wenn das API-Token an einen Dritten weitergegeben wird und der Abonnent auf eine Datenschutzverletzung durch einen Dritten aufmerksam gemacht wird; und (iv) das Token gemäß der Organisationsrichtlinie des Abonnenten häufig rotiert.
- Wenn der Abonnent oder seine Agenten auf Integrationen für APIs und Webhooks zugreifen oder diese entwickeln oder das Sunshine Conversations Erlebnis anpassen, übernimmt der Abonnent die volle Verantwortung, die Datenschutz- und Sicherheitsauswirkungen aller angepassten Workflows und aller zulässigen Abonnenten oder Drittanbieter (einschließlich Chatbot-Anbieter) zu verstehen über solche Zugriffe und/oder Integrationen Servicedaten und personenbezogene Gesundheitsinformationen zu erstellen, aufzurufen, zu modifizieren oder zu löschen.
- Der Abonnent erkennt an, dass die für Zendesk Support konfigurierten IP-Beschränkungen nicht auch für die Sunshine Conversations -API gelten. Die Abonnenten tragen die volle Verantwortung für die Beschränkung des Zugriffs auf die Sunshine Conversations -API und die API-Token wie unter 2.b beschrieben. und im Einklang mit den Richtlinien des Abonnenten steht.
- Der Abonnent sollte die Möglichkeit für Endbenutzer deaktivieren, Dateien an Sunshine Conversations Konversationen anzuhängen, und selbst die volle Verantwortung für die Aktivierung sicherer Anhängeübernehmen und auch sicherzustellen, dass Agenten keine Dateien mit PHI-Dateien an Messaging-Konversationen anhängen. Andernfalls kann jeder, der Zugriff auf die richtige URL des Anhangs hat, auf den uneingeschränkten Anhang zugreifen. In solchen Fällen übernimmt der Abonnent die gesamte Verantwortung für den Inhalt und Zugriff auf solche Anhangsdaten.
-
Wenn der Abonnent Authentifizierung für Endbenutzer implementieren möchte, übernimmt er die gesamte Verantwortung dafür, dass dies entsprechend den Best Practices zur Sicherheit und den Industriestandards erfolgt.
- Bei Verwendung dieses Ansatzes sollte der Abonnent (i) für jeden Authentifizierungskanal einen eindeutigen JWT-Signaturschlüssel verwenden und dem Token eine aussagekräftige Namensfunktion geben; (ii) Sie geben JWT-Signaturschlüssel nicht an Dritte weiter, es sei denn, dies ist erforderlich und es müssen Übertragungsverfahren durchgeführt werden, die durchgängig verschlüsselt sind; (ii) anerkennen, dass der Abonnent den zugehörigen JWT-Signaturschlüssel unverzüglich wechseln muss, wenn der JWT-Signaturschlüssel an einen Dritten weitergegeben wird und der Abonnent auf eine Datenschutzverletzung durch einen Dritten aufmerksam gemacht wird; und (iv) der JWT-Signaturschlüssel zumindest häufig in Übereinstimmung mit den Organisationsrichtlinien des Abonnenten rotiert wird.
- Der Abonnent sollte das JWT-Ablaufattribut verwenden und seinen Wert auf maximal 15 Minuten setzen.
- Der Abonnent erkennt an, dass Interaktionen zwischen Endbenutzern und KI -Agenten, die nicht von einem menschlichen Agenten übergeben und in ein Ticket umgewandelt werden, weiterhin im System gespeichert sind und dass es in der Verantwortung des Abonnenten liegt, diese Interaktionen entsprechend seinen Verpflichtungen zu löschen, z. B. durch Implementieren eines Webhooks die den Abonnenten benachrichtigt, wenn diese Konversationen gespeichert werden, und (automatisch) die Löschung über die Sunshine Conversations -API auslöst
- Der Abonnent erkennt an, dass Konversationen zwischen Endbenutzern und KI -Agenten, die in Tickets umgewandelt wurden, derzeit nicht geschwärzt werden können. Zum Löschen wird das Ticket gelöscht.
- Der Abonnent erkennt an, dass über die Sunshine Conversations API gelöschte Nachrichten nur für Endbenutzer, nicht aber im Zendesk- Arbeitsbereich für Agenten gelöscht werden. Sie können hierzu das Ticket selbst löschen oder die Funktion „Schwärzung“ verwenden (Einschränkungen: siehe Abschnitt 7.).
- Der Abonnent erkennt an, dass derzeit nicht alle Anhänge in Sunshine Conversation-Kanälen in Zendesk auf Malware gescannt werden. Der Abonnent übernimmt die volle Verantwortung für die Einrichtung von Verfahren und Richtlinien zur Risikominderung für seine Mitarbeiter.
V. Zendesk Chat:
- Der Abonnement sollte den Zugriff von Agenten auf den Zendesk Chat -Dienst beschränken, indem er sich an den Zendesk Support -Dienst anmeldet und sich über diesen authentifiziert.
- Abonnenten sollten keine Chatprotokolle per E-Mail senden, indem sie (a) das E-Mail-Piping deaktivieren, (b) die Option Chatprotokoll per E-Mail senden im Classic Web Widget deaktivieren und (c) keine Exporte per E-Mail vom Chat-Dashboardaus teilen
- Der Abonnent übernimmt die volle Verantwortung dafür, dass (i) in Chats keine personenbezogenen Gesundheitsinformationen vorhanden sind und/oder (ii) alle Agenten diese Daten einsehen können.
VI. Zendesk Explore Dienst:
Der Abonnent erkennt an, dass personenbezogene Gesundheitsinformationen über Benutzernamen, Tickettitel, Feld- und Formularoptionen und Inhalte von Freitextfeldern in Explore angezeigt werden können.
- Bei jeder Serviceinstanz, die personenbezogene Gesundheitsinformationen enthält, sollte der Abonnent (i) nur solchen Agenten Zugriff auf die Explore-Oberfläche gewähren, die auf alle Tickets/Anrufe/Chats zugreifen können, die in der übergeordneten Instanz des Dienstes PHI enthalten können, und (ii) einen solchen Zugriff unter Berücksichtigung der geringsten Berechtigungen gewähren, die für die Nutzung von Explore in ihrer Umgebung erforderlich sind. Weitere Informationen zum Konfigurieren von Zugriffsebenen in Explore finden Sie hier.
- Bei Nutzung der Exportfunktion (i) erkennt der Abonnent an, dass personenbezogene Gesundheitsinformationen an ein Gerät übertragen werden können, dem der Abonnent Zugriff auf die Benutzeroberfläche des Agenten gewährt hat und dass alle damit verbundenen Steuerungen auf diesem Gerät in der Verantwortung des Abonnenten liegen, und dass (ii) der Abonnent die Verwendung verweigern sollte Exportfunktionen per E-Mail für die exportierten Berichte nutzen, es sei denn, sie sind dafür verantwortlich, entweder (a) sicherzustellen, dass in diesen Exporten keine personenbezogenen Gesundheitsinformationen enthalten sind, oder (b) dass die für solche Übertragungen verwendeten E-Mail-Dienste die Verschlüsselung über das zulässige Mindestprotokoll unterstützen der bis dato aktuellen PCI-Standards entspricht.
* Besondere Überlegungen bei Verwendung von Explore Enterprise:
Der Abonnent erkennt an, dass bei Nutzung des Explore Enterprise-Dienstes möglicherweise mehr Funktionen für die gemeinsame Nutzung von Daten und zum Export bereitgestellt werden können. Der Abonnent muss:
- entweder (i) sicherstellen, dass in diesen Dashboards keine personenbezogenen Gesundheitsinformationen vorhanden sind, und/oder (ii) Dashboards nur mit Agenten, Gruppen, Listen oder Endbenutzern teilen, die zum Anzeigen und Empfangen dieser Daten berechtigt sind.
- IP-Beschränkungen nutzen
- beim Teilen von Dashboards über einen einheitlichen Ressourcen-Locator (URL) anerkennt der Abonnent, dass die Daten nicht mit einzelnen Benutzer- oder Gruppenbenutzerkonten geteilt werden, sondern über einen Zugriffslink. Der Abonnent sollte daher (i) den Kennwortschutz aktivieren, (ii) sicherstellen, dass die Komplexität der Kommunikation, die Rotation, die Speicherung und die Verteilung der gewählten Kennwörter an die empfangende Partei im Einklang mit den Kennwortrichtlinien des Abonnenten zum Schutz der in solchen Dashboards enthaltenen Daten erfolgt und (c) die Absenderadresse rotiert und zwar ohne unangemessene Verzögerung bei Verdacht oder Bestätigung der Offenlegung
VII. Produktintegrierte Funktionen für bereitgestellte verknüpfte Dienste („Add-ons“):
- Collaboration Deployed Associated Service: „Nebenkonversationen“. Der Abonnent erkennt an, dass bei Nutzung der Funktionalität „Nebenkonversationen“ untergeordnete Ticket- und/oder Nebenkonversationsnachrichten in der Support -Instanz des Abonnenten erstellt oder von dort aus per Ticket, E-Mail, Slack oder Integrationen (nach Ermessen des Agenten) an Empfänger gesendet werden können (je nach Ermessen des Agenten). . Wenn der Abonnent diese Funktionalität in einem für das Gesundheitswesen aktivierten Konto nutzt, übernimmt er die alleinige Verantwortung (i) dafür, dass in diesen Nachrichten keine personenbezogenen Gesundheitsinformationen enthalten sind, oder (ii) falls in diesen Nachrichten personenbezogene Gesundheitsinformationen enthalten sein könnten für jegliche Haftung, Kosten, Schäden oder Schäden im Zusammenhang mit dem unbefugten Erwerb, Zugriff, Verwendung oder Offenlegung von PHI infolge des Nachrichtenaustauschs über die Funktion „Nebenkonversation“.
VIII. Mobile Zendesk-Anwendungen (oder Zugriff per Mobilgerät wie Smartphone oder Tablet):
- Die Nutzung umfasst die Verschlüsselung auf Geräteebene
- Bimetrische oder PIN-Zugriffe auf die höchste zulässige Geräteeinstellung sollten genutzt werden
- Benachrichtigungen, die es ermöglichen, dass Ticketkommentare auf den Sperrbildschirmen solcher Geräte angezeigt werden, sollten deaktiviert werden
- Die Bildschirminaktivitätssperre sollte aktiviert und so konfiguriert sein, dass sie bei Inaktivität von maximal 15 Minuten sperrt.
- Der Abonnent erkennt an, dass die Schwärzungsfunktion in der mobilen Support -App nicht verfügbar ist und dass sich Agenten über den Browser anmelden müssen, um die Schwärzungsfunktion zu nutzen.
- Wenn der Abonnent die Authentifizierung von Endbenutzern für Zendesk Messaging wählt, erkennt er an, dass der Authentifizierungsstatus eines Endbenutzers in der mobilen Support -App nicht angezeigt wird.
IX. Zendesk Insights: Die Unterstützung für diesen Dienst wurde zum 5. Februar 2021 eingestellt.
X. Hinweis zur KI Funktionalität von Zendesk („Zendesk KI“, „Fortschrittliche KI“, „Generative KI“ usw.):
- Der Abonnent erkennt an, dass die KI Funktionen von Zendesk zur Steigerung der Produktivität des bzw. der Zendesk-Dienste(s) bestimmt sind und nicht auf eine Weise verwendet werden sollten, die als (i) Bereitstellung von medizinischem Rat, (ii) Bereitstellung einer Diagnose des Zustands oder der Symptome zu entwickeln, (ii) eine Behandlung zu verschreiben oder (iv) den Nutzer in irgendeiner Weise daran zu hindern, einen Rat, eine Diagnose oder eine Behandlung eines Gesundheitsexperten in Anspruch zu nehmen, (v) einem Nutzer anderweitig Informationen bereitzustellen oder Entscheidungen zu treffen, um ihn einzuschränken oder auszuschließen Gesundheitspläne, Behandlungsprogramme, Testdienste oder andere Gesundheitsleistungen, die sich auf die Inanspruchnahme oder Inanspruchnahme von Gesundheitsdiensten auswirken könnten (es sei denn, der Abonnent übernimmt die volle Verantwortung für diese Entscheidung basierend auf seinem konkreten Anwendungsfall und seinen Interaktionen mit seinen Benutzern). sowie die potenziellen Auswirkungen eines solchen Einsatzes von KI .)
- Der Abonnent erkennt an, dass bei Verwendung generativer KI Funktionen die KI Ausgaben nicht von Menschen sondern von Computern generiert werden und daher zu ungenauen Ergebnissen führen können. Zendesk übernimmt keine Garantie für die Genauigkeit dieser Ergebnisse.
- Der Abonnent erkennt an, dass die Funktion „Variationen generieren“ nicht aktiviert werden darf, wenn ein Gruß eines KI -Agenten Konversations-Bot verwendet wird, um den Endbenutzern des Abonnenten einen erforderlichen Haftungsausschluss zu übermitteln.
- Der Abonnent erkennt an, dass durch Aktivierung der Funktion „Erweitertes Schreiben“ im Admin Center diese Funktion für alle Agenten in ihrer Instanz unabhängig von ihren Rollen und Berechtigungen aktiviert wird.
XI. Zendesk QA
- Der Abonnent erkennt an, dass die Zendesk QA KI Funktionen zur Steigerung der Produktivität der Zendesk-Dienste dienen und nicht in einer Weise verwendet werden sollten, die als (i) Bereitstellung von medizinischem Rat oder (ii) Bereitstellung einer Zustandsdiagnose verstanden werden könnte oder Symptome zu entwickeln, (ii) eine Behandlung zu verschreiben oder (iv) den Nutzer in irgendeiner Weise daran zu hindern, einen Rat, eine Diagnose oder eine Behandlung eines Gesundheitsexperten in Anspruch zu nehmen, (v) einem Benutzer anderweitig Informationen bereitzustellen oder Entscheidungen zu treffen, um ihn aufzunehmen oder auszuschließen eines Gesundheitsplans, eines Behandlungsprogramms, eines Testdienstes oder eines anderen Gesundheitsdienstes, die sich auf seine Suche nach oder Inanspruchnahme von Gesundheitsdiensten auswirken könnten (es sei denn, der Abonnent übernimmt die volle Verantwortung für diese Entscheidung basierend auf seinem konkreten Anwendungsfall und seinen Interaktionen mit seinen Benutzern, wie z. B sowie die potenziellen Auswirkungen eines solchen Einsatzes von KI .)
- Der Abonnent nimmt zur Kenntnis, dass Lösch- oder Schwärzungen in seiner Zendesk-Instanz nicht sofort mit der Zendesk QA synchronisiert, sondern in den folgenden 3-6 Stunden übernommen werden.
- Bei Verwendung der Umfragefunktion sollte der Abonnent (i) die KI Unterstützungsfunktion von Zendesk QA deaktivieren (oder sicherstellen, dass alle Agenten, die QA Arbeiten durchführen, freigegeben sind, um potenzielle Daten in dieser Transaktion zu sehen, und dass die Grundsätze von Punkt 1 befolgt werden). ii) die Umfrage so konfigurieren, dass in den Fragen oder Beschreibungen der Umfrage keine personenbezogenen Gesundheitsinformationen enthalten sind (oder in E-Mails, die über Gelegenheits-StartTLS versendet werden, die Verantwortung für diese Daten übernehmen);
- Bei Verwendung der angepassten Integration „Zendesk Chat“ sollte der Abonnent einen in seinen Richtlinien festgelegten Datenaufbewahrungszeitraum festlegen, um sicherzustellen, dass seine Daten nicht unbegrenzt lang gespeichert werden.
- Der Abonnent erkennt an, dass ein Löschen von Teilen einer Zendesk Messaging-Konversation mit der Sunshine Conversations -API nicht in die Zendesk QA übernommen wird. Stattdessen sollten die Informationen durch Schwärzung aus dem ursprünglichen Ticket entfernt oder die gesamte Konversation entfernt werden.
- Der Abonnent erkennt an, dass Zendesk QA die Zendesk-Funktion „Private Anhänge“ gegenwärtig nicht unterstützt. Das bedeutet, dass Anhänge von jedem zugegriffen werden können, der Zugriff auf die korrekte URL für den Anhang hat, und dass sie nicht mit sensiblen Daten, einschließlich PHI, verwendet werden sollten. Der Abonnent übernimmt die gesamte Verantwortung für den Inhalt und Zugriff auf derartige URLs und/oder Anhangsdaten.
- Der Abonnent erkennt an, dass eine erweiterte Verbindungskonfiguration im Rahmen der erstmaligen Bereitstellung der Zendesk QA erst nach der ersten Synchronisierung möglich ist.
XII. Zendesk Workforce Management "WFM":
- Der Abonnent erkennt dies an
- Die Standardrolle „WFM -Administrator“ hat Zugriff auf alle Agentenaktivitäten und Einstellungen in Bezug auf den WFM Dienst (einschließlich der unter Punkt 2 genannten Stichwörter).
- Die Standardrolle „Agent“ hat Zugriff auf die Aktivitäten des Agenten, es sei denn, die Administratoren haben durch Erstellung angepasster Rollen (siehe hier) einen anderen Zugriff konfiguriert
- Der Abonnent erkennt an, dass Stichwörter, die von Agenten, Administratoren oder vordefinierter Systemlogik in Support -Tickets angewendet werden, im WFM Produkt für alle Benutzer sichtbar sind, die zur Anzeige der betreffenden Ticketaktivität berechtigt sind. Wenn Stichwörter vom Abonnenten als sensibel eingestuft werden, sollte der Zugriff entsprechend konfiguriert werden.
Hinweis: Aufgrund gesetzlicher oder regulatorischer Änderungen oder Änderungen des Zendesk-Service können sich die Sicherheitskonfigurationen in diesem Dokument von Zeit zu Zeit ändern. Dieses Dokument enthält die Empfehlungen von Zendesk für die minimalen Sicherheitskonfigurationen zum Schutz personenbezogener Gesundheitsinformationen in den oben genannten Zendesk-Produkten. Dieses Dokument ist weder als umfassende Vorlage für die Kontrolle dieser Daten noch als Rechtsberatung gedacht. Jeder Zendesk-Abonnent sollte bezüglich der HIPAA oder HDS-Compliance-Anforderungen einen eigenen Rechtsberater hinzuziehen und die zusätzlichen Änderungen an den Sicherheitskonfigurationen im Einklang mit der eigenen unabhängigen Analyse vornehmen, solange diese Änderungen die Sicherheit von nicht beeinträchtigen oder beeinträchtigen die in diesem Dokument beschriebenen Konfigurationen konfiguriert werden.
Änderungsprotokoll:
24. Januar 2025
- Konsolidierte HIPAA und HDS-Konfigurationen
27. Dezember 2024
- Abschnitt XII hinzugefügt, um Zendesk Workforce Management (WFM) in den Anwendungsbereich aufzunehmen
16. Dezember 2024
- Abschnitt xi hinzugefügt, um die Zendesk QA in den Anwendungsbereich aufzunehmen
- Verschiedene Instanzen von „Answer Bot“ in „KI -Agenten“ geändert, um Änderungen der Namenskonvention und einen erweiterten Anwendungsbereich zu kennzeichnen.
10. Oktober 2024
- Abschnitt I, Support, Nummer 12 (CSAT) und Abschnitt I, Support, Nummer 11 (Legacy- CSAT) bearbeitet, um neue Funktionen zu berücksichtigen.
7. März 2024
- Abschnitt X, „Hinweis zur KI Funktionalität“ von Zendesk, wurde hinzugefügt
-
Abschnitt I, Support, Nummer 7 (Anzeigeberechtigungen):
- Klarstellung, dass sich „Anzeigeberechtigungen“ auf die gesamte Instanz/Marke/Organisation und nicht nur auf die gesamte Organisation beziehen.
- Neue Bestimmung für das Verhalten Endbenutzer-spezifischer Organisationen hinzugefügt.
-
Abschnitt I, Support, Nummer 9 (E-Mail):
- Die Fälle, in denen Zendesk Support eine E-Mail an einen Endbenutzer sendet, haben jetzt auch Antworten über den E-Mail-Kanal oder solche, die durch eine Automatisierung oder einen Auslöser ausgelöst werden, anstatt nur einen Agenten, der auf ein Ticket antwortet.
- Sie haben festgelegt, dass automatische Benachrichtigungen standardmäßig die jüngste Ticketkorrespondenz oder andere konfigurierte Informationen enthalten können, darunter auch personenbezogene Informationen.
25. Oktober 2023
- Einführung: Verfeinerung des Einführungstexts für HIPAA fähige Konten
- Abschnitt II, Guide und Gather, Nummer 1 (Help-Center-Beschränkungen): Wir haben die IP-Beschränkungen durch beschränkte Beiträge ersetzt
13. April 2023
-
Abschnitt I, Support, Nummer 4 (APIs):
- Zur besseren Übersicht wurde ein Link zu den Authentifizierungsmethoden hinzugefügt
- b) Empfehlungen für den genauen Zeitrahmen für die Rotation zur Anpassung an branchenspezifische Best Practices entfernt und Verweis auf allgemeine Geschäftsbedingungen für die REST-API (Redundanz)
- c) hinzugefügt, um vor der Verwendung der Standardauthentifizierung für die API zu warnen
-
Abschnitt II, Leitfaden:
- Nummer 1 (Help-Center-Beschränkungen): Verweis auf geschlossene oder beschränkte Help Center hinzugefügt, um an die Produktfunktionen anzugleichen
- Nummer 5 (@Erwähnungen): Option zum Deaktivieren von @Erwähnungen zur Anpassung an das Produkt hinzugefügt für mehr Funktionalität sorgen
-
Abschnitt III, Messaging:
- Nummer 1 und 2 (Drittanbieterkanäle und private Anhänge): Zur übersichtlicheren Darstellung wurdenAbschnittskennungen (i) und (ii) hinzugefügt
- Nummer 2 (private Anhänge): „URLs und/oder“ zur Klarstellung hinzugefügt
- Nummer 7-10 (Endbenutzer-Authentifizierung, Löschung von Answer-Bot-Konversationen, Schwärzung, Malware-Scanning): Aus Gründen der Transparenz wurden vollständige Abschnitte hinzugefügt
- Abschnitt IV. Sunshine Conversations: ganzer Abschnitt hinzugefügt, da Sunshine Conversations in der Zendesk Suite Teil der BAA wird
- Abschnitt V, Chat, Nummer 3 (Arbeitsbereich für Agenten): kleine Formulierungskorrekturen
- Abschnitt achten, Mobile Anwendungen, Nummer 5-7 (Malware-Scanning, Schwärzung, Endbenutzer-Authentifizierung): ganze Abschnitte aus Transparenzgründen hinzugefügt
24. Februar 2023
- Abschnitt I. Support, Nummer 3: die separate Unterscheidung zwischen IP-Beschränkungen für Support und Chat wurde entfernt, da die Benutzeroberfläche jetzt vereinheitlicht ist.
- Abschnitt I. Support, Nummer 5: Klarstellung im Fall der Nichterfüllung der Anforderung hinzugefügt
- Abschnitt I. Support, Nummer 7: „Abonnent darf nicht“ geändert in „Abonnent nicht“.
- Abschnitt IV. Chat, Nummer 2: stellt klar, dass jegliche Exportfunktion von Daten aus Chat per E-Mail verboten ist und sich nicht nur auf Protokolle und Piping beschränkt.
- Abschnitt III. Messaging: gesamter Abschnitt hinzugefügt, um die Zendesk Messaging-Funktionalität über den Umfang der Zendesk-Geschäftspartnervereinbarung hinaus zu berücksichtigen.
9. Juli 2021
- Fügt Punkt 3 im Chat-Abschnitt für Verantwortlichkeiten im Zusammenhang mit der Nutzung des Arbeitsbereich für Agenten hinzu.
21. Januar 2021
- Durch Hinzufügen von Nummer 1.11 wird keine CSAT zugelassen, es sei denn, der Abonnent übernimmt die Verantwortung für die Daten, die im Rahmen der Umfrage per E-Mail gesendet werden.
- Vorbehalt in Nummer 1.7, um zu berücksichtigen, dass Abonnenten die Anzeigeberechtigungen ändern, weil Benutzer bereits die Genehmigung zum Zugriff auf diese Daten erhalten haben.
- Gesamtes Dokument aktualisiert, damit es dem Unternehmensstil der eingebetteten Links im Text entspricht ( statt Inline-URLs) (keine Auswirkung auf Konfigurationsinhalte).
August 2020
- Explore Enterprise bietet jetzt zusätzliche Funktionen zum Teilen von Dashboards
- Aufhebung der Sperre für Chat-Anhänge (Support Authentifizierungsanforderungen jetzt erfüllt)
- Es ist klar, dass das Verbot von ePHI in angepassten Feldern speziell für die Nutzung von Insights gilt, nicht global
- Ein neuer Abschnitt über Add-ons für bereitgestellte Dienste wurde hinzugefügt, wobei „Nebenkonversationen“ die erste Wahl ist
- Verschiedene Grammatik-/Formatierungsänderungen (die sich nicht auf den Inhalt auswirken)
13. Juli 2020:
- Begriffsklärung bezüglich der Nutzung von SMS über den Dienst im Gegensatz zur nativen Nutzung von SMS für produktintegrierte 2FA. * Zur Klarstellung: Die in Abschnitt 10 zu SMS genannten Vorbehalte zu ePHI gelten nicht für die produktintegrierte Nutzung der 2FA (siehe Abschnitt 1.a), da diese Funktion lediglich eine numerische Zeichenfolge zur Identitätsprüfung sendet.
13. Dezember 2019
- ermöglicht den Verzicht auf Agenten-IP-Beschränkungen, wenn der Anwendungsfall dies nicht zulässt, solange MFA für den Agentenzugriff durchgesetzt wird.
17. Dezember 2019
- lässt Kommentare von Endbenutzern in Guide zu, solange Agenten diese Kommentare moderieren und alle PHI-Kommentare entfernen.
6. November 2019
- Beitrag aktualisiert, um die Änderung widerzuspiegeln, dass Abonnenten nach eigenem Ermessen auf eine bestimmte Konfiguration verzichten oder sie ersetzen können, solange sie die Verantwortung für diese Entscheidung übernehmen.
„Versäumt es ein Abonnent, eine bestimmte unten aufgeführte Konfiguration oder eine Reihe erforderlicher Konfigurationen unten zu implementieren und einzuhalten, ahnden wir als
auf eigenes Risiko und nach alleinigem Ermessen des Abonnenten; und ein solches Versäumnis entbindet Zendesk und seine Mitarbeiter, Agenten und verbundenen Unternehmen von jeglicher Verantwortung im Hinblick auf den unbefugten Zugriff auf oder die unsachgemäße Verwendung oder Offenlegung der Servicedaten des Abonnenten, einschließlich aller elektronischen geschützten Gesundheitsdaten, infolge eines solchen Versäumnisses durch den Abonnenten . "
-
Weitere Änderungen:
- 1. die Fähigkeit zur Nutzung von SMS, solange der Abonnent selbst dafür verantwortlich ist, sicherzustellen, dass keine personenbezogenen Gesundheitsinformationen in solchen Übertragungen enthalten sind.
- 2. Die Möglichkeit, Anhänge in Chat zu verwenden, solange der Abonnent die gesamte Verantwortung dafür trägt, dass in diesen Anhängen keine personenbezogenen Gesundheitsinformationen enthalten sind.
6. März 2019
- aktualisiert, um Einstellungen für Zendesk Explore hinzuzufügen
17. Januar 2019
- aktualisiert, damit in Chat keine Anhänge mehr zulässig sind.
Hinweis zur Übersetzung: Dieser Beitrag wurde mit automatischer Übersetzungssoftware übersetzt, um dem Leser ein grundlegendes Verständnis des Inhalts zu vermitteln. Trotz angemessener Bemühungen, eine akkurate Übersetzung bereitzustellen, kann Zendesk keine Garantie für die Genauigkeit übernehmen.
Sollten in Bezug auf die Genauigkeit der Informationen im übersetzten Beitrag Fragen auftreten, beziehen Sie sich bitte auf die englische Version des Beitrags, die als offizielle Version gilt.
Bearbeitet 28. Jan. 2025 · Craig Lima
0
Follower
1
Stimme
0
Kommentare
Craig Lima hat einen Kommentar hinterlassen
July 9th 2021 edit:
1. Adds point 3. under Chat section for responsibilities around Agent Workspace usage.
Kommentar anzeigen · Gepostet 09. Juli 2021 · Craig Lima
0
Follower
0
Stimmen
0
Kommentare
Craig Lima hat einen Kommentar hinterlassen
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).
Kommentar anzeigen · Gepostet 21. Jan. 2021 · Craig Lima
0
Follower
0
Stimmen
0
Kommentare