📚 Improved IHK Projektdokumentation: Updated Markdown files & database logs for better clarity and organization. 🖊️🔍

IHK_Projektdokumentation/Dokumentation_Final_Markdown/Dokumentation.md

@@ -177,19 +177,21 @@ Aufräumarbeiten), noch eine verursachungsgerechte Kostenzuordnung
 möglich waren.
 
 Ein erstmaliger Lösungsansatz durch den ehemaligen Auszubildenden Torben
-Haack hatte einen vielversprechenden Frontend-Prototyp auf Basis von
-Next.js hervorgebracht. Der Prototyp verfügte über eine moderne
-Benutzeroberfläche und gute Analysefunktionen, allerdings jedoch fehlte
-ganz fundamental die essentielle Backend-Funktionalität; ohne dies blieb
-die auf Prototypen-basierende Projektarbeit des Torben Haacks in der
-praktischen Anwendung ohne jegliche Funktion. Ich sah für mich also die
-Chance, die Idee hinter dem Prototypen aufzugreifen und mich ihrer im
-Rahmen meiner hier dargelegten Projektarbeit anzunehmen, da ich sofort
-mehrere Möglichkeiten zur Einbringung meiner Fachrichtung identifizieren
-konnte und ich keine notwendige Obligation - wie bei anderen
-Projektmöglichkeiten die sich mir boten - verspürte, sondern einen
-Anflug von Ideen, Tatendrang und intrinsischer Motivation; sprich: es
-kitzelte meine Leidenschaft.
+Haack – Fachinformatiker für Daten- und Prozessanalyse – hatte einen
+vielversprechenden Frontend-Prototyp auf Basis von Next.js
+hervorgebracht. Der Prototyp verfügte über eine moderne
+Benutzeroberfläche mit umfangreichen Analysefunktionen seiner
+Fachrichtung entsprechend, allerdings fehlte die für den praktischen
+Einsatz unabdingbare Backend-Funktionalität; die cyberphysische
+Anbindung der Hardware-Komponenten lag außerhalb seines
+Kompetenzbereichs und war ursprünglich als kollaborative Ergänzung
+angedacht. Ich erkannte sofort die Synergie unserer unterschiedlichen
+Fachrichtungen: Während Haack die Datenvisualisierung und
+Prozessanalyse meisterhaft im Frontend abbildete, konnte ich mit meiner
+Spezialisierung auf digitale Vernetzung genau jene Schnittstelle zum
+cyberphysischen System schaffen, die dem Prototyp zur Produktivreife
+fehlte. Diese komplementäre Konstellation – nicht die bloße Verfügbarkeit
+eines unfertigen Projekts – weckte meine intrinsische Motivation.
 
 ## 1.2 Ableitung der Projektziele
 
@@ -248,11 +250,14 @@ Nachhinein als goldrichtig erweisen sollte.
 
 ## 1.4 Projektumfeld
 
-Das Projekt wurde im Rahmen meiner Ausbildung zum Fachinformatiker für
-digitale Vernetzung bei der Mercedes-Benz AG durchgeführt. Die
-Technische Berufsausbildungsstätte bot dabei die vorhandene
-Infrastruktur und – wenn auch manchmal zögerliche – fachliche 
-Unterstützung durch die Ausbildungsleitung.
+Die Realisierung des Projekts erfolgte in der spezifischen Konstellation
+der Mercedes-Benz-Ausbildungsumgebung – einem Mikrokosmos zwischen
+konzernweiten Standards und pragmatischer Ausbildungsrealität. Die
+Technische Berufsausbildungsstätte fungierte dabei nicht nur als
+physischer Ort, sondern als komplexes Spannungsfeld zwischen
+verfügbarer Infrastruktur, bürokratischen Prozessen und dem
+wohlwollenden, wenn auch zeitweise zögerlichen Support der
+Ausbildungsleitung.
 
 Die Zusammenarbeit mit Torben Haack erfolgte in Form einer sequenziellen
 Weiterentwicklung; ein Umstand, der sich aus der zeitlichen Versetzung
@@ -305,23 +310,26 @@ Lösungsansätzen zwang.
 
 Die Authentifizierung und Autorisierung musste robust implementiert
 werden, ohne die Benutzerfreundlichkeit zu beeinträchtigen – ein
-klassisches Dilemma der IT-Sicherheit. Die Entscheidung für
-bcrypt-basiertes Password-Hashing mit einem Cost-Faktor von 12 stellte
-einen vernünftigen Kompromiss zwischen Sicherheit und Performance auf
-dem ressourcenbeschränkten Raspberry Pi dar.
+klassisches Dilemma der IT-Sicherheit. Die Implementierung von
+bcrypt-basiertem Password-Hashing mit Cost-Faktor 12 war keine
+Entscheidung, sondern eine Selbstverständlichkeit – alles andere wäre
+fahrlässig gewesen. Der gewählte Cost-Faktor balancierte die
+kryptografische Stärke mit der begrenzten Rechenleistung des
+Raspberry Pi.
 
 Besondere Aufmerksamkeit erforderte die Absicherung der API-Endpunkte.
 Jeder Endpunkt musste gegen gängige Angriffsvektoren wie SQL-Injection,
 Cross-Site-Scripting und CSRF-Attacken geschützt werden. Die
-Implementierung eines Rate-Limiting-Mechanismus verhindert zudem
-Brute-Force-Angriffe auf die Authentifizierungsschnittstelle – eine
-Maßnahme, die sich später als weitsichtig erweisen sollte.
+Implementierung eines Rate-Limiting-Mechanismus erschwert
+Brute-Force-Angriffe auf die Authentifizierungsschnittstelle erheblich
+– verhindert sie freilich nicht vollständig, macht sie aber ökonomisch
+unattraktiv.
 
 ## 1.7 Darstellung der vorhandenen Systemarchitektur
 
-Die vorgefundene Systemarchitektur – wenn man sie denn überhaupt so
-nennen möchte – bestand aus isolierten Komponenten ohne jegliche
-Integration. Die 3D-Drucker operierten als Insellösungen, verbunden
+Die vorgefundene Systemarchitektur – möchte man sie überhaupt so
+nennen – bestand aus diffusen, operativ maximal auf ein Testnetzwerk
+begrenzten Komponenten ohne jegliche praktische Integration. Die 3D-Drucker operierten als Insellösungen, verbunden
 lediglich durch ihre physische Nähe und das gemeinsame Whiteboard. Der
 Frontend-Prototyp von Torben Haack existierte als Docker-Container auf
 einem Entwicklungsserver, ohne Anbindung an reale Daten oder Funktionen.
@@ -417,10 +425,14 @@ Die sechs TP-Link Tapo P110 Smart-Plugs bildeten das Herzstück der
 Hardware-Lösung. Jedes Gerät erhielt eine statische IP-Adresse im
 Bereich 192.168.0.100 bis 192.168.0.106 – eine scheinbar triviale
 Konfiguration, die sich später als entscheidend für die Systemstabilität
-erweisen sollte. Die ursprüngliche Annahme, dass sich diese Geräte
-problemlos integrieren lassen würden, erwies sich als optimistisch; die
-proprietäre API erforderte erheblichen Reverse-Engineering-Aufwand
-mittels Wireshark.
+erweisen sollte. Meine Zuversicht bezüglich einer einfachen Integration
+speiste sich aus meiner privaten Infrastruktur, in der ich bereits
+TAPO-Geräte aller Art erfolgreich in air-gapped Networks integriert
+hatte – allerdings mit dem entscheidenden Unterschied, dort nie mit der
+eigenständigen programmatischen Integration als Hauptkomponente
+beauftragt gewesen zu sein. Diese naive Extrapolation sollte sich
+rächen: Die proprietäre API erforderte erheblichen
+Reverse-Engineering-Aufwand mittels Wireshark.
 
 Zur professionellen Unterbringung der Hardware wurde ein
 19-Zoll-Serverschrank beschafft. Die internen Beschaffungsprozesse der
@@ -432,10 +444,15 @@ Präsentation des Projekts, die mir wichtig war.
 Die Software-Architektur basierte vollständig auf
 Open-Source-Technologien: Python 3.11 als Programmiersprache, Flask 2.3
 als Web-Framework, SQLAlchemy 2.0 für die Datenbankabstraktion und
-SQLite als Datenbanksystem. Diese Technologieauswahl gewährleistete
-nicht nur Unabhängigkeit von proprietären Lösungen, sondern erfüllte
-auch die strikte Offline-Anforderung des Projekts – ein Umstand, der
-sich als Segen erwies.
+SQLite als Datenbanksystem. Als Betriebssystem entschied ich mich nach
+anfänglicher Erwägung von NixOS letztendlich für Raspbian – die
+Verlockung deklarativer Konfiguration wich dem Pragmatismus, nicht
+unnötig zu experimentieren, wenn die Zeit ohnehin knapp bemessen war.
+Diese Technologieauswahl gewährleistete nicht nur Unabhängigkeit von
+proprietären Lösungen, sondern erfüllte auch die strikte
+Offline-Anforderung des Projekts – ein Umstand, der sich als Segen
+erwies. Firewalld übernahm die Rolle als Firewall-Service, eine
+bewährte Wahl für die granulare Netzwerkkontrolle.
 
 ## 2.3 Planung der Qualitätssicherung
 
@@ -528,6 +545,13 @@ Standards entworfen, mit klarer Trennung zwischen öffentlichen und
 authentifizierten Endpunkten. Über 100 Endpunkte wurden spezifiziert –
 eine Zahl, die zunächst übertrieben erschien, sich aber als notwendig
 erwies; jeder Endpunkt ein kleines Kunstwerk der Funktionalität.
+Ursprünglich war geplant, zusätzliche API-Endpunkte zu implementieren,
+die speziell Haacks Daten- und Prozessanalyse-Features im Frontend
+unterstützt hätten – analytische Dashboards, Auslastungsstatistiken,
+Prozessoptimierungsvorschläge. Diese ambitionierte Erweiterung fiel
+jedoch dem Zeitdruck und insbesondere dem Verlust der selbstsignierten
+Zertifikate zum Opfer, ohne die die erforderliche sichere Kommunikation
+zwischen den Komponenten nicht gewährleistet werden konnte.
 
 Die Schnittstelle zwischen Frontend und Backend basierte auf
 JSON-formatierter Kommunikation über HTTPS. Die Implementierung von
@@ -576,7 +600,13 @@ temporär.
 Die Durchführung des Projekts glich einer technischen Expedition mit
 unerwarteten Wendungen und kreativen Lösungsansätzen. Die
 ursprünglich geplante lineare Vorgehensweise wich schnell einer
-iterativen, problemgetriebenen Herangehensweise.
+iterativen, problemgetriebenen Herangehensweise. Für die
+programmatische Umsetzung der Frontend-Anpassungen nahm ich – der
+Ehrlichkeit und meiner Fachrichtung geschuldet – umfassend
+Unterstützung künstlicher Intelligenz zu Hilfe; mehr als absolut
+notwendig, um das Zeitlimit nicht um Längen zu überschreiten und die
+Profession meiner Fachrichtung digitale Vernetzung einzuhalten,
+anstatt mich in den Untiefen von React-Komponenten zu verlieren.
 
 ### 3.1.1 Datenabfrage der Sensoren
 
@@ -593,11 +623,17 @@ dritte Ansatz – Reverse Engineering mittels Wireshark – führte zum
 Durchbruch.
 
 Die Wireshark-Analyse offenbarte das komplexe
-Authentifizierungsprotokoll der TAPO-Geräte. Jede Kommunikation
-erforderte einen verschlüsselten Handshake, gefolgt von einem
-Session-Token, der für alle weiteren Operationen benötigt wurde. Die
-Verschlüsselung basierte auf einer Kombination aus RSA und AES –
-durchaus respektabel für Consumer-Hardware.
+Authentifizierungsprotokoll der TAPO-Geräte. Nach etlichem
+Herumprobieren und der Feststellung, dass die Python-Schnittstelle
+schlichtweg nicht funktionierte, zeichnete ich Netzwerkmitschnitte auf.
+Auffällig: immer dieselben Responses bei verschlüsselter Verbindung.
+Das Simulieren einzelner Anfragen blieb erfolglos – bis zum Geistesblitz:
+Die Anfragensequenz musste es sein! Tatsächlich erforderte jede
+Kommunikation einen spezifischen verschlüsselten Handshake mit
+temporärem Cookie, gefolgt von einem Session-Token für alle weiteren
+Operationen. Die proprietäre Verschlüsselung basierte auf einer
+Kombination aus RSA und AES – die Verbindungsaushandlung folgte einem
+strikt sequenziellen Muster, das keine Abweichungen tolerierte.
 
 Die Implementierung der Datenabfrage erfolgte schließlich über eine
 selbstentwickelte Wrapper-Klasse, die die Komplexität der Kommunikation
@@ -645,9 +681,23 @@ konsolidieren, vereinfachte nicht nur die Architektur, sondern
 reduzierte auch Kosten und Stromverbrauch.
 
 Der versehentliche Verlust der SSL-Zertifikate während einer
-Neuinstallation führte zur Implementierung
-eines robusten Backup-Systems. Kritische Konfigurationsdateien werden nun dreifach
-gesichert.
+Neuinstallation – genauer: die bereits von Haack genehmigten und
+mühsam durch die IT-Prozesse gebrachten Zertifikate – markierte einen
+Wendepunkt des Projekts. Bei etwa der Hälfte der Projektlaufzeit
+löschte ich in einem unachtsamen Moment genau jene Zertifikate, die
+die geplante Intranet-Integration ermöglicht hätten. Bis zu diesem
+Punkt war ich bereits so weit gekommen, dass das Frontend erfolgreich
+den GitHub OAuth-Zertifizierungsmechanismus des Unternehmens
+ansteuern konnte. Doch eine uns im E-Mail-Verkehr zuvor mitgeteilte
+IP-Adresse war – wie ich mittels zenmap-Analyse herausfand – aus
+unerfindlichen Gründen im DNS nicht mehr korrekt zugeordnet. Die
+Kombination aus verlorenen Zertifikaten und DNS-Anomalien machte die
+Intranet-Anbindung zum Zeitpunkt der Projektabgabe unmöglich; die
+Konzerngröße mit ihren entsprechend entschleunigenden Formalitäten
+und Genehmigungsprozessen ließ eine Neubeantragung innerhalb der
+verbleibenden Zeit nicht zu. Diese schmerzhafte Erfahrung führte
+immerhin zur Implementierung eines robusten Backup-Systems mit
+dreifacher Sicherung kritischer Konfigurationsdateien.
 
 Die Entscheidung, von der komplexen PyP100-Integration zu einem
 alternativen Modul zu wechseln, fiel nach tagelangen frustrierenden
@@ -721,10 +771,19 @@ erheblich, aber notwendig für die Compliance.
 
 Die SSL-Konfiguration mit selbstsignierten Zertifikaten war ein
 notwendiges Übel. Ohne Internet-Zugang war Let's Encrypt keine Option.
-Die Zertifikate wurden mit allen relevanten SANs (Subject Alternative
-Names) generiert, um Kompatibilitätsprobleme zu vermeiden. Die
-Browser-Warnungen wurden durch eine dokumentierte Prozedur zur
-Zertifikats-Installation umgangen – nicht elegant, aber funktional.
+Die Zertifikate wurden mittels OpenSSL mit allen relevanten SANs
+(Subject Alternative Names) generiert – ein Prozess, der trotz seiner
+scheinbaren Trivialität mehrere Iterationen erforderte, um
+Kompatibilitätsprobleme mit verschiedenen Browsern zu vermeiden. Die
+unvermeidlichen Browser-Warnungen wurden durch eine dokumentierte
+Prozedur zur Zertifikats-Installation umgangen, ergänzt durch die
+Installation der Mercedes Root CA-Zertifikate für die geplante
+Intranet-Integration. Zusätzlich implementierte ich einen ausgeklügelten
+Kiosk-Modus: OpenBox als minimalistisches Desktop-Environment, drei
+Chromium-Instanzen im Kiosk-Modus (Port 443 primär, Port 80 als
+Fallback, Port 5000 für lokalen Kiosk-Zugriff), automatischer Start via
+systemd-Service – eine Lösung, die nach Tests in VirtualBox nahtlos auf
+die Produktivumgebung übertragen werden konnte.
 
 Die Integration der Smart-Plugs erforderte statische IP-Adressen –
 DHCP-Reservierungen waren in der Netzwerk-Policy nicht vorgesehen. Die
@@ -744,11 +803,13 @@ API-Endpunkte wurden systematisch gegen die OWASP Top 10 abgesichert.
 Input-Validation erfolgte auf mehreren Ebenen – Client-seitig für UX,
 Server-seitig für Sicherheit; Vertrauen ist gut, Kontrolle ist besser.
 
-Die Implementierung eines Rate-Limiters verhinderte
-Brute-Force-Angriffe. Nach fünf fehlgeschlagenen Login-Versuchen wurde
-die IP-Adresse für 30 Minuten gesperrt – lang genug, um Angriffe
-unwirtschaftlich zu machen, kurz genug, um legitime Nutzer nicht
-übermäßig zu frustrieren; ein Balanceakt zwischen Sicherheit und
+Die Implementierung eines Rate-Limiters erschwerte
+Brute-Force-Angriffe erheblich – wenngleich eine vollständige
+Verhinderung illusorisch bleibt. Nach fünf fehlgeschlagenen
+Login-Versuchen wurde die IP-Adresse für 30 Minuten gesperrt – lang
+genug, um Angriffe ökonomisch unattraktiv zu machen, kurz genug, um
+legitime Nutzer bei versehentlichen Fehleingaben nicht übermäßig zu
+frustrieren; ein kalkulierter Kompromiss zwischen Sicherheit und
 Benutzerfreundlichkeit.
 
 DSGVO-Compliance wurde durch Privacy-by-Design erreicht.
@@ -893,13 +954,34 @@ werden können.
 # Anlagen
 
 ## Netzwerkdiagramme und Systemarchitektur
+- Netzwerktopologie der TBA-Infrastruktur
+- Systemarchitektur MYP
+- zenmap-Visualisierung der DNS-Anomalie
 
 ## API-Dokumentation
+- Vollständige REST-API-Spezifikation
+- Authentifizierungs-Flows
+- Beispiel-Requests und Responses
 
 ## Benutzerhandbuch
+- Installation und Konfiguration
+- Bedienungsanleitung für Endanwender
+- Administratorhandbuch
 
 ## Testprotokolle
+- Unit-Test-Ergebnisse
+- Integrationstests
+- Performance-Messungen
+- Sicherheitsaudits
 
 ## Screenshots der Benutzeroberfläche
+- Dashboard-Ansicht
+- Reservierungskalender
+- Administrationsbereich
+- Kiosk-Modus
 
 ## Konfigurationsdateien und Deployment-Skripte
+- systemd-Service-Definitionen
+- OpenSSL-Zertifikatsgenerierung
+- Firewalld-Konfiguration
+- Backup-Skripte