Zitat |
Aus Interesse: Warum sind Umgebungsvariablen sicherer? |
Prinzipiell gilt die Verwaltung von Credentials durch die "Umgebung" als die sicherste Variante.
Für die konkrete Umsetzung zB. einer Desktop App das in der Regel das Betriebssystem und im konkreten Fall von Windows eben der Credential Manager.
Wer mal einen Blick rein wirft der sieht auch, dass quais alle Windows oder auch zB. Microsoft Applikationen (zB Office Suite) aber auch zB. Git hier seine Credentials hinterlegt.
Damit wird sichergestellt, dass der Zugriff nur im Betriebssystem-Kontext (zB angemeldeter Benutzer) möglich ist. Credentials in Dateien kann jeder sehen, der Zugriff auf die Datei hat - egal wo sie liegt.
Basierend auf diesem Mechanismus funktionieren im Prinzip auch alle Enterprise Secret Manager, wie zB Azure KeyVault, Hashicorp Vault, AWS Secret Manager:
Der Zugriff auf den Vault ist nur durch die
Managed Identity möglich, wobei die Managed Identity durch die Umgebung (Azure, AWS, Kubernetes Cluster..) erzeugt oder mindestens aktiv verwaltet wird.
Konkretes Beispiel:
Der Zugriff auf Azure KeyVault ist nur von Azure-Services aus möglich; nicht von Deinem PC. Dein PC liegt schließlich nicht in der Hoheit von Azure; der Service hingehen schon.
Eine Managed Identity ist dabei zB. die Webanwendung, sodass auch wirklich nur diese Applikation Zugriff auf zB. Datenbank-Credentials hat.
Konkrete Azure Lekture:
What are managed identities for Azure resources?
Die .NET CLI hat seit längerem schon die Unterstützung von User Secrets während der Entwicklungszeit, sodass man auch gar nicht in die Versuchung kommen muss, irgendwelche Credentials in Dateien zu packen und gar eventuell einzuschecken.
Das funktioniert mit allen Applikationen, die den Microsoft.Extensions.Configurations entsprechend nutzen.
Die Docs hier liegen unter ASP.NET Core, weil es hier besonders wichtig ist, dass eben die Credentials nicht in Dateien liegen Safe storage of app secrets in development in ASP.NET Core