KrisFeb 25
Exposure-Management stellt fest, dass ein Access Key im Klartext in einem Skript steht.
Show threadKrisFeb 25

Kollege löscht den Key dort.

Exposure-Management stellt fest, dass nun ein Access Key im Klartext in ~/.viminfo steht.

Show threadKrisFeb 25

⁨sed -i '/der_key//g' .viminfo⁩⁩

Exposure-Managemnt stellt fest, dass nun ein Access Key im Klartext in der ⁨.bash_history⁩ steht.

Show threadKrisFeb 25

unset BASH_HISTFILE; sed -i s '/der_key//g' .bash_history⁩.

Exposure Management stellt fest, daß das ⁨unset BASH_HISTFILE⁩ das EPMS getriggert hat und der Key jetzt im Log des SOC steht.

Show threadMarianne Spiller
@isotopp 😂 Spezielle Spezialexpreten bei der Arbeit!
Feb 25 at 2:55pmWeb
Show threadfunzFeb 25
@netzwerkgoettin @isotopp wie mach ichs richtig?
Show threadGabeFeb 25
@funz @netzwerkgoettin @isotopp key ändern.
Show threadfunzFeb 25
@gabe @netzwerkgoettin @isotopp klar! :D
Danke!
Show threadGabeFeb 25

@funz @netzwerkgoettin @isotopp war flapsig, sorry. Aber ernst gemeint.

Es gibt ja reichlich Möglichkeiten, eine Datei zu ändern ohne zusätzliche Kopien (ed is the standard text editor!), aber die tiefere Lehre hier ist, daß das Kind schon längst im Brunnen ist, die festgestellten Schwierigkeiten sind da beispielhaft und nicht erschöpfend.

Es gibt keine "richtige" Lösung. Der Key ist als kompromittiert zu behandeln. Das Erlebnis mag als trigger dienen, Prozesse zur Änderung und Verwaltung von Keymaterial zu überprüfen und ggf. zu verbessern, und deutlich machen, warum das alles einfach sein muss.