From 89c871f9cbe304b627750f5eb2f7cf0040502ef4 Mon Sep 17 00:00:00 2001 From: Leon Etienne Date: Fri, 31 Jan 2025 02:38:57 +0100 Subject: [PATCH] do ze gender --- chapters/anforderungen.tex | 4 +- chapters/einleitung/problemstellung.tex | 13 +++---- chapters/einleitung/zielsetzung.tex | 6 +-- chapters/grundlagen/main.tex | 3 +- chapters/technische-umsetzung/main.tex | 52 ++++++++++++------------- 5 files changed, 38 insertions(+), 40 deletions(-) diff --git a/chapters/anforderungen.tex b/chapters/anforderungen.tex index 7c3caa8..ab0dd7b 100644 --- a/chapters/anforderungen.tex +++ b/chapters/anforderungen.tex @@ -23,14 +23,14 @@ nicht-funktioniale Anforderungen zu unterteilen ist. \begin{tabular}{|p{14cm}|} \hline \textbf{Funktionale Anforderungen} \\ \hline - Entwickler erhalten verschiedene Zugänge, definiert in einer YAML-Datei. \\ \hline + Entwickler*innen erhalten verschiedene Zugänge, definiert in einer YAML-Datei. \\ \hline 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 \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 Berechtigungen von Entwickler*innen verwalten. \\ \hline 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 diff --git a/chapters/einleitung/problemstellung.tex b/chapters/einleitung/problemstellung.tex index df5e557..019ca41 100644 --- a/chapters/einleitung/problemstellung.tex +++ b/chapters/einleitung/problemstellung.tex @@ -4,19 +4,18 @@ \section{Problemstellung} In der Arbeitsumgebung des Partnerunternehmens besteht zum Zeitpunkt der Themenfindung der hier beleuchteten Arbeit kein -Management für Secrets und Logindaten zwischen Entwicklern. Logindaten zu den Projekten des Unternehmens liegen schlicht in einem \ac{1P}-Vault. -\ac{1P} ist der vom Unternehmen verwendete Passwortmanager. Auf diesen Vault haben sämtliche interne Entwickler Zugriff, jedoch keine externen Entwickler. -Das ist so, weil anderenfalls dem externen Entwickler Lesezugriff auf sämtliche Einträge dieses Vaults gegeben werden müssten. +Management für Secrets und Logindaten zwischen Entwickler*innenn. Logindaten zu den Projekten des Unternehmens liegen schlicht in einem \ac{1P}-Vault. +\ac{1P} ist der vom Unternehmen verwendete Passwortmanager. Auf diesen Vault haben sämtliche internen Entwickler*innen Zugriff, jedoch keine externen Entwickler*innen. +Das ist so, weil anderenfalls dLesezugriff auf sämtliche Einträge dieses Vaults gegeben werden müssten. \ac{1P} unterstützt keine Freigaben einzelner Einträge an andere Nutzer, ohne diese Einträge in einen eigenen Vault zu kopieren. Würden diese manuell in einen eigenen Vault kopiert werden, müssten diese Einträge fortan redundant gepflegt werden. Das ist eine Fehlerquelle, die zu asynchronen Einträgen führt. Außerdem ist das ein großer Arbeitsaufwand. -All das gestaltet das Einbinden von externen Entwicklern, wie z.B. Freelancern, schwer. +All das gestaltet das Einbinden von externen Entwickler*innen, wie z.B. Freelancer*innen, schwer. \\ \\ Ein weiteres Problem ist, dass Secrets in Konfigurationsdateien, die firmeninternen Ansible-Scripten beilegen, unverschlüsselt einsichtig sind. Das macht es zu einem großen Sicherheitsrisiko und somit -impraktikabel externen Entwicklern Zugriff auf dieses Ansible-Repository zu gewähren. +inpraktikabel externen Entwickler*innen Zugriff auf dieses Ansible-Repository zu gewähren. Dieses Ansible-Repository ist jedoch zwingend erforderlich, um eine Entwicklungsungebung für Firmenprojekte auf dem lokalen Rechner zu schaffen. Auch hier sind Lösungen für externe -Entwickler zumeist unschöne Workarounds. - +Entwickler*innen zumeist unschöne Workarounds. diff --git a/chapters/einleitung/zielsetzung.tex b/chapters/einleitung/zielsetzung.tex index f3fb75d..2340cb6 100644 --- a/chapters/einleitung/zielsetzung.tex +++ b/chapters/einleitung/zielsetzung.tex @@ -3,12 +3,12 @@ % \section{Zielsetzung} -Ziel ist es, eine Umgebung zu schaffen, in der beliebigen Entwicklern bestimmte +Ziel ist es, eine Umgebung zu schaffen, in der beliebigen Entwickler*innen bestimmte \ac{1P}-Einträge zugewiesen werden können. Der Pflegeaufwand sollte hierbei überschaubar bleiben. -Das heisst, dass z.B. ganze Gruppen von Einträgen Entwicklern zugewiesen werden können. +Das heisst, dass z.B. ganze Gruppen von Einträgen Entwickler*innen zugewiesen werden können. Wenn z.B. einem Projekt viele Einträge zugeordnet sind, sollten diese idealerweise mit einer einzigen Configzeile -einem Entwickler zugeordnet werden können. +einem*r Entwickler*in zugeordnet werden können. Außerdem sollte eine Möglichkeit ausgearbeitet werden, um \ac{1P}-Einträge in Ansible auszulesen, damit keine Secrets mehr in den beiliegenden Konfigurationsdateien stehen, die das Freigeben dieser zu einem Sicherheitsproblem machen. diff --git a/chapters/grundlagen/main.tex b/chapters/grundlagen/main.tex index 76b568e..0752f63 100644 --- a/chapters/grundlagen/main.tex +++ b/chapters/grundlagen/main.tex @@ -19,7 +19,7 @@ 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 +Die lokalen Arbeitsumgebungen der Entwickler*innen liegen großteils außerhalb des Firmennetzwerkes, da diese Entwickler*innen oft oder ausschließlich im mobilen- bzw, Homeoffice arbeiten. Ein Firmen-VPN-Netz existiert nicht und ist auch nicht erwünscht. \section{1Password} @@ -33,4 +33,3 @@ im behandelten System herzustellen. \cite{bib:ansible} Ein Administrator definiert also nicht die erforderlichen Schritte, um einen Zustand $z$ zu erreichen, sondern lediglich $z$ selbst. Ansible kann über speziell gefertigte Python-Module um Schnittstellen erweitert werden. - diff --git a/chapters/technische-umsetzung/main.tex b/chapters/technische-umsetzung/main.tex index 8a1aaa0..185795b 100644 --- a/chapters/technische-umsetzung/main.tex +++ b/chapters/technische-umsetzung/main.tex @@ -11,8 +11,8 @@ Ein Artefakt des Brainstormings ist eine Mind-Map, die unter \fullref{app:ideens \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. -Entwickler hätten mit ihren Keys bestimmte Leseberechtigungen $r$ und Administratoren +Bei diesem Ansatz würden Administrator*innen und Entwickler*innen API-Keys für \ac{1P} erhalten. +Entwickler*innen hätten mit ihren Keys bestimmte Leseberechtigungen $r$ und Administratoren die Berechtigung $r$ zu verändern. \begin{nicepic} @@ -29,21 +29,21 @@ von API-Key-Berechtigungen nicht erlaubt. 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, +aus dem \ac{1P}-Vault des Partnerunternehmens abzufragen und an Entwickler*innen weiterzureichen. +Die \ac{MASA} provisioniert eigene API-Keys an Entwickler*innen 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 +Der API-Key könnte grundlegende Informationen wie zum Beispiel Entwickler*innennamen 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. +\ac{MASA} würde nur einen Teil des Entschlüsselungs-Keys vorrätig halten. Der andere Teil wäre in jedem Entwickler*innen-Key +eingebettet. Dadurch wäre gewährleistet, dass ein*e Angreifer*in, selbst bei sehr weitreichendem Zugriff +in die \ac{MASA}, nicht auf das Innere des Passwortmanagers zugreifen könne, da die \ac{MASA} dazu selbstständig +gar nicht im Stande wäre. Da Entwickler*innen lediglich ein Schlüsselfragment des Verschlüsselungs-Schlüssels +in ihrem Key eingebettet hätten, der einen serverseitigen Schlüssel der \ac{MASA} zum auslesen benötigt, +bestünde auch keine Gefahr, dass ein*e Entwickler*in anhand seines bzw. ihres Keys ungeschützten Zugang zum Passwortmanager +erhalten würde. Dieser Ansatz erlaubt für weitreichende Flexibilität, da sämtliche Logik, die sich mit Berechtigungen +beschäftigt, anwendungsfallspezifisch geplant und umgesetzt wäre. \begin{nicepic} \includegraphics[width=0.75\textwidth]{images/masa-diagram.png} @@ -57,10 +57,10 @@ Letztendlich entschied sich der Stakeholder gegen die Umsetzung der \ac{MASA}, d 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$. +Der letzte Lösungsansatz befasst sich mit dem Erstellen dedizierter Vaults für jede*n Entwickler*in $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. +Diese Einträge können über feste Eintrags-IDs und über Regex bezogen auf die Eingrags-Titel einem/r Entwickler*in vorgesehen werden. \begin{nicepic} \includegraphics[width=0.75\textwidth]{images/dev-stuff-python.png} @@ -69,7 +69,7 @@ Diese Einträge können über feste Eintrags-IDs und über Regex bezogen auf die \label{fig:ansatz-3-mit-python} \end{nicepic} -Letztendlich entschied sich der Stakeholder für Ansatz 3, da er ihm Kostengünstig und Aursreichend erschien. +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 @@ -78,11 +78,11 @@ 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. + Einen API-Key zu erstellen und zu übermitteln ist kostenspielig und umständlich. Ein \ac{1P}-Konto haben dem gegenüber bereits alle Entwickler*innen 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. + Da über die CLI-Methode der Zugriff auf die Entwickler*innen-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} @@ -90,10 +90,10 @@ Die CLI-API der Desktop-Anwendung zu verwenden, würde drei Probleme lösen: 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, +Es wurde eine rudimentäre Architektur entworfen, die beschreibt, welche Komponente des Werkzeuges aus welchen kleineren Komponenten besteht. +Am unteren Ende dieses Aggregatbaumes 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. Das Erfassen, auf welchen Eintrag welcher Entwickler Zugriff hat, +Hierbei handelt es sich nur um Lese, Erstell- und Löschvorgänge. Das Erfassen, auf welchen Eintrag welche*r Entwickler*in Zugriff hat, und auf welche nicht, übernimmt \textit{sync-dev-vault.py}. Die Funktionen der andere Skripte ergeben sich in Gänze aus ihren Dateinamen. \begin{nicepic} @@ -111,14 +111,14 @@ und auf welche nicht, übernimmt \textit{sync-dev-vault.py}. Die Funktionen der \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. +Die Konfigurationsdatei definiert Zielvaults, nach ihren kryptsichen IDs. Anhand dieser IDs sieht ein*e Administrator*in keine Vaultnamen. +Wenn nun aus etwaigen 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 in Form von Datenverlust. \subsubsection{Sicherheitsvorkehrungen} -Um das zu verhindern wurde eine Liste mit wichtigen Vault-IDs fest einkodiert. +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. +Wenn diese Vault-ID nun in der Liste der fest kodierten 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}