init
This commit is contained in:
189
expose.tex
Normal file
189
expose.tex
Normal file
@@ -0,0 +1,189 @@
|
||||
\documentclass[paper=a4,fontsize=12pt,ngerman]{scrartcl}
|
||||
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage[T1]{fontenc}
|
||||
\usepackage{graphicx}
|
||||
\usepackage[ngerman]{babel}
|
||||
\usepackage[autostyle=true]{csquotes} %biblatex german quoting
|
||||
\usepackage{amsmath}
|
||||
\usepackage{pifont} % ding55
|
||||
\usepackage[a4paper,left=25mm,right=35mm,top=25mm,bottom=30mm]{geometry}
|
||||
%\usepackage{parskip}
|
||||
\usepackage{comment} %dies ist ein kommentar
|
||||
% tableau
|
||||
\usepackage{booktabs}
|
||||
\usepackage{multirow} % table stuff
|
||||
\usepackage{tablefootnote} % table
|
||||
\usepackage{diagbox}
|
||||
\usepackage{caption}
|
||||
\usepackage{url} %damit urls richtig formatted werden dürfen, müss \url{URL} usen
|
||||
\usepackage{tikz}
|
||||
\usetikzlibrary{shapes.geometric, arrows, positioning}
|
||||
%\usepackage[colorlinks=false, hidelinks]{hyperref} % keine hyperrefs
|
||||
|
||||
\usepackage{listings} % code blocks
|
||||
\usepackage{xcolor}
|
||||
\usepackage{todonotes}
|
||||
|
||||
\usepackage[backend=biber, style=numeric, url=true]{biblatex} %URL in biblatex
|
||||
\addbibresource{literatur.bib}
|
||||
%\bibliography{literatur} %bibtex
|
||||
|
||||
\graphicspath{{graphics/}}
|
||||
|
||||
\definecolor{codegreen}{rgb}{0,0.6,0}
|
||||
\definecolor{codegray}{rgb}{0.5,0.5,0.5}
|
||||
\definecolor{codepurple}{rgb}{0.58,0,0.82}
|
||||
\definecolor{backcolour}{rgb}{0.95,0.95,0.92}
|
||||
|
||||
\lstdefinestyle{mystyle}{
|
||||
backgroundcolor=\color{backcolour},
|
||||
commentstyle=\color{codegreen},
|
||||
keywordstyle=\color{magenta},
|
||||
numberstyle=\tiny\color{codegray},
|
||||
stringstyle=\color{codepurple},
|
||||
basicstyle=\ttfamily\footnotesize,
|
||||
breakatwhitespace=false,
|
||||
breaklines=true,
|
||||
captionpos=b,
|
||||
keepspaces=true,
|
||||
numbers=left,
|
||||
numbersep=5pt,
|
||||
showspaces=false,
|
||||
showstringspaces=false,
|
||||
showtabs=false,
|
||||
tabsize=2
|
||||
}
|
||||
\lstset{style=mystyle}
|
||||
|
||||
\newcommand{\cmark}{\ding{51}}
|
||||
\newcommand{\xmark}{\ding{55}}
|
||||
\newcommand{\myTitleDos}{Entwicklung einer Deployment- und Upgradestrategie in Kubernetes-basierten On-Premise Umgebungen}
|
||||
\newcommand{\myTitle}{Security-Compliant Container-Supply-Chain und Patch-Management in isolierten Kubernetes-Umgebungen}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\pagenumbering{roman}
|
||||
\pagestyle{plain}
|
||||
|
||||
% Einbinden der Titelseite
|
||||
\begin{titlepage}
|
||||
|
||||
\linespread{1.5}
|
||||
|
||||
\includegraphics[width=\linewidth]{htw_logo}
|
||||
|
||||
\begin{center}
|
||||
\large
|
||||
\hfill
|
||||
\vfill
|
||||
\Large{\bfseries{Exposé: \myTitle}}
|
||||
|
||||
von \\
|
||||
Tim Wall\\
|
||||
Mat. Nr. 5014365
|
||||
|
||||
\vfill
|
||||
\vfill
|
||||
|
||||
Saarbrücken, den \today
|
||||
\end{center}
|
||||
|
||||
\end{titlepage}
|
||||
|
||||
\clearpage
|
||||
\pagenumbering{arabic}
|
||||
|
||||
%\tableofcontents
|
||||
|
||||
\section{Forschungsfrage}
|
||||
|
||||
Wie lässt sich eine sichere Softwarearchitektur für netzwerkisolierte Kubernetes-Cluster entwerfen, die eine automatisierte Container-Supply-Chain mit integrierter Security-Compliance (Image-Signing, Vulnerability Scanning, SBOM) und höchstmöglich automatisiertem Patch-Management ohne Internetverbindung gewährleistet?
|
||||
|
||||
\section{Problemstellung}
|
||||
|
||||
Moderne Software wird zunehmend über containerisierte Anwendungen verteilt und mit Orchestrations-Software wie Kubernetes verwaltet.
|
||||
Gleichzeitig werden hochregulierte On-Premise und Edge Umgebungen immer öfters vollständig ohne Internetanbindung betrieben.
|
||||
Regularien wie der Cyber-Resilience-Act setzen Software Bill of Materials (SBOMs), Schwachstellenmanagement, Incident Response und Meldepflichten vor.
|
||||
Diese Herausforderungen benötigen eine durchdachtes Architektur, welches automatisiert SBOM-Generierung, Vulnerability-Scanning, Image-Signatur, Deployment und Policy-Enforcement in isolierten Kubernetes-Umgebungen integriert.
|
||||
|
||||
\section{Nicht-Ziele}
|
||||
|
||||
Außerhalb des Umfangs dieser Arbeit sind Schwachstellen, die nicht die Container-Supply-Chain, das Patch-Management oder die Cluster-Verwaltung betreffen, zum Beispiel physische Schwachstellen. Desgleichen sind Multi-Cluster-Umgebungen und Windows-Nodes kein Ziel der Arbeit. Die Basis bildet der Orchestrator Kubernetes, die Übertragbarkeit auf Alternativen wie Docker Swarm oder HashiCorp Nomad ist nicht garantiert. Die Anforderungsanalyse und das darausfolgende Architekturkonzept basiert auf dem konkreten Unternehmenskontext der psb intralogistics GmbH und ist nicht für alle AirGap-Szenarien generalisierbar.
|
||||
|
||||
\section{Motivation}
|
||||
|
||||
Schwachstellen in weltweit genutzter Software und deren Supply-Chains werden im KI-Zeitalter schneller gefunden, (siehe xz, Copy Fail, Dirty Frag, npm Vorfälle) und können gleichzeitig schneller ausgenutzt werden.
|
||||
Während netzwerkisolierte Installationen ihre Angriffsoberfläche minimieren, ist sie nicht Null. Die Software-Supply-Chain, physischer Zugang und alternative Extraktionsmöglichkeiten wie Elektromagnetismus bleiben Wege, um ein Netzwerk zu infiltrieren oder Daten zu extrahieren. Somit ist auch innerhalb eines AirGap-Deployments ein Architekturkonzept notwendig, um die Sicherheit zu gewährleisten.
|
||||
|
||||
\section{Zielgruppe}
|
||||
|
||||
Die primäre Zielgruppe sind Cybersicherheitspezialisten und DevOps-Engineers, welche in regulierten Umgebungen AirGap-Kubernetes-Cluster bereitstellen und betreiben. Darunter zählen Behörden, kritische Infrastrukturbereitsteller, Finanzinstitute, Rüstungsunternehmen oder Industriekonzerne mit strengen Netzwerkanforderungen. Compliance-Verantwortliche bilden die Sekundärzielgruppe, da sie Anhand der Bewertung des Clusters Stärken und Defizite in existierenden Kriterienkatalogen identifizieren können.
|
||||
|
||||
\section{Heutiger Forschungsstand}
|
||||
|
||||
AirGap-Umgebungen und Provisionierung auf Basis von kubeadm, k3s, RKE2 und OpenShift sind gut Dokumentiert.
|
||||
Forschung zu Schwachstellenmanagement ist für Container in Online-Umgebungen abgedeckt. Sigstore Cosign, Trivy, Grype und Syft bilden die Grundlage für eine Container-Supply-Chain. Patch-Management in AirGap-Clustern ist eine akademische Forschungslücke. Es fehlt eine Referenzarchitektur für Offline-Umgebungen, aufbauend auf einem getestetem Gesamtsystem.
|
||||
|
||||
\section{Methodischer Ansatz}
|
||||
|
||||
Basierend auf der Analyse eines konkreten Anwendungsszenarios anhand der psb intralogistics GmbH und einer Literatur- sowie Tool-Analyse wird ein Anforderungskatalog erarbeitet. Darauf aufbauend wird eine Referenzarchitektur entworfen, implementiert und bezüglich Compliance und Sicherheit evaluiert.
|
||||
|
||||
\section{Notwendige Resourcen}
|
||||
|
||||
Schätzung der benötigten Ressourcen:
|
||||
|
||||
\begin{itemize}
|
||||
\item Infrastruktur: 3-5 Linux-Maschinen (Bare-Metal oder VM) zum Instanziieren von isolierten Kubernetes-Clustern
|
||||
\item Software: Ansible / pyinfra (Provisionerung), kubeadm / RKE2 / k3s / Talos (Distribution), Harbor Registry / Sonatype Nexus Repository (Repo), Cosign (Signierung), Trivy / Grype / Clair (CVE-Scan / SBOM), Syft (SBOM), Spegel (Image-Mirror), Kyverno / OPA Gatekeeper (Policy Admission), FluxCD / ArgoCD (GitOps), Hauler / Zarf (AirGap Transport)
|
||||
\item Zeit: 13 Wochen
|
||||
\end{itemize}
|
||||
|
||||
\section{Ergebnis}
|
||||
|
||||
Primär entsteht eine dokumentierte Referenzarchitektur, welche als Blaupause für das Bereitstellen von sicheren AirGap-Kubernetes-Clustern mit integrierter Container-Supply-Chain-Sicherheit dient, sowie ein dazugehöriges Mapping, welches die Einhaltung der Compliance-Anforderungen aufzeigt (CRA, SLSA). Ergänzend entsteht ein Proof-of-Concept, der die Architektur in einer Testumgebung mit den darausfolgenden Artefakte (z.B. GitOps-Directory, Helm-Charts, Ansible-Playbooks) abbildet.
|
||||
|
||||
\section{Zeitplan}
|
||||
|
||||
\begin{table}[ht]
|
||||
\begin{tabular}{rl}
|
||||
Woche & Aufgabe $\rightarrow$ Ergebnis \\
|
||||
\hline \\
|
||||
1 & Grundlagen-Recherche (k8s, AirGap, Supply-Chain, Patch-Management) \\
|
||||
& $\rightarrow$ Draft Theoretische Grundlagen \\
|
||||
|
||||
2 & Anforderungsanalyse psb und Literaturrecherche \\
|
||||
& $\rightarrow$ funktionale \& qualitative Anforderungen, Zielkonflikte, Testszenarien \\
|
||||
|
||||
3 & Architektur-Entwurf, Entscheidungsbegründung (ATAM Utility-Tree) \\
|
||||
& $\rightarrow$ Draft Architektur, Diagramme Komponenten \& Runtime \\
|
||||
|
||||
4 & Architektur-Feedback psb \& Betreuer, Finalisierung Architektur \\
|
||||
& $\rightarrow$ Finalisierung Architektur \\
|
||||
|
||||
5-6 & PoC Setup: Container-Supply-Chain (CVE, Signierung) \\
|
||||
& $\rightarrow$ Funktionale Pipeline \& Draft PoC Container-Supply-Chain \\
|
||||
|
||||
7-8 & PoC Setup: AirGap-Cluster, Provisionierung, Registry, Policies \\
|
||||
& $\rightarrow$ Funktionales Cluster \& Draft PoC Cluster \\
|
||||
|
||||
9 & PoC: Patch-Management, mögliche Automatisierung \\
|
||||
& $\rightarrow$ Draft Patch-Management \\
|
||||
|
||||
10 & PoC Testing \& Metrikerhebung (Deployment-Zeit, Automatisierung,) \\
|
||||
& $\rightarrow$ Draft Metriken, Erkenntnisse, Diagramme Metriken \\
|
||||
|
||||
11 & Compliance-Bewertung Architektur \& PoC (CRA, SLSA) \\
|
||||
& Architektur-Bewertung (STRIDE, Risiken, Tradeoffs) \\
|
||||
& $\rightarrow$ Draft Compliance, Draft Compliance-Bewertung\\
|
||||
|
||||
12 & Diskussion, Fazit \& Ausblick \\
|
||||
& $\rightarrow$ Draft Diskussion, Fazit \& Ausblick \\
|
||||
|
||||
13 & Proof-Read, Finalisierung, Signierung, Binden, Vorbereitung Kolloqium \\
|
||||
& $\rightarrow$ Finale Arbeit \\
|
||||
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\end{document}
|
||||
Reference in New Issue
Block a user