Dostęp do Claude Platform on AWS łączy trzy środowiska, ale o wyniku w zakresie bezpieczeństwa decyduje precyzja IAM
AWS opisał trzy ścieżki dostępu do Claude Platform on AWS w ramach jednej subskrypcji, mimo że mają one wyraźnie odmienne wymagania dotyczące poświadczeń i bezpieczeństwa.
Opublikowane 1 października wdrożenie łączy obciążenia AWS, laptopy deweloperów i usługi zewnętrzne z przestrzeniami roboczymi utrzymywanymi na wydzielonym koncie AI Services. Aplikacje produkcyjne wykorzystują międzykontowe Signature Version 4, deweloperzy otrzymują API keys o ograniczonym zakresie, a obciążenia zewnętrzne uwierzytelniają się poprzez federację OpenID Connect.
Architektura obiecuje scentralizowane rozliczenia i administrację bez wymuszania jednego modelu poświadczeń dla każdego środowiska. Równie wyraźne jest jednak napięcie. Centralizacja upraszcza zarządzanie odpowiedzialnością, ale zbyt szeroka polityka IAM lub niewłaściwie obsługiwany klucz deweloperski mogą osłabić granice przestrzeni roboczych, które czynią ten projekt użytecznym.
Nie jest to po prostu kolejny przewodnik po integracji Claude. Wdrożenie AWS przekształca uwierzytelnianie w płaszczyznę kontroli zależną od środowiska. Ujawnia również pracę operacyjną ukrytą za sformułowaniem „jedna subskrypcja”.
Amazon Bedrock pozostaje ważnym punktem odniesienia. Udostępnia modele Claude za pośrednictwem zarządzanej przez AWS usługi modeli bazowych. Claude Platform on AWS oferuje natomiast natywne doświadczenie platformy Anthropic poprzez konto AWS, w tym jej APIs, konsolę i funkcje platformowe.
Nowy wzorzec dostępu nie zaciera tej różnicy. Pokazuje, jak przedsiębiorstwa mogą rozszerzyć natywną platformę Anthropic na całą organizację AWS, zachowując opartą na IAM kontrolę nad ruchem produkcyjnym.
Jedna subskrypcja obsługuje teraz trzy granice zaufania
Istotna zmiana nie polega wyłącznie na szerszej łączności. AWS przypisał trzy środowiska do trzech odrębnych metod uwierzytelniania, przy jednoczesnym scentralizowaniu własności przestrzeni roboczych.
Proponowana topologia zaczyna się od trzech ról kont. Konto zarządzające obsługuje rozliczenia i nadzór na poziomie organizacji. Wydzielone konto AI Services jest właścicielem subskrypcji Claude Platform, przestrzeni roboczych, API keys i ról dostępu.
Następnie jedno lub więcej kont obciążeń korzysta z inferencji Claude bez posiadania subskrypcji. Ich aplikacje przyjmują role na koncie AI Services i wywołują zasoby przestrzeni roboczych autoryzowane przez te role.
To rozdzielenie nadaje kontu AI Services konkretny cel. Staje się ono administracyjną granicą wokół dostępu do Claude, zamiast kolejnym ogólnym kontem aplikacyjnym wypełnionym niezwiązanymi zasobami.
AWS zaleca tworzenie na tym koncie oddzielnych przestrzeni roboczych produkcyjnych i deweloperskich. Przestrzeń robocza jest granicą zasobów służącą do oddzielania zespołów, projektów lub środowisk przy zachowaniu scentralizowanej administracji.
Każda przestrzeń robocza ma Amazon Resource Name, czyli ARN, do którego mogą odwoływać się polityki IAM. Uprawnienia mogą więc autoryzować inferencję względem jednej przestrzeni roboczej bez automatycznego autoryzowania innej.
Pierwsza ścieżka dostępu obejmuje aplikacje działające już w AWS. AWS posługuje się przykładem poda Amazon EKS, choć ten wzorzec może mieć zastosowanie do innych obciążeń AWS.
Pod najpierw przyjmuje międzykontową rolę na koncie AI Services. Tymczasowe poświadczenia następnie podpisują żądania Claude za pomocą AWS Signature Version 4, powszechnie nazywanego SigV4.
SigV4 kryptograficznie podpisuje żądania AWS API za pomocą poświadczeń AWS. Pozwala usłudze odbierającej zweryfikować wywołującego, integralność żądania i kontekst autoryzacji bez osobnego statycznego sekretu API.
Międzykontowa rola przyznaje wybrane działania aws-external-anthropic względem ARN produkcyjnej przestrzeni roboczej. Przykład obejmuje inferencję, liczenie tokenów, pobieranie modeli i ich listowanie.
Rola nie potrzebuje uprawnień dostępu do deweloperskiej przestrzeni roboczej. Tworzy to bezpośrednią relację między tożsamością obciążenia, dozwolonymi działaniami API i dopuszczoną przestrzenią roboczą Claude.
Druga ścieżka obejmuje laptopy deweloperów. Deweloperzy często potrzebują prostszego sposobu testowania promptów, działania SDK i logiki aplikacji poza wdrożonym obciążeniem.
AWS przypisuje tym użytkownikom długotrwały API key powiązany z deweloperską przestrzenią roboczą. Standardowe SDK Anthropic może używać tego klucza względem regionalnego endpointu Claude Platform on AWS.
Ta ścieżka zachowuje znane środowisko pracy dewelopera, lecz tworzy trwałe poświadczenie typu bearer. Każdy, kto posiada klucz, może korzystać z jego uprawnień, dopóki nie wygaśnie lub administrator go nie unieważni.
Trzecia ścieżka jest skierowana do usług zewnętrznych. Przykłady obejmują obciążenia działające w Google Cloud, klastry Kubernetes poza AWS oraz systemy CI/CD, takie jak GitHub Actions lub GitLab CI.
Usługi te wykorzystują federację OIDC, która wymienia podpisany token dostawcy tożsamości na tymczasowe poświadczenia AWS. Tymczasowe poświadczenia generują krótkotrwały token bearer Claude.
Przykład AWS tworzy token ważny przez godzinę. Wdrożenie umożliwia konfigurowanie okresów ważności do 12 godzin, po których usługa zewnętrzna musi uzyskać kolejny token.
Łącznie te trzy ścieżki stanowią rdzeń wielośrodowiskowego dostępu do Claude. Subskrypcja pozostaje na jednym koncie, podczas gdy uwierzytelnianie zmienia się zależnie od miejsca działania wywołującego.
Na tym polega postęp architektoniczny. Uznaje on, że pod EKS, laptop dewelopera i zewnętrzny pipeline nie powinny współdzielić jednego uniwersalnego wzorca poświadczeń.
Dostęp do Claude Platform on AWS przenosi kontrolę do IAM
Dostęp do Claude Platform on AWS zależy teraz mniej od miejsca działania kodu, a bardziej od tego, czy IAM precyzyjnie opisuje jego zamierzoną tożsamość i przestrzeń roboczą.
AWS przedstawił tę usługę jako sposób korzystania z natywnej platformy Anthropic poprzez istniejące konto AWS. Firma podała, że AWS był pierwszym dostawcą chmury oferującym takie natywne doświadczenie przez własną strukturę kont.
Oryginalne ogłoszenie połączyło uwierzytelnianie, rozliczenia i funkcje audytowe z AWS. Klienci mogli używać APIs i narzędzi Anthropic bez nawiązywania odrębnej relacji handlowej.
Wielośrodowiskowy projekt rozszerza tę propozycję poza podstawowe połączenie API. Sprawia, że warstwą organizującą dostęp do Claude staje się organizacja AWS, a nie pojedyncza aplikacja.
Ma to znaczenie, ponieważ wykorzystanie AI w przedsiębiorstwach rzadko pozostaje w jednym środowisku. Zespół może testować aplikację lokalnie, wdrożyć ją w EKS i uruchamiać ewaluacje z innej chmury.
Współdzielony statyczny klucz może połączyć wszystkie trzy lokalizacje, ale jednocześnie zaciera ich tożsamości. Logi pokazują klucz, niekoniecznie obciążenie, konto lub pipeline, który z niego skorzystał.
Role międzykontowe zachowują więcej kontekstu. Obciążenie przyjmuje nazwaną rolę, otrzymuje tymczasowe poświadczenia i wysyła podpisane żądania, które AWS może przypisać do podmiotu.
Rola tworzy także dwa punkty kontrolne autoryzacji. Konto obciążenia musi zezwolić swojej lokalnej tożsamości na przyjęcie roli docelowej. Konto AI Services musi zaufać tej tożsamości i organizacji.
Przykład AWS dodaje warunek aws:PrincipalOrgID do polityki zaufania. Warunek ten ogranicza przyjmowanie ról do podmiotów powiązanych z określoną organizacją AWS.
Polityka uprawnień ogranicza następnie inferencję do ARN produkcyjnej przestrzeni roboczej. Zaufanie odpowiada na pytanie, kto może przyjąć rolę, podczas gdy uprawnienia definiują, co ta rola może zrobić później.
To rozdzielenie wywiera presję na zespoły, które wcześniej traktowały dostęp do modeli jako dystrybucję sekretów. Muszą teraz zarządzać uwierzytelnianiem Claude AWS jako architekturą tożsamości.
Zespoły bezpieczeństwa, platformowe i aplikacyjne muszą uzgodnić własność kont. Potrzebują również standardów nazewnictwa dla ról, przestrzeni roboczych, polityk i mapowań środowisk.
Wydzielone konto może uwidocznić te obowiązki. Nie czyni ich jednak automatycznie poprawnymi.
Architektura wpływa również na reagowanie na incydenty. Rola produkcyjna może zostać wyłączona bez natychmiastowego usuwania dostępu deweloperów. Przejęty klucz deweloperski można unieważnić bez zmiany roli obciążenia EKS.
Rozdzielenie przestrzeni roboczych może także wspierać przypisywanie kosztów. AWS podaje, że organizacje mogą tagować przestrzenie robocze i aktywować te tagi do alokacji kosztów.
Po aktywacji, która według AWS może potrwać od 24 do 48 godzin, zespoły mogą filtrować dane AWS Cost Explorer według przestrzeni roboczej. Tworzy to ścieżkę od izolacji technicznej do analizy wydatków na poziomie projektu.
Audytowalność wymaga kolejnego wyraźnego wyboru. Administracja przestrzeniami roboczymi domyślnie pojawia się w zdarzeniach zarządzania CloudTrail, ale inferencja należy do kategorii zdarzeń danych.
Dokumentacja monitorowania wskazuje, że zespoły muszą włączyć rejestrowanie zdarzeń danych, aby rejestrować inferencję i inne operacje przestrzeni roboczych. Zdarzenia te mogą również powodować dodatkowe opłaty CloudTrail.
To rozróżnienie łatwo przeoczyć. Centralizacja subskrypcji zwiększa potencjał ścieżki audytowej, ale nie gwarantuje rejestrowania aktywności inferencyjnej.
Projekt wywiera więc presję na właścicieli platform, by traktowali obserwowalność jako część kontroli dostępu. Polityka może ograniczyć działanie, podczas gdy rejestrowanie dostarcza dowodów na to, który podmiot faktycznie je wykonał.
Trzy ścieżki uwierzytelniania rozwiązują różne problemy
Architektura działa, ponieważ nie wymusza umieszczenia wygody, tożsamości obciążenia i federacji zewnętrznej w tym samym cyklu życia poświadczeń.
W przypadku obciążeń AWS międzykontowe SigV4 zapewnia najczystsze dopasowanie do istniejącej tożsamości chmurowej. Aplikacja otrzymuje tymczasowe poświadczenia AWS poprzez przyjęcie roli.
Następnie podpisuje każde żądanie do endpointu Claude. Na koncie obciążenia, w obrazie kontenera ani w konfiguracji wdrożenia nie jest przechowywany osobny Claude API key.
Podejście to jest zgodne z utrwalonymi zaleceniami AWS. Najlepsze praktyki IAM firmy zalecają tymczasowe poświadczenia ról dla obciążeń zamiast długotrwałych access keys.
Rola produkcyjna może obejmować wyłącznie działania potrzebne aplikacji. Podstawowa aplikacja synchroniczna może potrzebować uprawnień do inferencji i liczenia tokenów, lecz nie do działań dotyczących plików, zadań wsadowych ani administracji.
Claude Platform on AWS używa przestrzeni nazw IAM aws-external-anthropic. Jej model uprawnień mapuje ścieżki API na konkretne działania, takie jak CreateInference dla żądań wiadomości.
Działanie to może odwoływać się do ARN jednej przestrzeni roboczej. Aplikacja uzyskuje dostęp do produkcyjnej przestrzeni roboczej bez dziedziczenia ogólnokontowych uprawnień Claude.
Jest to najsilniejsza z trzech ścieżek dla ciągłych obciążeń AWS. Aplikacja nie przechowuje trwałego sekretu Claude, a AWS może przypisywać żądania przyjętej tożsamości.
Laptopy deweloperów tworzą inne ograniczenie. Wymaganie, by każdy lokalny eksperyment przechodził przez łańcuch ról międzykontowych, może zwiększać koszty konfiguracji i spowalniać iterację.
AWS wykorzystuje zatem API key o zakresie ograniczonym do przestrzeni roboczej dla środowiska deweloperskiego. Klucz działa ze standardowym klientem Anthropic i wskazuje na regionalny endpoint Claude Platform on AWS.
Ważnym zastrzeżeniem jest to, że nowo wygenerowany klucz nie jest automatycznie wystarczająco zawężony dla tego wzorca. AWS podaje, że przypisany do niego użytkownik IAM początkowo otrzymuje zarządzaną politykę AnthropicLimitedAccess.
Zgodnie z przewodnikiem wdrożeniowym ta zarządzana polityka przyznaje dostęp do wszystkich przestrzeni roboczych. Administrator musi ją odłączyć i zastąpić polityką inline ograniczoną do środowiska deweloperskiego.
Ten krok jest najważniejszym ręcznym mechanizmem kontroli na ścieżce deweloperskiej. Wygenerowanie klucza jest proste, ale wymuszenie zamierzonej granicy przestrzeni roboczej wymaga osobnej zmiany w IAM.
AWS zaleca późniejsze przetestowanie tej granicy. Deweloper powinien pomyślnie wywołać przestrzeń roboczą środowiska deweloperskiego, a następnie spróbować wykonać żądanie do produkcji i potwierdzić, że IAM je odrzuca.
Ten test negatywny ma większe znaczenie niż udane żądanie. Odpowiedź ze środowiska deweloperskiego potwierdza łączność, ale tylko odrzucone wywołanie produkcyjne weryfikuje deklarowaną izolację.
Klucz API pozostaje mechanizmem samouwierzytelniającym. Działa z AWS, innej chmury lub laptopa, ponieważ samo posiadanie klucza stanowi poświadczenie.
Zespoły powinny zatem przechowywać go w zatwierdzonym menedżerze sekretów i ustawić datę wygaśnięcia. Potrzebują też procedur unieważniania na wypadek utraty urządzeń, zmian ról i przypadkowego ujawnienia w repozytorium.
Ścieżka dla zewnętrznych obciążeń eliminuje ten trwały sekret. OIDC pozwala zgodnemu dostawcy tożsamości wystawić JSON Web Token identyfikujący obciążenie.
AWS Security Token Service weryfikuje token i sprawdza warunki zaufania roli. Następnie zwraca tymczasowe poświadczenia AWS za pośrednictwem AssumeRoleWithWebIdentity.
Wytyczne dotyczące OIDC zalecają ten wzorzec dla aplikacji poza AWS, ponieważ pozwala on uniknąć osadzonych, długoterminowych poświadczeń.
Zewnętrzne obciążenie wykorzystuje tymczasowe poświadczenia AWS do uzyskania krótkotrwałego tokenu bearer Claude. Po wygenerowaniu ten token bearer może wywoływać Claude bez przechowywania poświadczeń AWS.
Jest to przydatne dla zewnętrznych kontenerów i zadań CI/CD, ale odnawianie tokenów staje się częścią aplikacji. Usługa działająca nieprzerwanie musi odświeżyć token przed jego wygaśnięciem.
Polityka zaufania OIDC również wymaga szczególnej uwagi. Przykład AWS sprawdza deklaracje odbiorcy i podmiotu tokenu względem oczekiwanych wartości.
Odbiorca identyfikuje zamierzonego adresata tokenu. Podmiot odróżnia dozwolone obciążenie, konto usługi, repozytorium lub tożsamość potoku.
Luźne filtry deklaracji mogą dopuścić więcej zewnętrznych tożsamości, niż zamierzono. Prawidłowy mechanizm federacji z nieprecyzyjnym warunkiem zaufania nadal prowadzi do nadmiernego dostępu.
Te ścieżki są zatem uzupełniające, a nie wymienne.
Międzykontowe SigV4 pasuje do obciążeń produkcyjnych już zarządzanych przez tożsamości AWS.
Klucze API ograniczone do przestrzeni roboczej zmniejszają tarcie w lokalnym środowisku deweloperskim.
Federacja OIDC pasuje do zewnętrznej automatyzacji, która może przedstawić weryfikowalną tożsamość obciążenia.
Wspólnym elementem jest przestrzeń robocza. Każda ścieżka poświadczeń powinna ostatecznie przekładać się na uprawnienia do przestrzeni roboczej odpowiedniej dla danego środowiska.
Centralizacja nie eliminuje ryzyka związanego z poświadczeniami
Projekt poprawia izolację tylko wtedy, gdy każda rola, klucz, warunek zaufania, punkt końcowy i ustawienie rejestrowania odpowiadają zamierzonej przestrzeni roboczej.
Najbardziej oczywiste ryzyko dotyczy ścieżki deweloperskiej. Własne instrukcje AWS wskazują, że wygenerowany klucz API początkowo otrzymuje zarządzaną politykę z dostępem do każdej przestrzeni roboczej.
Administrator musi zidentyfikować nowo utworzonego użytkownika IAM będącego zapleczem klucza, usunąć tę politykę i dołączyć węższą politykę inline.
Ten przepływ pracy jest podatny na błąd ludzki. Administrator może ograniczyć niewłaściwego użytkownika, pozostawić zarządzaną politykę lub wskazać nieprawidłowy ARN przestrzeni roboczej.
W rezultacie klucz nadal będzie działał. Pomyślne żądanie deweloperskie nie ujawni, że zachował również dostęp do produkcji.
Obowiązkowy test odrzucenia może wykryć ten błąd. Organizacje powinny uczynić test dostępu produkcyjnego częścią procesu wydawania klucza, a nie opcjonalną walidacją wykonywaną później.
Klucze długoterminowe zapewniają też słabsze przypisanie działań niż dostęp oparty na rolach. Kilku deweloperów współdzielących jeden klucz może występować w zapisach audytowych jako ten sam podmiot.
Indywidualne klucze poprawiają możliwość przypisania działań, ale zwiększają liczbę poświadczeń wymagających bezpiecznego przechowywania, dat wygaśnięcia, unieważniania i śledzenia właścicieli.
Ścieżka międzykontowa ma inne tryby awarii. Polityka zaufania może być zbyt szeroka albo uprawnienie do przejęcia roli po stronie obciążenia może prowadzić do niewłaściwej roli docelowej.
Warunek aws:PrincipalOrgID pomaga ograniczyć zakres organizacyjny. Nie zastępuje jednak dokładnego ARN podmiotu ani starannego nazewnictwa ról.
Uprawnienia również wymagają przeglądu na poziomie działań. Przyznanie dostępu z użyciem symboli wieloznacznych w całej przestrzeni nazw aws-external-anthropic podważyłoby strukturę najmniejszych uprawnień opisaną w przewodniku.
AWS publikuje szczegółowe przykłady polityk IAM dotyczące wnioskowania w pojedynczej przestrzeni roboczej i innych mechanizmów kontroli. Zespoły powinny zweryfikować wdrożone polityki pod kątem funkcji API, z których faktycznie korzystają.
Ścieżka OIDC przenosi ciężar bezpieczeństwa na deklaracje zewnętrznej tożsamości. Jej bezpieczeństwo zależy od współdziałania wystawcy, odbiorcy, filtra podmiotu, polityki roli i mechanizmu odnawiania tokenów.
Wzorzec podmiotu obejmujący całą grupę repozytoriów może autoryzować niepowiązane potoki. Szeroki wzorzec konta usługi może dopuścić obciążenia spoza zamierzonej przestrzeni nazw.
Tymczasowe poświadczenia ograniczają czas ekspozycji, ale nie korygują nadmiernych uprawnień w tym okresie. Krótkotrwały dostęp jest bezpieczniejszy niż trwały, lecz nie staje się automatycznie dostępem o najmniejszych uprawnieniach.
Wygenerowany token Claude również staje się niezależnym poświadczeniem bearer. Do czasu wygaśnięcia samo jego posiadanie wystarcza do użycia go w granicach odziedziczonej autoryzacji.
Aplikacje powinny unikać drukowania go w logach, danych wyjściowych kompilacji, śladach wyjątków lub metadanych monitoringu. Tam, gdzie to praktyczne, czas życia tokenu powinien odpowiadać czasowi trwania zadania.
Zachowanie regionalne dodaje kolejne ograniczenie operacyjne. Przestrzenie robocze są tworzone w regionie AWS, a żądania API muszą być kierowane do odpowiedniego regionalnego punktu końcowego.
AWS odróżnia to powiązanie z punktem końcowym od geograficznego miejsca wykonywania wnioskowania. Ustawienia bezpieczeństwa przestrzeni roboczej niezależnie określają, czy wnioskowanie korzysta z trasowania w USA czy globalnego.
Klucze krótkoterminowe działają wyłącznie z tym samym regionalnym punktem końcowym, w którym zostały wygenerowane. Według przewodnika AWS długoterminowe klucze API nie są blokowane regionalnie.
Ta różnica może prowadzić do mylących awarii podczas wdrażania. Proces odnawiania tokenu może działać w jednym regionie, podczas gdy aplikacja wskazuje inny punkt końcowy.
Architektura ma również szerszą granicę, którą kupujący muszą zrozumieć. AWS podaje, że Claude Platform on AWS jest obsługiwana przez Anthropic, a żądania i dane są przetwarzane poza granicą bezpieczeństwa AWS.
To odróżnia usługę od założenia, że całe przetwarzanie pozostaje w obrębie perymetru usługi kontrolowanego przez AWS. Organizacje z rygorystycznymi wymaganiami dotyczącymi rezydencji danych potrzebują odrębnego przeglądu.
AWS przedstawia Claude Platform on AWS jako rozwiązanie uzupełniające wobec modeli Claude dostępnych za pośrednictwem Amazon Bedrock. Wybór nie sprowadza się więc wyłącznie do jednej metody uwierzytelniania zamiast drugiej.
Obejmuje on funkcje platformy, odpowiedzialność operacyjną, granice przetwarzania i wymagania regionalne. Dostęp dla wielu środowisk nie rozstrzyga tych kwestii dla każdego obciążenia.
Centralizacja może również zwiększyć zasięg skutków błędów administracyjnych. Konto AI Services przechowuje subskrypcję, przestrzenie robocze, klucze API i role dostępu.
Zmiana na tym koncie może jednocześnie wpłynąć na kilka kont aplikacyjnych. Projekt powinien zatem stosować wobec tego konta silniejsze mechanizmy kontroli zmian niż wobec zwykłego środowiska deweloperskiego.
Zespoły powinny tam, gdzie to możliwe, rozdzielać tworzenie polityk od ich zatwierdzania. Infrastruktura jako kod może również ograniczyć niespójne definicje ról między dodatkowymi zespołami i przestrzeniami roboczymi.
AWS podaje, że organizacje z większą liczbą środowisk mogą utworzyć przestrzeń roboczą dla każdego zespołu lub obciążenia i powtórzyć wzorzec ról międzykontowych.
Takie podejście skaluje model izolacji, ale mnoży także polityki, relacje ról, logi, tagi i konfiguracje punktów końcowych. Czynnikiem ograniczającym staje się dyscyplina operacyjna.
Centralną obietnicę należy więc formułować ostrożnie. Wzorzec zapewnia komponenty do izolacji przestrzeni roboczej, lecz to wdrożone polityki i obsługa poświadczeń decydują, czy izolacja zostanie zachowana.
Co przedsiębiorstwa powinny zweryfikować w następnej kolejności
Kolejny test dotyczy tego, czy organizacje potrafią konsekwentnie obsługiwać ten model dostępu, a nie tego, czy trzy przepływy uwierzytelniania działają w demonstracji.
Pierwszym sygnałem jest zautomatyzowana walidacja polityk. Zespoły powinny potwierdzić, że każda rola produkcyjna wskazuje jeden oczekiwany ARN przestrzeni roboczej i wyłącznie wymagane działania API.
Wydawanie kluczy deweloperskich powinno obejmować zastąpienie polityki, datę wygaśnięcia, przechowywanie sekretu i wymuszony test odrzucenia dostępu produkcyjnego. Proces zależny od pamięci z czasem nieuchronnie zacznie odbiegać od założeń.
Jeśli organizacje zautomatyzują te kontrole za pośrednictwem potoków wdrożeniowych, scentralizowany model AWS stanie się bardziej wiarygodny na dużą skalę. Powtarzające się ręczne wyjątki osłabiłyby ten wniosek.
Drugim sygnałem jest zakres audytu. Same zdarzenia zarządzania CloudTrail nie zapewniają widoczności poszczególnych wywołań wnioskowania.
Organizacje powinny włączyć zdarzenia danych dla odpowiedniego typu zasobu przestrzeni roboczej Claude, a następnie zweryfikować, czy zapisy zawierają użyteczne przypisanie podmiotu.
Powinny również sprawdzić, czy osoby reagujące na incydenty mogą powiązać żądanie z rolą EKS, kluczem deweloperskim lub zewnętrzną tożsamością OIDC.
Jeśli ścieżka audytu zachowuje te rozróżnienia, architektura trzech tras wspiera rozliczalny dostęp. Jeśli logi spłaszczają wywołujących do wspólnych tożsamości, centralizacja ma mniejszą wartość dochodzeniową.
Trzecim sygnałem jest wdrożenie poza aplikacjami natywnymi dla AWS. Ścieżka OIDC została zaprojektowana dla zewnętrznych chmur, wdrożeń Kubernetes i systemów CI/CD.
Jej rzeczywistym testem będzie niezawodna rotacja tokenów podczas długotrwałych zadań. Zespoły muszą także utrzymywać wąskie deklaracje podmiotu i odbiorcy w miarę zmian repozytoriów oraz kont usług.
Częste błędy uwierzytelniania skłoniłyby deweloperów do powrotu do długoterminowych sekretów. Stabilne odnawianie przy precyzyjnych warunkach zaufania wzmocniłoby podejście federacyjne.
Przedsiębiorstwa powinny też monitorować rozrastanie się liczby przestrzeni roboczych. Tworzenie jednej przestrzeni roboczej dla każdego zespołu lub obciążenia może poprawić izolację, odpowiedzialność i alokację kosztów.
Zbyt wiele przestrzeni roboczych bez spójnych etykiet i zasad cyklu życia może stworzyć inną formę rozproszenia. Stare klucze, porzucone role i nieużywane przestrzenie robocze potrzebują procesu wycofywania.
Dedykowane konto AI Services powinno stać się zarządzaną granicą usługi. Jego administratorzy potrzebują rejestrów odpowiedzialności za każdą przestrzeń roboczą, rolę i poświadczenie.
Zespoły platformowe mogą dokumentować decyzje dotyczące dostępu wraz z architekturą aplikacji i procedurami reagowania na incydenty. Przeszukiwalna baza wiedzy inżynierskiej może pomóc zachować te powiązania mimo zmian w zespołach.
Najbardziej użyteczna ocena zaczyna się od jednej kompletnej ścieżki aplikacji. Połącz obciążenie produkcyjne przez SigV4, klienta deweloperskiego przez ograniczony klucz, a potok przez OIDC.
Następnie zweryfikuj odrzucone żądania między przestrzeniami roboczymi, odnawianie tokenów, zdarzenia danych CloudTrail i awaryjne unieważnianie. Czy te mechanizmy kontroli nadal działają po rutynowych zmianach polityk?
Ta odpowiedź ma większe znaczenie niż pierwsze udane żądanie. Dostęp do Claude Platform on AWS obsługuje obecnie trzy środowiska w ramach jednej subskrypcji, ale jego wartość dla bezpieczeństwa zależy od powtarzalnych dowodów izolacji.
