From 388771fbf6d85f96b062d7d2ec2c874d9a298884 Mon Sep 17 00:00:00 2001 From: ValueOn AG Date: Wed, 3 Jun 2026 13:19:46 +0200 Subject: [PATCH] ims integrated into e-compliance --- .../informationssicherheitspolitik.md} | 0 .../02_Zugriffsmanagement_IAM_PAM.md | 0 .../03_Mitarbeitersicherheit_und_Screening.md | 0 ...rschluesselung_und_Schluesselmanagement.md | 0 .../05_Backup_und_Wiederherstellung.md | 0 ...siness_Continuity_und_Disaster_Recovery.md | 0 .../07_Incident_Response_und_Meldewesen.md | 0 .../05_betrieb}/08_Change_Management.md | 0 .../05_betrieb}/09_Patch_Management.md | 0 .../10_Schwachstellenmanagement.md | 0 .../05_betrieb}/11_Logging_und_Monitoring.md | 0 ...12_Netzwerk_und_Infrastruktursicherheit.md | 0 ...3_Datenaufbewahrung_Loeschung_LegalHold.md | 0 .../05_betrieb}/14_Exit_und_Transition.md | 0 .../15_Sichere_Softwareentwicklung_SDLC.md | 0 .../05_betrieb}/16_Kapazitaetsmanagement.md | 0 .../17_Subunternehmer_Management.md | 0 .../18_Analyse_Recht_und_BestPractice.md | 0 .../05_betrieb}/20260528_bcm_runbook.md | 0 .../20260528_datenbank-handling.md | 0 .../20260528_drittanbieter-inventar.md | 0 .../20260528_feature_release_bugfix.md | 0 .../ims/05_betrieb/neutralisierung-detail.md | 203 ++++++++++ .../ims/05_betrieb/security-overview.md | 369 ++++++++++++++++++ .../mappings/cacc-iso-crosswalk.md} | 0 25 files changed, 572 insertions(+) rename e-compliance/{Prozesse/legal/01_Informationssicherheitsrichtlinie.md => ims/02_fuehrung/informationssicherheitspolitik.md} (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/02_Zugriffsmanagement_IAM_PAM.md (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/03_Mitarbeitersicherheit_und_Screening.md (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/04_Verschluesselung_und_Schluesselmanagement.md (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/05_Backup_und_Wiederherstellung.md (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/06_Business_Continuity_und_Disaster_Recovery.md (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/07_Incident_Response_und_Meldewesen.md (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/08_Change_Management.md (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/09_Patch_Management.md (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/10_Schwachstellenmanagement.md (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/11_Logging_und_Monitoring.md (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/12_Netzwerk_und_Infrastruktursicherheit.md (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/13_Datenaufbewahrung_Loeschung_LegalHold.md (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/14_Exit_und_Transition.md (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/15_Sichere_Softwareentwicklung_SDLC.md (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/16_Kapazitaetsmanagement.md (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/17_Subunternehmer_Management.md (100%) rename e-compliance/{Prozesse/legal => ims/05_betrieb}/18_Analyse_Recht_und_BestPractice.md (100%) rename e-compliance/{Prozesse => ims/05_betrieb}/20260528_bcm_runbook.md (100%) rename e-compliance/{Prozesse => ims/05_betrieb}/20260528_datenbank-handling.md (100%) rename e-compliance/{Prozesse => ims/05_betrieb}/20260528_drittanbieter-inventar.md (100%) rename e-compliance/{Prozesse => ims/05_betrieb}/20260528_feature_release_bugfix.md (100%) create mode 100644 e-compliance/ims/05_betrieb/neutralisierung-detail.md create mode 100644 e-compliance/ims/05_betrieb/security-overview.md rename e-compliance/{Prozesse/legal/00_README_Prozessuebersicht.md => ims/mappings/cacc-iso-crosswalk.md} (100%) diff --git a/e-compliance/Prozesse/legal/01_Informationssicherheitsrichtlinie.md b/e-compliance/ims/02_fuehrung/informationssicherheitspolitik.md similarity index 100% rename from e-compliance/Prozesse/legal/01_Informationssicherheitsrichtlinie.md rename to e-compliance/ims/02_fuehrung/informationssicherheitspolitik.md diff --git a/e-compliance/Prozesse/legal/02_Zugriffsmanagement_IAM_PAM.md b/e-compliance/ims/05_betrieb/02_Zugriffsmanagement_IAM_PAM.md similarity index 100% rename from e-compliance/Prozesse/legal/02_Zugriffsmanagement_IAM_PAM.md rename to e-compliance/ims/05_betrieb/02_Zugriffsmanagement_IAM_PAM.md diff --git a/e-compliance/Prozesse/legal/03_Mitarbeitersicherheit_und_Screening.md b/e-compliance/ims/05_betrieb/03_Mitarbeitersicherheit_und_Screening.md similarity index 100% rename from e-compliance/Prozesse/legal/03_Mitarbeitersicherheit_und_Screening.md rename to e-compliance/ims/05_betrieb/03_Mitarbeitersicherheit_und_Screening.md diff --git a/e-compliance/Prozesse/legal/04_Verschluesselung_und_Schluesselmanagement.md b/e-compliance/ims/05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md similarity index 100% rename from e-compliance/Prozesse/legal/04_Verschluesselung_und_Schluesselmanagement.md rename to e-compliance/ims/05_betrieb/04_Verschluesselung_und_Schluesselmanagement.md diff --git a/e-compliance/Prozesse/legal/05_Backup_und_Wiederherstellung.md b/e-compliance/ims/05_betrieb/05_Backup_und_Wiederherstellung.md similarity index 100% rename from e-compliance/Prozesse/legal/05_Backup_und_Wiederherstellung.md rename to e-compliance/ims/05_betrieb/05_Backup_und_Wiederherstellung.md diff --git a/e-compliance/Prozesse/legal/06_Business_Continuity_und_Disaster_Recovery.md b/e-compliance/ims/05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md similarity index 100% rename from e-compliance/Prozesse/legal/06_Business_Continuity_und_Disaster_Recovery.md rename to e-compliance/ims/05_betrieb/06_Business_Continuity_und_Disaster_Recovery.md diff --git a/e-compliance/Prozesse/legal/07_Incident_Response_und_Meldewesen.md b/e-compliance/ims/05_betrieb/07_Incident_Response_und_Meldewesen.md similarity index 100% rename from e-compliance/Prozesse/legal/07_Incident_Response_und_Meldewesen.md rename to e-compliance/ims/05_betrieb/07_Incident_Response_und_Meldewesen.md diff --git a/e-compliance/Prozesse/legal/08_Change_Management.md b/e-compliance/ims/05_betrieb/08_Change_Management.md similarity index 100% rename from e-compliance/Prozesse/legal/08_Change_Management.md rename to e-compliance/ims/05_betrieb/08_Change_Management.md diff --git a/e-compliance/Prozesse/legal/09_Patch_Management.md b/e-compliance/ims/05_betrieb/09_Patch_Management.md similarity index 100% rename from e-compliance/Prozesse/legal/09_Patch_Management.md rename to e-compliance/ims/05_betrieb/09_Patch_Management.md diff --git a/e-compliance/Prozesse/legal/10_Schwachstellenmanagement.md b/e-compliance/ims/05_betrieb/10_Schwachstellenmanagement.md similarity index 100% rename from e-compliance/Prozesse/legal/10_Schwachstellenmanagement.md rename to e-compliance/ims/05_betrieb/10_Schwachstellenmanagement.md diff --git a/e-compliance/Prozesse/legal/11_Logging_und_Monitoring.md b/e-compliance/ims/05_betrieb/11_Logging_und_Monitoring.md similarity index 100% rename from e-compliance/Prozesse/legal/11_Logging_und_Monitoring.md rename to e-compliance/ims/05_betrieb/11_Logging_und_Monitoring.md diff --git a/e-compliance/Prozesse/legal/12_Netzwerk_und_Infrastruktursicherheit.md b/e-compliance/ims/05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md similarity index 100% rename from e-compliance/Prozesse/legal/12_Netzwerk_und_Infrastruktursicherheit.md rename to e-compliance/ims/05_betrieb/12_Netzwerk_und_Infrastruktursicherheit.md diff --git a/e-compliance/Prozesse/legal/13_Datenaufbewahrung_Loeschung_LegalHold.md b/e-compliance/ims/05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md similarity index 100% rename from e-compliance/Prozesse/legal/13_Datenaufbewahrung_Loeschung_LegalHold.md rename to e-compliance/ims/05_betrieb/13_Datenaufbewahrung_Loeschung_LegalHold.md diff --git a/e-compliance/Prozesse/legal/14_Exit_und_Transition.md b/e-compliance/ims/05_betrieb/14_Exit_und_Transition.md similarity index 100% rename from e-compliance/Prozesse/legal/14_Exit_und_Transition.md rename to e-compliance/ims/05_betrieb/14_Exit_und_Transition.md diff --git a/e-compliance/Prozesse/legal/15_Sichere_Softwareentwicklung_SDLC.md b/e-compliance/ims/05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md similarity index 100% rename from e-compliance/Prozesse/legal/15_Sichere_Softwareentwicklung_SDLC.md rename to e-compliance/ims/05_betrieb/15_Sichere_Softwareentwicklung_SDLC.md diff --git a/e-compliance/Prozesse/legal/16_Kapazitaetsmanagement.md b/e-compliance/ims/05_betrieb/16_Kapazitaetsmanagement.md similarity index 100% rename from e-compliance/Prozesse/legal/16_Kapazitaetsmanagement.md rename to e-compliance/ims/05_betrieb/16_Kapazitaetsmanagement.md diff --git a/e-compliance/Prozesse/legal/17_Subunternehmer_Management.md b/e-compliance/ims/05_betrieb/17_Subunternehmer_Management.md similarity index 100% rename from e-compliance/Prozesse/legal/17_Subunternehmer_Management.md rename to e-compliance/ims/05_betrieb/17_Subunternehmer_Management.md diff --git a/e-compliance/Prozesse/legal/18_Analyse_Recht_und_BestPractice.md b/e-compliance/ims/05_betrieb/18_Analyse_Recht_und_BestPractice.md similarity index 100% rename from e-compliance/Prozesse/legal/18_Analyse_Recht_und_BestPractice.md rename to e-compliance/ims/05_betrieb/18_Analyse_Recht_und_BestPractice.md diff --git a/e-compliance/Prozesse/20260528_bcm_runbook.md b/e-compliance/ims/05_betrieb/20260528_bcm_runbook.md similarity index 100% rename from e-compliance/Prozesse/20260528_bcm_runbook.md rename to e-compliance/ims/05_betrieb/20260528_bcm_runbook.md diff --git a/e-compliance/Prozesse/20260528_datenbank-handling.md b/e-compliance/ims/05_betrieb/20260528_datenbank-handling.md similarity index 100% rename from e-compliance/Prozesse/20260528_datenbank-handling.md rename to e-compliance/ims/05_betrieb/20260528_datenbank-handling.md diff --git a/e-compliance/Prozesse/20260528_drittanbieter-inventar.md b/e-compliance/ims/05_betrieb/20260528_drittanbieter-inventar.md similarity index 100% rename from e-compliance/Prozesse/20260528_drittanbieter-inventar.md rename to e-compliance/ims/05_betrieb/20260528_drittanbieter-inventar.md diff --git a/e-compliance/Prozesse/20260528_feature_release_bugfix.md b/e-compliance/ims/05_betrieb/20260528_feature_release_bugfix.md similarity index 100% rename from e-compliance/Prozesse/20260528_feature_release_bugfix.md rename to e-compliance/ims/05_betrieb/20260528_feature_release_bugfix.md diff --git a/e-compliance/ims/05_betrieb/neutralisierung-detail.md b/e-compliance/ims/05_betrieb/neutralisierung-detail.md new file mode 100644 index 0000000..afe138d --- /dev/null +++ b/e-compliance/ims/05_betrieb/neutralisierung-detail.md @@ -0,0 +1,203 @@ +# Neutralisierung + +**Stand:** 2026-04-16 + +--- + +## 1. Grundidee + +Neutralisierung passiert dort, wo **Content entsteht oder ins System einfliesst** — nicht als nachgelagerter Filter vor dem Modell-Call. Wenn Content einmal neutralisiert ist (z. B. im RAG), bleibt er neutralisiert. Kein doppeltes Verarbeiten. + +--- + +## 2. Wer fordert Neutralisierung? + +Drei Quellen, von breit nach spezifisch: + +| Quelle | Flag im Code | Bedeutung | +|--------|-------------|-----------| +| **Feature-Instanz** | `DataNeutraliserConfig.enabled` (hat `featureInstanceId` + `mandateId`) | Alle Daten in dieser Feature-Instanz werden neutralisiert. Betrifft jeden Content-Einstieg innerhalb dieser Instanz. | +| **Chat-Workflow / Session** | `ServiceCenterContext.requireNeutralization` (gesetzt z. B. vom AI-Workspace oder Automation) | Dieser Workflow/Turn: jeder Content, der hier verarbeitet wird, wird neutralisiert. | +| **Dokument oder Quelle** | `FileItem.neutralize`, `FileFolder.neutralize`, `DataSource.neutralize`, `FeatureDataSource.neutralize`, `FeatureDataSource.neutralizeFields` | Dieses konkrete Objekt: Content daraus wird neutralisiert, egal ob die Feature-Instanz oder der Workflow es sonst fordern würden. `FileFolder.neutralize` propagiert auf alle enthaltenen Dateien. `neutralizeFields` ermoeglicht Feld-Level-Maskierung bei DB-Queries. | + +**Auswertung:** Irgendeine Quelle sagt `True` → neutralisieren. Keine Quelle kann eine andere aufheben. Es gibt kein `False`-Override, das ein `True` von woanders aushebelt. + +--- + +## 3. Wo passiert die Neutralisierung? + +Am **Punkt der Content-Einspeisung** — dort wo Rohdaten zu verarbeitbarem Content werden: + +| Content-Einstieg | Was passiert | Wer prüft das Flag | +|------------------|-------------|---------------------| +| **Datei-Indexierung** (RAG) | Text-Chunks werden über `processText` neutralisiert, bevor sie ins Embedding gehen. Medien: nur internes Modell oder nicht indexieren. Ergebnis: RAG enthält nur neutralisierten Content. | `mainServiceKnowledge.indexFile` liest `FileItem.neutralize` | +| **Content-Extraktion** (Dokumente für KI-Verarbeitung) | Extrahierter Text/Tabellen werden neutralisiert. PDF, DOCX, XLSX, PPTX über `processFile` (Extract → neutralisieren → zurückschreiben). | Caller kennt die Quelle und deren Flag | +| **User-Prompt** (Chat-Eingabe) | Prompt-Text wird durch `processText` neutralisiert, wenn Feature-Instanz oder Workflow es fordern. | `mainServiceAi` prüft Context-Flag / Config | +| **DataSource-Download** | Flag wird auf erstellte `FileItem`s vererbt → bei Extraktion/Indexierung greift das File-Flag automatisch. | `mainServiceAgent._resolveDataSource` / `_downloadFromDataSource` | +| **FeatureDataSource-Abfrage (Tabelle)** | Wenn eine `FeatureDataSource.neutralize=True` hat → Content aus diesem Sub-Agent-Call wird neutralisiert. | `mainServiceAgent._queryFeatureInstance` setzt `requireNeutralization=True` | +| **FeatureDataSource-Abfrage (Feld/Typ, seit 2026-06)** | Typ- und vererbungsbewusst: **Strings** werden substring-neutralisiert sobald effektiv (explizit ODER geerbt, Feldname als Typ-Hint); **Binary** wird gedroppt; **andere Skalare** (number/date/bool) nur bei **explizitem** Feld-Flag als Ganzwert-Platzhalter `[NEUT..]`. Identifikatoren/System-Spalten ausgenommen, Engine-Ausfall = `[REDACTED]`. RAG-Bootstrap nutzt dieselbe Policy (Query- und Index-Pfad konsistent). | `featureDataProvider.finalizeRowsAsync` / `_neutralizeAndSerializeRows`; Policy aus `coreTools/_featureSubAgentTools` via `resolveEffectiveForFds` | +| **De-Neutralisierung für Download (seit 2026-06)** | Read-only Agent-Tool `revealDocument` löst Platzhalter **nur** über das lokale Mapping (`resolveText`, kein externes LLM) auf und liefert Klartext als transienten Einmal-Download (SSE `revealDownload`) — kein Save/Index/Historie. | `coreTools/_mediaTools._revealDocument` | +| **Ordner-Neutralisierung** | `FileFolder.neutralize=True` propagiert auf alle enthaltenen Dateien (rekursiv). Neue/verschobene Dateien erben das Flag. Index-Purge + Re-Index wie bei einzelnen Dateien. | `routeDataFiles.updateFolderNeutralize` | +| **Workflow-Aktion `neutralizeData`** | Expliziter Neutralisierungs-Schritt auf bereits extrahierten ContentParts. | Workflow-Config + `NeutralizationConfig.enabled` | + +**Was NICHT nochmal neutralisiert werden muss:** +- RAG-Chunks, die bereits neutralisiert indexiert sind — die sind schon sauber. +- Web-Suchergebnisse — enthalten keine Mandantendaten, brauchen keine Neutralisierung. + +**Flag-Änderung:** Ändert sich `FileItem.neutralize` (Toggle) → Index löschen → Re-Indexierung triggern → neuer Index ist im richtigen Zustand. + +--- + +## 4. Engine: `NeutralizationService` + +Eine Engine, drei Einstiege, aufgerufen an den Content-Einstiegspunkten aus Abschnitt 3. + +| API | Eingabe | Status | +|-----|---------|--------| +| `processText(text)` | Rohtext (Prompt, Message, Text-ContentPart, Text-Chunk) | **Ist** | +| `processFile(fileId)` | Datei aus DB — wird nach MIME geroutet | **Ist** | +| `processBinaryBytes` / `Async` | Bytes + Dateiname + MIME | **Ist** | +| **`processImage(imageBytes, fileName)`** / `processImageAsync` | Bild-Datei oder Bild-ContentPart (image/png, image/jpeg, …) | **Ist** (seit ~2026 Q1) | + +**Ist-Zustand Bilder (aktualisiert 2026-04-05):** `processImageAsync` ist implementiert und nutzt `NEUTRALIZATION_IMAGE` (Private LLM Vision). `_processBinaryFile` verarbeitet jetzt Bild-Parts ueber `processImageAsync`. **Einschraenkung:** Eigenstaendige Bild-Dateien (`image/*` MIME direkt an `processFile`) werden in `_isBinaryMimeType` weiterhin als Skip behandelt. + +**Ist (aktualisiert):** `processImageAsync` existiert als Einstieg. Ruft internes Vision-Modell (`NEUTRALIZATION_IMAGE` → Private-LLM) auf, um sensible Inhalte in Bildern zu erkennen/entfernen. Kein externer Provider. Modell nicht verfügbar → Bild blockieren (nicht unbehandelt weiterreichen). + +**Ablauf nach MIME:** + +| MIME | Pfad | +|------|------| +| PDF, DOCX, XLSX, PPTX | `runExtraction` → Text/Table-Parts durch `_neutralizeText`, Bild-Parts durch `processImage` → PDF in-place oder Office-Renderer | +| Text, JSON, CSV, XML | `_neutralizeText` direkt (TextProcessor, ListProcessor, BinaryProcessor je nach Inhalt) | +| Bilder (image/*) | **`processImage`** → internes Vision-Modell (`NEUTRALIZATION_IMAGE`). Nicht verfügbar → blockieren. | +| Video, Audio | Nur internes Modell oder blockieren (analog Bilder, aber niedrigere Priorität) | +| Anderes Binary | Skip (nicht unterstützt) | + +**Mapping:** Platzhalter `[typ.uuid]` → Attribute in DB. `resolveText(text)` für Rückübersetzung. + +--- + +## 5. Modellauswahl + +| Operation Type | Modelle | Zweck | +|----------------|---------|-------| +| `NEUTRALIZATION_TEXT` | `poweron-text-general` (Rating 9) | Falls Engine ein LLM für Text braucht | +| `NEUTRALIZATION_IMAGE` | `poweron-vision-general` (9), `poweron-vision-deep` (9) | Medien bei Neutralisierungspflicht: nur intern | + +Registriert in `aicorePluginPrivateLlm.py`. Externe Provider haben keine `NEUTRALIZATION_*`-Ratings → werden nie für Neutralisierung gewählt. + +--- + +## 6. Fail-safe + +| Situation | Verhalten | +|-----------|-----------| +| Neutralisierung gefordert, Engine nicht verfügbar | Content **nicht** weiterverarbeiten (blockieren) | +| Neutralisierung eines Teils schlägt fehl | Teil entfernen, nicht im Rohzustand weiterleiten | +| Kein internes Modell für Medien verfügbar | Medien-Part entfernen | + +--- + +## 7. Code-Karte + +| Bereich | Pfad | +|---------|------| +| Engine | `features/neutralization/serviceNeutralization/mainServiceNeutralization.py` + `subProcess*.py` | +| Config + Attribute DB | `features/neutralization/datamodelFeatureNeutralizer.py`, `interfaceFeatureNeutralizer.py` | +| Index (Data-at-rest) | `serviceCenter/services/serviceKnowledge/mainServiceKnowledge.py` | +| Prompt-Neutralisierung | `serviceCenter/services/serviceAi/mainServiceAi.py` (`_shouldNeutralize`, `_neutralizeRequest`) | +| Agent / DataSource / Feature | `serviceCenter/services/serviceAgent/mainServiceAgent.py` | +| Workflow-Aktion | `workflows/methods/methodContext/actions/neutralizeData.py` | +| Modelle / Enums | `datamodels/datamodelAi.py`, `aicore/aicorePluginPrivateLlm.py` | +| Flags | `datamodelFiles.py` (`FileItem.neutralize`), `datamodelDataSource.py`, `datamodelFeatureDataSource.py` | +| Context | `serviceCenter/context.py` (`ServiceCenterContext.requireNeutralization`) | + +--- + +## 8. Umsetzungsplan + +### Schritt 1: `processImage` in Engine bauen + +**Datei:** `mainServiceNeutralization.py` +**Was:** Neue Methode `processImage(imageBytes: bytes, fileName: str, mimeType: str) -> Dict` und `processImageAsync`. +**Wie:** Internes Vision-Modell aufrufen (`NEUTRALIZATION_IMAGE` via Model Selector / `aiObjects`). Prompt: sensible Inhalte im Bild erkennen und beschreiben, damit Caller entscheiden kann ob Bild blockiert wird. Kein internes Modell verfügbar → `{'status': 'blocked'}` zurückgeben. +**Abhängigkeit:** `OperationTypeEnum.NEUTRALIZATION_IMAGE` + Modell-Ratings in `aicorePluginPrivateLlm.py` — **bereits erledigt**. + +### Schritt 2: `_shouldNeutralize` vereinfachen + +**Datei:** `mainServiceAi.py` (Zeile ~560) +**Ist:** Prüft `request.requireNeutralization` → `context.requireNeutralization` → `NeutralizationConfig.enabled` (Mandant-Level Config). `request.requireNeutralization=False` bricht sofort ab. +**Soll:** Drei Quellen gemäss Abschnitt 2, kein `False`-Override: +1. Feature-Instanz: `NeutralizationConfig.enabled` (hat `featureInstanceId`) +2. Workflow/Session: `context.requireNeutralization` +3. Request: `request.requireNeutralization` + +Irgendein `True` → neutralisieren. `False` in einer Quelle hebt `True` in einer anderen **nicht** auf. +**Änderung:** `if request.requireNeutralization is False: return False` **entfernen**. Stattdessen OR-Verknüpfung aller drei Quellen. + +### Schritt 3: `_neutralizeRequest` auf Prompt/Messages beschränken + +**Datei:** `mainServiceAi.py` (Zeile ~592) +**Ist:** Neutralisiert `prompt`, `context`, `messages` (String-Content). +**Soll:** Zusätzlich Text in `contentParts` und Text-Teile in multimodalen Messages (content-Liste mit `type==text`). Bild-Teile in Messages: bei Neutralisierungspflicht über `processImage` prüfen oder entfernen. +**Wichtig:** Hier geht es nur um Prompt-/Sessiondaten. File-Content aus RAG ist bereits neutralisiert (Schritt 5), muss hier nicht nochmal durch. + +### Schritt 4: `indexFile` — Bild-Chunks behandeln + +**Datei:** `mainServiceKnowledge.py` (Zeile ~146 ff.) +**Ist:** Nur `textObjects` (contentType == "text") werden bei `_shouldNeutralize` durch `processText` geschickt. Bild-Chunks (`contentType == "image"`) werden unverändert indexiert. +**Soll:** Bild-Chunks bei `_shouldNeutralize` über `processImage` (Schritt 1) prüfen. Ergebnis `blocked` → Bild-Chunk nicht indexieren. Ergebnis OK → Bild-Chunk indexieren (internes Modell hat es gesehen, kein externer Provider nötig). +**Abhängigkeit:** Schritt 1. + +### Schritt 5: Agent-Tool `readFile` — Content bei Extraktion neutralisieren + +**Datei:** `mainServiceAgent.py`, Tool `_readFile` (Zeile ~540 ff.) +**Ist:** Liest aus Knowledge Store (bereits indexiert) oder extrahiert on-demand. Kein Neutralisierungs-Check. +**Soll:** +- **Knowledge Store Pfad (Zeile ~548):** RAG-Chunks sind bereits neutralisiert wenn `FileItem.neutralize=True` war (Schritt 4) → nichts zu tun. +- **On-Demand Extraktion (Zeile ~630 ff.):** Nach `runExtraction` und vor Rückgabe der Text-Objekte: `FileItem.neutralize` laden. Wenn `True` → Text-Objekte durch `processText`, Bild-Objekte durch `processImage`. + +### Schritt 6: Agent-Tool `summarizeContent` — File-Flag prüfen + +**Datei:** `mainServiceAgent.py`, Tool `_summarizeContent` (Zeile ~1921 ff.) +**Ist:** Liest Content-Objects aus Knowledge Store, baut `combinedText` und ruft `callAi` auf. Kein Neutralisierungs-Check. +**Soll:** Content aus Knowledge Store ist bereits neutralisiert (Schritt 4) → nichts zu tun, **sofern** File indexiert war. Wenn nicht indexiert: File-Flag prüfen, Text vor `callAi` durch `processText`. +**Hinweis:** Durch Schritt 4 ist der Regelfall abgedeckt. + +### Schritt 7: Agent-Tool `describeImage` — File-Flag prüfen + +**Datei:** `mainServiceAgent.py`, Tool `_describeImage` (Zeile ~2015 ff.) +**Ist:** Lädt Bild-Chunk oder Rohdaten, sendet per `callAi` mit `IMAGE_ANALYSE` an **beliebigen** Provider (inkl. extern). Kein Neutralisierungs-Check. +**Soll:** `FileItem.neutralize` laden (fileId ist bekannt). Wenn `True`: +- `operationType` auf `NEUTRALIZATION_IMAGE` statt `IMAGE_ANALYSE` → Model Selector wählt nur internes Modell. +- Kein internes Modell → Tool gibt Fehler zurück statt Bild an externen Provider zu senden. + +### Schritt 8: `_processBinaryFile` — Bild-Parts nicht mehr überspringen + +**Datei:** `mainServiceNeutralization.py` (Zeile ~298) +**Ist:** `if type_group in ('binary', 'image'): neutralized_parts.append(part); continue` — Bild-Parts werden übersprungen. +**Soll:** `binary` weiterhin skip. `image` → durch `processImage` (Schritt 1). Ergebnis `blocked` → Part entfernen. Ergebnis OK → Part behalten. +**Abhängigkeit:** Schritt 1. + +### Schritt 9: Workflow-Aktion `neutralizeData` — Bild-Parts + +**Datei:** `neutralizeData.py` (Zeile ~130 ff.) +**Ist:** Iteriert über ContentParts, neutralisiert nur Parts mit `part.data` (Text). `typeGroup != text/table` → unverändert durchgereicht. +**Soll:** Bild-Parts durch `processImage`. Ergebnis `blocked` → Part entfernen. +**Abhängigkeit:** Schritt 1. + +### Schritt 10: Tests + +| Test | Was | +|------|-----| +| T1 | `FileItem.neutralize=True` → `indexFile` → Text-Chunks neutralisiert, Bild-Chunks geprüft/blockiert | +| T2 | `readFile` on-demand auf File mit `neutralize=True` → Text neutralisiert | +| T3 | `describeImage` auf File mit `neutralize=True` → nur internes Modell | +| T4 | Feature-Instanz Config `enabled=True` → Prompt in `callAi` neutralisiert | +| T5 | Workflow `requireNeutralization=True` → Prompt neutralisiert | +| T6 | `processFile` auf PDF mit Bildern → Text neutralisiert, Bild-Parts durch `processImage` | +| T7 | Flag-Toggle → Index gelöscht → Re-Index im richtigen Zustand | + +### Schritt 11: Logging + +**Alle Stellen (Schritte 2–9):** Bei Neutralisierung loggen: welche Quelle (Feature-Instanz / Workflow / File-Flag), welche `fileId` falls vorhanden, Ergebnis (OK / Part entfernt / blockiert). **Kein Klartext** in Logs. diff --git a/e-compliance/ims/05_betrieb/security-overview.md b/e-compliance/ims/05_betrieb/security-overview.md new file mode 100644 index 0000000..0d72d31 --- /dev/null +++ b/e-compliance/ims/05_betrieb/security-overview.md @@ -0,0 +1,369 @@ +# PowerOn Plattform -- Sicherheit und Compliance + +**Stand:** Februar 2026 +**Zielgruppe:** Entscheidungsträger, Einkauf, Rechtsabteilung, Datenschutzbeauftragte +**Klassifizierung:** Kundeninformation + +--- + +## 1. Management Summary + +PowerOn ist eine **Multi-Mandanten-KI-Plattform für Unternehmen**, die es Organisationen ermöglicht, KI-gestützte Geschäftsprozesse sicher, datenschutzkonform und mandantengetrennt zu betreiben. Die Plattform richtet sich an mittlere bis grosse Unternehmen in datenschutzsensiblen Branchen wie Finanzwesen, Treuhand, Immobilien und Beratung. + +Dieses Dokument beschreibt die in PowerOn implementierten Sicherheits- und Datenschutzmassnahmen, ordnet diese gängigen Standards zu und benennt transparent bestehende Einschränkungen. + +**Kernaussagen:** + +- **DSGVO-Betroffenenrechte** (Auskunft, Löschung, Datenübertragbarkeit, Berichtigung) sind als Self-Service-Funktionen direkt in der Plattform implementiert. +- **Vollständige Mandantentrennung:** Daten eines Mandanten sind unter keinen Umständen für andere Mandanten einsehbar oder zugänglich. +- **Rollenbasierte Zugriffskontrolle (RBAC):** Jeder Datenzugriff wird gegen ein mehrstufiges Berechtigungssystem geprüft -- konfigurierbar pro Mandant und Funktionsmodul. +- **Verschlüsselung:** Sensible Konfigurationsdaten sind nach Industriestandard verschlüsselt, sämtliche Kommunikation erfolgt über verschlüsselte Verbindungen. +- **Audit-Trail:** Alle sicherheitsrelevanten Aktionen werden lückenlos protokolliert und stehen für Compliance-Nachweise zur Verfügung. +- **Transparenz bei KI-Nutzung:** Die Plattform dokumentiert offen, welche Daten an KI-Dienste übermittelt werden, und bietet Konfigurationsoptionen für höchste Datenschutzanforderungen. + +--- + +## 2. DSGVO-Konformität + +PowerOn implementiert die zentralen Betroffenenrechte der Datenschutz-Grundverordnung (DSGVO/GDPR) direkt als Plattformfunktionen. Im Folgenden wird für jeden relevanten Artikel beschrieben, was implementiert ist und wo Einschränkungen bestehen. + +### 2.1 Auskunftsrecht (Art. 15 DSGVO) + +Nutzer können über eine Self-Service-Funktion sämtliche über sie gespeicherten Daten exportieren: + +- Persönliche Profildaten (Name, E-Mail, Spracheinstellungen) +- Mandatszugehörigkeiten und zugewiesene Rollen +- Zugriffsrechte auf Funktionsmodule +- Erstellte und eingelöste Einladungen +- Zeitpunkte der Kontoerstellung und letzten Anmeldung + +Der Export umfasst alle auf Plattformebene gespeicherten Daten. Feature-spezifische Daten (z.B. Chat-Verläufe, Treuhandpositionen) können über die jeweiligen Funktionsmodule eingesehen werden. + +**Status: Implementiert.** + +### 2.2 Recht auf Löschung (Art. 17 DSGVO) + +Nutzer können ihr Konto und alle zugehörigen Daten eigenständig und unwiderruflich löschen. Dabei gilt: + +- Das System durchsucht automatisch alle Datenbanken (Plattform, Verwaltung, Chat, alle Funktionsmodule) nach Einträgen, die dem Nutzer zugeordnet sind. +- Nutzerbezogene Daten werden vollständig gelöscht. +- Audit-Logs werden anonymisiert statt gelöscht -- dies gewährleistet die Einhaltung gesetzlicher Aufbewahrungspflichten bei gleichzeitiger Wahrung der Betroffenenrechte. +- Die Löschung erfordert eine explizite Bestätigung durch den Nutzer. +- Systemadministratoren sind von der Selbstlöschung ausgenommen (Vier-Augen-Prinzip). + +**Status: Implementiert.** + +### 2.3 Recht auf Datenübertragbarkeit (Art. 20 DSGVO) + +Nutzerdaten können in einem maschinenlesbaren, standardisierten Format (JSON-LD nach schema.org) exportiert werden. Dieses Format ermöglicht die Übertragung der Daten an einen anderen Dienstleister. + +**Status: Implementiert.** + +### 2.4 Berichtigungsrecht (Art. 16 DSGVO) + +Nutzer können ihre Profildaten (Name, E-Mail, Spracheinstellungen) jederzeit selbst korrigieren. + +**Status: Implementiert.** + +### 2.5 Transparenz und Informationspflicht + +Die Plattform stellt Nutzern aktiv Informationen über die Datenverarbeitung bereit: + +- Welche Daten erhoben werden +- Zu welchem Zweck die Verarbeitung erfolgt +- Auf welcher Rechtsgrundlage die Verarbeitung basiert +- Welche Aufbewahrungsfristen gelten +- Welche Betroffenenrechte bestehen und wie sie ausgeübt werden können + +**Status: Implementiert.** + +### 2.6 Bekannte Einschränkungen + +Die folgenden Punkte sind transparent zu benennen: + +- **Consent-Management:** Die Plattform verfügt derzeit über kein granulares Einwilligungsmanagement mit individuellen Zustimmungs-Toggles. Die Einwilligung zur Datenverarbeitung erfolgt über die Nutzungsbedingungen und, bei Drittanbieter-Authentifizierung (Microsoft, Google), über die jeweiligen OAuth-Einwilligungsflüsse. +- **Datenschutz-Kontaktadresse:** Die Kontaktadresse für Datenschutzanfragen ist pro Deployment konfigurierbar und muss vom jeweiligen Betreiber hinterlegt werden. + +--- + +## 3. Mandantenmodell und Datenisolation + +### 3.1 Grundprinzip + +PowerOn ist als Multi-Mandanten-Plattform konzipiert. Jede Organisation, Abteilung oder jeder Kunde wird als eigenständiger **Mandant** abgebildet. Das zentrale Sicherheitsversprechen: + +> **Daten eines Mandanten sind unter keinen Umständen für Nutzer anderer Mandanten sichtbar oder zugänglich.** + +### 3.2 Wie die Trennung funktioniert + +- **Zugehörigkeitsprüfung bei jedem Zugriff:** Bevor ein Nutzer auf Mandantendaten zugreifen kann, prüft die Plattform, ob eine aktive Mitgliedschaft des Nutzers in diesem Mandanten besteht. Ohne nachgewiesene Mitgliedschaft wird der Zugriff verweigert. +- **Kein mandantenübergreifender Datenfluss:** Datenbankabfragen werden automatisch auf den Mandantenkontext gefiltert. Es gibt keinen Mechanismus, der Daten mandantenübergreifend zusammenführt oder exponiert. +- **Feature-Isolation:** Innerhalb eines Mandanten werden Funktionsmodule (z.B. CommCoach, Treuhand, Immobilien) zusätzlich isoliert. Nutzer benötigen für jedes Funktionsmodul eine explizite Zugriffsberechtigung. + +### 3.3 Mehrfachmandanten + +Nutzer können gleichzeitig in mehreren Mandanten arbeiten -- ein häufiges Szenario bei Beratern, Treuhändern oder Dienstleistern mit mehreren Kunden. Die Plattform stellt sicher: + +- Der Mandantenkontext wird pro Anfrage bestimmt, nicht pro Sitzung. Ein Wechsel zwischen Mandanten ist jederzeit möglich, ohne dass Daten vermischt werden. +- Es findet keine Übertragung von Daten, Berechtigungen oder Einstellungen zwischen Mandanten statt. + +### 3.4 Schutz vor Manipulation + +Auch bei technischem Wissen über die Plattformarchitektur ist ein unbefugter Zugriff auf fremde Mandantendaten nicht möglich: Die Zugehörigkeitsprüfung erfolgt serverseitig und kann nicht durch Manipulation von Anfrageparametern umgangen werden. + +--- + +## 4. Rollenbasierte Zugriffskontrolle (RBAC) + +### 4.1 Berechtigungsmodell + +PowerOn verfügt über ein feingliedriges, rollenbasiertes Berechtigungssystem. Für jede Aktion (Lesen, Erstellen, Bearbeiten, Löschen) können individuelle Berechtigungsstufen vergeben werden: + +| Berechtigungsstufe | Beschreibung | +|---|---| +| Kein Zugriff | Funktion ist nicht verfügbar | +| Eigene Daten | Zugriff nur auf selbst erstellte Einträge | +| Mandantendaten | Zugriff auf alle Daten innerhalb des eigenen Mandanten | +| Alle Daten | Vollzugriff (typischerweise für Administratoren) | + +### 4.2 Konfigurierbarkeit + +- Rollen können **pro Mandant** und **pro Funktionsmodul** definiert und zugewiesen werden. +- Es gibt keine fest verdrahteten Berechtigungen -- jede Organisation kann das Rollenmodell an ihre Bedürfnisse anpassen. +- Berechtigungsänderungen werden im Audit-Trail protokolliert. + +### 4.3 Administratoren + +Systemadministratoren verfügen über erweiterte Rechte, unterliegen jedoch ebenfalls dem RBAC-System. Alle Administratoraktionen werden gesondert im Audit-Log festgehalten. Es gibt kein unkontrolliertes "Superuser"-Konto ohne Nachvollziehbarkeit. + +--- + +## 5. Verschlüsselung und Datensicherheit + +### 5.1 Verschlüsselung ruhender Daten + +Alle sensiblen Konfigurationsdaten werden verschlüsselt gespeichert: + +- **Verschlüsselungsverfahren:** AES-Verschlüsselung (Fernet) +- **Schlüsselableitung:** PBKDF2-HMAC-SHA256 nach aktuellem Industriestandard +- **Umfang:** Datenbankpasswörter, API-Schlüssel für KI-Dienste, OAuth-Geheimnisse, JWT-Schlüssel und alle weiteren als "SECRET" gekennzeichneten Konfigurationswerte + +Sensible Konfigurationsdaten liegen zu keinem Zeitpunkt im Klartext in der Konfiguration oder im Quellcode vor. + +### 5.2 Verschlüsselung in Übertragung + +- Sämtliche Kommunikation zwischen Client und Server erfolgt über HTTPS/TLS. +- Verbindungen zu Drittdiensten (KI-Anbieter, Authentifizierungsdienste, E-Mail-Dienste) nutzen ebenfalls ausschliesslich verschlüsselte Verbindungen. +- Die TLS-Konfiguration erfolgt auf Infrastruktur-Ebene (Azure / Reverse Proxy) -- dies entspricht dem Branchenstandard bei Cloud-Deployments und ermöglicht zentrale Verwaltung und Aktualisierung der Zertifikate. + +### 5.3 Zugriffskontrolle auf Verschlüsselungsschlüssel + +- Der Zugriff auf Verschlüsselungsschlüssel ist auf das Minimum beschränkt. +- Jeder Zugriff auf Verschlüsselungsfunktionen (Entschlüsselung, Neuverschlüsselung) wird im Audit-Trail protokolliert. +- Eine Ratenbegrenzung schützt vor automatisierten Entschlüsselungsversuchen. + +--- + +## 6. Schutzmassnahmen gegen Angriffe + +PowerOn implementiert Schutzmassnahmen gegen die gängigsten Angriffsvektoren für Webanwendungen: + +### 6.1 Cross-Site Request Forgery (CSRF) + +Alle datenverändernden Operationen (POST, PUT, DELETE, PATCH) erfordern einen `X-CSRF-Token` Header. Die aktuelle Implementierung validiert das Tokenformat (16-64 Zeichen Hex-String); es gibt kein serverseitiges Session-Binding (kein klassisches Double-Submit oder Synchronizer Token). In Kombination mit `SameSite=Strict` Cookies und CORS bietet dies Basisschutz gegen CSRF. + +### 6.2 Ratenbegrenzung (Rate Limiting) + +Jede API-Funktion ist mit individuellen Zugriffslimits versehen, die automatisierte Angriffe und Missbrauch unterbinden: + +| Funktion | Limit | +|---|---| +| Anmeldung | 30 Versuche pro Minute | +| Datenexport (DSGVO) | 5 Anfragen pro Minute | +| Kontolöschung | 1 Anfrage pro Stunde | +| KI-Anfragen | 120 Anfragen pro Minute | +| Datei-Upload | 10 Uploads pro Minute | + +### 6.3 Eingabebereinigung + +Nutzereingaben werden bereinigt und validiert, bevor sie an KI-Modelle oder Datenbanken weitergeleitet werden. Dies schützt vor Prompt-Injection-Angriffen und anderen Manipulationsversuchen. + +### 6.4 SQL-Injection-Schutz + +- Alle Datenbankabfragen der Plattform verwenden parametrisierte Abfragen -- der Industriestandard zur Vermeidung von SQL-Injection. +- Der KI-gestützte Datenbankzugriff ist zusätzlich auf reine Leseabfragen (SELECT) beschränkt. Schreibende, ändernde oder löschende Operationen sind auf Systemebene blockiert. + +### 6.5 Cross-Origin Resource Sharing (CORS) + +Nur definierte und verifizierte Quelldomains erhalten Zugriff auf die Plattform-API. Anfragen von nicht autorisierten Quellen werden automatisch abgelehnt. + +--- + +## 7. KI-Dienste und Datenverarbeitung + +Transparenz im Umgang mit KI-Diensten ist für datenschutzbewusste Organisationen entscheidend. PowerOn legt offen, wie Daten im Kontext der KI-Nutzung verarbeitet werden. + +### 7.1 Welche Daten werden verarbeitet + +Im Rahmen der KI-gestützten Funktionen (KI-Assistent, Workflow-Verarbeitung, Dokumentenanalyse) können folgende Daten an KI-Dienste übermittelt werden: + +- Nutzeranfragen und -eingaben +- Dokumentinhalte (bei Dokumentenanalyse) +- Gesprächsverläufe (bei Chat-Funktionen) + +### 7.2 Welche KI-Anbieter werden genutzt + +PowerOn unterstützt mehrere KI-Anbieter, die je nach Bedarf und Konfiguration eingesetzt werden: + +- **OpenAI** (GPT-4o und weitere Modelle) +- **Anthropic** (Claude-Modelle) +- **Tavily** (Websuche) +- **Private LLM** (lokale/eigene Modelle -- kein externer Datenabfluss) + +Die Auswahl des Anbieters ist konfigurierbar und kann an die Datenschutzanforderungen des Kunden angepasst werden. + +### 7.3 Mandantentrennung bei KI-Anfragen + +Jede KI-Anfrage erfolgt im Kontext des jeweiligen Mandanten. Es findet keine Vermischung von Daten verschiedener Mandanten in KI-Anfragen statt. + +### 7.4 Kein Training mit Kundendaten + +Bei Nutzung der Enterprise-API-Vereinbarungen der KI-Anbieter (OpenAI Enterprise API, Anthropic API) werden Kundendaten nicht für das Training der KI-Modelle verwendet. Dies ist vertraglich durch die Auftragsverarbeitungsvereinbarungen (AV-V / DPA) mit den jeweiligen Anbietern abgesichert. + +### 7.5 Optionen für höchste Datenschutzanforderungen + +Für Organisationen mit besonders hohen Datenschutzanforderungen bietet PowerOn: + +- **Datenschutz-Neutralisierer:** Optionales Modul, das personenbezogene Daten vor der Übermittlung an externe KI-Dienste entfernt oder pseudonymisiert. +- **Private-LLM-Anbindung:** Möglichkeit, ein eigenes, lokal betriebenes Sprachmodell zu nutzen. In diesem Fall verlassen keine Daten die eigene Infrastruktur. + +### 7.6 Bekannte Einschränkung + +Die automatische Erkennung und Filterung personenbezogener Daten (PII) vor dem Versand an externe KI-Dienste ist **nicht standardmässig aktiviert**. Organisationen, die mit besonders sensiblen personenbezogenen Daten arbeiten, sollten den Datenschutz-Neutralisierer nutzen oder den Private-LLM-Connector einsetzen. + +--- + +## 8. Audit-Trail und Nachvollziehbarkeit + +### 8.1 Was wird protokolliert + +Sämtliche sicherheitsrelevanten Aktionen werden automatisch und lückenlos in einem Audit-Log erfasst: + +| Kategorie | Beispiele | +|---|---| +| Zugriff | Anmeldungen, fehlgeschlagene Anmeldeversuche, Abmeldungen | +| Sicherheit | Administratoraktionen, SysAdmin-Zugriffe, Sicherheitsereignisse | +| Datenschutz (DSGVO) | Datenexporte, Kontolöschungen, Portabilitätsanfragen | +| Berechtigungen | Rollenzuweisungen, Berechtigungsänderungen | +| Verschlüsselung | Zugriffe auf Verschlüsselungsfunktionen | +| Datenoperationen | Zugriffe auf sensible Geschäftsdaten | + +### 8.2 Aufbewahrung und Bereinigung + +- **Standard-Aufbewahrungsdauer:** 365 Tage (konfigurierbar) +- **Automatische Bereinigung:** Veraltete Einträge werden durch einen täglichen Prozess entfernt -- dies stellt sicher, dass Audit-Daten nicht unbefristet aufbewahrt werden (DSGVO-Konformität). +- **Anonymisierung:** Bei der Löschung eines Nutzerkontos werden zugehörige Audit-Einträge anonymisiert statt gelöscht. Die Nachvollziehbarkeit sicherheitsrelevanter Ereignisse bleibt gewahrt, ohne dass Rückschlüsse auf die gelöschte Person möglich sind. + +### 8.3 Nutzung für Compliance-Nachweise + +Die Audit-Daten können als Nachweis für interne und externe Audits herangezogen werden. Sie dokumentieren, wer wann welche sicherheitsrelevante Aktion durchgeführt hat, und unterstützen damit die Anforderungen an die Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO. + +--- + +## 9. Einordnung in gängige Standards + +PowerOn orientiert sich an anerkannten Standards und Rahmenwerken. Die folgende Einordnung beschreibt transparent, welche Anforderungen die Plattform bereits abdeckt und wo Ergänzungen erforderlich sind. + +### 9.1 DSGVO / GDPR + +| Anforderung | Status | Bemerkung | +|---|---|---| +| Betroffenenrechte (Art. 15--17, 20) | Implementiert | Auskunft, Löschung, Portabilität, Berichtigung als Self-Service | +| Rechenschaftspflicht (Art. 5 Abs. 2) | Implementiert | Lückenloser Audit-Trail | +| Verzeichnis der Verarbeitungstätigkeiten (Art. 30) | Unterstützt | Audit-Log liefert die Datenbasis; das formale Verzeichnis muss vom Betreiber geführt werden | +| Technische und organisatorische Massnahmen (Art. 32) | Implementiert | Verschlüsselung, Zugriffskontrolle, Mandantentrennung, Eingabevalidierung | +| Einwilligungsmanagement (Art. 7) | Teilweise | Über Nutzungsbedingungen und OAuth; kein granulares Consent-Tool | + +### 9.2 Schweizer Datenschutzgesetz (nDSG / revDSG) + +Die Anforderungen des revidierten Schweizer Datenschutzgesetzes sind mit den DSGVO-Massnahmen kompatibel. Insbesondere: + +- Informationspflicht bei Datenerhebung: Transparenzfunktion implementiert +- Recht auf Datenherausgabe und -löschung: Self-Service-Funktionen vorhanden +- Pflicht zu angemessenen technischen Massnahmen: Verschlüsselung, RBAC, Mandantentrennung + +### 9.3 OWASP Top 10 + +Die Plattform adressiert die häufigsten Web-Sicherheitsrisiken gemäss OWASP: + +| OWASP-Risiko | Massnahme in PowerOn | +|---|---| +| Broken Access Control | Rollenbasierte Zugriffskontrolle, Mandantenprüfung bei jedem Zugriff | +| Cryptographic Failures | AES-Verschlüsselung, PBKDF2-Schlüsselableitung, HTTPS/TLS | +| Injection | Parametrisierte Datenbankabfragen, Eingabebereinigung, SQL-Leseeinschränkung | +| Security Misconfiguration | CORS-Einschränkungen, Rate Limiting, CSRF-Schutz | +| Identification and Authentication Failures | JWT-basierte Authentifizierung, Token-Widerruf, Ratenbegrenzung bei Anmeldung | + +Es besteht **keine formale OWASP-Zertifizierung**. Die Massnahmen basieren auf den OWASP-Empfehlungen und sind als präventive Sicherheitsmassnahmen implementiert. + +### 9.4 ISO 27001 / BSI IT-Grundschutz + +Die implementierten technischen und organisatorischen Massnahmen (Zugriffskontrolle, Verschlüsselung, Audit-Logging, Eingabevalidierung, Mandantentrennung) bilden eine **solide Grundlage** für ein Informationssicherheits-Managementsystem (ISMS) nach ISO 27001 oder BSI IT-Grundschutz. + +Es besteht **keine formale Zertifizierung**. Die vorhandene Infrastruktur ermöglicht es jedoch, eine Zertifizierung auf dieser Basis gezielt anzustreben. + +--- + +## 10. Authentifizierung und Identitätsmanagement + +### 10.1 Anmeldemethoden + +PowerOn unterstützt mehrere Authentifizierungsverfahren: + +- **Lokale Anmeldung:** Benutzername und Passwort mit JWT-basierter Sitzungsverwaltung +- **Microsoft-Anmeldung (Azure AD / Entra ID):** Single Sign-On über bestehende Microsoft-Konten +- **Google-Anmeldung:** Single Sign-On über Google Workspace + +### 10.2 Sitzungssicherheit + +- Authentifizierungstoken werden in sicheren, HTTP-only Cookies gespeichert (nicht im Browser-Speicher zugänglich) +- Tokens haben eine konfigurierbare Gültigkeitsdauer +- Token-Widerruf ist jederzeit möglich (z.B. bei Verdacht auf Kompromittierung) +- Bei lokaler Anmeldung wird die Gültigkeit des Tokens zusätzlich gegen die Datenbank geprüft + +### 10.3 Automatische Token-Erneuerung + +Authentifizierungstoken werden automatisch erneuert, bevor sie ablaufen. Dies gewährleistet eine unterbrechungsfreie Nutzung bei gleichzeitiger Begrenzung der Token-Gültigkeitsdauer. + +--- + +## 11. Offene Punkte und Empfehlungen + +Transparenz schafft Vertrauen. Die folgenden Punkte sind offen benannt, damit Kunden und Betreiber informierte Entscheidungen treffen können. + +| Thema | Status | Empfehlung | +|---|---|---| +| Granulares Consent-Management | Nicht vorhanden | Falls regulatorisch erforderlich, als separates Modul ergänzen | +| PII-Filterung vor KI-Versand | Nicht standardmässig aktiv | Datenschutz-Neutralisierer aktivieren oder Private LLM einsetzen | +| Security-Header (CSP, HSTS) | Auf Infrastruktur-Ebene | Konfiguration auf Reverse-Proxy-Ebene dokumentieren und prüfen | +| Datenschutz-Kontaktadresse | Platzhalter | Pro Deployment mit tatsächlicher DSB-Kontaktadresse konfigurieren | +| Formale Zertifizierungen | Keine vorhanden | ISO 27001 / BSI auf Basis der vorhandenen Massnahmen anstrebbar | + +--- + +## 12. Zusammenfassung + +PowerOn vereint Enterprise-KI-Funktionalität mit einem umfassenden Sicherheits- und Datenschutzkonzept. Die Plattform bietet: + +- **DSGVO-konforme Betroffenenrechte** als Self-Service-Funktionen +- **Vollständige Mandantentrennung** mit serverseitiger Zugehörigkeitsprüfung +- **Feingliedriges Berechtigungssystem** mit individuell konfigurierbaren Rollen +- **Verschlüsselung nach Industriestandard** für ruhende und übertragene Daten +- **Lückenlosen Audit-Trail** für Compliance-Nachweise +- **Transparente KI-Datenverarbeitung** mit Optionen für höchste Datenschutzanforderungen + +Gleichzeitig werden bestehende Einschränkungen offen kommuniziert und Empfehlungen für ergänzende Massnahmen gegeben. Diese Kombination aus implementierter Sicherheit und transparenter Kommunikation bildet die Grundlage für eine vertrauensvolle Zusammenarbeit. + +--- + +*Dieses Dokument basiert auf einer Analyse der PowerOn-Plattform (Stand Februar 2026). Alle beschriebenen Massnahmen sind in der Plattform implementiert und wurden anhand der Codebasis verifiziert. Angaben ohne Gewähr -- für verbindliche Zusicherungen gelten die jeweiligen Vertragsvereinbarungen.* diff --git a/e-compliance/Prozesse/legal/00_README_Prozessuebersicht.md b/e-compliance/ims/mappings/cacc-iso-crosswalk.md similarity index 100% rename from e-compliance/Prozesse/legal/00_README_Prozessuebersicht.md rename to e-compliance/ims/mappings/cacc-iso-crosswalk.md