Die Verbindung testen und Sicherheit
Was der Button Verbindung testen tut, wie die häufigsten Fehler zu lesen sind, und wie die Plattform Zugangsdaten aufbewahrt, die nie wieder auf den Bildschirm zurückkommen.
Eine Datenquelle verwahrt den Schlüssel zu einer echten Datenbank — oft zu einer Produktionsdatenbank. Diese Seite deckt beide Seiten dieser Verantwortung ab: wie Sie vor dem Speichern bestätigen, dass die Verbindung funktioniert, und was die Plattform danach mit den Zugangsdaten tut (und zu tun sich weigert).
Die Verbindung testen
Der Button Verbindung testen steht im Anlegeformular und im Modal Verbindung bearbeiten, neben den Aktionen zum Speichern:
- Füllen Sie die Verbindungsfelder aus.
- Klicken Sie auf Verbindung testen. Der Button wechselt zu Wird getestet….
- Die Plattform öffnet eine echte Verbindung zur Datenbank, führt eine harmlose Prüfabfrage aus und schließt die Verbindung wieder. Es wird nichts geschrieben und nichts geändert.
- Bei Erfolg erscheint die Bestätigung „Verbindung OK.“; bei Misserfolg erscheint eine Warnung mit der Meldung, die die Datenbank-Engine zurückgegeben hat — wortwörtlich, denn sie ist es, die sagt, was zu korrigieren ist.
Zwei Sonderfälle:
- Beim Bearbeiten mit leerem Passwort verwendet der Test das gespeicherte Passwort — er testet also die Verbindung so, wie sie nach dem Speichern sein wird.
- Bei einem noch nicht angelegten SQLite gibt es keinen Button — die Datei existiert noch nicht, und ein Test könnte dort nur lügen. Er erscheint nach dem Speichern.
Dica
Testen Sie immer vor dem Speichern. Eine falsche Verbindung zu speichern macht im Moment nichts kaputt — aber die erste API oder das erste Skript, das sie nutzt, wird fehlschlagen, und dann taucht der Fehler weit weg von seiner Ursache auf.
Der Test ist fehlgeschlagen — und jetzt?
Die Meldung kommt von der Engine und ist deshalb unterschiedlich; die Muster sind es nicht:
| Symptom | Was zu prüfen ist |
|---|---|
| Es dauert und endet im Timeout | Sind Host und Port richtig? Nimmt der Server Verbindungen von der Maschine an, auf der die Plattform läuft (Firewall, Netz)? |
| Authentifizierungsfehler / login failed | Benutzer und Passwort. In manchen Engines auch, ob dieses Konto sich von einer anderen Maschine aus verbinden darf. |
| Unbekannte Datenbank | Das Feld Database enthält den exakten Namen der Datenbank innerhalb des Servers. |
| SSL/TLS-Fehler bei einem SQL Server 2008/2012 | Schalten Sie Legacy-TLS (alter SQL Server) ein — genau dafür ist es da. |
| Zertifikatsfehler bei anderen Engines | SSL verwenden / Encrypt je nachdem, was der Server verlangt; bei internen Servern mit eigenem Zertifikat Trust server certificate. |
| Oracle findet den Dienst nicht | Folgt der Connect string dem Muster host:port/service_name? Ist der service_name der des Dienstes und nicht die SID? |
Zugangsdaten, die nie wieder auf den Bildschirm kommen
Das Passwort einer Datenquelle ist einmal schreibbar: Es geht ins Formular hinein, und von da an zeigt die Plattform es nicht wieder — niemandem, nie, auch nicht dem, der es geschrieben hat.
- Wenn Sie Verbindung bearbeiten öffnen, sind alle Felder ausgefüllt außer dem Passwort. Das Feld heißt Passwort (leer = beibehalten): leer bleibt das aktuelle bestehen; ausgefüllt ersetzt es das alte.
- Es gibt keinen Bildschirm, keinen Export und keine Berechtigung, die das Passwort im Klartext zurückgibt. Wenn Sie es verlieren, setzen Sie es auf dem Datenbankserver neu und schreiben das neue hier hinein.
- Ruhend werden die Zugangsdaten verschlüsselt — wie die Formulare selbst sagen: „Alles wird ruhend verschlüsselt.“
Nota
Das gilt für das, was die Plattform kontrolliert. Das Passwort existiert weiterhin in Ihrem Kopf, in Ihrem Passwortmanager und auf dem Datenbankserver — die Plattform garantiert nur, dass es auf dieser Seite nicht wieder auf dem Bildschirm auftaucht.
Und wenn die App auf Reisen geht?
Beim Exportieren einer App (Einstellungen → App exportieren) wählen Sie das Schicksal der Geheimnisse:
- Ohne Geheimnisse (empfohlen) — „Die Verbindungen der Datenquellen und die Secrets reisen leer mit“. Wer sie in einer anderen Installation importiert, füllt die Zugangsdaten neu aus — die Passwörter reisen nicht mit.
- Mit Geheimnissen, durch eine Passphrase geschützt — die Werte reisen verschlüsselt mit einer Passphrase mit, die Sie festlegen und die beim Import abgefragt wird. „Ohne die Passphrase sind die Geheimnisse des Pakets unwiederbringlich.“
Wer was tun darf
| Aktion | Erforderliches Profil in der App |
|---|---|
| Die Liste der Datenquellen sehen und die App nutzen | Developer |
| Datenquellen anlegen, bearbeiten, umbenennen, löschen | Administrator |
| SQL-Konsole, Objekte anlegen/ändern (DDL) | Administrator |
Deshalb sieht ein Developer womöglich weder den Button Datenquelle hinzufügen noch das Menü Verbindung bearbeiten — das ist kein Fehler, das ist das Profil.
Alles wird protokolliert
- Historie der App — jedes Anlegen, Ändern, Umbenennen und Löschen einer Datenquelle geht in die Änderungshistorie ein („Datenquelle ‚crm‘ erstellt“, „Datenquelle ‚crm‘ geändert“, …), mit Autor und Datum.
- Audit der Plattform — dieselben Operationen bleiben im Audit-Trail des Radar, mit dem Ziel Datenquelle.
- SQL-Konsole — wenn Sie SQL ausführen, das schreibt oder ändert (ein UPDATE, ein DROP…), wird das Ereignis mit der Art der Operation und einem Fingerabdruck der Query auditiert — ohne den Text des SQL, damit sensible Daten, die in der Konsole geschrieben wurden, nicht im Protokoll landen.
- Radar → Zustand — der Abschnitt Verbindungen zu Datenbanken zeigt die in allen Apps konfigurierten Verbindungen. Und das mit bewusster Vorsicht: „Diese Seite verbindet sich von selbst mit keiner davon: Es sind Produktionsdatenbanken, und bei jedem Besuch Verbindungen zu öffnen ist Traffic, den niemand bestellt hat.“
Gute Praxis
- Eigenes Konto, minimale Rechte. Legen Sie in der Datenbank einen Benutzer nur für die App an, mit Zugriff ausschließlich auf die nötigen Tabellen. Alles, was die App ausführt — APIs, Skripte, Konsole — geht über dieses Konto.
- Richten Sie die Tests auf Testdaten. Beim Testen einer schreibenden API warnt die Plattform selbst: „Der Test führt die Pipeline echt gegen die Datenquellen aus — eine Mutation schreibt wirklich. Stellen Sie sicher, dass Sie auf Testdaten zeigen.“
- Verschlüsseln Sie die Verbindung, wann immer der Server es erlaubt (SSL verwenden / Encrypt) — besonders, wenn die Datenbank in einem anderen Netz steht.
- Namen, die die Umgebung nennen.
crmundcrm-testeverhindern den schlimmstmöglichen Irrtum: an der richtigen Stelle der falschen Umgebung zu schreiben.
Häufige Fragen
- Zeigt mir Keplin das Passwort, das ich gespeichert habe? Nein. Es ist einmal schreibbar — die Alternative ist, es zu ersetzen.
- Rührt Verbindung testen die Daten an? Nein. Es öffnet die Verbindung, führt eine harmlose Prüfabfrage aus und schließt sie.
- Warum besteht der Test, aber die Query der API schlägt fehl? Der Test prüft die Verbindung, nicht die Rechte auf jede einzelne Tabelle. Wenn das Konto eine Tabelle nicht lesen oder beschreiben darf, taucht der Fehler in dieser Query auf.
- Ich habe das Passwort auf dem Datenbankserver geändert — und jetzt? Die APIs und Skripte beginnen mit einem Authentifizierungsfehler fehlzuschlagen. Öffnen Sie Verbindung bearbeiten, schreiben Sie das neue Passwort hinein und Speichern.