Kolumne: Stropek as a Service

Gut gemeinte Security als Risikofaktor für die Cloud-Entwicklung
Kommentare

Security ist ein brandaktuelles Thema, gerade in Hinblick auf die Cloud. Firmen sollten sich dabei aber nicht selber im Weg stehen. Auch das zwiespältige Verhältnis der hiesigen Unternehmen zu GitHub und Open Source ist problematisch für die gesunde Weiterentwicklung der IT-Welt.

Workshops über Entwicklungstechnologien und Tools wie .NET Core, Angular, TypeScript & Co gehören zu meinem Job. Es kommt oft vor, dass ich solche Trainingsevents vor Ort bei Kunden mache und es sich dabei um relativ große Firmen handelt. Sicherheit wird in solchen Enterprise-Umgebungen natürlich groß geschrieben.

Auf der technischen Seite schützen Firewalls und Proxies. Organisatorisch begrenzen diverse Verträge und Policies den Spielraum der Entwicklungsteams. Scheint alles sinnvoll und durchdacht, hat allerdings einen Haken: Vor lauter Cloud-Panik verschlafen viele größere Firmen die Tatsache, dass ohne Cloud heute kaum mehr Software entwickelt werden kann, die auf dem aktuellen Stand der Technik ist. Die Folge ist, dass nicht selten gut gemeinte Sicherheitsmaßnahmen zum Securityalbtraum werden.

Proxies: Zusätzliche Sicherheit oder Feind der Cloud-Entwicklung?

Das erste konkrete Beispiel, über das ich berichten möchte, sind Proxies. Wenn ich ein Training über Webentwicklung in größeren Firmen mache, rechne ich mittlerweile schon fix mit einem nennenswerten Zeitbudget, das für Netzwerkproblembehebung draufgeht. Der Grund sind so gut wie immer Proxies.

Will man heute moderne Webentwicklungstools wie .NET Core, Node.js, Angular oder Visual Studio Code nutzen, kommt man ohne Cloud-Dienste wie NPM, NuGet und GitHub nicht weit. Das Dumme ist nur, dass die Netzwerk- und Sicherheitsteams in Großfirmen die Netzwerke nicht nur nach Kräften vor eindringenden Bösewichten schützen, sondern auch Verbindungen nach außen streng kontrollieren. Die Folge sind oft Proxies mit Authentifizierung.

NPM & Co brauchen die Proxyeinstellungen, damit sie ins Internet kommen. Nichts leichter als das: npm config set proxy, und schon klappt es. Es ist nur leider so, dass die Proxyeinstellungen inklusive eingebettetem Benutzernamen und Passwort in einer Textdatei auf der lokalen Festplatte landen. Das in Verbindung mit einer unverschlüsselten Festplatte, und schon ist aus der Sicherheitsmaßnahme Proxy eine große Sicherheitslücke geworden. Dazu kommt, dass man ohne Administratorrechte durch Kommandos wie npm config get proxy zu den Proxyeinstellungen inklusive Passwort kommt (Abb. 1). Treten vielleicht auch noch durch Proxy ausgelöste Zertifikatsprobleme auf? Kein Problem, drehen wir einfach TLS/SSL ab und verwenden HTTP statt HTTPS beim Zugriff auf NPM, dann klappt npm restore endlich.

Abb. 1: Proxyeinstellungen mit Passwort landen in einer Konfigurationsdatei

Abb. 1: Proxyeinstellungen mit Passwort landen in einer Konfigurationsdatei

Das Interessante daran ist, dass nahezu alle Entwicklungsteams, die ich im Rahmen von Workshops auf diesen Zusammenhang aufmerksam mache, darüber schon Bescheid wissen. Es ist ihnen auch klar, dass das sicherheitstechnisch keine sonderlich gute Idee ist. Sie berichten aber in der Regel, dass sie keine andere Chance haben. Oft höre ich Aussagen wie: „Den Netzwerkadmins ist das egal, ob wir da ein Problem haben. Die verstehen nicht, wofür wir das brauchen.“

Mein Appell an alle Entwicklerinnen und Entwickler, die vor ähnlichen Problemen stehen: Bitte schreit laut auf. Eskaliert das Problem zu euren Sicherheitsverantwortlichen. Erklärt, warum ihr ohne diese Cloud-Dienste nicht entwickeln könnt. Macht auf das Sicherheitsproblem aufmerksam. Wenn sich dann immer noch nichts ändert, habt ihr zumindest alles in eurer Macht Stehende getan.

Eigene Paketserver statt NuGet und NPM

Bei meinem zweiten Beispiel geht es nochmals um Paketmanager. Wenn sich in größeren Firmen das Bewusstsein durchsetzt, dass über NPM, NuGet & Co wichtige Bibliotheken aus dem Internet heruntergeladen werden, die dann ihren Weg indirekt ins Herz der eigenen Rechenzentren finden, entwickelt sich oft hektische Betriebsamkeit. Cloud-Skeptiker verlangen sofort die Errichtung eigener Paketserver im lokalen Netz. Sie versprechen sich davon zusätzliche Kontrolle und Sicherheit.

Lokale Paketserver sind eigentlich keine schlechte Idee – wenn sie ordentlich gewartet werden. In der Praxis kümmert sich aber in nahezu keinem Großunternehmen jemand um sie. Wie soll man schließlich ein so sperriges Thema wie Paketmanagement den Budgetverantwortlichen erklären? Die Folge: Veraltete und unvollständige Paketserver, abgelaufene Zertifikate, frustrierte Entwicklungsteams und schlussendlich das heimliche Umgehen der internen Paketserver und Laden der Pakete über dubiose Quellen aus dem Internet.

Mein Appell an alle Sicherheitsverantwortlichen: Nicht alle Cloud-Dienste für Entwicklungsteams sind schlecht. Eigene Server im lokalen Netz sind nur dann eine gute Idee, wenn man gewillt ist, diese Server langfristig und ordentlich zu warten. Wenn das nicht der Fall ist, sind die Dienste in der Cloud ganzheitlich gesehen die wesentlich sicherere Variante.

GitHub: Das zwiegespaltene Verhältnis zu Open Source

Mein drittes Beispiel ist der Umgang mit Open Source und im Speziellen GitHub in Großfirmen. Kostenlose Open-Source-Technologien werden gerne genommen, schließlich schont das das Budget, und Open Source macht sich immer gut in Strategiepräsentationen. Umgekehrt sehe ich jedoch fast immer in fassungslose Gesichter, wenn ich in Workshops bei größeren Firmen frage, warum nicht die eine oder andere intern entwickelte Komponente als Open-Source-Projekt auf GitHub veröffentlicht wird. „Unsere Dienstverträge verbieten uns, auch nur eine einzige Zeile Quellcode im Internet zu veröffentlichen“, solche Aussagen höre ich nicht selten. Meistens sind es diese Firmen, die sich im nächsten Satz über die mangelnde Qualität und Stabilität mancher Open-Source-Projekte beschweren. Nicht verwunderlich, wenn alle nur nehmen, aber nichts zurückgeben, oder? Das ist aber ein anderes Thema.

Worauf ich im Moment hinaus möchte, ist, dass ohne GitHub bei Sprachen und Plattformen wie C#, .NET, TypeScript, Angular, Node.js oder Azure nichts mehr geht. Wenn man ein Problem hat, meldet man das inklusive Beispielcode über ein GitHub Issue. Wenn ein Fehler in Dokumentation oder Code entdeckt wird und man weiß, wie er behoben werden kann, erstellt man einen Fix und anschließend einen Pull Request. Wenn man ein kniffliges Problem gelöst hat, das so bisher nicht dokumentiert war, veröffentlicht man ein Sample auf GitHub und schreibt einen Blogartikel. So läuft der Hase heutzutage in der Softwareentwicklung.

Liebe Entscheidungsträger: Policies, Dienstverträge oder Beraterverträge, die vor lauter Paranoia GitHub de facto unbrauchbar machen, tragen weder zur Effizienzsteigerung noch zur Erhöhung der Sicherheit bei. Die Folge sind wieder und wieder erfundene Räder, schlechte Softwarequalität, die Nutzung privater Accounts und Geräte zur Umgehung von Einschränkungen und nicht zuletzt das Abwandern wertvoller, frustrierter Talente. Nur die wenigsten Codemodule sind wirklich so geheim und geschäftskritisch, dass sie schützenswert sind. Mit allem anderen kann wesentlich freizügiger umgegangen werden.

Wer A sagt, muss auch B sagen

Firmen, die Cloud-basierende PaaS und SaaS-Dienste in der Softwareentwicklung vermeiden möchten, müssen gewillt sein, den daraus resultierenden Mehraufwand zu tragen. Das Aufbauen und Warten eigener Dienste im lokalen Netz ist teuer. Wer dabei schlampt und kaputtspart, macht aus gut gemeinten Sicherheitsvorkehrungen schnell das genaue Gegenteil.

Lesen Sie alle Ausgaben der Kolumne „Stropek as a Service„!
In der Kolumne greift Rainer Stropek spannende Aspekte wie die Finanzierung, den Customer Lifetime Value, aber auch wichtige Themen wie Billing, Kundenbindung durch Qualität oder APIs auf – alles aus der Sicht eines Unternehmers, der seit 20 Jahren in der IT-Branche tätig ist und seit fünf Jahren intensive Erfahrungen mit SaaS gesammelt hat.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -