apply mama feedback
This commit is contained in:
parent
df208d2dd7
commit
897ab23fda
SSH Key Fingerprint:
SHA256:hs2AZKjRTbd2kYg44u89rM19UT2LyBOpSbIShsdkkfg
@ -14,7 +14,7 @@ Notizen zu diesem Interview befinden sich im Anhang unter
|
||||
\fullref{app:stakeholder-interview}.
|
||||
|
||||
\section{Ergebnisse}
|
||||
Das Ergenis der Anforderungserfassung ist ein Lastenheft, das in constraints, funktionale und
|
||||
Das Ergebnis der Anforderungserfassung ist ein Lastenheft, das in constraints, funktionale und
|
||||
nicht-funktioniale Anforderungen unterteilt ist. Im Zuge des Interviews und diversen anderen, informalen Gespräche,
|
||||
hat sich der Autor ein tiefes Verständnis für das vorliegende Problem des Auftraggebers anggeignet.
|
||||
Das untenstehende Lastenheft wurde mit dem Stakeholder besprochen und bestätigt.
|
||||
@ -25,18 +25,18 @@ Das untenstehende Lastenheft wurde mit dem Stakeholder besprochen und bestätigt
|
||||
\begin{tabular}{|p{14cm}|}
|
||||
\hline
|
||||
\textbf{Funktionale Anforderungen} \\ \hline
|
||||
Entwickler*innen erhalten verschiedene Zugang zu verschiedenen \ac{1P}-Einträgen (Zugänge),
|
||||
Entwickler*innen erhalten verschiedene Zugänge zu verschiedenen \ac{1P}-Einträgen (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 Entwickler*innen einzeln zuweisbar sein. \\ \hline
|
||||
Nicht in der Konfugration gelistete Zugänge sollen bei Anwendung entfernt werden. \\ \hline
|
||||
\ac{1P}-Einträge sollen Entwicklern*innen einzeln zuweisbar sein. \\ \hline
|
||||
Nicht in der Konfiguration gelistete Zugänge sollen bei Anwendung entfernt werden. \\ \hline
|
||||
Ansible-Secrets müssen aus \ac{1P} dereferenziert werden können. \\ \hline
|
||||
Einträge sollen für Entwickler*innen einsehbar sein. \\ \hline
|
||||
\textbf{Nicht-funktionale Anforderungen} \\ \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
|
||||
Das System muss einfach zu pflegen sein. \\ \hline
|
||||
Die benötigte Zeit zur Ausführung der Anwendung soll angemessen lange sein. \\ \hline
|
||||
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
|
||||
|
||||
@ -14,7 +14,7 @@ All das gestaltet das Einbinden von externen Entwickler*innen, wie z.B. Freelanc
|
||||
\\
|
||||
\\
|
||||
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
|
||||
beilegen, unverschlüsselt einsichtig sind. Das macht es zu einem großen Sicherheitsrisiko und somit,
|
||||
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
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
%
|
||||
|
||||
\section{Zielsetzung}
|
||||
Ziel ist es, eine Umgebung zu schaffen, in der beliebigen Entwickler*innen bestimmte
|
||||
Ziel ist es, eine Umgebung zu schaffen, in der beliebigen Entwicklern*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 Entwickler*innen zugewiesen werden können.
|
||||
|
||||
@ -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 Administrator*innen und Entwickler*innen API-Keys für \ac{1P} erhalten.
|
||||
Entwickler*innen hätten mit ihren Keys bestimmte Leseberechtigungen $r$ und Administratoren
|
||||
Bei diesem Ansatz würden Administratoren*innen und Entwicklern*innen API-Keys für \ac{1P} erhalten.
|
||||
Entwickler*innen hätten mit ihren Keys bestimmte Leseberechtigungen $r$ und Administratoren*innen
|
||||
die Berechtigung $r$ zu verändern.
|
||||
|
||||
\begin{nicepic}
|
||||
@ -30,7 +30,7 @@ Der nächste Lösungsansatz befasst sich mit einer Abstraktionsebene: Der \ac{MA
|
||||
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*innen weiterzureichen.
|
||||
Die \ac{MASA} provisioniert eigene API-Keys an Entwickler*innen und vermermerkt serverseitig,
|
||||
Die \ac{MASA} provisioniert eigene API-Keys an Entwickler*innen und vermerkt serverseitig,
|
||||
welcher API-Key berechtigt ist, welche \ac{1P}-Einträge abzufragen.
|
||||
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
|
||||
@ -40,9 +40,9 @@ Um diesem Risikofaktor entgegenzuwirken würde der \ac{1P}-Key der \ac{MASA} ver
|
||||
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,
|
||||
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
|
||||
erhalten würde. Dieser Ansatz erlaubt weitreichende Flexibilität, da sämtliche Logik, die sich mit Berechtigungen
|
||||
beschäftigt, anwendungsfallspezifisch geplant und umgesetzt wäre.
|
||||
|
||||
\begin{nicepic}
|
||||
@ -53,8 +53,8 @@ beschäftigt, anwendungsfallspezifisch geplant und umgesetzt wäre.
|
||||
\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.
|
||||
Letztendlich entschied sich der Stakeholder gegen die Umsetzung der \ac{MASA}, da dieser Ansatz als 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 jede*n Entwickler*in $d$.
|
||||
@ -78,7 +78,8 @@ 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 Entwickler*innen des Partnerunternehmens.
|
||||
Einen API-Key zu erstellen, zu übermitteln und als Nutzer zu verorten ist kostspielig und umständlich.
|
||||
Ein \ac{1P}-Konto haben dem gegenüber viele externe Partner*innen des Partnerunternehmens bereits.
|
||||
\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 \\
|
||||
@ -94,7 +95,7 @@ Es wurde eine rudimentäre Architektur entworfen, die beschreibt, welche Kompone
|
||||
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 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.
|
||||
und auf welche nicht, übernimmt \textit{sync-dev-vault.py}. Die Funktionen der anderen Skripte ergeben sich in Gänze aus ihren Dateinamen.
|
||||
|
||||
\begin{nicepic}
|
||||
\includegraphics[width=1\textwidth]{images/config-file.png}
|
||||
@ -120,7 +121,7 @@ Die Funktionsweise des Programmes ist wie folgt:
|
||||
|
||||
|
||||
\subsubsection{Performanzprobleme und Optimierung}
|
||||
Eine Schwierigkeit, die sich im Rahmen der Umsetzung offenbart hat, ist, dass das \ac{1P}-CLI sehr langsam ist.
|
||||
Eine Schwierigkeit, die sich im Rahmen der Umsetzung offenbarte, ist, dass das \ac{1P}-CLI sehr langsam ist.
|
||||
Soll die Liste aller Einträge eines Vaults ausgelesen werden, dauert das nach Erfahrungen des Autors etwa eine Sekunde, da es sich hierbei um \emph{eine} Anfrage handelt.
|
||||
Diese Listenansicht zeigt jedoch nur begrenzte Informationen der Einträge.
|
||||
Soll ein bestimmtes Feld eines Eintrages (z.B. \enquote{Originale Eintrags-ID}) in Erfahrug gebracht werden, müssen alle Informationen \textit{eines} Eintrages
|
||||
@ -131,14 +132,16 @@ Das \ac{1P}-CLI kann zwar für Detail-Aufrufe mehrere Eintrags-IDs auf Standard-
|
||||
wie zehn Anfragen für jeweils einen Eintrag zu stellen.
|
||||
\\
|
||||
\\
|
||||
Die naive Herangehensweise, um einen Eintrag einer bestimmten originalen \ac{UUID} zu finden, ist es, jeden Eintrag auf dessen originale \ac{UUID} zu prüfen, bis der passende Eintrag gefunden wurde.
|
||||
Diese Lösungsweg hat eine Zeitkomplexität von $O(n^2)$.
|
||||
Eine spätere Ergänzung, um die programmatische Auslesung der Einträge einer bestimmten originalen \ac{UUID} in $O(n)$ anstatt $O(n^2)$ zu gewährleisten, ist die Unterhaltung von Mapping-Objekten in Entwickler*innen-Vaults.
|
||||
Je Entwickler*innen-Vault wird abschließend der Synchronisierung ein Mapping-Objekt erstellt.
|
||||
In der naiven Herangehensweise, um einen Eintrag einer bestimmten originalen \ac{UUID} zu finden,
|
||||
wird jeder Eintrag auf dessen originale \ac{UUID} geprüft, bis der passende Eintrag gefunden wurde.
|
||||
Dieser Lösungsweg hat für \emph{einen} Eintrag eine Zeitkomplexität von $O(n)$.
|
||||
Eine spätere Ergänzung, um die programmatische Auslesung \emph{eines} Eintrages einer bestimmten originalen \ac{UUID} in $O(1)$ anstatt $O(n)$ zu gewährleisten,
|
||||
ist die Unterhaltung von Mapping-Objekten in Entwickler*innen-Vaults.
|
||||
Je Entwickler*innen-Vault wird abschließend zur Synchronisierung ein Mapping-Objekt erstellt.
|
||||
Diese Mapping-Objekte halten die Informationen vorrätig, welche öffentliche \ac{1P}-\ac{UUID} zu welcher privaten \ac{1P}-\ac{UUID} gehört.
|
||||
Mit diesen Mapping-Objekten kann ein beliebiger Eintrag anhand einer öffentlichen \ac{UUID}
|
||||
binnen zwei Anfragen erfasst werden: Anfragen des Mapping-Objektes und Anfragen des privaten Objektes.
|
||||
Das entspricht einer Zeitkomplexität von $O(2n) = O(n)$.
|
||||
Das entspricht einer Zeitkomplexität von $O(2) = O(1)$.
|
||||
Desweiteren kann \ac{1P} Eintragsdaten lokal zwischenspeichern.
|
||||
Diese Option lässt sich mit dem Flag \textit{--cache} auf Leseoperationen anwenden
|
||||
und beschleunigt das Auslesen der angefragten Informationen, soweit diese im Cache existieren.
|
||||
@ -157,18 +160,18 @@ Wenn diese Vault-ID nun in der Liste der fest kodierten Nutzvault-IDs vorkommt,
|
||||
Somit ist gewährleistet, dass selbst bei einer fatalen Fehlkonfiguration kein Datenverlust entseht.
|
||||
|
||||
\section{Integration in Ansible}
|
||||
Eine Anfordergung beschreibt, dass \ac{1P}-Einträge von Entwickler*innen innerhalb von Ansible-Playbooks
|
||||
Eine Anfordergung beschreibt, dass \ac{1P}-Einträge von Entwicklern*innen innerhalb von Ansible-Playbooks
|
||||
dereferenziert und verwendet werden können.
|
||||
|
||||
\ac{1P} unterstützt nativ das Ersetzen von \ac{1P}-Referenzen in Dateien durch Secrets.
|
||||
Diese Technik nennt sich \enquote{\ac{1PSA}}.
|
||||
Diese Technologie ist jedoch nicht für die hier vorliegende Aufgabenstellung verwertbar, da die dem zugrunde liegende
|
||||
Berechtigungsverwaltung auf Vault-Basis steht. Entweder hat ein*e Entwickler*in Zugriff auf einen gesamten Vault, oder er*sie keinen Zugriff auf den gesamten Vault.
|
||||
Eine feingranularere Steuerung ist hier nicht möglich, jedoch für die hier gegebenen Anforderungen nötig. \cite{bib:1password-secrets-automation}
|
||||
Berechtigungsverwaltung auf Vault-Basis steht. Entweder hat ein*e Entwickler*in Zugriff auf einen gesamten Vault, oder er*sie hat keinen Zugriff auf den gesamten Vault.
|
||||
Eine feinere Steuerung ist hier nicht möglich, jedoch für die hier gegebenen Anforderungen nötig. \cite{bib:1password-secrets-automation}
|
||||
\ac{1PSA} erfasst \acp{UUID} und ist daher mit dem Konzept von Entwickler*innen-Vaults inkompatibel, da
|
||||
Entwickler*innen hierbei eigene Kopien der originalen Einträge führen, die jeweils eigene \acp{UUID} haben.
|
||||
Externe Entwickler*innen haben somit keinen Zugriff auf die originalen, öffentlichen \acp{UUID} und die privaten \acp{UUID}, die im Entwickler*innen-Vault
|
||||
vorhanden sind, gelten jeweils nur für ein*e Entwickler*in. Das erfordert eine maßgeschneiderte, programmatische Lösung:
|
||||
vorhanden sind, gelten jeweils nur für eine*n Entwickler*in. Das erfordert eine maßgeschneiderte, programmatische Lösung:
|
||||
|
||||
\begin{nicepic}
|
||||
\includegraphics[width=0.75\textwidth]{images/docker-ansible-structure.png}
|
||||
@ -188,7 +191,7 @@ Ab hier wird die Nutzergruppe \enquote{Entwickler*innen} in zwei Untergruppen st
|
||||
Da diese Entwickler*innen keinen Entwickler*innen-Vault haben, müssen sie direkt auf diese notierte, öffentliche \ac{UUID} zugreifen.
|
||||
\item [Externe Entwickler*innen] \hfill \\
|
||||
Externe Entwickler*innen verfügen über einen Entwickler*innen-Vault, nicht jedoch über direkten Zugriff auf die vermerkte, öffentliche \ac{UUID}.
|
||||
Falls der*die jeweilige Entwickler*in Zugriff auf einen verlinkten Eintrag hat, dann nur auf eine Kopie des Eintrages in dessen*deren jeweiligen Entwickler*innen-Vaults.
|
||||
Falls der*die jeweilige Entwickler*in Zugriff auf einen verlinkten Eintrag hat, dann nur auf eine Kopie des Eintrages in dessen*deren jeweiligen Entwickler*innen-Vault.
|
||||
Diese Kopie hat eine andere \ac{UUID} als die, die in der Host-Konfiguration steht. Sie ist ja auf technischer Ebene ein anderer Eintrag, nur mit identischem Inhalt.
|
||||
Die in den Host-Konfigurationen vermerkten, öffentlichen \acp{UUID} müssen also zunächst in eine private, sich im Entwickler*innen-Vault befindliche, \ac{UUID} übersetzt werden.
|
||||
\end{description}
|
||||
@ -200,8 +203,12 @@ Texttransformator und kann in Ansible verwendet werden.
|
||||
\\
|
||||
\texttt{\{\{\ \enquote{hello world} | uppercase \}\}}.\\
|
||||
\cite{bib:ansible-filter-plugins}
|
||||
\\
|
||||
\\
|
||||
Dieses Beispiel führt das \enquote{uppercase}-Filtermodul an.
|
||||
Ein Beispiel mit dem im Rahmen dieser Ausarbeitung bereitgestellten Filtermodul würde so aussehen:\\
|
||||
Ein Beispiel mit dem im Rahmen dieser Ausarbeitung bereitgestellten Filtermodul würde so aussehen:
|
||||
\\
|
||||
\\
|
||||
\texttt{\{\{ smtp.password | resolve\_1p\_secret \}\}}.
|
||||
|
||||
\begin{nicepic}
|
||||
@ -264,7 +271,7 @@ Diese beschäftigen sich damit, zu limitieren, wie oft das \ac{1P}-CLI angefragt
|
||||
Anstatt das Mapping-Objekt für jedes angefragte Secret erneut abzufragen, könnte es zwischengespeichert werden.
|
||||
\item [Ganze Einträge zwischenspeichern] \hfill \\
|
||||
Für den Fall, dass ein Eintrag mehrach angefragt wird, könnte ein einmal angefragter Eintrag zwischengespeichert werden.
|
||||
Würden mehrere Felder eines Eintrages angefragt werden (z.B. \textit{=Host, Port, Benutzername, Passwort, Name}), so müsse der gesamte Eintrag nur ein mal angefragt werden.
|
||||
Würden mehrere Felder eines Eintrages angefragt werden (z.B. \textit{=Host, Port, Benutzername, Passwort, Name}), so müsste der gesamte Eintrag nur ein mal angefragt werden.
|
||||
\end{description}
|
||||
|
||||
All diese Ansätze erfordern es Daten zwischenzuspeichern. Filtermodule haben allerdings keinen persistenten Arbeitsspeicher über verschiedene Aufrufe hinaus.
|
||||
|
||||
@ -14,7 +14,7 @@
|
||||
\item [Ansible-Role] \hfill \\
|
||||
Eine Abfolge von definierten Schritten, die von Ansible-Playbooks ausgeführt werden. Eine solche Role könnte z.B. einen Server buchen, konfigurieren und verwendungsfertig bereitstellen.
|
||||
\item [Detailansicht / Detailaufruf] \hfill \\
|
||||
Eine Anfrage, \emph{ein} Objekt oder \emph{einen} Eintrag zurückgibt oder manipuliert.
|
||||
Eine Anfrage, die \emph{ein} Objekt oder \emph{einen} Eintrag zurückgibt oder manipuliert.
|
||||
\item [Docker] \hfill \\
|
||||
Eine arrivierte Container-Engine für Anwendungsentwicklung.
|
||||
\item [Entwickler*innen-Vault] \hfill \\
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user