# Verschlüsselung und Schlüsselmanagement

**Dokumenttyp:** Konzept
**Geltungsbereich:** Speicherung und Übertragung aller Kundendaten der PORTA-Plattform
**Version:** 1.0
**Status:** Entwurf zur internen Freigabe
**Owner:** Betrieb / DevOps
**Letzte Aktualisierung:** 02.06.2026
**Deckt ab (CACC):** 43, 44, 45, 46, 70, 71, 72

---

## 1. Verschlüsselung bei der Übertragung (in transit) (#70)

| Verbindung | Schutz |
|---|---|
| Endnutzer → `api.poweron.swiss` | HTTPS / TLS [ZU PRÜFEN: TLS 1.2 / 1.3? Ältere Versionen deaktiviert?] |
| Anwendung → Datenbank `db.poweron.swiss` | [ZU PRÜFEN: TLS/SSL auf PostgreSQL-Verbindung aktiv?] |
| Anwendung → LLM-Provider (OpenAI etc.) | HTTPS / TLS (durch Provider-APIs) |
| System-E-Mail (Azure Communication Services) | TLS |

**Vorgabe:** Alle externen Verbindungen über TLS 1.2 oder höher; ältere Protokolle deaktiviert.

## 2. Verschlüsselung im Ruhezustand (at rest) (#70)

| Datenort | Verschlüsselung |
|---|---|
| PostgreSQL-Datenbank (Infomaniak Managed DB) | [ZU PRÜFEN: At-Rest-Verschlüsselung durch Infomaniak aktiviert? Standard bei Managed Databases bestätigen] |
| VM-Speicher (Infomaniak) | [ZU PRÜFEN: Volume-Verschlüsselung] |
| Backup-/Export-Dateien (JSON) | **Aktuell unverschlüsselt** — siehe Hinweis unten |

> **Wichtiger offener Punkt:** Die JSON-Exporte aus `datenbank-handling.md` enthalten *alle* Kundendaten im Klartext und sind aktuell nicht verschlüsselt. **Massnahme:** Export-Dateien verschlüsselt ablegen (z. B. AES-256 / GPG) und Aufbewahrungsort absichern. → siehe `13_Datenaufbewahrung_Loeschung_LegalHold.md`.

## 3. Verarbeitung bei LLM-Providern (in use)

Zur KI-Verarbeitung werden Inhaltsdaten an externe LLM-Provider übermittelt (Primär: OpenAI, USA). Während der Verarbeitung liegen die Daten beim Provider. Schutzmechanismen:

- Übertragung ausschliesslich über TLS.
- Vertragliche Absicherung über AVV/DPA und (für US-Provider) EU-Standardvertragsklauseln. **[ZU PRÜFEN: Verträge abgeschlossen — siehe `17_Subunternehmer_Management.md`]**
- Zero-Data-Retention-Vereinbarung (Daten werden nicht für Provider-Training genutzt). **[ZU PRÜFEN: Enterprise-Tier / Opt-out aktiviert?]**

## 4. Schlüsselmanagement-Modelle (#43–46, #71)

Der Katalog beschreibt vier Modelle. Aktueller Stand und Angebot von PowerOn:

| Modell | Beschreibung | PowerOn-Angebot |
|---|---|---|
| **A — Kundenkontrolliert** | Schlüssel nur für vom Kunden zugelassene Nutzer/Prozesse | [ZU PRÜFEN: technisch möglich?] |
| **B — Anbieter verwaltet (Standard)** | Schlüssel im Speicher von PowerOn/Infomaniak, PowerOn verwaltet | Aktueller Stand: Infomaniak Managed Keys |
| **C — Anbieter-Speicher, Kunde verwaltet remote** | Schlüssel bei PowerOn, Verwaltung durch Kunde | [ZU PRÜFEN] |
| **D — Kunden-Schlüsselspeicher (BYOK)** | Schlüssel in kundenseitigem Key Store | [ZU PRÜFEN: BYOK angeboten?] |

**Realistische Aussage für das Assessment:** Aktuell wird Modell B (anbieterverwaltet über Infomaniak) genutzt. BYOK/kundenkontrollierte Schlüssel sind [ZU PRÜFEN: nicht / in Planung].

## 5. Schlüssellebenszyklus (#72)

Anforderungen für sichere Erzeugung, Speicherung, Archivierung, Abfrage, Verteilung, Sperrung und Löschung von Schlüsseln:

| Phase | Vorgabe | Status |
|---|---|---|
| Erzeugung | Durch Infomaniak Managed DB / etablierte Bibliotheken | [ZU PRÜFEN] |
| Speicherung | Getrennt von verschlüsselten Daten | [ZU PRÜFEN] |
| API-Keys (OpenAI etc.) | In `.env` auf dem Server, nicht im Git | Umgesetzt (Konfiguration getrennt) |
| Rotation | API-Keys bei Offboarding/Verdacht rotieren | [ZU PRÜFEN: Rotationsintervall definieren] |
| Sperrung/Löschung | Bei Vertragsende Schlüssel vernichten (Krypto-Löschung) | siehe Dok 13 |

## 6. Stand der Umsetzung / Lücken

| Thema | Status | Massnahme |
|---|---|---|
| At-Rest-Verschlüsselung DB bestätigen | [ZU PRÜFEN] | Bei Infomaniak verifizieren, dokumentieren |
| Export-Dateien verschlüsseln | Offen | AES-256/GPG einführen |
| BYOK-Angebot | [ZU PRÜFEN] | Entscheidung für regulierte Kunden |
| Schlüssel-Rotationsintervall | Offen | Festlegen |