feedback von dem mlemmer
This commit is contained in:
parent
df86b1cf95
commit
8a3210bc3c
@ -2,7 +2,7 @@
|
||||
\label{app:ideensammlung}
|
||||
|
||||
\begin{nicepic}
|
||||
\includegraphics[width=1\textwidth]{images/ideensammlung.jpg}
|
||||
\includegraphics[width=0.75\textwidth]{images/ideensammlung.jpg}
|
||||
\captionof{figure}{Ideensammlung}
|
||||
\caption*{Quelle: Eigene Darstellung}
|
||||
\label{fig:ideensammlung}
|
||||
|
@ -2,8 +2,9 @@
|
||||
\label{app:old-relation-diagram}
|
||||
|
||||
\begin{nicepic}
|
||||
\includegraphics[width=0.9\textwidth]{images/old-usage-diagram.jpg}
|
||||
\includegraphics[width=0.75\textwidth]{images/old-usage-diagram.jpg}
|
||||
\captionof{figure}{Relationsdiagramm: (Überholt) Relationsdiagramm}
|
||||
\caption*{Quelle: Eigene Darstellung}
|
||||
\label{fig:relationsdiagramm-old}
|
||||
\end{nicepic}
|
||||
|
||||
|
@ -16,7 +16,7 @@ Notizen zu diesem Interview befinden sich im Anhang unter
|
||||
\section{Ergebnisse}
|
||||
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.
|
||||
hat sich der Autor ein tiefes Verständnis für das vorliegende Problem des Auftraggebers angeignet.
|
||||
Das untenstehende Lastenheft wurde mit dem Stakeholder besprochen und bestätigt.
|
||||
|
||||
\begin{table}[ht]
|
||||
|
@ -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
|
||||
|
@ -12,7 +12,7 @@ Das Synchronisations-Werkzeug verweigert Anfragen, die zur Löschung von origina
|
||||
\\
|
||||
\\
|
||||
Ebenso ist Teil des Ergebnisses ein Ansible-Filtermodul, das in der Lage ist, unsensible \ac{1P}-Referenzen
|
||||
in Host-Konfigurationsdateien aus \ac{1P} zu derereferenzieren, sowohl als interne*r Entwickler*in ohne Entwickler*innen-Vault,
|
||||
in Host-Konfigurationsdateien aus \ac{1P} zu dereferenzieren, sowohl als interne*r Entwickler*in ohne Entwickler*innen-Vault,
|
||||
als auch als externe*r Entwickler*in mit\\
|
||||
Entwickler*innen-Vault. Das geschiet in einer IT-sicherheitstechnich unbedenklichen
|
||||
und performanten Art- und Weise.
|
||||
@ -23,7 +23,7 @@ Nach Vorstellung der erarbeiteten Ergebnisse vor dem Stakeholder zeigt sich sich
|
||||
pragmatische Korrektheit des Produktes.
|
||||
|
||||
Die hier geschaffene Technologie bringt dem Partnerunternehmen zweierlei Mehrwert:
|
||||
Einerseits können \ac{1P}-Berechtigungen nun ohne weiteres beschränkt an Praktikant*innen, neu einngestellte und externe Entwickler*innen
|
||||
Einerseits können \ac{1P}-Berechtigungen nun ohne weiteres beschränkt an Praktikant*innen, neu eingestellte und externe Entwickler*innen
|
||||
vergeben werden. Darüber hinaus bereitet diese Technologie den Weg für das Partnerunternehmen,
|
||||
ihr Docker-Ansible-Repository so anzupassen, dass es keine Klartext-Secrets mehr beinhaltet.
|
||||
Das erlaubt dem Partnerunternehmen diese Toolbox mit externen Entwickler*innen und Agenturen zu teilen
|
||||
|
@ -70,7 +70,7 @@ Diese Einträge können über feste Eintrags-IDs und über Regex bezogen auf die
|
||||
\label{fig:ansatz-3-mit-python}
|
||||
\end{nicepic}
|
||||
|
||||
Nach Betrachtung der diversen Ansätze entschied sich der Stakeholder für Ansatz 3, da er ihm kostengünstig und aursreichend erschien.
|
||||
Nach Betrachtung der diversen Ansätze entschied sich der Stakeholder für Ansatz 3, da er ihm kostengünstig und ausreichend erschien.
|
||||
|
||||
\subsection{Kodierung}
|
||||
Um den vom Stakeholder ausgewählten Ansatz 3 wie geplant umzusetzen, wurden zunächst
|
||||
@ -150,7 +150,7 @@ Auf Unix-ähnlichen Betriebssystemen ist dieses Verhalten
|
||||
standardmäßig aktiviert. \cite{bib:1password-cli-caching}
|
||||
|
||||
\subsubsection{Sicherheitsbedenken}
|
||||
Die Konfigurationsdatei definiert Entwickler*innen-Vaults, über ihre \acp{UUID}. In diesen IDs sieht ein*e Administrator*in keine Vaultnamen. Diese sind nicht sprechend.
|
||||
Die Konfigurationsdatei definiert Entwickler*innen-Vaults über ihre \acp{UUID}. In diesen IDs sieht ein*e Administrator*in keine Vaultnamen. Diese sind nicht sprechend.
|
||||
Wenn nun aus etwaigen Gründen dort die \ac{UUID} 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.
|
||||
|
||||
@ -223,7 +223,7 @@ Ein Beispiel mit dem im Rahmen dieser Ausarbeitung bereitgestellten Filtermodul
|
||||
\end{nicepic}
|
||||
|
||||
\subsection{Akzeptierte Formate}
|
||||
Das Filtermodul akzeptiert mehrere, verschiedene Eingabeformate und ist rückwärtskompatibil.
|
||||
Das Filtermodul akzeptiert mehrere, verschiedene Eingabeformate und ist rückwärtskompatibel.
|
||||
|
||||
\subsubsection*{Kein erkanntes Format}
|
||||
Wird kein bekanntes Format erkannt, wird der Wert unverändert zurückgegeben. Das ermöglicht Rückwärtskompatibilät,
|
||||
@ -279,7 +279,7 @@ Diese beschäftigen sich damit, zu limitieren, wie oft das \ac{1P}-CLI angefragt
|
||||
\end{description}
|
||||
|
||||
All diese Ansätze erfordern es Daten zwischenzuspeichern. Filtermodule haben allerdings keinen persistenten Arbeitsspeicher über verschiedene Aufrufe hinaus.
|
||||
E.g. nach jedem angefragten Secret, verliert er seinen internen Zustand.
|
||||
Also nach jedem angefragten Secret verliert das Filtermodul seinen Zustand.
|
||||
Daher muss dieses zwischengespeichert in einer Datei stattfinden. Hierfür wird eine Tempdatei über Pythons \textit{tempfile.gettempdir()}-Funktion ermittelt.
|
||||
Diese Zwischenspeicher beinhalten die vom \ac{1P}-CLI zurückgegebenen Informationen.
|
||||
|
||||
@ -319,7 +319,7 @@ Dieser Prozess würde durch diese Vorkehrung so aussehen:
|
||||
Durch die Implementation des Mapping-Zwischenspeichers, wird die Ausführzeit von 17 Sekunden auf acht Sekunden reduziert.
|
||||
|
||||
\subsubsection{Eintrags-Zwischenspeicher}
|
||||
Wird ein Eintrag von \ac{1P} angefragt, so soll das Filtermodul diessen lokal zwischengespeichern.
|
||||
Wird ein Eintrag von \ac{1P} angefragt, so soll das Filtermodul diesen lokal zwischenspeichern.
|
||||
Das stellt ein Problem dar, sobald der Eintrag
|
||||
im Entwickler*innen-Vault manuell verändert wird. Das ist jedoch nicht angedacht.
|
||||
Die Entwickler*innen sollten keine Schreibberechtigung auf ihren Vault haben.
|
||||
@ -345,6 +345,6 @@ Durch das Implementieren des Eintrags-Zwischenspeichers wird die Ausführzeit vo
|
||||
\end{table}
|
||||
|
||||
\subsubsection{Sicherheit}
|
||||
Um zu vermeiden, dass sensible Daten, wie zum Beispiel die Secrets in den Eintrags-Daten des Passwortmanagers im Klartext im Zwischenspeicher, für viele Prozesse lesbar, gespeichert werden,
|
||||
Um zu vermeiden, dass sensible Daten, wie zum Beispiel die Secrets in den Eintragsdaten des Passwortmanagers im Klartext im Zwischenspeicher, für viele Prozesse lesbar, gespeichert werden,
|
||||
werden diese in der Schreib- und Lesefunktion mit AES-256 verschlüsselt.
|
||||
Die Wahl fällt auf AES-256, weil es keine bekannten Angriffe gegen AES-256 gibt, die wesentlich effektiver sind als generische Angriffe gegen Blockchiffren. \cite{bib:BSI-TR-02102-1-2024}
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
\begin{description}
|
||||
\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.
|
||||
Eine Gruppierung an Daten, die einen Login ermöglichen. Z.B. $(\text{Nutzername},\text{Passwort})$. Eine solche Struktur kann bei \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 \\
|
||||
@ -21,13 +21,13 @@
|
||||
Ein 1P-Vault, in dem die Kopien bzw. Referenzen auf Einträge des Partnerunternehmens verortet sind. Hier liegen nur Kopien bzw. Referenzen!
|
||||
Der Sinn eines solchen Vaultes ist es, Entwickler*innen beschränkten Lesezugriff auf Daten der Nutzvaults zu gewähren.
|
||||
\item [Jinja-Templating-Engine] \hfill \\
|
||||
Eine Templating Engine, die das Jina-Format verwendet. Ansible verwendet eine Jinja-Templating-Engine.
|
||||
Eine Templating Engine, die das Jinja-Format verwendet. Ansible verwendet eine Jinja-Templating-Engine.
|
||||
\item [Listenansicht / Listenaufruf] \hfill \\
|
||||
Eine Anfrage, die eine Liste von Objekten oder Einträgen zurückgibt.
|
||||
\item [Nutzvault] \hfill \\
|
||||
Ein 1P-Vault, in dem die originalen Einträge des Partnerunternehmens verortet sind. Hier liegen keine Kopien, sondern Originale!
|
||||
\item [Öffentliche 1P-UUID] \hfill \\
|
||||
Die 1P-UUID, die zu einem originalen Eintrag gehört, und nicht zu einer Referenz.
|
||||
Die 1P-UUID, die zu einem originalen Eintrag gehört und nicht zu einer Referenz.
|
||||
Externe Entwickler*innen haben also keinen direkten Zugriff auf einen solchen Eintrag, sondern müssen stattdessen eine Referenz auf diesen Eintrag verwenden.
|
||||
Eine solche UUID kann beispielsweise in Ansible-Konfigurationdateien stehen
|
||||
und von jedem*r Entwickler*in verwendet werden.
|
||||
|
Loading…
x
Reference in New Issue
Block a user