Technische und organisatorische Maßnahmen

Maßnahmen nach Art. 32 DSGVO für den Betrieb von SVEMS.

Stand: 2. September 2026 · Anlage 2 zum Auftragsverarbeitungsvertrag · Verantwortlich: Green Energy Tools GmbH, Friedrichstraße 155, 10117 Berlin · datenschutz@green-energy-tools.de

1. Überblick über die Systemlandschaft

Ein Objektspeicher eines Cloud-Anbieters wird nicht eingesetzt; hochgeladene Dateien liegen auf dem verschlüsselten EFS-Dateisystem in unserer eigenen VPC.

2. Vertraulichkeit (Art. 32 Abs. 1 lit. b DSGVO)

2.1 Zutrittskontrolle

Es wird keine eigene Hardware betrieben. Der physische Zutrittsschutz obliegt den Rechenzentrumsbetreibern Amazon Web Services (Frankfurt am Main) und Hetzner Online GmbH (Deutschland), die hierfür jeweils zertifiziert sind (u. a. ISO 27001). Deren Nachweise fordern wir im Rahmen der Unterauftragskontrolle an.

2.2 Zugangskontrolle (Systemzugang)

• Zugang zur Anwendung ausschließlich über persönliche, benannte Benutzerkonten; keine Sammel- oder Funktionskonten.
• Passwörter werden ausschließlich als bcrypt-Hash gespeichert; Klartextpasswörter existieren zu keinem Zeitpunkt in Datenbank, Protokollen oder Backups.
• Mindestanforderungen an die Passwortlänge sowie Bestätigung der E-Mail-Adresse vor Erstnutzung (Devise validatable, confirmable).
• API-Zugangsschlüssel werden nur als Hash gespeichert (api_token_digest); der Klartext wird einmalig bei Erzeugung angezeigt.
• Sitzungs-Cookies sind signiert und als HttpOnly sowie SameSite=Lax gesetzt, in Produktion zusätzlich Secure.
• Der administrative Serverzugang erfolgt über SSH mit Schlüsselpaaren; Passwort-Login ist nicht vorgesehen.
• Die Datenbank ist nicht öffentlich erreichbar (publicly_accessible = false) und nur aus dem privaten Subnetz der Anwendung heraus zugänglich; Zugriff wird über Security Groups auf die Anwendungsinstanzen eingeschränkt.

2.3 Zugriffskontrolle (Berechtigungen)

• Rollen- und mandantenbasierte Autorisierung über eine zentrale Policy-Schicht (action_policy); jede Ressource wird gegen die Organisationszugehörigkeit des Aufrufers geprüft.
• Trennung nach Organisationen: Projekte, Simulationen, Berichte und Vorlagen sind einer Organisation zugeordnet; ein organisationsübergreifender Zugriff ist nicht vorgesehen.
• Anonyme Berechnungen im Endkundenbereich sind über ein zufällig erzeugtes, nicht erratbares Kennzeichen plus signiertes Cookie an den jeweiligen Browser gebunden; ein Zugriff auf fremde Berechnungen ist darüber nicht möglich.
• Der Kreis der Personen mit administrativem Zugriff auf Produktivsysteme ist auf die technisch verantwortlichen Personen beschränkt und wird bei personellen Änderungen unverzüglich angepasst.

2.4 Trennungskontrolle

• Produktion, Staging und Entwicklung laufen in getrennten Umgebungen mit getrennten Datenbanken und getrennten Zugangsdaten.
• Mandantentrennung erfolgt logisch über die Organisationszuordnung und wird bei jedem Zugriff durch die Policy-Schicht erzwungen.
• Hintergrundverarbeitung ist in getrennte Warteschlangen-Pools unterteilt, sodass Integrationslast Simulationsläufe nicht beeinträchtigt.

2.5 Pseudonymisierung und Verschlüsselung

• Transportverschlüsselung: ausschließlich HTTPS. Der Load Balancer erzwingt TLS ab Version 1.2 (ELBSecurityPolicy-TLS-1-2-2017-01) mit einem Zertifikat aus dem AWS Certificate Manager; unverschlüsselte Aufrufe werden per HTTP 301 auf HTTPS umgeleitet. Die Anwendung setzt zusätzlich force_ssl.
• Dateiablage: Das EFS-Dateisystem mit allen hochgeladenen Dateien ist verschlüsselt (encrypted = true).
• Anwendungsebene: Zugangsdaten für Drittsysteme (OAuth-Access- und Refresh-Token, Webhook-Secrets) werden mit Active Record Encryption verschlüsselt in der Datenbank abgelegt. Passwörter und API-Schlüssel werden ausschließlich gehasht gespeichert.

3. Integrität (Art. 32 Abs. 1 lit. b DSGVO)

3.1 Weitergabekontrolle

• Jede Übermittlung an Unterauftragnehmer erfolgt ausschließlich über TLS-gesicherte Verbindungen.
• Der Rechenknoten für Simulationen erhält keine Anschriften und keine Geokoordinaten, sondern ausschließlich die für die Berechnung erforderlichen Zeitreihen und Parameter.
• Die Kommunikation zwischen Anwendung und Rechenknoten ist beidseitig tokenbasiert authentifiziert.
• Eine vollständige Übersicht aller Empfänger führen wir in der öffentlich einsehbaren Unterauftragnehmerliste.

3.2 Eingabekontrolle

• Erstellungs- und Änderungszeitpunkte werden für alle fachlichen Datensätze geführt; Projekte und Simulationen sind der erzeugenden Person und Organisation zugeordnet.
• Anwendungs- und Zugriffsprotokolle werden zentral in CloudWatch Logs gesammelt und dort 20 Tage aufbewahrt.
• Änderungen an der Anwendung erfolgen ausschließlich über versionierte Deployments aus der Versionsverwaltung; ein manuelles Bearbeiten von Code auf Produktivsystemen findet nicht statt.

3.3 Schutz gegen typische Angriffe

• Schutz vor websiteübergreifender Anfragenfälschung (CSRF) durch signierte Formular-Token.
• Schutz vor SQL-Injection durch ausschließlich parametrisierte Abfragen des eingesetzten ORM.
• Content Security Policy mit script-src 'self': Es kann kein Skript von einer fremden Herkunft ausgeführt werden. Die Richtlinie läuft derzeit im Melde-Modus und wird nach Auswertung der Meldungen scharf geschaltet.
• Begrenzung der Anfragerate je IP-Adresse im offen zugänglichen Endkundenbereich zur Abwehr automatisierter Massennutzung.
• Statische Sicherheitsanalyse des Anwendungscodes mit Brakeman als Teil der Entwicklung.

4. Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b DSGVO)

• Betrieb in einer eigenen VPC über zwei Availability Zones mit vorgelagertem Load Balancer und Health Checks.
• Datenbank-Snapshots der Produktionsdatenbank; die Wiederherstellung erfolgt aus einem Snapshot in eine neue Instanz.
• Die gesamte Infrastruktur ist als Terraform-Code beschrieben und damit reproduzierbar neu aufsetzbar.
• Anwendungsprotokolle liegen außerhalb der Instanzen in CloudWatch und überstehen daher den Verlust einer Instanz.
• Schutz vor Datenverlust durch Bedienfehler: fachliche Löschvorgänge laufen über definierte Abhängigkeiten, sodass zusammengehörige Datensätze konsistent entfernt werden.

5. Verfahren zur regelmäßigen Überprüfung (Art. 32 Abs. 1 lit. d DSGVO)

• Datenschutz-Management: Verzeichnis der Verarbeitungstätigkeiten, Löschkonzept und Datenpannen-Prozess werden geführt und mindestens jährlich überprüft.
• Unterauftragskontrolle: Die Unterauftragnehmerliste wird bei jeder Änderung fortgeschrieben und mindestens jährlich vollständig überprüft, einschließlich der Frage, ob die vertraglichen Grundlagen noch aktuell sind.
• Überprüfung der Maßnahmen: Dieses Dokument wird mindestens jährlich sowie anlassbezogen bei wesentlichen Änderungen der Systemlandschaft überprüft und fortgeschrieben.
• Meldung von Schwachstellen: Sicherheitsforschende erreichen uns über die maschinenlesbare Kontaktdatei unter /.well-known/security.txt sowie unter datenschutz@green-energy-tools.de.
• Vorfallsbehandlung: Für Verletzungen des Schutzes personenbezogener Daten besteht ein dokumentierter Prozess mit Meldung an den Verantwortlichen ohne schuldhaftes Zögern (siehe § 8 des Auftragsverarbeitungsvertrags).

6. Auftragskontrolle

• Verarbeitung ausschließlich auf dokumentierte Weisung des Verantwortlichen.
• Sämtliche zum Zugriff berechtigten Personen sind auf Vertraulichkeit verpflichtet.
• Mit allen Unterauftragnehmern bestehen Verträge nach Art. 28 DSGVO; die eingesetzten Unterauftragnehmer sind in Anlage 1 abschließend benannt.
• Über beabsichtigte Änderungen im Kreis der Unterauftragnehmer informieren wir vorab in Textform.

7. Angemessenheit

Die Maßnahmen berücksichtigen den Stand der Technik, die Implementierungskosten sowie Art, Umfang, Umstände und Zwecke der Verarbeitung und die Eintrittswahrscheinlichkeit und Schwere der Risiken für die Rechte und Freiheiten natürlicher Personen. Verarbeitet werden im Wesentlichen geschäftliche Kontakt- und Projektdaten sowie Verbrauchs- und Lastgangdaten. Besondere Kategorien personenbezogener Daten nach Art. 9 DSGVO werden nicht verarbeitet.

Als besonders schutzbedürftig behandeln wir die Lastgangdaten: Eine hoch aufgelöste Verbrauchszeitreihe lässt Rückschlüsse auf Anwesenheits-, Betriebs- und Produktionsmuster zu. Für diese Daten gelten daher dieselben Zugriffs- und Trennungsmaßnahmen wie für Stammdaten, und sie werden bei Übermittlung an den Rechenknoten bewusst ohne Standortbezug übergeben.