Sicherheit der Labud-Informatik-Webseite
Security-by-Design: Wie die Webseite von Labud Informatik bewusst schlank, robust und sicher betrieben wird – von statischem Build bis klarer Verantwortlichkeit.
Einordnung und Zielsetzung
Die Sicherheit der Labud-Informatik-Webseite folgt einem klaren Grundprinzip:
So wenig Angriffsfläche wie möglich – so viel Kontrolle wie nötig.
Die Webseite ist überwiegend statisch aufgebaut und verzichtet bewusst auf serverseitige Laufzeitlogik. Sicherheitsmaßnahmen setzen daher primär vor dem Deployment (Build-Time) sowie auf Infrastruktur- und Prozess-Ebene an, nicht in komplexer Runtime-Logik.
Ziel ist kein maximaler, sondern ein angemessener und nachvollziehbarer Sicherheitslevel, der zum Zweck, zum Datenvolumen und zur Betriebsrealität der Webseite passt.
Bedrohungsmodell (Threat Model)
Die Sicherheitsarchitektur orientiert sich an einem realistischen Bedrohungsmodell:
Explizit nicht im Scope
- Kein Benutzerkonto-System
- Keine Authentifizierung oder Autorisierung
- Keine sensiblen personenbezogenen Daten
- Keine Zahlungs- oder Transaktionsdaten
Relevante Risiken
- Manipulation ausgelieferter Inhalte
- Missbrauch von Formular-Schnittstellen (Spam, Abuse)
- Supply-Chain-Risiken im Build-Prozess
- Fehlkonfiguration der Auslieferungsinfrastruktur
Die getroffenen Maßnahmen adressieren genau diese Risikoklassen.
Architekturbedingte Sicherheitsvorteile
Statische Auslieferung
Die Webseite wird als statisches Artefakt (HTML, CSS, JavaScript) ausgeliefert. Daraus ergeben sich mehrere Sicherheitsvorteile:
- Keine serverseitige Code-Ausführung zur Laufzeit
- Keine dynamischen Datenbankabfragen
- Keine klassischen Web-Angriffsvektoren wie SQL-Injection oder Server-Side-Template-Injection
Der Webserver dient ausschließlich als Datei-Auslieferer.
Build-Time statt Runtime-Komplexität
Sicherheitsrelevante Entscheidungen werden bewusst in die Build-Phase verlagert:
- Abhängigkeiten sind versioniert und überprüfbar
- Der Build ist reproduzierbar
- Das Ergebnis ist ein unveränderliches Artefakt
Im Betrieb selbst existiert keine Logik, die manipuliert oder fehlkonfiguriert werden könnte.
Transport- und Infrastruktur-Sicherheit
HTTPS als Grundvoraussetzung
Die Webseite wird ausschließlich über HTTPS ausgeliefert. Die TLS-Terminierung erfolgt abhängig vom Hosting-Modell:
- bei GitHub Pages: durch die Plattform
- bei Docker/Nginx: durch vorgelagerte Infrastruktur (z. B. Hosting-Provider)
Der Webcontainer selbst bleibt bewusst schlank und übernimmt keine Zertifikatsverwaltung.
Minimaler Server-Footprint
Beim Betrieb mit Docker gilt:
- Ein einzelner Container
- Ein einzelner Prozess (Nginx)
- Keine Shell-Zugänge im Betrieb
- Keine persistente Speicherung
Dies reduziert die Angriffsfläche signifikant.
Formular- und Schnittstellen-Sicherheit
Kontaktformulare stellen den einzigen interaktiven Teil der Webseite dar.
Schutzmaßnahmen
- Keine direkte Mail-Exponierung im Frontend
- Validierung der Eingaben
- Trennung von Frontend und Versand-Logik
- Klare Fehlermeldungen ohne technische Details
Optional können zusätzliche Maßnahmen ergänzt werden, z. B.:
- Rate-Limiting
- Captcha-Mechanismen
- Serverseitige Spam-Filter
Diese Erweiterungen erfolgen gezielt und bedarfsorientiert.
Supply-Chain-Sicherheit
Abhängigkeiten
- Verwendung etablierter Open-Source-Bibliotheken
- Feste Versionierung (
pnpm-lock) - Regelmäßige Updates im Rahmen der Wartung
CI-Pipeline
- Automatisierter Build
- Keine Secrets im Repository
- Trennung von Build- und Deployment-Rechten
Damit wird das Risiko durch manipulierte Abhängigkeiten oder Build-Umgebungen reduziert.
Verantwortlichkeiten und Scope
Ein zentrales Sicherheitsprinzip der Webseite ist klare Verantwortlichkeit:
| Bereich | Verantwortung |
|---|---|
| Anwendungscode | Labud Informatik |
| Build-Prozess | Labud Informatik |
| Infrastruktur | Hosting-Provider |
| TLS-Zertifikate | Hosting-Provider |
| Netzwerk-Sicherheit | Hosting-Provider |
Diese Trennung ist bewusst gewählt und dokumentiert.
Was bewusst nicht umgesetzt wird
Nicht jede theoretisch mögliche Maßnahme ist sinnvoll. Bewusst verzichtet wird auf:
- Security-Theater ohne realen Mehrwert
- Komplexe Runtime-Firewalls
- Selbstbetriebene Zertifikats-Automatisierung
- Over-Engineering für nicht vorhandene Risiken
Sicherheit wird als angemessene Ingenieursdisziplin verstanden.
Fazit
Die Sicherheit der Labud-Informatik-Webseite entsteht nicht durch eine Vielzahl isolierter Maßnahmen, sondern durch:
- eine bewusst einfache Architektur
- minimale Angriffsflächen
- klare Verantwortlichkeiten
- reproduzierbare Prozesse
Das Ergebnis ist eine Webseite, die robust, nachvollziehbar und wartbar sicher betrieben werden kann – ohne unnötige Komplexität.
Sicherheit durch Klarheit, nicht durch Zufall.