bump versino

appendix/interview-jochen.tex

@@ -1,4 +1,84 @@
 \chapter{Stakeholder-Interview}
 \label{app:stakeholder-interview}
 
-\textbf{!!!TODO TODO TODO ADD APPENDIX INTERVIEW!!!}
+\textbf{Anforderungserfassung 1Password-Berechtigungsverwaltung}\\
+\textbf{und -Schnittstelle} \\
+\textbf{16.10.2024 und 23.10.2024, Bad Dürkheim} \\
+\textbf{Teilnehmer: Leon Etienne, Jochen Stange} \\
+
+\textbf{Frage:} Was sind die Aufgabenbereiche von externen Entwickler*innen?
+\begin{quote}
+Externe steigen z.B. für die Umsetzung großer Projekte ein und arbeiten in diesem Umfang mit uns in agilen Entwicklungsprozessen wie z.B. Scrum.
+Je nach dem Projekt braucht man da schon einige Zugänge.
+Es kommt aber auch vor, dass Entwickler wie \emph{<Name geschwärzt>} selbstständig Projekte umsetzen, gegebenfalls auch kleine Projekte.
+Die brauchen dann eigentlich nur den Backend-Login. Den können wir auch auch mailen.
+Es war aber auch schon im Diskurs TYPO3-Upgrades outzusourcen. Das ist sowieso undankbare Arbeit und wir wären froh, das aus den Füßen zu haben.
+Da müssten wir schon einige Zugänge übermitteln.
+\end{quote}
+
+\textbf{Frage:} Und wieso lagern wir solche Upgrades nicht schon aus?
+\begin{quote}
+Naja die dafür zuständigen Dienstleister brauchen dafür unser Docker-Ansible. Das können wir aber nicht rausgeben, das ist ja voll mit Email und Datenbankzugängen.
+Wir sind ja schon lange dran das zu fixen, nur wir kommen wir nie so wirklich dazu.
+\end{quote}
+
+
+\textbf{Frage:} Könntest du dir vorstellen, diese Zugänge in unseren Passwortmanager auszulagern? Damit könnten wir die Berechtigungsverwaltung an 1Password abgeben.
+\begin{quote}
+Sicher, wenn Ansible dann noch drankommt, klingt das gangbar. Wie funktioniert die Berechtigungsverwaltung da überhaupt?
+\clearpage
+\emph{<Es wird gemeinsam durch die administrative 1Password-Oberfläche gestöbert>}
+\\
+\\
+Mh. Ich finde nur Berechtigungen, um Vaults freizugeben, nicht aber für einzelne Einträge.
+Wir haben doch eigentlich durch unseren relativ teuren Tarif Zugang zu Live-Support.
+Ich stelle nachher mal eine Support-Anfrage. Die sollen mir erklären, wie das geht. Muss ja gehen.
+\\
+\\
+\emph{<Das Interview wird bis nach dem Support-Zoom-Call mit 1Password pausiert>}
+\\
+\\
+Leon, das glaubst du nicht. Das geht wirklich nicht. Man kann nur ganze Vaults freigeben.
+Man kann noch nicht mal Verknüpfungen auf einzelne Einträge in diesen erstellen. Wenn wir jetzt \emph{<Name geschwärzt>} Zugang auf 2 oder 3 Einträge geben wollten, müssten wir die von Hand kopieren und ab dann
+doppelt Pflegen. Das ist ja unglaublich.
+\end{quote}
+
+\textbf{Frage:} Ich verstehe. Und wenn wir je Projekt einen Vault erstellen würden?
+\begin{quote}
+    Dann müssten wir ja den ganzen Passwortmanager umbauen. Außerdem haben wir über 200 Projekte. Mit so vielen Vaults würde sich
+    niemand mehr zurecht finden. Lass das mal lieber sein.
+\end{quote}
+
+\textbf{Frage:} Ich lasse mir etwas einfallen. Klingt, als müssten wir etwas eigenes bauen. Wäre es OK, wenn wir Zugänge in YAML definieren?
+\begin{quote}
+Solange es mit etwas technischem Know-How nicht zu aufwändig zu pflegen ist, gerne.
+Ich will aber nicht, dass wir nachher für jedes Projekt 20 Einträge einzeln jedem Entwickler zuweisen müssen. Das muss projektbasiert gehen.
+Trotzdem muss es aber funktionieren, dass wir projektunabhängige Einträge so zuweisen können. Für interne Werkzeuge z.B.
+\end{quote}
+
+\textbf{Frage:} Vlt. könnten wir Wildcards verwenden, um die Eintragstitel zu durchsuchen? Die sind bei uns ja sehr einheitlich.
+\begin{quote}
+Klingt pragmatisch. Da kann man dann notfalls auch komplette Eintragstitel reinschreiben, oder?
+Die Einträge, auf die so eine Wildcard passt, werden dann der Entwicklerin zugewiesen.
+\end{quote}
+
+\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.
+\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.
+\begin{quote}
+Klingt gut. Aber müssen wir die dann nicht doch wieder doppelt pflegen?
+\end{quote}
+
+\textbf{Frage:} Nein, ich würde einen Mechanismus bauen, der sich darum kümmert, diese Vaults aktuell zu halten. Wenn überhaupt müssen wir einen Sync-Prozess anstoßen. Passt das?
+\begin{quote}
+Wenn du das so hinkriegst, wäre das gut. Zwar nicht ideal, aber 1P scheint ja nicht mehr herzugeben.
+\end{quote}
+
+\textbf{Frage:} Super. Wenn du sonst keine Fragen oder Anregungen mehr hast, würde ich gleich damit loslegen :)
+\begin{quote}
+Im Moment nicht. Ich melde mich wenn doch.
+\end{quote}

chapters.tex

@@ -11,6 +11,6 @@
 \input{chapters/anforderungen.tex}
 \input{chapters/technische-umsetzung/main.tex}
 
-\input{chapters/evaluation.tex}
+\input{chapters/evaluation-fazit.tex}
-\input{chapters/fazit.tex}
+\input{chapters/ausblick.tex}
 

chapters/anforderungen.tex

@@ -7,7 +7,7 @@
 \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 semistrukturiertes Interview mit dem Stakeholder durchgeführt.
+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
@@ -15,7 +15,9 @@ Notizen zu diesem Interview befinden sich im Anhang unter
 
 \section{Ergebnisse}
 Das Ergenis der Anforderungserfassung ist ein Lastenheft, das in constraints, funktionale und
-nicht-funktioniale Anforderungen zu unterteilen ist.
+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.
 
 \begin{table}[ht]
     \centering
@@ -41,6 +43,7 @@ nicht-funktioniale Anforderungen zu unterteilen ist.
         Nutzung von \ac{1P} ist zwingend erforderlich. \\ \hline
         Die Übermittlung der Secrets muss über das Internet erfolgen. \\ \hline
     \end{tabular}
-    \caption{Anforderungen}
+    \caption{Lastenheft}
+    \label{tbl:lastenheft}
 \end{table}
 

chapters/ausblick.tex

@@ -0,0 +1,16 @@
+%
+% Chapter: Evaluation
+%
+
+% Let chapter stay on the same page
+\begingroup
+\let\clearpage\relax
+
+\chapter{Ausblick}
+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
+aufweisen.
+
+\endgroup

chapters/evaluation-fazit.tex

@@ -0,0 +1,32 @@
+%
+% Chapter: Evaluation
+%
+
+\chapter{Evaluation und Fazit}
+Das abschließende Ergebnis des in dieser Ausarbeitung dokumentierten Projektes
+ist ein Python-Projekt, das in der Lage ist, anhand einer Berechtigungs-Konfigurationsdatei im Yaml-Format
+\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.
+\\
+\\
+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\\
+Entwickler*innen-Vault. Das geschiet in einer IT-sicherheitstechnich unbedenklichen
+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.
+
+\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,
+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
+und somit Arbeit auszulagern.
+

chapters/evaluation.tex

@@ -1,7 +0,0 @@
-
-%
-% Chapter: Evaluation
-%
-
-\chapter{Evaluation}
-

chapters/fazit.tex

@@ -1,8 +0,0 @@
-%
-% Chapter: Fazit
-%
-
-\chapter{Fazit}
-\section{Ausblick}
-\section{Offene Problemstellungen}
-

chapters/technische-umsetzung/main.tex

@@ -308,13 +308,30 @@ 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 wird dieser lokal zwischengespeichert. Das stellt ein Problem dar, sobald der Eintrag
+Wird ein Eintrag von \ac{1P} angefragt, so soll das Filtermodul diessen lokal zwischengespeichern.
+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 diesen haben und das Synchronisierungs-Werkzeug
+Die Entwickler*innen sollten keine Schreibberechtigung auf ihren Vault haben.
-löscht Einträge und erstellt diese neu. Damit erhalten diese eine neue \ac{UUID} und sind somit im Zwischenspeicher nicht mehr repräsentiert.
+Werden originale Einträge verändert, werden die Referenzeinträge vom Synchronisierungswerkzeug gelöscht
+und neu erstellt. Damit erhalten diese eine neue \ac{UUID} und sind somit im Zwischenspeicher nicht mehr repräsentiert.
+Durch das Implementieren des Eintrags-Zwischenspeichers wird die Ausführzeit von acht Sekunden auf zwei Sekunden reduziert.
 
-\subsubsection{Eintrags-Zwischenspeicher}
+\begin{table}[!htbp] % !htbp
-Durch das implementieren des Eintrags-Zwischenspeichers wird die Ausführzeit von acht Sekunden auf zwei Sekunden reduziert.
+    \centering
+    \begin{tabular}{|l|l|r|}
+        \hline
+        \textbf{Aktiviertes Caching-Level}   &   \textbf{Ausführzeit (Sekunden)}\\
+        \hline
+        Ohne Cache                  & 17\\
+        \hline
+        UUID-Mapping-Cache          &  8\\
+        \hline
+        Mapping+Item-Cache          &  2\\
+        \hline
+    \end{tabular}
+    \caption{Ausführzeiten des Test-Playbooks mit Testdaten (Fünf Secrets aus einem 1P-Eintrag)}
+    \label{tbl:ausführzeiten-versch-caches}
+\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,

config.tex

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

dexes/acrodex.tex

@@ -8,16 +8,16 @@
 \begin{acronym}
 %
 %
+    \acro{1PSA}[1PSA]{1Password Secrets Automation}
     \acro{1P}[1P]{1Password}
     \acro{API}[API]{Application Programmer Interface}
     \acro{CLI}[CLI]{Command Line Interface}
     \acro{GAU}[GAU]{Größter Anzunehmender Unfall}
     \acro{GUI}[GUI]{Graphical User Interface}
     \acro{MASA}[MASA]{Medienagenten Secret Authority}
-    \acro{YAML}[YAML]{Yet Another Markup Language}
     \acro{UUID}[UUID]{Universally Unique Identifier}
     \acroplural{UUID}[UUIDs]{Universally Unique Identifiers}
-    \acro{1PSA}[1PSA]{1Password Secrets Automation}
+    \acro{YAML}[YAML]{Yet Another Markup Language}
 %
 %
 \end{acronym}

dexes/glossarydex.tex

@@ -9,17 +9,23 @@
         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.
     \item [(1P-)Vault] \hfill \\
         Eine Kollektion an Secret-Einträgen in einem Passwort-Manager (1Password).
-    \item [Nutzvault] \hfill \\
+    \item [Ansible-Playbook/s] \hfill \\
-        Ein 1P-Vault, in dem die originalen Einträge des Partnerunternehmens verortet sind. Hier liegen keine Kopien, sondern Originale!
+        Ansible-Playbooks sind Skripte, mit dem Ziel einen deklarierten Zustand herzustellen. \cite{bib:ansible}
+    \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.
+    \item [Docker] \hfill \\
+        Eine arrivierte Container-Engine für Anwendungsentwicklung.
     \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.
-    \item [Ansible-Playbook/s] \hfill \\
+    \item [Jinja-Templating-Engine] \hfill \\
-        Ansible-Playbooks sind Skripte, mit dem Ziel einen deklarierten Zustand herzustellen. \cite{bib:ansible}
+        Eine Templating Engine, die das Jina-Format verwendet. Ansible verwendet eine Jinja-Templating-Engine.
-    \item [Docker] \hfill \\
+    \item [Listenansicht / Listenaufruf] \hfill \\
-        Eine arrivierte Container-Engine für Anwendungsentwicklung.
+        Eine Anfrage, die eine Liste von Objekten oder Einträgen zurückgibt.
-    \item [Toolbox] \hfill \\
+    \item [Nutzvault] \hfill \\
-        Eine Ansammlung an Werkzeugen, wie zum Beispiel Skripte.
+        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.
         Externe Entwickler*innen haben also keinen direkten Zugriff auf einen solchen Eintrag, sondern müssen stattdessen eine Referenz auf diesen Eintrag verwenden.
@@ -28,11 +34,9 @@
     \item [Private 1P-UUID] \hfill \\
         Die 1P-UUID, die zu einem Referenz-Eintrag gehört, und nicht zu einem originalen Eintrag. Diese Einträge sind emphemerisch und existieren ausschließlich
         in den einzelnen Developer-Vaults und sind Entwickler*innen-spezifisch.
-    \item [Listenansicht / Listenaufruf] \hfill \\
+    \item [Secret] \hfill \\
-        Eine Anfrage, die eine Liste von Objekten oder Einträgen zurückgibt.
+        Eine vertrauliche Information, wie zum Beispiel ein Passwort.
-    \item [Detailansicht / Detailaufruf] \hfill \\
+    \item [Toolbox] \hfill \\
-        Eine Anfrage, \emph{ein} Objekt oder \emph{einen} Eintrag zurückgibt oder manipuliert.
+        Eine Ansammlung an Werkzeugen, wie zum Beispiel Skripte.
-    \item [Jinja-Templating-Engine] \hfill \\
-        Eine Templating Engine, die das Jina-Format verwendet.
 \end{description}