Datensicherheit und Mandantentrennung

Diese Seite beschreibt, wie die App die Daten eines Kontos von allen anderen Konten trennt, welche Rolle was darf, wie Personenbezogenes in Gesprächen maskiert wird, wer den Klartext sehen kann, wie Schlüssel abgelegt werden und welche Ziele ausgehende Abrufe erreichen dürfen. Sie richtet sich an Inhaber und Verwaltung eines Kontos.

Trennung der Konten

Jedes Konto ist ein eigener Mandant. Die Trennung liegt in der Datenschicht und nicht in einzelnen Bildschirmen: Jede Abfrage auf kontobezogene Daten wird auf das Konto der laufenden Anfrage beschränkt, und neue Datensätze erhalten dieses Konto selbsttätig. Steht kein Konto fest, liefert die Abfrage keine Zeilen, statt über Kontogrenzen hinweg zu lesen.

Woher das Konto einer Anfrage kommt, hängt vom Zugangsweg ab:

Der Status wird bei jeder Anfrage neu geprüft. Wird ein Konto gesperrt, endet der Zugriff damit auch für Sitzungen, die bereits offen sind. Die App zeigt dann „Dieses Konto ist gesperrt. Bitte schreiben Sie an mail@xicbot.de.“ Eine neue Anmeldung in ein nicht aktives Konto wird mit 403 abgewiesen und unter Letzte Anmeldungen mit dem Ergebnis gesperrt erfasst. Diese Liste zeigt höchstens 50 Einträge, die neuesten zuerst; mehr unter Konto und Sicherheit.

Rollen und Berechtigungen

Die Rollen haben eine Rangfolge. Eine Funktion verlangt eine Mindestrolle, und jede höhere Rolle darf sie ebenfalls. Die Rolle Inhaber wird in der Teamverwaltung nicht vergeben. Wie Rollen vergeben werden, steht unter Team und Rollen.

Für die Themen dieser Seite gelten diese Mindestrollen:

Fehlt eine verlangte Bestätigung der E-Mail-Adresse, antwortet die Schnittstelle mit 403 email_unverified. Fehlt die Rolle, antwortet sie mit 403 role_too_low und nennt die verlangte Rolle im Feld required, bei der Adresse für die Übergabe zusätzlich handoff_email im Feld field. Die App zeigt je nach verlangter Rolle eine eigene Meldung:

Zwischen Konten wechseln

Wer zu mehreren Konten gehört, wechselt über Konto wechseln. Die Rolle gilt je Konto: Nach dem Wechsel arbeiten Sie mit der Rolle, die Sie im Zielkonto haben. Ein Konto, das es nicht gibt, und ein Konto, zu dem Sie nicht gehören, ergeben dieselbe Antwort 404 not_found. An der Antwort lässt sich also nicht ablesen, ob ein fremdes Konto existiert. Ein gesperrtes Zielkonto ergibt 403 mit tenant_ und dem Status. Der Wechsel ist auch aus einem gesperrten Konto heraus möglich.

Ein Wechsel steht in der Regel im Protokoll als tenant.switched, mit dem vorherigen Konto und der Rolle im neuen Konto. Während einer Übernahme durch den Betreiber ist der Wechsel gesperrt. Mehr zu mehreren Konten unter Team und Rollen.

Anmeldung und Sitzungen

Jede Anmeldung erhält eine eigene Anmeldemarke mit 30 Tagen Laufzeit. Die App legt sie im Speicher des Browsers (localStorage) unter xicbot.marke ab. Beim Abmelden wird nur die Marke dieses Geräts gelöscht; Anmeldungen auf anderen Geräten bleiben bestehen.

• Die Geräteliste zeigt die gültigen Anmeldungen, höchstens 50, die neuesten zuerst. Abgelaufene Marken erscheinen dort nicht mehr.
• Jede Anmeldung außer der eigenen lässt sich mit Beenden einzeln beenden, mit Alle anderen beenden alle zugleich. Sitzungen einer Übernahme durch den Betreiber bleiben bei Alle anderen beenden bestehen; sie lassen sich einzeln beenden. Auch API-Schlüssel bleiben gültig; ihre Zahl steht in der Regel im Protokolleintrag account.sessions_ended.
• Beim Ändern des Kennworts werden Sitzungen beendet; wie viele, steht in der Regel im Protokolleintrag account.password_changed.
• Anmelden, Abmelden, das Beenden einzelner und aller anderen Sitzungen erscheinen in der Regel im Protokoll als account.login, account.logout, account.session_ended und account.sessions_ended. Endet dabei eine Übernahme durch den Betreiber, weil sie mit Beenden in ihrer Zeile beendet oder aus ihr heraus abgemeldet wird, steht stattdessen impersonation.end im Protokoll, siehe Übernahme durch den Betreiber.

Maskierung in Gesprächen

Gespräche werden so gespeichert, wie sie geführt wurden. Maskiert wird bei der Ausgabe: Die App zeigt personenbezogene Angaben durch Platzhalter ersetzt und vermerkt im Gespräch „Personenbezogenes ist maskiert: E-Mail, Telefon, IBAN und Anschrift.“ Welche Arten ein Gespräch enthält, liefert die Schnittstelle im Feld masked_kinds.

Die Platzhalter erscheinen in deutscher Form, auch in der englischen Oberfläche. Lässt sich ein Text nicht prüfen, steht an seiner Stelle [nicht maskierbar]: Im Zweifel wird maskiert. Maskiert erscheinen:

• der Text jeder Nachricht im Verlauf
• der Titel des Gesprächs in Liste und Ansicht
• Inhalte von Werkzeugaufrufen, ausgenommen reine Strukturfelder
• Fragen in der Auswertung, dort zusätzlich auf 300 Zeichen gekürzt
• der Übergabegrund in der Ansicht des Gesprächs
• die Frage in gap.detected und der Grund in handoff.triggered, die an Ihre Webhooks gehen, siehe API-Schlüssel und Webhooks
• die Werte unter Ungedeckte Angaben zu einer Antwort
• beide CSV-Dateien, siehe Ausfuhr als CSV

Nicht maskiert ist die E-Mail, die bei einer Übergabe an die Adresse für die Übergabe geht: Sie enthält die letzten bis zu 200 Nachrichten des Gesprächs im Wortlaut. Ändern kann diese Adresse nur der Inhaber.

Die Suche in der Gesprächsliste läuft für den Inhaber im Klartext, für alle anderen Rollen über den maskierten Text. Eine Suche nach einer Telefonnummer findet für diese Rollen also nichts, was sie nicht sehen dürfen. Trifft eine solche Suche auf mehr als 20.000 Gespräche, antwortet die Schnittstelle mit 422 search_too_broad; grenzen Sie dann Zeitraum oder Filter ein. Mehr unter Gespräche.

Klartext anfordern

Den Klartext eines Gesprächs fordert nur der Inhaber an. Für andere Rollen zeigt die App den Hinweis „Den Klartext kann nur der Inhaber des Kontos anfordern – mit Grund, und jeder Zugriff wird protokolliert.“

1. 1

   Schritt 1

   Gespräch öffnen

   Öffnen Sie das Gespräch unter Gespräche.

2. 2

   Schritt 2

   Klartext anfordern

   Wählen Sie Klartext anfordern.

3. 3

   Schritt 3

   Grund angeben

   Tragen Sie unter Grund für den Zugriff ein, wofür Sie den Klartext brauchen: mindestens 5, höchstens 200 Zeichen. Einen Vorgabewert gibt es nicht. Ist der Grund zu kurz, erscheint „Bitte einen Grund mit mindestens fünf Zeichen angeben.“

4. 4

   Schritt 4

   Bestätigen

   Bestätigen Sie mit Klartext anzeigen. Das Gespräch erscheint ohne Maskierung, darüber steht „Klartext sichtbar – dieser Zugriff ist protokolliert.“

Die Rolle wird bei jeder Anforderung erneut geprüft. Der Klartext gilt nur für diese Ansicht: Wird das Gespräch neu geladen, erscheint es wieder maskiert, und ein weiterer Zugriff braucht einen neuen Grund. Fehlt die Rolle inzwischen, meldet die App „Den Klartext kann nur der Inhaber des Kontos anfordern.“

Liste der Klartextzugriffe

Jedes Gespräch führt unter Klartextzugriffe die letzten 20 Zugriffe mit Zeitpunkt, E-Mail-Adresse der Person und Grund. Die Liste sieht jede Rolle, die das Gespräch öffnen kann. Gab es noch keinen Zugriff, steht dort Bisher kein Klartextzugriff.

Ausfuhr als CSV

Die App bietet zwei CSV-Dateien an, beide mit maskierten Inhalten. Jede Ausfuhr erzeugt vor der Ausgabe den Protokolleintrag conversation.exported. Er hält fest, ob im Klartext ausgeführt wurde, den Grund und die Zahl der Zeilen, dazu bei der Liste den verwendeten Filter und beim einzelnen Gespräch, ob gekürzt wurde. Scheitert dieser Eintrag bei einer Ausfuhr im Klartext, wird keine Datei ausgegeben; eine maskierte Ausfuhr läuft weiter, weil sie nichts offenlegt.

• Der Name der Einzeldatei enthält nur die Kennung des Gesprächs, keinen Titel.
• Beginnt ein Feld mit =, +, -, @ oder einem Tabulator, wird ein Apostroph vorangestellt. So wertet eine Tabellenkalkulation den Inhalt nicht als Formel aus.
• Zeilenumbrüche innerhalb eines Felds werden durch Leerzeichen ersetzt. Trennzeichen ist das Semikolon.
• In conversations.csv erscheinen Titel und Übergabegrund maskiert.

Über die Schnittstelle kann der Inhaber eine Ausfuhr im Klartext abrufen, mit den Parametern reveal=1 und reason (5 bis 200 Zeichen). Ohne Rolle Inhaber lautet die Antwort 403 role_too_low, ohne ausreichenden Grund 422 reason_required. Enthält Ihr Paket die Ausfuhr nicht, antworten Liste und Einzeldatei mit 402 plan_feature_missing, auch ohne Klartext. Die Antwort trägt die Köpfe x-rows (Zahl der Zeilen), x-masked (1 maskiert, 0 Klartext) und bei der Einzeldatei x-capped (1, wenn gekürzt). Die App lädt ausschließlich maskiert herunter. Mehr unter Gespräche und API: Gespräche und Verwaltung.

Übernahme durch den Betreiber

Um bei Fragen im Konto zu helfen, kann der Betreiber von XICBOT ein Konto übernehmen. Übernommen wird der ranghöchste Zugang, der gerade in diesem Konto arbeitet: zuerst Inhaber, dann Verwaltung, Bearbeiten und Lesen, bei gleicher Rolle der älteste. Ein Mitglied, das gerade in einem anderen Konto arbeitet, zählt dabei nicht mit. Das Kennwort dieses Zugangs wird dabei weder gelesen noch geändert. Die Übernahme läuft über eine eigene Anmeldemarke mit 4 Stunden Laufzeit. Der Betreiber startet sie mit Konto übernehmen und kann unter Grund der Übernahme einen Grund mit bis zu 200 Zeichen angeben. Der Beginn steht mit Grund und Ablaufzeit im Aktionsprotokoll des Betreibers und im Protokoll Ihres Kontos; kommt einer der beiden Einträge nicht zustande, beginnt die Übernahme nicht. Auch das Ende steht in der Regel in beiden Protokollen: wenn der Betreiber die Übernahme mit Übernahme beenden schließt oder sich darin abmeldet, wenn Sie sie in der Geräteliste beenden und wenn sie endet, weil alle Sitzungen des Zugangs enden, etwa beim Zurücksetzen des Kennworts über den Link, wenn der Betreiber die zweite Stufe zurücksetzt oder wenn der Zugang aus dem Team entfernt wird. Ebenso endet eine laufende Übernahme, wenn der übernommene Zugang selbst in ein anderes Konto wechselt; ihr Ende steht dann in der Regel im Protokoll des Kontos, in dem sie begann, und im Aktionsprotokoll des Betreibers. Beenden beide Seiten die Übernahme zugleich, steht das Ende nur einmal in jedem Protokoll. Nur wenn sie nach 4 Stunden von selbst abläuft, entsteht kein Eintrag zum Ende; die Ablaufzeit steht dann im Eintrag zum Beginn. Ein Konto ohne Zugang lässt sich nicht übernehmen.

• In der Geräteliste des übernommenen Zugangs erscheint die Sitzung als Übernahme durch den Betreiber. Mit Beenden lässt sie sich dort vorzeitig beenden; Alle anderen beenden lässt sie bestehen.
• Was während der Übernahme geändert wird, erscheint im Protokoll des Kontos unter dem übernommenen Zugang.
• Die Schnittstelle meldet eine laufende Übernahme bei der Abfrage des eigenen Zugangs im Feld impersonation, mit der E-Mail-Adresse des Betreibers (operator) und der Ablaufzeit (expires_at).

Während einer Übernahme sind Funktionen gesperrt, mit denen sich der Zugang aussperren oder schwächen ließe. Die Schnittstelle antwortet dort mit 403 in_impersonation. Die Sperre gilt nur für Anfragen aus der Übernahme; Ihre eigenen Sitzungen betrifft sie nicht:

Der Betreiber sieht während der Übernahme in der Statusleiste Übernahme mit seiner Adresse, ein Vorleseprogramm hört „Sie arbeiten im Konto eines Kunden.“; beendet wird sie mit Übernahme beenden. Dabei wird die Anmeldemarke der Übernahme gelöscht; ohne Beenden läuft sie nach 4 Stunden ab. Ein Aufruf zum Beenden ohne laufende Übernahme ergibt 400 no_impersonation.

Kennwörter, Schlüssel und Geheimnisse

• Je Konto sind höchstens 10 API-Schlüssel zugleich aktiv. Darüber antwortet die Schnittstelle mit 422 too_many_keys, die App mit „Die Höchstzahl gleichzeitiger Schlüssel ist erreicht.“
• Der API-Schlüssel gehört in den Kopf X-Api-Key. Steht er als Parameter api_key oder key in der Adresse, lautet die Antwort 400 key_in_url. Fehlt der Kopf oder beginnt sein Wert nicht mit xbot_, lautet sie 401 key_missing.
• Unbekannte, widerrufene und abgelaufene Schlüssel ergeben dieselbe Antwort 401 invalid_key. Die Antwort verrät also nicht, ob ein Schlüssel einmal gültig war.

Anlegen und Widerrufen von Schlüsseln steht unter API-Schlüssel und Webhooks und API-Anmeldung, die Shop-Anbindung unter Katalog und Shop.

Ausgehende Abrufe

Mehrere Funktionen rufen Adressen außerhalb von XICBOT ab: Webhooks, Werkzeuge mit eigener Schnittstelle, Website-Quellen im Wissen, die Shop-Anbindung und Quellen, die über die Schnittstelle angelegt werden. Für alle gilt dieselbe Zielprüfung:

• Erlaubt sind Adressen mit http oder https.
• Der Name wird für IPv4 und IPv6 aufgelöst. Jede gefundene Adresse muss im öffentlichen Netz liegen; private, verbundlokale, reservierte und Loopback-Bereiche sind gesperrt. IPv4-Adressen in IPv6-Schreibweise werden ebenso geprüft.
• Geprüft wird beim Speichern. Webhooks, Werkzeuge, Website-Quellen und die Shop-Anbindung werden unmittelbar vor jedem Abruf erneut geprüft.
• Webhooks und Werkzeuge verbinden sich nur mit den eben geprüften Adressen und folgen keiner Umleitung.
• Website-Quellen folgen Umleitungen, prüfen aber jedes neue Ziel einzeln.

Beim Speichern lautet die Antwort 422 mit einem der folgenden Gründe im Feld error. Im Bereich Schnittstellen zeigt die App für alle vier Gründe „Diese Adresse ist als Ziel nicht zugelassen.“ Unter Auslöser › Werkzeuge nennt sie den Grund am Feld Adresse der Schnittstelle, etwa „Der Name dieser Adresse lässt sich nicht auflösen. Bitte prüfen Sie die Schreibweise.“; alle Sätze dort stehen unter Welche Adressen erlaubt sind. In der Zustellliste eines Webhooks und beim Probeversand erscheinen die einzelnen Meldungen:

Fristen und Größen

Ein Werkzeug mit eigener Schnittstelle sendet seine Anfrage als POST mit JSON. Die Frist beträgt 8 Sekunden; der Wert deadline_s eines Werkzeugs wird auf 1 bis 20 Sekunden begrenzt, der Verbindungsaufbau auf höchstens 5 Sekunden. Antworten über 64 KiB werden abgebrochen. Ist ein Zugangsschlüssel hinterlegt, geht er als Authorization: Bearer mit. Webhooks haben ebenfalls eine Frist von 8 Sekunden. Mehr unter Werkzeuge und Wissen.

Fehlerantworten

Fehlerantworten der Schnittstelle enthalten keine internen Angaben wie Art der Ausnahme, Datei, Zeile oder Aufrufkette. Bei Statuscodes ab 500 wird ein mitgelieferter Text durch „Serverfehler“ ersetzt; eine Antwort ohne Text erhält keinen, not_logged lautet etwa nur {"error":"not_logged"}. Meldungen zu Eingabefehlern mit Statuscodes unter 500 bleiben erhalten, damit sie sich dem betroffenen Feld zuordnen lassen.

Protokoll

Das Protokoll hält fest, wer im Konto was getan hat: Jeder Eintrag enthält Zeitpunkt, Aktion, die E-Mail-Adresse der Person, den betroffenen Gegenstand und Zusatzangaben. Erfasst wird eine festgelegte Reihe von Aktionen, nicht jeder Seitenaufruf und nicht jedes Lesen. Lesen dürfen Zugänge ab der Rolle Verwaltung mit bestätigter E-Mail-Adresse. Wie die Liste aufgebaut ist und wie Sie darin filtern und blättern, steht unter Team und Rollen. Diese Aktionen erscheinen im Protokoll, jeweils unter ihrer Bezeichnung in der App:

Bei vielen Änderungen entsteht der Eintrag in derselben Transaktion wie die Änderung selbst: beim Löschen eines Gesprächs, bei Werkzeugen und Weiterleitungsregeln, bei Änderungen am Team, an Wissensquellen, Frage-Antwort-Paaren und Suchgewichten, beim Wiederherstellen eines Wissensstands, bei der zweiten Stufe, bei Sicherheitsschlüsseln und beim Sperren eines Besuchers. Lässt sich der Eintrag nicht schreiben, bleibt der bisherige Stand erhalten; beim Löschen eines Gesprächs meldet die App dann „Nicht gespeichert: Der Eintrag ins Protokoll kam nicht zustande. Bitte versuchen Sie es erneut.“ Ausgenommen sind Handlungen, die an einem Protokollfehler nicht scheitern sollen: Konto anlegen und bestätigen, die Bestätigungsmail erneut senden, anmelden und abmelden, Sitzungen beenden, das Kennwort ändern oder zurücksetzen, das Konto wechseln, eine Wissensquelle anlegen oder neu einlesen, das Wissen neu berechnen, Prüffragen und Prüfläufe ausführen sowie Anhänge von Besuchern speichern. Sie gelingen auch dann, wenn der Eintrag nicht geschrieben werden kann; der Eintrag fehlt in diesem Fall. Den Anhang eines Besuchers gibt der Dienst dagegen nur heraus, wenn der Abruf im Protokoll verzeichnet ist. Wie lange Einträge aufbewahrt werden, steht unter Aufbewahrung und Löschung.

Eine Übernahme durch den Betreiber steht mit Beginn und Ende in diesem Protokoll: als Übernahme durch den Betreiber begonnen, unter Angaben mit Grund (reason) und Ablaufzeit (expires_at), und als Übernahme durch den Betreiber beendet, unter Angaben mit ended_by: operator, wenn der Betreiber sie beendet hat, sonst customer. Endet sie, weil das Kennwort über den Link zurückgesetzt wird, der Zugang aus dem Team entfernt wird oder selbst in ein anderes Konto wechselt, nennt Angaben zusätzlich den Anlass als cause: password_reset, member_removed oder tenant_switched. Beginn und Ende hält auch das Aktionsprotokoll des Betreibers fest; eine laufende Übernahme erkennen Sie außerdem in der Geräteliste, siehe Übernahme durch den Betreiber. Was während einer Übernahme geändert wird, steht im Protokoll unter dem übernommenen Zugang.

Häufige Fragen