Agile und sichere Software-Entwicklung in sensiblen Bereichen

Agile Software-Entwicklung wird seit Jahren erfolgreich in den unterschiedlichsten Bereichen umgesetzt. Oft wird die Transformation in Richtung Agile durch junge Kolleginnen und Kollegen vorangetrieben, für die der Umgang mit Cloud, Innovation und Agilität selbstverständlich ist.

Betrachtet man jedoch besonders geschützte Bereiche, dann nimmt die Verfügbarkeit solcher Mitarbeitenden eher ab. Nicht jeder Entwickler ist willens oder in der Lage, eine entsprechende Sicherheitsüberprüfung, Freigabe und gegebenenfalls damit einhergehende Beschränkungen für sich zu akzeptieren. Gleichfalls ist der Bedarf an Innovation und Transformation in sensiblen Bereichen wie Sicherheit, Hoheitsaufgaben, Energieversorgung und Verteidigung immens.

Diesen Spagat lösen wir bei Capgemini mit dem Konzept der "Secure Software Factory". Das Konzept wurde im Rahmen von Digitalisierungsprojekten in sicherheitskritischen Bereichen entwickelt und weiter verfeinert. Es basiert daher auf realen Anforderungen und Erfahrungen. In diesem Blog soll ein kurzer Überblick über die wesentlichen Aspekte gegeben werden:

Bild: Entkopplung von Entwicklung und Betrieb (Quelle: Capgemini)

Das Konzept arbeitet nach dem Prinzip "DEV Low / RUN High" – was nichts anderes bedeutet, als dass Software in wenig bis gar nicht reglementierten Bereichen entwickelt und dann einem Secure Operations Team zum Betrieb in abgeschotteten Bereichen übergeben wird.

Das klingt zunächst naheliegend, doch der Teufel steckt im Detail. Der Vorteil von "DEV Low" liegt in der einfachen Nutzung agiler Werkzeuge und Innovationen auf Basis von Public-Cloud-Infrastrukturen. Dies beschleunigt die Entwicklung und senkt gleichzeitig die Kosten. Das Ergebnis sind stark verkürzte Release-Zyklen, wodurch die Qualität und Innovation der gesamten Umgebung gesteigert werden kann.
 

Allerdings können Software und Daten nicht einfach so in eine höhere Datenklassifizierung übertragen werden. Dazu muss ein entsprechendes Gateway eingerichtet werden, um die notwendigen technischen und organisatorischen Maßnahmen zur Sicherstellung des Datenschutzes umzusetzen. Dies lässt sich in der Regel relativ schnell realisieren.

Wenn jedoch ein Fehler in der Software gefunden wird, dann muss dieser Fehler aus einer restriktiven oder sogar isolierten Sicherheitsumgebung in eine geringere Schutzklasse überführt werden, damit Entwickler den Fehler nachstellen und beheben können. Je höher die Schutzklassen werden, desto komplexer wird dieser Prozess und kann damit die Geschwindigkeit für das Fixen von Bugs stark verlangsamen – und das in sicherheitskritischen Umgebungen.

Bild: Staging-Prozess zur Anpassung der Sicherheitsklassifizierung je nach Umgebung (Quelle: Capgemini)

Eine starke Automatisierung ist daher sehr wünschenswert und wird mit der Secure Software Factory auf Red Hat OpenShift umgesetzt.

Der Einsatz von Red Hat OpenShift:

Red Hat OpenShift bietet eine Reihe von Funktionen, die in diesem Umfeld genutzt werden. Einige wesentliche Elemente und Ideen sind:

Wie kann der Code in eine niedrigere Umgebung verschoben werden?

Verteilen Sie keinen Quellcode oder versuchen Sie nicht, Git-Patch-Dateien über das Gateway zu versenden, sondern stellen Sie fertige binäre Artefakte bereit, für die eine Sicherheitsbescheinigung der Software-Lieferkette ausgestellt werden kann (zum Beispiel signierte SBOMs gemäß SLSA Lv3 / https://slsa.dev/). Bei den Artefakten kann es sich um Bibliotheken handeln (man denke an das Open-Source-Produktmodell), die mit anderen Bibliotheken kombiniert werden, um eine einsatzfähige Anwendung zu erstellen, oder es kann sich um vollständige Anwendungen handeln, die im Ist-Zustand bereitgestellt werden können. Aber wie lässt sich die Portabilität einer Anwendung maximieren?

Containerisierung maximiert Portabilität

Wir nutzen Container ein, um die fertige Anwendung überall einsetzen zu können. Wir verwenden SLSA-Bescheinigungen und signierte Container, um die Ausführung von Applikationen zu kontrollieren. Container bringen auch zusätzliche Vorteile mit sich: Sie fördern Microservice-Side-Units, die sich einfacher und schneller ändern lassen, sie fördern einen Repave-Ansatz für Operationen (das heißt Beenden nach Belieben, Neustart von Scratch) und sie lassen sich leicht auf Sicherheitslücken untersuchen. Aber Container brauchen eine Container-Plattform...

Warum Red Hat OpenShift?

Red Hat OpenShift wird genutzt, um die Container zu hosten und eine voll funktionsfähige, sichere CI/CD-Pipeline bereitzustellen, die den oben genannten SBOM- und SLSA-Lv3-Anforderungen entspricht. Red Hat OpenShift kann problemlos bei jedem Cloud-Anbieter betrieben werden und kann für hohe Sicherheitsanforderungen auch vollständig getrennt oder isoliert betrieben werden.

Red Hat OpenShift ist die ausgereifteste und umfassendste Container-Plattform auf dem Markt, ergänzt durch ein starkes Ökosystem, das die Bedürfnisse von Unternehmen und der Verteidigung versteht, insbesondere die Sicherheitskontrollen, die für höhere Sicherheitsanforderungen (RUN High) relevant sind.

Die Ergebnisse der Secure Software Factory können sich sehen lassen:

Bild: Projektergebnisse in sicherheitskritischen Umgebungen (Quelle: Capgemini)

Weitere Informationen gibt es unter: https://www.capgemini.com/gb-en/industries/public-sector/