Sicherheit als Teil jeder Plattformebene
Schutz entlang der gesamten Anfragekette
Sicherheit entsteht aus aufeinander abgestimmten Kontrollen – vom externen Zugang bis zur Verarbeitung und Speicherung.
Externer Zugriff
Nutzer, Anwendungen und Quellsysteme
Geschützter Eintritt
Gateway API, TLS und APISIX
Identität & Rechte
Keycloak, Rollen, Scopes und Datenräume
Dienste & Daten
Fachkomponenten und ihre Persistenz
Sicherheitsprinzipien
Die Sicherheitsarchitektur folgt vier grundlegenden Prinzipien:
- Zentrale Identitäten: Benutzer, technische Clients und Rollen werden an einer gemeinsamen Stelle verwaltet.
- Minimale Berechtigungen: Zugriffe werden auf den benötigten Mandanten, Datenraum, Dienst und Verwendungszweck begrenzt.
- Mehrere Schutzebenen: Gateway, Identitätsdienst, Kubernetes und Fachkomponenten prüfen jeweils den Teil der Anfrage, für den sie verantwortlich sind.
- Nachvollziehbare Änderungen: Konfiguration, Richtlinien und Bereitstellung werden versioniert; technische Signale unterstützen Prüfung und Fehleranalyse.
1. Geschützte Zugänge
Externe Zugriffe erreichen die Plattform über definierte DNS-Namen und TLS-gesicherte Endpunkte. NGINX Gateway Fabric setzt die Gateway API um; cert-manager stellt die dafür benötigten Zertifikate bereit. Für geschützte Fach-APIs übernimmt APISIX hinter dieser Eintrittsschicht die Authentifizierung und das API-spezifische Routing.
APISIX trennt den öffentlichen Endpunkt vom internen Dienst, validiert Zugriffstoken und leitet nur freigegebene Methoden und Pfade weiter. Damit bleiben interne Service-Adressen und Datenbanken außerhalb der öffentlichen Schnittstelle. Welche APIs auf diese Weise bereitgestellt werden, beschreibt der Bereich Schnittstellen.
2. Identitäten, Rollen und Datenräume
Keycloak ist die zentrale Identitäts- und Zugriffsverwaltung der UDSP. Benutzer und technische Clients erhalten signierte Token. Rollen, Scopes und mandantenspezifische Merkmale im Token bilden die Grundlage für nachgelagerte Entscheidungen in APISIX und den Fachkomponenten.
Das Rollen- und Rechtekonzept beschreibt Mandanten-Realms, direkte anwendungsspezifische Rollenzuweisungen sowie die voneinander getrennten Dataspace- und API-Zugriffe der UDSP. GeoServer, CKAN, Grafana, Superset und weitere Dienste besitzen daneben eigene Berechtigungsmodelle, die an den jeweiligen Plattformzugang angebunden werden.
3. Isolation und Richtlinien im Cluster
Innerhalb des Kubernetes-Clusters werden Plattformbereiche durch Namespaces, Service Accounts, Rollen und Secrets voneinander getrennt. Komponenten erhalten die für ihre Aufgabe benötigten Ressourcen und Berechtigungen. Wo Datenverkehr zusätzlich eingeschränkt wird, begrenzen Network Policies die erlaubten Kommunikationswege.
Kyverno prüft Kubernetes-Ressourcen gegen zentrale Richtlinien. Die Betriebsart wird über das Inventory festgelegt: Richtlinien können zunächst auswertend eingesetzt und anschließend gezielt durchgesetzt werden. Policy Reporter macht die Ergebnisse dieser Prüfungen zentral sichtbar.
Die Plattformautomatisierung erzeugt daraus kein starres Einheitsprofil. Sie stellt die Kontrollen bereit und verbindet sie mit der konkreten Auswahl aus Komponenten, Mandanten und Zielumgebung.
4. Schutz von Konfiguration und Daten
Passwörter, Tokens und private Zugangsdaten werden als Secrets behandelt und nicht als unverschlüsselte Projektkonfiguration veröffentlicht. Die konkrete Bereitstellung dieser Werte richtet sich nach dem Deployment-Prozess und der angeschlossenen Secret-Verwaltung.
Persistente Daten bleiben in den jeweils zuständigen Diensten: PostgreSQL für relationale, räumliche und zeitbezogene Daten, MinIO für Objekte sowie komponentenspezifische Speicher für Kontext-, Sensor- und Katalogdaten. Aufbewahrung, Verschlüsselung und Zugriffsschutz werden passend zur Schutzbedarfs- und Betriebsumgebung festgelegt.
Logische PostgreSQL-Backups und Velero ergänzen den präventiven Schutz um Wiederherstellbarkeit. Ein Backup gilt erst dann als wirksam, wenn Aufbewahrung, Zugriff und Restore-Verfahren gemeinsam geplant und geprüft werden.
5. Transparenz und technische Nachweise
Sicherheitsrelevante Zustände werden nicht in einem isolierten Werkzeug betrachtet. Richtlinienergebnisse, Zugriffsprotokolle, Kubernetes-Ereignisse, Metriken und Backup-Status fließen in das gemeinsame Lagebild der Plattform ein. Die Observability- und Monitoringarchitektur beschreibt, wie diese Signale gesammelt, korreliert und für Reaktionen bereitgestellt werden.