%
% Chapter: Technische Umsetzung
%

\chapter{Technische Umsetzung}
\section{Berechtigungsverwaltung}
\subsection*{Ausarbeitung der Herangehensweise}
\subsubsection*{Ansatz 1}
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.
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 Administratoren und Entwickler API-Keys für \ac{1P} erhalten.
Entwickler 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 weiterzureichen.
Die \ac{MASA} provisioniert eigene API-Keys an Entwickler und vermermerkt serverseitig,
welcher API-Key berechtigt ist, welche \ac{1P}-Einträge abzufragen.
Der API-Key könnte grundlegende Informationen wie zum Beispiel Entwicklernamen 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-Key
eingebettet. Dadurch wäre gewährleistet, dass ein Angreifer, selbst bei sehr weitreichendem Zugriff
in die \ac{MASA}, nicht auf das Innere des Passwort-Managers zugreifen könnte, da die \ac{MASA} dazu selbstständig
gar nicht im Stande wäre. Da Entwickler lediglich ein Schlüsselfragment des Verschlüsselungs-Schlüssels
in ihrem Key eingebettet hätten, der ohne einen serverseitigen Schlüssel der \ac{MASA} nicht auslesen werden kann,
bestünde auch keine Gefahr, dass ein Entwickler anhand seines bzw. ihres Keys ungeschützten Zugang zum Passwort-Manager
erhaltne würde. Dieser Ansatz erlaubt für weitreichende Flexibilität, da sämtliche Logik, die sich mit Berechtigungen
beschäftigt, selbst 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 jeden Entwickler $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 Entwickler 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-1-mit-python}
\end{nicepic}

\subsection*{Kodierung}

\section{Integration in Ansible}