Amazon AWS ergänzt AgentCore Identity um Private Key JWT und ersetzt Shared Secrets durch KMS-Kontrolle

Amazon AWS hat AgentCore Identity um die Private-Key-JWT-Authentifizierung ergänzt und bietet automatisierten Agenten damit eine neue Alternative zu langlebigen OAuth-Client-Secrets. Die Änderung verlagert die Client-Authentifizierung hin zu kurzlebigen, signierten Assertions, die durch AWS Key Management Service abgesichert sind. Zudem entsteht für jede Signaturanfrage ein klarerer Eintrag in AWS CloudTrail.

Diese Kombination ist relevant, weil ein autonomer Agent Token deutlich häufiger anfordern kann als eine herkömmliche, auf Mitarbeitende ausgerichtete Anwendung. Ein kopiertes Client-Secret kann nutzbar bleiben, bis es rotiert oder widerrufen wird. Eine Private-Key-JWT-Assertion läuft schnell ab und erfordert für jede neue Anfrage Zugriff auf einen geschützten Signaturschlüssel.

Im Kern geht es nicht einfach um Schlüssel statt Passwörter. Amazon Bedrock AgentCore Identity verspricht nun mehr Kontrolle, ohne Entwickler dazu zu zwingen, einen eigenen Signaturdienst aufzubauen und zu betreiben. Ob sich dieses Versprechen erfüllt, hängt von der Kompatibilität des Identity Providers, einer präzisen Claim-Konfiguration, KMS-Berechtigungen und vollständiger Audit-Abdeckung ab.

Amazon AWS verlagert die OAuth-Client-Authentifizierung in KMS

Die entscheidende Änderung besteht darin, dass AgentCore Identity einen OAuth-Client authentifizieren kann, ohne ein wiederverwendbares Client-Secret zu speichern.

Im neuen, in der Ankündigung zu Private Key JWT beschriebenen Muster erstellt AgentCore Identity ein JSON Web Token und signiert es über AWS KMS. Der Identity Provider prüft diese Signatur mithilfe des zugehörigen öffentlichen Schlüssels.

Der private Schlüssel verbleibt in KMS. Ein Agent, Anwendungsprozess oder Administrator muss den Schlüssel nicht in eine Konfigurationsdatei, ein Container-Image, eine Umgebungsvariable oder einen separaten Secret Store exportieren.

Das signierte JWT ist eine Client-Assertion, das heißt, es weist die Identität des OAuth-Clients gegenüber einem Authorization Server nach. Es ist nicht das Access Token, das letztlich einer API vorgelegt wird. Der Authorization Server validiert die Assertion, bevor er dieses Access Token ausstellt.

Diese Unterscheidung ist leicht zu übersehen. Die OAuth-Client-Authentifizierung beantwortet die Frage, ob die Anwendung, die ein Token anfordert, tatsächlich der registrierte Client ist. Der OAuth-Grant bestimmt hingegen, wessen Berechtigung das resultierende Token repräsentiert und welche Zugriffsrechte es erhält.

Private Key JWT kann daher mit mehr als einem Grant Flow eingesetzt werden. AgentCore Identity unterstützt nutzerdelegierten Zugriff über den Authorization Code Grant sowie Machine-to-Machine-Zugriff über Client Credentials. Die umfassenderen Authentifizierungsmuster decken zudem On-Behalf-Of-Konfigurationen für Token Exchange ab.

Bei einer nutzerdelegierten Anfrage autorisiert zunächst eine Person den Zugriff über den Identity Provider. AgentCore Identity authentifiziert anschließend den OAuth-Client, wenn es den Authorization Code gegen Token eintauscht. Die Zustimmung des Nutzers und die Identität des Clients bleiben getrennte Kontrollmechanismen.

Bei einer Machine-to-Machine-Anfrage durchläuft kein Nutzer einen interaktiven Consent-Screen. Der Agent fordert ein Access Token unter der eigenen Berechtigung der Anwendung an. Private Key JWT authentifiziert diese Anwendung während des Client-Credentials-Austauschs.

Damit ist die Funktion über Login-Szenarien hinaus relevant. Sie zielt auf den ausgehenden Zugriff von Agenten auf Unternehmens-APIs, Softwaredienste und andere geschützte Ressourcen. Gerade bei diesen Verbindungen kann eine statische Zugangsinformation zu einer betrieblichen Belastung werden.

AgentCore Identity fungiert bereits als Vermittler zwischen Agenten, Authorization Servern und Resource Servern. Es ruft Zugangsdaten ab und hält langfristige Secrets und Refresh Tokens von Agent-Code fern. Private Key JWT erweitert diese Abgrenzung auf das Authentifizierungsmaterial des OAuth-Clients.

Der Anforderungspfad umfasst nun mehrere explizite Schritte. Der Agent bittet AgentCore Identity um autorisierten Zugriff. AgentCore Identity erstellt eine zeitlich begrenzte Assertion, ruft KMS zur Signatur auf und sendet sie an den Token Endpoint des Identity Providers.

Der Identity Provider prüft die Signatur anhand des registrierten öffentlichen Schlüssels. Er bewertet außerdem Claims, die Client, Audience, Ausstellungszeit und Ablaufzeit identifizieren. Bestehen diese Prüfungen, gibt der Provider über AgentCore Identity ein Access Token zurück.

Dieses Design beseitigt Vertrauen nicht. Es verlagert es in KMS-Richtlinien, IAM-Rollen, OAuth-Konfiguration und die Registrierung öffentlicher Schlüssel beim Identity Provider. Diese Kontrollen sind granularer als eine kopierte Zeichenfolge, schaffen aber auch mehr Stellen, an denen eine Abweichung die Authentifizierung verhindern kann.

Wie Private Key JWT das Secret-Modell verändert

Private Key JWT verringert die Abhängigkeit von Shared Secrets, doch seine Sicherheit hängt davon ab, wer KMS zum Signieren auffordern darf.

Die traditionelle OAuth-Client-Authentifizierung verwendet häufig client_secret_basic oder client_secret_post. Beide Methoden senden eine Client-ID und ein Shared Secret an den Authorization Server. Der Unterschied besteht darin, ob diese Zugangsdaten in einem HTTP-Basic-Header oder im Request Body erscheinen.

Die AWS-Dokumentation beschreibt HTTP Basic als Standardmethode für benutzerdefinierte AgentCore-Identity-Provider. Das Secret bleibt bis zur Rotation, seinem Ablauf oder einem Widerruf wiederverwendbar. Jedes System, das eine Kopie besitzt, wird Teil der Sicherheitsgrenze dieser Zugangsinformation.

Private Key JWT ersetzt dieses symmetrische Modell durch ein asymmetrisches Schlüsselpaar. Eine Partei kontrolliert den privaten Signaturschlüssel, während der Identity Provider nur den öffentlichen Verifikationsschlüssel speichert. Die Offenlegung des öffentlichen Schlüssels erlaubt einem Angreifer nicht, gültige Assertions zu erzeugen.

Der Ansatz folgt dem OAuth JWT profile, das JWTs für Client-Authentifizierung und Authorization Grants definiert. Die Token-Anfrage enthält eine Client-Assertion und kennzeichnet sie als JWT-Bearer-Assertion.

Eine typische Assertion enthält einen Issuer Claim zur Identifizierung des Clients, einen Subject Claim für diesen Client und einen Audience Claim, der den Token Endpoint benennt. Sie umfasst außerdem Ablauf- und Ausstellungszeiten. Eine eindeutige JWT-Kennung kann einem Identity Provider helfen, Replay-Versuche zu erkennen.

Diese Felder sind keine dekorativen Metadaten. Eine falsche Audience kann ein korrekt signiertes JWT ungültig machen. Eine Zeitabweichung kann dazu führen, dass der Provider eine Assertion als verfrüht oder abgelaufen ablehnt.

Private Key JWT garantiert auch nicht automatisch Replay-Schutz. RFC 7523 überlässt bestimmte Schutzmaßnahmen gegen Wiederholungsangriffe der Deployment-Policy. Identity Provider benötigen angemessene Laufzeitbegrenzungen und, sofern unterstützt, eine Nachverfolgung eindeutiger Assertions.

Kurze Ablaufzeiten begrenzen den Nutzen einer abgefangenen Assertion. Sie schützen jedoch nicht ein System, in dem ein Angreifer wiederholt den Signaturschlüssel aufrufen darf. Deshalb werden die KMS-Key-Policy und IAM-Berechtigungen zur zentralen Durchsetzungsebene.

AWS KMS repräsentiert einen asymmetrischen Schlüssel als verbundenes öffentliches und privates Paar. Bei Signaturschlüsseln bleibt die private Komponente innerhalb des Dienstes geschützt. Die öffentliche Komponente kann heruntergeladen und bei einem externen Identity Provider registriert werden.

KMS unterstützt mehrere asymmetrische Schlüsseltypen, darunter RSA- und Elliptic-Curve-Schlüssel für Signatur und Verifikation. Der gewählte Schlüsseltyp und Algorithmus müssen zu den vom Identity Provider akzeptierten Verfahren passen.

AgentCore Identity benötigt die Berechtigung, den konfigurierten Schlüssel zum Signieren zu verwenden. AWS erklärt, dass Aufrufer der KMS-Sign-Operation über die Key Policy für kms:Sign autorisiert sein müssen. Der Dienst verwendet dann die private Komponente, ohne sie zurückzugeben.

Das ist eine bedeutende Verbesserung der Eingrenzung. Ein Konfigurationsleck, das einen Key ARN offenlegt, gibt kein privates Schlüsselmaterial preis. Ein Angreifer bräuchte weiterhin AWS-Zugangsdaten und eine wirksame Berechtigung zum Aufruf des Schlüssels.

Die Signierberechtigung bleibt jedoch sensibel. Eine Rolle mit umfassendem kms:Sign-Zugriff könnte potenziell Signaturen außerhalb des vorgesehenen Workload-Pfads anfordern. Teams sollten Berechtigungen an die richtigen AgentCore-Ausführungsrollen binden und allgemeinen Wildcard-Zugriff vermeiden.

Die Änderung wirkt sich auch auf die Rotation aus. Bei einem Shared Secret müssen beide Seiten denselben vertraulichen Wert ersetzen. Bei asymmetrischer Authentifizierung können Teams beim Identity Provider einen neuen öffentlichen Schlüssel einführen und den alten Verifikationsschlüssel während eines kontrollierten Übergangs beibehalten.

Diese Überschneidung kann Ausfallzeiten reduzieren, sofern der Identity Provider mehrere aktive Schlüssel unterstützt. Akzeptiert er nur einen öffentlichen Schlüssel, erfordert die Rotation weiterhin abgestimmtes Timing. Private Key JWT verändert das rotierte Material, nicht die Notwendigkeit eines erprobten Rotationsprozesses.

Die unterstützten Grant Flows stehen für unterschiedliche Agentenidentitäten

Private Key JWT authentifiziert den OAuth-Client, während der gewählte Grant bestimmt, ob ein Agent für sich selbst oder für einen Nutzer handelt.

Der Authorization Code Grant eignet sich für Agenten, die im Namen einer Person auf Ressourcen zugreifen. Ein Nutzer meldet sich über einen Identity Provider an und genehmigt die angeforderten Berechtigungen. Der Authorization Server gibt einen Code zurück, den der Client gegen Token eintauscht.

Während dieses Austauschs verwendet AgentCore Identity die Private-Key-JWT-Assertion, um nachzuweisen, dass der registrierte Client die Anfrage stellt. Die Assertion ersetzt nicht die Zustimmung des Nutzers. Sie stärkt die Authentifizierung am Token Endpoint.

Dieser Flow eignet sich für einen Agenten, der den Kalender eines Nutzers liest, die autorisierten Datensätze eines Mitarbeitenden durchsucht oder ein Customer-Management-System innerhalb delegierter Berechtigungen aktualisiert. Der resultierende Zugriff bleibt an den Nutzer und die genehmigten Scopes gebunden.

Der Client Credentials Grant behandelt einen anderen Fall. Hier handelt der Workload ohne interaktiven Nutzer für sich selbst. Ein geplanter Agent könnte eine interne Inventar-API aufrufen, Service-Alerts verarbeiten oder genehmigte Betriebsdaten abrufen.

Private Key JWT authentifiziert diesen Machine Client, bevor der Authorization Server ein Application Token ausstellt. Da keine Person beteiligt ist, tragen Client-Identität, Token Scopes und die nachgelagerte Authorization Policy einen größeren Teil der Sicherheitslast.

Organisationen sollten die beiden Grants nicht als austauschbare Deployment-Optionen behandeln. Die Verwendung von Client Credentials für eine Aufgabe, bei der die Nutzeridentität erhalten bleiben sollte, kann die Nachvollziehbarkeit verschleiern. Ein delegierter Flow für Hintergrund-Service-Arbeit kann fragile Abhängigkeiten von einzelnen Konten schaffen.

On-Behalf-Of-Zugriff führt eine weitere Variante ein. Ein Agent erhält Nachweise einer bestehenden Nutzeridentität und tauscht sie gegen ein Token, das für eine andere Ressource geeignet ist. Der Flow muss die Beziehung zwischen Nutzer, Agent und Zieldienst bewahren.

Die Dokumentation von AgentCore Identity beschreibt für diese Fälle sowohl Standard-Token-Exchange- als auch JWT-basierte Authorization-Grant-Ansätze. Die Unterstützung hängt weiterhin vom externen Authorization Server und dessen Regeln für Token Exchange ab.

Private Key JWT kann den an diesem Austausch beteiligten Client authentifizieren. Es entscheidet nicht, ob das eingehende Nutzer-Token gültig ist oder ob die angeforderte Delegierung erlaubt sein sollte. Diese Entscheidungen verbleiben bei den zuständigen Identitäts- und Autorisierungssystemen.

Diese Trennung ist einer der stärksten architektonischen Aspekte der Funktion. Teams können einen Grant anhand der Berechtigung wählen, die ein Agent benötigt, und anschließend Private Key JWT danach auswählen, wie der Client seine Identität nachweisen soll.

Sie verdeutlicht auch, weshalb ein einzelnes „Agent Credential“ ein unsicheres Denkmodell ist. Ein Agent kann eine Workload-Identität haben, für einen Nutzer handeln, mehrere Resource Server aufrufen und für jedes Ziel unterschiedliche Token verwenden.

Der Workload-Zugriffstoken von AgentCore Identity fügt eine weitere Ebene hinzu. AWS zufolge kann dieser Token die Identität des Agenten und die des Endnutzers enthalten, wenn der Agent Anmeldedaten aus dem Vault anfordert. AgentCore Runtime kann ihn gehosteten Agenten automatisch bereitstellen.

Dieser Workload-Token autorisiert den Zugriff auf AgentCore Identity. Der externe OAuth-Zugriffstoken autorisiert den Zugriff auf die Ziel-API. Die Private Key JWT Assertion authentifiziert den OAuth-Client während der Token-Ausstellung.

In einer End-to-End-Transaktion können daher drei Token auftreten, jeweils mit einer anderen Aufgabe. Werden sie verwechselt, kann dies zu fehlerhafter Validierung, übermäßiger Protokollierung oder unbeabsichtigter Offenlegung führen.

Sicherheitsprüfungen sollten jeden Token seinem Aussteller, seiner Zielgruppe, seinem Inhaber, seiner Laufzeit und seinem Ziel zuordnen. Sie sollten außerdem feststellen, welche Komponente ihn aktualisieren oder ersetzen kann. Diese Übung deckt Konstruktionsfehler auf, die Diagramme auf Produktebene verbergen können.

Der umfassendere Wettbewerbsdruck trifft auf geheimnisbasierte Agentenintegrationen. Statische Client Secrets sind vertraut und weit verbreitet unterstützt, lassen sich jedoch schlecht skalieren, wenn viele autonome Workloads unabhängige Berechtigungen und Audit-Trails benötigen.

Private Key JWT erhöht den Einrichtungsaufwand und reduziert zugleich die Vervielfältigung von Anmeldedaten. Für Teams, die bereits AWS IAM, KMS und CloudTrail betreiben, kann dieser Kompromiss attraktiv sein. Bei kleineren Bereitstellungen könnte die zusätzliche Policy-Komplexität den unmittelbaren Nutzen überwiegen.

Die Konfiguration der Vertrauenskette erfordert mehr als die Auswahl einer Methode

Die Einrichtung funktioniert nur, wenn KMS, IAM, AgentCore Identity und der externe Identitätsanbieter bei denselben kryptografischen und OAuth-Details übereinstimmen.

Die erste Voraussetzung ist ein asymmetrischer KMS-Schlüssel, der für Signatur und Verifikation konfiguriert ist. Verschlüsselungsschlüssel können diese Aufgabe nicht erfüllen. Die Schlüsselspezifikation und der Signaturalgorithmus müssen einer Kombination entsprechen, die vom Ziel-Identitätsanbieter akzeptiert wird.

AWS KMS stellt den öffentlichen Teil eines asymmetrischen Signaturschlüssels bereit. Teams registrieren diesen öffentlichen Schlüssel bei ihrem Identitätsanbieter, entweder direkt oder über eine unterstützte JSON Web Key-Konfiguration.

Der Identitätsanbieter muss den Schlüssel dem richtigen OAuth-Client zuordnen. Er muss außerdem Private Key JWT an seinem Token-Endpunkt unterstützen. Registrierungsoberflächen und akzeptierte Algorithmen unterscheiden sich je nach Anbieter, weshalb dieser Schritt anbieterspezifisch bleibt.

Als Nächstes erstellen oder aktualisieren Administratoren einen benutzerdefinierten OAuth-Anmeldedatenanbieter in der Amazon Bedrock AgentCore-Konsole. Die Konfiguration benötigt die Discovery-Informationen des Anbieters, die Client-Kennung, die KMS-Schlüssel-ARN und den Signaturalgorithmus.

OAuth Discovery ermöglicht AgentCore Identity, Autorisierungs- und Token-Endpunkte anhand der Metadaten des Anbieters zu ermitteln. Teams sollten prüfen, ob der ermittelte Token-Endpunkt dem vom Identitätsanbieter erwarteten Audience-Wert entspricht.

AgentCore Identity benötigt außerdem die Berechtigung, KMS aufzurufen. Der KMS-Signaturvorgang erfordert einen Schlüssel mit der Verwendung SIGN_VERIFY und einen mit diesem Schlüssel kompatiblen Algorithmus.

Abhängig vom ausgewählten Nachrichtentyp akzeptiert KMS entweder eine Rohmeldung oder einen vorberechneten Digest. Eine JWT-Implementierung muss versehentliches doppeltes Hashing vermeiden, da die externe Verifikation das für den Algorithmus festgelegte Hashing-Verhalten voraussetzt.

Auch die Konfiguration des JWT-Headers ist wichtig. Der Identitätsanbieter kann eine Schlüsselkennung verwenden, um den passenden öffentlichen Schlüssel auszuwählen. Eine fehlende oder falsche Kennung wird insbesondere bei einer Rotation problematisch, wenn mehrere öffentliche Schlüssel aktiv sein können.

Auch die Payload-Claims erfordern dieselbe Sorgfalt. Aussteller und Subjekt entsprechen üblicherweise der OAuth-Client-ID. Die Audience bezeichnet normalerweise den Token-Endpunkt des Autorisierungsservers, wobei die Anforderungen des Anbieters den genauen Wert bestimmen sollten.

Die Ablaufzeit sollte kurz bleiben. Die Ausstellungszeit muss eine synchronisierte Uhr widerspiegeln. Eine eindeutige Token-Kennung ist wertvoll, wenn der Anbieter zuvor akzeptierte Assertions protokolliert.

Nach dem Speichern des Anmeldedatenanbieters sollten Teams jeden vorgesehenen Grant unabhängig testen. Eine erfolgreiche Client-Credentials-Anfrage beweist nicht, dass der Authorization-Code-Austausch oder Token-Austausch korrekt konfiguriert ist.

Die Tests sollten mit minimalen Scopes beginnen. Wenn die Authentifizierung erfolgreich ist, aber die Autorisierung fehlschlägt, lässt sich der Unterschied leichter diagnostizieren. Breite Berechtigungen hinzuzufügen, um einen Fehler zu umgehen, kann ein Problem mit Audience oder Client-Registrierung verdecken.

Teams sollten auch negative Pfade testen. Eine mit dem falschen Schlüssel signierte Anfrage sollte fehlschlagen. Eine abgelaufene Assertion sollte fehlschlagen. Eine falsche Audience und ein nicht autorisierter KMS-Aufrufer sollten jeweils unterscheidbare Hinweise liefern.

Hier wird der operative Kompromiss sichtbar. Shared Secrets sind so einfach, dass Teams oft nur den Erfolgsfall validieren. Private Key JWT bietet stärkere Grenzen, doch diese Grenzen müssen ausdrücklich getestet werden.

Die Konfiguration schafft zudem Abhängigkeiten zwischen administrativen Teams. Ein Cloud-Security-Team kann KMS- und IAM-Policies verantworten. Ein Identitätsteam kann den OAuth-Client und die Registrierung des öffentlichen Schlüssels kontrollieren.

Anwendungsbesitzer konfigurieren AgentCore Identity und bestimmen Grant-Scopes. Audit-Teams entscheiden, welche CloudTrail-Einträge aufbewahrt und mit Warnungen versehen werden müssen. Keine einzelne Auswahl in einer Konsole löst diese Fragen der Verantwortlichkeit.

Ein sinnvoller Rollout beginnt mit einer nicht kritischen Integration. Teams können Claim-Anforderungen, Fehlerreaktionen, Rotationsschritte und Eskalationsverantwortlichkeiten dokumentieren, bevor sie die Methode auf viele Agenten anwenden.

Auf diese erste validierte Bereitstellung sollte Automatisierung folgen. Infrastrukturvorlagen können Schlüssel-Policies und Einstellungen von Anmeldedatenanbietern standardisieren, sollten jedoch das Verhalten des Identitätsanbieters nicht erraten.

Das Ergebnis ist kein System ohne Secrets. Token existieren weiterhin, Autorisierungsserver bleiben Vertrauensinstanzen, und AWS-Berechtigungen bleiben Anmeldedaten. Die engere Aussage ist besser vertretbar: Der OAuth-Client hängt nicht länger von einem gemeinsam genutzten, wiederverwendbaren Secret ab.

CloudTrail macht jede Signatur zu einem Audit-Signal

KMS-gestützte Signaturen liefern Verteidigern ein AWS-seitiges Ereignis, das sie mit Token-Anfragen und Agentenaktivität korrelieren können.

AWS KMS ist in CloudTrail integriert, das Aufrufe von Benutzern, Rollen und AWS-Services aufzeichnet. Seine KMS-Audit-Protokollierung umfasst kryptografische Vorgänge ebenso wie Schlüsselverwaltungsaktionen.

Eine Private Key JWT-Transaktion sollte daher Nachweise rund um die KMS-Signaturanfrage erzeugen. Das Ereignis kann den Vorgang, die Region, den Zeitpunkt, den relevanten Schlüssel sowie den beteiligten AWS-Prinzipal oder Service-Kontext identifizieren.

Dieser Eintrag erzählt für sich genommen nicht die ganze Geschichte. CloudTrail zeigt, dass eine autorisierte AWS-Identität eine Signatur angefordert hat. Die Protokolle des externen Identitätsanbieters zeigen, ob er die Assertion akzeptiert und einen Token ausgestellt hat.

Die Audit-Protokolle des Zielservice zeigen, was der resultierende Zugriffstoken getan hat. Eine wirksame Untersuchung korreliert alle drei Ebenen, anstatt das KMS-Ereignis als Beweis für erfolgreichen Ressourcenzugriff zu behandeln.

CloudTrail kann dennoch wichtige Fragen beantworten. Ermittler können nach unerwartetem Signaturvolumen, Anfragen von der falschen Rolle, Aufrufen in einer nicht genehmigten Region oder Aktivitäten mit einem Schlüssel außerhalb seines normalen Zeitplans suchen.

Die konfigurierten Ereignisselektoren sind entscheidend. AWS klassifiziert KMS-Ereignisse als Management-Ereignisse, und CloudTrail-Trails zeichnen Management-Aktivitäten normalerweise auf. Administratoren können KMS-Ereignisse jedoch ausdrücklich ausschließen.

AWS warnt, dass KMS-Vorgänge hohe Ereignisvolumen erzeugen können. Manche Organisationen filtern sie, um das Protokollierungsvolumen zu kontrollieren. Dadurch können gerade die Signaturnachweise entfernt werden, die dieses Authentifizierungsmuster leichter auditierbar machen.

Teams, die Private Key JWT einführen, sollten ihre Management-Ereigniseinstellungen überprüfen. Sie sollten bestätigen, dass relevante KMS-Aktivitäten den vorgesehenen Trail oder Event Data Store erreichen.

Auch Aufbewahrung und Durchsuchbarkeit sind wichtig. Der Ereignisverlauf ist für aktuelle Untersuchungen nützlich, während ein Trail oder CloudTrail Lake Event Data Store längerfristige Analysen unterstützt. Exportierte Einträge können außerdem Sicherheitsüberwachungssysteme speisen.

Eine Baseline sollte erwartetes Token-Refresh-Verhalten von Anomalien unterscheiden. Ein kontinuierlich laufender Maschinenagent kann Assertions in regelmäßiger Kadenz signieren. Ein benutzerdelegierter Workflow kann während aktiver Sitzungen Schübe erzeugen.

Große Abweichungen können auf eine Retry-Schleife, einen Konfigurationsfehler oder Missbrauch von Anmeldedaten hindeuten. Wiederholte Signaturen mit anschließender Ablehnung am Token-Endpunkt könnten auf eine falsche Audience, einen abgelaufenen öffentlichen Schlüssel oder ein Zeitproblem hinweisen.

Signaturaktivitäten ohne entsprechende AgentCore-Anfragen verdienen eine genauere Untersuchung. Gleiches gilt für erfolgreiche Token-Ausstellungen ohne die erwarteten nachgelagerten Aufrufe. Jedes Muster weist auf einen anderen Bruch in der Vertrauenskette hin.

Ereignisse im Schlüssel-Lebenszyklus sollten separate Warnungen auslösen. Das Deaktivieren eines Signaturschlüssels kann jede abhängige Integration anhalten. Policy-Änderungen können unbemerkt erweitern, wer ihn aufrufen darf.

CloudTrail hilft auch bei der Rotation. Teams können beobachten, ob der alte Schlüssel weiterhin Signaturanfragen erhält, nachdem ein neuer Schlüssel aktiv wird. Anhaltende Aktivität kann einen übersehenen Anmeldedatenanbieter oder eine verzögerte Bereitstellung aufdecken.

Die Audit-Transparenz bleibt jedoch bedingt. Protokolle müssen aktiviert, aufbewahrt, geschützt und überprüft werden. Ein erfasstes, aber nie abgefragtes Ereignis bietet wenig praktischen Schutz.

CloudTrail-Ereignisse validieren zudem nicht den geschäftlichen Grund einer Anfrage. Ein ordnungsgemäß autorisierter Agent kann dennoch zum falschen Zeitpunkt einen Zugriffstoken anfordern oder ihn für eine zu weit gefasste Aufgabe verwenden.

Diese Einschränkung lenkt die Aufmerksamkeit auf das Autorisierungsdesign. Private Key JWT kann beweisen, dass der Client den Zugriff auf einen Signaturschlüssel kontrolliert. Es kann nicht bestimmen, ob das Ziel des Agenten, das gewählte Tool oder der angeforderte Vorgang angemessen ist.

Organisationen benötigen Scope-Beschränkungen, Resource-Server-Policies, Workload-Kontrollen und Verhaltensüberwachung rund um den kryptografischen Nachweis. Die Signatur ist ein hochwertiges Signal, kein vollständiges System für Agenten-Governance.

Worauf Unternehmen nach dem Start von Private Key JWT achten sollten

Der nächste Test besteht darin, ob Private Key JWT zum operativen Standard wird oder eine fortgeschrittene Option für streng verwaltete Bereitstellungen bleibt.

Das erste Signal ist die Interoperabilität mit Identitätsanbietern. Eine erfolgreiche Einführung erfordert, dass Anbieter die ausgewählten Signaturalgorithmen, Claims, das Audience-Format und die Methode zur Registrierung öffentlicher Schlüssel akzeptieren.

AWS kann seine Seite des Austauschs vereinfachen, aber nicht den administrativen Workflow jedes Anbieters standardisieren. Klare, anbieterspezifische Beispiele würden fehlgeschlagene Bereitstellungen und unsichere Workarounds verringern.

Das zweite Signal ist das Rotationsverhalten. Unternehmen müssen wissen, ob sie überlappende öffentliche Schlüssel registrieren, AgentCore-Anbieter ohne Unterbrechung aktualisieren und die Migration über Audit-Einträge bestätigen können.

Eine Funktion, die nur bei der Ersteinrichtung funktioniert, löst nur die Hälfte des Problems. Produktionsauthentifizierung benötigt auch vorhersehbare Wiederherstellung, wenn ein Schlüssel deaktiviert, ersetzt oder kompromittiert wird.

Das dritte Signal ist die Audit-Einführung. CloudTrail gibt Teams Zugriff auf Signaturaufzeichnungen, doch Organisationen müssen KMS-Ereignisse aufbewahren und mit Protokollen von Identitätsanbietern und Resource-Servern verknüpfen.

Erkennungsleitlinien würden die Funktion nützlicher machen. Hohe Signaturraten, unbekannte Prinzipale, wiederholte Fehler und unerwartete regionale Aktivitäten sind praktische Kandidaten für Warnungen.

Sicherheitsteams sollten außerdem die Grenzen des Berechtigungsmodells von AgentCore Identity beobachten. Die ideale Policy erlaubt einem Workload, einen Signaturschlüssel für einen genehmigten Anbieter zu verwenden, ohne nicht zusammenhängenden Signaturzugriff zu gewähren.

Kontenübergreifende Schlüssel bieten Flexibilität, erfordern jedoch sorgfältige Ressourcen-Policies. AWS KMS unterstützt die kontenübergreifende Nutzung für Signaturen, wenn Aufrufer die Schlüssel-ARN angeben und die erforderlichen Berechtigungen erhalten.

Diese Fähigkeit kann eine zentralisierte Verantwortung für Sicherheit unterstützen. Sie kann jedoch auch Abhängigkeiten zwischen Anwendungskonten und einem zentralen Identitätskonto schaffen. Ausfälle oder Fehler in Richtlinien des zentralen Kontos können viele Agenten betreffen.

Unternehmen sollten operative Ergebnisse messen, statt anzunehmen, dass das kryptografische Design den Erfolg garantiert. Nützliche Indikatoren sind der Aufwand für die Rotation von Secrets, Fehler bei Token-Anfragen, unbefugte Signaturversuche und die Wiederherstellungszeit nach Schlüsseländerungen.

Sie sollten außerdem Private Key JWT mit der JWT-Authentifizierung vergleichen, die mit AWS IAM signiert wird. Die AgentCore-Identity-Dokumentation beschreibt eine Methode namens AWS_IAM_ID_TOKEN_JWT, die eine von IAM ausgestellte Assertion verwendet und verlangt, dass der Autorisierungsserver AWS IAM vertraut.

Beide Ansätze entfernen sich von gemeinsam genutzten Client-Secrets, begründen Vertrauen jedoch auf unterschiedliche Weise. Bei Private Key JWT muss der Identitätsanbieter einem kundenseitig verwalteten öffentlichen Schlüssel vertrauen. Die IAM-Methode verlangt dagegen, AWS IAM als Aussteller zu vertrauen.

Die Unterstützung durch Anbieter wird häufig darüber entscheiden, welcher Weg praktikabel ist. Einige Identitätssysteme unterstützen Private Key JWT bereits für vertrauliche OAuth-Clients. Weniger Systeme dürften so konfiguriert sein, dass sie einen AWS-IAM-Aussteller direkt akzeptieren.

Private Key JWT nimmt daher eine nützliche Zwischenposition ein. Es nutzt eine standardisierte OAuth-Authentifizierungsmethode und hält das private Signaturmaterial zugleich unter der Kontrolle von KMS.

Die größere Bedeutung der Funktion liegt darin, wie sie einen Agenten behandelt. Statt dem Agenten eine wiederverwendbare Zugangsinformation zu geben, führt die Plattform bei Bedarf einen eng autorisierten kryptografischen Vorgang aus.

Dieses Muster verringert den Wert kopierter Konfigurationsdaten. Es schafft zudem einen durchsetzbaren Kontrollpunkt für jede Token-Anfrage. Das sind konkrete Verbesserungen für autonome Workloads, die häufig und mit begrenzter Aufsicht arbeiten.

Der Kompromiss besteht in einer höheren Präzision bei der Konfiguration. Teams müssen Algorithmen, öffentliche Schlüssel, JWT-Claims, IAM-Richtlinien, OAuth-Grants, Token-Scopes und Logging-Kontrollen aufeinander abstimmen.

Amazon AWS hat diese Komplexität besser handhabbar gemacht, indem es die Signierung in AgentCore Identity integriert hat. Die damit verbundenen Vertrauensentscheidungen sind dadurch jedoch nicht verschwunden.

Bevor Sie die Methode breit einsetzen, wählen Sie einen repräsentativen Agenten aus und verfolgen Sie seinen vollständigen Zugriffspfad. Identifizieren Sie alle beteiligten Principals, Tokens, Grants, Scopes, Log-Quellen und Widerrufsmechanismen.

Testen Sie anschließend Rotation und Fehlerfälle, nicht nur eine erfolgreiche Authentifizierung. Wenn Ihr Team erklären kann, wer jede Signatur angefordert hat und was danach geschah, leistet Private Key JWT mehr als nur ein Secret zu ersetzen.