Hinweis: OpenID Connect wird ausschliesslich als Protokoll für die Anbindung an einen bestehenden Identity Provider des Kunden verwendet. Ein Authorization Server ist nicht Bestandteil des Lieferumfangs, kann jedoch bei Bedarf durch uns konzipiert, integriert oder konfiguriert werden. Die Anbindung an gängige Anbieter wie AGOV oder SwissID ist grundsätzlich möglich und wurde bereits erfolgreich realisiert.

Die Kapitel «Architektur», «Datenflüsse» und «Sicherheit» beschreiben AVG2 als Produkt. Betrieb und Infrastruktur liegen beim jeweiligen Betreiber. Die eingesetzten Technologien finden Sie im Kapitel «Technologie».

Alle Kantone erhalten dasselbe Docker-Image. Jeder Kanton hat eine eigene Installation mit eigener Datenbank, Unterschiede zwischen den Kantonen werden über Konfiguration gesteuert. Zwischen den Kantonen gibt es keine gemeinsamen Daten.

Bausteine

Externe Systeme

Folgende Systeme stellt der Betreiber bereit:

• Identity Provider des Kunden (OpenID Connect) für die Anmeldung
• Mailserver (SMTP) für Benachrichtigungen
• optional einen Virenscanner, der Uploads vor dem Speichern prüft

Auslieferung und Betrieb

• Datenbankänderungen werden als versionierte SQL-Skripte ausgeliefert und mit dem Werkzeug DbUpdater eingespielt, das als eigenes Image mitgeliefert wird.
• Health-Checks melden Start, Lauffähigkeit (Liveness) und Datenbankverbindung. Optional steht ein Prometheus-Endpunkt für Metriken zur Verfügung.
• Für Kubernetes liefern wir ein Helm-Chart mit.

Anmeldung und Benutzer

Die Anmeldung führt vom Browser über den Identity Provider des Kunden zum AVG2-Server. Der Server erhält vom Identity Provider die E-Mail-Adresse der Person und ordnet sie der in AVG2 erfassten Person zu. Rollen und Berechtigungen kommen aus AVG2, nicht vom Identity Provider.

Wer welche Benutzer erfasst und verwaltet, beschreibt der Abschnitt «Berechtigungsverwaltung» im Kapitel «Sicherheit». Wer sich beim Identity Provider anmeldet, ohne in AVG2 erfasst zu sein, erhält keine Rolle und damit keinen Zugriff.

Erfassung, Verarbeitung und Ausgabe

Personendaten

Zu Benutzern speichert AVG2 Name, Vorname, E-Mail-Adresse, Sprache, Rollen und Zeitpunkt der letzten Anmeldung. Adresse und Telefon sind freiwillige Angaben und werden in der Regel nicht ausgefüllt. Für Auszubildende gibt es keine Felder für Personendaten, erfasst werden nur Kennzahlen. Hochgeladene Dokumente können je nach Inhalt Personendaten enthalten.

Anmeldung und Sitzung

• Die Anmeldung läuft serverseitig über OpenID Connect mit dem Authorization Code Flow. Standardmässig nutzt AVG2 Pushed Authorization Requests, wenn der Identity Provider sie anbietet.
• Die Tokens bleiben auf dem Server im Sitzungsspeicher. Der Browser erhält nur ein Cookie mit einem Sitzungsschlüssel. Das Cookie ist HttpOnly und wird nur über HTTPS gesendet.
• Die Sitzung läuft nach Inaktivität ab (standardmässig nach 10 Minuten, durch den Betreiber einstellbar). Bei Aktivität verlängert sie sich.
• Beim Abmelden wird das Refresh-Token beim Identity Provider widerrufen.
• Die Zuordnung zur Person erfolgt über die E-Mail-Adresse aus dem Identity Provider. Voraussetzung ist, dass der Identity Provider verifizierte, eindeutige E-Mail-Adressen liefert. Dafür ist der Betreiber des Identity Providers verantwortlich.

Berechtigungsprüfung

• Der Server prüft jede API-Anfrage auf Anmeldung und Berechtigung. Ausgenommen sind nur wenige Endpunkte ohne geschützte Daten, etwa für An- und Abmeldung und Health-Checks. Massgebend ist die Prüfung auf dem Server, Prüfungen im Browser steuern nur die Anzeige.
• Jeder geschützte Endpunkt muss in der Berechtigungsverwaltung der Datenbank registriert sein. Anfragen an einen nicht registrierten Endpunkt werden abgelehnt.
• Rollen erhalten Berechtigungspakete mit einer Stufe: Lesen, Schreiben, erweitert oder Administration.
• Bei betriebsbezogenen Daten prüft der Server zusätzlich, ob die Person für diesen Betrieb berechtigt ist: über eine Rolle am Betrieb selbst oder an seiner Trägerschaft.

Berechtigungsverwaltung

Rollen und Berechtigungspakete richten wir ein. Kundenspezifische Anforderungen setzen wir bei Bedarf um. AVG2 unterscheidet zwei Rollentypen.

Rollentyp Betrieb

• Zu jedem Betrieb bzw. jeder Trägerschaft gibt es immer eine Ansprechperson. Sie ist dem Kanton offiziell bekannt und wird vom Kanton erfasst.
• Die Ansprechperson kann die Dateneingabe an Personen mit der Rolle Datenlieferant delegieren. Sie verwaltet selbst, welche Personen Zugriff auf die Applikation und auf ihren Betrieb haben.
• Für den Kanton bleibt die Ansprechperson massgebend: Sie prüft die Daten, gibt sie frei und ist für den Ablauf verantwortlich. Wie sie die Erfassung intern delegiert, liegt in ihrer Verantwortung.
• Eine Person kann mehreren Betrieben mit unterschiedlichen Rollen zugeordnet sein, z. B. bei Betrieb A als Ansprechperson und bei Betrieb B als Datenlieferant.

Rollentyp Applikation

Globale Rollen der Applikation:

• Systemadministrator: standardmässig der Support von itree, auf Wunsch auch der Kunde.
• Administrator: verantwortlich für die Konfiguration der Stammdaten.
• Sachbearbeiter: verantwortlich für die operativen Aufgaben. Oft gibt es keinen Sachbearbeiter, dann übernimmt der Administrator diese Aufgaben.
• Datenleser: Rolle für Audits.

Nutzung und inaktive Benutzer

AVG2 ist keine Applikation für die tägliche Arbeit. In der Regel fordert der Kanton die Leistungserbringer zu einem bestimmten Zeitpunkt auf, ihre Daten zu erfassen. Nach dem Erfassungszeitraum starten die Prozesse, daraus ergeben sich Rückfragen und Verfügungen. Benutzer melden sich deshalb oft monatelang nicht an, weil sie nichts aktiv tun müssen.

Ein automatisches Sperren inaktiver Benutzer ist darum nicht vorgesehen. Die Ansprechpersonen sind dem Kanton offiziell bekannt, dafür bestehen Meldeprozesse ausserhalb von AVG2. Personelle Wechsel werden deshalb organisatorisch geregelt, nicht in AVG2. Den Zeitpunkt der letzten Anmeldung sieht der Kanton in den Auswertungen.

Eingaben

• Alle Eingaben werden im Browser und auf dem Server mit denselben Regeln validiert. Der Server lehnt ungültige Daten auch dann ab, wenn der Browser umgangen wird.
• Textfelder mit HTML (z. B. E-Mail-Vorlagen, Hilfetexte) prüft der Server beim Speichern gegen eine Liste erlaubter Tags und Attribute. Die Liste ist in den Einstellungen anpassbar. Standardmässig enthält sie keine Skripte, keine eingebetteten Frames und keine Event-Handler. Links und Bildquellen sind nur mit sicheren Schemata erlaubt (z. B. https).
• Datenbankzugriffe laufen über Entity Framework Core mit parametrisierten Abfragen, auch beim Aufruf gespeicherter Prozeduren.

Dateien

• Die erlaubten Dateiendungen sind pro Dokumenttyp serverseitig festgelegt, nicht vom Browser.
• Optional prüft ein Virenscanner jeden Upload vor dem Speichern (siehe Kapitel «Architektur»).
• Lesen, Bearbeiten, Hochladen und Löschen sind pro Rolle und Dokumenttyp berechtigt. Der Server prüft dies bei jedem Zugriff, beim Download zusätzlich mit Bezug auf den Betrieb.
• Jeder Download eines Dokuments wird mit Person, Rolle und Zeitpunkt protokolliert. Ausgenommen sind Word-Vorlagen.

Nachvollziehbarkeit

• Die Stammdaten und die Daten der Betriebe speichern, wer sie wann erfasst und zuletzt geändert hat.
• Die Grundlagendaten der Betriebe werden mit Status und Begründung historisiert.
• Stammdaten werden pro Jahr eingefroren. Eingefrorene Jahre lassen sich nicht ohne Weiteres bearbeiten. Das ist gewollt: Spätere Änderungen wirken nicht rückwirkend auf frühere Jahre (Regressionssicherheit). Frühere Verfügungen und Abrechnungen bleiben damit nachvollziehbar.
• Ein Applikationsprotokoll (Serilog) schreibt in die Datenbank und als JSON auf die Konsole, mit einer Trace-ID pro Anfrage. Berechtigte Rollen sehen es in der Applikation.
• Der E-Mail-Versand wird mit Empfänger, Betreff, Status und auslösender Person protokolliert.
• Bei unerwarteten Fehlern erhält der Browser nur eine allgemeine, übersetzte Fehlermeldung. Die Details stehen nur im Protokoll.

Plattform

• Die TLS-Terminierung liegt beim Betreiber vor der Applikation.
• Mit dem Helm-Chart läuft der Container als Benutzer ohne Root-Rechte, ohne Privilege Escalation, ohne Linux-Capabilities, mit dem Seccomp-Profil RuntimeDefault und ohne Kubernetes-API-Token.
• Zugangsdaten (Datenbank, Identity Provider, SMTP) werden als Umgebungsvariablen bzw. Kubernetes-Secret übergeben, nicht im Image.

Abhängigkeiten

Für jedes Release erzeugen wir eine SBOM, die in Dependency-Track auf bekannte Schwachstellen geprüft wird (Werkzeuge siehe Kapitel «Technologie»). Die für AVG2 verantwortliche Person eines Kantons erhält Einsicht in unser Dependency-Track.

Die Übersicht zeigt, welche Dokumentation es zu AVG2 gibt, für wen sie bestimmt ist und wo sie zu finden ist.