OAuth das leise Risiko, das Berechtigungen in Zugangstüren zu Ihren Systemen verwandelt

Die Diskussion über die Risiken künstlicher Intelligenz in Unternehmen konzentriert sich oft auf das Sichtbare: Mitarbeiter treffen sensible Daten auf öffentliche Chatbots. Es gibt jedoch eine weniger laute und schädlichere Bedrohung, die Priorität verdient: OAuth-Integrationen, die Mitarbeiter mit kritischen Anwendungen verbinden (Google Workspace, Microsoft 365, Salesforce, etc.). Im Gegensatz zu einem Gespräch mit einem LLM schafft eine OAuth-Verbindung eine dauerhafte Brücke zwischen Ihrer Umgebung und einem Drittel; diese Brücke verschwindet nicht, wenn der Benutzer mit der App aufhört und eine Lücke in einen Lieferanten in eine direkte Zugangstür zu Ihren Systemen verwandeln kann.

Der jüngste Fall, dass Vercel betroffen ist illustrativ: ein Test einer Produktivitäts-App mit Berechtigungen auf Google Workspace endete die Verbindung, die Angreifern erlaubte, nach dem Kompromiss des Lieferanten zu schwenken. Es ist eine praktische Demonstration, warum es ist nicht genug, die Daten zu kontrollieren, die in einem Chat geschrieben werden: Wir müssen die Vertrauensverhältnisse kontrollieren, die zwischen Systemen entstehen. Um eine technische Analyse des Vorfalls zu lesen und wie Token und Berechtigungen ausgenutzt wurden, steht der von Sicherheitsspezialisten veröffentlichte Forschungsbericht zur Verfügung: Auspacken der Vercel Pause.

Dies ist kein isolierter oder exklusiver Fall von "AI"-Anwendungen. In den letzten Jahren haben wir Kampagnen von Token und OAuth-basierten Angriffen gesehen, die Tausende von Organisationen getroffen haben, und die Ankunft von AI-Tools, die Orchesterflüsse zwischen Anwendungen fließen, hat nur die Angriffsfläche multipliziert. Die Angreifer haben OAuth zu einem zuverlässigen Vektor gemacht, weil ein gültiges Token in vielen Fällen so viel oder wertvoller ist als ein Anmeldedaten.

Die Auswirkungen auf die Unternehmenssicherheit sind klar und funktionsfähig: Sie müssen Bewerbungsberechtigungen als kritische Vermögenswerte behandeln. Zunächst sollte ein restriktives Standard-Einwilligungsmodell in Ihren Unternehmensidentitäten verabschiedet werden und Benutzer sollten nicht in der Lage sein, neue Anwendungen ohne Zustimmung zu verknüpfen. Google Workspace und andere Plattformen erlauben Richtlinien, den Zugriff von Drittanbietern zu verwalten; der offizielle Leitfaden zur Steuerung von Drittanbieter-Anwendungen in Google Workspace ist ein guter Ausgangspunkt für Administratoren: Verwaltung von App-Zugriffen Dritter auf Google Workspace-Daten.

Betriebshygiene ist auch wichtig: regelmäßige Audits aktiver Integrationen, Überprüfungen der für jede App beantragten Genehmigungen und die Möglichkeit, Token automatisch gegen Verpflichtungsindikatoren zu widerrufen, sind Maßnahmen, die das Expositionsfenster reduzieren. Es ist auch kritisch, Antwortverfahren zu haben, die den massiven Rückzug von Konsens und die Rotation von Schlüsseln und Token bei Kompromissen eines Lieferanten beinhalten.

Es reicht nicht aus, nur den Identitätsanbieter zu kontrollieren. Viele Verbindungen treten zwischen SaaS und SaaS auf und sind vom Hauptverwaltungspanel nicht sichtbar. Aus diesem Grund ist eine Kombination von Methoden erforderlich: Erfassen von computergestützten Anwendungen, Überwachung von Authentifizierung und Konsens vom Browser und vom SSO und Bereitstellung von Erkennung, die seltene API-Verkehrsmuster oder Off-Sedule-Zugriff identifiziert. Darüber hinaus helfen Endpoint-Kontrollen und Browser-Erweiterungsrichtlinien, Liefervektoren wie Infostealers oder Phishing zu mildern, die in Tokens Diebstahl enden.

Auf taktischer Ebene gibt es Werkzeuge und Praktiken, die am besten zusammenarbeiten: obligatorische SSO mit zentralisierten Konsens-Politiken anwenden, starke MFA (ideal mit Hardware-Schlüsseln) für High-Permissions-Konten benötigen, Anwendungsbereiche auf das erforderliche Minimum beschränken und Sicherheitsüberprüfungen an Lieferanten vor der Integration benötigen. Es ist auch nützlich, Warnungen zu implementieren, die die Erstellung von benutzerdefinierten Anwendungen erkennen und sie automatisch überprüfen.

Die Entwicklung des Angriffs - von Phishing-Kampagnen, die Anwendungen zu Lücken in Lieferanten, die Token speichern - erfordert eine Reaktion, die Governance, Technologie und Schulung kombiniert. Sicherheitsteams sollten aufhören, an diese Kongestionen als "kleine Nutzerwahlen" zu denken und sie als Vertrauensbeziehungen zu betrachten, die aktiv verwaltet werden müssen. Um die Ansicht zu erweitern, wie Browser-basierte Angriffe und OAuth das Bild ändern, gibt es aktuelle Berichte, die Techniken wie Vice-Code Phishing und andere relevante Vektoren analysieren: Gerätecode Phishing: technischer Bericht.

Wenn Ihre Organisation noch keine klare Politik zur OAuth-Integration und zur KI-Nutzung hat, ist die Zeit zum Handeln jetzt. Kleine vorbeugende Abwehrmaßnahmen - Block unbefugter Zustimmung, regelmäßige Audits, Browser-Erkennung und IDP-Kontrollen - reduzieren das Risiko, dass ein IA-Test oder Dienstprogramm zum Zugriffspfad für eine größere Lücke wird. OAuth als kritische Oberfläche zu behandeln und Kontrollen zwischen Identitätsausrüstung, Endpunktsicherheit und Anwendungsmanagement zu koordinieren ist die strategische Entscheidung, die Sie vermeiden können, dass der nächste Lieferantenvorfall.