remove chapter name

appendix/interview-jochen.tex

@@ -5,6 +5,7 @@
 \textbf{und -Schnittstelle} \\
 \textbf{16.10.2024 und 23.10.2024, Bad Dürkheim} \\
 \textbf{Teilnehmer: Leon Etienne, Jochen Stange} \\
+\textbf{Dokumententyp: Gedächtnisprotokoll} \\
 
 \textbf{Frage:} Was sind die Aufgabenbereiche von externen Entwickler*innen?
 \begin{quote}
@@ -65,7 +66,7 @@ Die Einträge, auf die so eine Wildcard passt, werden dann der Entwicklerin zuge
 \textbf{Frage:} Ja, das würde gehen. Vlt wären aber 1Password-IDs eindeutiger. Das wäre auch kein nennenswerter Mehraufwand
 \begin{quote}
 Ok, dann nimm das noch mit dazu. Aber nicht anstatt.
-Äh und noch was. Das ist ja nicht nur für Ansible. Wie würden damit ja auch Accountzugänge verteilen. Wie sollen die Entwickler das dann einsehen? Über das Terminal wäre das sehr unhandlich.
+Äh und noch was. Das ist ja nicht nur für Ansible. Wir würden damit ja auch Accountzugänge verteilen. Wie sollen die Entwickler das dann einsehen? Über das Terminal wäre das sehr unhandlich.
 \end{quote}
 
 \textbf{Frage:} Wenn wir Entwicklern eigene Vaults geben würden, in die Einträge hinenkopiert werden, könnten sie die Einträge in der 1P App einsehen.

chapters/anforderungen.tex

@@ -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
+        \ac{1P}-Einträge sollen Entwicklern*innen einzeln zuweisbar sein. \\ \hline
-        Nicht in der Konfugration gelistete Zugänge sollen bei Anwendung entfernt werden. \\ \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
+        Das System muss einfach zu pflegen sein. \\ \hline
-        Die benötigte Zeit zur Ausführung der Anwendung soll nicht sehr lange 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

chapters/einleitung/problemstellung.tex

@@ -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/einleitung/zielsetzung.tex

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

chapters/evaluation-fazit.tex

@@ -22,7 +22,6 @@ Hiermit ist das in \fullref{tbl:lastenheft} definierte Lastenheft des Stakeholde
 Nach Vorstellung der erarbeiteten Ergebnisse vor dem Stakeholder zeigt sich sich dieser zufrieden und bestätigt die
 pragmatische Korrektheit des Produktes.
 
-\section{Mehrwert für das Partnerunternehmen}
 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
 vergeben werden. Darüber hinaus bereitet diese Technologie den Weg für das Partnerunternehmen,

chapters/technische-umsetzung/main.tex

@@ -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.
+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
+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
+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.
+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.
+In der naiven Herangehensweise, um einen Eintrag einer bestimmten originalen \ac{UUID} zu finden,
-Diese Lösungsweg hat eine Zeitkomplexität von $O(n^2)$.
+wird jeder Eintrag auf dessen originale \ac{UUID} geprüft, bis der passende Eintrag gefunden wurde.
-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.
+Dieser Lösungsweg hat für \emph{einen} Eintrag eine Zeitkomplexität von $O(n)$.
-Je Entwickler*innen-Vault wird abschließend der Synchronisierung ein Mapping-Objekt erstellt.
+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.
+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 feingranularere Steuerung ist hier nicht möglich, jedoch für die hier gegebenen Anforderungen nötig. \cite{bib:1password-secrets-automation}
+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.

config.tex

@@ -10,10 +10,10 @@
 \newcommand{\cfgDocClassification}{Projektbericht}
 
 % Document version
-\newcommand{\cfgDocVersion}{1.1}
+\newcommand{\cfgDocVersion}{1.2}
 
 % Last modification date
-\newcommand{\cfgDateLastModification}{14. Februar 2025}
+\newcommand{\cfgDateLastModification}{17. Februar 2025}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 

dexes/glossarydex.tex

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