Umgebungsvariable

Jedes Programm auf einem Computer braucht Einstellungen. Wo liegen die Daten? Welches Passwort gilt für den Zugriff auf einen anderen Dienst? Soll das Programm im Testmodus laufen oder für echte Nutzer? Solche Angaben kann man direkt in den Programmtext schreiben, aber das ist unpraktisch und unsicher. Stattdessen legt man sie als Umgebungsvariable ab: ein Name und ein Wert, die das Betriebssystem dem Programm beim Start übergibt. Ein typisches Beispiel sieht so aus: DATABASE_URL=postgres://server:5432/daten. Das Programm fragt beim Start nach dem Namen und bekommt den Wert zurück.

Warum Passwörter nicht in den Code gehören

Der wichtigste Grund für Umgebungsvariablen ist Sicherheit. Programmcode wird heute fast immer in Versionsverwaltungen wie GitHub gespeichert, also auf Servern, auf die viele Menschen Zugriff haben. Steht ein Zugangsschlüssel für einen KI-Dienst mitten im Code, landet er dort mit. Solche versehentlich veröffentlichten Schlüssel werden regelmäßig von automatischen Suchprogrammen gefunden und missbraucht. Rechnungen über mehrere tausend Euro für fremd genutzte Rechenzeit sind dabei keine Seltenheit.

Der zweite Grund ist Flexibilität. Dieselbe Software läuft meist an mehreren Orten: auf dem Laptop der Entwicklerin, auf einem Testserver und auf dem echten Server für die Kunden. Überall sind andere Datenbanken und andere Schlüssel nötig. Mit Umgebungsvariablen bleibt der Programmcode an allen drei Orten identisch. Nur die Werte von außen unterscheiden sich.

Dieses Prinzip hat sogar einen Namen. Die sogenannte Zwölf-Faktoren-Methode, eine bekannte Sammlung von Empfehlungen für Webanwendungen, fordert ausdrücklich: Konfiguration gehört in die Umgebung, nicht in den Code. Wer sich daran hält, kann eine Anwendung ohne Änderung am Programmtext auf einen anderen Server umziehen.

Vom Betriebssystem zum Programm

Technisch verwaltet das Betriebssystem für jeden laufenden Prozess eine Liste aus Namen und zugehörigen Werten. Ein Prozess ist einfach ein Programm, das gerade ausgeführt wird. Startet dieser Prozess ein weiteres Programm, gibt er seine Liste an das Kind weiter. Die Vererbung läuft also immer nach unten. Ein Programm kann seine eigenen Variablen ändern, aber nicht die des Programms, das es gestartet hat.

Beim Entwickeln schreibt man die Werte meist in eine Textdatei namens .env. Sie enthält Zeile für Zeile Einträge nach dem Muster NAME=WERT. Diese Datei wird bewusst von der Versionsverwaltung ausgeschlossen, damit sie nicht öffentlich wird. Auf echten Servern übernehmen andere Systeme diese Aufgabe, etwa die Verwaltungsoberfläche des Hosting-Anbieters oder spezielle Passworttresore.

Ein häufiger Irrtum: Umgebungsvariablen sind nicht verschlüsselt. Sie sind schlicht Text, den das Betriebssystem verwaltet. Wer bereits Zugriff auf den Server hat, kann sie in der Regel auslesen. Sie schützen also davor, dass Geheimnisse in den Code rutschen — nicht davor, dass jemand in den Server einbricht.

Von PATH bis OPENAI_API_KEY

Die bekannteste Umgebungsvariable heißt PATH und existiert auf Windows, macOS und Linux. Sie enthält eine Liste von Ordnern, in denen das System nach Programmen sucht. Wer in einer Kommandozeile ein Wort eintippt, löst genau diese Suche aus. Fehlermeldungen wie „Befehl nicht gefunden“ bedeuten meist nur, dass der passende Ordner nicht in PATH steht.

In der KI-Welt begegnet einem vor allem OPENAI_API_KEY oder ähnlich benannte Variablen anderer Anbieter. Fast jede Anleitung für ein KI-Programmierwerkzeug beginnt mit dem Schritt, diesen Schlüssel als Umgebungsvariable zu setzen. Die Programmbibliothek liest ihn dann automatisch aus, ohne dass man ihn im Code erwähnen muss.

Auch in Nachrichten tauchen Umgebungsvariablen auf, meist wenn etwas schiefgegangen ist. Berichte über Datenlecks nennen häufig falsch abgesicherte .env-Dateien als Ursache. Angreifer durchsuchen das Internet systematisch nach Servern, die solche Dateien versehentlich öffentlich ausliefern. Ein einziger Konfigurationsfehler reicht dann aus, um Tausende Zugangsdaten preiszugeben.