Zum Inhalt

03. Technische Handlungsfelder

Lernziele

Nach diesem Kapitel können Sie: - Die wesentlichen technischen Handlungsfelder in IT-Projekten identifizieren - Das STRIDE-Modell für Sicherheitsanalysen anwenden - Compliance-Anforderungen berücksichtigen - Strategien für Datenmanagement und Architektur entwickeln - Sicherheitsarchitektur "Built-in" statt "Bolt-on" planen

Lesezeit

ca. 15-20 Minuten

1. Einführung: Über Security hinaus

Ein robustes Lösungskonzept umfasst weit mehr als nur Code. IT-Berater müssen ein breites Spektrum an technischen Handlungsfeldern berücksichtigen, um die Qualität, Sicherheit und Nachhaltigkeit einer IT-Lösung sicherzustellen.

Die vier technischen Kern-Handlungsfelder:

mindmap
  root((Technische<br/>Handlungsfelder))
    Sicherheit
      STRIDE-Modell
      Authentifizierung
      Verschlüsselung
      Security-by-Design
    Compliance
      DSGVO
      ISO 27001
      SOX
      Branchenstandards
    Datenmanagement
      Backup & Recovery
      Data Lakes
      Datenqualität
      Governance
    Architektur
      High-Level-Design
      Microservices
      Skalierbarkeit
      Performance

1.1 Warum Sicherheit integraler Bestandteil ist

Früher wurde Sicherheit oft als nachträglicher Zusatz ("Bolt-on") betrachtet. Moderne Ansätze verfolgen Security-by-Design oder Built-in Security - Sicherheit wird von Anfang an in die Architektur integriert.

graph TD
    A["Bolt-on Security<br/>(alt)"] --> A1["Sicherheit wird nachträglich hinzugefügt"]
    A --> A2["Schwachstellen werden spät erkannt"]
    A --> A3["Behebung teuer und ineffektiv"]

    B["Built-in Security<br/>(modern)"] --> B1["Sicherheit ist integraler Bestandteil"]
    B --> B2["Risiken werden frühzeitig identifiziert"]
    B --> B3["Proaktive Vermeidung statt reaktive Behebung"]

    style A fill:#ffe1e1
    style B fill:#e1ffe1

Business-Argumente für Built-in Security:

  • Kostenvermeidung: Früheres Identifizieren von Risiken spart teure Nacharbeiten
  • Reputationsrisiko: Sicherheitslecks führen zu massivem Imageschaden
  • Compliance: Datenschutzverletzungen führen zu Bußgeldern (DSGVO bis 4% des weltweiten Umsatzes)
  • Wettbewerbsvorteil: Sicherheit wird zunehmend zum Kaufkriterium für Kunden

2. Sicherheitsarchitektur

2.1 Das STRIDE-Modell

STRIDE ist ein bewährtes Modell zur systematischen Identifizierung von Sicherheitsbedrohungen, ursprünglich von Microsoft entwickelt.

Akkronym-Bedeutung:

Buchstabe Begriff Bedeutung Beispiel
S Spoofing Identitätsfälschung Angreifer gibt sich als authentifizierter Benutzer aus
T Tampering Manipulation von Daten Unbefugter ändert Transaktionsdaten
R Repudiation Nichtanerkennung von Handlungen Benutzer behauptet, eine Aktion nicht ausgeführt zu haben
I Information Disclosure Offenlegung von Informationen Unbefugter erhält Zugriff auf geschützte Daten
D Denial of Service Dienstverweigerung System wird überlastet und nicht mehr erreichbar
E Elevation of Privilege Privilegieneskalation Angreifer erlangt höhere Rechte als berechtigt

2.2 Anwendung von STRIDE am Beispiel: E-Commerce-System

flowchart TD
    A[E-Commerce-System] --> B[Benutzerregistrierung]
    A --> C[Produktsuche]
    A --> D[Warenkorb]
    A --> E[Bezahlung]
    A --> F[Bestellhistorie]

    B --> S[Spoofing: Phishing-Registrierungen]
    C --> S
    D --> T[Tampering: Warenkorb-Inhalte ändern]
    E --> T
    E --> R[Repudiation: Bestellung abstreiten]
    E --> I[Information Disclosure: Zahlungsdaten offenlegen]
    A --> D[Denial of Service: System überlasten]
    B --> E[Elevation of Privilege: Benutzer zum Admin hochstufen]

    style S fill:#ffe1e1
    style T fill:#fff4e1
    style R fill:#e1f5ff
    style I fill:#e1f5ff
    style D fill:#ffe1e1
    style E fill:#fff4e1

Detaillierte Bedrohungsanalyse:

Spoofing (Identitätsfälschung)

Szenario: Ein Angreifer registriert sich mit einer gefälschten E-Mail-Adresse, die einer echten Firma ähnelt, um Bestellungen im Namen dieser Firma zu tätigen.

Gegenmaßnahmen: - E-Mail-Verifizierung durch Bestätigungslink - Multi-Faktor-Authentifizierung (MFA) - IP-Adressen-Tracking und Anomalie-Erkennung - CAPTCHA bei verdächtigen Registrierungsversuchen

Tampering (Manipulation)

Szenario: Ein Angreifer manipuliert Warenkorb-Inhalte oder Preise vor der Zahlungsabwicklung.

Gegenmaßnahmen: - Preise serverseitig validieren (niemals clientseitig vertrauen) - Digitale Signaturen für kritische Daten - Integritätschecks (Checksums, Hashes) - Transaktions-Logs für Audit-Trails

Repudiation (Nichtanerkennung)

Szenario: Ein Kunde bestellt Waren, bestreitet aber die Bestellung später, um nicht zu zahlen.

Gegenmaßnahmen: - Umfassende Audit-Logs mit Zeitstempeln - IP-Adressen und User-Agent protokollieren - Digitale Signaturen für Bestellungen - Zweifaktor-Authentifizierung bei kritischen Aktionen

Information Disclosure (Informationsleck)

Szenario: Ein Angreifer erhält Zugriff auf Kundendaten, Zahlungsdaten oder Bestellhistorien.

Gegenmaßnahmen: - Verschlüsselung sensibler Daten (At Rest) - TLS/SSL für Datenübertragung (In Transit) - Zugriffsbeschränkung nach dem Need-to-Know-Prinzip - Data Masking in Logs und UI

Denial of Service (DoS)

Szenario: Ein Angreifer überlastet den Server mit Anfragen, das System wird unbrauchbar.

Gegenmaßnahmen: - Rate Limiting und Throttling - DDoS-Schutz (Cloudflare, AWS Shield) - Skalierbarkeit (Horizontal Scaling, Load Balancing) - Caching für statische Inhalte

Elevation of Privilege (Rechteausweitung)

Szenario: Ein normaler Benutzer erlangt Administrator-Rechte durch eine Sicherheitslücke.

Gegenmaßnahmen: - Principle of Least Privilege (jeder Benutzer nur minimal notwendige Rechte) - Regelmäßige Sicherheits-Updates - Code-Reviews für Rechte-Checks - Penetration-Tests vor Go-Live

2.3 Defense in Depth

Defense in Depth ist eine Schicht-Sicherheitsstrategie, die mehrere, unabhängige Sicherheitsmechanismen kombiniert.

graph TD
    A[Externe Bedrohung] --> B1[Perimeter-Schicht<br/>Firewall, DDoS-Schutz]
    B1 --> B2[Netzwerk-Schicht<br/>Network Segmentation, VPN]
    B2 --> B3[Anwendungs-Schicht<br/>WAF, Rate Limiting]
    B3 --> B4[Anwendungs-Logik<br/>Input Validation, Auth]
    B4 --> B5[Datenschutz-Schicht<br/>Verschlüsselung, Backup]

    style B1 fill:#ffe1e1
    style B2 fill:#fff4e1
    style B3 fill:#e1ffe1
    style B4 fill:#e1f5ff
    style B5 fill:#f0e1ff

Vorteile von Defense in Depth: - Redundanz: Wenn eine Schicht durchbrochen wird, bieten andere Schutz - Risiko-Reduzierung: Ein einzelner Fehler hat keine katastrophalen Folgen - Anpassungsfähigkeit: Jede Schicht kann unabhängig angepasst werden

2.4 Authentifizierung und Autorisierung

Authentifizierung (Wer bist du?) vs. Autorisierung (Was darfst du tun?)

flowchart LR
    A[Benutzeranfrage] --> B[Authentifizierung<br/>Identity Provider]
    B --> C{Authentifiziert?}
    C -->|Nein| D[Zurückweisen<br/>401 Unauthorized]
    C -->|Ja| E[Autorisierung<br/>Role/Permission Check]
    E --> F{Autorisiert?}
    F -->|Nein| G[Zurückweisen<br/>403 Forbidden]
    F -->|Ja| H[Anfrage bearbeiten]

    style D fill:#ffe1e1
    style G fill:#ffe1e1
    style H fill:#e1ffe1

Authentifizierungs-Methoden:

Methode Beschreibung Stärke Typischer Einsatz
Passwort Passwort-basierte Authentifizierung Niedrig Nicht mehr empfohlen
2FA / MFA Multi-Faktor-Authentifizierung Hoch Moderne Standard-Anforderung
SSO Single Sign-On Mittel-Hoch Unternehmensumgebungen
OAuth 2.0 Delegierte Autorisierung Hoch Drittanbieter-Integration
JWT JSON Web Tokens Mittel-Hoch Stateless APIs
Biometrie Fingerabdruck, Gesichtserkennung Hoch Mobile Apps

Autorisierungs-Modelle:

  1. Role-Based Access Control (RBAC)
  2. Benutzer werden Rollen zugeordnet
  3. Rollen haben Berechtigungen

  4. Beispiele: Admin, Editor, Viewer

  5. Attribute-Based Access Control (ABAC)

  6. Berechtigungen basieren auf Attributen (Benutzer, Ressource, Umwelt)

  7. Beispiel: "Benutzer mit Rolle 'Manager' darf Dokumente in Abteilung 'Sales' während Geschäftszeiten einsehen"

  8. Policy-Based Access Control (PBAC)

  9. Formale Regeln für Zugriffsentscheidungen
  10. Beispiel: "IF user.department == department AND user.level >= document.required_level THEN allow"

2.5 Verschlüsselung

Verschlüsselungs-Arten:

Art Beschreibung Beispiel
At Rest Verschlüsselung gespeicherter Daten Datenbank-Verschlüsselung (TDE), Festplattenverschlüsselung (BitLocker)
In Transit Verschlüsselung während der Übertragung TLS/SSL für HTTPS, SSH, VPN
End-to-End Verschlüsselung von Endpunkt zu Endpunkt Signal, WhatsApp, E-Mail-Verschlüsselung (PGP)

Verschlüsselungs-Algorithmen:

Algorithmus Typ Status Anwendung
AES-256 Symmetrisch Empfohlen Datenbank, Dateien
RSA-2048/4096 Asymmetrisch Empfohlen Schlüsselaustausch, Signaturen
ECDSA Asymmetrisch Empfohlen Signatures, TLS
DES/3DES Symmetrisch Veraltet Nicht mehr verwenden
SHA-1 Hash Veraltet Nicht mehr verwenden
SHA-256/512 Hash Empfohlen Integritätsprüfungen, Passwort-Hashing

Best Practices für Passwort-Hashing:

  • Verwenden Sie moderne Hash-Algorithmen wie bcrypt, Argon2 oder PBKDF2
  • Addieren Sie ein einzigartiges Salt pro Passwort
  • Verwenden Sie eine ausreichende Work Factor (z.B. bcrypt cost factor 12)
  • Speichern Sie niemals Klartext-Passwörter

3. Compliance

3.1 DSGVO (GDPR)

Die Datenschutz-Grundverordnung (DSGVO) ist europäische Gesetzgebung zum Schutz personenbezogener Daten.

Kernelemente der DSGVO:

Aspekt Beschreibung IT-Implikation
Recht auf Information Betroffene müssen informiert werden Datenschutzerklärung, Cookie-Banner
Recht auf Löschung Betroffene können Löschung fordern Datenlöschungs-Mechanismen, Data Retention Policy
Recht auf Berichtigung Betroffene können Daten korrigieren lassen UI für Datenänderung, Audit-Logs
Recht auf Datenportabilität Betroffene erhalten Daten in maschinenlesbarem Format CSV/JSON-Export-Funktion
Datenschutz durch Technik Sicherheitsmaßnahmen bei Entwicklung Privacy by Design, Data Minimization
Meldepflicht bei Verstößen Verletzungen müssen innerhalb von 72h gemeldet werden Sicherheits-Überwachung, Incident-Response

DSGVO-Checkliste für IT-Projekte:

  • Datenerhebung auf das Notwendige beschränken (Data Minimization)
  • Einwilligung (Consent) explizit einholen und dokumentieren
  • Personenbezogene Daten verschlüsseln (At Rest + In Transit)
  • Zugriffskontrolle implementieren (RBAC, Audit-Logs)
  • Datenlöschungs-Mechanismen für "Recht auf Vergessen"
  • Datenexport-Funktion für "Recht auf Datenportabilität"
  • Datenschutz-Folgenabschätzung (DPIA) bei hohem Risiko
  • Auftragsverarbeitungsverträge (AVV) mit Drittanbietern
  • Incident-Response-Plan für Datenschutzverletzungen

3.2 ISO 27001

ISO 27001 ist der internationale Standard für Informationssicherheits-Managementsysteme (ISMS).

Kern-Anforderungen der ISO 27001:

Bereich Beschreibung
Management-Commitment Oberste Leitung muss Informationssicherheit unterstützen
Sicherheitspolitik Umfassende Sicherheitsrichtlinie
Risikomanagement Systematische Identifikation und Behandlung von Sicherheitsrisiken
Schutzmaßnahmen Technische und organisatorische Maßnahmen
Awareness & Schulung Schulungen für Mitarbeiter
Continual Improvement Kontinuierliche Verbesserung durch Audits und Reviews

ISO 27001 vs. DSGVO:

Aspekt ISO 27001 DSGVO
Fokus Informationssicherheit (alle Daten) Datenschutz (personenbezogene Daten)
Zertifizierbar Ja Nein (aber Compliance prüfbar)
Umfang Ganzheitliches ISMS Datenschutz-relevante Aspekte
Verpflichtend Freiwillig Gesetzlich vorgeschrieben
Zielgruppe Unternehmen Organisationen, die personenbezogene Daten verarbeiten

3.3 SOX (Sarbanes-Oxley Act)

Der Sarbanes-Oxley Act ist US-Gesetzgebung für Unternehmen, die an der US-Börse notiert sind. Es fokussiert auf die Zuverlässigkeit der Finanzberichterstattung.

Relevante Abschnitte für IT:

Section Inhalt IT-Anforderungen
302 Corporate Responsibility CEO/CFO-Zertifizierung der Finanzberichte
404 Management Assessment of Internal Controls Interne Kontrollen müssen dokumentiert und getestet werden
409 Real Time Issuer Disclosures** Schnelle Offenlegung wesentlicher Ereignisse

SOX-Compliance für IT-Systeme:

  • Change Management: Alle Änderungen an Finanzsystemen müssen dokumentiert werden
  • Access Control: Zugriffsrechte müssen dokumentiert und regelmäßig geprüft werden
  • Audit Trails: Alle Finanztransaktionen müssen vollständig protokolliert werden
  • Segregation of Duties: Trennung von Aufgaben (z.B. Anlegen und Genehmigen von Rechnungen)
  • Backup & Recovery: Regelmäßige Backups und getestete Wiederherstellungsprozesse

3.4 Branchenspezifische Compliance

Finanzsektor (BaFin, MaRisk):

  • Mindestanforderungen an das Risikomanagement
  • Auslagerungs-Management bei Outsourcing
  • Notfallmanagement und Business Continuity

Gesundheitswesen (Patientendatenschutz, BSI-Grundschutz):

  • Besonders strenge Datenschutzanforderungen
  • Verschlüsselung aller Patientendaten
  • Audit-Logs für alle Zugriffe

Industrie (ISO 27034, IEC 62443):

  • Sicherheitsanforderungen für ICS/SCADA-Systeme
  • OT-Security (Operational Technology Security)
  • Schutz vor Angriffen auf kritische Infrastruktur

4. Datenmanagement

4.1 Data Lifecycle Management

stateDiagram-v2
    [*] --> Erfassung: Daten werden erstellt
    Erfassung --> Speicherung: Daten werden gespeichert
    Speicherung --> Nutzung: Daten werden verwendet
    Nutzung --> Archivierung: Daten werden nicht mehr aktiv genutzt
    Archivierung --> Löschung: Daten werden endgültig gelöscht
    Löschung --> [*]

    Nutzung --> Nutzung: Aktive Nutzung
    Speicherung --> Speicherung: Backup/Snapshot

    note right of Erfassung
        Input Validation
        Data Quality
    end note

    note right of Speicherung
        Verschlüsselung
        Redundanz
    end note

    note right of Nutzung
        Zugriffsrechte
        Audit-Logs
    end note

    note right of Archivierung
        Komprimierung
        Migration
    end note

    note right of Löschung
        DSGVO-konform
        Zero-Knowledge
    end note

4.2 Backup- und Disaster Recovery-Strategien

Backup-Typen:

Typ Beschreibung Vor- & Nachteile
Full Backup Vollständige Backup aller Daten + Schnellste Wiederherstellung
- Höchster Speicherbedarf
Incremental Backup Backup seit dem letzten Backup + Minimaler Speicherbedarf
- Langsamste Wiederherstellung
Differential Backup Backup seit dem letzten Full Backup + Schneller als Incremental
- Größer als Incremental
Snapshot Zeitpunktaufnahme (z.B. Datenbank) + Schnelle Wiederherstellung
- Eventuell nicht konsistent
Continuous Backup Jede Änderung wird gesichert + Maximale Sicherheit
- Hoher Overhead

RPO und RTO:

Metrik Bedeutung Beispiel-Werte
RPO (Recovery Point Objective) Maximaler Datenverlust (Zeit) "Maximal 1 Stunde Datenverlust"
RTO (Recovery Time Objective) Maximale Wiederherstellungszeit "System innerhalb von 4 Stunden wiederhergestellt"

Backup-Strategie-Beispiel:

graph LR
    subgraph Täglich
        A1[Full Backup Mo]
        A2[Incremental Di]
        A3[Incremental Mi]
        A4[Incremental Do]
        A5[Incremental Fr]
    end

    subgraph Wöchentlich
        B1[Full Backup Sa]
    end

    subgraph Monatlich
        C1[Full Backup 1. So im Monat]
    end

    A1 --> B1
    B1 --> C1
    C1 --> D[Archivierung]

Disaster Recovery Plan (DRP):

Ein DRP sollte folgende Elemente enthalten:

  1. Kritische Systeme identifizieren: Welche Systeme sind für den Geschäftsbetrieb essenziell?
  2. RTO/RPO definieren: Für jedes System individuelle Ziele
  3. Backup-Strategie: Regelmäßige Backups mit Test-Wiederherstellungen
  4. Notfallstandort: Sekundärer Standort (Hot Standby, Cold Standby)
  5. Notfallteam: Verantwortlichkeiten und Kommunikationsplan
  6. Testplan: Regelmäßige Tests des Disaster Recovery (mindestens jährlich)

4.3 Data Lakes und Data Warehouses

Data Lake:

  • Speicherung von Rohdaten (strukturiert, unstrukturiert, semi-strukturiert)
  • Schema-on-Read: Datenstruktur wird bei Nutzung definiert
  • Flexible Exploration und Analyse
  • Typische Technologien: Amazon S3, Azure Data Lake Storage, Hadoop HDFS

Data Warehouse:

  • Speicherung von strukturierten Daten für Berichterstattung
  • Schema-on-Write: Datenstruktur wird bei Speicherung definiert
  • Optimiert für OLAP (Online Analytical Processing)
  • Typische Technologien: Snowflake, Amazon Redshift, Google BigQuery, Azure Synapse

Vergleich:

Aspekt Data Lake Data Warehouse
Datenformat Rohdaten,多样化格式 Strukturierte Daten
Schema Schema-on-Read Schema-on-Write
Zweck Exploration, Machine Learning Berichterstattung, BI
Flexibilität Hoch Mittel
Abfrageperformance Variierend Optimiert
Kosten Geringer pro TB Höher pro TB
Governance Herausfordernd Einfacher

4.4 Datenqualität und Governance

Dimensionen der Datenqualität:

Dimension Beschreibung Beispiel
Genauigkeit Daten sind korrekt Die E-Mail-Adresse "max@mustermann.de" ist gültig
Vollständigkeit Alle Daten sind vorhanden Alle Pflichtfelder sind ausgefüllt
Konsistenz Daten sind widerspruchsfrei Kundendaten sind in allen Systemen gleich
Aktualität Daten sind aktuell Adressdaten wurden kürzlich aktualisiert
Validität Daten entsprechen dem Format Telefonnummern haben gültiges Format
Eindeutigkeit Keine Duplikate Jeder Kunde ist nur einmal vorhanden

Data Governance-Elemente:

  • Data Stewards: Verantwortlich für Datenqualität und -richtlinien
  • Data Catalog: Übersicht aller Datenquellen und Metadaten
  • Data Lineage: Verfolgung der Datenherkunft und -transformationen
  • Data Classification: Einteilung nach Sensibilität (Public, Internal, Confidential, Restricted)
  • Data Retention Policy: Regeln für Aufbewahrung und Löschung von Daten

5. Architektur

5.1 Architektur-Muster

Monolith:

graph TD
    A[Benutzer] --> B[Monolithische Anwendung]
    B --> B1[Benutzerverwaltung]
    B --> B2[Geschäftslogik]
    B --> B3[Datenschicht]
    B --> B4[Reporting]

    B1 --> C[Database]
    B2 --> C
    B3 --> C
    B4 --> C
  • Vorteile: Einfach zu entwickeln, testen und deployen
  • Nachteile: Skalierbarkeits-Probleme, enge Kopplung, schwierige Team-Skalierung

Microservices:

graph TD
    A[Benutzer] --> B[API Gateway]

    B --> C1[User Service]
    B --> C2[Order Service]
    B --> C3[Payment Service]
    B --> C4[Notification Service]

    C1 --> D1[(User DB)]
    C2 --> D2[(Order DB)]
    C3 --> D3[(Payment DB)]
    C4 --> D4[(Notification DB)]
  • Vorteile: Skalierbar, unabhängige Teams, Technologie-Heterogenität
  • Nachteile: Komplexität, Netzwerk-Overhead, Verteilte Transaktionen

5.2 Skalierbarkeit

Vertical Scaling (Scale Up):

  • Erhöhung der Ressourcen eines einzelnen Servers (CPU, RAM, Storage)
  • Einfach zu implementieren
  • Aber physikalische Grenzen und höhere Kosten

Horizontal Scaling (Scale Out):

  • Hinzufügen weiterer Server
  • Höhere Verfügbarkeit und Kosten-Effizienz
  • Aber komplexe Koordination

Auto Scaling:

graph LR
    A[Last-Messung] --> B{Last > Threshold?}
    B -->|Ja| C[Scale Up]
    B -->|Nein| D{Last < Low Threshold?}
    D -->|Ja| E[Scale Down]
    D -->|Nein| A
    C --> A
    E --> A

5.3 Performance-Optimierung

Caching-Strategien:

Typ Beschreibung Beispiel
In-Memory Cache Daten im RAM zwischengespeichert Redis, Memcached
CDN Cache Statische Inhalte weltweit verteilt Cloudflare, Akamai
Database Cache Datenbank-Query-Ergebnisse zwischengespeichert Redis Query Cache
Application Cache Cache auf Anwendungsebene Spring Cache, Guava Cache

Database Optimization:

  • Indexing: Indexe für häufige Abfragen erstellen
  • Query Optimization: Langsame Queries identifizieren und optimieren
  • Connection Pooling: Datenbank-Verbindungen wiederverwenden
  • Read Replicas: Lesezugriffe auf Read-Replicas verteilen

Schlüsselbegriffe

Begriff Definition
STRIDE Modell zur Identifizierung von Sicherheitsbedrohungen (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege)
Defense in Depth Schicht-Sicherheitsstrategie mit mehreren unabhängigen Sicherheitsmechanismen
Security-by-Design Sicherheit wird von Anfang an in die Architektur integriert
MFA / 2FA Multi-Faktor-Authentifizierung, mehrere unabhängige Faktoren für Authentifizierung
RPO Recovery Point Objective, maximaler Datenverlust bei einem Disaster
RTO Recovery Time Objective, maximale Zeit zur Wiederherstellung nach einem Disaster
DSGVO / GDPR Datenschutz-Grundverordnung, europäische Datenschutzgesetzgebung
ISO 27001 Internationaler Standard für Informationssicherheits-Managementsysteme
SOX Sarbanes-Oxley Act, US-Gesetzgebung für Finanzberichterstattung
Data Lake Zentrale Speicherung von Rohdaten für flexiblen Zugriff
Data Warehouse Strukturierte Speicherung von Daten für Berichterstattung und BI

Verständnisfragen

Frage 1: STRIDE-Analyse

Sie erstellen ein Online-Banking-System. Führen Sie eine STRIDE-Analyse für das Szenario "Überweisung" durch und identifizieren Sie für jeden STRIDE-Buchstaben eine konkrete Bedrohung und eine geeignete Gegenmaßnahme.

Lösung: STRIDE-Analyse für Überweisung:

STRIDE-Buchstabe Bedrohung Gegenmaßnahme
S (Spoofing) Angreifer gibt sich als authentifizierter Bankkunde aus und sendet Überweisungen im Namen des Opfers Multi-Faktor-Authentifizierung (MFA) für Überweisungen, Anomalie-Erkennung für IP-Adressen/Geräte
T (Tampering) Angreifer manipuliert den Überweisungsbetrag vor der Absendung (z.B. €10.000 → €100.000) Serverseitige Validierung aller Beträge, Digitale Signaturen für Transaktionen, Audit-Logs für Änderungen
R (Repudiation) Kunde bestreitet die Überweisung, um nicht zahlen zu müssen Umfassende Audit-Logs mit Zeitstempel, IP-Adresse, User-Agent, MFA-Bestätigung protokollieren, Einwilligungs-Tan erfassen
I (Information Disclosure) Angreifer erhält Zugriff auf Bankdaten oder Überweisungsdetails Verschlüsselung aller sensiblen Daten (At Rest und In Transit), Zugriffsbeschränkung nach Need-to-Know, Datenmaskierung in Logs
D (Denial of Service) Angreifer überlastet das System mit Überweisungsanfragen, reguläre Kunden können keine Überweisungen tätigen Rate Limiting, DDoS-Schutz, Horizontal Scaling, Load Balancing, CAPTCHA bei hohem Volumen
E (Elevation of Privilege) Angreifer eskaliert von normalem Benutzerkonto zu Administrator-Rechten und manipuliert Überweisungen Principle of Least Privilege, Regelmäßige Sicherheits-Updates, Penetration-Tests, Code-Reviews für Rechte-Checks
Frage 2: DSGVO-Compliance

Ein E-Commerce-Unternehmen plant die Speicherung von Kundendaten (Name, Adresse, E-Mail, Bestellhistorie, Zahlungsdaten). Welche DSGVO-Anforderungen müssen bei der technischen Umsetzung berücksichtigt werden?

Lösung: DSGVO-Anforderungen für E-Commerce-Kundendaten:

1. Datenerhebung und Einwilligung (Art. 7, Art. 9): - Klare Datenschutzerklärung (Art. 13) - Explizite Einwilligung für Marketing-E-Mails (Double Opt-In) - Cookie-Banner für Tracking - Dokumentation aller Einwilligungen (Zeitstempel, IP)

2. Datenschutz durch Technik (Privacy by Design - Art. 25): - Data Minimization: Nur notwendige Daten erheben - Verschlüsselung personenbezogener Daten (At Rest: AES-256, In Transit: TLS 1.3) - Pseudonymisierung wo möglich (z.B. Hashing von E-Mails für Analyse)

3. Zugriffsrechte und Zugriffskontrolle (Art. 32): - Role-Based Access Control (RBAC) - Audit-Logs für alle Zugriffe auf Kundendaten - Regelmäßige Überprüfung der Zugriffsrechte

4. Rechte der Betroffenen (Art. 15-21): - Recht auf Auskunft: API für Datenexport (JSON/CSV) - Recht auf Berichtigung: UI für Datenänderung - Recht auf Löschung ("Recht auf Vergessen"): Automatische Löschung nach Aufbewahrungsfrist (z.B. Bestellhistorie nach 10 Jahren) - Recht auf Einschränkung: Möglichkeit, Datenverarbeitung zu sperren

5. Datenportabilität (Art. 20): - Strukturierter, maschinenlesbarer Datenexport (z.B. JSON) - Direkt-Übertragung an andere Anbieter

6. Sicherheit der Datenverarbeitung (Art. 32): - Verschlüsselung (At Rest & In Transit) - Regelmäßige Sicherheits-Updates - Penetration-Tests vor Go-Live - Incident-Response-Plan für Datenpannen

7. Meldung von Datenpannen (Art. 33): - Automatische Erkennung von Sicherheitsvorfällen - Meldung an Aufsichtsbehörde innerhalb von 72 Stunden - Benachrichtigung betroffener Personen bei hohem Risiko

8. Auftragsverarbeitung (Art. 28): - AVV mit Cloud-Providern (AWS, Azure, etc.) - Datenverarbeitung nur in EU/EEC oder mit Angemessenheitsbeschluss

9. Aufbewahrungsfristen: - Bestellhistorie: 10 Jahre (steuerrechtliche Aufbewahrungspflicht) - Zahlungsdaten: Nur für Dauer der Transaktion (PCI-DSS-Compliance) - Nicht mehr benötigte Daten: Sofortige Löschung

Frage 3: Backup-Strategie

Ein Unternehmen hat folgende Anforderungen: Maximale Datenverlust von 1 Stunde, maximale Wiederherstellungszeit von 4 Stunden. Empfehlen Sie eine Backup-Strategie und begründen Sie Ihre Entscheidung.

Lösung: Anforderungen: - RPO (Recovery Point Objective): Maximal 1 Stunde Datenverlust - RTO (Recovery Time Objective): Maximal 4 Stunden Wiederherstellungszeit

Empfohlene Backup-Strategie:

1. Täglich: Full Backup + Hourly Incremental Backups - Full Backup: Täglich um 2 Uhr nachts (Rückkehr zur Basis) - Incremental Backups: Stündlich, jede volle Stunde (3:00, 4:00, ..., 23:00, 1:00) - Begründung: Incremental Backups sind schnell und speichereffizient, erfüllen das RPO von 1 Stunde

2. Wöchentlich: Full Backup auf externe Storage - Freitags: Vollständiges Backup auf Cloud-Storage oder Band - Begründung: Schutz vor logischen Fehlern, Ransomware, und physischen Schäden

3. Monatlich: Archivierung - 1. Sonntag im Monat: Langfristige Archivierung auf WORM-Speicher (Write Once, Read Many) - Begründung: Compliance-Anforderungen, Langzeitarchivierung für steuerliche Aufbewahrung

Wiederherstellungsprozess:

graph LR
    A[Incident erkannt] --> B[Letztes Full Backup wählen<br/>z.B. Heute 2:00 Uhr]
    B --> C[Incremental Backups anwenden<br/>bis zum gewünschten Zeitpunkt]
    C --> D[Zeit für Wiederherstellung]
    D --> E{Ist RTO (4h) eingehalten?}
    E -->|Ja| F[Erfolgreiche Wiederherstellung]
    E -->|Nein| G[Strategie anpassen<br/>z.B. Schnellere Storage]

Technische Umsetzung:

  • Full Backup: Auf Hochleistungs-SSD-Storage (schnelles Wiederherstellen)
  • Incremental Backups: Auf SSD-Storage mit Deduplizierung
  • Wöchentliche Backups: Auf Cloud-Storage (z.B. AWS S3 Glacier)
  • Archivierung: Auf Immutable Storage (WORM)

Zeitabschätzung für RTO von 4 Stunden:

Schritt Zeit

| Full Backup wiederherstellen | 2 Stunden | | Incremental Backups anwenden (z.B. 5 Stück) | 1 Stunde | | Integritätsprüfung und Verifizierung | 0,5 Stunden | | Puffer für Probleme | 0,5 Stunden | | Gesamt | 4 Stunden |

**Zusätzliche Maßnahmen:**

- **Test-Wiederherstellungen**: Monatlich durchführen, um RTO zu verifizieren
- **Monitoring**: Automatische Benachrichtigung bei fehlgeschlagenen Backups
- **Disaster Recovery-Plan**: Dokumentierter Prozess mit Verantwortlichkeiten
- **Hot Standby**: Sekundärer Standort für kritische Systeme

**Begründung der Entscheidung:**

Diese Strategie erfüllt die RPO-Anforderung von 1 Stunde durch stündliche Incremental Backups und die RTO-Anforderung von 4 Stunden durch schnelle Full-Backups auf Hochleistungs-Storage. Die wöchentlichen Backups und Archivierung bieten zusätzlichen Schutz gegen logische Fehler und Compliance-Einhaltung.