Open Source Personal Agenten bereits Zugang zu Unternehmensnetzwerken; Identitätskontrolle

Weniger als ein Jahr nach dem ersten Open-Source-Personal-Agenten erschienen, hat sich die Debatte von "wenn" zu "wie" bewegt, um ihre Präsenz in Unternehmensnetzwerken zu kontrollieren. Tatsachen im Bereich bestätigt: Diese Agenten - sowohl die in der Cloud des Lieferanten als auch die auf dem Computer des Benutzers laufenden - greifen bereits auf Unternehmenssysteme mit den gleichen Kanälen wie andere Anwendungen zu: OAuth-Einwilligung, Anmeldeinformationen gespeichert in Browsern, API-Schlüsseln und persönlichen Token, oder direkten Zugriff von einem Endpunkt mit lokaler Software. Was ändert, ist das Wesen, das im Auftrag des Mitarbeiters fungiert: es ist nicht nur ein Gerät oder eine App, sondern ein autonomer Agent, der umfangreiche Aktionen mit der Identität des Arbeiters orchestrieren kann.

Technisch gesehen gibt es vier Hauptvektoren, mit denen ein persönlicher Agent eine Unternehmensumgebung eingeben kann, und jeder erfordert verschiedene Kontrollen. Zuerst der OAuth-Durchfluss: der Agent fordert Berechtigungen von Google Workspace, Microsoft 365, Slack oder anderen, und der Benutzer gewährt Zugriff mit einem Klick; aus der Service-Perspektive sieht es wie die gleiche Mitarbeitersitzung. Zweite, Browser-Automatisierung und integrierte Passwort-Manager ermöglichen es einem Agenten, "sign" in einem Dienst, als wäre es der Mensch. Dritte, nicht-offizielle Integrationen können mitAPI Schlüsseloder langfristige Token, die der Benutzer erstellt und aufrecht erhält; diese Anmeldeinformationen überleben auch, wenn der Benutzer Rolle ändert. Viertens lesen lokale Agenten im Laptop des Mitarbeiters oder persönliche Server Dateien, E-Mails und Kalender direkt, wenn erlaubt.

Direkte Folge: ein persönlicher Agent erbt die Berechtigungen des Benutzers, und fordert oft viel weniger Zugriff, als es wirklich funktionieren muss. Das Risiko ist doppelt: zufällige Exposition sensibler Daten und Beharrlichkeit des Zugangs nach Beendigung der Arbeitsbeziehung. Darüber hinaus kann die Architektur des Lieferanten die Aufgabe komplizieren: Einige Lieferanten führen den Agenten in einem eigenen VM, der Token hält und die Benutzerrichtlinien implementiert, nicht die des Unternehmens, die Sitzungen und Anmeldeinformationen auf andere Infrastrukturen überträgt.

Wer beeinflusst das? An die ganze Kette: Mitarbeiter, die Agenten verwenden, um die Produktivität zu verbessern (von Entwicklern bis zum Verkaufspersonal), IT und Sicherheitsausrüstung, die Identitäten und Daten schützen müssen, und oft Dritte (Kunden oder Lieferanten), wenn die Informationen des Unternehmens unbeabsichtigt geteilt werden. Bei regulierten Organisationen steigt das Risiko der Nichteinhaltung, wenn OAuth-Konzessionen oder Token außerhalb der Kontrolle des Unternehmens liegen.

Was sicher bestätigt werden und was nicht: Es wird bestätigt, dass Agenten die üblichen Authentifizierungsmechanismen verwenden und dass es Beispiele für Agenten gibt, die mit Unternehmensdienstleistungen integrieren. Es wird auch festgestellt, dass viele Lieferanten in verwalteten Einsatzsteuerungen arbeiten. Es ist eine Schätzung - nicht eine absolute Gewissheit -, dass die meisten Unternehmen bereits persönliche Agenten ohne Aufsicht verbunden haben. Die Ungewissheit ist das genaue Ausmaß des unbeaufsichtigten Zugangs in jeder Organisation und wie sich die kurzfristigen Zuordnungs- und Offboarding-Fähigkeiten entwickeln werden.

Aus praktischer Sicht ist die Identifizierung von Identität als Kontrollebene die effektivste Strategie. Statt zu versuchen, alle Varianten zu blockieren - ein Spiel von Whac---A-Mole, dass Sie immer verlieren - es ist angemessen, anzunehmen, dass Agenten erscheinen und Design-Kontrollen auf dem Umfang, die wirklich wichtig sind: Identitäten, Token und Sitzungen. Dies beinhaltet eine zuverlässige Erkennung, Zuschreibung, Einschränkung von Privilegien und Widerrufsvorgängen.

Spezifische und handlungsfähige Maßnahmen dass ein Sicherheitsbeauftragter sofort umsetzen sollte: erstens den Zugriff von Drittanbietern und OAuth-Konzessionen in ihren Mietern (Google und Microsoft bieten administrative Kontrollen an, um Anwendungen mit Datenzugriff auf die Liste zu bringen; siehe Google Workspace-Dokumentation und Azure AD-Einwilligung). Zweitens, um geltend zu machen, dass nur zugelassene Anträge Genehmigungen durch zentralisierte Zustimmungsrichtlinien oder durch das Sperren von Benutzerzugriffen verlangen. Drittens, entfernen oder drehen Sie langfristige Token und migrieren Sie zu Authentifizierungsflüssen mit Kurzlebens-Token und delegierte Berechtigung mit minimalem Umfang. Viertens, erweitern Sie Offboarding-Politiken, um automatisierten Widerruf von OAuth-Konzessionen, Schließung von aktiven Sitzungen und Löschung von Schlüsseln, die mit dem Arbeitnehmer verbunden sind. Fünftens, implementieren Erkennung in Endpunkten und Netzwerken: EDR / SIEM und CASB oder DLP-Lösungen sollten über typische Agent-Muster (Start-up von Lieferanten-IP-Bereichen, plötzliche Erstellung von API-Schlüsseln, ungewöhnliche Verwendung von Service-Konten).

Zwei wirkungsstarke technische Maßnahmen, die wenig neue Infrastruktur erfordern: die Genehmigung der Verwaltung für Apps (das Verbieten von Genehmigungen allein durch Nutzer) zu ermöglichen und risikobasierte bedingte Zugangsrichtlinien für jede Authentifizierung mit erweiterten Genehmigungen umzusetzen. Beide reduzieren Angriffe auf Tokens-Missbrauch und werden das Problem der Sitzungen, die als ununterbrochene Mitarbeiter fungieren, mildern.

Nicht alles wird heute gelöst: offene Herausforderungen bleiben dabei, mit hoher Sicherheit zu unterscheiden, ob eine Authentifizierung vom Menschen oder seinem Agenten kommt, wenn beide Anmeldeinformationen teilen, und wie man sicherstellt, dass das "Wissen", das sich ein Agent sammelt, während des Offboardings gelöscht wird. Es fehlt auch an umfassenden Interoperabilitätsstandards für einen Administrator, um "diesen Agenten gehört dieser Person" zu sehen, ohne die Privatsphäre des Lieferanten oder Benutzers zu brechen. Da diese Kapazitäten reifen, ist die Kombination aus Identitäts-Governance, spezialisierter Erkennung und robusten Betriebsabläufen die beste Verteidigung.

Praktische und anzuwendende Referenzressourcen: der Google Workspace Apps Control Guide (https: / / support.google.com / a / reply / 7281227) und Microsofts Dokumentation zu Einwilligungen und Berechtigungen in Azure AD (https: / / learn.microsoft.com / en-us / azure / active-directory / management-apps / Zustimmung). Für technische Prinzipien zu OAuth und besten Sicherheitspraktiken ist die OWASP-Sammlung als operative Checkliste nützlich (https: / / cheatsheetseries.owasp.org / cheatsheets / OAuth2 _ Cheat _ Sheet.html).

Kurz gesagt, die Blockierung von persönlichen Agenten im Prinzip ist eine politisch verlockende, aber unpraktische Option. Die realistischste und effektive Strategie ist, den Agenten als externe Einheit zu behandeln und seinen Umfang durch Identität zu kontrollieren: Inventar und Zuschreibung, Prinzip des minderjährigen Privilegs, automatische Stornierung in Offboarding und proaktive Erkennung in Token und Sitzungen. Diejenigen, die diese Maßnahmen implementieren, werden das Risiko nicht vollständig beseitigen, sondern die Wahrscheinlichkeit und Auswirkungen von Lecks und Missbrauch durch Agenten, die mit Mitarbeiteridentitäten handeln, erheblich verringern.