Sicherheitskonzept für lokale Docker-Installationen in der Entwicklungsabteilung?
Hallo zusammen,
ich leite eine kleine IT-Abteilung in einer mittelständischen Softwareschmiede und mein Team arbeitet gerade schwer daran, die Versäumnisse der vergangenen Jahre aufzuholen. Vor allem die IT-Sicherheit ist wie zu erwarten eine Katastrophe. Zusätzlich sind Entwickler - abgesehen von Geschäftsführern - ohnehin die schwierigste Klientel, die man sich vorstellen kann. Sie brauchen alles, maximale Rechte und keine Einschränkungen, denn sonst fühlen sie sich in ihrer Kreativität eingeschränkt.
Nichtsdestoweniger habe ich ein dickes Fell und drücke die IT-Sicherheit durch. Auch im Client-Bereich. Es ist nämlich durchaus möglich, auch Entwickler-PCs mit einem gewissen Sicherheitsstandard zu betreiben. Das ganze ist natürlich immer ein Kampf gegen die ständigen neuen Anforderungen, die an unseren Support branden.
Allerdings müssen natürlich auch wir mit der Zeit gehen. Die Architektur unseres Produkts soll auf Mircoservices migriert werden, was auch mit einer Containerisierung einhergeht. Meine Herangehensweise wäre, zentral die entsprechende Infrastruktur so bereit zu stellen, das die Entwickler auf einem Server mittels Webinterface (z.B. Portainer) ihre Container testen können. Optimalerweise in einem eigenen Netzwerksegment so weit wie möglich zugenagelt. Aus der Entwicklungsabteilung wird natürlich damit argumentiert, dass dies zu kompliziert wäre weil sie Container kurzer Taktung erstellen, testen und wieder vernichten müssen. Sie wollen Docker direkt auf den Rechnern der Entwickler installierten. Natürlich mit allen nötigen Berechtigungen und den damit einhergehenden Sicherheitsproblemen.
Hat jemand von euch eine ähnliche Situation und kann mir erzählen, wie ihr das angegangen seid? Wie sieht euer Sicherheitskonzept (technisch und organisatorisch) aus, um den Entwicklern so viele Freiheiten wie möglich zu lassen? Wie verhindert ihr, dass alle möglichen Bullshit-Container aus dem Internet heruntergeladen und ausgeführt werden. Habt ihr - abgesehen von den üblichen Argumenten bezüglich Sicherheit und Datenschutz - vielleicht noch Munition für oder gegen dieses Konzept?
Mir selbst fehlt hier leider die Erfahrung und auch ansonsten ist das Unternehmen in diesem Bereich nicht gerade mit einem Übermaß an Fachwissen gesegnet. Im Großen und Ganzen beläuft sich die Anforderungen darauf, dass "Container die Zukunft sind und wir das machen müssen". Die Kollegen sehen nicht die technischen und organisatorischen Albtraum, der sich hier aufspannt sondern glauben, es wäre mit einem Doppelklick auf install.exe getan. Insofern bin ich dankbar für Ideen und Lösungskonzepte.
Danke schonmal vorab für den Input. Ich bin gespannt auf die Diskussion.
VG
Daniel
ich leite eine kleine IT-Abteilung in einer mittelständischen Softwareschmiede und mein Team arbeitet gerade schwer daran, die Versäumnisse der vergangenen Jahre aufzuholen. Vor allem die IT-Sicherheit ist wie zu erwarten eine Katastrophe. Zusätzlich sind Entwickler - abgesehen von Geschäftsführern - ohnehin die schwierigste Klientel, die man sich vorstellen kann. Sie brauchen alles, maximale Rechte und keine Einschränkungen, denn sonst fühlen sie sich in ihrer Kreativität eingeschränkt.
Nichtsdestoweniger habe ich ein dickes Fell und drücke die IT-Sicherheit durch. Auch im Client-Bereich. Es ist nämlich durchaus möglich, auch Entwickler-PCs mit einem gewissen Sicherheitsstandard zu betreiben. Das ganze ist natürlich immer ein Kampf gegen die ständigen neuen Anforderungen, die an unseren Support branden.
Allerdings müssen natürlich auch wir mit der Zeit gehen. Die Architektur unseres Produkts soll auf Mircoservices migriert werden, was auch mit einer Containerisierung einhergeht. Meine Herangehensweise wäre, zentral die entsprechende Infrastruktur so bereit zu stellen, das die Entwickler auf einem Server mittels Webinterface (z.B. Portainer) ihre Container testen können. Optimalerweise in einem eigenen Netzwerksegment so weit wie möglich zugenagelt. Aus der Entwicklungsabteilung wird natürlich damit argumentiert, dass dies zu kompliziert wäre weil sie Container kurzer Taktung erstellen, testen und wieder vernichten müssen. Sie wollen Docker direkt auf den Rechnern der Entwickler installierten. Natürlich mit allen nötigen Berechtigungen und den damit einhergehenden Sicherheitsproblemen.
Hat jemand von euch eine ähnliche Situation und kann mir erzählen, wie ihr das angegangen seid? Wie sieht euer Sicherheitskonzept (technisch und organisatorisch) aus, um den Entwicklern so viele Freiheiten wie möglich zu lassen? Wie verhindert ihr, dass alle möglichen Bullshit-Container aus dem Internet heruntergeladen und ausgeführt werden. Habt ihr - abgesehen von den üblichen Argumenten bezüglich Sicherheit und Datenschutz - vielleicht noch Munition für oder gegen dieses Konzept?
Mir selbst fehlt hier leider die Erfahrung und auch ansonsten ist das Unternehmen in diesem Bereich nicht gerade mit einem Übermaß an Fachwissen gesegnet. Im Großen und Ganzen beläuft sich die Anforderungen darauf, dass "Container die Zukunft sind und wir das machen müssen". Die Kollegen sehen nicht die technischen und organisatorischen Albtraum, der sich hier aufspannt sondern glauben, es wäre mit einem Doppelklick auf install.exe getan. Insofern bin ich dankbar für Ideen und Lösungskonzepte.
Danke schonmal vorab für den Input. Ich bin gespannt auf die Diskussion.
VG
Daniel
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673948
Url: https://administrator.de/forum/docker-sicherheitskonzept-entwicklung-container-673948.html
Ausgedruckt am: 21.07.2025 um 14:07 Uhr
4 Kommentare
Neuester Kommentar
Zitat von @Visucius:
Bestimmt ne doofe Frage. Aber wo ist der Unterschied ob ich einen Docker-Container auf einem Laptop eines Entwicklungs-Ing. in einem vLAN hoste oder auf einem Server in einem vLAN?
Willst Du alle Docker-Container vorher persönlich absegnen?!
Bestimmt ne doofe Frage. Aber wo ist der Unterschied ob ich einen Docker-Container auf einem Laptop eines Entwicklungs-Ing. in einem vLAN hoste oder auf einem Server in einem vLAN?
Willst Du alle Docker-Container vorher persönlich absegnen?!
Man will die "Coporate-Daten" nicht auf zerfrickelten Entwicklungskisten haben.
Ich kenne die Situation sowohl als Inhouse IT-Mitarbeiter und mittlerweile seit einigen Jahren als Berater in div. anderen Unternehmen.
Am Ende läuft es immer auf die selben 2-3 Lösungen hinaus:
- Option 1: Entwicklung findet auf dem jeweiligen "Haupt"-Endgerät des Entwicklers statt. Admin-Rechte werden entzogen und mittels PIM / PAM Lösung (meist BeyondTrust) gezielt und zeitlich begrenzt vergeben (sehr teuer & komplex)
- Option 2: Es gibt ein "Haupt"-Endgerät für Collaboration (Mails, Teams etc. pp.) + ein weiteres Entwicklungs-Endgerät ohne Zugriff auf Unternehmensdaten. Einbindung in zentrale Security-Lösungen in "weniger scharf" (Leicht umsetzbar, vergleichweise günstig)
- Option 3: Entwicklungsplattform via VDI bereitstellen. VDI ist in bestehende Security-Lösungen, aber in "weniger scharf" eingebunden. (Teuer, aber super in der Verwaltung weil zentralisiert. Entwicklungsdaten bleiben im Haus, kein Risiko bei Verlust von Gerät + wenn Entwickler Endgeräte austauschen, muss die Entwicklungsumgebung nicht erst tagelang wieder hergerichtet werden)
Alle anderen Versuche es "irgendwie" recht zu biegen, haben nicht mal mittelfristig gut funktioniert - So meine Erfahrung
Hallo,
dein Anliegen ist berechtigt, aber erfahrungsgemäß ist es in einem solchen Umfeld nicht direkt umsetzbar. Wenn die Entwickler auf zentraler Infrastruktur arbeiten sollen, muss die verfügbar sein und hinsichtlich aller Bedürfnisse funktionieren. Das ist ein Overhead an Hardware, Software, Prozessen und Personal, der in den meinsten Unternehmen jeder Größenordnung fehlt, wenn sie nicht von Grund auf aus einer Sicherheiskultur entwickelt wurden.
Ich rate, den Zustand vorläufig zu akzeptieren und Risiken mit allgemeinen Maßnahmen zu begegnen, im Wesentlichen neben AV/EDR:
Wenn du das mit vollständiger Abdeckung hast, behandelst Du schon mal viele Risiken, die nicht gerade Insider-Threat sind. Zusätzlich liefert es dir die Datenpunkte und die vorbereiteten Lösungen/Regelwerke, die Du für eine gekapselte Entwicklungsumgebung ohnehin bräuchtest - ohne dass dir die Entwicklung im Nacken sitzt. Du hast dann ein gepflegtes Software-Inventar, einen Überblick, was an Images geladen wird, was da drin ist und was evtl. riskant ist. Mit solchen Daten kannst Du der manchmal überforderten Entwicklung zuliefern (SBOM) und einen Mehrwert schaffen. Im Anschluss kann man dann eine zentrale Infrastruktur aufbauen, die funktioniert und auch akzeptiert wird, weil sie den Entwicklern lokale Bastelei und damit verbundene Fehler erspart.
Grüße
Richard
dein Anliegen ist berechtigt, aber erfahrungsgemäß ist es in einem solchen Umfeld nicht direkt umsetzbar. Wenn die Entwickler auf zentraler Infrastruktur arbeiten sollen, muss die verfügbar sein und hinsichtlich aller Bedürfnisse funktionieren. Das ist ein Overhead an Hardware, Software, Prozessen und Personal, der in den meinsten Unternehmen jeder Größenordnung fehlt, wenn sie nicht von Grund auf aus einer Sicherheiskultur entwickelt wurden.
Ich rate, den Zustand vorläufig zu akzeptieren und Risiken mit allgemeinen Maßnahmen zu begegnen, im Wesentlichen neben AV/EDR:
- Netzwerksicherheit mit Proxy-Inspection und Always-On-VPN
- Patch-Management und automatisiertes Software-Deployment
- Vulnerability-Scanning
- SIEM
Wenn du das mit vollständiger Abdeckung hast, behandelst Du schon mal viele Risiken, die nicht gerade Insider-Threat sind. Zusätzlich liefert es dir die Datenpunkte und die vorbereiteten Lösungen/Regelwerke, die Du für eine gekapselte Entwicklungsumgebung ohnehin bräuchtest - ohne dass dir die Entwicklung im Nacken sitzt. Du hast dann ein gepflegtes Software-Inventar, einen Überblick, was an Images geladen wird, was da drin ist und was evtl. riskant ist. Mit solchen Daten kannst Du der manchmal überforderten Entwicklung zuliefern (SBOM) und einen Mehrwert schaffen. Im Anschluss kann man dann eine zentrale Infrastruktur aufbauen, die funktioniert und auch akzeptiert wird, weil sie den Entwicklern lokale Bastelei und damit verbundene Fehler erspart.
Grüße
Richard
Moin,
ich halte dagegen, wieso sind Container die Zukunft? Oftmals sind diese Container, die schnell kommen länger am leben (viel länger) als man denkt und weiterhin dann ungepatched. Mein dramatischstes waren einmal grob 6 Jahre ohne jedwede Maintenance. Natürlich, super.
Aber du hast Recht, Entwickler sind schwierig.
ich halte dagegen, wieso sind Container die Zukunft? Oftmals sind diese Container, die schnell kommen länger am leben (viel länger) als man denkt und weiterhin dann ungepatched. Mein dramatischstes waren einmal grob 6 Jahre ohne jedwede Maintenance. Natürlich, super.
Aber du hast Recht, Entwickler sind schwierig.