Drittanbieter-Apps als Identitätsrisiko

Eine SaaS-Integration in Microsoft 365 ist nicht nur ein beschafftes Produkt: Sie kann als Service Principal mit eigenständiger Identität und weitreichenden Berechtigungen im Tenant handeln. Der Vorfall um ConnectWise Cloud Backup, vormals SkyKick, verdeutlicht die Konsequenz. ConnectWise bestätigte unbefugten Zugriff auf Anwendungsidentitäten und deaktivierte am 17. Oktober 2026 sieben betroffene App-Identitäten. Für betroffene Organisationen ist damit nicht allein die Lieferantenbewertung relevant, sondern die Frage, welche Berechtigungen eine externe Anwendung im eigenen Tenant hatte, welche Aktivitäten nachweisbar sind und wie eine kontrollierte Wiederinbetriebnahme aussehen kann.

Der Vorfall: bestätigte Erkenntnisse und Evidenzgrenzen

Nach dem technischen Untersuchungs- und Bereinigungsleitfaden von ConnectWise verhindert die Deaktivierung betroffener Verbindungen neue Authentifizierungen. Sie nimmt jedoch keine bereits im Tenant vorgenommenen Änderungen zurück. Bereits ausgestellte Tokens können bis zum Ablauf oder einer anderweitigen Invalidierung weiter nutzbar sein. Ebenso müssen zusätzlich eingerichtete Credentials, Berechtigungen oder Zugänge gesondert untersucht werden.

Unabhängige Analysen liefern wichtige, aber abgegrenzte Zusatzbefunde. Todyl berichtete aus überwachten Tenants über erfolgreiche automatisierte Anmeldungen der ConnectWise-Cloud-Backup-Anwendung am 15. Oktober 2026. Huntress beobachtete in zwei untersuchten Tenants Folgeaktivitäten, bei denen eine verwandte Anwendung sich selbst eine Global-Administrator-Rolle zuwies und anderen Anwendungen neue Secrets hinzufügte. Huntress weist zugleich darauf hin, dass frühere Konfigurationsänderungen ohne Quell-IP nicht demselben Operator zugeordnet werden konnten. Daraus folgt weder, dass jeder Tenant mit installierter Anwendung kompromittiert war, noch dass Datenabfluss generell nachgewiesen wäre.

Diese Abgrenzung ist für die Incident-Bewertung zentral: Ein gemeinsamer User Agent, eine IP-Adresse oder ein Tool-Treffer ist ein Untersuchungsanlass, aber kein abschließender Nachweis für Kompromittierung oder Exfiltration.

Warum Multi-Tenant-Apps privilegierte Identitäten sind

Microsoft Graph unterscheidet delegierte Berechtigungen von Anwendungsberechtigungen. Beim delegierten Zugriff handelt eine Anwendung im Kontext eines angemeldeten Benutzers. Beim App-only-Zugriff handelt sie dagegen mit ihrer eigenen Identität, ohne Benutzeranmeldung. Anwendungsberechtigungen können Zugriff auf sämtliche Daten erlauben, die von der jeweiligen Berechtigung erfasst sind. Microsoft empfiehlt das delegierte Modell, wenn die fachliche Anforderung damit erfüllt werden kann.

Im Tenant erscheint eine externe Multi-Tenant-Anwendung typischerweise als Enterprise Application beziehungsweise Service Principal. Die zentrale App-Registrierung und die vom Anbieter verwalteten Credentials liegen jedoch im Herausgebertenant. Kundenseitige Administratoren können diese zentralen Elemente nicht einsehen. Sie können und sollten aber den lokalen Service Principal prüfen: erteilte delegierte und Application Permissions, lokale Credentials, Owners, Rollen, Consent-Vorgänge und Audit-Aktivitäten.

Die Risikokonzentration entsteht, wenn ein Credential im Herausgeberkontext für eine Anwendung nutzbar ist, die in vielen Kundentenants mit umfangreichen Berechtigungen konsentiert wurde. Das ist kein genereller Befund zu jeder SaaS-Anwendung. Es begründet aber eine andere Governance-Kategorie als bei einer gewöhnlichen Produktivitätsintegration.

MFA und Benutzerkontrollen reichen nicht aus

Service-Principal-Sign-ins sind eigenständige, nicht benutzerbezogene Anmeldeereignisse. Eine Anwendung oder ein Service Principal authentifiziert sich beispielsweise mit Client Secret oder Zertifikat. Deshalb begrenzen MFA für Benutzerkonten und klassische, auf Benutzeranmeldungen ausgerichtete Conditional-Access-Regeln eine kompromittierte App-Identität nicht zwangsläufig.

Conditional Access für Workload Identities kann Service Principals gezielt einbeziehen. Microsoft grenzt die Funktion jedoch ausdrücklich ab: Microsoft- und Drittanbieter-SaaS-Anwendungen, einschließlich Multi-Tenant-Apps, werden nicht abgedeckt. Für eine betroffene externe Multi-Tenant-Anwendung ersetzt diese Kontrolle daher weder die Deaktivierung der Verbindung noch die Prüfung erteilter Berechtigungen. Für eigene Single-Tenant-Service-Principals kann sie dagegen eine ergänzende Schutzschicht sein.

Untersuchung in vier Beweisstufen

Die Triage sollte nicht nur zwischen „betroffen“ und „nicht betroffen“ unterscheiden. Praktikabler ist eine Befundmatrix mit getrennten, nachvollziehbaren Statuswerten:

Verdächtiger Versuch: Auffällige Indikatoren liegen vor, etwa ein passender User Agent oder IP-Treffer, aber keine bestätigte erfolgreiche Authentifizierung.
Bestätigte erfolgreiche App-Authentifizierung: Service-Principal-Sign-ins belegen, dass die Anwendung im Tenant authentifiziert wurde.
Bestätigte unautorisierte Konfigurationsänderung: Audit-Ereignisse zeigen beispielsweise neue Credentials, Owner, Rollen, Consent Grants oder App-Role-Assignments.
Möglicher oder bestätigter Ressourcenzugriff: Die vorhandene Telemetrie erlaubt eine belastbare Aussage zu Zugriffen auf Daten oder weist eine Beobachtbarkeitslücke aus.

ConnectWise verlangt eine tenantweise Untersuchung, ausdrücklich auch für verwaltete Kundentenants und ruhende Verbindungen. Die Prüfung eines MSP-Tenants ersetzt nicht die Untersuchung einzelner Kundentenants. Fehlende Daten dürfen dabei nicht als Entlastung gelten, sondern sind als dokumentierte Beobachtbarkeitslücke zu behandeln.

Telemetrie und Beweissicherung vor der Bereinigung

Vor Deaktivierung, Löschung oder Re-Consent sollten verfügbare Beweise und Konfigurationsstände gesichert werden. Dazu gehören insbesondere Service-Principal-Sign-ins, Entra-Audit-Logs, Berechtigungs- und Rollenstände sowie Metadaten zu Credentials und Owners. Der ConnectWise-Leitfaden nennt für die Directory-Audit-Prüfung vor allem Ereignisse aus ApplicationManagement, RoleManagement, Policy und UserManagement. Besonders relevant sind Credential-Änderungen, neue Service Principals, Besitzerwechsel, Consent- und App-Role-Änderungen, Rollenzuweisungen sowie Änderungen an Conditional Access oder Named Locations.

Microsoft empfiehlt ebenfalls die Überwachung privilegierter App-Berechtigungen und Rollen. Die Detektion sollte deshalb nicht nur neue Sign-in-Profile pro Service Principal umfassen, sondern auch „Add app role assignment to service principal“, delegierte Permission Grants sowie unerwartete Rollen- und Credential-Änderungen.

Die Aufbewahrung ist ein eigenständiges Risiko: Entra-Audit- und Sign-in-Logs werden je nach Lizenztyp typischerweise nur sieben oder 30 Tage standardmäßig vorgehalten. Microsoft Graph Activity Logs entstehen zudem erst nach Aktivierung der Kategorie über Diagnostic Settings und Anbindung an Speicher- oder Analyseziele. Eine langfristige, kontrollierte und möglichst manipulationsgeschützte Exportarchitektur für diese Daten sollte sich daher an Incident-, Datenschutz-, Vertrags- und Nachweisanforderungen orientieren, nicht allein an der Standard-Retention.

Containment und kontrollierte Wiederinbetriebnahme

Die Reaktion sollte nicht auf die Frage „App löschen oder behalten?“ verkürzt werden. Zunächst sind Beweise und Konfiguration zu sichern. Anschließend kann die Enterprise Application deaktiviert werden, um neue Authentifizierungen zu unterbinden. Parallel sind unautorisierte lokale Credentials, Owners, Rollen, Consent Grants und mögliche Folgeidentitäten zu untersuchen und gegebenenfalls zu entfernen. Ein vom Lieferanten bereitgestelltes Ersatz-Credential beseitigt nicht automatisch Persistenz, die ein Angreifer durch zusätzliche Secrets, Berechtigungen oder Rollen geschaffen haben könnte.

Eine Wiederfreigabe sollte erst nach formalen Anweisungen des Lieferanten und nach eigener Validierung erfolgen. Dazu gehören zumindest eine erneute Bewertung der notwendigen Berechtigungen, die Prüfung der Abhängigkeiten – etwa Backup, Wiederherstellung oder Monitoring – sowie eine dokumentierte Freigabe durch fachliche Ownership, IAM und Security. Deaktivierung ist dabei oft besser reversibel als ein vorschnelles Löschen; die konkrete Entscheidung hängt jedoch von Befund, Betriebsabhängigkeit und Wiederherstellungsweg ab.

Drittanbieter-Governance für Service Principals

Ein belastbares Inventar externer Enterprise Applications sollte mindestens App-ID, Publisher- oder Owner-Tenant, fachlichen Owner, Vertragsverantwortung, Datenklassen, verwendete APIs, delegierte und Application Permissions, Entra- oder Azure-Rollen, Consent-Historie, letzte Nutzung und Abschaltfolgen erfassen. Für Anwendungen mit breiten Application Permissions ist eine wiederkehrende Rezertifizierung durch Fachbereich, IAM und Security sinnvoll. Bleibt sie aus, kann eine risikobewertete Deaktivierung angemessen sein.

Beschaffung und Vertragsmanagement sollten bei hochprivilegierten Integrationen Anforderungen an den App-Identity-Lifecycle vereinbaren. Dazu zählen nachvollziehbarer Credential-Schutz und Rotation, unverzügliche Incident-Benachrichtigung, technische Indicators of Compromise, Unterstützung bei der tenantweisen Untersuchung, Evidenz- und Log-Verfügbarkeit, Kriterien für Wiederfreigabe sowie Exit- und Re-Consent-Verfahren.

Regulatorische und datenschutzrechtliche Einordnung

Artikel 21 der NIS2-Richtlinie verlangt für erfasste wesentliche und wichtige Einrichtungen angemessene und verhältnismäßige Cyberrisikomanagementmaßnahmen. Die Sicherheit der Lieferkette ist ausdrücklich einbezogen; direkte Lieferanten und Dienstleister, produktspezifische Schwachstellen und Cybersecurity-Praktiken sind zu berücksichtigen. Welche konkreten Pflichten für eine Organisation gelten, richtet sich jedoch nach dem anwendbaren nationalen Umsetzungsrecht und dem jeweiligen Anwendungsbereich. Der Vorfall begründet daher keine pauschale NIS2-Pflicht für jede Microsoft-365-Organisation, liefert aber einen klaren Risikokontext für Lieferanten- und Identity-Governance.

Besteht ein möglicher Zugriff auf personenbezogene Daten, ist auch die DSGVO-Schnittstelle einzelfallbezogen zu bewerten. Eine Meldung nach Artikel 33 DSGVO folgt nicht automatisch aus einem kompromittierten Service Principal. Erforderlich sind die Prüfung einer Verletzung des Schutzes personenbezogener Daten und eine dokumentierte Risikobewertung, insbesondere anhand belegter oder möglicher Zugriffe und vorhandener Beobachtbarkeitslücken. Soweit eine Meldung erforderlich ist, gilt sie nach Möglichkeit innerhalb von 72 Stunden ab Kenntnis.

Der operative Kern bleibt damit eindeutig: Externe Multi-Tenant-Apps brauchen einen benannten Owner, minimale Berechtigungen, überprüfbare Abschaltfähigkeit und ausreichend lange Telemetrie. Erst diese Verbindung aus IAM, Incident Response und Third-Party-Risk-Management macht aus einer SaaS-Integration eine steuerbare Identität.