Wie realisiert man in der EDV eine Sandbox?

**Eine Sandbox in der EDV realisiert man, indem man ein Programm technisch vom restlichen System trennt und ihm nur exakt die Rechte, Dateien, Netzwerkzugriffe und Systemaufrufe gibt, die es wirklich braucht.** Entscheidend ist: Eine Sandbox ist kein einzelnes Produkt, sondern ein Bündel aus Isolation + Rechtebegrenzung + Kontrolle des Datenflusses. ([learn.microsoft.com](https://learn.microsoft.com/en-us/entra/identity-platform/secure-least-privileged-access)) ## Was praktisch dahintersteckt Die sauberste Umsetzung folgt immer demselben Muster: - **eigene Ausführungsumgebung** für den Prozess - **Least Privilege**: keine Admin-Rechte, keine unnötigen Berechtigungen - **begrenzter Zugriff** auf Dateisystem, Registry, Geräte, IPC und Netzwerk - **kontrollierte Schnittstellen** für alles, was die Anwendung doch braucht - **Überwachung und Reset-Möglichkeit**, damit die Umgebung nach Nutzung verworfen werden kann Genau das ist der Sicherheitsgewinn: Wenn die Anwendung kompromittiert wird, bleibt der Schaden auf diese kleine Umgebung begrenzt statt das ganze System zu betreffen. ([learn.microsoft.com](https://learn.microsoft.com/en-us/entra/identity-platform/secure-least-privileged-access)) ## Die drei üblichen Wege ### 1. Betriebssystem-Sandbox Hier läuft die Anwendung weiter auf demselben OS, aber mit stark eingeschränkten Rechten. Typische Mittel sind: - eigener Benutzer oder Low-Privilege-Token - eingeschränkte Dateipfade - blockierte oder gefilterte Systemaufrufe - Capability-/Manifest-basierte Freigaben - Mandatory Access Control wie SELinux/AppArmor Das ist meist der beste Kompromiss aus Sicherheit und Performance. Unter Windows ist **AppContainer** genau so ein Modell: Prozesse laufen mit niedriger Integrität und bekommen nur explizit erlaubte Fähigkeiten. ([learn.microsoft.com](https://learn.microsoft.com/en-us/windows/security/book/application-security-application-isolation)) ### 2. Container-Sandbox Container isolieren Prozesse stärker auf Ebene von Namespaces, Cgroups und Policies. Das ist gut für Server, Build-Systeme und Dienste, aber oft schwächer als eine echte VM, weil der Kernel geteilt wird. Der häufige Denkfehler ist: **Container sind nicht automatisch eine starke Sandbox.** Erst mit zusätzlichen Policies, seccomp, read-only Filesystem, ohne Privileged Mode und minimalen Capabilities wird daraus eine brauchbare Sicherheitsgrenze. Teilweise werden deshalb „sandboxed containers“ intern sogar als VM umgesetzt. ([bsi.bund.de](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/Sicherheitsanalyse_KVM/Sicherheitsanalyse_KVM.pdf?__blob=publicationFile&v=2)) ### 3. Virtuelle Maschine Die stärkste klassische Trennung ist eine eigene VM mit separatem Kernel. Das ist die richtige Wahl für: - Analyse unbekannter Software - Öffnen potenziell schädlicher Dateien - Browser-/Office-Isolation in Hochsicherheitsumgebungen - Malware-Analyse Nachteil: mehr Ressourcen, mehr Verwaltungsaufwand. Vorteil: deutlich kleinere Ausbruchfläche als bei reinem Prozess- oder Container-Sandboxing. ([bsi.bund.de](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/Sicherheitsanalyse_KVM/Sicherheitsanalyse_KVM.pdf?__blob=publicationFile&v=2)) ## So setzt man es sinnvoll um Für eine belastbare Sandbox reicht „in VM starten“ allein nicht. Sinnvoll ist diese Reihenfolge: 1. **Minimaler Startkontext** Kein Admin, kein Root, keine unnötigen Gruppen oder Tokens. ([learn.microsoft.com](https://learn.microsoft.com/en-us/entra/identity-platform/secure-least-privileged-access)) 2. **Dateisystem begrenzen** Nur ein Arbeitsverzeichnis freigeben, idealerweise temporär oder read-only. 3. **Netzwerk standardmäßig sperren** Nur gezielt erlauben, wenn die Anwendung es wirklich braucht. 4. **Systemaufrufe und Gerätezugriff reduzieren** Besonders wichtig bei Containern und riskanten Parsern. 5. **Datenaustausch nur über definierte Übergaben** Zum Beispiel Upload-Ordner, Copy-in/Copy-out oder API-Gateway statt Vollzugriff. 6. **Umgebung verwerfbar machen** Nach jeder Sitzung zurücksetzen oder neu erzeugen. Der entscheidende Unterschied zu vielen oberflächlichen Erklärungen: Eine Sandbox ist erst dann gut, wenn sie **standardmäßig alles verbietet** und nur das Nötige freischaltet. Nicht umgekehrt. ([learn.microsoft.com](https://learn.microsoft.com/en-us/entra/identity-platform/secure-least-privileged-access)) ## Konkretes Beispiel Wenn du etwa einen PDF-Renderer sandboxen willst, ist die schlechte Lösung: normales Benutzerkonto und Hoffnung. Die gute Lösung ist: - eigener isolierter Prozess - nur Leserechte auf die zu öffnende Datei - kein Schreibzugriff außerhalb eines Temp-Ordners - kein Netzwerk - keine Admin-Rechte - nach dem Schließen komplette Entsorgung der Umgebung Dann führt selbst eine Lücke im PDF-Parser nicht sofort zu einem Volltreffer auf das Gesamtsystem. Genau für solche riskanten Operationen werden Sandboxes gebaut. ([learn.microsoft.com](https://learn.microsoft.com/en-us/windows/win32/secauthz/implementing-an-appcontainer)) ## Klare Empfehlung Für **Desktop-Anwendungen** ist OS-Sandboxing meist die praktikabelste Lösung. Für **Server-Workloads** sind gehärtete Container sinnvoll. Für **unbekannte oder potenziell schädliche Software** ist eine **VM** die bessere Wahl. Die beste Antwort lautet also nicht „mit einer Sandbox-Software“, sondern: **durch konsequente Isolation auf der passenden Ebene und durch radikale Rechtebegrenzung.**