Software im Unternehmen wie Steckbausteine zusammensetzen Composable Architecture – das Beste aus zwei Welten

Ein Gastbeitrag von Boris Cipot * Lesedauer: 6 min |

Anbieter zum Thema

Composable Architecture setzt auf Standardanwendungen, die sich über offene Schnittstellen flexibel erweitern lassen, um neue Use Cases dynamisch zu integrieren. Dank Standards erhalten Unternehmen ein starkes Fundament, bei gleichzeitig maximaler Flexibilität durch offene Schnittstellen.

Anstelle eines riesigen, monolithischen Blocks gibt es bei Composable Architecture verschiedene Bauteile, die wie Klemmbausteine miteinander interagieren.
Anstelle eines riesigen, monolithischen Blocks gibt es bei Composable Architecture verschiedene Bauteile, die wie Klemmbausteine miteinander interagieren.

Composable Architecture bringt viele Vorteile. Wir wollen in diesem Beitrag häufig gestellte Fragen in Bezug auf diese Art der Software-Entwicklung beantworten. Einfach ausgedrückt soll Composable Architecture dabei helfen, dass Unternehmen einerseits auf die umfassende Stabilität einer Standard-Software als Basis setzen. Auf der anderen Seite soll diese Software über Schnittstellen so offen wie möglich sein, um eigene Use Cases zu integrieren und die Lösung mit Komponenten zu erweitern.

Composable Architecture findet sich als Design-Konzept in immer mehr Umgebungen. Auch Infrastrukturen mit Microservices und API-gestützte Umgebungen gehen nach diesem Prinzip vor. Anstatt eines riesigen, monolithischen Blocks, gibt es verschiedene Bauteile einer Lösung, die wie Klemmbausteine miteinander interagieren.

Developer erhalten dabei mehr Eigenverantwortung für die Komponenten, die sie entwickeln. Im Idealfall führt das zu mehr Sicherheit, Stabilität und Leistungsfähigkeit. Dabei ist das Konzept an sich nicht neu. Auch Object Oriented Programming macht sich die Idee von kleineren, austauschbaren Komponenten zunutze, die über sogenannte Interfaces angesprochen werden.

Aber selbst, wenn bei der Entwicklung von Quellcode bewährte Verfahren angewendet werden, steht am Ende infrastrukturseitig eine monolithische Produktarchitektur. Heutzutage spricht einiges für Composable Architecture, auch aus Gründen der Skalierungsfähigkeit für einzelne Bestandteile eines Services statt des kompletten Backend. Es gibt allerdings einiges zu beachten.

Wie sicher sind Composable-Architecture-Umgebungen?

Da bei Composable Architecture der Technologie-Stack oder die Geschäftsanwendungen auf Komponenten aufbaut, ist zunächst wichtig, dass jede einzelne Komponente so sicher wie nur möglich ist. Jedes Bauteil sollte nach Best Practices im Rahmen der maximalen Möglichkeiten designt sein. Das erhöht gleichzeitig die Sicherheit der kompletten Lösung und ist ein wichtiger Faktor, um die einzelnen Komponenten zu schützen.

Hinzu kommt die Möglichkeit, Aufgaben zwischen den Komponenten zu delegieren. Auch hier sollte gewährleistet sein, dass Kommunikation und Ablauf der Prozesse so intelligent gelöst sind, dass die Sicherheit auf einem maximalen Stand ist. Die zwischen den Komponenten ablaufenden Prozesse sollten ebenfalls optimal definiert sein, damit zwischen den Teilen der Software nicht versehentlich Interaktionen ablaufen, die nicht beabsichtigt sind.

Bei der Implementation kommt es darauf an, dass die Software nicht nur aus einem Basis-Teil besteht, sondern aus mehreren Bereichen. Innerhalb der Sicherheits-Strategie des Unternehmens müssen sie sowohl getrennt als auch im Zusammenspiel Berücksichtigung finden.

Entstehen durch das Verbinden von Komponenten Sicherheitslücken?

Der Vorteil bei der Composable Architecture ist, dass die unterschiedlichen Komponenten sehr viel leichter überschaubar und abzusichern sind. Entwickler kennen die einzelnen Bestandteile sehr gut und können so bei der Absicherung optimal mitwirken. Das verringert die Wahrscheinlichkeit von Lücken deutlich, weil keine riesigen Code-Sammlungen entstehen, die einzelne Entwickler kaum mehr durchschauen.

Im Fokus der Composable Architecture steht der API-first-Ansatz. Das heißt, dass sich einzelne Komponenten leicht ersetzen lassen, wenn sie die verwendete API richtig nutzen. Tauchen Sicherheitslücken in einer Komponente auf, kann diese einzelne Komponente leicht ersetzt oder abgesichert werden.

Entwickler sollten die APIs in solchen Architekturen unbedingt so planen, dass Sicherheit und optimale Authentifizierung berücksichtigt werden. Das gilt auch für eine richtig gesteuerte Berechtigungsstruktur. Gelingt es einem Angreifer eine Komponente zu kompromittieren, müssen die anderen Komponenten dennoch geschützt bleiben. Mit der richtigen Planung liegt darin eine der großen Stärken der Composable Architecture.

Was macht Composable Architecture besser als Monolithen?

Composable Architecture fördert die Eigenverantwortung der Entwickler. Es handelt sich dabei nicht nur um das Vermischen von Code oder die Integration kostengünstiger Open-Source-Bestandteile. Die einzelnen Komponenten in der Composable Architecture liegen in der Verantwortung des jeweiligen Entwicklers. Dieser muss dafür sorgen, dass „seine“ Komponenten stabil, leistungsstark und sicher sind. Das bedeutet aber nicht, dass Sicherheit hier ein Selbstläufer ist.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Softwareentwicklung und DevOps

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Generell macht Composable Architecture Schluss mit dem Ansatz „Das ist nicht mein Problem, darum müssen sich andere kümmern“. Die Komponente ist in der Verantwortung des jeweiligen Entwicklers und die Sicherheit der Komponente ist eine seiner Aufgaben

Übernehmen Entwickler in einer Composable Architecture mehrere Komponenten, fällt es bei kleineren Bausteinen deutlich leichter, den Überblick behalten. Anders als bei sehr großen Code-Blöcken. Dadurch steigt aber nicht automatisch der Sicherheitslevel. Auch hier sollten Entwickler Best Practices bei der Sicherheitsplanung beachten.

Das kann ein großer Vorteil sein, denn die Funktionen innerhalb einer Komponente lassen sich relativ einfach verstehen. Gleichzeitig steigt die Zahl von Schnittstellen zwischen den Komponenten. Das wiederum erhöht das Risiko von Schwachstellen, die in diesen Komponenten auftreten. Ein besonderes Augenmerk sollte deshalb unbedingt auf der Sicherheit dieser Schnittstellen liegen.

Vereinfacht Composable Architecture die Anwendungen und Technologie-Stacks?

Meistens nutzen Firmen Composable Architecture, weil den vorhandenen Anwendungen Funktionen fehlen, die für bestimmte Use Cases notwendig sind. Beim Ansatz der Composable Architecture lassen sich diese neuen Funktionen einfacher integrieren, ohne die existierenden Systeme komplett ersetzen zu müssen.

Wenn in etablierten Systemen Sicherheitsmängel auftreten, kann es sinnvoll sein, einzelne Komponenten nacheinander herauszulösen und über eine Composable Architecture gegen neue, bessere und sichere „Module“ zu ersetzen.

Das Gleiche gilt für die Wartung. Sind die Kosten bei großen Lösungen zu hoch, lässt sich der Aufwand durch die Implementierung neuer und getrennter Komponenten reduzieren. Allerdings dürfen Verantwortliche nicht außer Acht zu lassen, dass sich durch weitere Schnittstellen und Komponenten die Angriffsfläche der Umgebung verbreitert.

Bedeutet Composabale Architecture das Ende monolithischer Anwendungen?

In vielen Fällen kann man monolithische Anwendungen nicht ersetzen. Das ist zu komplex, teuer und ineffizient. Es gibt aber durchaus Möglichkeiten, wie man monolithische Anwendungen erweitern und damit modernisieren kann. Hier funktioniert Composable Architecture eher als Partner denn als Gegenspieler von monolithischen Anwendungen. Schlussendlich lassen sich damit Geschäftsanwendungen erweitern, ohne den Produktionsablauf zu stören.

Welche Komponenten sind in einer Composable Architecture gefährdet?

Generell sollte jede Komponente besonders geschützt werden. Gelingt es einem Angreifer dann, eine dieser Komponenten zu kompromittieren, lassen sich die übrigen mit der richtigen Planung trotzdem absichern. Wichtig sind in diesem Fall auch die Interaktionen zwischen den Bestandteilen der Composable Architecture. Sie müssen in einem umfassenden Authentifizierungs- und Berechtigungsmodell so sicher wie möglich ablaufen.

Die Kommunikation sollte man zusätzlich auf die Komponenten beschränken, die wegen der Funktionsfähigkeit der Umgebung miteinander kommunizieren „müssen“. Sollte dennoch eine Komponente kompromittiert werden, sollte die übrige Umgebung weiterhin so sicher wie nur möglich sein. Die Verantwortlichen sollten die Umgebung regelmäßig testen, um zu überprüfen, wie widerstandsfähig sie ist.

Wie wird die Sicherheit von Composable Architecture in Zukunft aussehen?

Die Eigenverantwortung der jeweiligen Entwickler wird weiter steigen. Sie zeichnen verantwortlich dafür, dass die Sicherheit jeder einzelnen Komponente so hoch wie möglich ist. Sicherheitsexperten kümmern sich ihrerseits um die komplette Umgebung. Sie behalten den Überblick über sämtliche Komponenten und deren Interaktionen.

Boris Cipot
Boris Cipot
(Bild: Synopsys)

Von den Erfahrungen der Sicherheitsfachleute profitieren wiederum die Entwickler. Genau darin liegt die große Stärke der Composable Architecture: Das eigenverantwortliche Arbeiten der Entwickler führt zu höherer Sicherheit bei den Komponenten und dadurch zu sicheren Infrastrukturen. Komponenten arbeiten effektiv miteinander. Sie sind aber so weit voneinander abgeschottet, dass ein kompromittierter Bereich nicht unweigerlich zur Kompromittierung der ganzen Umgebung führt.

* Boris Cipot ist Senior Sales Engineer bei der Synopsys Software Integrity Group.

(ID:49410386)