Artikel und Blogs sollten positiv sein. Stets das Gute suchen, neue Lösungen oder Denkweisen aufzeigen. Doch manchmal gibt es auch die Tage, die alles andere als das sind. Überall kaputte Prozesse, fehlendes technisches Verständnis und Grundlagen. Der heutige Rant in drei Akten geht in Richtung Softwareentwickler und deren Entscheidungen.
Erster Akt
Der Softwarelieferant eines gemeinsam betreuten Kunden möchte eine Python-Runtime installiert haben. Ein legitimer Wunsch, der nicht ohne Rückfragen bleibt. Warum? Was ist das genaue Problem? Gibt es vielleicht bereits bestehende Lösungen, die das Problem auch lösen?
Die Antwort auf meine Fragen kam prompt: Mit Hilfe von Python-Skripten sollen “Worker” die bestehende Warenwirtschaft des Software-Lieferanten funktional erweitern. Ein Wunsch, gegen den ich normalerweise nichts einzuwenden habe. Nur gibt es da ein Problem.
Auf dem Produktivsystem des Kunden gibt es nichts anzupassen. Im Operations hat grundsätzlich niemand, mich einschließlich, am “offenen Herzen” etwas auszuprobieren oder zu entwickeln. Ein Deployment erfolgt idealerweise automatisiert in Gestalt von Paketen, Installern oder Skripten. Stichwort: “Infrastructure as Code”.1
Der Softwarelieferant hat folglich keinen direkten Zugriff und arbeitet kontrolliert mit Jumphost und Entwicklermaschine so wie in meinem Blog “Management externer Dienstleister” beschrieben.2
Zweiter Akt
Von der Informationssicherheit betrachtet ist der Python-Interpreter auf einem Produktivsystem zunächst eine weitere Abhängigkeit, eine technische Schuld3, die stets aktuell zu halten ist.
Leider laufen Update- und Produktzyklen von Softwareprodukten und ihren Abhängigkeiten meist auseinander. Und da es sich um Windows-Software handelt, helfen weder WSUS, Online-Updates oder Windows selbst weiter. Von Anbeginn an fehlt Windows eine saubere Paketverwaltung.4
Eine Python-Runtime5 auf einem Produktivsystem wiegt auch in anderer Hinsicht schwer. Der Kunde betreibt seine Systeme mit einem aktivierten Application Whitelisting (Software Restriction Policies, SRP).6 Der einzige und sicherste Schutz vor Ransomware. Die Risikoabwägung ist vernichtend eindeutig: Wenn Anwender künftig beliebige Python-Skripte ausführen können, wird das zum klaffenden Loch im Schutzkonzept.
Die Vorteile bei der Softwareentwicklung werden hier teuer mit gravierenden Nachteilen im Operations erkauft.
Die naheliegende Lösung, die ich dem Software-Lieferanten vorgeschlagen habe. Ein Deployment in Gestalt von Executable-Binaries. Der pyInstaller7 packt beispielsweise alle Objekte und Abhängigkeiten wahlweise in einer .exe zusammen, ein Einzeiler:
python pyInstaller --onefile datei.py
Es bleibt beim Einzeiler auch wenn mehrere Dateien im Programmverzeichnis vorliegen:
FORFILES /P "c:\program files\ordnername" /M *.py /C "cmd /c "python pyInstaller --onefile @path"
Bei Verwendung von SRP und Abhängigkeiten sollte bedacht werden, dass pyInstaller bei Ausführung einer –onefile gepackten .exe die Abhängigkeiten als DLL in einen Temp-Ordner extrahiert und von dort aus versucht zu starten. Den –onefle Switch einfach weglassen, damit es auch in SRP klappt.
Ich habe dem Softwareentwickler Runtime und pyInstaller auf seiner isolierten Entwicklungsmaschine eingerichtet. Keine Python-Runtime auf einem Produktivsystem, keine zusätzliche Abhängigkeit, keine erhöhte Komplexität. Alle Beteiligten könnten in Ruhe weiter arbeiten.
Dritter Akt
Am Tag darauf erhielt ich die Antwort, dass dem Software-Lieferanten alles “zu kompliziert” sei. Er habe seine Programmierer nun angewiesen, alles in der Power-Shell umzusetzen.
Nun diese Problemlösung ist mir und dem Kunden auch Recht. Kein Einwand, wenn auf Bestehendes zurück gegriffen wird. Selbst im Falle der ungeliebte Power-Shell, die mit SRP und GPO hinreichend verwaltet wird.
Doch verstehen muss ich das alles nicht. Es bleiben G’schmäckle und Bestätigung zurück, Dev und Ops besser klar getrennt zu halten. Jeder andere hätte sich jetzt bei direktem Zugriff des Dienstleisters auf das produktive System ein unbemerktes Problem eingefangen.
Technische Entscheidungen können sehr schnell jedes Sicherheitskonzept untergraben wenn nicht sofort gegen gesteuert und Dienstleister klar geführt werden.
In diesem Sinne,
Euer Tomas Jakobs