sicherheit
This commit is contained in:
@@ -304,4 +304,18 @@ 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 8 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 wird dieser lokal zwischengespeichert. 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
|
||||
löscht Einträge und erstellt diese neu. Damit erhalten diese eine neue \ac{UUID} und sind somit im Zwischenspeicher nicht mehr repräsentiert.
|
||||
|
||||
\subsubsection{Eintrags-Zwischenspeicher}
|
||||
Durch das implementieren des Eintrags-Zwischenspeichers wird die Ausführzeit von acht Sekunden auf zwei Sekunden reduziert.
|
||||
|
||||
\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,
|
||||
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}
|
||||
|
Reference in New Issue
Block a user