Kolumne: Stropek as a Service

Quo vadis, Security?
Keine Kommentare

Durch die Verschiebungen innerhalb der IT-Branche hin zu immer mehr Cloud-Computing und ihren Providern stellt sich häufig die Frage nach den Zuständigkeiten im Bereich IT-Security. Häufig gibt es bei der Umstellung Bedenken innerhalb von Unternehmen ob eventuell verlorengehender Autonomität und dem Verwerfen lange entwickelter Routinen und Richtlinien. Man muss allerdings gar nicht alle bisherigen Standards über Bord werfen.

Teamautonomie wird in Zeiten von Cloud-Computing großgeschrieben. Ich habe in dieser Kolumne schon mehrfach Plädoyers dafür gehalten, dass Teams entsprechend des DevOps-Gedankens die Verantwortung nicht nur für Softwarearchitektur und Code übernehmen, sondern auch für den Betrieb und damit verbundene Sicherheitsthemen. Mit modernen PaaS- und Serverless-Diensten wird das machbar. Nächtliche Patchorgien oder manuell installierte und gewartete Firewalls gibt es bei Cloud-native-Softwarelösungen in den großen Public-Cloud-Umgebungen nicht mehr. Für die Basissicherheit von Plattformen wie Webfarmen, Datenbankclustern und Message Brokern sorgt der Cloud-Provider. Für die Absicherung auf Anwendungsebene sind einfach zu integrierende Komponenten für Authentifizierung, Verschlüsselung und Logging verfügbar. Teams, die ihre Cloud-Umgebung kennen, eine gute Basisausbildung in der Entwicklung sicherer Software haben und das notwendige Verantwortungsbewusstsein mitbringen, sind in der Lage, die Gesamtverantwortung für ihre Cloud-basierenden Lösungen zu übernehmen.

Veränderungen sind schwierig

Eine Verschiebung von Verantwortung weg von zentralen Betriebs- und Sicherheitsteams hin zu den dezentralen Anwendungsteams sorgt meiner Erfahrung nach in vielen Organisationen für nicht unwesentliche Herausforderungen. Die über Jahre von Sicherheitsverantwortlichen erstellten Richtlinien sind in der Cloud nicht unverändert anwendbar. Im Gegenteil, sie sind oft hinderlich und kontraproduktiv. Hinzu kommen oft Schwierigkeiten auf persönlicher Ebene. Mitglieder zentraler Betriebs- und Sicherheitsabteilungen suchen ihre Rolle in einer von autonomen DevSecOps-Teams geprägten Welt. Änderungen werden nicht immer mit offenen Armen willkommen geheißen. Man sieht den eigenen Einflussbereich schwinden und hat Bedenken, ob die Entwicklungsteams wirklich das notwendige Wissen und die erforderliche Einstellung für den stabilen und sicheren Betrieb ihrer Software besitzen.

Zentrale Teams sind nicht obsolet

Es versteht sich von selbst, dass es in größeren Organisationen dedizierte Teams für die Sicherheit der eigenen IT-Infrastruktur (z. B. Netzwerk, lokal installierte Server, virtuelle Maschinen, Laptops, Smartphones etc.) braucht. Mir geht es jedoch hier um die Sicherheit von Softwarelösungen in der Public Cloud, die von autonomen Teams gestaltet und entwickelt werden. Selbst in diesem Umfeld halte ich persönlich in Organisationen ab einer gewissen Größe zentrale Teams, die gewisse Aufgaben für den Schutz der Softwarekomponenten in der Cloud übernehmen, für sinnvoll und notwendig. Ihre Rolle ändert sich aber. In Folge möchte ich Beispiele dafür nennen, wie zentrale Sicherheitsteams zur gesamtheitlichen Cloud-Security beitragen können.

Beratung

Nicht alle Softwareentwicklerinnen und -entwickler haben eine solide Ausbildung und umfangreiche praktische Erfahrung im Bereich Softwaresicherheit. So können z. B. Wissenslücken bei Netzwerksicherheit, Verschlüsselung, digitalen Signaturen etc. bestehen. Der Entwicklungsbedarf muss aber nicht nur technischer Natur, sondern kann auch oft mangelndes Bewusstsein für die Wichtigkeit von IT-Sicherheit und für Sicherheitsrisiken sein. Die Folge sind Sicherheitslücken auf Prozessebene, die von Angreifern ausgenutzt werden können.

Zentralen Sicherheitsteams kommt an dieser Stelle eine wichtige, beratende Rolle zu. Sie werden zu Servant Leaders, führen also die Teams in Sachen IT-Sicherheit in der Cloud, indem sie ihnen dienen bzw. Hilfe und Beratung anbieten. Hier einige Beispiele für konkrete Angebote:

  • Organisation und Durchführung von Weiterbildungsmaßnahmen über sicherheitsrelevante Dienste in den jeweiligen Public-Cloud-Umgebungen

  • Schulungen und Workshops zu sicherheitsbezogenem Basiswissen (technisch, organisatorisch)

  • Zusammenfassung zwingend einzuhaltender, organisationsspezifischer Rahmenbedingungen (z. B. besondere rechtliche Anforderungen an IT-Sicherheit); Ableitung konkreter technischer Handlungsanweisungen

  • kollegial abgewickelte Code- und Architekturreviews

  • Organisation und Begleitung spezifischer Sicherheitstests (z. B. Zertifizierungen, Penetrationstests)

  • Checklisten und Entwurfsmuster (technisch, organisatorisch)

  • Bereitstellung von Beispielcode und -projekten

  • Empfehlungen für zu nutzende und zu vermeidende Komponenten (Cloud-Dienste, Softwarekomponenten)

  • Einbringen von Spezialwissen (z. B. Pair Programming bei besonders sicherheitskritischen Softwareteilen)

Ich möchte an hier betonen, dass die Teammitglieder, die sich auf Produkt- und Projektmanagement konzentrieren, genauso Adressaten der genannten Maßnahmen sind wie die, die Code schreiben. In meiner Beratungsarbeit mit Teams, die in Richtung Cloud gehen, merke ich immer wieder, dass Sicherheit häufig auf technische Aspekte reduziert wird. Sicherheitsaspekte müssen allerdings bereits bei der fachlichen Gestaltung der Software berücksichtigt werden und das Produktmanagement muss dem Thema Sicherheit bei der Priorisierung der Aufgaben ausreichend Raum geben. Auch wenn es um kaufmännische Aspekte wie Abopreise oder Betriebskostenabschätzungen von Lösungen in der Public Cloud geht, muss Sicherheit im Hinterkopf behalten werden. Sonst kommt es zu Sparmaßnahmen an falschen Stellen, die negative Auswirkungen auf die Cloud-Sicherheit haben.

Monitoring

Selbst bei noch so engagierten DevSecOps-Teams sind Fehler unvermeidlich. Zentrale Sicherheitsteams sollten für diese Fälle ein digitales Sicherheitsnetz aufspannen, das Fehler erkennt, auf sie hinweist und vielleicht sogar verhindert bzw. automatisch korrigiert. Alle großen Public-Cloud-Plattformen bieten entsprechende Dienste an. Im Fall von Microsoft wären hier beispielsweise Azure Security Center, Azure Policy oder Azure Tenant Security Solution zu nennen. Mit Diensten wie diesen lassen sich zwingend einzuhaltende Richtlinien sicherstellen, automatische Sicherheitsprüfungen durchführen, automatische Sicherheitsbewertungen erstellen, fehlerhafte Konfigurationen automatisch ändern und vieles mehr.

Das richtige Maß an zentral definierten Regeln und Teamautonomie zu finden, ist in diesem Zusammenhang nicht einfach. Die Verlockung, Sicherheitslücken erst gar nicht aufkommen zu lassen und daher bei erzwungenen Richtlinien sehr strikt zu sein, ist groß. Das steht aber im Gegensatz dazu, dass autonome Teams selbständig die besten Lösungen für ihre konkreten Herausforderungen finden sollen. Ich möchte an dieser Stelle nochmals auf den Grundgedanken des Servant Leaderships verweisen. Zentrale Sicherheitsteams sollten nicht zu Verhinderern werden, vor denen man als DevSecOps-Team Angst haben muss, sondern vielmehr zu hilfreichen Begleitern, die den Teams Sicherheit geben.

Zentrale Dienste

In jeder größeren Cloud-Umgebung gibt es zentrale Dienste, die nicht einem einzelnen DevSecOps-Team zugeordnet werden können. Hier einige auf Microsoft Azure bezogene Beispiele:

  • Auswahl der entsprechenden Azure-Active-Directory-(AAD-)Lizenzform (Free, Premium etc.)

  • AAD-Konfiguration (Multi-Factor Authentication, Conditional Access, Privileged Identity Management)

  • Gliederung der Azure Subscriptions

  • Vergabe von Berechtigungen auf AAD-Tenant- und Subscription-Ebene

  • Planung und Umsetzung zentraler, virtueller Netzwerkinfrastruktur (z. B. VPN Gateway aus dem Firmennetzwerk, zentrale DNS-Infrastruktur)

Punkte wie diese sind für die sichere und reibungslose Nutzung einer Public-Cloud-Umgebung in größeren Organisationen entscheidend und meiner Ansicht nach am besten bei einem zentralen IT-Sicherheitsteam aufgehoben. Ich habe bei meiner Arbeit mit Kunden schon mehrfach erlebt, dass die Verantwortung für zentrale Cloud-Dienste ungeplant einfach dem ersten Team zugefallen ist, das den Weg in die Cloud gewagt hat. An sich bin ich ein großer Freund hemdsärmeliger, unbürokratischer Herangehensweisen an neue Themen. Organisationen müssen jedoch erkennen, wenn sich die Cloud von einem Randthema weg entwickelt und sich in größerem Umfang ausbreitet. In diesem Fall muss die Verantwortung für zentrale Cloud-Themen zu einem Team wandern, das dafür die notwendigen Kompetenzen und Ressourcen hat.

Unterstützung durch das Management

Der Erfolg des Wandels eines zentralen IT-Sicherheitsteams, der mit der Entwicklung von Cloud-native-Anwendungen verbunden ist, hängt entscheidend von der Unterstützung durch das Managementteam ab. Rollenbeschreibungen ändern sich, Verantwortlichkeiten müssen neu verteilt werden, Mitarbeiterinnen und Mitarbeiter werden zum Teil in andere Teams wandern, neue Talente müssen an Bord geholt werden, erfahrene Teammitglieder brauchen entsprechende Weiterbildung etc. Diese Maßnahmen brauchen Zeit und ein gewisses Budget.

Das zentrale IT-Sicherheitsteam muss in Sachen Public Cloud mit Kompetenzen und Verantwortlichkeiten ausgestattet werden, sonst folgen Frustration und Abwanderung wichtiger Teammitglieder. Kompetenzen ohne Verantwortung bergen die Gefahr von Entscheidungen, mit undurchdachten Auswirkungen, die Andere auszubaden haben. Insofern hat ein IT-Sicherheitsprojekt mit Fokus auf Public Cloud meiner Erfahrung nach immer einen wesentlichen organisatorischen Anteil und braucht daher Managementunterstützung auf strategischer Ebene.

 

Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
X
- Gib Deinen Standort ein -
- or -