<\/span><\/h2>\n\n\n\nAuthentifizierung und Autorisierung sind das am st\u00e4rksten exponierte Element der Sicherheit einer Webanwendung. Welche Strategie sollten Sie w\u00e4hlen? Das h\u00e4ngt vom Projekt ab. OAuth 2.0 bew\u00e4hrt sich hervorragend, wenn Sie eine Integration mit externen Identit\u00e4tsanbietern brauchen. Serverseitige Sitzungen bieten Einfachheit und volle Kontrolle in geschlossenen B2B-Systemen. Und JWT (JSON Web Tokens)? Enorm beliebt in Microservice-Architekturen, aber mit realen Risiken verbunden. Ein mit einem schwachen Algorithmus signiertes oder im localStorage abgelegtes Token ist ein Geschenk f\u00fcr Angreifer, die XSS ausnutzen. Bei Web Systems w\u00e4hlen wir die Strategie individuell – wir analysieren die gesch\u00e4ftlichen Anforderungen, die Gr\u00f6\u00dfe des Systems und das Bedrohungsprofil.<\/p>\n\n\n\n
Multi-Faktor-Authentifizierung (MFA) sollte Standard sein. Besonders in Systemen, die sensible oder finanzielle Daten verarbeiten. Die Kosten f\u00fcr die Einf\u00fchrung von TOTP (Time-based One-Time Password) oder die Integration mit Authenticator-Apps? Marginal im Vergleich zum Risiko einer Konto\u00fcbernahme durch Phishing oder Credential Stuffing. In unseren B2B-Projekten ist MFA die Standardanforderung f\u00fcr administrative Konten. Immer h\u00e4ufiger f\u00fchren wir sie auch f\u00fcr Endnutzer ein – progressiv. Das System verlangt den zweiten Faktor bei Operationen mit erh\u00f6htem Risiko, nicht bei jeder Anmeldung.<\/p>\n\n\n\n
Das Berechtigungsmodell? Das h\u00e4ngt von der Komplexit\u00e4t der Organisationsstruktur des Kunden ab. RBAC (Role-Based Access Control) reicht aus, wenn Sie eine feste, \u00fcberschaubare Zahl von Rollen haben – Administrator, Moderator, Nutzer. In komplexen Systemen jedoch, in denen die Rechte von Abteilung, Standort, Zugriffszeit oder Dokumentenklassifizierung abh\u00e4ngen, bietet ABAC (Attribute-Based Access Control) deutlich mehr Flexibilit\u00e4t. Tipp:<\/strong> Speichern Sie in SPA-Anwendungen Access-Tokens im Arbeitsspeicher (in einer JavaScript-Variablen) und Refresh-Tokens in HttpOnly-Cookies mit den Flags Secure und SameSite. Vermeiden Sie localStorage – er ist f\u00fcr jedes Skript auf der Seite zug\u00e4nglich. Bei einer XSS-Schwachstelle bedeutet das die sofortige \u00dcbernahme der Nutzersitzung.<\/p>\n\n\n\n<\/span>Datenschutz und DSGVO-Konformit\u00e4t in Webanwendungen<\/span><\/h2>\n\n\n\nDer Schutz personenbezogener Daten ist nicht nur ein H\u00e4kchen bei der Checkbox \u201eDSGVO-konform”. Es geht um das Vertrauen von Kunden und Partnern. Das Fundament? Verschl\u00fcsselung auf zwei Ebenen. Daten in der \u00dcbertragung – TLS 1.3 (\u00e4ltere Protokollversionen schalten wir ab). Daten im Ruhezustand – Verschl\u00fcsselung auf Ebene der Datenbank oder des Dateisystems. Nutzerpassw\u00f6rter speichern wir ausschlie\u00dflich als Hashes, die mit brute-force-resistenten Algorithmen erzeugt werden – bcrypt oder Argon2id mit passend gew\u00e4hltem Rechenaufwand. MD5? SHA-256 f\u00fcr Passw\u00f6rter? Niemals. Ihre Rechengeschwindigkeit spielt den Angreifern in die H\u00e4nde.<\/p>\n\n\n\n
Privacy by design bedeutet, DSGVO-konforme Systeme vom ersten Architekturentwurf an zu planen, statt ein bestehendes System nachtr\u00e4glich zu flicken. Wie sieht das bei uns in der Praxis aus? Minimierung der erhobenen Daten (wir fragen uns: brauchen wir diese Information wirklich?), Pseudonymisierung wo immer m\u00f6glich, Trennung identifizierender Daten von analytischen Daten. Jede Operation an personenbezogenen Daten wird in einem unver\u00e4nderlichen Audit-Log protokolliert – wer wann welche Operation durchgef\u00fchrt hat. Ein solches Log hilft, unbefugten Zugriff zu erkennen und die Konformit\u00e4t bei einer Pr\u00fcfung durch die Aufsichtsbeh\u00f6rde nachzuweisen.<\/p>\n\n\n\n
Das Recht auf L\u00f6schung (Art. 17 DSGVO) ist in komplexen B2B-Systemen erst recht eine Herausforderung. Die personenbezogenen Daten eines Kunden ziehen sich durch viele Tabellen, Dienste und Sicherungskopien. Eine vollst\u00e4ndige L\u00f6schung erfordert eine durchdachte Strategie. Wir nutzen das Muster Soft Delete mit kaskadierender Anonymisierung – statt Datens\u00e4tze physisch zu l\u00f6schen, ersetzen wir identifizierende Daten durch unumkehrbare Werte. So bewahren wir die referenzielle Integrit\u00e4t der Datenbank und die M\u00f6glichkeit, aggregierte Daten weiter zu verarbeiten. Die Aufbewahrungsrichtlinie definieren wir gemeinsam mit dem Kunden, und den eigentlichen L\u00f6schvorgang nach Ablauf der Aufbewahrungsfrist automatisieren wir. Denn manuell schafft das niemand.<\/p>\n\n\n\n
<\/span>Monitoring, Reaktion auf Vorf\u00e4lle und kontinuierliche Verbesserung<\/span><\/h2>\n\n\n\nSie haben die Anwendung in den Produktivbetrieb gebracht – und das war’s? Nein. Hier f\u00e4ngt es erst an. Kontinuierliches Monitoring und die Bereitschaft zur schnellen Reaktion – ohne das geht es nicht. Zentrale Protokollierung von Sicherheitsereignissen (SIEM) erlaubt es, Informationen aus verschiedenen Quellen zu korrelieren: Anwendungslogs, Webserver, Datenbank, Firewall. Wir konfigurieren Alarme f\u00fcr massenhaft fehlgeschlagene Logins (Brute-Force-Angriff?), unerwartete Muster im API-Verkehr (Scraping oder DDoS?) und Zugriffsversuche auf Ressourcen ohne Autorisierung. Monitoring bedeutet nicht, Daten zu sammeln. Es ist die F\u00e4higkeit, das Signal aus dem Rauschen herauszufiltern. Und Rauschen gibt es reichlich.<\/p>\n\n\n\n
Ein Plan zur Reaktion auf Sicherheitsvorf\u00e4lle legt fest, wer im Krisenfall was tut. Wer entscheidet \u00fcber die Abschaltung eines kompromittierten Systems? Wer kommuniziert mit dem Endkunden? In welcher Frist muss die Aufsichtsbeh\u00f6rde informiert werden? (Die DSGVO verlangt die Meldung einer Verletzung innerhalb von 72 Stunden.) Diese Fragen sollten nicht zum ersten Mal gestellt werden, wenn es bereits brennt. Wir f\u00fchren regelm\u00e4\u00dfig Szenario\u00fcbungen durch – wir simulieren verschiedene Arten von Verletzungen, vom Datenleck bis zu Ransomware. Wir pr\u00fcfen die Wirksamkeit der Verfahren und verk\u00fcrzen die Reaktionszeit. Besser \u00fcben als live improvisieren.<\/p>\n\n\n\n
Penetrationstests und Sicherheitsaudits f\u00fchren wir zyklisch durch – die H\u00e4ufigkeit passen wir dem Risikoniveau des Projekts an. Anwendungen, die Finanz- oder Medizindaten verarbeiten? Audit jedes Quartal. Systeme mit niedrigerem Risikoprofil? Alle sechs Monate. Zwischen externen Audits betreiben wir kontinuierliches automatisches Monitoring – DAST-Scanner in der CI\/CD-Pipeline fangen Sicherheitsregressionen laufend ab, bevor der Code in den Produktivbetrieb gelangt. Und wir messen alles: die Zahl der gefundenen Schwachstellen, die durchschnittliche Zeit bis zu ihrer Behebung (MTTR), die Codeabdeckung durch SAST-Scans, den Anteil der Abh\u00e4ngigkeiten mit aktuellen Patches. Die regelm\u00e4\u00dfige Analyse dieser Kennzahlen zeigt Trends und macht deutlich, wo Ressourcen den gr\u00f6\u00dften Effekt bringen.<\/p>\n\n\n\n