ansatz 2

chapters/technische-umsetzung/main.tex

@@ -5,6 +5,7 @@
 \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,
@@ -23,6 +24,32 @@ die Berechtigung $r$ zu verändern.
 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.
+
+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}
+
+\subsection*{Kodierung}
 
 \section{Integration in Ansible}