Sicherheits-Checkliste für Integrationen #

Diese Seite ist für die Person, die eine Integration vor dem Livegang prüft, und danach einmal im Jahr erneut. Jeder Punkt nennt, wo er zu prüfen ist. Die Gründe hinter den Punkten stehen auf Sicherheit für Integrationen.

Inhalt #

1. Zugangsdaten
2. Konten und Rechte
3. Transport
4. Eingabe und Ausgabe
5. Protokollierung und Audit
6. Datenschutz
7. Bereitschaft für Vorfälle
8. Freigabe

Zugangsdaten #

• To do: Kein Geheimnis im Repository der Erweiterung oder in seiner Historie (suchen Sie nach expk_, expt_, password, secret, key).
• To do: Geheimnisse nur in settings/override/*.ini.append.php (außerhalb von Git gehalten) oder in der Umgebung.
• To do: Ein Satz Zugangsdaten pro Integration, Umgebung und Zweck; die Namen sagen, welcher.
• To do: API-Schlüssel auf die nötigen Bereiche (Scopes) beschränkt; Ablaufdaten gesetzt; Rotationstermin im Kalender (Persönliche API-Schlüssel).
• To do: OAuth-Client-Geheimnisse nur auf Servern; oauth/authorize nur für die Rollen, die es brauchen.
• To do: Zugangsdaten, die das Personal des Integrators kannte, werden bei der Übergabe rotiert.

Konten und Rechte #

• To do: Ein Dienstkonto pro Integration; keine Administratorrolle (Dienstkonten).
• To do: Richtlinien so weit wie möglich nach Teilbaum, Klasse, Sektion und Sprache eingeschränkt.
• To do: Ein verbotener Aufruf wurde ausprobiert und mit 403 beantwortet.
• To do: Skripte laufen als Betriebssystembenutzer der Website, nicht als root.
• To do: LDAP: eigenes Bind-Konto nur mit Leserechten; LDAPDebugTrace=disabled.
• To do: SSO-Handler: Der vertrauenswürdige Header kann nur vom Proxy kommen; Administratoren melden sich auf andere Weise an.

Transport #

• To do: HTTPS bei jeder API und jedem Webhook, in beide Richtungen; rest.ini [Authentication] RequireHTTPS erwogen.
• To do: Zertifikatsprüfung bei jedem ausgehenden Aufruf eingeschaltet.
• To do: SFTP statt FTP; Host-Schlüssel ausdrücklich als vertrauenswürdig hinterlegt.
• To do: LDAP über ldaps://.
• To do: Endpunkte, die nur andere Systeme nutzen, sind wo möglich am Webserver auf deren Adressen beschränkt.

Eingabe und Ausgabe #

• To do: Jeder Wert aus einem anderen System wird geprüft (Typ, Länge, erlaubte Zeichen); IDs werden in Ganzzahlen umgewandelt.
• To do: Eigenes SQL verwendet (int) und $db->escapeString(); keine Verkettung von Zeichenketten aus ungeprüfter Eingabe.
• To do: Rich Text wird in eine erlaubte Menge von Elementen umgewandelt; kein rohes HTML in Templates.
• To do: URLs: nur https/http; unsichere Schemata abgewiesen.
• To do: Dateiimporte bleiben innerhalb des Importverzeichnisses unter var/; Größen begrenzt.
• To do: Ausgehende Aufrufe an Adressen aus Daten weisen private und Loopback-Adressen ab; Timeouts und Größengrenzen gesetzt.
• To do: Eigene Endpunkte prüfen den Zugriff (canRead(), Richtlinien) und verlangen für Schreibzugriffe POST und das Formular-Token.
• To do: Antworten enthalten keine Passwörter, Tokens oder personenbezogenen Daten, die der Aufrufer nicht braucht.

Protokollierung und Audit #

• To do: Eine Zusammenfassungszeile pro Lauf im Protokoll der Integration; Fehler in error.log über eZDebug::writeError().
• To do: Keine Geheimnisse oder vollständigen Nutzdaten mit personenbezogenen Daten in irgendeinem Protokoll.
• To do: Die Aktivität des Dienstkontos nach den ersten Läufen im Audit geprüft (exp:audit tail).
• To do: Abweisungen (access.apikey.use.failed, access.permission.refused) werden beobachtet.
• To do: Falls gefordert, werden Sicherheitsereignisse über die Syslog- oder Webhook-Senke an das SIEM gesendet (Ausgehende Webhooks).

Datenschutz #

Diese Punkte sind Praxis, keine Rechtsberatung.

• To do: Jeder Fluss mit personenbezogenen Daten ist mit Zweck, Feldern, Empfängern und Aufbewahrung aufgeführt.
• To do: Auftragsverarbeiter (E-Mail-Anbieter, KI-Anbieter, CDN, SaaS-Suche) sind dem Kunden bekannt und durch Vereinbarungen abgedeckt.
• To do: Nur nötige Felder werden gesendet; Exporte werden gelöscht, wenn sie nicht mehr gebraucht werden.
• To do: Gesammelte Formulardaten werden aus Exponential entfernt, wenn die Aufbewahrung endet.
• To do: Testdaten werden anonymisiert, wenn eine Kopie der Produktion die Produktion verlässt.

Bereitschaft für Vorfälle #

• To do: Das Runbook sagt, wie jeder Satz Zugangsdaten sofort widerrufen wird.
• To do: Das Runbook sagt, wie jeder Fluss angehalten wird (Setup > Cronjobs, Anhalten).
• To do: Ansprechpartner für jedes andere System und für Sicherheit sind aufgeführt.
• To do: Sicherheitslücken in Exponential werden vertraulich an [email protected] gemeldet.

Freigabe #

Integration: ...............   Version: .........   Environment: production
Reviewed by: ...............   Date: .........
Open findings (id, severity, owner, due): ...............
Decision: go-live approved / approved with conditions / not approved

Auf Deutsch: Integration, Version, Umgebung (Produktion); geprüft von, Datum; offene Befunde (ID, Schweregrad, Verantwortlicher, Frist); Entscheidung: Livegang freigegeben / unter Auflagen freigegeben / nicht freigegeben.

Verwandte Seiten #

• Sicherheit für Integrationen
• Checkliste für die Sicherheitsprüfung beim Hosting
• Checklisten zu Barrierefreiheit, Sicherheit und Compliance
• Checkliste zum Livegang einer Integration
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.