CallwiseDocs

Sicherheitsmodell

Die Regeln, die Postgres durchsetzt, unabhängig davon, was die App oder ein API-Client sendet.

Die App blendet aus, was Sie nicht nutzen können, aber das Ausblenden ist nicht der Schutz. Jede Regel unten wird von der Datenbank mit Row-Level-Security, Spaltenrechten, Triggern oder geprüften Funktionen durchgesetzt, und jede hat einen Test, der versucht, sie zu brechen (pnpm test:rls, siehe Tests).

Produkttabellen beginnen mit cw_, und jede Zeile gehört zu einem Arbeitsbereich. Der Zugriff wird von einer Funktion entschieden, cw_can_access(workspace, module, level), die von jeder Richtlinie verwendet wird.

Die Regeln

#RegelWie Postgres sie durchsetzt
1Nur die Abrechnung kann Tarif, Status, Zeitraum oder das Pool-Kontingent eines Arbeitsbereichs ändern.Angemeldete Benutzer können cw_subscriptions lesen, haben darauf aber kein Schreibrecht.
2Niemand schaltet ein Modul frei, ohne zu zahlen. Neue Module starten als locked; das Einschalten eines gesperrten Moduls schlägt fehl.Benutzer können access_state nicht schreiben; Inhaber dürfen nur enabled aktualisieren, und ein Trigger lehnt das für gesperrte Module ab.
3Das Veröffentlichen eines Skripts erfordert publish auf der Rezeption.Versionen werden nur von cw_publish_agent() angelegt, das die Stufe prüft. Direkte Schreibvorgänge auf Versionen oder den Veröffentlichungszeiger werden abgelehnt.
4Anrufdatensätze können aus der App nicht umgeschrieben werden. Nur die Prüfmarkierung und das Kennzeichen ändern sich, und als Prüfperson werden immer Sie eingetragen.Spaltenrecht nur auf den Prüffeldern; ein Trigger setzt die Prüfperson und die Zeit aus dem angemeldeten Benutzer.
5Benutzer können keine Anrufe oder Transkriptzeilen anlegen.Kein Einfügerecht. Nur der Sprachdienst schreibt sie, über den signierten Webhook.
6Ein Modul auf none oder ein ausgeschaltetes Modul liefert keine Zeilen.cw_can_access in jeder Leserichtlinie.
7Ein Arbeitsbereich sieht niemals die Daten eines anderen.cw_can_access prüft zuerst die Mitgliedschaft.
8Personen können ihre eigene Zugriffsstufe nicht anheben.Nur Inhaber und Administratoren bearbeiten den Zugriff; Administratoren können die Zeilen des Inhabers nicht anfassen.
9Auditeinträge werden nur als Sie selbst geschrieben.Die Einfügerichtlinie verlangt actor_type = 'user' und Ihre eigene Benutzer-ID; keine Aktualisierungen und keine Löschungen.
10Ein schreibgeschützter Arbeitsbereich kann nicht geändert werden.cw_can_access begrenzt jede Stufe auf view für schreibgeschützte Module.
11Das Löschen eines Anrufers und das Routing einer Telefonnummer erfordern publish.cw_erase_caller() prüft die Stufe; die Aktualisierungsrichtlinie für Telefonnummern verlangt publish.
12Notizen gehören ihrem Autor.Einfügungen müssen Ihre eigene Benutzer-ID verwenden; Sie können nur Ihre eigenen Notizen bearbeiten oder löschen.

Weitere Schutzmaßnahmen

  • Service-Role. Der Schlüssel, der diese Regeln umgeht, wird nur in einer Serverdatei verwendet (apps/web/lib/callwise/service-role.ts), für die Abrechnung und den Sprach-Webhook.
  • Sprach-Webhook. HMAC-signiert, Zeitstempel innerhalb von 5 Minuten geprüft, idempotent über die Ereignis-ID.
  • Aufnahmen. Privater Bucket; eine Datei ist nur mit view auf der Rezeption in ihrem Arbeitsbereich lesbar; keine Uploads aus der App.
  • Ausgehende Webhooks. Ziel-URLs durchlaufen eine serverseitige Prüfung, bevor etwas gesendet wird.
  • Der Demomodus kann in der Produktion nicht ohne ein ausdrückliches ALLOW_DEMO_IN_PROD=true laufen und führt niemals eine externe Anfrage aus.

Was noch nicht abgedeckt ist

Es wurde kein externes Sicherheitsaudit und kein Penetrationstest durchgeführt, und Callwise besitzt keine Compliance-Zertifizierung. Siehe Daten und Datenschutz.

On this page