Wer eine Anwendung segmentieren oder in eine andere Umgebung verlagern will, steht vor einer scheinbar simplen Frage: Mit welchen Systemen tauscht sie Daten aus? In gewachsenen IT-Landschaften kann das oft niemand mehr verlässlich beantworten. Dokumentationen hinken der Realität hinterher, und hinter vielen Anwendungen verbergen sich Abhängigkeiten, die nirgendwo verzeichnet sind.
Application Dependency Mapping (ADM) schließt genau diese Wissenslücke. Das Verfahren zeichnet die tatsächliche Kommunikation auf und verdichtet sie zu einer belastbaren Karte – dem Fundament für Mikrosegmentierung ebenso wie für jede Migrationsplanung.
Was ist Application Dependency Mapping?
Application Dependency Mapping steht für die automatisierte Erhebung und Visualisierung der Kommunikationsbeziehungen zwischen Anwendungen und den Systemen, auf denen sie betrieben werden. Als Datenbasis dient Telemetrie aus der laufenden Umgebung: Agents auf den Workloads oder Flow-Daten aus dem Netzwerk protokollieren, welcher Prozess über welchen Port mit welcher Gegenstelle spricht.
Aus diesen Rohdaten entsteht eine Abhängigkeitskarte, die den Ist-Zustand abbildet – nicht den dokumentierten Soll-Zustand. Genau das macht sie wertvoll: Sichtbar wird, was wirklich geschieht, einschließlich der Verbindungen, die längst in Vergessenheit geraten waren. Moderne Werkzeuge koppeln Sichtbarkeit und Durchsetzung: Dieselben Agents, die den Datenverkehr beobachten, setzen später auch die Segmentierungsregeln durch.
Funktionsweise
- Telemetrie sammeln: Agents auf Servern und Workloads oder Sensoren im Netz erfassen Verbindungen samt Prozess, Port und Ziel. Die Aufzeichnung läuft dauerhaft, damit auch seltene Ereignisse wie Monatsabschlüsse ins Bild geraten.
- Kontext ergänzen: Nackte IP-Adresspaare haben wenig Aussagekraft. Workloads erhalten deshalb Metadaten wie Anwendungszugehörigkeit und Umgebung – so wird aus Rohdaten eine verständliche Aussage: Der Webshop spricht mit der Zahlungsdatenbank.
- Karte erzeugen: Die Beziehungen erscheinen als interaktive Darstellung, gruppiert nach Anwendungen und filterbar nach Umgebung. Weil laufend neue Telemetrie einfließt, bleibt die Karte nahe an Echtzeit.
- Abweichungen aufspüren: Die Karte zeigt auch Unerwartetes – Verbindungen aus der Testumgebung in die Produktion oder Systeme, die eigentlich außer Betrieb sein sollten.
- Regeln ableiten: Aus den beobachteten Flows entstehen Vorschläge für Segmentierungsrichtlinien. Vor der Durchsetzung lassen sie sich simulieren, um Störungen des Betriebs auszuschließen.
Warum es wichtig ist
- Segmentierung braucht Fakten: Jede Segmentierungsregel setzt Wissen über legitime Kommunikation voraus. Ohne diese Grundlage drohen Betriebsstörungen oder wirkungslose Richtlinien.
- Migrationen ohne böse Überraschungen: Vor einem Umzug in die Cloud oder ein neues Rechenzentrum zeigt die Karte, welche Systeme zusammen wandern müssen und welche Verbindungen künftig über Weitverkehrsstrecken liefen.
- Schnellere Vorfallsanalyse: Bei einem Sicherheitsvorfall ist sofort ersichtlich, welche Systeme mit dem betroffenen Workload kommuniziert haben und wohin sich ein Angreifer bewegt haben könnte.
- Aufräumen auf Basis von Daten: Tote Verbindungen und vergessene Systeme werden sichtbar – eine sachliche Grundlage für Konsolidierungen.
- Nachweise statt Annahmen: Auditoren erhalten eine aktuelle Darstellung der Datenflüsse, etwa als Beleg für die Trennung von Umgebungen.
Typische Einsatzfelder
Das wichtigste Einsatzfeld ist die Vorbereitung von Mikrosegmentierung: Bevor Richtlinien den Ost-West-Verkehr im Rechenzentrum begrenzen, liefert die Dependency Map ein verlässliches Bild der legitimen Kommunikation – Regeln entstehen aus Beobachtung, nicht aus Vermutung. Das zweite Feld sind Migrationen: Ob Cloud-Umzug oder Rechenzentrumswechsel, die Karte definiert Move Groups, also eng gekoppelte Systeme, die gemeinsam umziehen. Drittens die Modernisierung: Vor der Abschaltung einer Altanwendung zeigt die Karte, wer noch von ihr abhängt. Viertens Compliance: Wo personenbezogene oder zahlungsrelevante Daten fließen, verlangen Prüfungen einen Nachweis der realen Datenwege. In Zero-Trust-Programmen markiert die Karte zudem den Startpunkt, weil sich Schutzziele erst formulieren lassen, wenn die tatsächlichen Kommunikationspfade bekannt sind. In der Praxis übernehmen spezialisierte Managed-Service-Provider die Kartierung als Dauerbetrieb – etwa im Rahmen einer gemanagten Mikrosegmentierung –, damit sie aktuell bleibt, statt als einmalige Momentaufnahme zu enden.
Abgrenzung zur CMDB
Eine Configuration Management Database (CMDB) führt Bestandsdaten: welche Systeme existieren, wem sie gehören, ergänzt um Details wie installierte Software. Diese Sicht ist nützlich, hat aber zwei strukturelle Schwächen. Sie wird manuell oder halbautomatisch gepflegt und veraltet dadurch schnell. Und sie kennt Konfigurationen, aber kaum das reale Verhalten: Ob zwei Systeme tatsächlich miteinander sprechen, steht dort bestenfalls als Absichtserklärung.
Application Dependency Mapping beobachtet dagegen fortlaufend das reale Verhalten und aktualisiert sich dadurch selbst. Wo die CMDB-Pflege Interviews und Handarbeit erfordert, liefert Telemetrie binnen kurzer Zeit ein erstes belastbares Bild. Beide Werkzeuge ergänzen sich: Die CMDB steuert Stammdaten und Verantwortlichkeiten bei, die Dependency Map das Verhalten. Für Segmentierungs- und Migrationsentscheidungen ist die beobachtete Kommunikation die verlässlichere Quelle.
Häufige Fragen
Warum setzt Mikrosegmentierung eine Dependency Map voraus?
Segmentierungsregeln legen fest, welche Kommunikation erlaubt bleibt. Ohne Kenntnis der realen Verbindungen ist jede Regel Spekulation: Zu strenge Richtlinien unterbrechen Geschäftsprozesse, zu lockere verfehlen ihr Schutzziel. Die Dependency Map liefert die Faktenbasis und ermöglicht es, geplante Regeln vorab zu simulieren. Durchgesetzt wird erst, wenn keine legitime Verbindung mehr blockiert würde.
Genügt eine gut gepflegte CMDB nicht als Grundlage?
Als Inventar ja, als Entscheidungsbasis für Segmentierung oder Migration selten. Eine CMDB dokumentiert Bestände und Zuständigkeiten, altert aber schnell und beschreibt Absichten statt beobachtetes Verhalten. Application Dependency Mapping misst die tatsächliche Kommunikation kontinuierlich. Sinnvoll ist die Kombination: Stammdaten aus der CMDB geben der beobachteten Karte Kontext und Verantwortliche.
Woher kommen die Daten für die Dependency Map?
Die verlässlichste Quelle sind schlanke Agents auf den Workloads, die Verbindungen samt zugehörigem Prozess registrieren – im Rechenzentrum wie in der Cloud. Ergänzend oder alternativ dienen Flow-Daten aus der Netzwerkinfrastruktur und Metadaten der Cloud-Plattformen. Entscheidend ist die fortlaufende Erfassung: Eine einmalige Momentaufnahme übersieht seltene, aber geschäftskritische Verbindungen.
Wie schnell entsteht eine belastbare Karte?
Erste Einblicke gibt es kurz nach der Anbindung der Workloads. Für eine tragfähige Entscheidungsgrundlage empfiehlt sich ein Beobachtungszeitraum von mehreren Wochen, damit auch periodische Ereignisse wie Monats- oder Quartalsabschlüsse erfasst werden. Die Dauer richtet sich nach Größe und Dynamik der Umgebung. Danach hält die laufende Telemetrie die Karte dauerhaft aktuell.
Unterstützt Application Dependency Mapping auch Migrationen?
Ja – es zählt zu den wichtigsten Instrumenten der Migrationsplanung. Die Karte weist eng gekoppelte Systeme aus, die als Move Group gemeinsam umziehen sollten. Sie zeigt, welche Verbindungen nach dem Umzug über Weitverkehrsstrecken laufen würden und Latenzprobleme riskieren. Nach der Migration belegt sie, dass keine übersehene Abhängigkeit ins alte Umfeld zurückführt.