+150 XP

Claude · Connector-Sicherheit, Berechtigungen und Governance

In dem Moment, in dem Sie Google Drive mit Claude verbinden, geben Sie einem Sprachmodell den Schlüssel zu echten Dokumenten, echten Kundennamen und echten Umsatzzahlen. Genau darum geht es, und genau deshalb gibt es diese Lektion. Connectors machen aus Claude statt einer clever formulierenden Textmaschine etwas, das in Ihre tatsächlichen Systeme greift. Die Frage ist also nicht mehr „kann es helfen“, sondern „was habe ich gerade autorisiert, und wer sieht, was als Nächstes passiert“.

Was ein Connector tatsächlich erlaubt

Ein Connector ist eine Brücke zwischen Claude und einem externen Dienst (Gmail, Google Drive, Notion, GitHub, Slack und ein wachsender Marketplace weiterer Anbieter). Unter der Haube sprechen die meisten Connectors das Model Context Protocol (MCP), den offenen Standard, den Anthropic eingeführt hat, damit KI-Anwendungen Tools aufrufen und Ressourcen aus externen Systemen lesen können. MCP kennen Sie konzeptionell bereits; hier interessiert uns, was es autorisiert.

Wenn Sie einen Connector hinzufügen, durchlaufen Sie einen OAuth-Flow. OAuth ist das „Mit Google anmelden“-Muster, das Sie überall gesehen haben: Sie melden sich auf der Seite des Anbieters an, und der Anbieter gibt Claude ein Token mit begrenzten Rechten statt Ihres Passworts. Das entscheidende Wort ist Scope. Ein Scope ist eine bestimmte, benannte Berechtigung wie „Ihre Dateien lesen“ oder „E-Mails in Ihrem Namen senden“.

Zwei Connectors mit dem Namen „Google Drive“ können sehr unterschiedliche Scopes anfordern. Einer fragt möglicherweise nur `drive.readonly` an. Ein anderer verlangt vollen Lese- und Schreibzugriff. Lesen Sie den Consent-Screen. Das ist kein juristisches Beiwerk, sondern die tatsächliche Liste dessen, was Claude ab jetzt mit Ihrem Konto tun kann.

json
{
  "connector": "google-drive",
  "scopes": [
    "https://www.googleapis.com/auth/drive.readonly",
    "https://www.googleapis.com/auth/drive.metadata.readonly"
  ],
  "access": "read-only",
  "can_write": false
}

Wenn der Consent-Screen Schreib- oder Löschrechte anfordert und Sie Claude nur zum Zusammenfassen von Dokumenten brauchen, ist das ein Missverhältnis, bei dem Sie innehalten sollten. Erteilen Sie den engsten Scope, der die Aufgabe erfüllt.

Read, Search und Act sind drei verschiedene Risikostufen

Connector-Berechtigungen laufen auf drei Verhaltensweisen hinaus, und die sind nicht gleich gefährlich.

Read erlaubt Claude, Inhalte in das Kontextfenster zu holen. Das Risiko hier ist Exposition: sensible Daten fließen in einen Prompt und von dort in Claudes Antwort, in ein Artifact oder in ein mit Kollegen geteiltes Project.

Search erlaubt Claude, Ihre Daten zu durchsuchen, um relevante Elemente zu finden. Etwas höheres Risiko, weil Claude entscheidet, was relevant ist, und Dokumente hervorholen kann, die Sie längst vergessen hatten.

Act erlaubt Claude, die Außenwelt zu verändern: eine Slack-Nachricht senden, ein GitHub-Issue anlegen, einen Kalendereintrag ändern, eine E-Mail verschicken. Diese Kategorie verdient echte Vorsicht, denn ein halluziniertes Detail oder eine falsch verstandene Anweisung hat jetzt Konsequenzen außerhalb des Chats.

Eine nützliche Gewohnheit: Wenn ein Connector handeln kann, gehen Sie davon aus, dass Claude irgendwann einmal das Falsche tun wird, und fragen Sie, ob dieser eine Fehler reparabel ist. Eine E-Mail-Vorlage an die falsche Person zu senden, ist reparabel. Einen ganzen Drive-Ordner zu löschen, nicht.

Privates Konto versus Arbeitskonto

Das ist die Unterscheidung, die die meisten falsch verstehen, und sie hat nichts damit zu tun, welche E-Mail-Adresse Sie eingetippt haben.

Wenn Sie ein privates Konto verbinden, autorisiert der Connector meist gegen *Ihre individuellen* Berechtigungen. Der Blast Radius ist alles, was Sie persönlich sehen können. Für Ihr eigenes Gmail oder Ihr eigenes Notion ist das oft unproblematisch.

Wenn Sie ein Arbeitskonto verbinden, ändern sich zwei Dinge. Erstens kann der Admin Ihrer Organisation steuern, ob Connectors überhaupt erlaubt sind, welche und für wen. In den Claude-Plänen Team und Enterprise verwalten Admins die Verfügbarkeit von Connectors und können den Marketplace einschränken. Zweitens erbt der Connector *Ihre Arbeitsberechtigungen*, die weit breiter sein können, als Sie denken: geteilte Drives, interne Wikis, Kundendaten. Claude hat über Ihr Token jetzt ein Fenster in all das.

Die Falle ist, eine Arbeitsdatenquelle in einem privaten Claude-Konto zu verbinden oder Arbeitsdaten in ein Project zu ziehen, das Sie später extern teilen. Daten, die unter den Zugriffskontrollen Ihres Unternehmens standen, unterliegen jetzt Ihrer Chat-Hygiene. Halten Sie Arbeits-Connectors in der vom Unternehmen verwalteten Claude-Organisation, wo Admin-Policy und Logging greifen.

Wenn Sie einen Workspace administrieren, setzen Sie diese Leitplanken in der Claude Connectors-Dokumentation und in den Admin-Einstellungen. Prüfen Sie sie, bevor Sie Connectors für ein Team ausrollen.

Was geloggt wird und was nicht

Ohne Audit Trail ist Governance unmöglich, also wissen Sie, was aufgezeichnet wird.

In verwalteten Plänen bietet Anthropic Admins Einblick in Connector-Nutzung und -Aktivität, und Enterprise-Pläne ergänzen detaillierteres Audit-Logging und weitere Kontrollen. Erfasst wird in der Regel: welche Connectors aktiviert sind, wer sie verbunden hat und Connector-Aktivität auf Kontoebene. Das ist Ihre Accountability-Ebene, wenn jemand fragt: „Wer hat Claude Zugriff auf das Finance-Drive gegeben?“

Was *kein* Ersatz für die Logs des Quellsystems ist: Wenn Claude über einen Connector ein Google Doc liest, kann dieser Zugriff auch in Googles Audit-Logs als Aktivität *Ihres* Kontos auftauchen, weil das OAuth-Token in Ihrem Namen handelt. Eine Connector-Aktion kann also an zwei Stellen erscheinen: in der Sicht Ihrer Claude-Organisation und in der Sicht des vorgelagerten Anbieters. Security-Teams sollten beide abbilden.

Denken Sie separat an die Modellseite. Standardmäßig legen Anthropics Commercial- und API-Bedingungen fest, dass Ihre Geschäftsdaten nicht zum Training von Modellen verwendet werden. Der Connector, der Daten hineinleitet, ändert diesen Standard nicht, aber er bedeutet, dass sensible Inhalte nun in der Konversationshistorie und möglicherweise in geteilten Projects liegen. Die Aufbewahrung *davon* richtet sich nach den Dateneinstellungen Ihres Plans, nicht nach dem Connector.

Understanding OAuth Scopes in 5 Minutes

Watch on YouTube

Marketplace und Custom Connectors

Der Connector-Marketplace senkt die Hürde, Tools hinzuzufügen, was gut ist und gleichzeitig eine Supply-Chain-Frage aufwirft. Ein Remote-MCP-Server eines Drittanbieters, den Sie verbinden, ist Code, der auf der Infrastruktur eines anderen läuft, die Daten empfängt, die Sie senden, und zurückgibt, was er will. Behandeln Sie einen neuen Connector wie die Installation einer Browser-Erweiterung: bevorzugen Sie offizielle und verifizierte Anbieter, prüfen Sie, wer den Server betreibt, und fügen Sie keine Zugangsdaten in Connectors ein, die Sie nicht bewerten können.

Wenn Ihr Team einen Custom Connector baut (einen internen MCP-Server), ist das für sensible Systeme oft der *sicherere* Weg, weil Sie Scopes, Hosting und Logging kontrollieren. Spezifikation und SDKs finden Sie auf modelcontextprotocol.io, und Anthropics Referenz-Server sind offen unter github.com/anthropics verfügbar. Eine Eigenentwicklung erlaubt Ihnen, nur die drei Tools bereitzustellen, die ein Workflow braucht, statt eine ganze API-Oberfläche.

Wissenscheck

1. Was stellt ein „Scope“ im Kontext von Connectors tatsächlich dar?

2. Warum betont die Lektion den OAuth-Flow beim Hinzufügen eines Connectors?

3. Sie brauchen Claude nur, um Dokumente in Google Drive zusammenzufassen, aber der Consent-Screen fordert vollen Lese-, Schreib- und Löschzugriff. Was ist die beste Reaktion?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE korrekten Aussagen über Connectors und das Model Context Protocol (MCP).

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE korrekten Aussagen über den Unterschied zwischen den Connector-Verhaltensweisen Read und Search.

Wählen Sie alle richtigen Antworten aus.

Eine einfache Regel dafür, was Sie verbinden

Sparen Sie sich das lange Policy-Dokument. Nutzen Sie vor jedem Connector eine Frage:

„Wenn ein Fremder genau diesen Zugriff eine Stunde lang hätte, was wäre das Schlimmste, das er tun könnte, und könnte ich es rückgängig machen?“

Dieser eine Satz zwingt Sie, gleichzeitig über Scope (welcher Zugriff), Blast Radius (wie viele Daten) und Umkehrbarkeit (Act versus Read) nachzudenken. Wenden Sie ihn so an:

  • Bedenkenlos verbinden: Read-only-Zugriff auf Daten, die Ihnen gehören, geringe Sensibilität, wo Zusammenfassen oder Suchen durch Claude echte Zeit spart. Ihre privaten Notion-Notizen. Ein öffentliches GitHub-Repo. Read-only-Drive für einen Ordner mit Entwürfen.
  • Bewusst verbinden: Arbeitsdatenquellen, aber nur innerhalb einer admin-verwalteten Claude-Organisation, mit dem engsten Scope und niemals in einem Project, das Sie extern teilen könnten. Das interne Wiki Ihres Teams, read-only.
  • Nicht verbinden (oder hart absichern): Schreib- oder Löschzugriff auf Systems of Record, alles, was Kunden-PII oder regulierte Daten berührt, Finanzsysteme und Produktionsinfrastruktur, es sei denn, Ihre Organisation hat es ausdrücklich genehmigt und ein Mensch bestätigt jede Aktion. Schreibzugriff auf eine Produktionsdatenbank über einen Connector ist die Bequemlichkeit fast nie wert.

Die Asymmetrie zählt. Das falsche Dokument zu lesen, ist ein Datenschutzproblem, das Sie eingrenzen können. Claude gegen ein System of Record *handeln* zu lassen, ist ein operatives Problem, das Sie womöglich nicht zurückdrehen können.

Bei Aktionen einen Menschen in der Loop halten

Wenn Sie Connectors aktivieren, die handeln können, gestalten Sie den Workflow so, dass Claude vorschlägt und ein Mensch entscheidet. In der Praxis heißt das: Claude entwirft die Slack-Nachricht oder das GitHub-Issue und zeigt es Ihnen vor dem Senden, statt vollständig autonome Ausführung zu verdrahten. Für echte autonome Agents auf Basis des Claude Agent SDK steuern Sie das auf Code-Ebene über Tool-Berechtigungen und Bestätigungsschritte, ein tiefergehendes Thema als Connectors auf Claude.ai, das aber demselben Prinzip folgt: gefährliche Tools erfordern explizite Freigabe.

Ein schnelles Denkmodell für jeden Connector, den Sie hinzufügen:

yaml
connector: github
scope: repo-readonly        # der engste, der funktioniert
account: work-managed-org   # nicht privat
shared_in_projects: false   # externes Abfließen vermeiden
can_act: false              # nur lesen; keine Issue-/PR-Schreibrechte
review: human-confirms-actions

Wenn Sie diese Zeilen nicht mit Überzeugung ausfüllen können, sind Sie noch nicht bereit, diese Quelle zu verbinden.

Zugriff sauber entziehen

Berechtigungen, die Sie erteilen, müssen Sie auch entziehen können. Einen Connector in Claude zu trennen, entfernt ihn aus Ihrer App, aber der saubere Widerruf erfolgt zusätzlich beim Anbieter. Gehen Sie in die Sicherheitseinstellungen des Quelldienstes (zum Beispiel „Drittanbieter-Apps mit Kontozugriff“ in Ihrem Google-Konto) und widerrufen Sie das Token auch dort. So ist garantiert, dass die OAuth-Freigabe tot ist, selbst wenn irgendetwas gecacht wurde. Machen Sie eine regelmäßige Connector-Prüfung zur Gewohnheit: schauen Sie jedes Quartal, was verbunden ist, und entfernen Sie alles, was Sie nicht mehr nutzen. Ruhender Zugriff ist das häufigste stille Risiko.

Die wichtigsten Erkenntnisse

  • Scopes sind die eigentliche Grenze. Lesen Sie den OAuth-Consent-Screen und erteilen Sie die engste Berechtigung, die die Aufgabe erfüllt. Bevorzugen Sie read-only, sofern ein Workflow nicht wirklich handeln muss.
  • Private und Arbeitskonten sind nicht austauschbar. Halten Sie Arbeitsdatenquellen in einer admin-verwalteten Claude-Organisation, in der Policy und Logging greifen, und ziehen Sie regulierte Daten niemals in ein Project, das Sie extern teilen könnten.
  • Act ist die gefährliche Kategorie. Bei jedem Connector, der senden, schreiben oder löschen kann, sollte ein Mensch jede Aktion bestätigen. Fragen Sie sich, ob ein einzelner Fehler umkehrbar ist.
  • Nutzen Sie den Einzeiler-Test: „Wenn ein Fremder diesen Zugriff eine Stunde lang hätte, was wäre das Schlimmste, das er tun könnte, und könnte ich es rückgängig machen?“ Lassen Sie die Antwort entscheiden.
  • An der Quelle widerrufen und quartalsweise prüfen. In Claude zu trennen genügt nicht; killen Sie das Token in den Sicherheitseinstellungen des Anbieters und räumen Sie ungenutzte Connectors aus.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Connectoren nur mit Read-only-Scopes freigeben und Tokens quartalsweise beim Anbieter widerrufen
  • Wenden Sie den Fremder-mit-einer-Stunde-Test an, bevor Sie eine Datenquelle anbinden
Vollständiges Action Playbook ansehen →

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.