Wir sind ein Rechenzentrum, das eine SQL Server 2000-Umgebung hostet, die Datenbankdienste für ein von uns verkauftes Produkt bereitstellt, das als Rich-Client-Anwendung auf jedem unserer zahlreichen Kunden und auf deren Arbeitsstationen geladen wird.
Derzeit verwendet die Anwendung direkte ODBC-Verbindungen vom Client-Standort zu unserem Rechenzentrum.
Wir müssen mit der Verschlüsselung der Anmeldeinformationen beginnen – da heute alles im Klartext vorliegt und die Authentifizierung nur schwach verschlüsselt ist – und ich versuche, die beste Möglichkeit zu finden, SSL auf dem Server zu implementieren und dabei die Auswirkungen auf den Client zu minimieren.
Ein paar Dinge jedoch:
1) Wir haben unsere eigene Windows-Domäne und alle unsere Server sind mit unserer privaten Domäne verbunden. Unsere Kunden wissen nichts von unserer Domäne.
2) Normalerweise stellen unsere Clients eine Verbindung zu unseren Rechenzentrumsservern her, indem sie a) eine TCP/IP-Adresse verwenden, b) einen DNS-Namen verwenden, den wir über das Internet veröffentlichen, Zonenübertragungen von unseren DNS-Servern an unsere Kunden durchführen oder der Client statische HOSTS-Einträge hinzufügen.
3) So wie ich es verstehe, kann ich die Verschlüsselung so aktivieren, dass ich im Netzwerkdienstprogramm die Option „Verschlüsselung“ für das Protokoll auswählen kann, das ich verschlüsseln möchte. Zum Beispiel TCP/IP.
4) Wenn die Verschlüsselungsoption ausgewählt ist, kann ich zwischen der Installation eines Drittanbieterzertifikats oder eines selbstsignierten Zertifikats wählen. Ich habe das selbstsignierte Zertifikat getestet, aber es gibt potenzielle Probleme. Ich erkläre es gleich. Wenn ich mich für ein Drittanbieterzertifikat wie Verisign oder Network Solutions entscheide, welche Art von Zertifikat beantrage ich dann? Dies sind keine IIS-Zertifikate? Wenn ich ein selbstsigniertes Zertifikat über den Zertifikatsserver von Microsoft erstelle, muss ich „Authentifizierungszertifikat“ auswählen. Was bedeutet dies in der Welt der Drittanbieter?
5) Wenn ich ein selbstsigniertes Zertifikat erstelle, ist mir bewusst, dass der Name „Ausgestellt an“ mit dem FQDN des Servers übereinstimmen muss, auf dem SQL ausgeführt wird. In meinem Fall muss ich meinen privaten Domänennamen verwenden. Wenn ich diesen verwende, was bewirkt das für meine Clients, wenn sie versuchen, eine Verbindung zu meinem SQL-Server herzustellen? Sie können meine privaten DNS-Namen in ihrem Netzwerk sicher nicht auflösen …
Ich habe auch überprüft, dass sich das selbstsignierte Zertifikat bei der Installation im lokalen persönlichen Speicher für das Benutzerkonto befinden muss, unter dem SQL Server ausgeführt wird. SQL Server wird nur gestartet, wenn der FQDN mit dem „Ausgestellt an“ des Zertifikats übereinstimmt und SQL unter dem Konto ausgeführt wird, unter dem das Zertifikat installiert ist.
Wenn ich ein selbstsigniertes Zertifikat verwende, bedeutet das, dass jeder meiner Clients es zur Überprüfung installieren muss?
6) Wenn ich ein Zertifikat eines Drittanbieters verwende, was die beste Option zu sein scheint, müssen dann alle meine Clients über Internetzugang verfügen, wenn sie auf meine privaten Server über ihre private WAN-Verbindung zugreifen, um das Zertifikat zu überprüfen?
Was mache ich mit dem FQDN? Es klingt, als müssten sie meinen privaten Domänennamen verwenden – der nicht veröffentlicht ist – und können nicht mehr den verwenden, den ich für sie eingerichtet habe?
7) Ich plane, bald auf SQL 2000 zu aktualisieren. Ist die Einrichtung von SSL mit SQL 2005 einfacher/besser als mit SQL 2000?
Jede Hilfe oder Anleitung wäre willkommen
Antwort1
Ehrlich gesagt ist es am besten, wenn Sie nicht mehr direkt auf den Datenbankserver zugreifen. Dies ist eine von Natur aus schwache Lösung (aus Sicherheitsgründen), da jeder versuchen kann, sich mit dem SA-Konto bei Ihrem SQL Server anzumelden.
Eine bessere Lösung wäre, einen Webdienst auf einem Webserver einzurichten und Ihre Anwendung Anfragen über HTTPS an diesen Webdienst senden zu lassen. Anschließend leitet der Webdienst die Anfragen an die Datenbank weiter, wobei die Datenbank vom öffentlichen Internet getrennt (oder durch eine Firewall geschützt) sein muss.
Dies bietet Ihnen außerdem den Vorteil, dass Sie die Datenbank problemlos austauschen können, da die Webserver nur mit der Datenbank kommunizieren. Außerdem können Sie die Webebene ausgleichen, sodass Sie bei wachsendem Umfang die Verbindungslast auf die Webserver verteilen können.