Informationssicherheitsrichtlinie

Version 1.0 — Stand: März 2026

CONPORT Services GmbH
Alte Benninghofer Str. 24
44263 Dortmund
Geschäftsführer: Benjamin Schowe

§ 1 Zweck und Geltungsbereich

Diese Informationssicherheitsrichtlinie legt die verbindlichen Grundsätze und Anforderungen für den Schutz der Informationswerte der CONPORT Services GmbH und der auf der SaaS-Plattform „Aldric" verarbeiteten Kundendaten fest.

Ziel ist der Schutz der Vertraulichkeit, Integrität und Verfügbarkeit aller verarbeiteten Informationen — unabhängig davon, ob sie in digitaler oder physischer Form vorliegen.

Diese Richtlinie gilt für:

alle Mitarbeiterinnen und Mitarbeiter der CONPORT Services GmbH
externe Auftragnehmer, Berater und Dienstleister mit Zugang zu Systemen oder Daten
alle IT-Systeme, Anwendungen und Infrastrukturkomponenten, die im Rahmen der Aldric-Plattform betrieben werden
Daten aller Mandanten, die die Aldric-Plattform nutzen

§ 2 Informationssicherheitsziele

2.1 CIA-Schutzziele

Vertraulichkeit (Confidentiality): Informationen sind nur für autorisierte Personen zugänglich. Mandantendaten sind strikt voneinander isoliert. Unbefugter Zugriff wird durch technische und organisatorische Maßnahmen verhindert.
Integrität (Integrity): Informationen sind vollständig, korrekt und unverändert. Manipulationen werden durch Audit-Logging mit Hash-Chains erkannt und dokumentiert. Eingaben werden auf Ebene der API validiert.
Verfügbarkeit (Availability): Systeme und Daten stehen autorisierten Nutzern im vereinbarten Umfang zur Verfügung. Ausfallzeiten werden minimiert; Verfügbarkeitsziele sind in der SLA definiert.

2.2 Compliance-Ziele

Einhaltung der Datenschutz-Grundverordnung (DSGVO / Art. 32)
Einhaltung einschlägiger nationaler und internationaler Sicherheitsstandards
Erfüllung der vertraglichen Sicherheitszusagen gegenüber Kunden (siehe AVV)
Erreichung der in der SLA definierten Verfügbarkeitsziele

§ 3 Organisation der Informationssicherheit

3.1 Verantwortlichkeiten

Geschäftsführung: Die Geschäftsführung (Benjamin Schowe) trägt die Gesamtverantwortung für Informationssicherheit und stellt die erforderlichen Ressourcen bereit.
Informationssicherheitsbeauftragter (ISB): Die Geschäftsführung benennt einen Informationssicherheitsbeauftragten, der die Umsetzung dieser Richtlinie koordiniert, Sicherheitsvorfälle bewertet und als zentraler Ansprechpartner für Sicherheitsfragen fungiert.
Alle Mitarbeiter: Jeder Mitarbeiter ist verpflichtet, diese Richtlinie einzuhalten, Sicherheitsvorfälle unverzüglich zu melden und an Schulungsmaßnahmen teilzunehmen.

3.2 Jährliche Schulung

Alle Mitarbeiter und relevanten externen Auftragnehmer nehmen mindestens einmal jährlich an einer Informationssicherheitsschulung teil. Neue Mitarbeiter erhalten eine Sicherheitseinweisung im Rahmen des Onboardings (§ 13).

§ 4 Zugriffskontrolle

4.1 Rollenbasierte Zugriffskontrolle (RBAC)

Die Aldric-Plattform implementiert eine feingranulare rollenbasierte Zugriffskontrolle auf drei Ebenen:

Modulebene: Zugriff auf einzelne Compliance-Module (z.B. DSFA, AVV, Audit)
Funktionsebene: Lesen, Schreiben, Genehmigen, Exportieren innerhalb eines Moduls
Datensatzebene: Zugriff auf einzelne Datensätze basierend auf Rolle und Zuständigkeit

4.2 Authentifizierung

Authentifizierung erfolgt ausschließlich über Keycloak (OpenID Connect / JWT)
Single Sign-On (SSO) wird unterstützt
Multi-Faktor-Authentifizierung (MFA) wird für Administratorkonten dringend empfohlen und kann mandantenweise vorgeschrieben werden
Token-Laufzeiten und Sitzungs-Timeouts sind konfigurierbar
Brute-Force-Schutz mit automatischem Rate-Limiting ist aktiv

4.3 Minimales Berechtigungsprinzip

Zugriffsrechte werden nach dem Prinzip der minimalen Berechtigung (Least Privilege) vergeben. Benutzer erhalten nur die Berechtigungen, die für ihre konkrete Aufgabe erforderlich sind.

4.4 Regelmäßige Zugriffsüberprüfung

Berechtigungen werden quartalsweise überprüft. Nicht mehr benötigte Zugriffsrechte werden unverzüglich entzogen. Beim Ausscheiden von Mitarbeitern oder Auftragnehmern werden alle Zugriffsrechte am letzten Arbeitstag deaktiviert.

§ 5 Datenisolierung und Mandantentrennung

5.1 Row-Level Security (RLS)

Die Mandantentrennung wird durch PostgreSQL Row-Level Security (RLS) auf Datenbankebene technisch erzwungen. Jede Tabelle enthält eine tenant_id, und alle Datenbankabfragen werden automatisch durch RLS-Policies auf den jeweiligen Mandanten gefiltert — unabhängig von der Anwendungslogik.

5.2 JWT-basierte Mandantenidentifikation

Die tenant_id eines Nutzers wird ausschließlich aus dem verifizierten JWT-Token abgeleitet, der von Keycloak ausgestellt wird. Eine Manipulation durch Client-seitige Anfragen ist technisch ausgeschlossen — die Anwendung akzeptiert keine mandantenbezogenen Parameter aus dem Request-Body oder der URL.

5.3 Cross-Tenant-Schutz

Ein mandantenübergreifender Datenzugriff ist durch das Zusammenspiel von RLS, JWT-Validierung und RBAC technisch verhindert. Auch bei Fehlkonfigurationen auf Anwendungsebene verhindert die Datenbankschicht jede Offenlegung fremder Mandantendaten.

§ 6 Verschlüsselung

6.1 Datenübertragung

Alle Verbindungen zwischen Clients und der Plattform sind mit TLS 1.2 oder höher verschlüsselt
HTTP-Verbindungen werden auf HTTPS umgeleitet; unsichere Protokolle sind deaktiviert
Alle internen Service-to-Service-Verbindungen (inkl. Datenbankverbindungen) sind verschlüsselt

6.2 Daten im Ruhezustand

Dateien und Objekte werden verschlüsselt in MinIO (S3-kompatibel) gespeichert
Datenbankbackups werden verschlüsselt abgelegt
Passwörter werden mit bcrypt gehasht und niemals im Klartext gespeichert

6.3 Schlüsselverwaltung

Kryptografische Schlüssel werden sicher verwahrt und regelmäßig rotiert. Ablauf- und Rotationszyklen werden dokumentiert.

§ 7 Netzwerksicherheit

Firewall-Regeln: Nur notwendige Ports und Protokolle sind offen; nicht benötigte Dienste sind deaktiviert
Netzwerksegmentierung: Produktions-, Test- und Entwicklungsumgebungen sind netzwerktechnisch voneinander getrennt
Intrusion Detection: Anomalien im Netzwerkverkehr werden erkannt und gemeldet
DDoS-Schutz: Schutzmaßnahmen gegen Distributed-Denial-of-Service-Angriffe sind aktiv
Rate Limiting: API-Endpunkte sind gegen Missbrauch durch Rate-Limiting geschützt
Administrativer Zugang: SSH-Zugang zu Produktionssystemen erfolgt ausschließlich über SSH-Key-Authentifizierung; Passwort-Login ist deaktiviert

§ 8 Protokollierung und Überwachung

8.1 Audit-Logging

Die Plattform protokolliert lückenlos alle sicherheitsrelevanten Aktionen, darunter:

Anmeldungen und fehlgeschlagene Authentifizierungsversuche
Zugriffe auf und Änderungen an sicherheitsrelevanten Datensätzen
administrative Aktionen (Rollenzuweisung, Konfigurationsänderungen)
Exporte und Datendownloads

8.2 Integritätsschutz durch Hash-Chains

Audit-Log-Einträge sind durch verkettete Hashes (Hash-Chains) gegen nachträgliche Manipulation geschützt. Jeder Logeintrag enthält den Hash seines Vorgängers, sodass Lücken oder Änderungen im Protokoll zuverlässig erkannt werden.

8.3 Log-Aufbewahrung und Monitoring

Logs werden mindestens 90 Tage aufbewahrt
Sicherheitsrelevante Ereignisse werden automatisch erkannt und lösen Alarme aus
Kritische Systemkomponenten werden kontinuierlich überwacht (Monitoring & Alerting)

§ 9 Datensicherung

Automatisierte Backups: Täglich automatisierte Sicherungen aller Produktionsdaten
Verschlüsselte Speicherung: Backups werden verschlüsselt und getrennt vom Produktionssystem abgelegt
Aufbewahrungszeiten: Tagesbackups 30 Tage, Monatsbackups 12 Monate
Wiederherstellungstests: Backup-Wiederherstellungen werden regelmäßig getestet und dokumentiert
RTO/RPO: Recovery Time Objective (RTO) und Recovery Point Objective (RPO) sind in der SLA verbindlich definiert
Point-in-Time Recovery: Für die Datenbank steht eine zeitpunktgenaue Wiederherstellung zur Verfügung

§ 10 Schwachstellenmanagement

10.1 Patch-Management

Abhängigkeiten (Libraries, Frameworks, Betriebssystem-Pakete) werden regelmäßig aktualisiert
Kritische Sicherheitslücken (CVSS ≥ 9.0) werden innerhalb von 72 Stunden nach Bekanntwerden gepatcht
Hochgradige Sicherheitslücken (CVSS 7.0–8.9) werden innerhalb von 7 Tagen behoben

10.2 Automatisiertes Schwachstellen-Scanning

Automatisierte Vulnerability-Scans werden regelmäßig ausgeführt und Ergebnisse dokumentiert. Bekannte Schwachstellen in eingesetzten Komponenten werden über Dependency-Auditing-Tools kontinuierlich überwacht.

10.3 Responsible Disclosure

Sicherheitslücken können verantwortungsvoll an security@conport.services gemeldet werden. Gemeldete Schwachstellen werden unverzüglich bewertet und behoben. Meldende Personen erhalten eine Bestätigung innerhalb von 5 Werktagen.

§ 11 Physische Sicherheit

EU-Rechenzentren: Alle Produktionsdaten werden ausschließlich in Rechenzentren innerhalb der Europäischen Union verarbeitet und gespeichert
ISO 27001-Zertifizierung: Die eingesetzten Rechenzentren sind nach ISO 27001 oder einem gleichwertigen Standard zertifiziert
Physische Zugangskontrolle: Rechenzentrumszugang ist auf autorisiertes Personal beschränkt (biometrische Kontrollen, Videoüberwachung, 24/7-Sicherheitspersonal)
Räumlichkeiten CONPORT: Büroräume sind gegen unbefugten Zutritt gesichert; Bildschirmsperren sind vorgeschrieben

§ 12 Incident Management

12.1 Incident Response Plan

Sicherheitsvorfälle werden gemäß dem detaillierten Incident Response Plan behandelt. Dieser definiert Erkennungs-, Eingrenzungs-, Behebungs- und Nachsorgeprozesse.

12.2 DSGVO-Meldepflicht

Datenschutzverletzungen werden der zuständigen Aufsichtsbehörde gemäß Art. 33 DSGVO innerhalb von 72 Stunden nach Bekanntwerden gemeldet, sofern ein Risiko für betroffene Personen nicht ausgeschlossen werden kann. Kunden werden unverzüglich — spätestens innerhalb von 24 Stunden — über sie betreffende Vorfälle informiert (siehe auch AVV § 7).

12.3 Eskalationsmatrix

Eine interne Eskalationsmatrix legt für jeden Schweregrad (P1–P4) fest, welche Personen zu benachrichtigen sind und welche Maßnahmen innerhalb welcher Frist einzuleiten sind. Die Eskalationsmatrix ist Bestandteil des Incident Response Plans.

§ 13 Schulung und Sensibilisierung

Jährliche Pflichtschulung: Alle Mitarbeiter absolvieren jährlich eine Informationssicherheitsschulung, die aktuelle Bedrohungen, Richtlinien und technische Maßnahmen behandelt.
Onboarding-Einweisung: Neue Mitarbeiter und externe Auftragnehmer erhalten vor dem ersten Systemzugang eine Sicherheitseinweisung und bestätigen die Kenntnisnahme dieser Richtlinie schriftlich.
Phishing-Sensibilisierung: Regelmäßige Phishing-Simulationen und Sensibilisierungsmaßnahmen schulen Mitarbeiter im Umgang mit Social-Engineering-Angriffen.
Dokumentation: Schulungsnachweise werden für jeden Mitarbeiter archiviert.

§ 14 Überprüfung und Aktualisierung

Diese Richtlinie wird regelmäßig überprüft und bei Bedarf aktualisiert:

Jährliche Überprüfung: Mindestens einmal im Jahr, in der Regel im ersten Quartal des Geschäftsjahres
Nach signifikanten Vorfällen: Nach Sicherheitsvorfällen der Schweregrade P1 oder P2 wird die Richtlinie unverzüglich bewertet und ggf. angepasst
Nach wesentlichen Architekturänderungen: Bei grundlegenden Änderungen an der Plattformarchitektur oder der Infrastruktur
Bei gesetzlichen Änderungen: Wenn neue rechtliche Anforderungen es erfordern

Änderungen werden versioniert dokumentiert. Die jeweils aktuelle Version ist unter dieser URL abrufbar.

Fragen zur Informationssicherheit richten Sie bitte an: security@conport.services