Amazon AWS dodaje Private Key JWT do AgentCore Identity, zastępując współdzielone sekrety kontrolą KMS

Amazon AWS dodał uwierzytelnianie Private Key JWT do AgentCore Identity, zapewniając zautomatyzowanym agentom nową alternatywę dla długotrwałych sekretów klienta OAuth. Zmiana przenosi uwierzytelnianie klientów w kierunku krótkotrwałych, podpisanych asercji opartych na AWS Key Management Service. Tworzy też wyraźniejszy zapis każdego żądania podpisu w AWS CloudTrail.

To połączenie ma znaczenie, ponieważ autonomiczny agent może żądać tokenów znacznie częściej niż konwencjonalna aplikacja używana przez pracowników. Skopiowany sekret klienta może pozostać użyteczny, dopóki ktoś go nie obróci lub nie unieważni. Asercja Private Key JWT szybko wygasa i przy każdym nowym żądaniu wymaga dostępu do chronionego klucza podpisującego.

Główne napięcie nie sprowadza się po prostu do kluczy kontra haseł. Amazon Bedrock AgentCore Identity obiecuje teraz silniejszą kontrolę bez zmuszania deweloperów do budowania i obsługi własnej usługi podpisującej. To, czy ta obietnica się sprawdzi, zależy od zgodności z dostawcą tożsamości, precyzyjnej konfiguracji oświadczeń, uprawnień KMS oraz pełnego pokrycia audytowego.

Amazon AWS przenosi uwierzytelnianie klienta OAuth do KMS

Istotna zmiana polega na tym, że AgentCore Identity może uwierzytelnić klienta OAuth bez przechowywania wielokrotnie używanego sekretu klienta.

W nowym wzorcu opisanym w ogłoszeniu Private Key JWT AgentCore Identity tworzy JSON Web Token i podpisuje go za pośrednictwem AWS KMS. Dostawca tożsamości weryfikuje ten podpis, używając odpowiadającego mu klucza publicznego.

Klucz prywatny pozostaje w KMS. Agent, proces aplikacji ani administrator nie muszą eksportować klucza do pliku konfiguracyjnego, obrazu kontenera, zmiennej środowiskowej ani osobnego magazynu sekretów.

Podpisany JWT jest asercją klienta, co oznacza, że potwierdza tożsamość klienta OAuth wobec serwera autoryzacji. Nie jest tokenem dostępu, który ostatecznie przedstawia się API. Serwer autoryzacji weryfikuje asercję przed wydaniem tego tokenu dostępu.

To rozróżnienie łatwo przeoczyć. Uwierzytelnianie klienta OAuth odpowiada na pytanie, czy aplikacja żądająca tokenu jest zarejestrowanym klientem. Grant OAuth określa, czyj autorytet reprezentuje wynikowy token i jakie uprawnienia otrzymuje.

Private Key JWT może zatem działać w ramach więcej niż jednego przepływu grantów. AgentCore Identity obsługuje dostęp delegowany przez użytkownika za pośrednictwem grantu authorization code oraz dostęp machine-to-machine za pośrednictwem client credentials. Jego szersze wzorce uwierzytelniania obejmują również konfiguracje wymiany tokenów on-behalf-of.

W przypadku żądania delegowanego przez użytkownika osoba najpierw autoryzuje dostęp za pośrednictwem dostawcy tożsamości. Następnie AgentCore Identity uwierzytelnia klienta OAuth podczas wymiany kodu autoryzacyjnego na tokeny. Zgoda użytkownika i tożsamość klienta pozostają odrębnymi mechanizmami kontroli.

W przypadku żądania machine-to-machine żaden użytkownik nie przechodzi przez interaktywny ekran zgody. Agent żąda tokenu dostępu w ramach własnego autorytetu aplikacji. Private Key JWT uwierzytelnia tę aplikację podczas wymiany client credentials.

To sprawia, że funkcja jest istotna nie tylko dla logowania. Jej celem jest wychodzący dostęp agentów do firmowych API, usług oprogramowania i innych chronionych zasobów. Są to właśnie połączenia, w których statyczne poświadczenie może stać się obciążeniem operacyjnym.

AgentCore Identity już działa jako pośrednik między agentami, serwerami autoryzacji i serwerami zasobów. Pobiera poświadczenia, jednocześnie chroniąc długoterminowe sekrety i tokeny odświeżania przed kodem agentów. Private Key JWT rozszerza tę granicę na materiał uwierzytelniający klienta OAuth.

Ścieżka żądania obejmuje teraz kilka wyraźnych etapów. Agent prosi AgentCore Identity o autoryzowany dostęp. AgentCore Identity tworzy ograniczoną czasowo asercję, wywołuje KMS w celu jej podpisania i wysyła ją do punktu końcowego tokenów dostawcy tożsamości.

Dostawca tożsamości sprawdza podpis względem zarejestrowanego klucza publicznego. Ocienia także oświadczenia identyfikujące klienta, odbiorcę, czas wydania i wygaśnięcie. Jeśli te kontrole zakończą się powodzeniem, dostawca zwraca token dostępu za pośrednictwem AgentCore Identity.

Ten projekt nie eliminuje zaufania. Przenosi je do polityk KMS, ról IAM, konfiguracji OAuth i rejestracji klucza publicznego u dostawcy tożsamości. Mechanizmy te są bardziej szczegółowe niż jeden skopiowany ciąg znaków, lecz tworzą też więcej miejsc, w których niezgodność może zatrzymać uwierzytelnianie.

Jak Private Key JWT zmienia model sekretów

Private Key JWT ogranicza zależność od współdzielonych sekretów, ale jego bezpieczeństwo zależy od kontrolowania, kto może zlecać KMS podpisywanie.

Tradycyjne uwierzytelnianie klienta OAuth często wykorzystuje client_secret_basic lub client_secret_post. Obie metody wysyłają identyfikator klienta i współdzielony sekret do serwera autoryzacji. Różnica polega na tym, czy te poświadczenia pojawiają się w nagłówku HTTP Basic, czy w treści żądania.

Dokumentacja AWS opisuje HTTP Basic jako domyślną metodę dla niestandardowych dostawców AgentCore Identity. Sekret pozostaje wielokrotnie używany aż do rotacji, wygaśnięcia lub unieważnienia. Każdy system posiadający jego kopię staje się częścią granicy bezpieczeństwa poświadczenia.

Private Key JWT zastępuje ten symetryczny model asymetryczną parą kluczy. Jedna strona kontroluje prywatny klucz podpisujący, podczas gdy dostawca tożsamości przechowuje wyłącznie publiczny klucz weryfikacyjny. Ujawnienie klucza publicznego nie pozwala atakującemu tworzyć prawidłowych asercji.

Podejście jest zgodne z profilem OAuth JWT, który definiuje JWT dla uwierzytelniania klientów i grantów autoryzacyjnych. Żądanie tokenu zawiera asercję klienta i identyfikuje ją jako asercję okaziciela JWT.

Typowa asercja zawiera oświadczenie issuer identyfikujące klienta, oświadczenie subject dotyczące tego klienta oraz oświadczenie audience wskazujące punkt końcowy tokenów. Obejmuje również czasy wygaśnięcia i wydania. Unikalny identyfikator JWT może pomóc dostawcy tożsamości wykrywać próby ponownego użycia.

Pola te nie są ozdobnymi metadanymi. Nieprawidłowy odbiorca może sprawić, że poprawnie podpisany JWT będzie nieważny. Różnica czasu może spowodować, że dostawca odrzuci asercję jako przedwczesną lub wygasłą.

Private Key JWT również nie gwarantuje automatycznie ochrony przed ponownym użyciem. RFC 7523 pozostawia część mechanizmów obronnych przed powtórzeniami polityce wdrożeniowej. Dostawcy tożsamości potrzebują odpowiednich limitów ważności oraz, tam gdzie jest to obsługiwane, śledzenia unikalnych asercji.

Krótkie okresy ważności ograniczają użyteczność przechwyconej asercji. Nie chronią jednak systemu, w którym atakujący ma uprawnienie do wielokrotnego wywoływania klucza podpisującego. Dlatego polityka klucza KMS i uprawnienia IAM stają się podstawową warstwą egzekwowania kontroli.

AWS KMS reprezentuje klucz asymetryczny jako powiązaną parę klucza publicznego i prywatnego. W przypadku kluczy podpisujących komponent prywatny pozostaje chroniony wewnątrz usługi. Komponent publiczny można pobrać i zarejestrować u zewnętrznego dostawcy tożsamości.

KMS obsługuje wiele asymetrycznych typów kluczy, w tym klucze RSA i krzywych eliptycznych do podpisywania oraz weryfikacji. Wybrany typ klucza i algorytm muszą odpowiadać temu, co akceptuje dostawca tożsamości.

AgentCore Identity potrzebuje uprawnienia do używania skonfigurowanego klucza do podpisywania. AWS podaje, że osoby wywołujące operację KMS Sign wymagają autoryzacji kms:Sign za pośrednictwem polityki klucza. Usługa korzysta następnie z komponentu prywatnego, nie zwracając go.

To istotne ulepszenie ograniczenia ryzyka. Wyciek konfiguracji ujawniający ARN klucza nie ujawnia materiału klucza prywatnego. Atakujący nadal potrzebowałby poświadczeń AWS i skutecznej autoryzacji do wywołania klucza.

Jednak uprawnienie do podpisywania pozostaje wrażliwe. Rola z szerokim dostępem kms:Sign mogłaby potencjalnie żądać podpisów poza zamierzoną ścieżką obciążenia roboczego. Zespoły powinny wiązać uprawnienia z właściwymi rolami wykonawczymi AgentCore i unikać ogólnego dostępu z symbolami wieloznacznymi.

Zmiana wpływa również na rotację. W przypadku współdzielonego sekretu obie strony muszą zastąpić tę samą poufną wartość. Przy uwierzytelnianiu asymetrycznym zespoły mogą wprowadzić nowy klucz publiczny u dostawcy tożsamości, zachowując stary klucz weryfikacyjny podczas kontrolowanego przejścia.

To nakładanie się może ograniczyć przestoje, o ile dostawca tożsamości obsługuje wiele aktywnych kluczy. Jeśli akceptuje tylko jeden klucz publiczny, rotacja nadal wymaga skoordynowanego harmonogramu. Private Key JWT zmienia materiał podlegający rotacji, a nie potrzebę przetestowanego procesu rotacji.

Obsługiwane przepływy grantów służą różnym tożsamościom agentów

Private Key JWT uwierzytelnia klienta OAuth, podczas gdy wybrany grant określa, czy agent działa we własnym imieniu, czy w imieniu użytkownika.

Grant authorization code pasuje do agentów uzyskujących dostęp do zasobów w imieniu osoby. Użytkownik loguje się za pośrednictwem dostawcy tożsamości i zatwierdza żądane uprawnienia. Serwer autoryzacji zwraca kod, który klient wymienia na tokeny.

Podczas tej wymiany AgentCore Identity wykorzystuje asercję Private Key JWT, aby udowodnić, że żądanie składa zarejestrowany klient. Asercja nie zastępuje zgody użytkownika. Wzmacnia uwierzytelnianie w punkcie końcowym tokenów.

Ten przepływ sprawdza się w przypadku agenta odczytującego kalendarz użytkownika, przeszukującego autoryzowane rekordy pracownika lub aktualizującego system zarządzania klientami w ramach delegowanych uprawnień. Wynikowy dostęp pozostaje powiązany z użytkownikiem i zatwierdzonymi zakresami.

Grant client credentials dotyczy innego przypadku. Tutaj obciążenie robocze działa we własnym imieniu, bez interaktywnego użytkownika. Zaplanowany agent może wywoływać wewnętrzne API zapasów, przetwarzać alerty usługowe lub pobierać zatwierdzone dane operacyjne.

Private Key JWT uwierzytelnia tego klienta maszynowego, zanim serwer autoryzacji wyda token aplikacyjny. Ponieważ nie ma obecnej osoby, tożsamość klienta, zakresy tokenu i polityka autoryzacji po stronie systemów docelowych przejmują większą część ciężaru bezpieczeństwa.

Organizacje nie powinny traktować tych dwóch grantów jako wymiennych opcji wdrożeniowych. Użycie client credentials do zadania, które powinno zachować tożsamość użytkownika, może zaciemnić rozliczalność. Użycie przepływu delegowanego do pracy usługowej w tle może tworzyć kruche zależności od indywidualnych kont.

Dostęp on-behalf-of wprowadza kolejny wariant. Agent otrzymuje dowód istniejącej tożsamości użytkownika i wymienia go na token odpowiedni dla innego zasobu. Przepływ musi zachować relację między użytkownikiem, agentem i usługą docelową.

Dokumentacja AgentCore Identity opisuje dla tych przypadków zarówno standardową wymianę tokenów, jak i podejścia oparte na grancie autoryzacyjnym JWT. Obsługa nadal zależy od zewnętrznego serwera autoryzacji i jego zasad wymiany tokenów.

Private Key JWT może uwierzytelnić klienta uczestniczącego w tej wymianie. Nie rozstrzyga, czy przychodzący token użytkownika jest prawidłowy ani czy żądana delegacja powinna być dozwolona. Decyzje te pozostają po stronie odpowiednich systemów tożsamości i autoryzacji.

To rozdzielenie jest jednym z najmocniejszych aspektów architektonicznych tej funkcji. Zespoły mogą wybrać grant na podstawie autorytetu, jakiego potrzebuje agent, a następnie wybrać Private Key JWT na podstawie sposobu, w jaki klient powinien potwierdzić swoją tożsamość.

Podkreśla też, dlaczego pojedyncze „poświadczenie agenta” jest niebezpiecznym modelem mentalnym. Agent może mieć tożsamość obciążenia roboczego, działać w imieniu użytkownika, wywoływać kilka serwerów zasobów i używać różnych tokenów dla każdego miejsca docelowego.

Token dostępu do obciążenia AgentCore Identity dodaje kolejną warstwę. AWS podaje, że token ten może zawierać tożsamość agenta i tożsamość użytkownika końcowego, gdy agent żąda poświadczeń ze skarbca. AgentCore Runtime może automatycznie przekazywać go hostowanym agentom.

Ten token obciążenia autoryzuje dostęp do AgentCore Identity. Zewnętrzny token dostępu OAuth autoryzuje dostęp do docelowego API. Asercja Private Key JWT uwierzytelnia klienta OAuth podczas wydawania tokenu.

W jednej transakcji end-to-end mogą więc wystąpić trzy tokeny, z których każdy pełni inną funkcję. Ich pomylenie może prowadzić do nieprawidłowej walidacji, nadmiernego logowania lub przypadkowego ujawnienia.

Przeglądy bezpieczeństwa powinny przypisać każdy token do jego wystawcy, odbiorcy, posiadacza, czasu życia i miejsca docelowego. Powinny też wskazać, który komponent może go odświeżyć lub zastąpić. Takie ćwiczenie pozwala wykryć błędy projektowe, które mogą pozostawać niewidoczne na diagramach na poziomie produktu.

Szersza presja konkurencyjna dotyczy opartych na sekretach integracji agentowych. Statyczne sekrety klienta są znane i szeroko obsługiwane, ale słabo skalują się, gdy wiele autonomicznych obciążeń potrzebuje niezależnych uprawnień i ścieżek audytu.

Private Key JWT zwiększa nakład pracy przy konfiguracji, jednocześnie ograniczając powielanie poświadczeń. Dla zespołów, które już korzystają z AWS IAM, KMS i CloudTrail, taka wymiana może być atrakcyjna. W mniejszych wdrożeniach dodatkowa powierzchnia polityk może jednak przeważyć nad natychmiastową korzyścią.

Konfiguracja łańcucha zaufania wymaga więcej niż wybrania metody

Konfiguracja powiedzie się tylko wtedy, gdy KMS, IAM, AgentCore Identity i zewnętrzny dostawca tożsamości uzgodnią te same szczegóły kryptograficzne i OAuth.

Pierwszym wymogiem jest asymetryczny klucz KMS skonfigurowany do podpisywania i weryfikacji. Klucze szyfrujące nie mogą realizować tego zadania. Specyfikacja klucza i algorytm podpisu muszą odpowiadać kombinacji akceptowanej przez docelowego dostawcę tożsamości.

AWS KMS udostępnia publiczną część asymetrycznego klucza do podpisywania. Zespoły rejestrują ten klucz publiczny u swojego dostawcy tożsamości — bezpośrednio lub za pośrednictwem obsługiwanej konfiguracji JSON Web Key.

Dostawca tożsamości musi powiązać klucz z właściwym klientem OAuth. Musi również obsługiwać Private Key JWT w swoim punkcie końcowym tokenów. Interfejsy rejestracji i akceptowane algorytmy różnią się między dostawcami, dlatego ten etap pozostaje zależny od konkretnego dostawcy.

Następnie administratorzy tworzą lub aktualizują niestandardowego dostawcę poświadczeń OAuth w konsoli Amazon Bedrock AgentCore. Konfiguracja wymaga informacji o wykrywaniu dostawcy, identyfikatora klienta, ARN klucza KMS i algorytmu podpisu.

Mechanizm wykrywania OAuth pozwala AgentCore Identity odnaleźć punkty końcowe autoryzacji i tokenów na podstawie metadanych dostawcy. Zespoły powinny zweryfikować, czy wykryty punkt końcowy tokenów odpowiada wartości audience oczekiwanej przez dostawcę tożsamości.

AgentCore Identity potrzebuje również uprawnienia do wywoływania KMS. Operacja podpisywania w KMS wymaga klucza o zastosowaniu SIGN_VERIFY oraz algorytmu zgodnego z tym kluczem.

KMS akceptuje surową wiadomość lub wcześniej obliczony skrót, zależnie od wybranego typu wiadomości. Implementacja JWT musi unikać przypadkowego podwójnego haszowania, ponieważ zewnętrzna weryfikacja zakłada zachowanie haszowania określone przez algorytm.

Znaczenie ma także konfiguracja nagłówka JWT. Dostawca tożsamości może używać identyfikatora klucza do wybrania właściwego klucza publicznego. Brakujący lub nieprawidłowy identyfikator staje się szczególnie problematyczny podczas rotacji, gdy aktywnych może być kilka kluczy publicznych.

Równie starannego podejścia wymagają oświadczenia w ładunku. Wystawca i podmiot zwykle odpowiadają identyfikatorowi klienta OAuth. Odbiorca zwykle identyfikuje punkt końcowy tokenów serwera autoryzacji, choć dokładną wartość powinny określać wymagania dostawcy.

Czas wygaśnięcia powinien być krótki. Czas wystawienia musi odzwierciedlać zsynchronizowany zegar. Unikalny identyfikator tokenu jest wartościowy tam, gdzie dostawca rejestruje wcześniej zaakceptowane asercje.

Po zapisaniu dostawcy poświadczeń zespoły powinny niezależnie przetestować każdy planowany grant. Udane żądanie client credentials nie dowodzi, że wymiana kodu autoryzacyjnego lub wymiana tokenów została poprawnie skonfigurowana.

Testy powinny zaczynać się od minimalnych zakresów. Jeśli uwierzytelnienie się powiedzie, ale autoryzacja zawiedzie, łatwiej zdiagnozować różnicę. Dodawanie szerokich uprawnień w celu obejścia błędu może ukryć problem z odbiorcą lub rejestracją klienta.

Zespoły powinny również testować ścieżki negatywne. Żądanie podpisane niewłaściwym kluczem powinno zakończyć się niepowodzeniem. Wygasła asercja powinna zostać odrzucona. Nieprawidłowy odbiorca i nieautoryzowany wywołujący KMS powinny generować rozróżnialne dowody.

W tym miejscu widoczny staje się kompromis operacyjny. Współdzielone sekrety są na tyle proste, że zespoły często walidują wyłącznie ścieżkę pozytywną. Private Key JWT zapewnia silniejsze granice, ale wymagają one jawnego testowania.

Konfiguracja tworzy również zależności między zespołami administracyjnymi. Zespół bezpieczeństwa chmurowego może być właścicielem polityk KMS i IAM. Zespół tożsamości może kontrolować klienta OAuth i rejestrację klucza publicznego.

Właściciele aplikacji konfigurują AgentCore Identity i określają zakresy grantów. Zespoły audytowe decydują, które wpisy CloudTrail muszą być przechowywane i objęte alertami. Żaden pojedynczy wybór w konsoli nie rozwiązuje tych kwestii własności.

Przydatne wdrożenie pilotażowe zaczyna się od jednej niekrytycznej integracji. Zespoły mogą udokumentować wymagania dotyczące oświadczeń, reakcje na błędy, kroki rotacji i odpowiedzialność za eskalację, zanim zastosują tę metodę do wielu agentów.

Automatyzacja powinna nastąpić po pierwszym zweryfikowanym wdrożeniu. Szablony infrastruktury mogą ujednolicić polityki kluczy i ustawienia dostawców poświadczeń, ale nie powinny zgadywać zachowania dostawcy tożsamości.

Rezultatem nie jest system pozbawiony sekretów. Tokeny nadal istnieją, serwery autoryzacji wciąż utrzymują zaufanie, a uprawnienia AWS pozostają poświadczeniami. Węższe twierdzenie jest bardziej obronne: klient OAuth nie zależy już od współdzielonego, wielokrotnego użytku sekretu.

CloudTrail zamienia każdy podpis w sygnał audytowy

Podpisywanie wspierane przez KMS zapewnia obrońcom zdarzenie po stronie AWS, które mogą skorelować z żądaniami tokenów i aktywnością agentów.

AWS KMS integruje się z CloudTrail, który rejestruje wywołania wykonywane przez użytkowników, role i usługi AWS. Jego rejestrowanie audytowe KMS obejmuje operacje kryptograficzne oraz działania związane z zarządzaniem kluczami.

Transakcja Private Key JWT powinna zatem tworzyć dowody dotyczące żądania podpisania w KMS. Zdarzenie może identyfikować operację, region, czas, właściwy klucz oraz zaangażowany podmiot AWS lub kontekst usługi.

Sam ten zapis nie przedstawia pełnej historii. CloudTrail pokazuje, że autoryzowana tożsamość AWS zażądała podpisu. Logi zewnętrznego dostawcy tożsamości pokazują, czy zaakceptował on asercję i wydał token.

Logi audytowe usługi docelowej pokazują, co zrobił wynikowy token dostępu. Skuteczne dochodzenie koreluje wszystkie trzy warstwy, zamiast traktować zdarzenie KMS jako dowód udanego dostępu do zasobu.

CloudTrail nadal może odpowiadać na ważne pytania. Śledczy mogą szukać nieoczekiwanego wolumenu podpisów, żądań z niewłaściwej roli, wywołań w niezatwierdzonym regionie lub aktywności obejmującej klucz poza jego normalnym harmonogramem.

Znaczenie mają skonfigurowane selektory zdarzeń. AWS klasyfikuje zdarzenia KMS jako zdarzenia zarządzania, a ścieżki CloudTrail zwykle rejestrują aktywność związaną z zarządzaniem. Administratorzy mogą jednak jawnie wykluczyć zdarzenia KMS.

AWS ostrzega, że operacje KMS mogą generować duże wolumeny zdarzeń. Niektóre organizacje filtrują je, aby kontrolować wolumen logów. Może to usunąć właśnie te dowody podpisywania, które ułatwiają audyt tego wzorca uwierzytelniania.

Zespoły wdrażające Private Key JWT powinny przejrzeć swoje ustawienia zdarzeń zarządzania. Powinny potwierdzić, że istotna aktywność KMS trafia do zamierzonej ścieżki lub magazynu danych zdarzeń.

Znaczenie mają także retencja i możliwość wyszukiwania. Historia zdarzeń jest przydatna podczas niedawnych dochodzeń, natomiast ścieżka lub magazyn danych zdarzeń CloudTrail Lake wspiera dłuższe analizy. Wyeksportowane zapisy mogą również zasilać systemy monitorowania bezpieczeństwa.

Punkt odniesienia powinien odróżniać oczekiwane zachowanie związane z odświeżaniem tokenów od anomalii. Stale działający agent maszynowy może podpisywać asercje w regularnym rytmie. Przepływ pracy delegowany użytkownikowi może tworzyć serie żądań podczas aktywnych sesji.

Duże odchylenia mogą wskazywać na pętlę ponawiania prób, błąd konfiguracji lub niewłaściwe użycie poświadczeń. Powtarzające się podpisywanie, po którym następuje odrzucenie przez punkt końcowy tokenów, może wskazywać na nieprawidłowego odbiorcę, wygasły klucz publiczny lub problem z zegarem.

Aktywność podpisywania bez odpowiadających jej żądań AgentCore zasługuje na bliższą analizę. Podobnie jest z udanym wydaniem tokenu bez oczekiwanych dalszych wywołań. Każdy wzorzec wskazuje na inną przerwę w łańcuchu zaufania.

Zdarzenia cyklu życia klucza powinny otrzymywać osobne alerty. Wyłączenie klucza podpisującego może zatrzymać każdą zależną integrację. Zmiany polityk mogą po cichu rozszerzyć grono podmiotów uprawnionych do jego wywoływania.

CloudTrail pomaga również podczas rotacji. Zespoły mogą obserwować, czy stary klucz nadal otrzymuje żądania podpisywania po aktywacji nowego klucza. Dalsza aktywność może ujawnić pominiętego dostawcę poświadczeń lub opóźnione wdrożenie.

Widoczność audytowa pozostaje jednak warunkowa. Logi muszą być włączone, przechowywane, chronione i przeglądane. Zdarzenie zarejestrowane, ale nigdy niewyszukane, zapewnia niewielką praktyczną ochronę.

Zdarzenia CloudTrail nie walidują również biznesowego uzasadnienia żądania. Prawidłowo autoryzowany agent nadal może zażądać tokenu dostępu w niewłaściwym czasie albo użyć go do zbyt szerokiego zadania.

To ograniczenie kieruje uwagę ku projektowaniu autoryzacji. Private Key JWT może udowodnić, że klient kontroluje dostęp do klucza podpisującego. Nie może określić, czy cel agenta, wybrane narzędzie lub żądana operacja są odpowiednie.

Organizacje potrzebują ograniczeń zakresów, polityk serwera zasobów, kontroli obciążeń i monitorowania zachowania wokół kryptograficznego dowodu. Podpis jest jednym wysokiej jakości sygnałem, a nie kompletnym systemem zarządzania agentami.

Na co przedsiębiorstwa powinny zwracać uwagę po uruchomieniu Private Key JWT

Kolejny test pokaże, czy Private Key JWT stanie się standardem operacyjnym, czy pozostanie zaawansowaną opcją dla ściśle zarządzanych wdrożeń.

Pierwszym sygnałem jest interoperacyjność dostawców tożsamości. Udane wdrożenie wymaga, aby dostawcy akceptowali wybrane algorytmy podpisywania, oświadczenia, format odbiorcy i metodę rejestracji klucza publicznego.

AWS może uprościć swoją stronę wymiany, ale nie może ujednolicić administracyjnego przepływu pracy każdego dostawcy. Jasne przykłady specyficzne dla dostawców ograniczyłyby liczbę nieudanych wdrożeń i niebezpiecznych obejść.

Drugim sygnałem jest zachowanie podczas rotacji. Przedsiębiorstwa muszą wiedzieć, czy mogą rejestrować nakładające się klucze publiczne, aktualizować dostawców AgentCore bez przerw oraz potwierdzać migrację za pomocą zapisów audytowych.

Funkcja działająca tylko podczas początkowej konfiguracji rozwiązuje połowę problemu. Uwierzytelnianie produkcyjne potrzebuje także przewidywalnego odzyskiwania sprawności, gdy klucz zostanie wyłączony, zastąpiony lub skompromitowany.

Trzecim sygnałem jest wykorzystanie audytu. CloudTrail daje zespołom dostęp do zapisów podpisywania, ale organizacje muszą przechowywać zdarzenia KMS i łączyć je z logami dostawców tożsamości oraz serwerów zasobów.

Wskazówki dotyczące wykrywania uczyniłyby tę funkcję bardziej użyteczną. Wysokie tempo podpisywania, nieznane podmioty, powtarzające się błędy i nieoczekiwana aktywność regionalna to praktyczni kandydaci do alertów.

Zespoły bezpieczeństwa powinny również obserwować granice modelu uprawnień AgentCore Identity. Idealna polityka pozwala jednemu obciążeniu używać jednego klucza podpisującego dla jednego zatwierdzonego dostawcy, bez przyznawania niezwiązanego dostępu do podpisywania.

Klucze międzykontowe zapewniają elastyczność, ale wymagają starannych polityk zasobów. AWS KMS obsługuje użycie międzykontowe do podpisywania, gdy wywołujący określają ARN klucza i otrzymują wymagane uprawnienia.

Ta funkcja może wspierać scentralizowane zarządzanie bezpieczeństwem. Może jednak również tworzyć zależności między kontami aplikacji a centralnym kontem tożsamości. Awarie lub błędy w politykach na koncie centralnym mogą wpływać na wielu agentów.

Przedsiębiorstwa powinny mierzyć wyniki operacyjne, zamiast zakładać, że projekt kryptograficzny gwarantuje sukces. Przydatne wskaźniki obejmują obciążenie związane z rotacją sekretów, niepowodzenia żądań tokenów, nieautoryzowane próby podpisywania oraz czas odzyskiwania sprawności po zmianach kluczy.

Powinny także porównać Private Key JWT z uwierzytelnianiem JWT podpisywanym przez AWS IAM. Dokumentacja AgentCore Identity opisuje metodę AWS_IAM_ID_TOKEN_JWT, która wykorzystuje potwierdzenie wystawione przez IAM i wymaga, aby serwer autoryzacji ufał AWS IAM.

Oba podejścia odchodzą od współdzielonych sekretów klienta, ale inaczej ustanawiają zaufanie. Private Key JWT wymaga, aby dostawca tożsamości ufał publicznemu kluczowi zarządzanemu przez klienta. Metoda IAM wymaga zaufania do AWS IAM jako wystawcy.

Wsparcie po stronie dostawcy często przesądzi o tym, które rozwiązanie jest praktyczne. Niektóre systemy tożsamości już obsługują Private Key JWT dla poufnych klientów OAuth. Mniej z nich może być skonfigurowanych do bezpośredniego akceptowania AWS IAM jako wystawcy.

Private Key JWT zajmuje więc użyteczne miejsce pośrednie. Stosuje standardową metodę uwierzytelniania OAuth, jednocześnie utrzymując prywatny materiał podpisujący pod kontrolą KMS.

Szersze znaczenie tej funkcji wynika ze sposobu traktowania agenta. Zamiast przekazywać agentowi poświadczenie wielokrotnego użytku, platforma wykonuje ściśle autoryzowaną operację kryptograficzną wtedy, gdy potrzebny jest dostęp.

Ten wzorzec zmniejsza wartość skopiowanych danych konfiguracyjnych. Tworzy też egzekwowalny punkt kontrolny dla każdego żądania tokenu. To konkretne ulepszenia dla autonomicznych obciążeń roboczych, które działają często i pod ograniczonym nadzorem.

Kompromisem jest większa precyzja konfiguracji. Zespoły muszą zsynchronizować algorytmy, klucze publiczne, deklaracje JWT, polityki IAM, przyznania OAuth, zakresy tokenów oraz mechanizmy kontroli logowania.

Amazon AWS uczynił tę złożoność bardziej możliwą do opanowania, wprowadzając podpisywanie do AgentCore Identity. Nie sprawił jednak, że związane z tym decyzje dotyczące zaufania zniknęły.

Przed szerokim wdrożeniem tej metody wybierz jednego reprezentatywnego agenta i prześledź jego kompletną ścieżkę dostępu. Zidentyfikuj każdego uczestnika, token, przyznanie, zakres, źródło logów i mechanizm unieważniania.

Następnie przetestuj rotację i awarie, a nie tylko udane uwierzytelnianie. Jeśli Twój zespół potrafi wyjaśnić, kto zażądał każdego podpisu i co wydarzyło się później, Private Key JWT robi więcej niż tylko zastępuje sekret.