Wie Microgateways den Boden für Sicherheit in der Software-Entwicklung bereiten
In einer zunehmend digitalen und von Software geprägten Welt ist der Erfolg eines Unternehmens maßgeblich davon abhängig, wie schnell und sicher es Dienste entwickeln und bereitstellen kann. Ein Schlüsselaspekt hierbei sind DevOps und insbesondere DevSecOps, die für eine Kultur der kooperativen Zusammenarbeit über Funktionen hinweg stehen. Doch die Implementierung dieser strukturellen und technischen Veränderungen ist keineswegs trivial. Um erfolgreich zu sein, führt heute kein Weg mehr an Microgateways vorbei. Aber das ist nur ein Baustein – das vollständige Bild ist weitaus vielschichtiger.
Traditionell haben Software-Entwicklung und -Betrieb in einem Unternehmen unterschiedliche Ziele verfolgt:
- Softwareentwicklung muss agil, kreativ und auf dem neusten technischen Stand sein, um ständig neue Features liefern zu können
- IT Operations ist im Gegensatz dazu auf Stabilität, Sicherheit und Zuverlässigkeit ausgelegt.
DevOps vereint diesen scheinbaren Widerspruch zwischen Flexibilität und Stabilität. Dazu soll die gesamte Wertschöpfungskette von der Softwareentwicklung bis zum Betrieb auf interdisziplinäre Weise kombiniert werden. Das bricht Silodenken auf, indem es die Gräben zwischen den Silos überbrückt, und richtet die Organisation auf das gemeinsame Ziel der schnellen Lieferung neuer Funktionen in stabilen, sicheren Schritten aus.
Von DevOps zu DevSecOps – was versteckt sich dahinter?
Ursprünglich war Security eine Art "Torwächter" am Ende des Softwareentwicklungsprozesses, ähnlich wie Operations vor der Einführung von DevOps. Das "Sec" in "DevSecOps" betont und verdeutlicht die Zusammenarbeit und die Verschiebung der Verantwortung. In einer DevSecOps-Kultur verfügt jedes agile Team über einen Sicherheitsexperten, der sich um nicht-funktionale Anforderungen kümmert, wie etwa die Klassifizierung von Daten und andere Aspekte der Risikoanalyse. Dadurch wird sichergestellt, dass der Product Owner bei der Entwicklung auch Sicherheitsaspekte berücksichtigt.
Dieser proaktive Ansatz ermöglicht es den Teams, die Gesamtverantwortung für den Umfang ihrer Services zu übernehmen. Wenn die Sicherheit zudem asynchron zur Produktentwicklung integriert wird, kann der Product Owner sowohl die Geschwindigkeit als auch die Sicherheit steuern, ohne dabei eines von beiden zu vernachlässigen. Daher erfordert eine agile Entwicklung auch agile Infrastrukturen und agile Sicherheit.
Die Art und Weise, wie Software vor internen und externen Bedrohungen geschützt wird, entwickelt sich als Reaktion auf die aktuelle Bedrohungslage. Der jüngste Schritt in dieser Entwicklung ist die Einführung von Zero-Trust-Architekturen. Bei herkömmlichen Perimeter-Sicherheitsarchitekturen erfolgt die Trennung zwischen einem unsicheren externen Netzwerk und einem sicheren internen Netzwerk am Perimeter. Hier wird der gesamte Datenverkehr überwacht, und potenziell gefährlicher Verkehr wird blockiert. Bei Zero-Trust-Architekturen wird die Überwachung und Blockierung von Verkehr nicht mehr am Perimeter durchgeführt, sondern direkt von den Diensten selbst. Anders ausgedrückt, jeder Dienst prüft seinen eigenen Datenverkehr und erlaubt nur den als sicher erkannten Verkehr. Dies reduziert die Komplexität des Sicherheitssystems und macht es überschaubarer. Die Implementierung einer Zero-Trust-Architektur erfordert Technologien, die denen am Perimeter ähneln, jedoch in kleinerem und ressourcenschonendem Maßstab. Aus dieser Anforderung heraus entstand die Idee der Microgateways.
Microgateways als Enabler für DevSecOps
Die Stärke von Zero Trust liegt darin, Ressourcen und Sicherheitsmaßnahmen überall verteilen und an die Anforderungen anzupassen zu können. Sicherheit ist also nicht mehr nur an einem einzigen Ort konzentriert. Aber hier liegt auch eine große Herausforderung, denn nicht alles kann einfach überall verteilt werden. Eine solche Herausforderung betrifft etwa das Identitäts- und Zugangsmanagement (IAM): Um Benutzern ein nahtloses Single-Sign-On-Erlebnis zu bieten, ist es am besten, zentrale Authentifizierungs- und Identitätsmanagementdienste zu verwenden.
In diesem Kontext fungiert das Edge-Gateway als eine Art Wächter für Sicherheitsrichtlinien. Die eigentlichen Entscheidungen darüber, wer auf welche Ressourcen zugreifen darf, werden jedoch von einem zentralen IAM-Dienst getroffen (wie in einem Diagramm dargestellt). Die Prüfung der Identität der Benutzer und die Autorisierung, was sie tun dürfen, erfolgen durch die einzelnen Dienste und Ressourcen selbst.
Das zentrale Gateway bleibt wichtig
Das Aufstellen eines Edge Gateways vor den Microgateways ist keine technische Notwendigkeit, sondern eine Entscheidung im Designprozess. Diese Entscheidung basiert darauf, dass bestimmte Aufgaben besser auf einem sogenannten Edge-orientierten Gerät erledigt werden können, während andere eng mit einem bestimmten Service verbunden sind. Das Edge-orientierte Gateway hat deshalb eine eher generische Konfiguration. Dadurch wird die einfache und reibungslose Integration neuer Dienste ermöglicht, die von den einzelnen Microgateway-Instanzen geschützt werden. Mit anderen Worten, es dient als eine Art zentrale Schnittstelle, die es erleichtert, neue Dienste in das System aufzunehmen und sie effektiv zu schützen.
Das Microgateway macht DevOps- zu DevSecOps-Teams
Das Aufgabengebiet für die Integration von Funktionen, wie das Hinzufügen von Ausnahmeregelungen oder das Umleiten von URLs, liegt normalerweise beim Microgateway. Dieses Gateway ist eine schlanke Sicherheitskomponente, die einen bestimmten Dienst schützt. In einer Zero-Trust-Architektur sorgt jede Dienstinstanz nicht nur für ihren eigenen Schutz vor unerwünschtem Datenverkehr, sondern überprüft auch jede Anfrage, um sicherzustellen, dass nur ordnungsgemäß authentifizierte Benutzer Zugriff auf die entsprechenden Dienste und Daten haben. Die Entscheidung, ob ein Dienst oder eine Anwendung für externe Anfragen geöffnet wird, kann nach wie vor am Netzwerkperimeter getroffen werden.
Das Microgateway wird vom DevOps-Team des geschützten Dienstes verwaltet und unterstützt auf vielfältige Weise:
- Agilität: Mehrere unabhängige Entwicklungsteams profitieren von der bestehenden Infrastruktur. Da die Konfiguration des Microgateways vom Entwicklungsteam gewartet wird, erfordert eine neue Serviceversion wenig bis keine Koordinierung mit dem Gateway- Administrator.
- Skalierbarkeit und Verfügbarkeit: Microgateways werden direkt mit ihren Services eingerichtet und skalieren mit ihnen. Die Funktionen der Microgateways stellen sicher, dass Session-Informationen unabhängig davon zur Verfügung stehen, welche Microgateway-Instanz die Anfrage bearbeitet.
- Time-to-Market: Microgateways erzwingen die Authentifizierung, bevor der Zugriff auf den Dienst erlaubt wird. Das beseitigt die Notwendigkeit, diese Funktionen in jeden einzelnen Dienst einzuarbeiten. Da diese kritischen Sicherheitsaufgaben von der standardisierten Infrastrukturkomponente übernommen werden, können die Entwickler mehr Zeit in Business-Features investieren.
- Maßgeschneiderte Sicherheit: Microgateways haben einen sehr geringen Ressourcenverbrauch, sodass Entwickler sie während des gesamten Entwicklungsprozesses verwenden können. Dies stellt sicher, dass der Dienst gut mit dem Microgateway funktioniert und ermöglicht es den Entwicklern, Filterregeln für optimale Sicherheit zu konfigurieren. Integrationsschwierigkeiten und Sicherheitsprobleme werden viel früher im Entwicklungszyklus erkannt, lange bevor der Dienst live geht.
Microgateways sind somit ein wichtiges Werkzeug, um den Weg der DevOps-Teams bei der Umsetzung von Zero-Trust-Architekturen zu unterstützen und so zu DevSecOps-Teams zu werden.
Blognews direkt in Ihr Postfach
Der Airlock Newsletter informiert Sie laufend über neue Blogartikel.