Reverse Proxy & SSL Betrieb
Nginx/Apache-Reverse-Proxy mit TLS, Headern und korrekten Weiterleitungen.
Kurz erklärt
Diese Seite beschreibt den Arbeitsstandard für Reverse Proxy & SSL Betrieb – mit Fokus auf konkrete Entscheidungen statt allgemeiner Leitlinien.
Zentral sind hier vor allem welche header moodle vertraut und tls-/redirect-standard, damit Teams denselben Maßstab anwenden.
Nachvollziehbar wird der Standard erst durch verlinkte Nachweise wie proxy-konfiguration und durch dokumentierte Grenzfälle/Ausnahmen.
Wann diese Seite hilft
Typische Situationen, in denen diese Seite als Arbeitsdokument Mehrwert bringt – und wo eine andere Doku passender ist.
Typische Einsätze
- wenn bei Reverse Proxy & SSL Betrieb technische Standards zu reverse-proxy/load-balancer-regeln verbindlich dokumentiert werden müssen
- wenn Teamwechsel/Vertretung denselben Ablauf für welche header moodle vertraut sicher ausführen soll
- wenn Störungen oder Changes zeigen, dass Nachweise wie proxy-konfiguration bisher fehlen
- wenn Konfig- oder Betriebsabweichungen (z. B. forwarded-header sind inkonsistent) wiederholt auftreten
Eher nicht passend bei
- wenn es bei Reverse Proxy & SSL Betrieb nur um einen einmaligen Einzelfall ohne Standardisierungsbedarf geht
- wenn ein detailliertes Projektticket oder eine technische Schritt-für-Schritt-Anleitung gepflegt werden soll
Empfohlener Ablauf
Pragmatische Reihenfolge, die in der Praxis funktioniert – vom Scope bis zum Review.
- Ist-Stand und Scope für Reverse Proxy & SSL Betrieb erfassen, inklusive reverse-proxy/load-balancer-regeln und kritischer Abhängigkeiten.
- Sollzustand / Standards festlegen; wichtig sind Entscheidungen zu welche header moodle vertraut.
- Änderungen kontrolliert testen (Staging, Testsystem oder Checkliste) und Ergebnis dokumentieren.
- Produktiv umsetzen, Nachtests durchführen und proxy-konfiguration + tls-testnachweise verlinken.
- Monitoring/Reviews auswerten und wiederkehrende Befunde wie „Forwarded-Header sind inkonsistent“ in den Standard einarbeiten.
Entscheidungsregeln
Reverse Proxy & SSL Betrieb ist gut dokumentiert, wenn Regeln, Grenzfälle und Nachweise so konkret sind, dass Teams damit ohne Zusatzabsprachen arbeiten können.
Entscheidungsrahmen
Für Reverse Proxy & SSL Betrieb zuerst den Anwendungsbereich konkret machen: Reverse-Proxy/Load-Balancer-Regeln.
Verantwortung
Entscheidungen zu welche header moodle vertraut und tls-/redirect-standard nicht implizit lassen, sondern Rollen und Freigaben explizit benennen.
Abweichungsregeln
Ausnahmen nur zulassen, wenn sie den Standard nicht aufweichen; besonders relevant sind hier ssl/tls-zertifikate und header.
Review-Auslöser
Prüfbar ist die Regel erst, wenn proxy-konfiguration und tls-testnachweise sauber verlinkt sind.
Was dokumentiert werden soll
Hier nur die spezifischen Inhalte zu Reverse Proxy & SSL Betrieb pflegen; allgemeine Doku-Regeln bleiben in der zentralen Leitlinie. Zentrale Leitlinie.
Die Seite ist dann gut, wenn eine Vertretung den Standard anwenden oder prüfen kann, ohne erst Personenwissen einsammeln zu müssen.
Kontext
Begriffe, Scope und Grenzen zu Reverse Proxy & SSL Betrieb konkretisieren – inklusive reverse-proxy/load-balancer-regeln.
Umsetzungsvorgaben
Den Standard so notieren, dass welche header moodle vertraut und änderungsweg für proxy-regeln eindeutig entschieden sind.
Prüfpfad
Artefakte direkt nennen und verlinken: Proxy-Konfiguration, TLS-Testnachweise, Smoke-Tests nach Änderung.
Offene Punkte / Ausnahmen
Aktive Ausnahmen, letzte Änderung und nächster Review gehören auf die Seite – besonders bei Themen mit ssl/tls-zertifikate und header.
Typische Stolperfallen
Pflege hier echte Fallstricke aus der Praxis von Reverse Proxy & SSL Betrieb; allgemeine Hinweise gehören in die zentrale Leitlinie. Zentrale Leitlinie.
- Umfang driftet: Forwarded-Header sind inkonsistent.
- Regel bleibt abstrakt: SSL-Verlängerung ist nicht im Ablauf verankert.
- Nachweis fehlt: Timeouts passen nicht zu Uploads.
- Ausnahme entgleist: Staging und Produktion driften auseinander.
Moodle-Referenz (offizielle Doku 5.1)
Kurze Verweise auf die offizielle Moodle-Dokumentation für Reverse Proxy & SSL Betrieb. So bleibt diese Seite AFANDI-spezifisch und vermeidet doppelte Grundlagen.
Offizielle Referenzen
Dokumentationsfokus
- Proxy/SSL-Setup inkl. Header-Weitergabe, HTTPS-Weiterleitung und Health-Checks dokumentieren.
- UI-Pfad, Rolle und Testfall explizit notieren (nicht nur den gewünschten Endzustand).
- Abweichungen von AFANDI-Standards separat markieren, damit Updates leichter reviewbar bleiben.
Prüfung & Pflege
Prüfe diese Seite gegen reale Vorgänge zu Reverse Proxy & SSL Betrieb – nicht nur gegen den Wortlaut. Entscheidend ist, ob Standard, Ausnahmen und Nachweise im Alltag tragen.
- Stimmen Header-/SSL-Settings mit Moodle-Anforderungen überein?
- Sind Zertifikatsläufe dokumentiert?
- Wurden Redirects getestet?
- Stimmen Konfiguration und Doku überein?
Prüf-Fokus für „Reverse Proxy & SSL Betrieb“: Moodle-Betrieb; prüfe dabei insbesondere reverse-proxy/load-balancer-regeln.
Sinnvolle Kennzahlen
Wenige Kennzahlen genügen – wichtig ist, dass sie Entscheidungen oder Verbesserungen auslösen.
Für „Reverse Proxy & SSL Betrieb“ Kennzahlen direkt an welche header moodle vertraut und die häufigsten Praxisrisiken koppeln.
TLS-Fehler
Fehler bei Zertifikat/Handshake
Intervall: monatlich
Proxy-Timeouts
Anzahl Timeout-Ereignisse am Proxy
Intervall: monatlich
Config-Änderungen mit Testnachweis
Anteil Proxy-Changes mit Smoke-Test
Intervall: monatlich
Nächste Schritte
Ergänze jetzt die konkrete Entscheidung zu welche header moodle vertraut inkl. Verantwortlichen, Datum und Verweis auf proxy-konfiguration.
Auf „Reverse Proxy & SSL Betrieb“ als Nächstes besonders klar machen: welche reverse-proxy/load-balancer-regeln im Standardfall gelten und welche Ausnahmen befristet sind.