do ze gender
This commit is contained in:
parent
c9bba59d43
commit
89c871f9cb
SSH Key Fingerprint:
SHA256:hs2AZKjRTbd2kYg44u89rM19UT2LyBOpSbIShsdkkfg
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user