ScB-2-4

pflichtenheft.md

@@ -71,8 +71,9 @@
 
 *Phase 2: Schülerzugang braucht mehr Nutzer…. Zugriffe / Tag steigen auch.*
 
-| **300 aktuellen Nutzern**  <br>Das System muss mindestens 300 aktuelle Benutzer unterstützen, die das System administrieren, bearbeiten und nutzen können. Nicht jeder Benutzer benötigt ein eigenes Profil. | HW-1 |
+|Anforderung|ID|
 | --- | --- |
+| **300 aktuellen Nutzern**  <br>Das System muss mindestens 300 aktuelle Benutzer unterstützen, die das System administrieren, bearbeiten und nutzen können. Nicht jeder Benutzer benötigt ein eigenes Profil. | HW-1 |
 | **ca. 50 Zugriffe / Tag**  <br>Das System muss in der Lage sein, ca. 50 aktive Benutzer pro Tag (tendenziell steigend) zu unterstützen, ohne dass die Systemleistung beeinträchtigt wird. Die Systemressourcen sollten ausreichend dimensioniert sein, um eine reibungslose und effiziente Nutzung durch die Benutzer zu gewährleisten. | HW-2 |
 | **Einfach skalierbar**  <br>Das System muss einfach skaliert werden können, um aufsteigende Anforderungen und Benutzerzahlen reagieren zu können. Dies sollte ohne wesentliche Änderungen an der Systemarchitektur oder -Infrastruktur möglich sein, um eine flexible und kosteneffiziente Anpassung an zukünftige Bedürfnisse zu ermöglichen. | HW-3 |
 
@@ -80,7 +81,13 @@
 
 Phase 2: Schülerzugang braucht mehr Nutzer…. Zugriffe / Tag steigen auch.
 
-<table><tbody><tr><th><p><strong>Die Anwendung wird auf einem Cloud-Server betrieben, der skalierbar ist, um den Anforderungen eines wachsenden Benutzerstamms gerecht zu werden.</strong></p></th><th><p>HW-4</p></th></tr><tr><td><p><strong>Hochverfügbar: 99.5%</strong></p><p>Das System muss eine Verfügbarkeit von mindestens 99,5% aufweisen. Dies bedeutet, dass das System innerhalb eines Jahres höchstens 43,8 Stunden (0,5% von 8760 Stunden) nicht verfügbar sein darf.</p></td><td><p>HW-5</p></td></tr><tr><td><p><strong>Datenbank und Anwendung muss redundant und gegen Ausfall eines Servers gesichert sein.</strong></p><p>Die Datenbank und die Anwendung müssen redundant und gegen Ausfälle gesichert sein, um Datenverluste und Systemausfälle zu vermeiden. Dies umfasst die Implementierung von:</p><ul><li>Datenbankreplikation</li><li>Regelmäßige Backups und Datenwiederherstellung</li></ul></td><td><p>HW-6</p></td></tr><tr><td><p><strong>.Net Runtime muss unterstützt werden</strong><br>Die Anwendung muss die .NET Runtime unterstützen, um eine reibungslose Ausführung von .NET-basierten Anwendungen zu ermöglichen.</p></td><td><p>HW-7</p></td></tr><tr><td><p><strong>Sicherheit und administrativer Zugriff:</strong></p><p>Der Zugriff auf die Anwendung und die Infrastruktur muss jederzeit gegeben sein. Dies kann durch die Implementierung von:</p><ul><li>SSH-Zugriff für Administratoren</li><li>VPN-Verbindung (Virtual Private Network) für eine sichere und verschlüsselte Verbindung</li><li>Zugriffskontrolle und Authentifizierung, um den Zugriff auf autorisierte Personen zu beschränken</li></ul><p>erreicht werden.</p></td><td><p>HW-8</p></td></tr></tbody></table>
+|Anforderung|ID|
+| --- | --- |
+| **Die Anwendung wird auf einem Cloud-Server betrieben, der skalierbar ist, um den Anforderungen eines wachsenden Benutzerstamms gerecht zu werden.** | HW-4 |
+| **Hochverfügbar: 99.5%** <br>Damit diese Anforderung auch im Falle eines gröberen Ausfalls eingehalten werden kann, muss es diverse Dokumentation und Anleitungen zum Wiederherstellungsprozesses geben. Es wird ein eigenes Desaster Recovery Handbuch geben. Damit diverse Probleme schnell erkannt werden, wird es ein rudimentäres Logging geben. (Wie viele Requests? Ressourcenverbrauch? Durchschnittliche antwortzeit des Servers...) Sollte einer dieser Werte auffällig weit aus der Norm fallen, wird der Absolventenverein, sowie diese Diplomarbeitsgruppe automatisch benachrichtigt, damit mit untersuchungen / gegenmaßnahmen in angriff genommen.<br> *Das System muss eine Verfügbarkeit von mindestens 99,5% aufweisen. Dies bedeutet, dass das System innerhalb eines Jahres höchstens 43,8 Stunden (0,5% von 8760 Stunden) nicht verfügbar sein darf.* | HW-5 |
+| **Datenbank und Anwendung muss redundant und gegen Ausfall eines Servers gesichert sein.** <br> Die Datenbank wird auf beiden Servern repliziert vorhanden sein. Ob das ein warm-standby, hot-standby, oder gar eine Multi-Master Replizierung wird, muss noch entschieden werden. Im Falle eines Ausfalls einer der beiden DBs, soll die andere automatisch zum neuen Master "promoted" werden, wodurch die Anwendung ohne einen groß Merkbaren ausfall direkt weiter ausgeführt werden kann. <br> Außerdem soll regelmäßig ein Backup von der gesamten Datenbank gemacht werden, welches auf einem unabhängigen File Server/Provider gelagert wird, um im Falle eines Datenverlustes die DB wiederher zu stellen. *<br> Die Datenbank und die Anwendung müssen redundant und gegen Ausfälle gesichert sein, um Datenverluste und Systemausfälle zu vermeiden. Dies umfasst die Implementierung von:</p><ul><li>Datenbankreplikation</li><li>Regelmäßige Backups und Datenwiederherstellung</li></ul>* | HW-6 |
+| **.Net Runtime muss unterstützt werden** <br> Die Anwendung muss die .NET Runtime unterstützen, um eine reibungslose Ausführung von .NET-basierten Anwendungen zu ermöglichen. | HW-7 |
+| **Sicherheit und administrativer Zugriff:** <br> Der Administrative zugriff auf das System geschieht über eine SSH Verbindung, welche nur duch eine VPN (Wireguard) aufgebaut werden kann. Die Authentifizierung (der VPN und SSH) wird über Schlüsselpaare gemacht, um sicherer gegenüber bruteforce Angriffe zu sein. <br> Der Zugriff auf die Anwendung und die Infrastruktur muss jederzeit gegeben sein. Dies kann durch die Implementierung von:</p><ul><li>SSH-Zugriff für Administratoren</li><li>VPN-Verbindung (Virtual Private Network) für eine sichere und verschlüsselte Verbindung</li><li>Zugriffskontrolle und Authentifizierung, um den Zugriff auf autorisierte Personen zu beschränken</li></ul> erreicht werden. | HW-8 |
 
 ## Anforderungen an den Bedienrechner / das mobile Endgerät
 
@@ -91,9 +98,9 @@ Phase 2: Schülerzugang braucht mehr Nutzer…. Zugriffe / Tag steigen auch.
 
 ## Anforderungen an das Backup, Recovery und Desaster-Recovery
 
-| **Automatisierte Datensicherung**<br><br>Zur Erhöhung der Datensicherheit soll über das Komplettsystem eine automatisierte Datensicherung erfolgen. (Versionen / Binaries der Anwendungen, Konfigurationsdateien und Nutzerdaten) | HW-12 |
+| **Automatisierte Datensicherung**<br>Zur Erhöhung der Datensicherheit soll über das Komplettsystem eine automatisierte Datensicherung erfolgen. Versionen / Binaries der Anwendungen, Konfigurationsdateien und Nutzerdaten, die Datenbank... Diese Dateien werdenauf einem unbhängigen File Server gelagert. Die Binaries sollen nur bei Updates unserer Software ausgetauscht werden, Konfigurationen bei Änderung erneuert gesichert und die Datenbank mit Nutzerdaten in einem regelmäßigen Zeitfenster. (Vielleicht misbrauchen wir einfach ein Git Repository, das ist vorallem für die Versionierung und Automatisierung dieser Backups sehr gut geeignet) | HW-12 |
 | --- | --- |
-| **Wiederherstellungszeitraum**<br><br>Die Wiederherstellung des Servers im Falle eines Ausfalls (des Rechenzentrums) muss innerhalb von **einem Tag** gewährleistet sein. Also nach 24 Stunden muss das System wieder in einen benutzbaren Zustand gebracht werden | HW-13 |
+| **Wiederherstellungszeitraum**<br><br> <>Das gehört mMn. nach oben zu allgemeine Anforderungen und ausgetauscht mit HW-5<> Die Wiederherstellung des Servers im Falle eines Ausfalls (des Rechenzentrums) muss innerhalb von **einem Tag** gewährleistet sein. Also nach 24 Stunden muss das System wieder in einen benutzbaren Zustand gebracht werden | HW-13 |
 | **Dokumentation zum Wiederherstellungsverfahren muss vorhanden sein.**<br><br>Schritt für Schritt Anweisungen zum Wiederherstellen des Systems | HW-14 |
 
 ## Anforderungen an Redundanz und Verfügbarkeit
@@ -109,9 +116,9 @@ Redundanzeigenschaften Bespr. Mit Hr. Prof. Gürth
 
 ### Verfügbarkeitsanforderungen
 
-| **99% / Jahr (87.6h)**<br><br>Das System soll weniger als 90 Stunden im Jahr ausfallen. | RED-4 |
+| **99% / Jahr (87.6h)**<br>Durch eine schnelle Wiederherstellungszeit und klar vorgegebene Disaster Recovery Dokumentation und resilienz in der Architektur des Systems, sowie ein Monitoring und Logging zur frühen Erkennung etwaiger Probleme werden die 99% / Jahr eingehalten werden.<br>Das System soll weniger als 90 Stunden im Jahr ausfallen. | RED-4 |
 | --- | --- |
-| **Wiederherstellungszeit: the next business day**<br><br>Das System soll bis zum übernächsten Werktag wieder in einen Nutzbaren zustand bringbar sein. | RED-5 |
+| **Wiederherstellungszeit: the next business day**<br>Durch weitgehende automatisierte Skripte soll der Wiederherstellungsprozess vereinfacht werden. Ein Desaster-Recovery Handbuch liegt bei, um den Benutzer schritt für Schritt durch den Wiederherstellungsprozess zu begleiten.<br>Das System soll bis zum übernächsten Werktag wieder in einen Nutzbaren zustand bringbar sein. | RED-5 |
 |     |     |
 
 ## Schnittstellen
@@ -320,7 +327,7 @@ Protokollierung aller Authentifizierungsversuche und der zugehörigen LinkedIn-D
 
 Mehr Prosa (Unterscheidung Phase 1 & 2)
 
-| **Dashboard**<br><br>Frontend:  <br>Zeige die letzten Anmeldeaktivitäten und biete schnelle Optionen zur Sicherheitsverwaltung. Ermögliche Benachrichtigungen bei neuen Login-Versuchen und erleichtere den Zugriff auf Sicherheitsfunktionen.<br><br>Backend:<br><br>Ein Backend-Dashboard bündelt Systemdaten wie Nutzeraktivität, Serverstatus und Verkaufszahlen in Echtzeit. Es visualisiert KPIs über Diagramme und Tabellen, ermöglicht schnelle Analysen und unterstützt präzise Entscheidungen. Durch Zugriffsrechte und performante Datenbanken bleibt das Dashboard sicher und effizient – die zentrale Kontrollstelle für Systemauswertungen. | AUS-1 |
+| <br>Dashboard<br>Frontend:  <br>Anforderung:<br>Das Frontend der Webanwendung soll ein Dashboard bereitstellen, das die letzten Anmeldeaktivitäten des Benutzers anzeigt, schnelle Optionen zur Sicherheitsverwaltung bietet und Benachrichtigungen zu neuen Login-Versuchen ermöglicht. Das Dashboard soll die Benutzerfreundlichkeit und Transparenz im Umgang mit sicherheitsrelevanten Informationen gewährleisten.<br>Beschreibung der Funktionalität:  <br>1. Anzeige der letzten Anmeldeaktivitäten: <br>- Das Dashboard zeigt eine übersichtliche Liste der letzten Anmeldeaktivitäten, einschließlich Datum, Uhrzeit, Gerät/Browser und Standort (basierend auf der IP-Adresse).<br>- Ungewöhnliche oder verdächtige Aktivitäten werden visuell hervorgehoben (z. B. durch farbliche Markierungen oder Warnsymbole). <br>- Eine Funktion zur Markierung von Aktivitäten als „verdächtig“ ermöglicht dem Benutzer, ungewöhnliche Logins direkt zu melden<br>2. Sicherheitsverwaltung:<br>- Das Dashboard enthält direkte Links oder Schaltflächen zu wichtigen Sicherheitsfunktionen, darunter:<br>- Änderung des Passworts<br>- Aktivierung/Deaktivierung der Zwei-Faktor-Authentifizierung (2FA)<br>- Übersicht und Verwaltung aktiver Sitzungen mit der Möglichkeit, einzelne Sitzungen zu beenden<br>- Eine Funktion zur Anzeige und Verwaltung von vertrauenswürdigen Geräten wird bereitgestellt.<br>3. Benachrichtigungen bei neuen Login-Versuchen:<br>- Das Dashboard zeigt Benachrichtigungen zu neuen Login-Versuchen in Echtzeit an, falls diese erkannt werden.<br>- Bei neuen Login-Versuchen aus unbekannten Standorten oder Geräten wird eine zusätzliche Sicherheitsabfrage bereitgestellt (z. B. über E-Mail oder SMS).<br>4. Benutzerfreundlichkeit und Usability:<br>- Die Darstellung der Informationen erfolgt in einem klar strukturierten und leicht verständlichen Format (z. B. Tabellen oder Karten).<br>- Die Sicherheitsoptionen sind intuitiv zugänglich und mit kurzen Erklärungen versehen, um die Benutzerfreundlichkeit zu erhöhen.<br>- Das Design ist responsive und für die Nutzung auf verschiedenen Geräten (Desktop, Tablet, Mobil) optimiert.<br>5. Barrierefreiheit:<br>- Das Dashboard erfüllt Standards zur Barrierefreiheit und unterstützt z. B. Screenreader oder Tastatur-Navigation.<br>- Visuelle Warnhinweise (z. B. zu verdächtigen Aktivitäten) werden durch alternative Texte und Symbole ergänzt<br>Akzeptanzkriterien:<br>- Das Dashboard zeigt die letzten Anmeldeaktivitäten vollständig und korrekt an, einschließlich aller relevanten Details.<br>- Sicherheitsfunktionen wie Passwortänderung, 2FA-Verwaltung und Sitzungsübersicht sind direkt zugänglich und funktionieren einwandfrei.<br>- Benachrichtigungen zu neuen Login-Versuchen werden in Echtzeit angezeigt und ermöglichen eine schnelle Reaktion des Benutzers.<br>- Das Dashboard ist auf verschiedenen Geräten benutzerfreundlich und barrierefrei bedienbar.<br><br>Backend:<br><br>Ein Backend-Dashboard bündelt Systemdaten wie Nutzeraktivität, Serverstatus und Verkaufszahlen in Echtzeit. Es visualisiert KPIs über Diagramme und Tabellen, ermöglicht schnelle Analysen und unterstützt präzise Entscheidungen. Durch Zugriffsrechte und performante Datenbanken bleibt das Dashboard sicher und effizient – die zentrale Kontrollstelle für Systemauswertungen | AUS-1 |
 | --- | --- |
 | Auswertungen erstellen<br><br>Frontend:  <br>Erstelle präzise Auswertungen deiner Anmeldedaten: Analysiere Login-Häufigkeit, erkenne verdächtige Aktivitäten und gewinne Einblicke in Nutzerverhalten. Optimiere deine Sicherheitsstrategie<br><br>Backend:<br><br>Für Auswertungen im Backend sind strukturierte Daten, Filter und Algorithmen zur KPI-Berechnung nötig. Diagramme und Tabellen visualisieren die Ergebnisse. Zugriffsrechte sichern die Daten, eine performante Datenbank sorgt für schnelle Analysen – so werden Rohdaten in präzise Systemauswertungen verwandelt. | AUS-2 |
 | Auswertugnen erstellen 2 (Phase 2)<br><br>Frontend:  <br>Login-Standorte und verwendete Geräte aufzeigen. Finde heraus, zu welchen Zeiten die meisten Anmeldungen stattfinden und entdecke potenzielle Sicherheitslücken durch Vergleich der Nutzeraktivitäten. Erhalte zudem detaillierte Statistiken zu fehlgeschlagenen Login-Versuchen und häufig genutzten Wiederherstellungsfunktionen, um gezielt Sicherheitsmaßnahmen zu verbessern.<br><br>Backend:<br><br>Für Backend-Auswertungen benötigt man zuverlässige Datenquellen, Filter und Algorithmen zur Berechnung von Metriken. Eine schnelle Datenbank ermöglicht effiziente Verarbeitung, Visualisierungstools wandeln Ergebnisse in Diagramme und Tabellen um. Zugriffsrechte sichern die Daten – so entsteht eine präzise und sichere Analysebasis. | AUS-3 |
@@ -334,11 +341,11 @@ Mehr Prosa (Unterscheidung Phase 1 & 2)
 
 ## Schwarzes Brett (Phase 2)
 
-| **Feed**<br><br>Eine Seite auf den Mitteilungen und Ankündigungen gemacht werden. Hier kann man Events anzeigen lassen, Posts anderer Mitglieder usw. | ScB-1 |
+| **Feed**<br>Es muss ein Interface / eine Schnittstelle für alle Elemente, welche am Schwarzen Brett auftauchen geschaffen werden. Dann muss eine API Route für das Abrufen der einzelnen Einträge geschaffen werden. Die gesammte Entwicklung wird in einem Oqtane Modul geschehen. Der Feed priorisiert die Posts vom Absolventenverein und muss die Sichtbarkeitsstufe des Posts berücksichtigen.<br>Eine Seite auf den Mitteilungen und Ankündigungen gemacht werden. Hier kann man Events anzeigen lassen, Posts anderer Mitglieder usw. | ScB-1 |
 | --- | --- |
-| **Posten**<br><br>Jeder darf posten, solange ihm in der Vergangenheit dieses Privileg nicht weggenommen wurde. Diese Posts werden dann in dem Feed angezeigt. Ein Post kann eine Sichbarkeitsstufe haben (standardmäßig: öffentlich = jeder angemeldete Benutzer) | ScB-2 |
-| **Werbung**<br><br>Firmen können Job Inserate schalten, Diplomarbeitskooperationen anbieten usw. Wir stellen die Schnittstelle für diese Firmen bereit, aber um die Abrechnung muss sich gesondert jemand anderer kümmern | ScB-3 |
-| **Meldungsvorgang**<br><br>Man kann unangemessene Inhalte melden, diese Meldungen werden dann von Hand durchgeschaut, ob diese den Regeln widersprechen, und kann dem Benutzer über eine Rollenänderung das Privileg des Postens / Interagieren mit anderen Nutzern auf der Seite entfernt werden. | ScB-4 |
+| **Posten**<br>Es wird eine neue API Route in dem Modul implementiert, die es ermöglicht eigene Einträge auf dem schwarzen Brett zu posten. Hierfür braucht man nichts wirklich ausgefallenes.<br>Jeder darf posten, solange ihm in der Vergangenheit dieses Privileg nicht weggenommen wurde. Diese Posts werden dann in dem Feed angezeigt. Ein Post kann eine Sichbarkeitsstufe haben (standardmäßig: öffentlich = jeder angemeldete Benutzer) | ScB-2 |
+| **Werbung**<br>Um Werbung auf dem schwarzen Brett anbieten zu können, muss mitgezählt werden, welche Posts geladen / gesehen worden sind. Es wird auch eine "Abrechnungsseite" geben, auf der die Kosten Vorgerechnet werden. Um die Abrechnung muss sich der Absolventen Verein selber kümmern.<br>Firmen können Job Inserate schalten, Diplomarbeitskooperationen anbieten usw. Wir stellen die Schnittstelle für diese Firmen bereit, aber um die Abrechnung muss sich gesondert jemand anderer kümmern | ScB-3 |
+| **Meldungsvorgang**<br>Es werden neue Knöpfe bei den Posts hinzugefügt, mit denen man einen Post melden kann. Optional mit Angabe eines Grundes. Dieser Post wird sofort offline genommen und dann zur Durchsicht von Seiten des Absolventenvereins markiert. Je nach dem, was der AV dann Beschließt, wird dem Benutzer dann das Recht auf Posten entzogen.<br>Man kann unangemessene Inhalte melden, diese Meldungen werden dann von Hand durchgeschaut, ob diese den Regeln widersprechen, und kann dem Benutzer über eine Rollenänderung das Privileg des Postens / Interagieren mit anderen Nutzern auf der Seite entfernt werden. | ScB-4 |
 
 ## Anmeldetool für Treffen