ansatz 2

chapters/anforderungen.tex

@@ -37,6 +37,7 @@ nicht-funktioniale Anforderungen zu unterteilen ist.
         der zugrunde liegenden \ac{1P}-Einträgen führen könnten.\\ \hline
         \textbf{Constraints} \\ \hline
         Nutzung von 1Password ist zwingend erforderlich. \\ \hline
+        Die Übermittlung der Secrets muss über ds Internet erfolgen. \\ \hline
     \end{tabular}
     \caption{Anforderungen}
 \end{table}

chapters/grundlagen/main.tex

@@ -19,6 +19,9 @@ Die Arbeitsumgebung des Partnerunternehmens besteht für diese Themenstellug nen
     \label{fig:relationsdiagramm-devenv}
 \end{nicepic}
 
+Die lokalen Arbeitsumgebungen der Entwickler liegen großteils außerhalb des Firmennetzwerkes, da diese Entwickler
+oft oder ausschließlich im mobilen- bzw, Homeoffice arbeiten. Ein Firmen-VPN-Netz existiert nicht und ist auch nicht erwünscht.
+
 \section{1Password}
 \ac{1P} ist der vom Partnerunternehmen verwendete Passwort-Manager.
 Bereits vor Beginn der Bearbeitung dieser Themenstellung wurde deutlich gemacht, dass es

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}
 

dexes/acrodex.tex

@@ -9,6 +9,8 @@
 %
 %
     \acro{1P}[1P]{1Password}
+    \acro{MASA}[MASA]{Medienagenten Secret Authority}
+    \acro{API}[API]{Application Programmer Interface}
     %\acroplural{CMS}[CMSe]{Content Management Systeme}
 %
 %