Wat geavanceerde versleuteling doet

Advanced encryption zet specifieke gebruikersvelden onder een sleutel die je zelf houdt, en er zitten beperkingen aan die je vooraf wilt weten.

Advanced encryption zet specifieke gebruikersvelden onder een sleutel die je zelf houdt, en er zitten beperkingen aan die je vooraf wilt weten.

Wat je al hebt zonder deze add-on

Elk Zendesk-account versleutelt servicegegevens in rust in AWS met AES-256, en alles onderweg loopt over HTTPS met TLS 1.2 of hoger. Deze add-on is dus niet het verschil tussen versleuteld en niet versleuteld, en voor het invullen van een vragenlijst heb je hem zelden nodig.

Wat er wél verandert

Wie de sleutel heeft. Met eigen sleutels wordt de data versleuteld tegen een sleutel in jouw eigen key management service in plaats van tegen een sleutel die alleen Zendesk beheert. Je kunt AWS KMS, Azure Key Vault, Google Cloud KMS of Thales CipherTrust Manager gebruiken; die laatste is degene om naar te kijken als de eis is dat de sleutel bij een Europese aanbieder blijft.

Wat het dekt, en wat niet

Het versleutelt gebruikersvelden: naam, alias, handtekening, gegevens, notities, e-mailadres en identiteiten uit sociale kanalen, in Support, knowledge en voice.

Het versleutelt de ticketinhoud niet. Bij e-mail is alleen het adres gedekt: de onderwerpregel, de tekst en de HTML-bron niet. Is je reden om dit te willen het beschermen van wat klanten je hebben geschreven, dan doet deze add-on dat niet.

Twee plekken bewaren de gedekte velden alsnog in leesbare vorm, en allebei verdienen ze een naam voordat iemand hiervoor tekent. De gebruikersdatasets van Explore staan onversleuteld, en bestanden van bulkimport en -export staan dertig dagen leesbaar voordat ze worden verwijderd. Een maatregel die bij de database ophoudt, houdt niet op bij het werkblad.

De waarschuwing die er het meest toe doet

Wat het verder blokkeert

• Sandboxen. Er een aanmaken kan niet zolang dit aanstaat. Zendesk vraagt je het eerst in een sandbox te beproeven voordat je het in productie aanzet, dus maak die sandbox eerst aan of je hebt er geen.
• Tickets delen. Wordt niet ondersteund.
• Zoeken. Zoeken met jokertekens en op woordgroepen wordt slechter over de versleutelde velden, en dat merken agenten voordat iemand hun uitlegt waarom.
• Triggers voor berichten met een voorwaarde op de naam van een eindgebruiker werken niet meer.
• Je account naar een andere regio verplaatsen. Een versleuteld account komt daar niet meer voor in aanmerking, dus vraag die verhuizing eerst aan als hij er ooit komt.

Waar het niet tegen beschermt

Tegen alles wat via de gewone interface gebeurt. Een agent die een ticket kan openen leest het; een gekaapt agentaccount komt nog steeds overal waar dat account bij kon. De meeste echte incidenten zijn van dat type, dus dit is een maatregel naast goede toegangshygiëne en niet in plaats daarvan.

Bepalen of je het nodig hebt

Sleutelbeheer hoort bij wie dat elders in je organisatie ook doet, normaal gesproken IT-security en niet een supportbeheerder. Controleer vóór aanschaf of de velden die het dekt ook de velden zijn die je verplichting noemt, want daar valt het het vaakst tegen.

Overleg met ons voordat je begint. De inrichting heeft gevolgen die lastig terug te draaien zijn, en de beperkingen hierboven accepteer je makkelijker vóórdat je er iets omheen hebt gebouwd.

Zie ook

• Geavanceerde versleuteling inrichten
• Wat de add-on Advanced Data Privacy and Protection je geeft