Team-Interview und Case Study
Solution Architect:in (mwd)
Vorstellung
Aufgabe 1
Registrierung eines neuen Smartphones als Signatur-Gerät

Warum?

Zweck:
Qualifizierte elektronische Signatur

Anforderungen:
Alleinige Kontrolle

Verfahren:
2-Faktor-Authentifizierung = Besitz + Wissen

Bislang

Chipkarte + Pin + Kartenleser + Anwendung
Ablauf vorher

Neu

Smartphone + App + PIN bzw. Biometrisches Verfahren
Ablauf neu

Voraussetzungen

  • Smartphone 1 hat die App und ist mit seinem Zertifikat registriert
  • Smartphone 2 hat die App und ein Zertifikat, ist aber nicht registriert
  • Anwender hat Zugriff auf beide Smartphones und die Anwendung zur Verwaltung

Anmeldung in der Anwendung

Anmeldung

Registrierung des neuen Geräts

Registrierung

Sonderfall: Verlorenes Smartphone

  • Zertifikat ist auf dem Gerät gespeichert
  • „Besitz” ist damit nicht mehr gegeben
  • für den Anwender: kein Zugriff mehr möglich
  • für den Finder: auch kein Zugriff möglich

Vorgehen bei Verlust

  • Identifizierbarkeit ist ohnehin notwendig
  • „Online Certificate Status Protocol” vor jeder Signatur
  • kein Backend, kein OCSP, keine Signatur
Aufgabe 2
Abstürze, Fehleranalyse, Monitoring

Abstürze vermeiden

  • Usability leidet, damit Zufriedenheit und Akzeptanz
  • Abstürze führen zu Folgeproblemen
  • aber vor allem: Hinweis auf mögliche Sicherheitslücken
Abstürze bedeuten, dass Zustände auftreten, die vorher nicht bedacht und berücksichtigt wurden.

Ursachen

  • Gesamtkonstrukt aus verteilten Komponenten
  • jede Komponenten für sich ist komplex
  • unzuverlässige Kommunikation zwischen den Komponenten
  • Hardwarefehler, Softwarefehler, Fehler in der Programmierung

Übersicht

Übersicht
Abstürze können also immer auftreten –
sollten sie aber nicht.

Werkzeuge

  • Absturz-Erkennung und Logging in der App
  • Logging von Zugriffen, Ereignissen und Zuständen im Backend
  • Monitoring von Systemzuständen
  • Erfassung zusammenhängender Ereignisse

Problem

verteilte Anwendung – viele unterschiedliche Daten in verschiedenen Formaten

Lösung: OpenTelemetry

  • standardisierte Schnittstellen und Formate
  • Unterstützung für viele Sprachen und Plattformen
  • Integration mit vielen Tools und Diensten
  • Open Source und On-Premise

Software-Stack

  • App: OpenTelemetry SDK für Android oder iOS
  • Reverse Proxy/Load Balancer: z.B. ngx_otel_module für Nginx
  • Backend: OpenTelemetry SDK
  • Logs: Grafana Loki
  • Metriken: Prometheus mit InfluxDB
  • Traces: Grafana Tempo
  • „Zentrale”: Grafana Alloy
  • GUI und Alerting: Grafana

Zusätzlich: eigene Metriken definieren

  • Status aller Komponenten
  • Status der Verbindungen zwischen den Komponenten
  • Anzahl der aktiven Nutzer
  • Anzahl der Abstürze
  • Anzahl der problematischen HTTP-Requests

Übersicht

Übersicht

Beispiel

Grafana Dashboard 1

Beispiel

Grafana Dashboard 2

Beispiel

Grafana Dashboard 3

Vorteile

  • ganzheitliche Sicht auf die Anwendung
  • frühzeitige Erkennung von Problemen
  • schnelle Analyse von Ursachen

Diskussion