wrote some stuww

chapters/anforderungen.tex

@@ -27,7 +27,8 @@ nicht-funktioniale Anforderungen zu unterteilen ist.
         Wildcard-Matching auf den \ac{1P}-Eintragstitel für zusammenhängende Einträge. \\ \hline
         \ac{1P}-Einträge sollen einzeln zuweisbar sein. \\ \hline
         Nicht im YAML gelistete Zugänge sollen bei Anwendung entfernt werden. \\ \hline
-        Ansible Secrets müssen aus 1Password dereferenziert werden können. \\ \hline
+        Ansible Secrets müssen aus \ac{1P} dereferenziert werden können. \\ \hline
+        Einträge sollen auch manuell einsehbar sein. \\ \hline
         \textbf{Nicht-funktionale Anforderungen} \\ \hline
         Das System muss Berechtigungen von Entwicklern verwalten. \\ \hline
         Das System muss benutzerfreundlich sein. \\ \hline
@@ -36,8 +37,8 @@ nicht-funktioniale Anforderungen zu unterteilen ist.
         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
+        Nutzung von \ac{1P} ist zwingend erforderlich. \\ \hline
+        Die Übermittlung der Secrets muss über das Internet erfolgen. \\ \hline
     \end{tabular}
     \caption{Anforderungen}
 \end{table}

chapters/technische-umsetzung/main.tex

@@ -4,10 +4,11 @@
 
 \chapter{Technische Umsetzung}
 \section{Berechtigungsverwaltung}
-\subsection*{Ausarbeitung der Herangehensweise}
-\subsubsection*{Ansatz 1}
+\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 Administratoren und Entwickler API-Keys für \ac{1P} erhalten.
@@ -24,7 +25,7 @@ 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}
+\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
@@ -55,7 +56,7 @@ 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}
+\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.
@@ -65,10 +66,52 @@ Diese Einträge können über feste Eintrags-IDs und über Regex bezogen auf die
     \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}
+    \label{fig:ansatz-3-mit-python}
 \end{nicepic}
 
-\subsection*{Kodierung}
+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 der Entwickler 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 Developer-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, welcher Teil des Werkzeuges aus welchen Unterteilen besteht.
+Am unteren Ende dieses Abhängigkeitsbaumes 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.
+
+\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 Administrator keine Vaultnamen.
+Wenn nun aus irrelevanten 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 des Datenverlustes.
+
+\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 mit 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}
 

dexes/acrodex.tex

@@ -10,6 +10,9 @@
 %
     \acro{1P}[1P]{1Password}
     \acro{API}[API]{Application Programmer Interface}
+    \acro{CLI}[CLI]{Command Line Interface}
+    \acro{GAU}[GAU]{Größter Anzunehmender Unfall}
+    \acro{GUI}[GUI]{Graphical User Interface}
     \acro{MASA}[MASA]{Medienagenten Secret Authority}
     \acro{YAML}[YAML]{Yet Another Markup Language}
     %\acroplural{CMS}[CMSe]{Content Management Systeme}

dexes/glossarydex.tex

@@ -5,8 +5,8 @@
 \chapter{Glossar}
 
 \begin{description}
-    \item [(1P-)Eintrag] \hfill \\
-        Eine Gruppierung an Daten, die einen Login ermögliche. Z.B. $(\text{Nutzername},\text{Passwort})$. Eine solche Struktur kann bein \ac{1P} aus beliebig vielen Schlüsselwertpaaren bestehen.
+    \item [(1P-)Eintrag/Secret] \hfill \\
+        Eine Gruppierung an Daten, die einen Login ermögliche. Z.B. $(\text{Nutzername},\text{Passwort})$. Eine solche Struktur kann bein \ac{1P} aus beliebig vielen Schlüsselwertpaaren bestehen. Wird in dieser Ausarbeitung synonym zu 'Secret' verwendet.
     \item [(1P-)Vault] \hfill \\
         Eine Kollektion an Secret-Einträgen in einem Passwort-Manager (1Password).
     \item [Ansible-Playbook/s] \hfill \\

dexes/literature.bib

@@ -33,3 +33,11 @@
   year         = {2025},
   note         = {Zugriff: Januar 2025}
 }
+
+@misc{bib:ansible-docs-python-module,
+  author       = {{Red Hat, Inc.}},
+  howpublished = "\url{https://cn-ansibledoc.readthedocs.io/zh-cn/latest/dev_guide/developing_modules_general.html}",
+  title        = {{ Ansible module development: getting started }},
+  year         = {2019},
+  note         = {Zugriff: Januar 2025}
+}