| | |
|---|
| | | automatisch selbst eingetragen (`Add-MpPreference`) |
|---|
| | | - Firewall-Freigabe-Skript ergänzt, nachdem der Test im echten |
|---|
| | | Firmennetzwerk anstand (Port 5000 war durch die Windows-Firewall blockiert) |
|---|
| | | - **Installer-Dateien werden direkt ins Paket gebündelt statt zur Laufzeit |
|---|
| | | nachzuladen.** Auslöser: beim ersten Test im Firmennetz enthielt der |
|---|
| | | Download nur die Skript-Dateien, die eigentlichen Installer wurden erst |
|---|
| | | beim Ausführen auf dem Zielrechner per Netzwerk nachgeladen – das setzt |
|---|
| | | Netzwerkzugriff des Zielrechners auf den Server in genau dem Moment |
|---|
| | | voraus. Jetzt werden die Dateien beim Erzeugen des Pakets direkt mit |
|---|
| | | eingepackt, der Zielrechner braucht für die Installation selbst kein |
|---|
| | | Netzwerk mehr (nur die abschließende, optionale Protokoll-Meldung). |
|---|
| | | |
|---|
| | | ## v9 – Zugriffsbeschränkung lokal (Server) vs. Netzwerk |
|---|
| | | Auslöser: Wird der Server über das Netzwerk erreicht (nicht direkt am |
|---|
| | | Server), soll nur die Software-Anforderung sichtbar sein, um "Blödsinn" zu |
|---|
| | | verhindern (Katalog verändern, Protokolle einsehen usw. nur direkt am |
|---|
| | | Server). Wer aus dem Netzwerk Software herunterlädt, muss sich mit Namen |
|---|
| | | eintragen, und alle Zugriffe werden protokolliert. |
|---|
| | | - Unterscheidung über `request.remote_addr` (127.0.0.1/::1 = lokal, alles |
|---|
| | | andere = Netzwerk) |
|---|
| | | - Für Netzwerk-Zugriffe: alle Routen außer der Software-Anforderung |
|---|
| | | (`/einrichten`) geben 403 mit Hinweisseite zurück |
|---|
| | | - Software-Anforderung heißt bei Netzwerkzugriff bewusst anders |
|---|
| | | ("Software anfordern" statt "Rechner einrichten") und weist auf die |
|---|
| | | Protokollierung hin |
|---|
| | | - Neues Zugriffsprotokoll (`/zugriffslog`, ebenfalls nur lokal einsehbar): |
|---|
| | | Zeitpunkt, IP-Adresse, per Reverse-DNS ermittelter Rechnername (falls |
|---|
| | | auflösbar), selbst angegebener Name, Aktion |
|---|
| | | - **Bewusst nicht umgesetzt:** echte Windows-Benutzername-Erkennung. Das |
|---|
| | | bräuchte NTLM/Kerberos-Integration (z. B. IIS-Reverse-Proxy vor Flask), |
|---|
| | | was über reines Flask/HTTP nicht möglich ist – im Architektur-Dokument als |
|---|
| | | offener Punkt festgehalten, nicht stillschweigend als "erledigt" behandelt |
|---|
| | | |
|---|
| | | ## Offene Design-Frage: Skript-Ansatz vs. automatische Verteilung |
|---|
| | | Nach dem ersten Test im Firmennetz wurde nochmal grundsätzlich hinterfragt, |
|---|
| | | ob der Skript-Ansatz (manueller Download + Ausführen auf dem Zielrechner) |
|---|
| | | der richtige Weg ist, oder ob Daten "automatisch" auf dem Zielrechner landen |
|---|
| | | sollten. Eine echte automatische Verteilung ohne manuellen Schritt am |
|---|
| | | Zielrechner würde entweder eine dauerhaft laufende Helfer-Software auf jedem |
|---|
| | | Zielrechner oder Windows-Remoting (PowerShell Remoting) voraussetzen – beide |
|---|
| | | Wege brauchen im Kern eine Domänen-Infrastruktur bzw. zentrale |
|---|
| | | Zugangsdaten-Verwaltung, die aktuell nicht vorhanden ist. Diese Frage wurde |
|---|
| | | bewusst nicht in diesem Prototyp entschieden, sondern als offener Punkt für |
|---|
| | | die Übernahme festgehalten (siehe README.md). |
|---|
| | | |
|---|
| | | ## Testmethodik (durchgehend) |
|---|
| | | Da die Zielumgebung Windows ist, die Entwicklung aber in einer Linux-Umgebung |
|---|
