diff --git a/chapters/technische-umsetzung/main.tex b/chapters/technische-umsetzung/main.tex index 88cafea..e259c08 100644 --- a/chapters/technische-umsetzung/main.tex +++ b/chapters/technische-umsetzung/main.tex @@ -11,7 +11,7 @@ Ein Artefakt des Brainstormings ist eine Mind-Map, die unter \fullref{app:ideens 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 +Entwickler hätten mit ihren Keys bestimmte Leseberechtigungen $r$ und Administratoren die Berechtigung $r$ zu verändern. \begin{nicepic} @@ -44,10 +44,29 @@ bestünde auch keine Gefahr, dass ein Entwickler anhand seines bzw. ihres Keys u 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} diff --git a/dexes/acrodex.tex b/dexes/acrodex.tex index 5e1f11e..49b63c4 100644 --- a/dexes/acrodex.tex +++ b/dexes/acrodex.tex @@ -9,10 +9,10 @@ % % \acro{1P}[1P]{1Password} - \acro{MASA}[MASA]{Medienagenten Secret Authority} \acro{API}[API]{Application Programmer Interface} + \acro{MASA}[MASA]{Medienagenten Secret Authority} + \acro{YAML}[YAML]{Yet Another Markup Language} %\acroplural{CMS}[CMSe]{Content Management Systeme} % % \end{acronym} - diff --git a/dexes/glossarydex.tex b/dexes/glossarydex.tex index 3608383..b0dc5f1 100644 --- a/dexes/glossarydex.tex +++ b/dexes/glossarydex.tex @@ -5,9 +5,13 @@ \chapter{Glossar} \begin{description} - \item [Docker] \hfill \\ - Eine arrivierte Container-Engine für Anwendungsentwicklung. + \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-)Vault] \hfill \\ + Eine Kollektion an Secret-Einträgen in einem Passwort-Manager (1Password). \item [Ansible-Playbook/s] \hfill \\ Ansible-Playbooks sind Skripte, mit dem Ziel einen deklarierten Zustand herzustellen. \cite{bib:ansible} + \item [Docker] \hfill \\ + Eine arrivierte Container-Engine für Anwendungsentwicklung. \end{description} diff --git a/images/dev-stuff-python.png b/images/dev-stuff-python.png new file mode 100644 index 0000000..8f7e6bd Binary files /dev/null and b/images/dev-stuff-python.png differ diff --git a/images/masa-diagram.png b/images/masa-diagram.png new file mode 100644 index 0000000..35b2c3d Binary files /dev/null and b/images/masa-diagram.png differ diff --git a/main.pdf b/main.pdf index d3e16a7..b25451f 100644 Binary files a/main.pdf and b/main.pdf differ