In dieser Ausgabe seiner Kolumne geht Rainer Stropek auf Problematiken ein, die Firmen häufig sehen, wenn sie sich mit dem Thema der Public Cloud konfrontiert sehen. Oft nutzen Unternehmen nicht das volle Potenzial der Cloud aufgrund verschiedener Ängste und Sorgen. Um diese möglichst zu nehmen, stehen auch Entwickler im Fokus der Verantwortung.
Identity Management als Herausforderung in SaaS-Anwendungen
Wenn ich mit Kunden arbeite, die den Umstieg von klassischer IT in Richtung Cloud planen, stehen in Sachen Informationssicherheit so gut wie immer zwei Fragen im Mittelpunkt: Wie halten wir Hacker durch Firewalls von unseren Servern fern und wie verhindern wir das Mitlauschen der US-Cloud-Provider? Diese Fragen spiegeln den typischen Sicherheitsansatz wider, den Firmen seit Jahrzehnten verfolgen. Sie schotten ihr Netzwerk durch Firewalls vom Internet ab und treffen unterschiedlich stark ausgeprägte Maßnahmen, um ihr lokales Netz sicher zu halten. Die Serverhardware und große Teile ihrer Netzwerkinfrastruktur halten sie unter ihrer physischen Kontrolle, um den Zugriff durch nicht berechtigte Personen zu verhindern und dadurch den Datenschutz sicherzustellen.
Diese Maßnahmen prägen auch die Organisationsstruktur. Es gibt in der Regel eine eigene IT-Sicherheitsabteilung, die zum Großteil aus Expertinnen und Experten für Firewalls, Netzwerksicherheit, Virenscanner und Betriebssicherheit im Rechenzentrum besteht. Sie arbeiten Hand in Hand mit den Administratorinnen und Administratoren, die die Hoheit über hochprivilegierte Benutzerkonten sowie die Verantwortung für die Hochverfügbarkeit der Basisinfrastruktur besitzen und sich um Updates kümmern. Die Softwareentwicklung ist organisatorisch getrennt.
In der Cloud ist alles anders
Firmen, die seit langer Zeit so organisiert sind, fühlen sich beim Gedanken an eine Public Cloud im ersten Moment unwohl. Erstens verlieren sie in der Cloud die physische Kontrolle über ihre Server- und Netzwerkinfrastruktur. Die dicke Stahltür, mit der ihr eigenes Rechenzentrum versperrt ist, sehen sie nicht mehr. Es hat sich aber mittlerweile bei praktisch allen meinen Kunden die Überzeugung durchgesetzt, dass die großen Cloud-Provider in Sachen Rechenzentrumsbetrieb wissen, was sie tun. Diverse ISO-Zertifizierungen durch unabhängige Prüfinstitute und viele Videos, in denen die beeindruckenden Sicherheitsmaßnahmen präsentiert werden, zeigen Wirkung. Man findet sich damit ab, ein wenig Kontrolle abzugeben.
Dann ist da aber als Nächstes die Sache mit PaaS und Serverless. Cloud-Expertinnen und -Experten wie ich werden nicht müde, den Kunden zu erzählen, dass man mit IaaS das Potenzial der Cloud nicht ausschöpft. Wer von der Cloud in vollem Umfang profitieren möchte, setzt auf Platform as a Service (PaaS) und Serverless. Das bedeutet aber, dass man auch auf Softwareebene Kontrolle abgeben muss. Keine Betriebssystemupdates mehr selbst installieren, keine SQL-Serverupdates mehr durchführen, keine neuen .NET-Versionen einspielen, keine Serverzertifikate mehr manuell erneuern etc. Die Serverplattformen in der Public Cloud sind außerdem von Haus aus für den Betrieb im öffentlichen Internet ausgelegt und haben Firewalls, Load Balancer und Co. gleich eingebaut. Sie in virtuelle Netzwerke (VNets) zu integrieren und dadurch vom öffentlichen Internet abzuschotten, war beispielsweise in Azure bisher schwierig und wird durch Private Links erst langsam möglich. Treffen etablierte IT-Sicherheitsmaßnahmen auf so fundamental geänderte Grundvoraussetzungen, braucht es ein generelles Umdenken, wenn man die neuen Cloud-Dienste nutzen will.
Geänderte Erwartungshaltungen
Zu all den oben erwähnten Änderungen kommt noch hinzu, dass die Erwartungshaltung der Benutzer sich in den letzten Jahren deutlich verändert hat. Aus dem Privatleben sind sie durch OneDrive, Dropbox, Gmail, WhatsApp etc. gewohnt, dass man auf jedem Gerät von überall aus auf alle seine Daten zugreifen kann. Ausgewählte Fotos vom letzten Urlaub mit Freunden zu teilen ist ein Kinderspiel.
Die große Herausforderung für moderne Informationssicherheit ist es, den Spagat aus Sicherheit und bequemem, problemlosem Arbeiten über das Internet zu schaffen. Das ist aus meiner Sicht ohne massive Kostensteigerung nur dann machbar, wenn man bereit ist, Gewohntes über Bord zu werfen, Aufgaben durch vermehrten Einsatz von PaaS- und Serverless-Cloud-Komponenten an den Cloud-Provider abzugeben und einen geänderten Sicherheitsansatz zu verfolgen, der nicht mehr nur durch Firewalls, Virenscanner und physische Zutrittssicherheit geprägt ist.
Azure Active Directory
Azure Active Directory (AAD) ist eine zentrale Komponente in Microsoft-geprägten Organisationen, um Sicherheit zu gewährleisten und gleichzeitig den Benutzern mehr Freiheiten zu geben. Statt den Zugriff auf Unternehmensanwendungen von der physischen Verbindung zum LAN abhängig zu machen, nutzt man Techniken wie Conditional Access Policies [1]. Der Zugang zu Anwendungen und Daten hängt an verschiedenen Faktoren wie der Region, von der aus der Zugriff geschieht, der Art der Authentifizierung (z. B. Multi-Factor Authentication, kurz MFA), dem Sicherheitsniveau des Geräts (z. B. Betriebssystemversion, verschlüsselt ja/nein) etc. Als Voraussetzung, um das alles zu nutzen, müssen Anwendungen Single Sign-on (SSO) und Single Log-off (SLO) mit AAD unterstützen. Hier sind wir als Softwareentwicklerinnen und -entwickler gefragt. Wir müssen die Möglichkeiten von AAD sowie die zugrundeliegenden Protokolle wie OpenID Connect kennen und einsetzen können.
Keine Geheimnisse mehr
Das beste AAD hilft nichts, wenn an allen Ecken und Enden Lücken vorhanden sind und man sich erst recht regelmäßig über irgendwelche Secrets (z. B. Azure Storage Account Key, SQL-Server-Benutzer/Passwort, Azure Functions API Keys) an unternehmenskritischen IT-Systemen anmeldet. Solche Secrets in Textform sind riskant, da sie durch kleine Unachtsamkeiten leicht verloren gehen. Man checkt die falsche Konfigurationsdatei in die Quellcodeverwaltung ein und schon haben alle Entwicklerinnen und Entwickler das Passwort einer wichtigen Datenbank. Man bittet externe Personen um Hilfe und bespricht in einem Webmeeting Code. Dummerweise öffnet man während des Meetings eine Konfigurationsdatei mit sicherheitskritischen Secrets. Bleiben solche in falsche Hände gelangten Secrets dann vielleicht noch für lange Zeit unverändert, können unberechtigte Personen über das Internet auf Firmendaten, die in der Cloud liegen, zugreifen.
Die Lösung liegt darin, Secrets soweit technisch möglich aus dem Code zu verbannen. Nahezu alle wichtigen Azure-Dienste unterstützen mittlerweile die AAD-integrierte Anmeldung. Mit Managed Identities wird man den mühsamen Prozess des regelmäßigen Änderns von Passwörtern für Service Principals (Dienstbenutzer) los und überlässt ihn Azure. Dort, wo Secrets unumgänglich sind, gehören sie in den Azure Key Vault. Die Anmeldung dort läuft dann über AAD und/oder Managed Identities.
Plädoyer für DevSecOps
Ich bin ein Verfechter von DevSecOps. DevOps hat einen wesentlichen Teil der Verantwortung für den Betrieb von Software in der Cloud in die Entwicklungsteams verlagert. Als Entwicklerinnen und Entwickler müssen wir als Nächstes lernen, auch Überlegungen zur Informationssicherheit wie die oben genannten Beispiele von Anfang an in unsere Entwicklungsprozesse miteinzubeziehen. Wenn wichtige Anwendungen, APIs oder Datenbanken netzwerktechnisch plötzlich über das Internet erreichbar sind, steigt unsere Verantwortung. SSO/SLO, richtiger Umgang mit Secrets, Verschlüsselung sensitiver Daten, solche Dinge müssen wir als DevSecOps-Teams verinnerlichen.
Das von Sicherheitsexpertinnen geforderte Principle of Least Privilege (PoLP) müssen wir nicht nur akzeptieren, wir müssen es durch unsere Softwarearchitekturen und Prozesse aktiv unterstützen und einfordern. Infrastructure as Code (IaC) und moderne Logging-, Monitoring- und Telemetriedienste wie Application Insights helfen beispielsweise, Entwicklung und Betrieb ohne Zugriffsrechte auf Produktivumgebungen zu gewährleisten. Durch den richtigen Einsatz von virtuellen Netzwerken (VNets und Subnets), Network Security Groups (NSGs) und Private Endpoints sowie durch die automatisierte Konfiguration der in PaaS- und Serverless-Diensten integrierten Firewalls können wir unbefugte Zugriffe deutlich erschweren. In der Vergangenheit waren solche Themen Aufgabe von Netzwerksicherheitsteams. Verteilte Cloud-Lösungen sind für eine solche Aufgabentrennung zu komplex und sie verändern sich zu rasch.
Es ist darüber hinaus unsere Aufgabe, unsere eigenen IT-Systeme wie Quellcodeverwaltung oder CI/CD-Server kritisch zu durchleuchten. Wir müssen Konzepte entwickeln, wie wir das Einschleusen von Schadcode verhindern.
Übernehmen wir Verantwortung
Wenn wir als Entwicklungsteams Sicherheit als lästige Hürde sehen, die uns von außen in den Weg gestellt wird, dürfen wir uns nicht wundern, wenn auf traditionelle Sicherheitsmechanismen bestanden und die Nutzung moderner Cloudplattformen dadurch eingeschränkt oder sogar verunmöglicht wird. Erst wenn wir zeigen, dass wir uns nicht nur der Möglichkeiten, sondern auch der Risiken der Cloud bewusst sind, wird man uns das notwendige Vertrauen entgegenbringen und es uns erlauben, neue Wege zu gehen.
Reference: https://entwickler.de/online/windowsdeveloper/potenzial-cloud-umdenken-saas-579955794.html
