Denodo absichern: TLS, Administrationskonten, AD und Rollen

Quellen- und Prüfstand: 25.10.2026 · Denodo Platform 9.5. Redaktioneller Leitfaden für eine neue selbst verwaltete Pilotinstallation. Tatsächlichen Update-, Bundle-, Treiber- und OS-Stand prüfen. Bei Updates können Menünamen und Abläufe abweichen; die verlinkte Herstellerhilfe hat Vorrang. Keine hier ausgeführte Denodo-Installation.

Was die Absicherung erreichen soll

Die fachliche Testperson soll die vereinbarte Konsumsicht lesen können. Sie soll weder Verbindungen verwalten noch zusätzliche Rohdaten sehen. Ein Administrationszugang ist dafür kein geeigneter Test. Dieses Kapitel beschreibt einen lokalen Pilotablauf; die konkrete Authentifizierung muss zu Ihrer Edition und Architektur passen.

Authentifizierung prüft, wer sich anmeldet. Autorisierung legt erlaubte Aktionen fest. Das technische Konto, mit dem Denodo auf die Quelle zugreift, ist ein dritter, eigener Prüfpunkt. Eine AD-Anmeldung vererbt nicht automatisch die passenden Quellrechte.

Lokale Administration zuerst ordnen

1. Vor einer breiteren Netzfreigabe die vorhandenen Standardzugänge inventarisieren: VDP, Web-Konfiguration von Design Studio und Marketplace sowie gegebenenfalls Scheduler. Das sind mehrere Schutzbereiche.
2. Für VDP in Design Studio unter Administration → User management einen benannten Administrationszugang gemäß IAM-Vorgabe einrichten. Die Anmeldung und benötigten administrativen Aktionen mit diesem Zugang prüfen, bevor ein bisheriger Zugang nach der freigegebenen Vorgabe stillgelegt wird. Kein ungetesteter Kontowechsel ohne Rückweg.
3. Die lokalen Einstellungsbereiche von Design Studio und Marketplace separat bearbeiten; deren Passwortänderung ist nicht durch eine bloße VDP-Kontoänderung erledigt. Für Scheduler die zu den aktivierten Komponenten gehörenden Konten erfassen.
4. Geheimnisse im vorgesehenen Secret Store hinterlegen. In Dokumentexporten nur die Referenz und die zuständige Rolle aufnehmen. Nicht ein gemeinsam genutztes Klartextpasswort in alle Tabellen kopieren.

TLS auf jedem relevanten Weg prüfen

Ein KeyStore enthält die Serveridentität mit privatem Schlüssel; ein TrustStore enthält vertrauenswürdige Zertifizierungsstellen. Eine HTTPS-Seite allein beweist noch keine verschlüsselte VDP-Clientverbindung oder Quellverbindung.

1. Pro Endpunkt DNS-Name, Zertifikatsaussteller, Laufzeit und verantwortliche Rolle festlegen. Das Zertifikat muss zum verwendeten Namen passen.
2. Nach der verlinkten TLS-Anleitung VDP-Server, eingebetteten Webserver, Administrationswerkzeuge und externe Clients getrennt konfigurieren. Die Anleitung bietet auch einen TLS-Konfigurator; Parameter immer aus dem tatsächlichen Paket übernehmen.
3. Mit einem vorgesehenen Client die Verbindung inklusive Zertifikatsprüfung herstellen. TrustStore und vollständige Zertifikatskette prüfen; Zertifikatsprüfung nicht als dauerhaften Workaround abschalten.
4. Im vereinbarten Testnetz zusätzlich einen nicht vertrauenswürdigen beziehungsweise falschen Endpunkt testen. Erwartung: keine stillschweigende Verbindung. Ergebnis und Clientversion dokumentieren.

AD/LDAP und Rechte – kontrollierter Pilot

Für eine lokale Testinstallation ist eine neue AD-/LDAP-Anbindung optional. Verwende zunächst die im vorherigen Abschnitt eingerichteten lokalen Konten. Der folgende Abschnitt gilt, wenn du ausdrücklich eine zentrale Anmeldung einrichten möchtest.

Für Active Directory kann eine passende LDAP-Anbindung Teil des Designs sein. LDAPS/Vertrauen, Suchbasis, Benutzer- und Gruppenfilter, technische Bind-Identität und Rollenzuordnung mit IAM abstimmen. Wenn föderiertes SSO vorgesehen ist, den dafür unterstützten Weg prüfen; LDAP ist nicht automatisch Entra-SSO oder SCIM.

1. Zwei Testidentitäten mit unterschiedlichen Gruppenzuordnungen bereitstellen. Anmeldung zunächst auf den Pilot begrenzen.
2. Eine fachliche Rolle wie vertrieb_leser definieren – eine Projektkonvention, keine eingebaut zugesicherte Rolle. Nur die freigegebene Sicht und erforderlichen Aktionen erlauben. Den Regelentwurf im Schutzplan dokumentieren.
3. Als Leser die Konsumsicht abfragen; dann Administration und nicht freigegebene Rohsicht versuchen. Die Gegenprobe muss scheitern. Mehrfachmitgliedschaften gesondert prüfen.
4. Eine Gruppenzuordnung im Test entziehen und nach dem festgelegten Sitzungs-/Synchronisationsverhalten erneut testen. Zeit bis zum wirksamen Entzug messen; kein sofortiges Verhalten ohne Nachweis versprechen.

Abnahme: Zugriff und Gegenproben sind mit den echten Rollen bestanden. Noch offene IAM- oder TLS-Fragen blockieren die entsprechende Freigabe, auch wenn ein Administrator alles abfragen kann.

Herstellerquellen

• Change default passwords
• TLS, KeyStore and TrustStore
• LDAP authentication