Jede Connection in der IDMC braucht Zugangsdaten: einen Datenbankbenutzer mit Passwort, einen Access Key oder ein Token. Spätestens bei einem Security-Review kommt dann die Frage, wo diese Passwörter eigentlich liegen und wer sie sehen kann. In diesem Artikel zeige ich euch die drei Wege, die die IDMC dafür anbietet, und für welche Vorgaben welcher Weg passt.

Genau genommen kennt die IDMC nur zwei Speicherorte, die Informatica Cloud und den lokalen Secure Agent. Der dritte Weg, ein externer Secrets Manager, ergänzt die Cloud-Speicherung: Die sensiblen Felder kommen dann aus dem eigenen Vault, alles andere bleibt in der IDMC.

Drei Speicherorte für Connection-Passwörter: verschlüsselt im IDMC-Repository der Cloud, lokal auf einem Secure Agent im Firmennetz oder in einem externen Secrets Manager, aus dem der Secure Agent das Secret zur Laufzeit holt
Speicherorte für Connection-Passwörter.

Die Einstellung „Connection Credentials“

Wo die Connection-Eigenschaften liegen, legt man im Administrator auf der Seite Settings mit der Einstellung Connection Credentials fest. Zur Wahl stehen „Informatica Cloud“ und „Local Secure Agent“. Die Einstellung gilt für alle Connections der Organisation, nicht für einzelne Connections. Wechselt man den Speicherort, verschiebt die IDMC die Connection-Eigenschaften selbst.

Variante 1: Informatica Cloud

Das ist der Standard. Die Connection-Eigenschaften samt Passwort liegen im Repository der IDMC und sind damit immer verfügbar, egal welcher Secure Agent gerade läuft. Verschlüsselt werden sie vom Key Management Service der IDMC, und Informatica sichert sie mit den Standard-Backups.

Die Schlüssel sind je Organisation eigene. Sie werden ihrerseits mit einem Master-Key im Key Management Service des Cloud-Anbieters verschlüsselt, auf dem euer POD läuft. Wer diesen Master-Key selbst halten möchte, kann Customer-managed Keys in AWS KMS, Azure Key Vault oder Google Cloud KMS einsetzen. Der KMS muss dabei beim selben Cloud-Anbieter liegen wie der POD.

Hinweis: Widerruft man einen eigenen Master-Key, ohne ihn vorher im Administrator zu deaktivieren, sperrt man laut FAQ die ganze Organisation. Die Anmeldung scheitert dann, und laufende Sitzungen werden innerhalb von zehn Minuten ungültig.

Variante 2: Local Secure Agent

Mit „Local Secure Agent“ bleiben die Connection-Eigenschaften innerhalb der eigenen Firewall. Gespeichert werden sie auf genau einem Secure Agent, nicht auf einer Agent-Gruppe, und zwar im Verzeichnis:

<Secure Agent installation directory>/apps/Data_Integration_Server/data

Die Knowledge Base nennt genauer den Unterordner connections. Verschlüsselt wird mit AES-256 im CBC-Modus, die Dateien sind also nicht lesbar. Die Schlüssel sind je Mandant eigene, und ein gemeinsames Dateisystem für mehrere Agents ist laut Knowledge Base nicht möglich.

Diese Variante hat Folgen für den Betrieb:

  • Verfügbarkeit: Der Secure Agent muss laufen, sonst laufen keine Tasks, und niemand kann mit den Connections arbeiten.
  • Sicherung: Für das Backup seid ihr selbst verantwortlich, am besten regelmäßig und besonders nach einem Wechsel des Speicherorts.
  • Kombination: Ein Secrets Manager ist mit lokal gespeicherten Credentials nicht möglich.
  • FedRAMP: In FedRAMP-Organisationen ist der lokale Speicherort nicht erlaubt.

Variante 3: Externer Secrets Manager

Wer seine Passwörter bereits zentral in einem Vault verwaltet, kann ihn an die IDMC anbinden. Unterstützt werden laut Doku drei Anbieter: AWS Secrets Manager, Azure Key Vault und HashiCorp Vault in der Cloud-Variante HCP. Je Organisation oder Sub-Organisation ist genau ein Secrets Manager möglich. Die Secure Agents holen die Zugangsdaten zur Laufzeit aus dem Vault, die übrigen Eigenschaften der Connection bleiben im Repository der IDMC. Als Vorteil nennt Informatica, dass sich die Secrets nach eigenem Plan rotieren lassen, ohne Connections, Mappings oder Tasks anzufassen.

Eingerichtet wird der Secrets Manager im Administrator auf der Seite Settings, Registerkarte Security. Über das Stift-Symbol aktiviert man „Enable Secret Vault“, wählt den Anbieter, trägt die Verbindungsdaten ein und testet die Verbindung. Die Anmeldung am Vault unterscheidet sich je Anbieter:

Anbieter Anmeldung nötige Rechte
AWS Secrets Manager IAM-Rolle, Instance Profile oder Access Key GetSecretValue, ListSecrets
Azure Key Vault App-Registrierung mit Client ID, Client Secret, Tenant ID, Vault URI Get und List auf Secrets
HashiCorp Vault (HCP) AppRole mit Role ID und Secret ID read und list, Service Tokens

In der Connection schaltet man anschließend „Use Secret Vault“ ein und für jede sensible Eigenschaft einen eigenen Schieberegler. Ins Feld kommt dann nicht mehr das Passwort, sondern der Verweis auf das Secret, etwa <secret name>:<key> für einen Schlüssel in einem JSON-Secret oder nur <secret name> für einen einfachen Wert. Bei HashiCorp Vault mit der KV-Engine in Version 2 sieht das zum Beispiel so aus:

secret/data/dwh/oracle:password

Einige Voraussetzungen sollte man vorab prüfen:

  • Speicherort: Die Einstellung „Connection Credentials“ muss auf „Informatica Cloud“ stehen.
  • Runtime: Alle Secure Agents der Runtime Environment müssen auf einer eigenen Maschine oder VM laufen und den Vault erreichen. Hosted Agent und Serverless Runtime kommen nicht an einen externen Secrets Manager heran. Seit Oktober 2025 können außerdem Elastic Runtime Environments den AWS Secrets Manager nutzen.
  • Dienst: Auf den Agents muss der zusätzliche Dienst „Secret Manager“ aktiviert sein. Er übernimmt die Kommunikation mit dem Vault.
  • Rechte: Zum Einrichten braucht man die Admin-Rolle oder die Privilegien „SMS Manage Connection“ und „SMS View Connection“.
  • Sub-Organisationen: Der Dienst muss auf einem Agent der Sub-Organisation selbst laufen. Ein Agent, den die Parent-Organisation teilt, erreicht nur deren Vault.

Abgerechnet wird der Secrets Manager über das IPU-Meter „Secrets Manager“, gezählt in „Daily connection definitions“, also in der Zahl der Connections, die an einem Tag Zugangsdaten aus dem Vault holen. Wie ihr den IPU-Verbrauch je Meter auswertet, habe ich im Artikel über den IPU-Verbrauch per REST-API beschrieben.

Hinweis: Wer den Secrets Manager wieder abschalten will, muss zuerst in allen Connections „Use Secret Vault“ deaktivieren und erst danach „Enable Secret Vault“. Die Zugangsdaten sind dann in den Connections neu einzutragen.

Export und Import

Unabhängig von der Variante gilt beim Umzug von Assets zwischen Organisationen: Die IDMC übernimmt beim Import keine Connection-Passwörter und Security-Tokens. Laut Doku trägt man sie nach dem Import in der Zielorganisation neu ein. Gibt es dort schon eine Connection mit demselben Namen, verwendet die IDMC diese und überschreibt sie nicht.

Welche Variante passt

Die drei Wege unterscheiden sich vor allem darin, wo das Passwort liegt und wer für Schlüssel und Sicherung zuständig ist:

Informatica Cloud Local Secure Agent Secrets Manager
Passwort liegt im Repository der IDMC auf einem Secure Agent im eigenen Vault
Schlüssel IDMC, optional eigener Master-Key IDMC, AES-256 Vault des Unternehmens
Verfügbarkeit immer nur, wenn der Agent läuft Agent und Vault
Sicherung Informatica ihr selbst wie euer Vault
Rotation in der IDMC pflegen in der IDMC pflegen im Vault, ohne Connection anzufassen

Wenn keine besonderen Vorgaben bestehen, reicht der Standard. Muss der Schlüssel in eurer Hand liegen, sind Customer-managed Keys aus meiner Sicht der kleinste Schritt. Dürfen Passwörter das Firmennetz nicht verlassen, bleibt die lokale Speicherung, mit dem Preis, dass ein einzelner Agent zum kritischen Punkt wird. Gibt es bereits einen zentralen Vault mit eigener Rotation, passt der Secrets Manager am besten, sofern ihr mit eigenen Secure Agents arbeitet.

Mit dem IPU-Modell sind laut Informatica alle berechtigten Cloud-Dienste enthalten. Fehlt eine der Optionen in eurer Organisation, klärt das mit Informatica.

Quellen

Ich hoffe, dass ich dem einen oder anderen mit diesem Überblick die Entscheidung erleichtern konnte.

Falls ihr Fragen dazu habt oder vor einer ähnlichen Aufgabe steht, schreibt mir gerne.