selbst probelesen

appendix/ideensammlung.tex

@@ -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}

appendix/old-relation-diagram.tex

@@ -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}
+

chapters/anforderungen.tex

@@ -7,16 +7,15 @@
 \section{Anforderungserfassung}
 Obwohl bereits vor Beginn des Projektes einige Anforderungen bekannt sind,
 müssen manche Details nachträglich in Erfahrung gebracht werden.
-Hierfür wurde ein informales Interview mit dem Stakeholder durchgeführt.
-Im Rahmen dieses Interviews wurden vorbereitete Fragen gestellt, dem Stakeholder aber auch die Möglichkeit
-gegeben frei heraus zu sprechen und Wünsche zu äußern.
-Notizen zu diesem Interview befinden sich im Anhang unter
+Hierfür wurde ein informelles Interview mit dem Stakeholder durchgeführt.
+Im Rahmen dieses Interviews wurde frei gesprochen. 
+Eine Mitschrift dieses Interviews befinden sich im Anhang unter
 \fullref{app:stakeholder-interview}.
 
 \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.
+Das Ergebnis der Anforderungserfassung ist ein Lastenheft, das in Constraints, funktionale und
+nicht-funktioniale Anforderungen unterteilt ist. Im Zuge des Interviews und diversen anderen, ad-hoc geführten Gesprächen,
+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]
@@ -27,7 +26,7 @@ Das untenstehende Lastenheft wurde mit dem Stakeholder besprochen und bestätigt
         \textbf{Funktionale Anforderungen} \\ \hline
         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
+        Wildcard-Matching auf den \ac{1P}-Eintragstitel. \\ \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
@@ -38,7 +37,7 @@ Das untenstehende Lastenheft wurde mit dem Stakeholder besprochen und bestätigt
         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
+        der zugrunde liegenden \ac{1P}-Einträge führen könnten.\\ \hline
         \textbf{Constraints} \\ \hline
         Nutzung von \ac{1P} ist zwingend erforderlich. \\ \hline
         Die Übermittlung der Secrets muss über das Internet erfolgen. \\ \hline

chapters/ausblick.tex

@@ -10,7 +10,7 @@
 Auf diese Umsetzung aufbauend sollten die bestehenden Ansible-Roles im Docker-Ansible-Repository
 des Partneruntehmens so angepasst werden, dass diese das \textit{resolve\_1p\_secret} Filtermodul verwenden.
 Ebenso sollte das bestehende Inventar an Host-Konfigurationsdateien migriert werden, sodass diese keine Klartext-Secrets mehr beinhalten,
-sondern diese nach \ac{1P} verschoben werden und die Host-Konfigurationsdateien lediglich eine IT-sicherheitstechnisch unbedenkliche Referenz auf \ac{1P}-Einträge
+sondern diese nach \ac{1P} ausgelagert werden und die Host-Konfigurationsdateien lediglich eine IT-sicherheitstechnisch unbedenkliche Referenz auf \ac{1P}-Einträge
 aufweisen.
 
 \endgroup

chapters/einleitung/methodik.tex

@@ -7,5 +7,5 @@ Einige Anforderungen sind bereits im Voraus definiert.
 Weiterführende Anforderungen werden im Rahmen einer Anforderungserfassung ermittelt.
 Anschließend werden verschiedene Lösungsansätze betrachtet und auf Tauglichkeit geprüft.
 Nachdem ein akzeptabler Lösungsweg gefunden ist, wird dieser umgesetzt.
-Abschließend wird der Erfolg des Unterfanges evaluiert und mögliche, auf dieses Projekt aufbauende Arbeiten in Ausblick gestellt.
+Abschließend wird der Erfolg des Unterfangens evaluiert und mögliche, auf dieses Projekt aufbauende.
 

chapters/einleitung/problemstellung.tex

@@ -4,7 +4,7 @@
 
 \section{Problemstellung}
 In der Arbeitsumgebung des Partnerunternehmens besteht zum Zeitpunkt der Themenfindung der hier beleuchteten Arbeit kein
-Management für Secrets und Logindaten zwischen Entwickler*innen. Logindaten zu den Projekten des Unternehmens liegen schlicht in einem \ac{1P}-Vault.
+Management für Secrets und Logindaten zwischen Entwickler*innen. Logindaten zu den Projekten des Unternehmens liegen in einem großen \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.
 Der Grund dafür ist, dass anderenfalls Lesezugriff 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.
@@ -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

chapters/evaluation-fazit.tex

@@ -8,12 +8,12 @@ ist ein Python-Projekt, das in der Lage ist, anhand einer Berechtigungs-Konfigur
 \ac{1P}-Einträge in Entwickler*innen-Vaults zu kopieren, zu löschen und deren Referenz zu den originalen Einträgen zu wahren.
 Diese Berechtigungs-Konfigurationsdatei unterstützt das Erfassen von Berechtigungen über Wildcard-Matching sowie über einzelne
 \ac{UUID}-Zuweisungen. Diese Einträge können Entwickler*innen anschließend in der \ac{1P}-GUI-Anwendung einsehen.\\
-Das Synchronisations-Werkzeug verweigert Anfragen, die zur Löschung von originalen Einträgen führen könnte.
+Das Synchronisations-Werkzeug verweigert Anfragen, die zur Löschung von originalen Einträgen führen könnten.
 \\
 \\
 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,
-als auch als externe*r Entwickler*in mit\\
+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.
 \\
@@ -21,9 +21,8 @@ und performanten Art- und Weise.
 Hiermit ist das in \fullref{tbl:lastenheft} definierte Lastenheft des Stakeholders in Gänze erfüllt.
 Nach Vorstellung der erarbeiteten Ergebnisse vor dem Stakeholder zeigt sich sich dieser zufrieden und bestätigt die
 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

chapters/technische-umsetzung/main.tex

@@ -59,7 +59,7 @@ aufwändig betrachtet wird und für den durch sie erbrachten Vorteil zu viel Auf
 
 \subsubsection{Ansatz 3}
 Der letzte Lösungsansatz befasst sich mit dem Erstellen dedizierter Vaults für jede*n Entwickler*in $d$.
-Hierbei existiert eine Python-Toolbox, die anhand einer Yaml-Datei Referenzen auf diese Passwort-Einträge
+Hierbei existiert eine Python-Toolbox, die anhand einer Yaml-Datei Referenzen auf die Passwort-Einträge
 in $\text{Vault}_d$ 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/r Entwickler*in vorgesehen werden.
 
@@ -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
@@ -136,7 +136,7 @@ wie zehn Anfragen für jeweils einen Eintrag zu stellen.
 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,
+Eine spätere Ergänzung, um das programmatische Auslesen \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.
@@ -150,29 +150,28 @@ 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.
 
 \subsubsection{Sicherheitsvorkehrungen}
 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 der fest kodierten Nutzvault-IDs vorkommt, meldet die Methode einen deskriptiven Fehler und beendet die Programmausführung.
+Alle Erstell- oder Löschfunktionen müssen einen Vault-ID-Parameter erhalten, selbst wenn dieser technisch nicht notwendig ist.
+Wenn diese Vault-ID nun in der Liste der fest kodierten Nutzvault-IDs vorkommt, meldet die Funktion 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}
 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 hat keinen Zugriff auf den gesamten Vault.
+Berechtigungsverwaltung auf Vaults basiert. 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 eine*n Entwickler*in. Das erfordert eine maßgeschneiderte, programmatische Lösung:
+vorhanden sind, existieren 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}
@@ -187,7 +186,7 @@ Also eine UUID, die für alle Entwickler*innen greifbar ist.
 Ab hier wird die Nutzergruppe \enquote{Entwickler*innen} in zwei Untergruppen strukturiert:
 \begin{description}
     \item [Interne Entwickler*innen] \hfill \\
-        Interne, festangestellte Entwickler*innen haben Vollzugriff auf den \ac{1P} und somit auch Zugriff auf die
+        Interne, festangestellte Entwickler*innen haben Vollzugriff auf \ac{1P} und somit auch Zugriff auf die
         in den Host-Konfigurationen vermerkte, öffentliche \ac{UUID} eines Eintrages.
         Da diese Entwickler*innen keinen Entwickler*innen-Vault haben, müssen sie direkt auf diese notierte, öffentliche \ac{UUID} zugreifen.
 \end{description}
@@ -196,7 +195,7 @@ Ab hier wird die Nutzergruppe \enquote{Entwickler*innen} in zwei Untergruppen st
     \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-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.
+        Diese Kopie hat eine andere \ac{UUID} als die, die in der Host-Konfiguration steht. Sie ist 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}
 
@@ -223,10 +222,11 @@ 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,
+Wird kein bekanntes Format erkannt, wird der Wert unverändert zurückgegeben.
+Das ermöglicht Rückwärtskompatibilität,
 sodass nach-wie-vor hardgecodede Secrets funktionieren, und nicht versehentlich als \ac{UUID} interpretiert werden.
 Das gewährleistet eine flüssigere Migration der Host-Konfigurationen, da somit bestehende Dateien weiterhin valide sind.
 
@@ -237,7 +237,7 @@ Es wird versucht, das Feld \enquote{password} aus diesem Eintrag zu dereferenzie
 \subsubsection*{Objektformat}
 Wird ein Yaml-Objekt übergeben, so werden die Keys \enquote{1P\_secret\_uuid} und \enquote{1P\_field\_id} erwartet.
 Diese definieren die Werte der Eintrags-\ac{UUID} und der Feld-ID in der ein Secret steht. Das ermöglicht z.B. auch den Benutzernamen (\textit{1P\_field\_id: username}) eines
-Eintrages abzufragen, anstelle nur des Passworts. Ist keine Feld-ID gegeben, so wird auf das Standardfeld \enquote{password} zurückgefallen.
+Eintrages abzufragen, anstelle des Passworts. Ist keine Feld-ID gegeben, so wird auf das Standardfeld \enquote{password} zurückgefallen.
 
 
 \subsection{Übersetzung der UUIDs}
@@ -252,11 +252,11 @@ von einem*r interne*n Entwickler*in ausgegangen. Sind beide Konfigurationen zugl
 Ist ein*e interne*r Entwickler*in angenommen, so wird der Mapping-Schritt übersprungen. Der verbleibende Prozess bleibt unberührt.
 
 \subsection{Kommunikation mit 1Password}
-Ist eine \ac{UUID} ermittelt, auf die der*ie Nutzer*in Zugriff hat, wird diese über das \ac{1P}-CLI angefragt.
+Ist eine \ac{UUID} ermittelt, auf die der*die Nutzer*in Zugriff hat, wird diese über das \ac{1P}-CLI angefragt.
 Dieser Aufruf ist: \textit{op item get <UUID>} mit dem Zusatz \textit{--format json}, um die Ausgabe programmatisch auswerten zu können.
 
 \subsection{Performanz und Benchmarks}
-Um diese Konfiguration zu testen, werden in einem Testszenario fünf Werte aus \ac{1P} ausgelesen:
+Um die Implementation zu testen, werden in einem Testszenario fünf Werte aus \ac{1P} ausgelesen:
 \begin{itemize}
     \item Datenbank-Host
     \item Datenbank-Port
@@ -264,7 +264,7 @@ Um diese Konfiguration zu testen, werden in einem Testszenario fünf Werte aus \
     \item Datenbank-Passwort
     \item Datenbank-Name
 \end{itemize}
-Diese Einträge abzufragen dauert durch das imperformante \ac{1P}-CLI rund 17 Sekunden.
+Diese Einträge abzufragen dauert durch das imperformante \ac{1P}-CLI 17 Sekunden.
 
 \subsection{Optimierung}
 Es bieten sich zwei Möglichkeiten an, den in \fullref{fig:flowchart-filtermodule-resolve-1p-secret} abgebildeten Prozess zu beschleunigen.
@@ -272,15 +272,15 @@ Diese beschäftigen sich damit, zu limitieren, wie oft das \ac{1P}-CLI angefragt
 
 \begin{description}
     \item [Das Mapping-Objekt zwischenspeichern] \hfill \\
-        Anstatt das Mapping-Objekt für jedes angefragte Secret erneut abzufragen, könnte es zwischengespeichert werden.
+        Anstatt das Mapping-Objekt für jedes angefragte Secret erneut abzufragen, kann 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üsste der gesamte Eintrag nur ein mal angefragt werden.
+        Für den Fall, dass ein Eintrag mehrfach angefragt wird, könnte ein einmal angefragter Eintrag zwischengespeichert werden.
+        Würden mehrere Felder desselben 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.
-E.g. nach jedem angefragten Secret, verliert er seinen internen Zustand.
-Daher muss dieses zwischengespeichert in einer Datei stattfinden. Hierfür wird eine Tempdatei über Pythons \textit{tempfile.gettempdir()}-Funktion ermittelt.
+Also nach jedem angefragten Secret verliert das Filtermodul seinen Zustand.
+Daher muss der Zwischenspeicher eine Datei sein. Hierfür wird eine Tempdatei über Pythons \textit{tempfile.gettempdir()}-Funktion ermittelt.
 Diese Zwischenspeicher beinhalten die vom \ac{1P}-CLI zurückgegebenen Informationen.
 
 \begin{nicepic}
@@ -294,7 +294,7 @@ Diese Zwischenspeicher beinhalten die vom \ac{1P}-CLI zurückgegebenen Informati
 Wenn das Mapping-Objekt angefragt wird, so wird zunächst geprüft, ob es eine lokal zwischengespeicherte Version gibt.
 Falls ja, wird diese geladen und verwendet.
 Falls nein, wird es via dem \ac{1P}-CLI angefragt und lokal gespeichert.
-Sollte der Mapping-Zwischenspeicher verwendet werden und das gesuchte Objekt nicht darin gefunden werden, so wird dieser Zwischenspeicher gelöscht und das Mapping-Objekt erneut angefragt.
+Sollte der Mapping-Zwischenspeicher verwendet werden und das gesuchte Objekt nicht darin gefunden werden, so wird der Zwischenspeicher gelöscht und das Mapping-Objekt neu angefragt.
 Das deckt folgenden Problemfall ab:
 
 \begin{enumerate}
@@ -316,10 +316,10 @@ Dieser Prozess würde durch diese Vorkehrung so aussehen:
     \item Der Prozess ist erfolgreich
 \end{enumerate}
 
-Durch die Implementation des Mapping-Zwischenspeichers, wird die Ausführzeit von 17 Sekunden auf acht Sekunden reduziert.
+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}
+Die Wahl fällt auf AES-256, weil es keine bekannten Angriffe gegen AES-256 gibt, die wesentlich effektiver als generische Angriffe gegen Blockchiffren sind. \cite{bib:BSI-TR-02102-1-2024}

config.tex

@@ -10,10 +10,10 @@
 \newcommand{\cfgDocClassification}{Projektbericht}
 
 % Document version
-\newcommand{\cfgDocVersion}{1.2}
+\newcommand{\cfgDocVersion}{1.4}
 
 % Last modification date
-\newcommand{\cfgDateLastModification}{17. Februar 2025}
+\newcommand{\cfgDateLastModification}{26. Februar 2025}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -40,7 +40,7 @@
 \newcommand{\cfgUniversityDepartment}{Fachbereich Informatik}
 
 % University degree course
-\newcommand{\cfgUniversityDegreeCourse}{Angewandte Informatik - dual (M.Sc)}
+\newcommand{\cfgUniversityDegreeCourse}{Angewandte Informatik - dual (M.Sc.)}
 
 % University supervisor name
 \newcommand{\cfgUniversitySupervisorName}{Professor Dr. Heinemann}
@@ -56,3 +56,4 @@
 
 % University course name
 \newcommand{\cfgCourseName}{Deep Dive}
+

dexes/glossarydex.tex

@@ -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 \\
@@ -20,14 +20,17 @@
     \item [Entwickler*innen-Vault] \hfill \\
         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.
+\end{description}
+\clearpage
+\begin{description}
     \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.