Zitat von RayYago: |
Ich weiß nicht genau was ein ConsoleHost ist |
Wenn Du etwas nicht weißt, dann hilft meist ein Blick in die Dokumentation.
Zitat von https://docs.microsoft.com/de-de/aspnet/core/fundamentals/host/generic-host?view=aspnetcore-3.1: |
Der Host ist ein Objekt, das alle Ressourcen der App kapselt, z. B.:- Abhängigkeitsinjektion
- Protokollierung
- Konfiguration
- IHostedService-Implementierungen
|
Es sorgt dafür, dass Du ein Rahmen hast, der Dir gewisse Verantwortungen abnimmt - egal ob in ASP.NET Anwendungen, wo es bereits eingebaut ist, oder Konsolenanwendungen (in denen man es leider selbst hinzugefügen muss) oder Desktop Anwendungen (in denen man das meiste noch hinzufügen muss).
Ein Code Beispiel für Konsolenanwendungen siehst Du via dem GitHub Link.
Die eigentliche Anwendung ist dann:
C#-Code: |
services.AddHostedService<MyHangfireApp>();
|
als Start und als Implementierung:
C#-Code (https://github.com/BenjaminAbt/Hangfire.ConsoleHost/blob/master/sample/Server/MyHangfireApp.cs): |
public class MyHangfireApp : IHostedService, IDisposable
|
Daher hab ich Dir den Link gegeben.
Zitat von RayYago: |
Diese Verzeichnise sind doch auch einsehbar? |
Hab ProgramData in AppData bereits korrigiert gehabt.
Aber ja, diese Verzeichnisse sind immer lesbar, sobald der PC komprommitiert ist.
Während er Entwicklung gibt es auch die dotnet user secrets, die manche LEute auch für den produktiven Einsatz nehmen, die auf Environment Variables basieren, aber für den produtiven Einsatz nicht empfohlen sind.
Zitat von https://docs.microsoft.com/de-de/aspnet/core/security/app-secrets?view=aspnetcore-3.1&tabs=windows: |
Umgebungsvariablen werden im Allgemeinen in unverschlüsseltem, unverschlüsseltem Text gespeichert. Wenn der Computer oder der Prozess kompromittiert ist, kann von nicht vertrauenswürdigen Parteien auf Umgebungsvariablen zugegriffen werden. Möglicherweise sind zusätzliche Maßnahmen erforderlich, um eine Offenlegung von Benutzer Geheimnissen zu verhindern. |
Zitat von RayYago: |
Umgebungsvariablen sind doch auch als plain text zu sehen. Und eine Datei mit dem ConnectionString einfach unter ProgramData abzulegen ist wahrscheinlich auch nicht besonders sicher oder? |
Egal wie man ein Passwort ablegt: sobald man ein Passwort irgendwo ablegt, ist es nicht sicher.
Sicher sind nur integrierte Lösungen wie zB. Azure Active Directory oder zB. Azure Key Vault (für Applikationen in der Azure Umgebung).
Alles, was Du irgendwie auf Deinem PC ablegst, kann auf eine gewisse Art und Weise ausgelesen werden.
Alles.
Eine Verschlüsselung von etwas, das Du nachher wieder im Urzustand brauchst (wie ein ConnectionString oder ein Passwort, also kein Hashing) ist prinzipiell auch nur eine Verschleierung.
Spätestens im Speicher kann es ausgelesen werden.
Daher auch den Tipp mit der Alternative.
Der Zustand
Zitat von RayYago: |
Aber die eigentliche App.Config bleibt unverschlüsselt. Der Client hat zwar die verschlüsselte Version, aber in meinen Verzeichnissen ist die unverschlüsselte Datei zu finden. |
ist prinzipiell korrekt so.
Du hast während der Entwicklung immer die originale Datei; und wenn diese Teil des Publish Prozesses ist, dann wird diese natürlich zusätzlich mitgliefert.
Im Prinzip ist das alles eher "ein Problem Deines Workflows"; das so kein Tooling abdeckt.