HSWO_MSC_WS2425_DEEP_DIVE_PAPER/chapters/technische-umsetzung/main.tex

%
% Chapter: Technische Umsetzung
%

\chapter{Technische Umsetzung}
\section{Berechtigungsverwaltung}
\subsection{Ausarbeitung der Herangehensweise}
Zunächst wurde gebrainstormed, welche Herangehensweisen hier möglich sind.
Ein Artefakt des Brainstormings ist eine Mind-Map, die unter \fullref{app:ideensammlung} zu finden ist.

\subsubsection{Ansatz 1}
Der aus dieser Mindmap, nach individueller Meinung des Autors, vielversprechenste Ansatz ist es,
die \ac{1P}-Restful-API zu verwenden.
Bei diesem Ansatz würden Administrator*innen und Entwickler*innen API-Keys für \ac{1P} erhalten.
Entwickler*innen hätten mit ihren Keys bestimmte Leseberechtigungen $r$ und Administratoren
die Berechtigung $r$ zu verändern.

\begin{nicepic}
    \includegraphics[width=0.75\textwidth]{images/dev-stuff-via-api-keys.png}
    \captionof{figure}{Relationsdiagramm: Ansatz 1 | 1Password-API}
    \caption*{Quelle: Eigene Darstellung}
    \label{fig:ansatz-1-mit-api-keys}
\end{nicepic}

Dieser Ansatz wurde zeitnah als unumsetzbar erkannt und verworfen, da \ac{1P} das nachträgliche Verändern
von API-Key-Berechtigungen nicht erlaubt.

\subsubsection{Ansatz 2}
Der nächste Lösungsansatz befasst sich mit einer Abstraktionsebene: Der \ac{MASA}.
Hier ist die grundlegende Idee, dass es eine serverseitige Anwendung gibt, die sich \ac{MASA} nennt.
Diese Anwendung übernimmt die Aufgabe anhand eines hinterlegten \ac{1P}-API-Keys Secrets
aus dem \ac{1P}-Vault des Partnerunternehmens abzufragen und an Entwickler*innen weiterzureichen.
Die \ac{MASA} provisioniert eigene API-Keys an Entwickler*innen und vermermerkt serverseitig,
welcher API-Key berechtigt ist, welche \ac{1P}-Einträge abzufragen.
Der API-Key könnte grundlegende Informationen wie zum Beispiel Entwickler*innennamen und Ablaufzeitpunkte des
Keys einbetten. Dieser Ansatz trägt viel Sicherheitsverantwortung, da eine mögliche Ausnutzung einer
Sicherheitslücke der \ac{MASA} direkt in den Firmen-Passwortmanager führen würden.
Um diesem Risikofaktor entgegenzuwirken würde der \ac{1P}-Key der \ac{MASA} verschlüsselt werden und die
\ac{MASA} würde nur einen Teil des Entschlüsselungs-Keys vorrätig halten. Der andere Teil wäre in jedem Entwickler*innen-Key
eingebettet. Dadurch wäre gewährleistet, dass ein*e Angreifer*in, selbst bei sehr weitreichendem Zugriff
in die \ac{MASA}, nicht auf das Innere des Passwortmanagers zugreifen könne, da die \ac{MASA} dazu selbstständig
gar nicht im Stande wäre. Da Entwickler*innen lediglich ein Schlüsselfragment des Verschlüsselungs-Schlüssels
in ihrem Key eingebettet hätten, der einen serverseitigen Schlüssel der \ac{MASA} zum auslesen benötigt,
bestünde auch keine Gefahr, dass ein*e Entwickler*in anhand seines bzw. ihres Keys ungeschützten Zugang zum Passwortmanager
erhalten würde. Dieser Ansatz erlaubt für weitreichende Flexibilität, da sämtliche Logik, die sich mit Berechtigungen
beschäftigt, anwendungsfallspezifisch geplant und umgesetzt wäre.

\begin{nicepic}
    \includegraphics[width=0.75\textwidth]{images/masa-diagram.png}
    \captionof{figure}{Relationsdiagramm: Ansatz 2 | MASA}
    \caption*{Quelle: Eigene Darstellung}
    \label{fig:ansatz-2-mit-masa}
\end{nicepic}


Letztendlich entschied sich der Stakeholder gegen die Umsetzung der \ac{MASA}, da dieser Ansatz für zu
Aufwändig betrachtet wird und für den durch sie erbrachten Vorteil zu viel Aufwand und Angriffsfläche schaffen würde.

\subsubsection{Ansatz 3}
Der letzte Lösungsansatz befasst sich mit dem Erstellen dedizierter Vaults für jede*n Entwickler*in $e$.
Hierbei existiert eine Python-Toolbox, die anhand eine Yaml-Datei Referenzen auf diese Passwort-Einträge
in $\text{Vault}_e$ legt und von dort entfernt, wenn ein solcher Zugriff laut der Yaml-Datei nicht mehr vorgesehen ist.
Diese Einträge können über feste Eintrags-IDs und über Regex bezogen auf die Eingrags-Titel einem/r Entwickler*in vorgesehen werden.

\begin{nicepic}
    \includegraphics[width=0.75\textwidth]{images/dev-stuff-python.png}
    \captionof{figure}{Relationsdiagramm: Ansatz 2 | Python-Toolbox}
    \caption*{Quelle: Eigene Darstellung}
    \label{fig:ansatz-3-mit-python}
\end{nicepic}

Letztendlich entschied sich der Stakeholder für Ansatz 3, da er ihm kostengünstig und aursreichend erschien.

\subsection{Kodierung}
Um den vom Stakeholder ausgewählten Ansatz 3 wie geplant umzusetzen, wurden zunächst
die Dokumentationen diverser \ac{1P}-Schnittstellen konsultiert. Schnell offenbarte sich eine Alternative
zu API-Keys: Die \ac{1P}-Desktop-Anwendung stellt eine CLI-API bereit.
Die CLI-API der Desktop-Anwendung zu verwenden, würde drei Probleme lösen:
\begin{description}
    \item [Kosten und hedonische Qualität] \hfill \\
        Einen API-Key zu erstellen und zu übermitteln ist kostenspielig und umständlich. Ein \ac{1P}-Konto haben dem gegenüber bereits alle Entwickler*innen des Partnerunternehmens.
    \item [Authentifizierung und Sicherheit] \hfill \\
        Anstatt einen API-Key unsicher zu speichern und in relevante Programme (=Ansible) zu laden, wird die Authentifizierung zu \ac{1P} ausgelagert.
    \item [Manuelle Einsicht] \hfill \\
        Da über die CLI-Methode der Zugriff auf die Entwickler*innen-Vaults direkt über die \ac{1P}-Desktop-App geschieht, kann diese den Vault-Inhalt auch dem Nutzer in ihrem GUI offenbaren.
    \item [Integrationsaufwand] \hfill \\
        Die Verwendung der \ac{1P}-Restful-API erscheint dem Autor nach ihrer Dokumentation sehr aufwändig und kompliziert. Eine CLI-API zu verwenden würde somit in der Umsetzung Projektressourcen sparen.
\end{description}

So begründet fällt die Wahl der Schnittstelle zu \ac{1P} auf ihre CLI-API.
Um schnelle Softwareentwicklung mit minimalem Overhead zu gewährleisten und um für eine spätere Einbindung in Ansible
bereits in Vorleistung zu treten, fällt die Wahl der Programmiersprache auf Python. Ansible-Module können mit Python geschrieben werden. \cite{bib:ansible-docs-python-module}
Es wurde eine rudimentäre Architektur entworfen, die beschreibt, welche Komponente des Werkzeuges aus welchen kleineren Komponenten besteht.
Am unteren Ende dieses Aggregatbaumes stehen atomare Operationen. Im Kontext dieses Werkzeuges sind atomare Operationen Operationen,
die vom \ac{1P}-CLI ausgeführt werden. Diese Operationen implementiert also \ac{1P} selbst.
Hierbei handelt es sich nur um Lese, Erstell- und Löschvorgänge. Das Erfassen, auf welchen Eintrag welche*r Entwickler*in Zugriff hat,
und auf welche nicht, übernimmt \textit{sync-dev-vault.py}. Die Funktionen der andere Skripte ergeben sich in Gänze aus ihren Dateinamen.

\begin{nicepic}
    \includegraphics[width=1\textwidth]{images/config-file.png}
    \captionof{figure}{Struktur der Zugriffs-config.yml}
    \caption*{Quelle: Eigene Darstellung}
    \label{fig:config-file}
\end{nicepic}

\begin{nicepic}
    \includegraphics[width=0.75\textwidth]{images/program-structure.png}
    \captionof{figure}{Diagramm: Programmstruktur Secret-Synchronizer}
    \caption*{Quelle: Eigene Darstellung}
    \label{fig:programmstruktur-secret-synchronizer}
\end{nicepic}

\subsubsection{Sicherheitsbedenken}
Die Konfigurationsdatei definiert Zielvaults, nach ihren kryptsichen IDs. Anhand dieser IDs sieht ein*e Administrator*in keine Vaultnamen.
Wenn nun aus etwaigen Gründen dort die ID eines Nutzvaults des Partnerunternehmems aufgeführt wäre, würde das
Werkzeug alle sich dort befindlichen Zugänge löschen. Das wäre ein Super-GAU in Form von Datenverlust.

\subsubsection{Sicherheitsvorkehrungen}
Um das zu verhindern, wurde eine Liste mit wichtigen Vault-IDs fest einkodiert. 
Alle Erstell- oder Löschmethoden müssen einen Vault-ID-Parameter erhalten, selbst wenn dieser technisch nicht notwendig ist.
Wenn diese Vault-ID nun in der Liste der fest kodierten Nutzvault-IDs vorkommt, meldet die Methode einen deskriptiven Fehler und beendet die Programmausführung.
Somit ist gewährleistet, dass selbst bei einer fatalen Fehlkonfiguration kein Datenverlust entseht.

\section{Integration in Ansible}