bluebay2014 - stock.adobe.com

Infrastructure as Code: Vor- und Nachteile im Überblick

IaC gewinnt immer mehr Anhänger, da sich damit neue Workloads in einem automatisierten Prozess einheitlich und sicher ausspielen lassen. Eine Abschätzung der Vor- und Nachteile.

Es ist immer wieder faszinierend, genau zu analysieren, wie sich das gefühlte und das echte Risiko durch die Einführung neuer Technologien und Prozesse in einem Unternehmen verändern. Sicherheitsexperten wissen, dass die meisten Techniken das Risiko für eine Organisation nicht nur in eine Richtung steuern.

So ist es durchaus möglich, dass sich durch die Einführung einer neuen Sicherheitstechnologie komplett neue Risiken ergeben, während damit schon länger bekannte Gefahren bekämpft werden. Ebenso kann es sein, dass sie das Risiko für manche Unternehmen senken, während sie es für andere erhöhen.

Es ist daher sehr viel Erfahrung und Wissen nötig, um diese Veränderungen rechtzeitig erkennen und einschätzen zu können. Die Fähigkeit, eine solche optimale Balance beim Verringern von Risiken zu finden und gleichzeitig für minimale neue Gefahren zu sorgen, unterscheidet nur durchschnittliche Sicherheitsexperten von den wirklich großartigen Kollegen.

Infrastructure as Code oder abgekürzt IaC ist ein noch relativ junger Ansatz, der genau diesem Muster folgt. Mit IaC ist es möglich, bestehende Risiken zu senken und gleichzeitig neue Gefahren zu minimieren. IaC kann jedoch auch für neue Risiken in Unternehmen sorgen, wenn es schlampig und ohne ein besonderes Augenmerk auf das Thema IT-Security eingeführt wird. Sobald aber die IT-Sicherheit im Fokus der Bemühungen steht, dann ist Infrastructure as Code eine der derzeit besten Maßnahmen, die Sie ergreifen können, um aktuelle und künftige Cyberbedrohungen im operativen Betrieb zu verringern.

Zunächst sollten Sie allerdings verstehen, was IaC genau ist, und sich erst danach damit beschäftigen, welche Auswirkungen die Technik auf Ihre IT-Security-Bestrebungen hat.

Was verbirgt sich hinter Infrastructure as Code?

In der Vergangenheit hatten Unternehmen physische Rechenzentren und IT-Infrastrukturen, die vor allem aus Hardware bestanden. Heutzutage setzen die meisten Firmen keine eigene Hardware mehr ein, sondern verwenden vor allem virtuelle Deployments, Workloads aus der Cloud sowie Container.

Das Einrichten eines neuen OS-Images in einer solchen Umgebung kann prinzipiell auf zweierlei Arten erfolgen. Zunächst gibt es den altbekannten Weg, bei dem ein Image erst installiert und danach individuell konfiguriert wird. Das Erstellen von 1.000 oder 50.000 dieser Systeme ist jedoch eine enorme Herausforderung, die in den meisten Firmen viele Monate dauern dürfte.

Der zweite, deutlich leichter durchzuführende Weg basiert auf einer im Vorfeld angelegten Definition, die genau festlegt, was benötigt wird. Dafür gibt es mittlerweile zahlreiche Werkzeuge, die die wichtigsten Aufgaben bei der Erstellung von virtuellen Maschinen (VMs) übernehmen, die das Betriebssystem dann installieren und das Image zuletzt auch ausspielen.

Dabei legen Firmen eine Konfigurationsdatei oder ein Skript an, das sämtliche gewünschten Einstellungen enthält. Diese Daten können dann genutzt werden, um immer wieder genau das Image zu erhalten, das darin festgelegt wurde. Dieser zweite Prozess ist genau das, was den Kern von Infrastructure as Code ausmacht.

Abbildung 1: Die Kernelemente von Infrastructure as Code machen das Konzept so populär.
Abbildung 1: Die Kernelemente von Infrastructure as Code machen das Konzept so populär.


Die Vorteile von Infrastructure as Code

IaC ist auch deswegen so überzeugend, da die gewünschte Konfiguration in nur einer einzigen Datei festgeschrieben wird. Auf diese Weise wird Infrastructure as Code selbst zu einer reinen Softwareangelegenheit. Die Konfigurationsdatei kann zum Beispiel mit anderen Personen oder Abteilungen geteilt und je nach Bedarf auch später noch aktualisiert und angepasst werden. Die Datei kann sogar in eine Versionsverwaltung integriert werden, um dauerhaft die Kontrolle über alle jemals erfolgten Änderungen zu behalten.

Darüber hinaus hilft IaC den Unternehmen dabei, die teilweise nur marginalen Unterschiede zwischen verschiedenen Workload-Konfigurationen zu minimieren. Gelegentlich spricht man davon, dass Server nach einer gewissen Zeit eine eigene „Persönlichkeit“ entwickeln, die sozusagen auf dem zugrundeliegenden Betriebssystem basiert und die sich immer weiter entwickelt, wenn etwa die Konfiguration angepasst oder neue Software installiert wird.

IaC ermöglicht es dagegen, dass ein IT-Team in kürzester Zeit neue, immer in sich konsistente Workloads erstellt, aufsetzt und ausspielt. Außerdem arbeitet Infrastructure as Code sehr gut mit DevOps zusammen, da sich das Konzept sehr leicht in die dort genutzten automatisierte Bereitstellung integrieren lässt.

Wie sich Infrastructure as Code auf die Sicherheit auswirkt

Wenn man verstanden hat, was IaC ist und wie die essentiellen Vorteile aussehen, ist es wichtig, sich auf die Auswirkungen des Konzepts auf die IT-Security und etwaige neue Risiken zu konzentrieren, die daraus resultieren. So können die IT-Sicherheitsexperten im Unternehmen die Gefahren besser einschätzen, die sich aus Infrastructure as Code ergeben.

Besonders wichtig ist es dabei, sich mit dem Thema IaC auf einer breiten Basis zu beschäftigen, weil es zahllose Tools gibt, die das Konzept unterstützen. Dazu gehören etwa Werkzeuge zum Provisioning wie Terraform, Orchestration-Tools wie AWS CloudFormation oder den Azure Resource Manager, Konfigurationsmanagement-Tools wie Chef und Puppet, Automatisierung-Tools wie Ansible und Container-fokussierte Anwendungen wie Docker.

Letzteres setzt auf die Auszeichnungssprache YAML, um Konfigurationen festzulegen. Die individuellen Besonderheiten dieser verschiedenen Lösungen, die IaC unterstützen, sind allerdings ein komplexes Thema.

Das Fokussieren auf anspruchsvolle IaC-Konzepte lässt noch viele Spielräume. Im Folgenden finden Sie drei positive Auswirkungen von Infrastructure as Code auf die IT-Sicherheit, die in die Planungen mit einbezogen werden sollten:

1. Sorgt für einheitliche Konfigurationen

Einer der aus Sicherheitssicht größten Vorteile von IaC ist die Fähigkeit, für einheitliche Konfigurationen zu sorgen, die für alle eingesetzten Workloads gelten. Weil sie über alle Workloads genutzt werden, unterstützen die Konfigurationen die Ziele eines Unternehmens aus Security-Sicht am besten. Da die dabei verwendeten Prozesse zudem automatisch ablaufen, kann man sie als vertrauenswürdig einstufen und davon ausgehen, dass alle gewünschten Einstellungen auch wirklich durchgeführt wurden.

Auf der anderen Seite sorgt diese Eigenheit von IaC für ein nicht zu vernachlässigendes Risiko. So kann sich ein Fehler in der Konfiguration schnell über die gesamte Infrastruktur ausbreiten. Genauso wie es Bugs in Software gibt, können natürlich auch Fehler beim Festlegen der gewünschten Konfiguration auftreten. Um dies zu vermeiden, müssen die Security-Teams dafür sorgen, dass alle notwendigen Schritte unternommen werden, um die Konfigurationen zu härten und um Probleme frühzeitig zu finden.

Automatisierte Scanning-Tools eignen sich sehr gut dazu, um potentielle Fehlkonfigurationen oder andere Schwachstellen so schnell wie möglich aufzuspüren. Anschließend kann die Konfiguration sofort angepasst werden.

2. Reduziert menschliche Fehler durch Automatisierung

Ein weiterer Vorteil von IaC aus Security-Sicht ist, dass dabei deutlich weniger menschliche Fehler auftreten. Allzu häufig sind sie der Grund für Fehlkonfigurationen und andere Sicherheitsprobleme. Da das Deployment bei Infrastructure as Code automatisch und ohne Einwirkung von Menschen erfolgt, gibt es weniger Möglichkeiten für einzelne Administratoren, individuelle Änderungen an der Konfiguration vorzunehmen, die dann versehentlich für Sicherheitslücken sorgen.

Ein Nachteil der Automatisierung ist jedoch, dass es dadurch zu einer Art „Zerfaserung“ kommen kann. Wie viele Sicherheitsexperten bestätigen können, kommt es auch in der Cloud zu solchen Entwicklungen, wenn Workloads ohne ein Konzept für ihre spätere Löschung eingerichtet werden.

Ein automatisiertes Vorgehen beim Deployment bedeutet, dass es später auch leichter zu nicht mehr benötigten Instanzen kommt. Um dies zu vermeiden, sollten Sie regelmäßige Inventarisierungsmaßnahmen durchführen sowie Tagging nutzen. Diese Maßnahmen können übrigens ebenfalls automatisiert werden.

3. Verringert den Bedarf an privilegierten Accounts

Ein weiterer nicht zu vernachlässigender Vorteil von Infrastructure as Code ist, dass dadurch der Bedarf an Einzelpersonen mit erweiterten Berechtigungen erheblich reduziert wird. Da sowohl die Konfiguration als auch das Deployment automatisiert erfolgen, wird nur noch selten ein Eingriff durch einen menschlichen Administrator benötigt, um etwa eine Ressource erstmals zu aktivieren.

Unter manchen Umständen und meist völlig unerwartet gelangen aber immer wieder auch vertrauliche Daten wie API Keys, Zugangsdaten zu privilegierten Konten oder kryptographische Schlüssel in produktiv genutzte Umgebungen. Also an Stellen, an denen sie in der Regel nichts verloren haben. Deswegen sollten regelmäßig Tests durchgeführt werden, um zum Beispiel nicht benötigte Admin-Accounts aufzuspüren und um sicherzustellen, dass keine vertraulichen Daten versehentlich vorhanden sind.

Wie auch in anderen Bereichen hängen die Auswirkungen des Einsatzes von Infrastructure as Code davon ab, wie das Konzept in der Praxis umgesetzt wird. Entweder stärkt es die IT-Security-Bestrebungen eines Unternehmens oder es unterminiert sie. Die große Herausforderung für die Sicherheitsexperten in einem Betrieb ist deshalb, die Vorteile zu maximieren, während die Nachteile reduziert werden. Das erfordert ein profundes Verständnis der richtigen Balance. Genau dies ist der erste Schritt auf dem Weg, IaC als wertvolle Unterstützung bei der Absicherung einer modernen IT-Umgebung zu nutzen.

Erfahren Sie mehr über Anwendungs- und Plattformsicherheit

ComputerWeekly.de
Close