Lesen Sie zuerst den letzten Abschnitt, wenn Sie Calcutab prüfen. Dort steht, was wir nicht haben: der Teil, nach dem man bei Anbietern sonst suchen muss.
Diese Seite ist für die Person geschrieben, die uns freigeben muss. Sie beschreibt, was tatsächlich gebaut ist, nicht was geplant ist.
Das Entscheidende: Ihre Daten können keine andere Kundin erreichen
Jeder Datensatz trägt den Arbeitsbereich, zu dem er gehört, und jede Abfrage ist darauf eingegrenzt. Das ist die gewöhnliche Antwort, und für sich genommen ist sie nur so gut wie die Entwicklerin, die zuletzt eine Abfrage geschrieben hat.
Deshalb erzwingt es die Datenbank zusätzlich. Zeiteinträge, Sätze, Jira-Zugangsdaten und Abschlüsse verweisen über einen zusammengesetzten Fremdschlüssel aus (id, Arbeitsbereich) auf ihren Elterndatensatz. Postgres selbst weist eine Zeile zurück, die in den Arbeitsbereich einer anderen Kundin zeigt: keine WHERE-Klausel, die jemand vergessen kann, sondern eine Einschränkung, die den Fehler unspeicherbar macht.
Drei der unten genannten automatischen Prüfungen bestehen, um genau das zu belegen, indem sie es versuchen.
Zugriff und Geld
Vier Stufen: Plattformbetreiber, Inhaberin des Arbeitsbereichs, Führungskraft, Mitglied. Jede Seite und jede Aktion prüft serverseitig. Einen Menüpunkt zu verbergen ist keine Zugriffskontrolle, und wir behandeln es nicht als solche; die Prüfungen laufen auch dann, wenn der Link nie gezeigt wurde.
Geld wird weggelassen, nicht verborgen. Ein Mitglied sieht keine Kosten, auch nicht den eigenen Satz. Die Zahlen werden gar nicht erst an seinen Browser gesendet, es gibt also im Quelltext nichts zu finden.
Zugangsdaten und Geheimnisse
| Was | Wie es gehalten wird |
|---|---|
| Jira-API-Token, Slack-Token | AES-256-GCM, verschlüsselt bevor sie die Datenbank erreichen, versioniert, damit Schlüssel rotiert werden können. Werden nie über die letzten vier Zeichen hinaus zurückgegeben, nie protokolliert, nie in eine Protokollzeile geschrieben |
| Passwörter, wo ein Arbeitsbereich sie nutzt | Gesalzenes scrypt, mit dem Kostenfaktor neben jedem Hash, damit er erhöht werden kann. Nie wiederherstellbar, weder durch uns noch durch sonst jemanden |
| Einladungs- und Passwort-Links | Gespeichert wird nur der SHA-256 des Tokens. Eine entwendete Datenbank vervollständigt keines von beidem |
| Der Verschlüsselungsschlüssel selbst | Google Secret Manager, nie im Repository |
Die meisten Arbeitsbereiche haben überhaupt kein Passwort: die Anmeldung läuft über Google oder Atlassian, es gelten also die Zwei-Faktor- und Offboarding-Regeln des jeweiligen Anbieters, und bei uns gibt es nichts zu verlieren.
Auf dem Transportweg und im Browser
Der gesamte Verkehr läuft über TLS. Sitzungs-Cookies sind Secure, HttpOnly, SameSite=Lax.
Jede Seite trägt eine pro Anfrage erzeugte Content-Security-Policy mit einem frischen Nonce; Skripte werden über den Nonce erlaubt, nicht über unsafe-inline. frame-ancestors steht auf none, die Anwendung kann also nicht in einen Rahmen gesetzt werden.
Was aufgezeichnet wird
Ein nur anfügbares Änderungsprotokoll: Satzänderungen, Änderungen an Mitgliedschaften, Einstellungen, Periodenabschlüsse und jede Zeiterfassung, die für jemand anderen bearbeitet wurde, mit wer, was, von was zu was und wann. Als CSV exportierbar.
Sätze werden nie bearbeitet. Eine Änderung fügt eine Zeile mit neuem Startdatum ein, sodass ein im Vorjahr erstellter Bericht weiterhin die Zahl des Vorjahres liefert.
Missbrauch
Schreibvorgänge und Anmeldeversuche sind ratenbegrenzt. Acht aufeinanderfolgende fehlgeschlagene Passwortversuche sperren ein Konto für fünfzehn Minuten, allerdings nur bei Passwörtern, denn eine Sperre der Google- und Atlassian-Wege würde es jedem erlauben, einer Kollegin den Zugang zu verwehren, indem er ihre Adresse errät.
Wo Ihre Daten liegen
Google Cloud Run in europe-west1 (Belgien); PostgreSQL bei Neon in AWS eu-central-1 (Frankfurt). Sicherungen bleiben in der EU. Die vollständige Liste der Unterauftragsverarbeiter steht im [AVV](/legal/dpa), Abschnitt 7; es ist die ganze Liste, und sie zu ändern ändert jenes Dokument.
Vor jeder Freigabe geprüft
Vierzehn automatische Prüfungen laufen gegen eine echte Bereitstellung, nicht gegen eine Attrappe, und decken ab:
- eine Führungskraft, die in Mitgliedschaften, Projekte, Berichte und CSV-Exporte eines anderen Arbeitsbereichs greift
- ein Mitglied, das die Satzkarte, den Protokollexport oder die Betreiberseite erreicht
- eine mit dem falschen Schlüssel signierte Sitzung
- unauthentifizierter Zugriff auf Seiten, die eine Anmeldung verlangen
- Stacktraces, Bereitstellungsdetails und Policy-Header
Das Skript weigert sich überhaupt zu laufen, solange nicht zuerst eine erzeugte Sitzung akzeptiert wird: Eine frühere Fassung meldete elf bestandene Prüfungen gegen das, was sich als leere Weiterleitungs-Antworten herausstellte, und das ist die Art Ergebnis, die schlimmer ist als gar keines.
Daneben: 936 Unit-Tests, 233 End-to-End-Tests gegen einen echten Browser und eine echte Datenbank sowie 216 Integrationstests.
Wenn etwas schiefgeht
Ein schriftlicher Störungsprozess regelt, wer in welcher Reihenfolge und innerhalb welcher Frist informiert wird. Zustands- und Fehleralarme erreichen den Betreiber, wenn der Dienst oder seine Datenbank aus zwei Regionen nicht mehr erreichbar ist.
Melden Sie eine Schwachstelle an support@calcutab.com. Wir bestätigen den Eingang innerhalb eines Werktags. Eine Prämie bieten wir derzeit nicht.
Was wir nicht haben
Hier genannt, statt es Sie entdecken zu lassen:
- Kein unabhängiger Penetrationstest. Die obigen Prüfungen sind unsere eigenen. Ein Test durch Dritte wird beauftragt, sobald eine Kundin den Bericht braucht; wir werden nicht so tun, als gäbe es ihn schon.
- Kein SOC 2 und kein ISO 27001. Beides ist nicht in Arbeit. Beides ist ein Jahr Arbeit und ein fünfstelliger Betrag, und wir sagen das lieber, als etwas anderes anzudeuten.
- Keine Rufbereitschaft. Die Alarmierung erreicht eine Person. Außerhalb der Arbeitszeit hängt die Wiederherstellung an dieser Person.
- Keine vertragliche Zusage zu Verfügbarkeit oder Wiederherstellungszeit. Das sagen auch die Nutzungsbedingungen.
- Keine kundenverwalteten Schlüssel, kein SAML, kein SCIM. OIDC je Arbeitsbereich ist machbar und ungebaut; SAML bräuchte einen Broker. Heute existiert keines von beidem.
- Die Rechtsdokumente wurden nicht von externen Anwälten geprüft. Sie sind als Version 1.0 veröffentlicht und beschreiben, was die Software tatsächlich tut; ihre rechtliche Tragfähigkeit in Ihrer Rechtsordnung haben wir nicht prüfen lassen.
Wenn eines davon für Sie ein Ausschlusskriterium ist, sagen Sie es; es ist besser, das vor dem Kauf zu wissen als danach.