From 548bab93e55f6e514557571d3c9da9b1c1d59c35 Mon Sep 17 00:00:00 2001
From: Server-Bibliothek <server-bibliothek@lokal>
Date: Do, 23 Jul 2026 15:07:49 +0200
Subject: [PATCH] Zugriffsbeschraenkung: voller Zugriff nur lokal am Server, Netzwerk nur Software-Anforderung + Zugriffsprotokoll

---
 ARCHITEKTUR.md |   49 ++++++++++++++++++++++++++++++++++++++++++-------
 1 files changed, 42 insertions(+), 7 deletions(-)

diff --git a/ARCHITEKTUR.md b/ARCHITEKTUR.md
index e90bc6b..9af377f 100644
--- a/ARCHITEKTUR.md
+++ b/ARCHITEKTUR.md
@@ -197,15 +197,50 @@
 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.

--
Gitblit v1.9.3