Da über die CLI-Methode der Zugriff auf die Entwickler*innen-Vaults direkt über die \ac{1P}-Desktop-App geschieht, kann diese den Vault-Inhalt auch dem Nutzer in ihrem GUI offenbaren.
Die Verwendung der \ac{1P}-Restful-API erscheint dem Autor nach ihrer Dokumentation sehr aufwändig und kompliziert. Eine CLI-API zu verwenden würde somit in der Umsetzung Projektressourcen sparen.
\end{description}
So begründet fällt die Wahl der Schnittstelle zu \ac{1P} auf ihre CLI-API.
Um schnelle Softwareentwicklung mit minimalem Overhead zu gewährleisten und um für eine spätere Einbindung in Ansible
bereits in Vorleistung zu treten, fällt die Wahl der Programmiersprache auf Python. Ansible-Module können mit Python geschrieben werden. \cite{bib:ansible-docs-python-module}
\item{Kopiere alle vorgesehenen Einträge $e_m \in\text{Master-Vault}$ nach $d$ und ergänze das Feld \enquote{Originale Eintrags-ID} mit dem \ac{UUID} von $e_m$.}
\item{Erstelle ein ID-Mapping-Objekt von $e_d$ zu $e_m$ in $d$.}
\end{enumerate}
\subsubsection{Performanzprobleme und Optimierung}
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
abgefragt werden. Hier ist \textit{ein} CLI-API-Aufruf pro Eintrag erforderlich. Sind einem*r Entwickler*in z.B. 30 Einträge zugeordnet, so dauert das Finden eines Eintrages
Ein Kopiervorgang stellt zwei Aufrufe dar (=\textit{lesen,erstellen}), also dauert das Kopieren von 30 Einträgen $n=30; 2n =60$ Sekunden.
Das \ac{1P}-CLI kann zwar für Detail-Aufrufe mehrere Eintrags-IDs auf Standard-Input annehmen und bearbeiten, jedoch zeigen Versuche des Autors, dass das nicht die benötigte Zeit pro Eintrag beeinflusst. Das heißt, eine Anfrage für zehn Einträge zu stellen, dauert in etwa zehn mal so lange,
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.
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 diese Vault-ID nun in der Liste der fest kodierten Nutzvault-IDs vorkommt, meldet die Methode einen deskriptiven Fehler und beendet die Programmausführung.
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
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.
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.
Ist in der Docker-Ansible-Konfigurationsdatei eine Entwickler*innen-Vault-\ac{UUID} definiert, so wird von einem*r externe*n Entwickler*in ausgegangen.
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.
All diese Ansätze erfordern es Daten zwischenzuspeichern. Filtermodule haben allerdings keinen persistenten Arbeitsspeicher über verschiedene Aufrufe hinaus.
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.
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.
Das deckt folgenden Problemfall ab:
\begin{enumerate}
\item Zwischenspeicher wird erstellt
\item Entwickler*in erhält mehr Berechtigungen
\item Entwickler*in will diese Berechtungen nutzen
\item Der Zwischenspeicher wird verwendet, spiegelt diese neuen Berechtigungen aber nicht wider
\item Der Prozess schlägt zu Unrecht fehl
\end{enumerate}
Dieser Prozess würde durch diese Vorkehrung so aussehen:
\begin{enumerate}
\item Zwischenspeicher wird erstellt
\item Entwickler*in erhält mehr Berechtigungen
\item Entwickler*in will diese Berechtungen nutzen
\item Der Zwischenspeicher wird verwendet, spiegelt diese neuen Berechtigungen aber nicht wider
\item Das System erneuert den Zwischenspeicher
\item Der Zwischenspeicher spiegelt nun die neuen Berechtiungen wider
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}
