Ab Version 17.32.160 LTS, 20.0 PROD und 17.33.270 BETA hat Invantive SQL die Standardeinstellungen für Verbindungen zu MySQL, PostgreSQL und SQL Server geändert, um die Verschlüsselung des Datentransports mittels SSL zu erzwingen. Dieser Artikel gibt einige Tipps zur richtigen Konfiguration von Zertifikaten. Diese sind jedoch nur Vorschläge. Konsultieren Sie Ihren Datenbankadministrator, Sicherheitsbeauftragten oder IT-Anbieter für vertiefte Kenntnisse und die Anwendung auf Ihre lokale Situation.
Ab 20.0.112 und 20.1.261 BETA wurden die Standardeinstellungen für SQL Server optimiert: Die Standardverschlüsselung ist deaktiviert, wenn ein SQL Server-Datencontainer durch Erkennung registriert wurde und entweder mit dem Pipe-Treiber (Windows-Interne Datenbank) zugegriffen wird oder der Datenquelle/Servername keinen Dezimalpunkt (‘.’) enthält. Dies vereinfacht die Erstnutzung, da es nur wenige (wenn überhaupt) durchsuchbare lokale SQL Server-Instanzen mit richtiger Zertifikatskonfiguration gibt.
Typischer SQL Server-Fehler
Nach einem Upgrade könnten Sie auf einen Fehler mit dem Code itgenclr038, itgenclr121 oder itgenase498 stoßen, wie:
provider: SSL Provider, error: 0 - Die Zertifikatskette wurde von einer nicht vertrauenswürdigen Instanz ausgestellt.
Oder
SSL Provider, error: 0 - Der Name des Zielprinzipals ist falsch.
Typischer PostgreSQL-Fehler
Bei PostgreSQL könnten Sie auf einen Fehler stoßen wie:
Remote certificate validation failed
oder ein itgenclr072 mit einem Text wie:
AuthenticationException
Exception while performing SSL handshake.
Das Remote-Zertifikat wurde von dem bereitgestellten RemoteCertificateValidationCallback abgelehnt.
oder ein itgenclr139 Fehler wie:
SSL-Verbindung angefordert. Keine SSL-fähige Verbindung von diesem Host konfiguriert.
Typischer MySQL-Fehler
Bei MySQL könnten Sie auf einen Fehler stoßen wie:
Der Host IRGENDWAS unterstützt keine SSL-Verbindungen.
Ansatz
Die empfohlenen Schritte bei solchen Problemen sind:
- Konfigurieren Sie eine ordnungsgemäße Transportverschlüsselung.
- Prüfen Sie mit Ihrem Sicherheitsbeauftragten, ob eine unverschlüsselte und ungesicherte Datenübertragung zwischen Ihrem Invantive SQL-Knoten und der Datenbank erlaubt ist.
- Falls ja, deaktivieren Sie die jetzt standardmäßige Verschlüsselung.
Transportverschlüsselung konfigurieren
Die Transportverschlüsselung muss auf dem Client, der die Verbindung herstellt, konfiguriert werden. Bei lokalen Produkten ist dies der Server oder das Gerät, auf dem das Invantive-Produkt ausgeführt wird. Invantive Online-Produkte bieten unterschiedliche Konfigurationsmöglichkeiten, aber das Laden benutzerdefinierter oder nicht standardmäßiger Zertifikate ist in der Regel nicht möglich.
Azure
Auf Azure stellt Microsoft standardmäßig die erforderlichen Zertifikate auf dem Server bereit, die standardmäßig auf Microsoft Windows akzeptiert werden.
Stellen Sie sicher, dass Sie den richtigen Hostnamen verwenden, wie myname.database.windows.net.
Amazon
Bei Amazon müssen Sie möglicherweise die Zertifikatskette auf Ihren Client laden. Folgen Sie den Anweisungen von AWS, die normalerweise lauten:
- Laden Sie den AWS-Öffentlichen Schlüssel von https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem herunter.
- Konvertieren Sie diesen in ein Zertifikat über https://www.sslshopper.com/ssl-converter.html (konvertieren Sie in PKCS#7/P7B).
- Importieren Sie die p7b-Datei in den Zertifikatsspeicher.
Selbstverwalteter Server
Für lokale und selbst verwaltete Server konsultieren Sie bitte Ihren lokalen Administrator.
Standardverschlüsselung deaktivieren
Diese Schritte beschreiben, wie Sie eine vom Client-Software initiierte Anforderung zur Verschlüsselung deaktivieren, indem Sie die Verbindungszeichenfolge ändern. Sowohl der Datenbankserver als auch der Client müssen der Verschlüsselung zustimmen, sodass es nicht immer möglich ist, eine clientseitige Lösung bereitzustellen.
Die Position der Verbindungszeichenfolge variiert, aber in den meisten Bereitstellungsszenarien findet man sie in settings*.xml-Dateien (Formatbeschreibung). Diese befinden sich typischerweise im %USERPROFILE%\invantive-Ordner; konsultieren Sie den Knowledge Base-Artikel 7208961 für weitere Informationen.
Innerhalb der settings*.xml-Dateien kann die Verbindungszeichenfolge als Teil einer Datencontainerdefinition vorkommen, wie:
<database
...
connectionString="Server=dbhost.com;Initial Catalog=database;Persist Security Info=False;User ID=user;Password=secret;Connection Timeout=30;"
Und in Attributen wie der für Invantive Data Replicator verwendeten Verbindungszeichenfolge:
dataCacheConnectionString="provider=SqlServer;connectionString={Server=dbhost.com;Database=database;User Id=user;Password=secret}"
Die Invantive-Dokumentation enthält weitere Hintergrundinformationen zur Einrichtung der settings*.xml-Dateien. Alternativ kann Ihnen Ihr lokaler Datenbankadministrator möglicherweise helfen.
SQL Server-Änderung
Als ersten Schritt könnten Sie weiter Verschlüsselung verwenden, aber einige Angriffe zulassen, indem Sie Ihre Verbindungszeichenfolge ändern, um Folgendes einzuschließen:
hostNameInCertificate=*.domain.name
Alternativ möchten Sie möglicherweise weiterhin Verschlüsselung verwenden, aber weitere Angriffe wie Instanz-Mann-in-der-Mitte-Angriffe zulassen, indem Sie Ihre Verbindungszeichenfolge ändern, um Folgendes einzuschließen:
TrustServerCertificate=True
Als letzten Ausweg deaktivieren Sie die Verschlüsselung vollständig mit:
Encrypt=false
SQL Server-Beispiel
Zum Beispiel führt das vollständige Deaktivieren der SQL Server-Verschlüsselung in der oben gezeigten Verbindungszeichenfolge als Teil einer Datencontainerdefinition zu:
<database
...
connectionString="Encrypt=false;Server=dbhost.com;Initial Catalog=...original..."
Und für SQL Server, das zur Speicherung des Invantive Data Replicator-Repositorys verwendet wird:
dataCacheConnectionString="provider=SqlServer;connectionString={Encrypt=false;Server=...original...}"
PostgreSQL
Als ersten Schritt möchten Sie möglicherweise Verschlüsselung weiter verwenden, aber zusätzliche Angriffe wie Instanz-Mann-in-der-Mitte-Angriffe zulassen, indem Sie Ihre Verbindungszeichenfolge ändern, um Folgendes einzuschließen:
Trust Server Certificate=True
Als letzten Ausweg erlauben Sie das Deaktivieren der Verschlüsselung mit:
SslMode=Prefer
MySQL
Als ersten Schritt möchten Sie möglicherweise Verschlüsselung weiter verwenden, aber zusätzliche Angriffe wie Instanz-Mann-in-der-Mitte-Angriffe zulassen, indem Sie Ihre Verbindungszeichenfolge ändern, um Folgendes einzuschließen:
SslMode=VerifyCA
Als letzten Ausweg erlauben Sie das Deaktivieren der Verschlüsselung mit:
SslMode=Preferred