diff --git a/chapters/anforderungen.tex b/chapters/anforderungen.tex index 31cf00d..7c3caa8 100644 --- a/chapters/anforderungen.tex +++ b/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} diff --git a/chapters/technische-umsetzung/main.tex b/chapters/technische-umsetzung/main.tex index e259c08..38dbef3 100644 --- a/chapters/technische-umsetzung/main.tex +++ b/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} diff --git a/dexes/acrodex.tex b/dexes/acrodex.tex index 49b63c4..94769f6 100644 --- a/dexes/acrodex.tex +++ b/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} diff --git a/dexes/glossarydex.tex b/dexes/glossarydex.tex index 3bdcdce..2aa3da4 100644 --- a/dexes/glossarydex.tex +++ b/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 \\ diff --git a/dexes/literature.bib b/dexes/literature.bib index ce18319..2ff8675 100644 --- a/dexes/literature.bib +++ b/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} +} diff --git a/images/program-structure.png b/images/program-structure.png new file mode 100644 index 0000000..3deff1a Binary files /dev/null and b/images/program-structure.png differ diff --git a/main.pdf b/main.pdf index bfa0d3e..147d1cd 100644 Binary files a/main.pdf and b/main.pdf differ