Wie lassen sich Verbindungsstrings am besten zentralisieren und sichern?

Question

Wie lassen sich die von den Anwendungen verwendeten Verbindungsstrings am besten zentralisieren und sichern? In meiner Umgebung haben wir viele interne Anwendungen. Jede Anwendung benötigt einen oder mehrere Verbindungsstrings, um auf die Datenbank zugreifen zu können. Unser Ziel ist es, alle diese Verbindungszeichenfolgen (insbesondere SQL-Logins und Passwörter) zu zentralisieren, damit wir die Passwörter an einer Stelle ändern können, anstatt in 35 verschiedenen .config-Dateien, Registrierungseinträgen usw.

Derzeit verwenden wir eine selbstentwickelte Komponente, die die Informationen über die Verbindungszeichenfolge aus einer Access-Datenbank abruft; dies deckt die Zentralisierungsanforderung ab, ist aber nicht besonders sicher. Darüber hinaus haben wir Anwendungen, die in Sprachen wie classic asp, vb6, delphi, c++ und .net geschrieben sind, so dass die Lösung von all diesen Anwendungen genutzt werden kann.

Hat jemand eine Idee, wie man das besser machen kann, oder müssen wir unseren gesamten Ansatz für den Zugriff unserer Anwendungen auf die Datenbank überarbeiten.

Answer 1

Das Unternehmen, für das ich arbeite, hat eine ähnliche Situation über eine SQL Server-Datenbank genutzt. Am Ende haben wir eine COM-konforme .net dll erstellt, um die API in der Datenbank zu vereinfachen und zu sichern und um sicherzustellen, dass die gleiche Logik zwischen klassischen Asp-, .net- und DTS-Paketen verwendet wird. Diese Lösung hat sich für uns seit einem Jahr bewährt, und obwohl viele von uns noch einige Refactoring-Maßnahmen durchführen möchten, hat sie sich bei Problemen wie Server-Migrationen oder Umbenennungen als sehr nützlich erwiesen.

Ich denke, Sie sind auf dem richtigen Weg, aber ich würde folgende Änderungen empfehlen:

• Versuchen Sie, auf einen echten Datenbankserver umzusteigen. Access ist großartig für MS Office, aber nicht für etwas in dieser Größenordnung.
• Erstellen Sie eine Verwaltungskonsole, die es ermöglicht, zu überprüfen, wer Informationen hinzufügt und bearbeitet (sichern Sie auch, wer Zugriff auf welche Einstellungen hat).
• Erstellen Sie eine COM-konforme DLL, damit sie von anderen Systemen auf sichere und konsistente Weise genutzt werden kann.

EDIT:

Nachdem ich jahrelang mit einem solchen System gearbeitet habe, ist mir aufgefallen, dass einem bei einigen Lösungen die Hände gebunden sind. Viele Tools auf dem Markt (z. B. nHibernate, Elmah usw. in der .Net-Welt) sind wirklich eingeschränkt, wenn der Verbindungsstring nicht mehr in den Konfigurationsdateien enthalten ist. Viele können leicht modifiziert werden, um Ihre API zu verwenden; es ist jedoch etwas, das mehr Zeit in Anspruch nimmt, um zu untersuchen, ob Sie es verwenden möchten. Nur zu Ihrer Information.

Answer 2

Sie können Windows Server verwenden, um Benutzer zu erstellen, die auf Ihre SQL Server-Datenbank zugreifen dürfen. Dann können Sie die integrierte Windows-Anmeldung in Verbindungsstrings verwenden.

Übrigens: Die Speicherung von Passwörtern in öffentlichen MDB macht sie irrelevant. Genauso wie sie nicht existieren.

Answer 3

Ist es nicht möglich, in den Verbindungszeichenfolgen auf "Window Integrated Security" umzuschalten, dann müssen Sie sich nicht so viele Gedanken über den Sicherheitsaspekt machen (es sei denn, Sie müssen den tatsächlichen Standort der Verbindung sichern).