ansatz 2

appendix.tex

@@ -4,4 +4,6 @@
 
 \begin{appendices}
     \input{appendix/interview-jochen}
+    \input{appendix/ideensammlung}
+    \input{appendix/old-relation-diagram}
 \end{appendices}

appendix/ideensammlung.tex

@@ -0,0 +1,9 @@
+\chapter{Ideensammlung}
+\label{app:ideensammlung}
+
+\begin{nicepic}
+    \includegraphics[width=1\textwidth]{images/ideensammlung.jpg}
+    \captionof{figure}{Ideensammlung}
+    \caption*{Quelle: Eigene Darstellung}
+    \label{fig:ideensammlung}
+\end{nicepic}

appendix/old-relation-diagram.tex

@@ -0,0 +1,9 @@
+\chapter{Relationsdiagramm (Überholt)}
+\label{app:old-relation-diagram}
+
+\begin{nicepic}
+    \includegraphics[width=0.9\textwidth]{images/old-usage-diagram.jpg}
+    \captionof{figure}{Relationsdiagramm: (Überholt) Relationsdiagramm}
+    \caption*{Quelle: Eigene Darstellung}
+    \label{fig:relationsdiagramm-old}
+\end{nicepic}

chapters/anforderungen.tex

@@ -33,10 +33,11 @@ nicht-funktioniale Anforderungen zu unterteilen ist.
         Das System muss benutzerfreundlich sein. \\ \hline
         Das System darf nicht aufwändig zu pflegen sein. \\ \hline
         Die benötigte Zeit zur Ausführung der Anwendung soll nicht sehr lange sein. \\ \hline
-        Das System muss robust gegenüber Misskonfigurationen sein, die zur Lösung von\\
-        den zugrunde liegenden \ac{1P}-Einträgen führen könnten.\\ \hline
+        Das System muss robust gegenüber Misskonfigurationen sein, die zur Löschung
+        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

@@ -4,5 +4,52 @@
 
 \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 haben 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.
+
+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}
 %
 %