75 lines
4.1 KiB
TeX
75 lines
4.1 KiB
TeX
%
|
|
% Chapter: Technische Umsetzung
|
|
%
|
|
|
|
\chapter{Technische Umsetzung}
|
|
\section{Berechtigungsverwaltung}
|
|
\subsection*{Ausarbeitung der Herangehensweise}
|
|
\subsubsection*{Ansatz 1}
|
|
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.
|
|
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
|
|
die Berechtigung $r$ zu verändern.
|
|
|
|
\begin{nicepic}
|
|
\includegraphics[width=0.75\textwidth]{images/dev-stuff-via-api-keys.png}
|
|
\captionof{figure}{Relationsdiagramm: Ansatz 1 | 1Password-API}
|
|
\caption*{Quelle: Eigene Darstellung}
|
|
\label{fig:ansatz-1-mit-api-keys}
|
|
\end{nicepic}
|
|
|
|
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}
|
|
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,
|
|
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
|
|
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.
|
|
|
|
\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}
|
|
|
|
\section{Integration in Ansible}
|
|
|