Sicherheit und täglicher Betrieb - MCP
Berechtigungen des Schlüssels
Jeder MCP-Schlüssel bekommt einen eigenen Satz Berechtigungen, unabhängig von anderen Schlüsseln desselben Kontos:
| Berechtigung | Was sie freischaltet |
|---|---|
monitoring.read | Alarme und tägliche Monitoring-Statistiken |
projects.read | die Projektliste und ihren aktuellen Zustand |
projects.write | Projekte anlegen und bearbeiten |
projects.delete | Projekte löschen |
issues.read | die Fehlerliste - nur Gruppenmetadaten |
issues.details | vollständiger Fehlerinhalt: Meldung, Absturzort, Stack |
issues.write | den Status eines Fehlers ändern |
issues.delete | Fehler löschen |
Ein Werkzeug, für das dem Schlüssel die passende Berechtigung fehlt, erscheint nicht in der Antwort von tools/list - das ist keine versteckte Option, sondern das Fehlen des Werkzeugs aus Sicht dieses Schlüssels.
issues.details ist die Ausnahme
Das ist die einzige Berechtigung, die standardmäßig nicht aktiviert ist, weil sie sensiblere Daten offenlegt als der Rest: Ohne sie liefert issues.list nur Gruppenmetadaten (Projekt-Token, Typ, Status, Ereigniszahl, Daten), und das Werkzeug issues.get existiert für diesen Schlüssel überhaupt nicht. Mit ihr bekommt die Liste zusätzlich die Fehlermeldung und den Absturzort, und issues.get liefert das vollständige Bild einer Gruppe - inklusive Stacktrace, Frames mit Codeausschnitt, Anfragedaten und Tagesverlauf. Aktiviere sie bewusst, erst wenn ein Werkzeug tatsächlich Fehler diagnostizieren soll und nicht nur zählen.
Der Umfang eines Schlüssels ist die Schnittmenge mit den Berechtigungen seines Ausstellers
Ein Schlüssel lebt nicht für sich allein - bei jeder Anfrage werden seine gespeicherten Berechtigungen mit den aktuellen Berechtigungen der Person geschnitten, die ihn ausgestellt hat. Wird diese Person herabgestuft oder ihr Konto deaktiviert, schrumpft oder erlischt der Schlüssel ab der nächsten Anfrage, ohne zusätzliche Aktion. Die Einschränkung betrifft nur das Lesen im Arbeitsspeicher - die Zeile des Schlüssels in der Datenbank bleibt unberührt, sodass die Wiederherstellung der früheren Berechtigungen des Ausstellers den vollen Umfang des Schlüssels sofort zurückgibt.
Was der MCP-Server nie herausgibt
Projektdaten enthalten nie private Schlüssel, und Fehlerdetails enthalten nie eine E-Mail-Adresse, einen Benutzernamen, eine Benutzer-ID oder eine IP-Adresse aus der Client-Nutzlast. Anfrage-Header laufen über eine Positivliste, nicht über eine Negativliste - ein neuer Authentifizierungs-Header, den ein Client zu senden beginnt, leckt nicht nur deshalb, weil ihn hier noch niemand eingetragen hat; die Zahl der ausgelassenen Header reist in der Antwort als headers_omitted mit. Werte lokaler Variablen von Stack-Frames gehen nie hinaus, und Quellcode wird nur an Frames der Client-Anwendung angehängt.
Audit und Ratenbegrenzung
Jeder Werkzeugaufruf landet im Audit-Log zusammen mit der als Hash gespeicherten IP-Adresse. Eine Anfrage, deren Origin-Header auf eine fremde Domain zeigt, endet mit 403 - ein Browser hat hier nichts zu suchen, dieser Endpunkt ist für serverseitige Clients gedacht. Die Ratenbegrenzung ist über den Token-Hash geschlüsselt, ein überlasteter Client frisst also nicht das Limit der übrigen Schlüssel des Kontos auf.