leonetienne/HSWO_MSC_WS2425_DEEP_DIVE_PAPER
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

do ze gender

Browse Source
This commit is contained in:
Leon Etienne
2025-01-31 02:38:57 +01:00
parent c9bba59d43
commit 89c871f9cb
5 changed files with 38 additions and 40 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
chapters/einleitung/problemstellung.tex
View File

@@ -4,19 +4,18 @@
\section{Problemstellung}
In der Arbeitsumgebung des Partnerunternehmens besteht zum Zeitpunkt der Themenfindung der hier beleuchteten Arbeit kein
Management für Secrets und Logindaten zwischen Entwicklern. Logindaten zu den Projekten des Unternehmens liegen schlicht in einem \ac{1P}-Vault.
\ac{1P} ist der vom Unternehmen verwendete Passwortmanager. Auf diesen Vault haben sämtliche interne Entwickler Zugriff, jedoch keine externen Entwickler.
Das ist so, weil anderenfalls dem externen Entwickler Lesezugriff auf sämtliche Einträge dieses Vaults gegeben werden müssten.
Management für Secrets und Logindaten zwischen Entwickler*innenn. Logindaten zu den Projekten des Unternehmens liegen schlicht in einem \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.
Das ist so, weil anderenfalls dLesezugriff 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.
Würden diese manuell in einen eigenen Vault kopiert werden, müssten diese Einträge fortan redundant gepflegt werden. Das ist eine Fehlerquelle, die zu
asynchronen Einträgen führt. Außerdem ist das ein großer Arbeitsaufwand.
All das gestaltet das Einbinden von externen Entwicklern, wie z.B. Freelancern, schwer.
All das gestaltet das Einbinden von externen Entwickler*innen, wie z.B. Freelancer*innen, schwer.
\\
\\
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
impraktikabel externen Entwicklern Zugriff auf dieses Ansible-Repository zu gewähren.
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
Entwickler zumeist unschöne Workarounds.
Entwickler*innen zumeist unschöne Workarounds.

6
chapters/einleitung/zielsetzung.tex
View File

@@ -3,12 +3,12 @@
%
\section{Zielsetzung}
Ziel ist es, eine Umgebung zu schaffen, in der beliebigen Entwicklern bestimmte
Ziel ist es, eine Umgebung zu schaffen, in der beliebigen Entwickler*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 Entwicklern zugewiesen werden können.
Das heisst, dass z.B. ganze Gruppen von Einträgen Entwickler*innen zugewiesen werden können.
Wenn z.B. einem Projekt viele Einträge zugeordnet sind, sollten diese idealerweise mit einer einzigen Configzeile
einem Entwickler zugeordnet werden können.
einem*r Entwickler*in zugeordnet werden können.
Außerdem sollte eine Möglichkeit ausgearbeitet werden, um \ac{1P}-Einträge in Ansible auszulesen,
damit keine Secrets mehr in den beiliegenden Konfigurationsdateien stehen, die das Freigeben
dieser zu einem Sicherheitsproblem machen.