Encrypt the connection, and keep the credentials out of reach

Bis 4.00 hätte diese Seite schreiben müssen, dass Transportverschlüsselung auf der Roadmap steht. Das ist vorbei: 4.01 verschlüsselt Verbindungen — und führt Sie für InterSystems IRIS und Caché, wo das Einrichten von TLS bisher eine Properties-Datei, keytool und einen Neustart bedeutete, Schritt für Schritt hindurch.

Die andere Hälfte desselben Themas sind die Zugangsdaten. Eine Verbindung ist nicht durch einen verschlüsselten Transport geschützt, wenn das Passwort dahinter in einer Datei liegt, die jeder vom Rechner kopieren kann. Beide Hälften haben sich in diesem Release geändert.

Der TLS-Reiter

Beide Verbindungsdialoge — der für InterSystems und der generische JDBC-Dialog — haben einen Reiter TLS mit denselben drei Einstellungen:

Daneben stehen Serverzertifikat vertrauen und ein erwarteter Zertifikats-Hostname für generische JDBC-Verbindungen sowie ein Name der SSL-Konfiguration für IRIS und Caché. Scheitert ein Handshake, sagt die Meldung, was passiert ist und welcher dieser Schalter hilft — der Unterschied zwischen einer Fünf-Minuten-Korrektur und einem Nachmittag mit einem Paketmitschnitt.

Eine Folge sollten Sie vor dem Update kennen: SQL-Server- und Azure-SQL-Verbindungen folgen jetzt der Vorgabe des Microsoft-Treibers, und die ist verschlüsselt mit Zertifikatsprüfung. Bis 4.00 wurde jede SQL-Server-Verbindung zwangsweise unverschlüsselt geführt. Für einen Server mit selbstsigniertem Zertifikat wählen Sie Verschlüsselt (TLS) plus Serverzertifikat vertrauen; für einen Server ohne TLS Keine Verschlüsselung, dann verhält sich die Verbindung wie zuvor. Mehr zu diesem Weg unter Azure SQL und Fabric.

Der TLS-Assistent für IRIS und Caché

Eine InterSystems-JDBC-Verbindung zu verschlüsseln bedeutete bisher: eine SSL-Konfigurationsdatei von Hand schreiben, mit keytool einen Truststore bauen, die Hostnamenprüfung richtig treffen und den Client neu starten, um zu erfahren, ob irgendetwas davon funktioniert hat. Der Assistent erledigt die Reihenfolge und endet mit dem einzigen Test, der zählt.

Zu öffnen über Assistant… auf dem TLS-Reiter einer Verbindung oder über Einstellungen > InterSystems IRIS / Caché > TLS > Set up…. Er hat vier Schritte:

1. Quelle wählen für das Serverzertifikat: vom Server holen, eine vorhandene PEM-, DER- oder P7B-Datei importieren oder einen bestehenden .p12/.jks-Truststore verwenden. Jede Option hat ihre eigenen Felder direkt darunter; Host und Port stehen in einem eigenen Abschnitt darüber, weil Hostnamenprüfung und Testverbindung sie in jedem Fall brauchen.
2. Zertifikat bestätigen. Beim Holen vom Server ist das Trust-on-First-Use, und der Assistent sagt das auch: Er zeigt die Kette — Subject, Aussteller, Gültigkeit, SHA-256-Fingerabdruck — zusammen mit der nüchternen Feststellung, dass ein Abholen nur belegt, was die Gegenstelle präsentiert hat, nicht, dass sie die richtige ist. Prüfen Sie den Fingerabdruck auf einem anderen Weg nach, bevor Sie vertrauen. Die Standardschaltfläche dieses Dialogs ist Abbrechen, und es gibt kein Häkchen und keinen Timer, an dem man vorbeiklicken kann.
3. Abschnitt benennen und Vorschau ansehen. Sie sehen die genauen Zeilen, die angehängt werden, und in welche Datei. Der Assistent hängt ausschließlich an — er schreibt keine von Hand gesetzte Zeile um und überschreibt keinen bestehenden Truststore.
4. Anwenden und testen. Vor dem Test prüft eine SAN-Vorabprüfung, ob der Host, mit dem Sie sich verbinden, im Zertifikat als DNS-Eintrag steht — dieselbe Prüfung, die der Treiber macht, hier abgefangen statt später am Ende eines Stacktrace. Sie warnt, statt zu blockieren; die Schaltfläche wird zu Try anyway. Danach werden Truststore geschrieben, der Abschnitt angehängt, SSL-Konfigurationsdatei gesetzt und eine echte Testverbindung aufgebaut.

Der Abschlussbericht wiederholt den Fingerabdruck für Ihre Unterlagen und ist bei einer Grenze deutlich, die leicht übersehen wird: Der eben gebaute Truststore deckt die Superserver-Verbindung zu IRIS oder Caché ab. Er gilt nicht für den Atelier-REST-Endpunkt, den der Quellcode-Reiter und die Klassenaktionen benutzen — das ist ein eigener HTTPS-Endpunkt mit eigenem Truststore.

Passwörter, geschützt von Windows statt von der Anwendung

Gespeicherte Verbindungspasswörter sind mit Windows DPAPI geschützt. Windows verschlüsselt sie gegen Ihr eigenes Windows-Benutzerprofil, der Schlüssel ist also nicht mehr Teil der Anwendung. Daraus folgen zwei Dinge, und beide sind der Punkt:

• Eine kopierte oder gesicherte config.json gibt Ihre Passwörter nicht mehr her. Bisher reiste der Schutz mit der Datei — womit er eigentlich keiner war.
• Ein anderes Windows-Konto auf demselben Rechner kann sie nicht lesen, auch mit Zugriff auf die Datei nicht.

Die Migration passiert beim ersten Start von selbst — es geht nichts verloren, und Sie verbinden sich weiter, ohne etwas einzutippen. Weil der Schutz an Rechner und Windows-Konto gebunden ist, behält eine auf einen anderen Rechner oder in ein anderes Konto übertragene Konfiguration jede Verbindung und fragt einmal je Passwort nach. Zwei zugehörige Aufräumarbeiten kommen dazu: Extras > Alle Server-Passwörter kodieren ist entfallen, weil ein noch im Klartext gespeichertes Passwort jetzt beim Laden der Konfiguration von selbst geschützt wird — und Extras > Alte Konfigurationsdateien entfernen… listet die alten Dateien auf, in denen noch Passwörter im Format vor 4.01 liegen, mit Pfad, Größe und dem Grund der Aufnahme, und löscht nichts, bevor Sie bestätigen. Ihre aktuelle config.json wird nie angefasst.

Oder gar nichts speichern

Passwort nie speichern ist ein Schalter auf dem neuen Reiter Passwort der Verbindungseigenschaften, mit einer Vorgabe für neu angelegte Verbindungen unter Einstellungen > Verbindungen. Ist er aktiv, wird für diese Verbindung kein Passwort geschrieben: SQL DATA LENS fragt einmal und behält es nur für die laufende Sitzung. In einem Unternehmen, dessen Richtlinie gespeicherte Zugangsdaten schlicht verbietet, beendet das einmalige Setzen der Vorgabe die Diskussion.

Eine Verbindung teilen, ohne Zugangsdaten zu teilen

Üblicherweise verteilt ein Team Verbindungsdaten per Screenshot eines Dialogs oder indem jemand eine Portnummer vorliest. Team-Profile ersetzen das: Export server profile… auf einer Verbindung oder einer ganzen Gruppe schreibt eine lesbare *.sdlprofile.json, die Sie auf ein Share legen, an eine Mail hängen oder in ein Wiki kopieren können, und Add server from profile… liest sie mit einer Vorschau dessen zurück, was sie anlegen wird.

Ein Passwort enthält sie überhaupt nicht — nicht verschleiert, nicht verschlüsselt, sondern gar nicht. Wer importiert, trägt beim ersten Verbinden die eigenen Zugangsdaten ein, was auch für die Nachvollziehbarkeit die richtige Antwort ist. Beim Import eines aktualisierten Profils werden Sie gefragt, was mit einer gleichnamigen Verbindung geschehen soll: aktualisieren und alles Lokale unverändert lassen, als Kopie importieren oder überspringen.

Ist eine Verbindung erst geteilt, folgt die Frage, was man mit ihr tun darf. Das sind Umgebungen und Schreibschutz: eine Einstufung als Produktion, eine Farbe und ein Wächter, der Schreibzugriffe ablehnt.

Was hier nicht abgedeckt ist

Transportverschlüsselung und Passwortspeicherung sind zwei der Fragen eines Security-Reviews, nicht alle. Der Rest — was den Rechner verlässt, was auf dem Datenbankserver installiert wird, Telemetrie, signierte Binaries, die mitgelieferte JRE — steht unter Sicherheit und Datenschutz, wo auch jede ausgehende Verbindung der Anwendung aufgeführt ist. Wenn Sie diese Antworten auf Briefpapier statt auf einer Webseite brauchen, schreiben Sie an sales@sqldatalens.com.

Der nächste Schritt

Der TLS-Assistent ist der Teil, den man kaum glaubt, bevor man ihm zugesehen hat. Laden Sie SQL DATA LENS herunter, öffnen Sie den TLS-Reiter einer IRIS-Verbindung und lassen Sie ihn in einem Durchgang holen, prüfen, schreiben und testen.