Basic-Authentifizierungsbenutzernamen sind sensible Metadaten

Basic-Authentifizierungsbenutzernamen sind sensible Metadaten.

Diese Aussage klingt kleinlich, bis ein Automatisierungslauf billing-export@north-division in ein Shell-Protokoll, ein CI-Log, einen Agenten-Prompt und ein Incident-Ticket kopiert. Das Passwort fehlt vielleicht an allen vier Stellen. Ein Angreifer erfährt trotzdem, dass ein Mandant namens north-division existiert, dass er eine Integration für Rechnungsexporte besitzt und dass das Konto wahrscheinlich eine bestimmte Legacy-API erreicht.

Teams teilen Daten oft in Geheimnisse und alles andere ein. Für agentengesteuerte API-Arbeit ist diese Trennung zu grob. Ein Benutzername, eine Mandantenkennung, ein Hostname, ein API-Pfad und ein Antwortcode können einzeln harmlos wirken. Zusammen beschreiben sie eine Kontostruktur, die einen Angriff wert ist. Behandle solche Kombinationen als sensible Metadaten, besonders wenn ein Agent Kontext deutlich weiter und schneller kopieren kann als jemand, der eine einzelne Anfrage eintippt.

Ein Benutzername kann zeigen, wie das Kontosystem aufgebaut ist

Ein Basic-Benutzername bedeutet oft mehr, als sein Feldname vermuten lässt. Legacy-Systeme verwenden ihn als Login-Namen, Kundencode, Bereichsbezeichnung, Servicerolle, Umgebungsmarker oder zusammengesetzte Kennung, die erstellt wurde, bevor es ein besseres Identitätsmodell gab.

Betrachte diese Werte:

acme-east:password
svc-payroll-prod:password
tenant-48291-export:password
[email protected]:password

Der erste Wert nennt einen Kunden und eine regionale Aufteilung. Der zweite benennt eine interne Fähigkeit und eine Umgebung. Der dritte verrät eine Mandantenkennung und eine Funktion. Der vierte legt eine Person und ihre Kundenbeziehung offen. Eine Passwortrotation behebt die Passwortseite. Die kopierte Kontokarte verschwindet dadurch nicht.

Das ist wichtig, weil Angreifer nicht jeden Angriff mit einem Zugangsdatenfund beginnen. Sie beginnen mit einer Zielliste. Ein erkennbarer Benutzername hilft ihnen, eine glaubwürdige Zurücksetzungsanfrage zu formulieren, verwandte Konten zu erraten, in geleakten Datensätzen zu suchen, einen kundenspezifischen Pfad zu testen oder den Support mit internen Details unter Druck zu setzen.

Verwirf das nicht als Theorie, nur weil der Benutzername ohne Passwort nicht gültig ist. Zu wissen, dass svc-orders-import-prod existiert, bedeutet nicht, das Konto zu kontrollieren. Es ist aber wesentlich nützlicher, als gar nichts zu wissen. Sicherheitsarbeit wird teuer, wenn Teams ein Feld erst dann schützen, wenn es ein vollständiges Zugangsdatenpaar bildet.

Die richtige Einstufung hängt vom Kontext ab. Ein allgemeiner öffentlicher Benutzername, den jedes Sandbox-Konto verwendet, braucht vielleicht wenig Schutz. Eine mandantengebundene Serviceidentität zusammen mit einem internen Endpunkt verdient deutlich strengere Behandlung. Halte diese Unterscheidung für jede Integration fest, statt nach einem Leak pauschale Regeln anzuwenden.

Basic-Authentifizierung hängt den Kontonamen an jeden Aufruf

Basic-Authentifizierung sendet einen als Base64 dargestellten Wert user-id:password im HTTP-Header Authorization. Base64 ändert die Darstellung. Die ursprünglichen Bytes bleiben für jeden sichtbar, der den Header lesen kann.

Eine typische Anfrage sieht so aus:

GET /v1/exports/monthly HTTP/1.1
Host: api.legacy.example
Authorization: Basic c3ZjLWJpbGxpbmctZXhwb3J0LXByb2Q6cmVkYWN0ZWQ=
Accept: application/json

Der codierte Text enthält beide Teile bei jedem API-Aufruf. Diese Wiederholung wird leicht vergessen. Natürlich kann auch ein Bearer-Token Kontokontext offenlegen, aber viele Basic-Integrationen verwenden lesbare Benutzernamen, die ihn nach dem Dekodieren direkt nennen.

RFC 7617 definiert das Verfahren und nennt zwei hier wichtige Details. Der erste Doppelpunkt trennt Benutzer-ID und Passwort, deshalb ist ein Doppelpunkt im Benutzernamen ungültig. Auch Steuerzeichen sind verboten. Ein Legacy-Anbieter kann also eine scheinbar praktische Kontokonvention akzeptieren, die einen standardkonformen Basic-Header nicht überlebt. Erfinde keine Escape-Regel in der Hoffnung, dass jede Bibliothek sie gleich interpretiert.

Das zweite Detail betrifft die Zeichenbehandlung. RFC 7617 erlaubt einem Server, UTF-8 in einer Challenge anzukündigen. Dieses Signal ist jedoch unverbindlich, und viele ältere Systeme behandeln nicht-ASCII-Identitäten nicht konsistent. Wenn ein Kontoname Akzentzeichen, Groß- und Kleinschreibungsregeln oder umgewandeltes Unicode enthält, teste das genaue Client-Server-Paar vor dem Produktiveinsatz. Eine Abweichung kann zu einem Authentifizierungsfehler führen, den jemand durch das Ausgeben der vollständigen Anmeldedaten im Debug-Log zu „beheben“ versucht.

Basic-Authentifizierung braucht außerdem HTTPS. OWASP beschreibt Basic-Anmeldedaten als codiert, nicht verschlüsselt, und empfiehlt TLS überall dort, wo Basic verwendet wird. TLS schützt die Verbindung während der Übertragung. Es schützt keinen Header, nachdem eine Clientbibliothek, ein Reverse-Proxy, ein Tracing-Agent, ein Fehlerhandler oder ein Debugging-Tool ihn aufgezeichnet hat.

Mandantenkennungen und Endpunkte werden als Paar gefährlich

Eine Mandantenkennung allein kann eine undurchsichtige Zahl sein. Ein Endpunkt allein kann ein allgemeiner Pfad sein. Zusammen können beide die Geschäftsfunktion eines Kunden und das zuständige System erkennen lassen.

Angenommen, ein Agent erhält diese Anweisung:

For tenant 48291, call https://ledger.internal.example/v2/reconciliation/import
with username tenant-48291-ledger-import.

Auch wenn eine andere Komponente das Passwort einfügt, enthält die Anweisung Mandant, Host, Vorgang und Serviceidentität. Der Agent kann sie in seine Arbeitsnotizen übernehmen. Ein Tool-Wrapper kann sie protokollieren. Ein Modelltranskript kann sie speichern. Ein Entwickler kann den Fehler in einen Chatkanal kopieren. Das Passwort blieb verborgen, die Kontostruktur jedoch nicht.

Die Offenlegung nimmt zu, wenn Namen einer vorhersehbaren Grammatik folgen. Wenn ein Benutzername tenant-48291-ledger-import lautet, liegt es nahe, auch tenant-48291-ledger-export, tenant-48291-reporting oder dieselben Rollen für andere Mandanten zu vermuten. Vorhersehbarkeit ist für Betreiber bequem und für das Aufzählen von Konten nützlich. Du musst alle Namenskonventionen aufgeben, solltest aber erkennen, wann eine Konvention aus einem geleakten Namen eine Verzeichnisabfrage macht.

Auch Endpunktpaare tragen Informationen. /admin/users, /payroll/export, /claims/submit und /archive/retention zeigen unterschiedliche Arten von Arbeit, selbst bei einem neutralen Hostnamen. Host plus Pfad plus Mandant liefern oft genug Informationen, um eine glaubwürdige Phishing- oder Support-Imitationsnachricht zu formulieren.

Bewerte das Tupel, nicht nur seine einzelnen Felder:

• Serviceidentität plus Mandantenkennung
• Serviceidentität plus Hostname
• Mandantenkennung plus Endpunktpfad
• Endpunktpfad plus Antworttext oder Fehlermeldung
• Zeitstempel plus Protokoll eines erfolgreichen Vorgangs

Das ist eine präzisere Regel als „Passwörter entfernen“. Sie erklärt, warum eine Logzeile ohne wörtliches Geheimnis trotzdem unsicher sein kann, wenn sie an ein breit zugängliches Observability-System gesendet wird.

Agenten kopieren Kontext, den normale Clients nicht kopieren

Ein gewöhnlicher API-Client erhält URL, Kontonamen und Passwort meist über einen engen Konfigurationsweg. Ein KI-Agent verarbeitet Anweisungen als Text. Er kann ein Repository untersuchen, ein Ticket lesen, einen Befehl ausführen, einen Fehler interpretieren und eine Zusammenfassung schreiben. Bei jedem Übergang können Kennungen erhalten bleiben, die ein traditioneller Client nie anzeigen müsste.

Das Risiko besteht nicht darin, dass Agenten grundsätzlich nachlässiger sind. Agenten-Workflows machen Kontext absichtlich transportierbar. Dieselbe Funktion, die einem Agenten erlaubt, eine Bereitstellungsnotiz und eine API-Antwort gemeinsam zu verstehen, kann Mandantennamen und Endpunktmuster in Tool-Eingaben, Transkripte oder erzeugte Patches übertragen.

Ein typischer Fehler sieht so aus:

1. Ein Entwickler legt einen Basic-Benutzernamen und einen Mandantencode in eine lokale .env-Datei, weil das Passwort aus einem Secret Store kommt.
2. Der Agent liest die Datei, um eine fehlerhafte Integration zu verstehen.
3. Die API antwortet mit einem ausführlichen 401-Fehler, der Benutzername und Mandant wiederholt.
4. Der Agent schreibt einen Fehlerbericht mit Konfigurationsauszug und Fehlermeldung.
5. Der Entwickler kopiert den Bericht in ein für eine größere Gruppe sichtbares Issue.

Niemand wollte Zugangsdaten veröffentlichen. Trotzdem enthält das Issue nun ein gültiges Namensmuster, einen Mandanten, einen Host, einen Pfad, eine Servicerolle und ein Zeitfenster, in dem die Integration aktiv war. Dieser Kontext reicht aus, um Folgerisiken zu schaffen.

Löse das nicht, indem du Agenten jeden nicht geheimen Text vorenthältst. Das blockiert nützliche Arbeit und scheitert in der Praxis meist. Entscheide stattdessen, welche Aktion welche Fakten braucht. Ein Agent, der einen monatlichen Export anfordern soll, braucht vielleicht nur einen abstrakten Aktionsnamen und einen Monat. Er braucht weder Basic-Benutzernamen noch Passwort, Mandantenrouting oder rohe Ziel-URL.

Damit ändert sich die Designfrage von „Kann der Agent sich authentifizieren?“ zu „Welche kleinste Aktionsbeschreibung braucht der Agent, um die gewünschte Anfrage zu erzeugen?“ Diese Frage hält die Kontostruktur aus dem Kontextfenster des Agenten heraus.

Identitätsdaten aus Prompts und Repositories heraushalten

Ein Prompt ist kein guter Konfigurationsspeicher. Dasselbe gilt für Quelldateien, beispielhafte curl-Befehle, Issue-Vorlagen, Shell-Aliase und Test-Fixtures. Sie gelangen alle weiter, als ihr Autor erwartet.

Trenne zunächst drei Dinge, die Teams häufig vermischen:

1. Zugangsdaten sind Benutzername und Passwort für die Authentifizierung.
2. Routing-Metadaten zeigen, wohin eine Anfrage geht, etwa Host, Mandantenpartition oder Endpunktfamilie.
3. Aktionsabsicht ist der Geschäftsvorgang, etwa „die Abstimmungsdatei für März herunterladen“.

Ein Mensch oder Agent kann die Aktionsabsicht oft nennen, ohne die beiden anderen Kategorien zu sehen. Das ist die bevorzugte Grenze. Wenn eine Legacy-API Routing über einen mandantenspezifischen Host oder Benutzernamen erzwingt, gehört die Zuordnung in die ausführende Komponente, nicht in den Prompt, der die Aktion anfordert.

Vermeide solche rohen .env-Beispiele in einem Repository:

LEGACY_API_URL=https://tenant-48291.api.legacy.example/v2/payroll/export
LEGACY_API_USER=tenant-48291-payroll-export
LEGACY_API_PASSWORD=replace-me

Der Platzhalter replace-me macht das Beispiel nicht sicher. URL und Benutzername dokumentieren weiterhin ein kundenspezifisches Integrationsmuster. Ein kopiertes Beispiel kann später unter Zeitdruck sogar zur Produktivkonfiguration werden.

Verwende stattdessen einen abstrakten lokalen Vertrag:

actions:
  export_monthly_payroll:
    account_ref: payroll-export-production
    target_ref: payroll-export-api
    inputs:
      - tenant_alias
      - month

Die Bezeichnungen account_ref und target_ref sollten so undurchsichtig sein, dass ein Leser des Repositorys weder Kunde noch Hostname oder Servicerolle ableiten kann. Der Executor löst sie lokal auf. Der Agent erhält tenant_alias nur, wenn die Aktion ihn tatsächlich benötigt. Wenn eine lokale Zuordnung möglich ist, sollte dieser Alias keine Produktiv-Mandantenkennung sein.

Dieser Ansatz verhindert auch einen häufigen Migrationsfehler: Das Passwort wird in einen Secret Manager verschoben, während Benutzername, Ziel-URL und Kundencode weiterhin fest im Programm stehen. Das ist besser, als ein Passwort zu committen, aber die Struktur bleibt für jeden Entwickler, jedes Build-Log und jeden Code-Scan-Export sichtbar.

Aliase verwenden, die aus einem Leak kein Verzeichnis machen

Undurchsichtige Namen sind keine Magie, verringern aber den Informationswert einer versehentlichen Offenlegung. Der Kontoname sollte seinen Zweck für die kleine Gruppe beschreiben, die ihn verwaltet, nicht eine Kundenbeziehung für jedes System ankündigen, das ihn sieht.

Vergleiche diese Service-Aliase:

bad:  acme-east-payroll-export-prod
better: svc-47f2-export-p1

Der zweite Alias enthält weiterhin ein lesbares Servicepräfix und einen Umgebungsmarker. Das ist oft praktikabel. Die nützlichen Details enden dort. Ein separates geschütztes Register kann svc-47f2-export-p1 dem Kunden, Besitzer, Endpunkt, Berechtigungen und Rotationsdatensatz zuordnen.

Behandle zufällig wirkende Aliase nicht als Ersatz für Autorisierung. Wer ein Passwort besitzt, kann sich weiterhin authentifizieren, und Mitarbeiter mit Zugriff auf das Register sehen weiterhin die Zuordnung. Aliase verringern unnötige Offenlegung. Least Privilege und Zugriffsprüfungen begrenzen, was das Konto tun darf.

Manchmal schreibt ein Anbieter das Benutzernameformat vor. Ältere APIs verlangen möglicherweise eine Kundennummer, eine E-Mail-Adresse oder einen zusammengesetzten Wert mit Region. Wenn das so ist, akzeptiere, dass dieses Feld sensibel ist, und ändere die Handhabung darum herum. Tu nicht so, als wäre der Wert öffentlich, nur weil du ihn nicht umbenennen kannst.

Halte vom Anbieter verlangte Kennungen innerhalb der Zugangsdaten-Grenze und mache nachgelagerte Ausgaben möglichst langweilig. Ein Request-Executor kann export accepted mit einer Job-ID zurückgeben. Er muss dem aufrufenden Agenten weder den übermittelten Benutzernamen noch die vollständige Ziel-URL oder den Mandantenroutingwert wiederholen.

Logs brauchen eine Prüfspur, aber kein Kontoverzeichnis

Sicherheitslogs müssen genug Details enthalten, um zu beantworten, wer eine Aktion begonnen hat, was geschah, wann es geschah und ob sie erfolgreich war. Sie müssen nicht jedes Byte speichern, das der Client gesendet hat. OWASP warnt in seinen Logging-Empfehlungen ausdrücklich davor, sensible Informationen wie Passwörter, Sitzungskennungen und unnötige Systemdetails zu protokollieren, fordert aber zugleich Logs für Authentifizierungs- und Zugriffskontrollereignisse.

Der Zielkonflikt ist real. Wenn du alles entfernst, können Betreiber Vorfälle nicht untersuchen. Wenn du rohe Header und vollständige URLs dauerhaft aufbewahrst, wird dein Log zu einem durchsuchbaren Kontoverzeichnis.

Verwende eine Datenform, die betriebliche Korrelation von sensiblen Metadaten trennt:

{
  "event": "legacy_api_call",
  "action": "export_monthly_payroll",
  "request_id": "req_01J...",
  "actor_run": "run_01J...",
  "credential_ref": "cred_4c91",
  "target_ref": "target_a77e",
  "result": "denied",
  "http_status": 401,
  "reason": "authentication_failed",
  "occurred_at": "2026-07-22T14:03:21Z"
}

Die Referenzen erlauben autorisierten Betreibern, Ereignisse mit einem geschützten Inventar abzugleichen. Sie schreiben Benutzername, Mandanten-ID, rohen Endpunkt oder Authorization-Header nicht in jedes Ereignis. Der Zugriff auf das Inventar sollte enger begrenzt sein als der normale Logzugriff.

Protokolliere nicht einfach einen Hash des Benutzernamens und betrachte das Problem als gelöst. Ein deterministischer Hash eines kleinen, strukturierten Namensraums ist oft erratbar. Ein stabiler Hash erlaubt außerdem, ein Konto über mehrere Datensätze zu verfolgen. Verwende für Korrelation eine zufällige, von deinem System vergebene Credential-Referenz. Rotiere oder deaktiviere die Referenz, wenn du die Zugangsdaten rotierst.

Sei vorsichtig mit Fehlerdiagnosen. Diese Antwort solltest du nicht weiterreichen:

401 for tenant-48291-payroll-export at /v2/payroll/export: user exists but password rejected

Sie bestätigt Konto, Mandant, Route und Prüfergebnis. Eine bessere interne Behandlung bewahrt die genaue Diagnose des Anbieters in einem eingeschränkten Supportdatensatz auf, wenn sie wirklich benötigt wird. Die allgemeine Aktivitätsspur protokolliert dagegen authentication_failed. Der Agent sollte eine kurze Fehlermeldung erhalten, die ihn zum Stoppen und Anfordern von Hilfe auffordert, nicht einen weiteren Hinweis, um Varianten auszuprobieren.

Bereinigung und Minimierung lösen unterschiedliche Probleme

Bereinigung entfernt einen bekannten gefährlichen Wert, nachdem jemand ihn bereits verarbeitet hat. Minimierung verhindert, dass der Wert überhaupt an einen Ort gelangt, an dem er nicht hingehört. Du brauchst beides, und ihre Verwechslung führt zu schlechten Designs.

Ein Header-Scrubber kann dies:

Authorization: Basic c3ZjLWJpbGxpbmctZXhwb3J0LXByb2Q6cmVkYWN0ZWQ=

in dies umwandeln:

Authorization: [REDACTED]

Das ist notwendig. Es sagt nichts über Pfad, Hostname, Mandantenparameter in der URL, ausführlichen 401-Text, Request-Bezeichnung oder Trace-Attribute aus, die neben dem Header gespeichert werden. Ein System, das stolz Passwörter entfernt, aber tenant-48291.api.legacy.example/payroll/export behält, hat ein Risiko verringert und zugleich eine brauchbare Kontokarte zurückgelassen.

Minimierung stellt vor der Anfrage schwierigere Fragen:

• Braucht der Agent den tatsächlichen Zielhost oder nur einen Aktionsnamen?
• Braucht das Aktivitätslog die Mandantenkennung oder nur eine geschützte Referenz?
• Braucht der Support die rohe Anbieterantwort im normalen Logstrom?
• Muss der Mandant in der URL stehen, wenn der Executor ihn lokal auflösen kann?
• Muss eine Person bei der Genehmigungsprüfung die vollständige Identität sehen oder reicht ein verständlicher, aber nicht verräterischer Name?

Hier geben viele Teams eine beliebte, aber falsche Empfehlung: „Protokolliere die ganze Anfrage einmal und verbessere die Filter später.“ Sie tun das, weil das Debuggen von Legacy-APIs mühsam ist und vollständige Mitschnitte Fragen schnell beantworten. Die erfassten Daten werden dann zu dauerhaften Spuren in Backups, Analysespeichern, Testumgebungen und kopierten Incident-Notizen. Baue stattdessen einen eingeschränkten Diagnoseweg für eine kurzlebige Untersuchung. Rohe Vollaufzeichnungen sollten nicht der normale Betriebsmodus sein.

Legacy-APIs brauchen eine Begrenzung, kein blindes Vertrauen

Vielleicht kannst du Basic-Authentifizierung in diesem Quartal nicht ersetzen. Ein Anbieter unterstützt möglicherweise nur einen Integrationsstil, oder ein Gerät besitzt eine seit Jahren unveränderte API. Die praktische Antwort ist Begrenzung, nicht die Wunschvorstellung, die Legacy-API sei unproblematisch.

Lege Basic-Anmeldedaten und Kennungszuordnung hinter eine Komponente, die den HTTP-Aufruf selbst ausführt. Der Agent sollte eine benannte Aktion mit strukturierten Eingaben anfordern. Die Request-Komponente wählt das Ziel, bezieht die Zugangsdaten, fügt sie in den Header ein, prüft den vorgesehenen Umfang und gibt ein begrenztes Ergebnis zurück.

Ein sinnvoller Vertrag für eine Agentenaktion sieht so aus:

{
  "action": "export_monthly_payroll",
  "tenant_alias": "tenant_ref_91ab",
  "month": "2026-06"
}

Der Aktions-Executor kann den Monat validieren, tenant_ref_91ab in einer lokal geschützten Zuordnung auflösen und den Anbieter aufrufen. Er sollte zusätzliche Felder wie url, authorization, username und headers ablehnen. Wenn Aufrufer diese Felder überschreiben können, lässt sich ein geschütztes Konto an einen beliebigen Host umleiten oder eine eng definierte Aktion wieder in einen allgemeinen HTTP-Client verwandeln.

Diese Einschränkung ist bei SSRF-ähnlichen Fehlern ebenso wichtig wie beim Schutz von Zugangsdaten. Eine vom Benutzer angegebene URL ist keine harmlose Bequemlichkeit, wenn der Executor Anmeldedaten besitzt. Das Ziel muss aus einer kontrollierten Definition stammen, und auch Weiterleitungen brauchen eine sorgfältige Behandlung. Folge keiner Weiterleitung zu einer neuen Origin, während der Authorization-Header erhalten bleibt.

Diese Grenze sollte auch Wiederholungen steuern. Ein schlecht entworfener Agent kann einen 401-Fehler mit veränderten Eingaben wiederholen oder nach einem Timeout eine Aktion mehrfach ausführen. Der Executor muss einen sicheren Transport-Retry von einem Authentifizierungsfehler oder einem unbekannten Ergebnis eines Schreibvorgangs unterscheiden. Bei einem nicht idempotenten Legacy-Endpunkt sollte er einen Status zurückgeben, der eine menschliche Prüfung erzwingt, statt dieselbe Anfrage erneut zu senden, nur weil der Agent selbstsicher darum bittet.

Sallyport passt zu diesem Muster, wenn ein MCP-fähiger Agent eine HTTP-API aufrufen muss, ohne selbst Basic-Anmeldedaten zu erhalten. Sein HTTP-Kanal fügt Basic-Anmeldedaten innerhalb der App ein. Sitzungs- und Aufrufsteuerung ermöglichen es einer Person zu entscheiden, wann ein Agentenlauf dieses Konto verwenden darf. Der Agent erhält das Aktionsergebnis, keinen Klartext-Benutzernamen und kein Passwort, das er anderswo wiederverwenden könnte.

Genehmigungen müssen genug Kontext zeigen, um falsche Aktionen zu erkennen

Ein Genehmigungsdialog mit nur „API-Aufruf erlauben?“ hilft nicht. Ein Dialog, der den vollständigen Basic-Benutzernamen, Mandanten, die komplette URL und den rohen Request-Body ausgibt, teilt zu viel. Der Prüfer braucht eine kompakte Beschreibung, die eine falsche Aktion erkennbar macht, ohne die gesamte Kontostruktur offenzulegen.

Zeige Aktionsnamen, geschützte Zielbezeichnung, eine für den Prüfer gewählte Mandantenbezeichnung, Vorgangstyp und Auswirkungen auf hoher Ebene. Zum Beispiel:

Allow export_monthly_payroll?
Target: Payroll export service
Tenant: Finance tenant 7
Operation: Create June 2026 export
Agent run: signed local coding process

Damit kann ein Prüfer unerwarteten Monat, Funktion oder Ziel erkennen. Anbieterhostname, Mandantennummer und Servicebenutzername erscheinen nicht im Genehmigungsdatensatz.

Die Anzeigebezeichnung braucht Governance. Wenn „Finance tenant 7“ in einem Team mit nur einem Finanzkunden auftaucht, kann sie diesen Kunden trotzdem identifizieren. Verwende Bezeichnungen, die zur Gruppe passen, die sie sieht. Sicherheit entsteht nicht dadurch, jeden nützlichen Namen durch einen undurchsichtigen Code zu ersetzen, den Prüfer nicht verstehen.

Fordere bei sensiblen Basic-Konten für jede Nutzung eine Genehmigung, wenn die Aktion Geld bewegen, regulierte Daten exportieren, Zugriffe ändern oder einen externen Partner kontaktieren kann. Eine Genehmigung pro Sitzung ist für einen kurzen Lauf mit vielen risikoarmen Lesevorgängen praktischer. Die Entscheidung sollte sich nach Berechtigungen des Kontos und Folgen der Aktion richten, nicht danach, dass Basic-Authentifizierung alt ist.

Bewahre eine prüfbare Aufzeichnung der Genehmigungsentscheidung und des resultierenden Aufrufs auf. Ein manipulationssicherer Datensatz hilft nur, wenn er Akteur, Aktion, Ergebnis und Genehmigungsstatus beschreibt, ohne zu einer weiteren Kopie der Kontokarte zu werden. Sallyports getrennte Sitzungs- und Aktivitätsjournale folgen dieser Trennung. Beide Ansichten werden aus seinem verschlüsselten, hashverketteten Audit-Log erzeugt.

Die Kontostruktur von Anfang an schwer sammelbar machen

Die Lösung ist kein riesiges Regelwerk mit dem Hinweis „Metadaten sorgfältig behandeln“. Mache den sicheren Weg zum Weg, den Entwickler und Agenten ganz selbstverständlich nutzen.

Erfasse jede Basic-Integration und beantworte für jede diese Fragen: Was verrät der Benutzername? Enthält er eine Person, einen Kunden, eine Umgebung, ein Produkt oder eine Rolle? Welches Host-Endpunkt-Paar macht den Wert aussagekräftiger? Wo erscheinen diese Werte heute? Welcher Aufrufer muss sie wirklich sehen?

Entferne anschließend die einfachen Kopien. Ersetze rohe curl-Schnipsel durch Aktionsbeispiele. Ersetze mandantenspezifische Fixture-Namen durch neutrale Test-Aliase. Blockiere Authorization-Header und URL-Userinfo in Anwendungslogs. Halte vollständige Anbieterdiagnosen aus agentensichtbaren Ausgaben heraus. Lehne vom Benutzer angegebene Request-Ziele an der Zugangsdaten-Grenze ab. Gib dem Support einen kontrollierten Weg, Details abzurufen, wenn ein Vorfall dies rechtfertigt.

RFC 9110 schreibt vor, dass Absender keine HTTP- oder HTTPS-URI-Referenzen mit user:password@host-Userinfo erzeugen dürfen. Außerdem warnt der Standard, dass Implementierungen Benutzerkennung oder Passwort offenlegen können, wenn diese Form in Konfigurationen oder Befehlsoptionen verwendet wird. Die Warnung gilt über URLs hinaus: Identitätsdetails in bequemen Textfeldern werden leicht an Orte kopiert, an denen sie nie hingehörten.

Basic-Authentifizierung bleibt vielleicht bestehen, weil ein Anbieter noch nicht weitergezogen ist. Deine eigene Handhabung muss nicht auf diesem Stand bleiben. Sobald du Benutzernamen, Mandantenkennungen und Endpunktpaare als sensible Metadaten behandelst, gibst du einem Agenten nicht mehr zusammen mit der Aufgabe das Kontoverzeichnis mit.