Bevor Sie eine Anwendung segmentieren oder migrieren können, müssen Sie eine Frage beantworten: Mit wem kommuniziert sie eigentlich? In gewachsenen Umgebungen kennt diese Antwort oft niemand mehr im Detail. Dokumentationen sind veraltet, und hinter vielen Anwendungen hängen Abhängigkeiten, die nirgends verzeichnet sind. Application Dependency Mapping (ADM) schließt diese Lücke: Es beobachtet die tatsächliche Kommunikation und macht daraus eine belastbare Karte, die Grundlage für Mikrosegmentierung und Migrationsplanung zugleich.
Was ist Application Dependency Mapping?
Application Dependency Mapping bezeichnet die automatisierte Erfassung und Visualisierung der Kommunikationsbeziehungen zwischen Anwendungen und den Systemen, auf denen sie laufen. Die Datengrundlage liefert Telemetrie aus der laufenden Umgebung: Agents auf den Workloads oder Flow-Daten aus dem Netzwerk zeichnen auf, welcher Prozess über welchen Port mit welchem Ziel spricht. Aus diesen Rohdaten entsteht eine Abhängigkeitskarte, die den Ist-Zustand zeigt statt des dokumentierten Soll-Zustands. Genau darin liegt der Wert: Die Karte bildet ab, was wirklich passiert, einschließlich der Verbindungen, von denen niemand mehr wusste. Moderne Werkzeuge verbinden dabei Sichtbarkeit und Durchsetzung: Dieselben Agents, die Flows beobachten, setzen später auch die Segmentierungsregeln um.
So funktioniert es
- Telemetrie erfassen: Agents auf Servern und Workloads oder Sensoren im Netzwerk protokollieren Verbindungen mit Prozess, Port und Gegenstelle. Die Erfassung läuft kontinuierlich, damit auch seltene Ereignisse wie Monatsabschlüsse sichtbar werden.
- Kontext anreichern: Reine IP-Adresspaare sagen wenig aus. Workloads erhalten deshalb Metadaten wie Anwendungszugehörigkeit und Umgebung. So entstehen verständliche Aussagen: Der Webshop spricht mit der Zahlungsdatenbank.
- Karte aufbauen: Die Beziehungen erscheinen als interaktive Karte, gruppiert nach Anwendungen und filterbar nach Umgebung. Da die Telemetrie laufend nachfließt, bleibt die Darstellung nahe an Echtzeit.
- Auffälligkeiten erkennen: Die Karte zeigt auch, was dort niemand erwartet: Verbindungen aus der Testumgebung in die Produktion oder Systeme, die längst abgeschaltet sein sollten.
- Richtlinien ableiten: Aus den beobachteten Flows entstehen Regelvorschläge für die Segmentierung. Diese lassen sich zunächst simulieren, um Betriebsstörungen auszuschließen, bevor sie durchgesetzt werden.
Warum es wichtig ist
- Ohne Karte keine Segmentierung: Jede Segmentierungsregel setzt Wissen über legitime Kommunikation voraus. Wer Regeln ohne diese Grundlage schreibt, riskiert Betriebsstörungen oder wirkungslose Richtlinien.
- Migrationen ohne Überraschungen: Vor einem Umzug in die Cloud oder ein neues Rechenzentrum zeigt die Karte, welche Systeme gemeinsam wandern müssen und welche Verbindungen künftig über Weitverkehrsstrecken liefen.
- Schnellere Incident-Analyse: Im Sicherheitsvorfall zeigt die Karte sofort, welche Systeme mit dem betroffenen Workload kommuniziert haben und wohin sich ein Angreifer bewegt haben könnte.
- Aufräumen mit Fakten: Die Karte entlarvt tote Verbindungen und vergessene Systeme, eine sachliche Grundlage für jede Konsolidierung.
- Belege statt Annahmen: Auditoren erhalten eine aktuelle Darstellung der Datenflüsse, etwa als Nachweis für die Trennung von Umgebungen.
Typische Szenarien
Das wichtigste Einsatzfeld ist die Vorbereitung von Mikrosegmentierung : Bevor Richtlinien den Ost-West-Verkehr im Rechenzentrum einschränken, liefert die Dependency Map ein belastbares Bild der legitimen Kommunikation. Regeln entstehen dann aus Beobachtung statt aus Vermutung. Das zweite Feld sind Migrationen: Ob Cloud-Umzug oder Rechenzentrumswechsel, die Karte definiert Move Groups, also Systeme, die wegen enger Kopplung gemeinsam migriert werden. Drittens die Modernisierung: Vor der Ablösung einer Altanwendung zeigt die Karte, wer noch von ihr abhängt. Und viertens Compliance: Wo personenbezogene oder zahlungsrelevante Daten fließen, verlangen Prüfungen einen Nachweis der tatsächlichen Datenwege. In Zero-Trust-Programmen bildet die Karte zudem den Startpunkt, weil sich Schutzziele erst formulieren lassen, wenn die realen Kommunikationspfade bekannt sind.
ADM und CMDB: die Abgrenzung
Eine Configuration Management Database verwaltet Bestandsdaten: welche Systeme existieren und wem sie gehören, ergänzt um Details wie installierte Software. Diese Sicht ist wertvoll, hat aber zwei strukturelle Schwächen. Sie wird manuell oder halbautomatisch gepflegt und veraltet deshalb schnell. Und sie kennt Konfigurationen, aber selten das tatsächliche Verhalten: Ob zwei Systeme miteinander sprechen, steht dort bestenfalls als Absichtserklärung. Application Dependency Mapping beobachtet dagegen kontinuierlich das reale Verhalten und hält sich dadurch selbst aktuell. Wo die Pflege einer CMDB Interviews und Handarbeit verlangt, liefert Telemetrie binnen kurzer Zeit ein erstes belastbares Bild. Beide Werkzeuge ergänzen sich: Die CMDB liefert Stammdaten und Verantwortlichkeiten, die Dependency Map liefert das Verhalten. Für Segmentierungs- und Migrationsentscheidungen ist die beobachtete Kommunikation die verlässlichere Quelle.
Umsetzung mit KAEMI
Für KAEMI ist die Dependency Map der erste Schritt jedes Segmentierungsprojekts. Auf Basis der Illumio-Plattform kartieren wir die Kommunikation Ihrer Workloads über Rechenzentrum und Cloud hinweg und leiten daraus Richtlinien ab, die vor der Durchsetzung simuliert werden. Das Ergebnis fließt direkt in die Mikrosegmentierung ein, mit der sich laterale Bewegungen von Angreifern wirksam eindämmen lassen. Steht eine Migration oder Umstrukturierung an, unterstützt KAEMI mit Professional Services bei Analyse und Planung auf Grundlage der erhobenen Karte. Als Managed Service Provider betreiben wir die Kartierung dauerhaft, damit sie aktuell bleibt, statt als einmalige Momentaufnahme zu enden. Den Einstieg finden Sie über Kontakt .