Sicherheitsproblematik quelloffener Software
Open Source als Risiko im RZ
Open-Source-Software hat für Entwicklungsteams große Bedeutung - von der OS-Ebene bis zur Containertechnik. Deshalb müssen Entwickler und Entscheider ihr Augenmerk darauf legen, wie sich die Allgegenwart des quelloffenen Codes auf die RZ-Betriebssicherheit auswirkt. Vor dem Hintergrund regulatorischer Gegebenheiten müssen sie das Thema Open-Source-Sicherheit in Bereichen angehen, die von Abwehrmaßnahmen am Perimeter bis zu internen Audits reichen.
Viele RZ-Betreiber nutzen Open Source, von den diversen Linux-Varianten bis zu Virtualisierungslösungen wie KVM oder Xen, zudem ist die Softwarearchitektur vieler Cloud-Rechenzentren mittels Linux-Containern virtualisiert. Auch Netzwerkgeräte laufen häufig auf Open-Source-Technik, ebenso Firewalls, Proxy-Server, Intrusion-Detection-Systeme und SDN-Infrastrukturen (Software-Defined Network).
Open-Source-Entwickler erschaffen Projekte oft, um ein bestimmtes Problem zu lösen. Deckt eine Lösung, die "gut genug" ist, ihre unmittelbaren Bedürfnisse ab, dann veröffentlichen sie deren Quellcode, sofern erforderlich. Denn eine Open-Source-Lizenz beinhaltet bestimmte Rechte und Pflichten: Eine "permissive" Lizenz bedeutet, dass es keine Verpflichtung gibt, sich daraus abgeleitete Arbeit zu teilen, während eine "reziproke" Lizenz erfordert, dass daraus entwickelter Code geteilt wird. Unternehmen, die Code unter reziproker Lizenz übernehmen, müssen ihre Anpassungen also an die Community weitergeben. Zwar existieren kommerzielle Anbieter von Open-Source-Software wie Red Hat und Suse, doch es gibt weit mehr Open-Source-Projekte als kommerzielle Lösungen. Eine Open-Source-Softwarelösung zu implementieren, kann schlicht daraus bestehen, ein Paket herunterzuladen, das den Großteil der Anforderungen erfüllt, und es einzusetzen. Die Entwickler erstellen dann per Zugriff auf den Quellcode die fehlenden Komponenten.
Das Kernprojekt muss über eine reziproke Lizenz eingereichte Erweiterungen jedoch nicht akzeptieren, wodurch ein Projektzweig (Fork) entsteht, der jener Person gehört, die die Erweiterungen einreicht. Permissive Lizenzen wiederum können zu einem internen Zweig führen. Jeder Projektzweig stellt einen nebenläufigen Entwicklungsstrang dar.
Verzweigter Softwarebestand
Unternehmenssoftware, die Open-Source-Komponenten beinhaltet, enthält somit häufig beabsichtigt und unbeabsichtigt Forks. Beabsichtigte Abspaltungen treten auf wie oben beschrieben, unbeabsichtigte geschehen, wenn eine Komponente in ein System eingebettet wird, während die Entwicklung für die ursprüngliche Komponente weiterläuft. Dadurch weicht die eingebettete Version möglicherweise von der Entwicklung der ursprünglichen Komponente ab. Der Nutzer trägt dann die Verantwortung für die Pflege jeder Softwarekomponente, die er abgespalten hat.
Diese Verantwortung ist von zentraler Bedeutung für das Management Open-Source-basierter Systeme im RZ. Unabhängig davon, ob ein Lieferant Software, Firmware oder Appliances bereitstellt, ist es entscheidend, das Ausgelieferte detailliert zu kennen, um die damit einhergehenden Risiken zu bewerten. Denn sollte es zu einem Sicherheitsvorfall kommen, besteht das Risiko eines Verstoßes gegen Regularien. Eine Stückliste, die die Open-Source-Komponenten im Lieferumfang beschreibt, hilft dem RZ-Betreiber, Risiken aus Sicherheitslücken sowie Lizenzrisiken zu reduzieren. Wenn es sich um reziproke Lizenzen handelt, wird dies in Form des Quellcodes offengelegt. Da permissive Lizenzen für den Endverbraucher keinen Quellcode-Zugriff erfordern, sind alternative Offenlegungen gefragt, die den Open-Source-Lizenzen entsprechen. Unabhängig von der Lizenz sind diese Komponenten Software-Assets, die dem Patching und fortwährender Sicherheitsüberwachung im Kontext relevanter Regularien unterliegen.
Sicherheit von Containerumgebungen
Besondere Bedeutung erhält das Sicherheits-Management im Kontext moderner Clouds, die sich auf Containertechnik stützen. Ein Containersystem ist im Wesentlichen ein Stack von Open-Source-Software. Dieser besteht aus einem Betriebssystem (normalerweise Linux), einer Container-Runtime-Umgebung (normalerweise Docker), einem Container-Orchestrierungssystem (etwa Kubernetes, Red Hat OpenShift oder Apache Mesos) und Container-Images.
Diese Images werden aus Basis-Images erstellt, die häufig Linux-Komponenten enthalten, die mit Anwendungscode gekoppelt sind, um eine containerisierte Anwendung zu bilden. Um das mit einem bestimmten Container-Image verbundene Risiko zu verstehen, muss man das in jeder Schicht des Stacks vorhandene Risiko und die Zusammensetzung jeder Schicht innerhalb des Stacks sowie des Containers erfassen.
Die DevOps-Prinzipien kontinuierlicher Integration und Bereitstellung ermöglichen es, mit hohem Tempo Containeranwendungen zu veröffentlichen. Daher muss ein IT-Team in allen Phasen der Delivery-Pipeline Sicherheitsbewertungen durchführen. Beispielsweise sind auch während der Integrationsphase Bewertungen des Sicherheitsrisikos vorzunehmen. Kann das Team die Governance-Bestimmungen nicht erfüllen, sollte es die Bereitstellung der Anwendung ablehnen.
RZ-Teams benötigen auch automatisierte Sicherheitsaudits, die vor der Bereitstellung erfolgen, um zu bestätigen, dass die Software noch den Bestimmungen entspricht. Da ordnungsgemäß entworfene Containeranwendungen mehrere Instanzen aus einem unveränderlichen Container-Image bereitstellen, kann man die Anforderung zur kontinuierlichen Überwachung des Sicherheitsrisikos durch Beglaubigung des Container-Images erfüllen. Dies stellt sicher, dass die Überwachungsanforderungen minimalen Einfluss auf die Gesamtsystemleistung haben. Zusammen mit dem in Orchestrierungssystemen vorhandenen Wissen ermöglicht es dieses Modell, automatisch eine Folgenabschätzung für neue Sicherheitswarnungen durchzuführen.
Eine solche Folgenabschätzung ist eine kritische Komponente eines Sanierungs- oder Wiederherstellungsplans. Das Fehlen des kompletten Überblicks von bereitgestellten Anwendungen und Abhängigkeiten innerhalb des installierten Stacks führt zu einer fehleranfälligen Folgenabschätzung. Tragfähige Lösungen für dieses Problem sollten daher diese Eigenschaften haben:
- automatisches Scannen aller Container-Images, unabhängig von Quelle und Bereitstellungsmodell,
- Bereitstellen von Metadaten für die Orchestrierungslösung, damit man Implementierungsrichtlinien durchsetzen kann,
- Identifizieren von sicherheitsrelevanten Änderungen, sobald sie für bereitstellbare Images offengelegt sind,
- Aufzeichnen von Sicherheitshinweisen, wie Exploits zu begegnen ist, mit Lösungsansätzen zur Wiederherstellung, sowie
- Abstimmung auf Open-Source-Entwicklung, insbesondere in Bezug auf Abspaltungen (Forks).
Teams in Rechenzentren können kaum mit den hunderten neuer Schwachstellenmeldungen pro Woche im Open-Source-Bereich Schritt halten. Ohne ein umfassendes Verständnis der Zusammensetzung von Open-Source-Code und einer Folgenabschätzung haben es die Teams schwer, schnell genug auf Sicherheitsvorfälle zu reagieren.
Lesen Sie mehr zum Thema
