Warum Architecture Drift ein Problem für DevSecOps ist Architecture Drift – Was das ist und wie es zu Sicherheitsverletzungen führt

Anbieter zum Thema

CrowdStrike GmbH c/o Citco Deutschland GmbH

SEPPmail - Deutschland GmbH

Jede Änderung in einem digitalen Ökosystem kann eine neue potenzielle Schwachstelle darstellen, die von einem Angreifer schnell entdeckt und ausgenutzt werden kann. Angesichts des raschen Fortschritts bei der technologischen Innovation und der Entwicklung der Infrastruktur von Unternehmen kann sich diese Schwachstelle in Form eines „Architecture Drift“ zeigen.

Mit der zunehmenden Verbreitung von Continuous Integration and Continuous Delivery (CI/CD) und Infrastructure-as-Code (IaC) ändern sich Anwendungen, Cluster und Umgebungen in Unternehmen ständig. Ein Architecture Drift tritt auf, wenn eine Anwendung, ein Microservice oder eine Infrastruktur über die geplante Konfiguration oder die genehmigten Betriebsgrenzen hinaus „driftet“.

Ein solcher Drift ist schwer zu erkennen und stellt ein Risiko dar, das oft erst erkannt oder gemanagt wird, wenn ein schwerwiegendes Ereignis wie ein Ausfall, ein Vorfall oder eine Sicherheitsverletzung eintritt. Eine solcher Drift kann an verschiedenen Stellen auftreten, z. B:

• Infrastruktur

• Netzwerk

• Container-Orchestrierung

• Anwendungslaufzeit

• Geschäftslogik

• Datenstrom

Architecture Drift kann sich auf die Infrastruktur auswirken, z.B. wenn IaC-Skripte wie Terraform oder CloudFormation nicht mehr mit dem synchronisiert sind, was in den Umgebungen läuft. Beispielsweise könnte ein Entwicklungsteam ein CloudFormation-Skript verwenden, um eine neue Umgebung bereitzustellen, die angibt, dass alle EC2-Instanzen „t2.small“ sein sollen. In der Zwischenzeit beschließt ein Ingenieur, manuell eine „c4.large“-Instanz zu derselben Umgebung hinzuzufügen. Da C4-Computing-Instanzen wesentlich teurer sind als T2-Instanzen, erhöht diese Änderung die Cloud-Kosten des Unternehmens und kann zu Zuverlässigkeits- und Leistungsproblemen führen.

Auch Geschäftslogik und Datenflüsse können „driften“

Kontinuierliche Entwicklung bedeutet, dass sich Code, Geschäftslogik, Datenströme und Anwendungsarchitektur in ihrer Umgebung stündlich ändern können. Je nach Automatisierungsgrad und Vorgaben in den CI/CD-Pipelines können Entwickler Code-Änderungen auf Abruf bereitstellen oder sie müssen einen Review-Prozess durchlaufen, wenn eine Änderung signifikant ist. Diese Codeänderungen können dazu führen, dass Assets auseinander driften, möglicherweise miteinander interagieren und neue Risiken entstehen. Eine einzige Code-Änderung kann zu neuen...

• Services,

• APIs,

• Abhängigkeiten,

• Bibliotheken,

• Drittanbieteraufrufen,

• Verbindungen zu Datenspeichern oder Datenbanken,

• Datenströmen,

• und weiteren Risiken, an die vielleicht noch nicht gedacht wurde, führen.

Selbst kleinste Änderungen können große Auswirkungen haben. So führte beispielsweise vor einigen Jahren eine kleine Codeänderung in einem Unternehmen zu einer Gefährdung personenbezogener Daten. Der Grund dafür war, dass der Ingenieur, der die betreffende Codeänderung vorgenommen hatte, nicht wusste, dass sein Code personenbezogene Daten enthielt, und dies auch nicht in seinem Fragebogen zur Änderungsanfrage angegeben hatte. Infolgedessen driftete der Code ab und kam mit Daten in Berührung, mit denen er nicht hätte in Berührung kommen dürfen. Dies führte zu einer unbeabsichtigten Offenlegung der sensiblen Daten.

Bei den Kunden von Bionic, einem Unternehmen von CrowdStrike, können häufig Drifts beobachtet werden. In den meisten Fällen hängen diese mit der Geschäftslogik, der Architektur und den Datenströmen zusammen. Natürlich können nicht alle Risiken in Anwendungen oder im Unternehmen beseitigt werden, aber es ist wichtig, über das Bekannte hinauszugehen und anders darüber nachzudenken, was das Unternehmen beeinflussen könnte.

Anwendungen sind komplexe Gebilde mit Hunderten oder Tausenden von Komponenten und Abhängigkeiten. Jede Code-Änderung birgt ein potenzielles Risiko. Die Frage ist nur: Ist man sich dieser Risiken bewusst und sind deren möglichen Auswirkungen bekannt?

Wie kann man Architecture Drift erkennen?

Application Security Posture Management (ASPM) erkennt und verwaltet Anwendungsabweichungen in Echtzeit. ASPM ermöglicht es Teams, ihre Anwendungsarchitekturen schnell zu erfassen und zu sichern, um über Richtlinien zu verfügen, die sie in Echtzeit benachrichtigen, wenn sich eine Architektur ändert. ASPM kann beispielsweise neue Services, APIs, neue Bibliotheken, Ports, Verbindungen, Abhängigkeiten oder sogar Datenflüsse erkennen, die eine Anwendung nach CI/CD-Implementierungen oder Codeänderungen aufweisen könnte.

ASPM markiert diese Abweichungen und liefert den vollständigen Geschäfts- und Anwendungskontext, sodass Teams die Wichtigkeit kritischer Dienste oder Datenströme, die betroffen sind, priorisieren können. Es kann auch visualisieren, wo jede Abweichung auftritt, so dass Teams das Gesamtbild sehen und Abweichungen erkennen können, bevor sie zu einem Problem werden.

Über den Autor: Jacob Garrison ist Technical Marketing Manager bei CrowdStrike.

(ID:50038824)