PruvaDoku

Sicherheit

Die 13 Regeln, die die Datenbank erzwingt, der Demo-Schutz und wie ausgehende Anfragen und Weiterleitungen geprüft werden.

Versicherer kalkulieren anhand von Pruva-Zahlen, daher dürfen die Zugriffsregeln nicht davon abhängen, dass sich die App korrekt verhält. Jede Regel unten wird in Postgres mit Sicherheit auf Zeilenebene, Spaltenrechten oder Triggern erzwungen. Jede hat einen Test in der RLS-Suite, der sich als die passende Rolle anmeldet und prüft, dass die verbotene Aktion scheitert.

Die 13 Regeln

  1. Nur der Store ändert, wofür ein Arbeitsbereich bezahlt hat. Tarif, Zustand und Periodenende einer Berechtigung kann nur die Service-Rolle des Stores schreiben. Ein Inhaber, der ein Modul auf active setzen will, erhält einen Fehler.
  2. Neue Module starten locked, und ein locked Modul lässt sich nicht einschalten. Berechtigungen stehen standardmäßig auf locked. Ein Inhaber kann ein locked Modul nicht aktivieren, zum Beispiel Documents in der Demo.
  3. Messwerte schreibt nur der Dienst. Sensordaten, Risikoscores, Emissionen, CII-Bewertungen und Policen haben für angemeldete Benutzer keine Rechte zum Einfügen, Aktualisieren oder Löschen. Nicht einmal der Owner kann sie ändern.
  4. Prämienentscheidungen brauchen publish, und die prüfende Person ist festgeschrieben. Eine Prämienanpassung annehmen oder ablehnen braucht publish für Vernetzte Versicherung. Die Datenbank setzt die prüfende Person auf die Person, die die Änderung macht; eine gefälschte prüfende Person wird überschrieben.
  5. Besatzung benachrichtigen braucht publish, und Agenten können es nie. Einen Alarm als der Besatzung mitgeteilt zu markieren braucht publish für Vorausschauende Instandhaltung. Agenten werden abgelehnt, selbst wenn jemand versucht hat, es zu gewähren.
  6. Modellwerte eines Alarms sind nur lesbar. Benutzer können Status und Notiz eines Alarms aktualisieren. Schwere, Wahrscheinlichkeit und Fenster schreibt nur das Modell.
  7. Kein Zugriff bedeutet keine Zeilen. Ein locked oder ausgeschaltetes Modul oder eine Stufe none liefert null Zeilen aus jeder Tabelle dieses Moduls. Der Underwriter liest null Alarme. Alle lesen null Dokumente, solange Documents locked ist.
  8. Der Underwriter sieht nur geteilte Schiffe. In der Demo sind das 6 von 18. Siehe Schiffe teilen.
  9. Benachrichtigungen können nicht umgeschrieben werden. Benutzer können eine Benachrichtigung nur als gelesen markieren. Titel, Text oder Link zu ändern, zum Beispiel auf eine Phishing-Seite, scheitert.
  10. Audit-Einträge werden nur als Sie selbst geschrieben. Ein Eintrag muss den angemeldeten Benutzer als Akteur nennen. Einen im Namen eines Agenten oder einer anderen Person zu schreiben scheitert.
  11. Agenten haben nie publish, und Mitglieder können den Zugriff nicht ändern. Einem Agenten publish zu gewähren scheitert. Nur Inhaber und Admins können Zugriffsstufen ändern.
  12. Das Einreichen eines Berichts braucht publish und ist festgeschrieben. Einen Bericht einzureichen braucht publish für das Emissionsbuch. Die Datenbank speichert, wer ihn eingereicht hat und wann.
  13. Nur Inhaber und Admins ändern Verbindungen. Personen wählen, ob ein Konnektor an ist, das Konto und einen https-Endpunkt. Status, letzte Synchronisierung und Problemtext kommen nur vom Synchronisierungsdienst, sodass eine defekte Verbindung nicht von Hand als gesund markiert werden kann.

Demo-Modus

  • Keine externen Anfragen. Im Demo-Modus liest die App generierte Daten und ruft keinen externen Dienst auf. Die Ende-zu-Ende-Tests blockieren Anfragen an Dritte und schlagen fehl, wenn eine versucht wird.
  • In der Produktion abgelehnt. Wenn DEMO_MODE=true und NODE_ENV=production, hält die App beim Start mit einem Fehler an. Eine öffentliche Demo ohne echte Daten muss ALLOW_DEMO_IN_PROD=1 absichtlich setzen.
  • Sichtbar. Ein Banner auf jeder Seite sagt, dass es eine Demo ist, und jede Schaltfläche, die senden, veröffentlichen oder ausgeben würde, zeigt stattdessen einen Hinweis.

Ausgehende Anfragen

Jede URL, die ein Benutzer eingibt, etwa ein Gateway-Webhook oder die Adresse eines Versichererportals, läuft durch den URL-Schutz, bevor sie aufgerufen wird. Er erlaubt:

  • nur https, auf dem Standardport,
  • keinen Benutzernamen und kein Passwort in der URL,
  • kein localhost, .local, .internal und keine Hostnamen aus einem einzigen Label,
  • keine IP-Adressen in privaten oder reservierten Bereichen (IPv4 und IPv6).

Der Aufrufer prüft die aufgelöste Adresse außerdem unmittelbar vor dem Verbindungsaufbau, sodass ein Hostname, der später auf eine private Adresse zeigt, abgelehnt wird.

Sichere Weiterleitungen

Nach der Anmeldung leitet Pruva nur auf einen Pfad derselben Website weiter. Ein next-Wert wie //evil.example, eine volle URL, ein Backslash-Trick oder ein Steuerzeichen fällt auf /app zurück.

Die Store-Nachricht

Die Website signiert jeden Checkout mit HMAC-SHA256 und einem gemeinsamen Geheimnis. Die App lehnt eine falsche Signatur oder eine Nachricht ab, die älter als 5 Minuten ist. In der Produktion signiert die Website nicht mit dem eingebauten Demo-Geheimnis. Siehe Berechtigungen.

Ein Problem melden

Dies ist ein privater Build. Melden Sie Sicherheitsprobleme direkt an das Pruva-Team, nicht in einem öffentlichen Kanal.

Auf dieser Seite