Dies ist der erste Teil meiner IaC-Übersicht basierend auf einem persönlichen Experiment: den Aufbau einer Cyber Range mit dem IaC-Paradigma. Hier sind die zweite und dritte Teile.

Während meiner Twitch-Sitzung biete ich den Teilnehmern normalerweise ein praktisches Labor an. Meine Labore werden automatisch auf AWS erstellt, indem Terraform und Ansible verwendet werden.

Szenario

Mein Szenario ist ziemlich einfach: Ich muss eine Reihe von VMs innerhalb von AWS erstellen und sie mit zusätzlicher Software und Diensten konfigurieren. Diese VMs stellen einige verwundbare Dienste bereit, die von den Teilnehmern ausgenutzt und verteidigt werden können.

Bevor ich die Twitch-Sitzung starte, starte ich manuell Terraform und Ansible, um VMs zu erstellen und zu konfigurieren. Konkret verwende ich:

• Terraform, um VMs in AWS zu erstellen;
• Terraform, um das Client-zu-Site-VPN-Gateway zu erstellen;
• OpenVPN, um eine Verbindung zur internen Seite des Labors herzustellen;
• Ansible, über OpenVPN, um VMs zu konfigurieren.

Der Aufbau dauert weniger als 10 Minuten.

Planung und Standardisierung

IaC besteht zu 80% aus Planung und Standardisierung. Das bedeutet, dass wir Anforderungen, Szenarien und Randfälle identifizieren müssen. Dann müssen wir festlegen, wie wir unsere Infrastruktur definieren (ich bezeichne diese Phase als “Modellierung”), und schließlich sollten wir Prototypen schreiben, um unsere Idee und unseren Ansatz zu überprüfen.

In meinem Fall muss ich Cyber Range-Szenarien erstellen, die mehrere VMs enthalten können:

• mit verschiedenen Betriebssystemen und Anwendungen;
• an verschiedene Netzwerke angeschlossen;
• möglicherweise durch zusätzliche Geräte (Firewalls) geschützt.

Alle VMs müssen von einem bestimmten Host aus zugänglich sein, um sie zu konfigurieren.

Letzte Anforderung: Alle Szenarien sollten vollständig von Grund auf erstellt und nach der Sitzung zerstört werden. Es werden keine dauerhaften Daten erwartet.

In meinem Fall habe ich mich entschieden:

• Ein benutzerdefiniertes Terraform-Modul zu schreiben, um die grundlegende Infrastruktur (Internetzugang, grundlegende Netzwerke, Client-zu-Site-VPN-Gateway oder Bastion-Hosts) zu erstellen;
• Die zusätzlichen Komponenten manuell zu definieren (zusätzliche VMs, Netzwerke und wie sie verbunden sind);
• Jede VM mit Rollen zu konfigurieren (mehrere Rollen können in derselben VM konfiguriert werden).

Erstellen der Infrastruktur

Das grundlegendste Szenario erfordert die Erstellung eines Bastion-Hosts und mindestens einer Ubuntu Linux-VM. Die Terraform-Dokumentation ist ziemlich erklärlich, und es gibt keine Probleme damit.

Mein einziger Vorschlag ist: Planen Sie sorgfältig, was Sie jetzt und in Kürze benötigen, und seien Sie bereit, sich anzupassen.

In meinen Fällen habe ich mich entschieden, Tags zu verwenden, um das Betriebssystem, installierte Anwendungen, Zweck und administrative Benutzer zu verfolgen… Diese Tags werden in Ansible nützlich sein.

Konfigurieren der Infrastruktur

Hier treten die Probleme auf: Terraform und Ansible sind zwei verschiedene Universen, und ich muss sie kommunizieren lassen. Bei der Verwendung von AWS und der sorgfältigen Planung meiner Infrastruktur habe ich das AWS EC2 Ansible-Inventar ziemlich gut gefunden, auch wenn es einige Einschränkungen hat.

Kurz gesagt:

• Terraform erstellt die Infrastruktur durch Anwendung von Tags;
• Das AWS EC2 Ansible-Inventar ruft die AWS EC2-Instanzen ab und bereitet ein Ansible-kompatibles Inventar vor, wobei die Tags beibehalten werden;
• Nach der Herstellung der OpenVPN-Verbindung kann Ansible interne VMs konfigurieren.

Das Ansible AWS EC2-Inventar löst alle internen VMs mit der privaten IP-Adresse auf:

plugin: aws_ec2
regions:
  - eu-central-1
filters:
  instance-state-name: running
keyed_groups:
  - key: tags
    prefix: tag
hostnames:
  - tag:Name
compose:
  ansible_host: private_ip_address

An diesem Punkt haben wir eine ausgezeichnete Möglichkeit, die Infrastruktur aufzubauen und zu konfigurieren, unabhängig davon, ob die VMs aus dem Internet erreichbar sind oder nicht. Der einzige Nebeneffekt ist, dass Client-zu-Site-VPN-Verbindungen einen großen Einfluss auf mein AWS-Konto haben.

Andere Dinge (Zertifikate)

Der oben beschriebene Ansatz erfordert den Aufbau und die Pflege einer CA (Zertifizierungsstelle):

• Der AWS-Client-zu-Site-Konzentrator erfordert ein Serverzertifikat;
• VPN-Clients benötigen das öffentliche Zertifikat der CA, um das Konzentratorzertifikat zu validieren;
• VPN-Clients benötigen ein gültiges Zertifikat, um vom VPN-Konzentrator akzeptiert zu werden;
• Der AWS-Client-zu-Site-Konzentrator benötigt das öffentliche Zertifikat der CA, um die Clientzertifikate zu validieren;
• Zusätzliche Server (z. B. Webserver) könnten gültige Zertifikate benötigen.

Auch wenn die AWS- und Terraform-Dokumentationen sehr gut sind, hat mich diese Aufgabe Stunden gekostet, um den richtigen Ansatz zu finden.

Schlussfolgerungen

Wie ich bereits erwähnt habe, besteht IaC zu 80% aus Planung und Standardisierung. Wenn es um Unternehmen geht, gibt es keinen “Standardansatz”, alles sollte um einen spezifischen Kontext herum gestaltet werden, mit besonderen Bedürfnissen. In einem realen Szenario sind viele Teams beteiligt: Betrieb (natürlich), Verbraucher (z. B. Entwickler), Audit und Compliance sowie Sicherheit… IaC erfordert einen “ganzheitlichen Ansatz”, Teams können nicht mit einem IaC-Ansatz gehen, ohne Stakeholder einzubeziehen. Alleine zu gehen bedeutet Versagen: Einschränkungen, hohe Kosten und viele nicht geplante Ausnahmen…