Zum Inhalt springen
View in the app

A better way to browse. Learn more.

Fachinformatiker.de

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Projektantrag: Konzeption und prototypische Umsetzung einer Infrastructure-as-Code-Lösung zur automatisierten und versionierten Verwaltung einer OPNsense-Firewall

Empfohlene Antworten

Guten Morgen allerseits,

nach dem mein erster Projektantrag abgelehnt wurde habe ich einen neuen erstellt.

Bevor ich ihn einreiche wollte ich mir über das Forum eine zweite Meinung einholen.

Es sind insgesamt vier Seiten geworden.

Ich will gar nicht um den heißen Brei herum reden, hier der Antrag:

Bezeichnung:

Konzeption und prototypische Umsetzung einer Infrastructure-as-Code-Lösung
zur automatisierten und versionierten Verwaltung einer OPNsense-Firewall
Beschreibung:

1. Ausgangssituation und Ist-Zustand


Das Projekt wird im eigenen IT-Dienstleistungsunternehmen mit Fokus auf Managed Services
durchgeführt. Die bestehende Firewall-Infrastruktur wird derzeit noch über eine proprietäre
Firewall-Plattform auf einer auf ESXi 8 basierten Virtualisierungsumgebung betrieben.

Die Administration der Firewall-Konfiguration erfolgt überwiegend manuell. 
Änderungen an Netzwerkobjekten, Firewall-Regeln, DHCP und weiteren Konfigurationseinstellungen 
werden direkt über die Administrationsoberfläche vorgenommen. Eine zentrale, automatisierte, 
versionierte und reproduzierbare Bereitstellung der Konfigurationen besteht derzeit nicht.
2. Schwachstellen und Problemanalyse

Die derzeit manuelle Verwaltung der Firewall-Konfiguration erschwert eine einheitliche
und reproduzierbare Bereitstellung von Netzwerkobjekten, Firewall-Regeln und DHCP
Einstellungen. Änderungen werden direkt auf dem System vorgenommen und sind dadurch
nur eingeschränkt nachvollziehbar und versionierbar.

Ein zentral definierter Soll-Zustand der Firewall-Konfiguration besteht derzeit nicht.
Dadurch können manuelle Änderungen zu Abweichungen zwischen der dokumentierten
und der tatsächlichen Konfiguration führen. Besonders bei wiederkehrenden oder
umfangreicheren Änderungen an der Konfiguration erhöht das den administrativen
Aufwand und das Risiko von Konfigurationsfehlern.

Auch die Wiederherstellung eines alten Konfigurationszustandes ist bei fehlerhaften
Änderungen nur eingeschränkt standardisiert. Für den zukünftigen Betrieb und die
Standardisierung von Managed Services besteht daher der Bedarf an einem
nachvollziehbaren und reproduzierbaren Verfahren zur Verwaltung von Firewall-Konfigurationen.
3. Zielsetzung und Anforderungen

Ziel des Projektes ist die Konzeption und prototypische Umsetzung einer Lösung zur
automatisierten, versionierten und reproduzierbaren Verwaltung ausgewählter
Firewall-Konfigurationen.

Hierzu werden erst einmal geeignete Automatisierungsansätze und Werkzeuge bezüglich
ihrer technischen Eignung für die eingesetzte Firewall-Plattform untersucht und miteinander
verglichen. Die Bewertung erfolgt dann anhand definierter Anforderungen wie
Integrationsfähigkeit, Automatisierungsgrad, Nachvollziehbarkeit von Änderungen,
Idempotenz, Fehlerbehandlung, Wartbarkeit und Erweiterbarkeit.

Auf Grundlage der Evaluation wird ein geeigneter Ansatz ausgewählt und innerhalb einer
separaten Testumgebung als Proof of Concept umgesetzt. Dabei sollen ausgewählte
Netzwerkobjekte, Firewall-Regeln und DHCP-Einstellungen automatisiert
bereitgestellt, verändert und validiert werden.

Außerdem soll ein Verfahren entwickelt werden, mit dem Konfigurationsänderungen
versioniert und ein vorheriger Zustand im Fehlerfall nachvollziehbar wiederhergestellt werden.

 
Anforderungen:

- automatisierte Bereitstellung ausgewählter Netzwerkobjekte, Firewall-Regeln
  und DHCP-Einstellungen

- versionierte und nachvollziehbare Verwaltung der Konfigurationsdaten

- strukturierte Abbildung der Firewall-Konfiguration in einem einheitlichen
  Konfigurationskonzept unter Berücksichtigung der Schnittstellen und
  Datenstrukturen des ausgewählten Automatisierungswerkzeuges

- reproduzierbare Bereitstellung eines definierten Soll-Zustandes

- Unterstützung idempotenter Änderungen

- Validierung der ausgerollten Konfigurationen

- definierte Fehlerbehandlung und Wiederherstellung eines vorherigen Zustandes

- Sichere Verwaltung notwendiger Zugangsdaten und Secrets durch verschlüsselte
  Ablage und kontrollierte Bereitstellung zur Laufzeit 

- Umsetzung und Erprobung ausschließlich innerhalb einer separaten Testumgebung

- Erweiterbarkeit des Ansatzes auf weitere Firewall-Konfigurationsbereiche
4. Projektabgrenzung und Einschränkungen 

- Produktive Firewall-Migration: Die Migration der bestehenden produktiven Firewall auf
  OPNsense erfolgt vor Beginn des Abschlussprojektes und ist nicht Bestandteil der Projektarbeit.
 
- Testumgebung: Die Konzeption, Umsetzung und Erprobung des Infrastructure as Code
  Proof of Concept erfolgt ausschließlich in einer separaten Testumgebung. Änderungen an der
  produktiven Firewall werden im Rahmen des Projektes nicht durchgeführt.

- Funktionsumfang: Der Prof of Concept beschränkt sich auf ausgewählte Konfigurationsbereiche,
  insbesondere auf Netzwerkobjekte, Firewall-Regeln und DHCP-Einstellungen.

- Eigenentwicklung: Die Entwicklung einer eigenen Automatisierungssoftware oder eines
  herstellerunabhängigen Datenmodells ist nicht Bestandteil des Projektes.

- Produktivsetzung: Eine Überführung des Proof of Concept in den produktiven Betriebs-erfolgt
  nicht innerhalb des Abschlussprojektes. Das Projektergebnis dient als technische Entscheidungs- 
  und Umsetzungsgrundlage für die geplante spätere Einführung der automatisierten 
  Firewall-Konfigurationsverwaltung im produktiven Betrieb.

- Zeitrahmen: Die Projektdurchführung ist auf insgesamt 40 Stunden begrenzt.

- Eigenleistung: Planung, Evaluation, Konzeption, Umsetzung, Test und Dokumentation des
  Proof of Concept erfolgen als Eigenleistung und werden vom Projektbetreuer abgenommen.
Projektphasen und Zeitplanung


Informationen:
5 Stunden

Analysephase:
    • Ist-Analyse der bestehenden administrativen Abläufe und Konfigurationsverwaltung (1h)
    • Anforderungsanalyse und Erstellung eines Anforderungskatalogs (2h)
    • Definition der Anforderungen an die Testumgebung (1h)
    • Projekt- und Meilensteinplanung (1h)

Beschreibung: Analyse der derzeitigen manuellen Firewall-Administration und der bestehenden 
Abläufe bei Konfigurationsänderungen. Definition der technischen und organisatorischen Anforderungen 
an die zukünftige automatisierte Konfigurationsverwaltung sowie Festlegung des Projektablaufs und der 
Anforderungen an die separate Testumgebung.

Planung:
11 Stunden

Evaluierungs- & Konzeptionsphase:
    • Recherche geeigneter Automatisierungsansätze und Werkzeuge (2h)
    • Technischer Vergleich der vorausgewählten Lösungen (2h)
    • Nutzwertanalyse und Auswahl des geeigneten Ansatzes (1,5h)
    • Wirtschaftlichkeits- und Aufwand-Nutzen-Betrachtung der vorausgewählten Lösungen(1h)
    • Erstellung des Konfigurationskonzepts (1,5h)
    • Konzeption der Versionierung und Secret-Verwaltung (1h)
    • Konzeption von Deployment, Validierung und Wiederherstellung (1,5h)
    • Erstellung des Testkonzepts (0,5h)

Beschreibung: Systematische Bewertung geeigneter Lösungen zur automatisierten Verwaltung der 
OPNsense-Firewall. Vergleich der vorausgewählten Ansätze anhand definierter Anforderungen wie 
Integrationsfähigkeit, Automatisierungsgrad, Idempotenz, Wartbarkeit, Fehlerbehandlung und Erweiterbarkeit. 
Auswahl einer geeigneten Lösung mittels Nutzwertanalyse und Erarbeitung des technischen Soll-Konzepts für 
Konfigurationsstruktur, Versionierung, Secret-Verwaltung, Deployment, Validierung und Wiederherstellung sowie 
die Aufstellung einer Wirtschaftlichkeits- und Aufwand-Nutzen-Betrachtung.

Durchführung:
11 Stunden

Realisierungsphase:
    • Bereitstellung und Grundkonfiguration der OPNsense-Testumgebung (1,5h)
    • Installation und Konfiguration der ausgewählten Automatisierungslösung (1,5h)
    • Aufbau der Repository- und Konfigurationsstruktur (1,5h)
    • Automatisierung von Netzwerkobjekten und Firewall-Regeln (3h)
    • Automatisierung ausgewählter DHCP-Einstellungen (1,5h)
    • Umsetzung der Versionierung und sicheren Secret-Verwaltung (1h)
    • Umsetzung des Sicherungs- und Wiederherstellungsverfahrens (1h)

Beschreibung: Technische Umsetzung des zuvor erarbeiteten Soll-Konzepts innerhalb einer separaten Testumgebung. 
Einrichtung der ausgewählten Automatisierungslösung und Aufbau einer strukturierten, versionierten Konfigurationsverwaltung. 
Automatisierte Bereitstellung ausgewählter Netzwerkobjekte, Firewall-Regeln und DHCP-Einstellungen sowie Umsetzung der 
vorgesehenen Secret-Verwaltung und des definierten Wiederherstellungsverfahrens.

Kontrolle:
13 Stunden

Qualitätssicherung, Projektabnahme & Dokudurchführung:
    • Funktionsprüfung der automatisierten Konfiguration (1,5h)
    • Prüfung der Idempotenz (0,5h)
    • Validierung des definierten Soll-Zustands (1h)
    • Fehler- und Wiederherstellungstest (1h)
    • Soll-Ist-Vergleich & Projektabnahme durch den Projektbetreuer (1h)
    • Erstellung des Projektberichts / Dokumentation (6,5h)
    • Zusammenstellung technischer Anlagen & Betriebsdokumentation (1,5h)

Beschreibung: Überprüfung der automatisiert bereitgestellten Firewall-Konfiguration anhand definierter Testfälle. 
Prüfung von Funktion, Idempotenz, Reproduzierbarkeit und Übereinstimmung mit dem definierten Soll-Zustand. 
Durchführung eines kontrollierten Fehler- und Wiederherstellungstests sowie Soll-Ist-Vergleich und Projektabnahme. 
Erstellung der Projektdokumentation einschließlich technischer Anlagen, Evaluationsergebnissen, Soll-Konzept und 
Testergebnissen sowie einer technischen Betriebsdokumentation.

Bearbeitet von Ueba3ba

das liest sich für mich wie ein Arbeitsauftrag ... ich seh da keine komplexen Entscheidungen.

Ich halte das aus dem Bauch heraus für eher ungeeignet. Du hast zwar zb wirtschaftliche Betrachtungen mit drin, aber es ist und bleibt opensense

Wenn ich den Antrag so lese reden wir über EINE Firewall ( die es schon gibt ) und für die willst Du im Grunde ne Versionierung und Doku von Änderungen machen.

Ich würde hier zu einer Ablehnung tendieren, da ich den FiSi zuwenig im Sinne der Prüfungsordnung erkenne. Mal sehen was die anderen so sagen ?

vor 18 Minuten, charmanta hat gesagt:

Wenn ich den Antrag so lese reden wir über EINE Firewall ( die es schon gibt ) und für die willst Du im Grunde ne Versionierung und Doku von Änderungen machen.

Das sehe ich ähnlich.

Dein Antrag scheint erstmal inhaltlich ordentlich, aber an ein paar Stellen noch nicht ganz rund. Am meisten stört mich der Widerspruch zwischen "läuft noch auf einer proprietären Firewall" und "Migration auf OPNsense ist schon erledigt". Das würde mich als Prüfer verwirren. Außerdem bleiben deine Ziele eher vage, weil konkrete Zahlen fehlen, etwa wie viele Regeln oder DHCP-Bereiche am Ende automatisiert laufen sollen und wie schnell ein Rollback gehen muss. Beim Nutzen für den Betrieb fehlt mir eine echte Rechnung und eine Stunde dafür wirkt mir zu dünn. Außerdem fehlen mir Angaben zum Projektumfeld (Auftraggeber, Betreuer, Ausstattung) und eine Übergabe an den Betrieb.

  • Autor

Guten Abend. Ich glaube ich weiß worauf ihr hinauswollt.

@charmanta du schriebst ,,EINE Firewall ( die es schon gibt ),,

Meinst du damit das ich es verallgemeinern müsste? Also nicht ,,IaC-Lösung zur Verwaltung einer OPNsense,,

sonder eher in Richtung ,,IaC-Lösung zur zentralen Verwaltung der Netzwerk-Infrastruktur,, ?

@Muff Potter Ich kann nachvollziehen warum du das als Widerspruch erkennst. Ich meinte damit: Zum Zeitpunkt der Erstellung des Antrages

ist die proprietäre Firewall im Einsatz(So steht es im ,,IST-Zustand,,) und wird vor Beginn und außerhalb des Projektes auf eine OPNsense migriert(So steht es in ,,Projektabgrenzung und Einschränkungen,,.

Dass das an der Stelle zu einem Widerspruch führen könnte war mir zu diesem Zeitpunkt nicht bewusst. Das lässt sich leicht korrigieren.

Um sagen zu können wie viele Regeln, DHCP-Reservierungen und -Bereiche am Ende automatisiert laufen sollen, müsste ich mein Projekt doch

wieder auf ein vorhandenes System ausrichten. Oder würde eine ungefähre Anzahl ausreichen? Es handelt sich ja um ein prototypisches PoC das als Grundlage für eine spätere Einführung dienen soll. Ah Moment, der Satz ,,Es handelt sich ja um ein prototypisches PoC das als Grundlage für eine spätere Einführung dienen soll,, bedeutet

das ich ja bei der Einführung wissen sollte wie viele Regeln, DHCP-Reservierungen und -Bereiche automatisch laufen sollen. ;-)

Den Nutzen kann ich noch etwas ausarbeiten und im Antrag an passender Stelle ergänzen. Da das Projekt in meinem Eigenen Unternehmen durchgeführt werden soll,

dient der Projektbetreuer als Auftraggeber. Meinst du damit das ich das konkret im Antrag erwähnen sollte?

Und die Übergabe an der Betrieb habe ich doch tatsächlich vergessen.

Danke für dieses und weiteres Feedback

LG
Üba3ba

Bearbeitet von Ueba3ba

Erstelle ein Konto oder melde dich an, um einen Kommentar zu schreiben.

Konto

Navigation

Suchen

Suchen

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.