Kapitel 8 · Sicherheit

Sicherheit

Sicherheitsrisiken bei lokalen Entwicklungstools

⚠️

Dieses Tutorial bezieht sich ausschliesslich auf die Verwendung von marimo mit localhost. Wer marimo in einem Netzwerk oder über das Internet betreiben möchte, muss sich eigenständig mit den notwendigen Sicherheitskonzepten auseinandersetzen – dies ist nicht Bestandteil dieser Schulung.

Viele Tools für Data Science und Notebook-Entwicklung – darunter marimo, Jupyter und ähnliche – laufen als lokaler Webserver in deinem Browser. Das ist praktisch, bringt aber einige Sicherheitsaspekte mit sich, die oft übersehen werden.

Lokaler Server heisst nicht automatisch sicher

Wenn du marimo edit ausführst, startet im Hintergrund ein Webserver – typischerweise unter http://localhost:2718. Das fühlt sich privat an, ist es aber nicht zwingend:

Andere Programme auf deinem Rechner können auf localhost zugreifen
Webseiten im Browser können unter Umständen Verbindungen zu localhost aufbauen (Cross-Site WebSocket Hijacking)
Netzwerk-Interfaces: Wird der Server auf 0.0.0.0 statt 127.0.0.1 gebunden, ist er für alle Geräte im lokalen Netzwerk erreichbar

💡

Faustregel: Behandle einen lokalen Entwicklungsserver ähnlich wie eine Anwendung, die im Netzwerk läuft – nicht wie ein rein privates Programm.

Typische Risiken bei Notebook-Tools

1. Veraltete Versionen

Entwicklungstools erhalten regelmässig Sicherheitsupdates. Da sie oft „im Hintergrund laufen" und nicht wie eine App aktiv genutzt werden, geraten Updates schnell in Vergessenheit.

# Regelmässig aktuell halten
pip install --upgrade marimo

2. Sensible Daten im Arbeitsverzeichnis

Notebooks liegen oft neben .venv-Dateien, Konfigurationen oder Zugangsdaten. Ein Tool mit Zugriff auf das Dateisystem kann diese Dateien prinzipiell lesen.

python

mein-projekt/
├── notebook.py       ← marimo öffnet dies
├── .venv              ← enthält API-Keys, Passwörter
├── config.json       ← Datenbankverbindungen
└── credentials.yaml  ← Cloud-Zugänge

Was ist das Home-Verzeichnis?

Das Home-Verzeichnis ist der persönliche Ordner deines Benutzerkontos. Auf macOS ist das /Users/deinname – also z. B. /Users/anna. Dort liegen alle deine Dateien, aber auch viele automatisch angelegte Konfigurationen und Zugangsdaten:

python

/Users/anna/                  ← Home-Verzeichnis
├── .ssh/                     ← SSH-Keys (Serverzugang)
├── .aws/                     ← AWS-Zugangsdaten
├── .zshrc                    ← Shell-Konfiguration
└── projekte/
    └── mein-projekt/        ← hier marimo starten ✅
        ├── hello_qrbill.py
        └── .venv

Wenn du marimo direkt im Home-Verzeichnis startest, hat der Prozess theoretisch Sicht auf all das. Startest du ihn stattdessen im Projektordner, ist die Exposition deutlich geringer – ein Angreifer müsste aktiv suchen, statt alles sofort vor sich zu haben.

# ❌ Zu weit oben – marimo sieht zu viel
cd ~
marimo edit

# ✅ Im Projektordner starten
cd ~/mein-projekt/mein-notebook
marimo edit

💡

Starte marimo immer im Projektordner, nicht im Home-Verzeichnis. Sensible Dateien gehören ausserdem in sichere Stores (z. B. einen Passwortmanager oder Secret Manager), nicht als Klartextdatei ins Projektverzeichnis.

3. Browser-Angriffsfläche

Da Notebook-Tools über den Browser bedient werden, gelten die gleichen Risiken wie bei Webanwendungen:

Eine bösartige Webseite könnte versuchen, im Hintergrund Anfragen an localhost zu senden
Browser-Extensions haben weitreichende Zugriffsrechte auf geöffnete Tabs

Empfehlung: Öffne Notebook-Tools in einem separaten Browser-Profil oder schliesse andere Tabs, wenn du mit sensiblen Daten arbeitest.

4. Netzwerkexposition und Isolierung

# ❌ Auf allen Interfaces lauschen – im lokalen Netzwerk sichtbar
marimo edit --host 0.0.0.0 

# ✅ Nur auf localhost – nur der eigene Rechner hat Zugriff
marimo edit --host 127.0.0.1

Besonders relevant in geteilten Umgebungen: Büronetzwerke, Universitätsnetzwerke, geteiltes WLAN.

Für Instanzen, die aus dem Internet erreichbar sein müssen (z. B. auf einem Server oder in der Cloud), gilt:

VPN oder IP-Whitelist vor den Notebook-Server schalten – niemals direkt ins Internet exponieren
Starke Authentifizierung aktivieren, idealerweise mit Token oder OAuth
Im Zweifel: lieber SSH-Tunneling nutzen als den Port direkt freigeben

# Sicherer Fernzugriff per SSH-Tunnel statt direkter Exposition
ssh -L 2718:localhost:2718 user@mein-server.example.com
# Danach lokal: http://localhost:2718

5. Monitoring – ungewöhnliche Aktivitäten erkennen

Notebook-Umgebungen können im laufenden Betrieb schwer zu überwachen sein. Worauf man achten sollte:

Unerwartete Terminal-Prozesse: Wurde eine Shell geöffnet, obwohl du das Terminal nicht genutzt hast?
Ungewöhnliche Dateizugriffe: Werden Log-Dateien, .env-Dateien oder Konfigurationen gelesen, die nichts mit dem Notebook zu tun haben?
Netzwerkverbindungen: Baut der marimo-Prozess Verbindungen nach aussen auf?

# Laufende Verbindungen des marimo-Prozesses prüfen (Linux/macOS)
lsof -i -n -P | grep marimo

# Prozessbaum beobachten – unerwartete Child-Prozesse?
pstree -p $(pgrep -f marimo)

Wer marimo in einer Team- oder Serverumgebung betreibt, sollte diese Checks in ein reguläres Monitoring einbauen.

6. Dependency Management

Notebook-Projekte haben oft viele Abhängigkeiten. Zwei häufige Fehler:

Unpinned Dependencies – pip install marimo installiert immer die neueste Version, die potenziell eine kompromittierte Abhängigkeit mitbringt.

Zu breite Versionsangaben – marimo>=0.20 erlaubt automatische Updates auf Versionen, die du nicht geprüft hast.

toml

# ❌ Zu unspezifisch – automatische Updates unkontrolliert
[project]
dependencies = ["marimo", "pandas>=2.0"]

# ✅ Exakte Versionen – reproduzierbar und kontrollierbar
[project]
dependencies = ["marimo==0.23.1", "pandas==2.2.3"]

# Aktuelle Umgebung einfrieren
pip freeze > requirements.txt

# Umgebung exakt reproduzieren
pip install -r requirements.txt

Ergänzend empfiehlt sich ein regelmässiger Scan der Abhängigkeiten auf bekannte Schwachstellen:

pip install pip-audit
pip-audit

Gute Gewohnheiten

Gewohnheit	Warum
Tools regelmässig updaten	Sicherheitslücken werden laufend entdeckt und gepatcht
`--host 127.0.0.1` verwenden	Verhindert Zugriff aus dem Netzwerk
Internet-Instanzen hinter VPN/Whitelist	Direkte Exposition ist ein hohes Risiko
Nicht im Home-Verzeichnis starten	Begrenzt Zugriff auf sensible Dateien
Separates Browser-Profil nutzen	Reduziert Browser-seitige Angriffsfläche
Ungewöhnliche Prozesse und Zugriffe beobachten	Angriffe früh erkennen
Exakte Versionen in `requirements.txt` pinnen	Verhindert unkontrollierte Dependency-Updates
`pip-audit` regelmässig ausführen	Bekannte Schwachstellen in Abhängigkeiten finden
Tools beenden wenn nicht gebraucht	Ein gestoppter Server kann nicht angegriffen werden

💡

Fazit: Lokale Entwicklungstools sind keine Sicherheitsrisiken per se – aber sie verdienen dieselbe Aufmerksamkeit wie andere Software. Wer seinen Notebook-Server isoliert betreibt, ungewöhnliche Aktivitäten im Blick behält und Abhängigkeiten kontrolliert verwaltet, arbeitet in der Praxis sehr sicher.