Sophos ITDR Directory und Identity Details untersuchen

Das Directory von Sophos ITDR ist das Arbeitsinventar für Identitäten, Gruppen, Geräte und Apps, die ITDR aus den verbundenen Identitätsprovidern erfasst. Die Kennzahlenkarten zeigen die Anzahl überwachter Objekte; ein Klick öffnet die entsprechende Sicht. Für eine Untersuchung wechselt man von diesem Gesamtbestand über einen Anzeigenamen zu den Detaildaten des Objekts.

Schnellweg: Unter My Products > Identity > Directory zuerst den richtigen Tab wählen, Suche und Filter anwenden und die Datenherkunft prüfen. Bei einem Benutzer Display Name öffnen, danach in Summary, Activity Log, Findings, Insights, Group Membership und Dark Web Intelligence jeweils eine konkrete Hypothese prüfen. Ein einzelnes Tag, ein hoher Risk Score oder eine ungewöhnliche Anmeldung ist ein Priorisierungssignal, aber allein noch kein Nachweis einer Kompromittierung.

Produktgrenzen vor der Untersuchung klären

Das ITDR Directory ist nicht der Verzeichnisdienst von Sophos Fusion (ehemals Sophos Central). Es zeigt den von der ITDR-Integration oder dem ITDR-Sensor erfassten Sicherheitskontext. Dagegen stellt Global Settings > Platform > Directory service Benutzer und Gruppen für gemeinsam genutzte Central-Funktionen und Produkte bereit. Daraus folgen drei wichtige Grenzen:

• Eine fehlende Identität im ITDR Directory wird nicht durch einen erneuten Central Directory Sync behoben. Zuerst werden die ITDR-Integration, der Providerbestand und dessen Erfassungsstand geprüft.
• Ein Objekt im ITDR Directory ist nicht automatisch ein verwalteter Central-Benutzer und belegt keine Produktzuweisung oder Endpoint-Installation.
• Filter, Tags und das blosse Öffnen von Detailseiten in ITDR ändern keine Entra-ID-, Active-Directory-, Intune- oder Central-Verzeichnisobjekte. Technische Korrekturen erfolgen im führenden System und werden danach in ITDR validiert; davon getrennt können ausdrücklich autorisierte Response-Aktionen über die dafür vorgesehenen Actions-Einstiege verfügbar sein.

Auch Sophos XDR hat einen anderen Zweck. Das ITDR Directory liefert Inventar-, Posture- und Identitätskontext. Eine XDR-Abfrage oder XDR-Investigation korreliert dagegen Telemetrie und Ereignisse aus unterstützten Datenquellen. Activity Log in Identity Details ist deshalb keine vollständige XDR-Timeline, und ein ITDR-Finding ist nicht automatisch eine XDR-Detection. Für eine fallübergreifende Bedrohungsuntersuchung werden bestätigte ITDR-Hinweise mit den verfügbaren XDR-, Endpoint-, Entra- und Netzwerkdaten korreliert, ohne fehlende Telemetrie als unauffälliges Ergebnis zu interpretieren.

Den Directory-Bestand richtig lesen

Der Einstieg unter My Products > Identity > Directory bietet vier fachlich unterschiedliche Tabs:

Suchfelder grenzen die jeweilige Sicht nach Namen ein. Suche und Filter wirken nur auf die angezeigten, von ITDR erfassten Daten. Kein Treffer beweist daher weder die Nichtexistenz beim Provider noch die Löschung eines Objekts. Vor einer Eskalation werden Schreibweise, Tab, aktive Filter, Provider-Tenant und Erfassungszeitpunkt kontrolliert.

Identitäten suchen, sortieren und filtern

Identities kann als Karten- oder Listenansicht dargestellt werden. Standardmässig sind Benutzer alphabetisch sortiert. Über das Sortiermenü lässt sich beispielsweise Risk Score absteigend wählen, um die zuerst zu untersuchenden Identitäten zu finden. Search Identities filtert nach Namen.

Welche Filter sinnvoll sind, hängt von der Untersuchung ab. Für die erste Priorisierung grenzen Status den vom Identitätsprovider gemeldeten Kontostatus und Risk Severity den Bereich des berechneten Risk Score ein. Is Admin steht für den vom Provider beziehungsweise anhand erkannter privilegierter Rollen gesetzten Admin-Kontext, Is VIP für die Auswahl zum VIP Monitoring und Is Compromised für vorhandene aktive Zugangsdaten-Leaks. Is Dormant findet Konten, für die seit mehr als 90 Tagen keine Anmeldung erfasst wurde.

Für die Einordnung des Kontos stehen Department und Employee Type als Organisationsattribute zur Verfügung, sofern der Provider sie liefert. Is Guest kennzeichnet ein Gastkonto beim Identitätsprovider; Is Cloud Only ein Konto, das nur beim Cloud-Identitätsprovider und ohne lokale Identifikatoren vorhanden ist. Den MFA-Kontext liefern Has MFA, Has Passwordless MFA, Primary MFA Method und MFA Method. Nach beim Provider gepflegten Ortsattributen filtern Country und Region.

Ein leerer Filterwert ist kein negatives Ergebnis. Wenn der Provider ein Attribut nicht liefert, die Lizenz den API-Zugriff begrenzt oder Microsoft aktualisierte Daten noch nicht bereitgestellt hat, kann ITDR das Feld nicht zuverlässig befüllen. Dies gilt besonders für MFA-, Admin-, Geräte- und Aktivitätsdaten.

In der Kartenansicht blendet der Pfeil am Kartenende weitere Informationen ein; jeweils nur eine Karte kann erweitert sein. In der Listenansicht erweitert der Pfeil links eine Zeile. Über das Spaltenmenü lassen sich Spalten anheften, automatisch dimensionieren, zurücksetzen, hinzufügen oder entfernen. Diese Darstellungseinstellungen verändern weder das Objekt noch seine Bewertung.

Wenn Response-Aktionen zuvor autorisiert wurden, stehen sie für einen Benutzer über Actions in der erweiterten Karte oder über die Spalte Actions in der Listenansicht zur Verfügung. Ob ein Einstieg beziehungsweise eine Aktion verfügbar ist, hängt von Identitätsstatus und Konfiguration ab; die Ausführung setzt zudem die erforderliche Operatorberechtigung und den internen Freigabeprozess voraus. Filter, Tags und das Öffnen von Details bleiben davon getrennte, nicht verändernde Funktionen. Nach einer ausgeführten Aktion werden das Ergebnis im führenden Provider und anschliessend der aktualisierte Zustand in ITDR geprüft.

Icons und Tags als Kontext, nicht als Urteil verwenden

Icons kennzeichnen User, MFA User, Deleted User, Locked User, Admin, Guest oder Service. Die zusätzlichen Tags beschreiben verschiedene Eigenschaften und sind nicht als gemeinsames Risikourteil zu lesen: Admin bedeutet, dass das Konto als Administrator erkannt wurde, Guest bezeichnet einen Gast im Tenant, Deleted User ein beim Provider gelöschtes und Locked User ein deaktiviertes Konto.

MFA User steht für aktivierte MFA, Compromised für einen aktiven Zugangsdaten-Leak und Dormant Account für eine Identität ohne erfasste Anmeldung in den letzten 90 Tagen. Cloud Only bedeutet, dass keine lokalen Identifikatoren vorhanden sind; bei Hybrid sind lokale Identifikatoren vorhanden und zwischen Cloud und lokaler Umgebung synchronisiert. Human ordnet die Identität einem menschlichen Benutzer zu, VIP kennzeichnet die Konfiguration für VIP Monitoring.

Human und Non-Human Identity (NHI) dürfen nicht vermischt werden. Ein menschliches Konto repräsentiert eine Person. Zu NHI gehören insbesondere Service Principals, Anwendungen und andere Maschinenidentitäten. Ein Service-Icon liefert entsprechenden Kontext in der Identitätssicht; die tenant-lokalen Enterprise Applications werden im Tab Apps untersucht. Dass ein Anzeigename wie eine Person oder ein Dienst klingt, ist keine belastbare Klassifikation.

Application Object und Service Principal unterscheiden

Ein Microsoft-Entra-Application Object ist die globale Definition einer registrierten Anwendung in ihrem Home-Tenant. Es beschreibt unter anderem die Identitätskonfiguration der Anwendung und besitzt eine App beziehungsweise Client ID. Bei einem Service Principal des Typs Application ist der Service Principal die konkrete lokale Instanz dieser Anwendung in einem bestimmten Tenant. Dieser Typ referenziert das Application Object und bestimmt im betreffenden Tenant, was die App tun darf, wer darauf zugreifen kann und auf welche Ressourcen sie zugreifen darf. Diese Zuordnung gilt nicht für jeden Service-Principal-Typ: Ein Service Principal des Typs Managed identity hat kein zugeordnetes Application Object; ein Legacy Service Principal hat keine zugeordnete App-Registrierung.

Der Tab Apps zeigt die von ITDR abgerufenen Enterprise Applications im überwachten Entra-Tenant, also anwendungsbezogene tenant-lokale Instanzen, und nicht einfach eine zweite Liste globaler App-Registrierungen. Daraus darf weder geschlossen werden, dass dort jeder Service-Principal-Typ aus Entra erscheint, noch dass jeder dargestellte NHI-Kontext eine App-Registrierung besitzt. Eine mehrmandantenfähige Anwendung kann ein Application Object im Home-Tenant, aber je einen eigenen Service Principal des Typs Application in mehreren konsumierenden Tenants besitzen. Deshalb müssen Display Name, Tenant, App/Client ID, Object ID, Owner und Berechtigungen zusammen verglichen werden. Gleiche Namen bedeuten nicht dasselbe Objekt; unterschiedliche lokale Service Principals dieses Typs können auf dieselbe globale Anwendung verweisen.

Mit Display Name öffnet man App Details. Dort werden die von ITDR abgerufenen Metadaten sowie Tabellen zu App-Ownern, verknüpften Findings und Berechtigungen geprüft. Eine auffällige Berechtigung wird im Provider gegen den vorgesehenen Geschäftszweck, den Publisher, den Consent und den zuständigen Owner validiert. Die Directory-Anzeige selbst widerruft keinen Consent und entfernt keine Berechtigung.

Gruppen und Geräte untersuchen

Unter Groups lässt sich die Suche mit vier Filtern eingrenzen: Deleted steht für beim Provider gelöschte Gruppen, Mail Enabled für Gruppen, die E-Mail empfangen können, und Security Enabled für Gruppen, die Zugriffe auf Ressourcen steuern können. Assignable to Roles kennzeichnet Gruppen, denen Rollen zugewiesen werden können.

Ein Klick auf Group Name öffnet Group Details mit den abgerufenen Gruppenmetadaten sowie Tabellen der zugeordneten Benutzer, Gruppen und Anwendungen. Bei einer Zugriffsprüfung werden Gruppentyp, Owner, direkte und verschachtelte Beziehungen sowie die fachliche Notwendigkeit im führenden Provider bestätigt. Mail Enabled sagt nichts darüber aus, ob eine Gruppe für Berechtigungen verwendet wird; dafür ist Security Enabled relevant.

Unter Devices kann nach Geräten gesucht und nach State, Ownership, Operating System, Architecture, Manufacturer, Model, Rooted, Managed und Compliant gefiltert werden. Die Sicht umfasst in Microsoft Entra ID registrierte persönliche und firmeneigene Geräte. Ein Geräteobjekt ist eine Identität im Provider; Microsoft Entra registered, Microsoft Entra joined und Microsoft Entra hybrid joined sind unterschiedliche Registrierungs- beziehungsweise Join-Kontexte und nicht gleichbedeutend mit einem installierten Sophos Endpoint Agent.

Über Display Name öffnet man Device Details. Je nach Gerätetyp zeigt die Seite abgerufene Metadaten, zugeordnete Identitäten, relevante Findings und weitere verfügbare Informationen. Managed, Compliant, Rooted oder Ownership sind Providerangaben. Fehlen sie, wird der Wert für die Untersuchung als nicht verfügbar beziehungsweise unbekannt dokumentiert. Daraus dürfen die Zustände «unmanaged», «non-compliant» oder «not rooted» ebenso wenig abgeleitet werden wie persönlicher oder firmeneigener Besitz. Ein fehlender Wert ist ausserdem nicht mit einem vom Provider ausdrücklich gemeldeten Wert Unknown gleichzusetzen.

Identity Details systematisch untersuchen

In Identities öffnet ein Klick auf Display Name die Seite Identity Details. Statt jeden Tab ohne Hypothese zu lesen, empfiehlt sich folgender Ablauf:

1. Objekt bestätigen: Anzeigename, Status, Typ, E-Mail-Adressen und Providerkontext mit dem erwarteten Benutzer abgleichen.
2. Priorität verstehen: Risk Score, beitragende Faktoren, offene Findings, Compromised, Admin, MFA- und Dormant-Kontext prüfen. Ein Score priorisiert die Untersuchung, ersetzt sie aber nicht.
3. Profil und Assets plausibilisieren: Rolle, Abteilung, Region, Organisationsstruktur und zugeordnete Intune-Geräte mit dem Sollprofil vergleichen.
4. Aktivität untersuchen: Zeitraum setzen, erfolgreiche und fehlgeschlagene Anmeldungen, Zeiten, Länder, IP-Adressen und ASNs auf Abweichungen prüfen.
5. Verknüpfte Evidenz öffnen: Findings, Detections, Gruppen und Dark-Web-Datensätze einzeln untersuchen, statt aus einer Zusammenfassung auf die Ursache zu schliessen.
6. Im führenden System validieren: Entra ID, lokales AD, Intune und gegebenenfalls XDR-Telemetrie gegenprüfen. Technische Änderungen danach im jeweiligen führenden System vornehmen. Ist stattdessen eine ausdrücklich freigegebene ITDR-Response vorgesehen, dafür einen verfügbaren Actions-Einstieg verwenden.
7. Ergebnis nachziehen: Nach der Korrektur oder Response das Ergebnis beim Provider und in ITDR erneut kontrollieren und dokumentieren, welche Anzeige bereits aktualisiert wurde und welche noch auf den nächsten Erfassungslauf wartet.

Summary

Summary verbindet Profil, Priorität und jüngste Aktivität. Unter Details stehen die verfügbaren Entra-ID-Angaben wie Rolle, Abteilung, Status, Land und Region, Erstellungs- und Änderungszeitpunkt, letzter Passwortwechsel sowie weitere zugeordnete E-Mail-Adressen. Assets zeigt die dem Benutzer in Entra ID zugeordneten Intune-Geräte. Multi-Factor Authentication nennt MFA-Provider, primäre MFA-Methode und weitere konfigurierte MFA-Typen. Den organisatorischen Kontext liefert Organization mit Vorgesetzten, direkten Reports und Organisationsstruktur; ein Klick auf eine Person öffnet sie in einem neuen Tab.

Für die Sicherheitsbewertung zeigt Recent Detections die Open Detections der letzten sieben Tage und die Closed Detections der letzten 30 Tage; View All führt zu Insights. Risk Score enthält den aktuellen Score und die wichtigsten beitragenden Faktoren. Top Sign-in Locations fasst die häufigsten Anmeldeorte mit öffentlicher und privater IP-Aktivität zusammen. Sofern Daten vorhanden sind, gliedert Commonly Used Entities erfolgreiche Authentifizierungen der letzten 30 Tage nach IP Addresses, Browser, Asset Name und OS Version.

Unter Top Sign-in Locations > View Details erscheinen für die letzten 30 Tage insbesondere geografischer Ort, ASN und Häufigkeit der wichtigsten IP-Adressen. IP type und Login outcome dienen dort als Filter; sie werden nicht als zwingend angezeigte Ergebnisspalten vorausgesetzt. Private IP-Adressen sind nicht geografisch wie öffentliche Adressen zu interpretieren. Eine häufige Stadt kann durch VPN- oder Cloud-Egress entstehen; ein unbekanntes Land kann eine Prüfung rechtfertigen, ist aber ohne Zeit-, Geräte- und Providerkontext noch kein Vorfall.

Activity Log

Activity Log zeigt Authentifizierungsaktivität für den oben rechts gewählten Zeitraum. Total Activities, Successful Logins und Failed Logins liefern zuerst das Volumen. Für die räumliche Einordnung zeigt Top sign-in locations Länder, IP-Adressen, Anzahl und die Verteilung auf öffentliche beziehungsweise private IPs. Authentication locations ergänzt die häufigsten Authentifizierungen der letzten 30 Tage nach IP-Adresse und ASN sowie eine Suche nach Ort, IP oder ASN. Den zeitlichen Verlauf stellen Logins per day mit getrennten erfolgreichen und fehlgeschlagenen Anmeldungen und die Activity map als Heatmap nach Wochentag und Tageszeit dar.

Diese ITDR-Sicht fasst Aggregate und Muster zusammen. Sie zeigt keine Ereignistabelle, in der all diese Angaben pro Anmeldung nebeneinanderstehen. Browser, Asset Name und OS Version sind stattdessen als 30-Tage-Profilaggregate erfolgreicher Authentifizierungen unter Summary > Commonly Used Entities zu bewerten und dürfen keinem einzelnen Eintrag im Activity Log zugeschrieben werden. Für eine Ereigniskorrelation mit exaktem Zeitpunkt und Zeitzone, Ergebnis, Quell-IP, ASN, Land, Gerät, Browser, Betriebssystem oder benachbarten Detections werden die jeweils verfügbaren Entra- beziehungsweise XDR-Ereignislogs herangezogen. Häufige Fehlversuche in den ITDR-Aggregaten können Benutzerfehler, veraltete Credentials oder einen Angriff darstellen; erst die Korrelation mit Ereignisevidenz entscheidet.

Findings, Insights, Group Membership und Dark Web Intelligence

Findings listet Findings dieser Identität nach Risiko. Der vollständige Text in Recommendation erscheint beim Darüberfahren; ein Klick auf den Finding-Namen öffnet die Details. Dabei werden Status, Risiko, Kategorie, betroffene Evidenz und empfohlene Behebung geprüft. Das manuelle Ändern eines Status ist nicht dasselbe wie die technische Behebung im Provider.

Insights zeigt Open Detections standardmässig für die letzten sieben Tage; der Zeitraum lässt sich über den Date Picker ändern. Closed Detections umfasst die letzten 30 Tage. Ein leerer Standardzeitraum schliesst ältere Aktivität daher nicht aus.

Group Membership listet die Gruppen des Benutzers. Das Suchfeld grenzt die Liste ein; ein Klick auf Group Name öffnet die Gruppe und ihre weiteren Mitglieder. Besonders relevant sind unerwartete privilegierte, rollenfähige, verschachtelte oder fachlich nicht mehr benötigte Mitgliedschaften. Änderungen erfolgen im führenden Provider.

Dark Web Intelligence zeigt Leak-Datensätze, die mit der Identität verknüpft sind. Über Breach Source öffnet man den jeweiligen Datensatz. Ein Datensatz dokumentiert die Offenlegung von Zugangsdaten. Für die Einordnung sind Leak-Zeitpunkt, Veröffentlichungs- beziehungsweise Breach-Kontext, Kontostatus und letzter Passwortwechsel gemeinsam zu prüfen. Der Datensatz beweist nicht automatisch, dass die aktuell verwendeten Credentials gültig sind oder dass eine Anmeldung stattgefunden hat.

Providergrenzen und Aktualisierungszeiten berücksichtigen

Sophos ITDR unterstützt Microsoft Entra ID und lokales Active Directory, doch nicht jeder Provider liefert dieselben Objekte und Felder. Cloud-spezifische Daten wie Intune-Assets, Entra-Service-Principals, MFA-Methoden oder Entra-Anmeldeaktivität können in einer rein lokalen AD-Integration fehlen. Umgekehrt erfasst der lokale ITDR-Sensor zusätzliche AD-Objekttypen für Posture-Prüfungen; das macht die Cloud-Tabs nicht automatisch vollständig.

Nach dem initialen vollständigen Entra-Abruf prüft ITDR Aktualisierungen je Datentyp in unterschiedlichen Intervallen: Benutzer-, Service-Principal-, App-, Gruppen- und Gerätedetails ungefähr alle zehn Minuten, MFA-Konfiguration ungefähr alle 15 Minuten, letzte Benutzeranmeldung ungefähr alle sechs Stunden und Domaindaten ungefähr alle 24 Stunden. Das sind Erfassungsintervalle, keine Garantie, dass Microsoft eine geänderte Quellinformation bereits über seine API liefert.

Entra ID P1 oder P2 ist für den vorgesehenen ITDR-Datenumfang erforderlich. Mit Entra ID Free sind APIs und Posture-Prüfungen eingeschränkt; eine Integration kann deshalb Provisioning Failed zeigen. Nach einem Lizenzupgrade können Admin- oder MFA-Angaben bei Microsoft bis zu einer Woche veraltet bleiben. In diesem Fall wird zuerst der entsprechende Microsoft-Entra-Aktivitätsbericht geprüft. Ist bereits die Provideranzeige nicht aktualisiert, kann ITDR noch keinen neueren Stand darstellen.

Drittanbieter-MFA in einer älteren Okta- oder Duo-Konfiguration kann ebenfalls als nicht geschützt erscheinen, weil Entra die MFA-Information nicht auf Benutzerebene speichert. Eine Anzeige Has MFA = false darf dann nicht isoliert als Beweis fehlender MFA-Kontrolle behandelt werden. Providerkonfiguration, Conditional Access, aktuelle External Authentication Methods und ein kontrollierter Anmeldetest müssen zusammenpassen.

Validierung und Troubleshooting

Objekt fehlt oder erscheint im falschen Tab

1. Aktive Suche und Filter zurücksetzen und Schreibweise sowie alternativen Anzeigenamen prüfen.
2. Kontrollieren, ob Identities, Groups, Devices oder Apps der richtige Objekttyp ist.
3. Tenant und führenden Identitätsprovider bestätigen; bei Apps Application Object, Service Principal, App/Client ID und Object ID unterscheiden.
4. Das Objekt direkt beim Provider suchen und Status, Löschung, Gast-, Cloud-, Hybrid- oder Servicekontext prüfen.
5. Unter den ITDR-Integrationseinstellungen Zustand und letzten erfolgreichen Abruf prüfen. Nicht ersatzweise Central Directory Sync neu starten.
6. Erst nach dem datentypspezifischen Erfassungsfenster erneut prüfen und Zeitpunkte dokumentieren.

Filter, MFA-, Admin- oder Gerätefeld ist leer oder unerwartet

• Filter entfernen und das Rohattribut im Provider prüfen.
• Entra-Lizenz, API-Verfügbarkeit und Integrationszustand kontrollieren.
• Bei MFA zusätzlich Provider, primäre und weitere Methode sowie Drittanbieter-Konfiguration prüfen.
• Bei Geräten zwischen Registrierung beziehungsweise Join, Intune-Verwaltung, Compliance und Sophos-Endpoint-Schutz unterscheiden.
• Nach Lizenz- oder Attributänderungen nicht nur ITDR, sondern zuerst die aktualisierte Provideranzeige validieren.
• «Leer», No data oder ein fehlender Tag als unbekannt dokumentieren, nicht als «nein».

Anmeldeort oder Aktivitätsmuster wirkt verdächtig

Im Activity Log zuerst den Zeitraum sowie Anmeldevolumen, Erfolgs- und Fehlschlag-Aggregate, Länder, IP-Adressen, ASN und Tages-/Zeitmuster vergleichen. Unter Top Sign-in Locations lassen sich IP type und Login outcome als Filter einsetzen.

Browser, Asset Name und OS Version separat unter Commonly Used Entities als 30-Tage-Aggregate einordnen. Exakte Ereigniszeit und Zeitzone sowie Ergebnis, Gerät, Browser und Betriebssystem einer einzelnen Anmeldung anschliessend in den verfügbaren Entra- beziehungsweise XDR-Ereignislogs korrelieren. Dabei auch die zugehörigen Findings und Insights prüfen.

NAT, VPN, Mobilfunk, Cloud-Egress und Reisen können den angezeigten Ort verändern. Bei bestätigtem Risiko Response-Schritte nur gemäss internem Incident-Prozess und mit den erforderlichen Berechtigungen ausführen.

Anzeige nach einer Behebung verifizieren

Die technische Änderung zuerst im führenden System bestätigen. Danach den erwarteten ITDR-Erfassungszeitpunkt abwarten, Filter zurücksetzen und dieselbe Identität beziehungsweise dasselbe Objekt erneut öffnen. Geprüft werden das korrigierte Feld, abhängige Tags, zugehörige Findings und der relevante Untersuchungszeitraum. Risk Score, Findings und Providerattribute können unterschiedliche Aktualisierungszyklen haben; ein noch unveränderter Score widerlegt die erfolgreiche Quelländerung nicht. Bleibt die Anzeige über das erwartete Fenster hinaus falsch, werden Providerbeleg, Tenant, Objekt-ID, Änderungszeit, Integrationszustand und Screenshots für die Eskalation gesichert.

Untersuchung nachvollziehbar abschliessen

Zum Abschluss Objekt, Tenant, Provider und Identitätstyp dokumentieren. Ebenfalls festhalten: verwendete Suche und Filter, Untersuchungszeitraum, geprüfte Detailbereiche, fehlende Providerdaten sowie die Ergebnisse der Validierung im führenden System und in ITDR. Human- und NHI-Kontext sowie Application Object und Service Principal bleiben dabei getrennt.