| | |
| | | aktuell `C:\ClientBibliothek`) – zentral anpassbar, falls die Infrastruktur |
| | | einen anderen Standardpfad vorgibt. |
| | | |
| | | ## 6a. Zugriffsbeschränkung: lokal (Server) vs. Netzwerk |
| | | |
| | | Seit Runde r17 unterscheidet die Anwendung, ob eine Anfrage direkt vom Server |
| | | selbst kommt (z. B. per RDP-Sitzung, im Browser dort `localhost`/`127.0.0.1` |
| | | aufgerufen) oder über das Netzwerk von einem anderen Rechner. |
| | | |
| | | - `ist_lokaler_zugriff()` prüft `request.remote_addr` gegen `127.0.0.1`/`::1` |
| | | - `@app.before_request`-Hook `_zugriff_beschraenken()` blockiert für |
| | | Netzwerk-Zugriffe alle Routen außer denen in `OEFFENTLICHE_ENDPUNKTE` |
| | | (aktuell nur `einrichten` und `static`) mit einer 403-Seite |
| | | - Die Seite `/einrichten` zeigt sich bei Netzwerkzugriff unter anderem Namen |
| | | ("Software anfordern" statt "Rechner einrichten") und mit Hinweis auf die |
| | | Protokollierung |
| | | - Jeder Aufruf/Download über `/einrichten` wird in der Tabelle `zugriffslog` |
| | | festgehalten (Zeitpunkt, IP-Adresse, per Reverse-DNS ermittelter |
| | | Rechnername falls auflösbar, selbst angegebener Name, Aktion) – einsehbar |
| | | unter `/zugriffslog` (selbst wieder nur lokal erreichbar) |
| | | |
| | | **Wichtige Einschränkung:** Ein echter Windows-Benutzername lässt sich über |
| | | reines HTTP **nicht** zuverlässig ermitteln – dafür wäre eine |
| | | NTLM/Kerberos-Integration nötig (z. B. über einen IIS-Reverse-Proxy vor |
| | | Flask, der die Windows-Anmeldung übernimmt und den Benutzernamen per Header |
| | | an die Flask-App durchreicht). Das ist in diesem Prototyp **nicht** |
| | | umgesetzt. Aktuell basiert die Identifizierung auf der IP-Adresse, einem per |
| | | Reverse-DNS aufgelösten Rechnernamen (funktioniert nur, wenn im |
| | | Firmennetzwerk DNS-Einträge für Client-Rechner existieren) und dem selbst im |
| | | Formular angegebenen Namen (nicht verifiziert). Für eine belastbarere |
| | | Identifizierung müsste diese IIS/NTLM-Integration nachgerüstet werden. |
| | | |
| | | **Anpassung an andere Infrastruktur:** Sollte der Server z. B. hinter einem |
| | | Reverse-Proxy laufen, liefert `request.remote_addr` ggf. die Proxy-IP statt |
| | | der echten Client-IP – in dem Fall müssten `X-Forwarded-For`-Header |
| | | ausgewertet werden (aktuell nicht implementiert, da kein Proxy im Einsatz). |
| | | |
| | | ## 7. Bekannte Grenzen / nicht vollständig getestet |
| | | |
| | | - **Keine Authentifizierung.** Es gibt kein Login-System. Jeder, der den |
| | | Server im Netzwerk erreichen kann, kann Software verwalten, Installer |
| | | herunterladen und Installations-Pakete erzeugen. Das war für den internen, |
| | | vertrauenswürdigen Einsatz im Firmennetz eine bewusste Vereinfachung – |
| | | **bei einer Anpassung an eine andere/größere Infrastruktur unbedingt |
| | | prüfen, ob das so bleiben darf**, insbesondere wenn der Server auch von |
| | | außerhalb des Firmennetzes erreichbar sein könnte. |
| | | - **Keine echte Authentifizierung, nur Herkunfts-Beschränkung.** Seit r17 |
| | | ist die Verwaltung (Katalog, Protokolle, Zugriffsprotokoll) nur noch vom |
| | | Server selbst aus erreichbar (siehe Abschnitt 6a) – das ist aber eine |
| | | Netzwerk-/IP-basierte Einschränkung, **kein Login mit Benutzername/Passwort**. |
| | | Wer direkt am Server sitzt (oder sich als diesen ausgibt, z. B. über |
| | | IP-Spoofing im selben Netzwerksegment), hat vollen Zugriff. Für ein |
| | | belastbares Sicherheitskonzept mit echten Benutzerkonten wäre ein |
| | | richtiges Login-System nötig. |
| | | - **Kein HTTPS/TLS.** Die Kommunikation läuft unverschlüsselt über HTTP. Für |
| | | ein internes, abgeschottetes Netzwerk meist unkritisch, sollte aber vor |
| | | einem größeren Rollout bewertet werden. |