Hallo xpi3000,
Ich weiß, dass oft empfohlen wird, Verbindungszeichenfolgen in der Anwendungskonfiguration zu speichern, auch von offizieller Seite. Und manchmal macht das auch Sinn.
Mein Problem damit ist nur, dass Verbindungszeichenfolgen standardmäßig als Einstellungen auf Anwendungsebene erstellt werden, was Kopfzerbrechen beim Deployment bereitet. Die Anwendungskonfiguration liegt ja meist unter %programfiles%,
bei der Anwendung, wo der Standarbenutzer keine Schreibrechte hat. Klar könnte man nun benutzerdefinierte Aktionen schreiben, die während der Installation die Anwendungskonfiguration entsprechend der Vorgaben ändern und ggf. verschlüsseln.
Aber zum einen benötigt man während der Installation elevierte Rechte, was die Art des Deployments stark einschränkt, zum anderen, was tun, wenn ein Port in der Verbindungszeichenfolge während des Betriebs geändert werden muss? Bei (hunderten
von) Installationen die app.config ersetzen? Das geht schon mal gar nicht, wenn Sections der app.config z.B. über DPAPI geschützt sind, da der Schutz maschinenspezifisch ist. Ganz zu schweigen vom Szenario in dem Windows neu aufgesetzt
werden muss, was die verschlüsselte app.config aus der täglichen Band-Sicherung so ziemlich unbrauchbar macht.
Soweit so gut. Nehmen wir nun gnädigerweise an, der Entwickler weicht auf die Benutzerebene der app.config aus, und benutzt die Verbindungszeichenfolgen der Anwendungsebene quasi nur als Startvorlage. Hier haben wir nun keine Schreibrechtprobleme
mehr, wir könnten sogar die Verschlüsselung maschinenunabhängig gestalten, wenn nur nicht das da wäre, was DPAPI so reizend macht: das (dort fehlende) Problem der Schlüsselverwaltung.
Darüber hinaus ist es fast ein Ding der Unmöglichkeit, die so über alle Rechner verstreuten Verbindungzeichenfolgen zentral zu verwalten. Das schafft heterogene Konfigurationszustände und gibt der Helpdesk die Möglichkeit sich noch lauter
zu behaupten.
Auch wenn nicht hunderte sondern nur einige wenige Mitarbeiter mit deinem Programm arbeiten und auch wenn Du kein FIPS 140-2 zertifiziertes Keymanagement brauchst,
in nuce bleibt das Problem doch immer gleich und (e)skaliert mit jedem neuen Mitarbeiter der dazukommt.
In der Arbeit mit dem SQL Server ziehe ich es deshalb vor, einfach die integrierte Authentifizierung zu benutzen. Keine Probleme mit der Verschlüsselung mehr. Datenvermeidung
at its best. Ob es eine integrierte Authentifizierung für MySQL gibt, weiß ich nicht. Du könntest aber - vor allem im Enterpriseumfeld - die Datenbank hinter der Facade eines WCF-Dienstes verbergen, was sowohl
das Problem der Schlüsselverwaltung als auch das der Konfiguration der Verbindungszeichenfolge stark vereinfacht. Die Kommunikation zwischen WCF-Client und WCF-Dienst kann über Zertifikate etc. abgesichert werden, so dass auch hier keine Passwörter
mehr verwendet werden müssen. Dein Problem ist kein einfaches Problem. Wäre es so, wäre es längst gelöst.
Gruß
Marcel
