Informationssicherheitsrichtlinie

Version 1.0 — Stand: Maerz 2026

CONPORT Services GmbH
Alte Benninghofer Str. 24
44263 Dortmund
Geschaeftsfuehrer: Benjamin Schowe

§ 1 Zweck und Geltungsbereich

Diese Informationssicherheitsrichtlinie legt die verbindlichen Grundsaetze und Anforderungen fuer den Schutz der Informationswerte der CONPORT Services GmbH und der auf der SaaS-Plattform „Aldric" verarbeiteten Kundendaten fest.

Ziel ist der Schutz der Vertraulichkeit, Integritaet und Verfuegbarkeit aller verarbeiteten Informationen — unabhaengig davon, ob sie in digitaler oder physischer Form vorliegen.

Diese Richtlinie gilt fuer:

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 fuer autorisierte Personen zugaenglich. Mandantendaten sind strikt voneinander isoliert. Unbefugter Zugriff wird durch technische und organisatorische Massnahmen verhindert.
Integritaet (Integrity): Informationen sind vollstaendig, korrekt und unveraendert. Manipulationen werden durch Audit-Logging mit Hash-Chains erkannt und dokumentiert. Eingaben werden auf Ebene der API validiert.
Verfuegbarkeit (Availability): Systeme und Daten stehen autorisierten Nutzern im vereinbarten Umfang zur Verfuegung. Ausfallzeiten werden minimiert; Verfuegbarkeitsziele sind in der SLA definiert.

2.2 Compliance-Ziele

Einhaltung der Datenschutz-Grundverordnung (DSGVO / Art. 32)
Einhaltung einschlaegiger nationaler und internationaler Sicherheitsstandards
Erfullung der vertraglichen Sicherheitszusagen gegenueber Kunden (siehe AVV)
Erreichung der in der SLA definierten Verfuegbarkeitsziele

§ 3 Organisation der Informationssicherheit

3.1 Verantwortlichkeiten

Geschaeftsfuehrung: Die Geschaeftsfuehrung (Benjamin Schowe) traegt die Gesamtverantwortung fuer Informationssicherheit und stellt die erforderlichen Ressourcen bereit.
Informationssicherheitsbeauftragter (ISB): Die Geschaeftsfuehrung benennt einen Informationssicherheitsbeauftragten, der die Umsetzung dieser Richtlinie koordiniert, Sicherheitsvorfaelle bewertet und als zentraler Ansprechpartner fuer Sicherheitsfragen fungiert.
Alle Mitarbeiter: Jeder Mitarbeiter ist verpflichtet, diese Richtlinie einzuhalten, Sicherheitsvorfaelle unverzueglich zu melden und an Schulungsmassnahmen teilzunehmen.

3.2 Jaehrliche Schulung

Alle Mitarbeiter und relevanten externen Auftragnehmer nehmen mindestens einmal jaehrlich 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 Datensaetze basierend auf Rolle und Zustaendigkeit

4.2 Authentifizierung

Authentifizierung erfolgt ausschliesslich ueber Keycloak (OpenID Connect / JWT)
Single Sign-On (SSO) wird unterstuetzt
Multi-Faktor-Authentifizierung (MFA) wird fuer 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 fuer ihre konkrete Aufgabe erforderlich sind.

4.4 Regelmaessige Zugriffsueberprufung

Berechtigungen werden quartalsweise ueberprueft. Nicht mehr benoetigt Zugriffsrechte werden unverzueglich 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 enthaelt eine tenant_id, und alle Datenbankabfragen werden automatisch durch RLS-Policies auf den jeweiligen Mandanten gefiltert — unabhaengig von der Anwendungslogik.

5.2 JWT-basierte Mandantenidentifikation

Die tenant_id eines Nutzers wird ausschliesslich 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 mandantenuebergreifender 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 Verschluesselung

6.1 Datenuebertragung

Alle Verbindungen zwischen Clients und der Plattform sind mit TLS 1.2 oder hoeher verschluesselt
HTTP-Verbindungen werden auf HTTPS umgeleitet; unsichere Protokolle sind deaktiviert
Alle internen Service-to-Service-Verbindungen (inkl. Datenbankverbindungen) sind verschluesselt

6.2 Daten im Ruhezustand

Dateien und Objekte werden verschluesselt in MinIO (S3-kompatibel) gespeichert
Datenbankbackups werden verschluesselt abgelegt
Passwoerter werden mit bcrypt gehasht und niemals im Klartext gespeichert

6.3 Schluesselverwaltung

Kryptografische Schluessel werden sicher verwahrt und regelmaessig rotiert. Ablauf- und Rotationszyklen werden dokumentiert.

§ 7 Netzwerksicherheit

Firewall-Regeln: Nur notwendige Ports und Protokolle sind offen; nicht benoetigte Dienste sind deaktiviert
Netzwerksegmentierung: Produktions-, Test- und Entwicklungsumgebungen sind netzwerktechnisch voneinander getrennt
Intrusion Detection: Anomalien im Netzwerkverkehr werden erkannt und gemeldet
DDoS-Schutz: Schutzmassnahmen gegen Distributed-Denial-of-Service-Angriffe sind aktiv
Rate Limiting: API-Endpunkte sind gegen Missbrauch durch Rate-Limiting geschuetzt
Administrativer Zugang: SSH-Zugang zu Produktionssystemen erfolgt ausschliesslich ueber SSH-Key-Authentifizierung; Passwort-Login ist deaktiviert

§ 8 Protokollierung und Ueberwachung

8.1 Audit-Logging

Die Plattform protokolliert lueckenlos alle sicherheitsrelevanten Aktionen, darunter:

Anmeldungen und fehlgeschlagene Authentifizierungsversuche
Zugriffe auf und Aenderungen an sicherheitsrelevanten Datensaetzen
administrative Aktionen (Rollenzuweisung, Konfigurationsaenderungen)
Exporte und Datendownloads

8.2 Integritaetsschutz durch Hash-Chains

Audit-Log-Eintraege sind durch verkettete Hashes (Hash-Chains) gegen nachtragliche Manipulation geschuetzt. Jeder Logeintrag enthaelt den Hash seines Vorgaengers, sodass Luecken oder Aenderungen im Protokoll zuverlassig erkannt werden.

8.3 Log-Aufbewahrung und Monitoring

Logs werden mindestens 90 Tage aufbewahrt
Sicherheitsrelevante Ereignisse werden automatisch erkannt und loesen Alarme aus
Kritische Systemkomponenten werden kontinuierlich ueberwacht (Monitoring & Alerting)

§ 9 Datensicherung

Automatisierte Backups: Taeglich automatisierte Sicherungen aller Produktionsdaten
Verschluesselte Speicherung: Backups werden verschluesselt und getrennt vom Produktionssystem abgelegt
Aufbewahrungszeiten: Tagesbackups 30 Tage, Monatsbackups 12 Monate
Wiederherstellungstests: Backup-Wiederherstellungen werden regelmaessig getestet und dokumentiert
RTO/RPO: Recovery Time Objective (RTO) und Recovery Point Objective (RPO) sind in der SLA verbindlich definiert
Point-in-Time Recovery: Fuer die Datenbank steht eine zeitpunktgenaue Wiederherstellung zur Verfuegung

§ 10 Schwachstellenmanagement

10.1 Patch-Management

Abhaengigkeiten (Libraries, Frameworks, Betriebssystem-Pakete) werden regelmaessig aktualisiert
Kritische Sicherheitsluecken (CVSS ≥ 9.0) werden innerhalb von 72 Stunden nach Bekanntwerden gepatcht
Hochgradige Sicherheitsluecken (CVSS 7.0–8.9) werden innerhalb von 7 Tagen behoben

10.2 Automatisiertes Schwachstellen-Scanning

Automatisierte Vulnerability-Scans werden regelmaessig ausgefuehrt und Ergebnisse dokumentiert. Bekannte Schwachstellen in eingesetzten Komponenten werden ueber Dependency-Auditing-Tools kontinuierlich ueberwacht.

10.3 Responsible Disclosure

Sicherheitsluecken koennen verantwortungsvoll an security@conport.services gemeldet werden. Gemeldete Schwachstellen werden unverzueglich bewertet und behoben. Meldende Personen erhalten eine Bestaetigung innerhalb von 5 Werktagen.

§ 11 Physische Sicherheit

EU-Rechenzentren: Alle Produktionsdaten werden ausschliesslich in Rechenzentren innerhalb der Europaeischen 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 beschraenkt (biometrische Kontrollen, Videoueberwachung, 24/7-Sicherheitspersonal)
Raeumlichkeiten CONPORT: Bueroraaume sind gegen unbefugten Zutritt gesichert; Bildschirmsperren sind vorgeschrieben

§ 12 Incident Management

12.1 Incident Response Plan

Sicherheitsvorfaelle werden gemaess dem detaillierten Incident Response Plan behandelt. Dieser definiert Erkennungs-, Eingrenzungs-, Behebungs- und Nachsorgeprozesse.

12.2 DSGVO-Meldepflicht

Datenschutzverletzungen werden der zustaendigen Aufsichtsbehoerde gemaess Art. 33 DSGVO innerhalb von 72 Stunden nach Bekanntwerden gemeldet, sofern ein Risiko fuer betroffene Personen nicht ausgeschlossen werden kann. Kunden werden unverzueglich — spaetestens innerhalb von 24 Stunden — ueber sie betreffende Vorfaelle informiert (siehe auch AVV § 7).

12.3 Eskalationsmatrix

Eine interne Eskalationsmatrix legt fuer jeden Schweregrad (P1–P4) fest, welche Personen zu benachrichtigen sind und welche Massnahmen innerhalb welcher Frist einzuleiten sind. Die Eskalationsmatrix ist Bestandteil des Incident Response Plans.

§ 13 Schulung und Sensibilisierung

Jaehrliche Pflichtschulung: Alle Mitarbeiter absolvieren jaehrlich eine Informationssicherheitsschulung, die aktuelle Bedrohungen, Richtlinien und technische Massnahmen behandelt.
Onboarding-Einweisung: Neue Mitarbeiter und externe Auftragnehmer erhalten vor dem ersten Systemzugang eine Sicherheitseinweisung und bestaetigen die Kenntnisnahme dieser Richtlinie schriftlich.
Phishing-Sensibilisierung: Regelmaessige Phishing-Simulationen und Sensibilisierungsmassnahmen schulen Mitarbeiter im Umgang mit Social-Engineering-Angriffen.
Dokumentation: Schulungsnachweise werden fuer jeden Mitarbeiter archiviert.

§ 14 Ueberpruefung und Aktualisierung

Diese Richtlinie wird regelmaessig ueberprueft und bei Bedarf aktualisiert:

Jaehrliche Ueberpruefung: Mindestens einmal im Jahr, in der Regel im ersten Quartal des Geschaeftsjahres
Nach signifikanten Vorfaellen: Nach Sicherheitsvorfaellen der Schweregrade P1 oder P2 wird die Richtlinie unverzueglich bewertet und ggf. angepasst
Nach wesentlichen Architektureaenderungen: Bei grundlegenden Aenderungen an der Plattformarchitektur oder der Infrastruktur
Bei gesetzlichen Aenderungen: Wenn neue rechtliche Anforderungen es erfordern

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

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