Zarządzanie kluczami API nie jest już małym zadaniem na pulpicie nawigacyjnym. W przypadku zespołów korzystających z interfejsów API AI jest to część modelu bezpieczeństwa, kosztów i operacji każdej aplikacji, która wysyła monity, odbiera dane wyjściowe modelu, wywołuje narzędzia lub wydaje pieniądze na mierzone wnioskowanie.

Wiele zespołów zaczyna od jednego klucza dostawcy w pliku środowiska lokalnego. Działa to, dopóki ten sam klucz nie pojawi się w zmiennych CI, notatnikach, rozszerzeniach IDE, agentach, zadaniach wsadowych, integracjach klientów i skryptach wsparcia. W tym momencie wyciek klucza nie jest jedynie problemem z uwierzytelnieniem. Może wyświetlać monity i odpowiedzi, powodować nieoczekiwane opłaty, wywoływać modele premium, uruchamiać narzędzia z uprawnieniami aplikacji lub uzależniać reakcję na incydenty od domysłów.

W tym przewodniku zarządzanie kluczami API jest traktowane jako cykl życia: w jaki sposób klucze są projektowane, wydawane, przechowywane, ustalane zakres, monitorowane, rotowane i unieważniane. Koncentruje się na dostępie do interfejsu API AI, gdzie do typowych problemów związanych z bezpieczeństwem interfejsu API dołączają dostęp do modelu, wydatki oparte na tokenach, dane uwierzytelniające wielu dostawców, przypisywanie klientów i klienci kompatybilni z OpenAI.

Gdzie klucze API pasują do bezpieczeństwa interfejsu API

Klucz API zwykle potwierdza posiadanie danych uwierzytelniających. Odpowiada na pytanie: „czy ten rozmówca ma ważny sekret?” Samo w sobie nie odpowiada na wszystkie istotne pytania dotyczące autoryzacji.

Zaplecze nadal musi zdecydować, czy osoba wywołująca może uzyskać dostęp do konkretnego dzierżawcy, obiektu, modelu, punktu końcowego, narzędzia, obszaru roboczego, raportu lub funkcji administracyjnej. Bezpieczeństwo interfejsu API OWASP 10 najważniejszych zagrożeń, takich jak uszkodzona autoryzacja na poziomie obiektu, zepsute uwierzytelnianie, nieograniczone zużycie zasobów i uszkodzona autoryzacja na poziomie funkcji przypomina, że ​​prawidłowe dane uwierzytelniające to tylko jedna warstwa systemu.

W przypadku interfejsów API AI to rozróżnienie ma znaczenie, ponieważ ten sam klucz może być w stanie wykonywać działania o bardzo różnych profilach ryzyka. Klucz, który może wywoływać niedrogi model tekstowy dla jednego wewnętrznego przepływu pracy, nie powinien automatycznie móc wywoływać modeli premium, tworzyć zadań wsadowych, uzyskiwać dostępu do danych innego dzierżawcy, wywoływać narzędzi wysyłających e-maile ani zarządzać ustawieniami rozliczeń.

Trwały model zabezpieczeń interfejsu API oddziela trzy kwestie:

  • Uwierzytelnianie: udowodnienie, że żądanie ma ważne dane uwierzytelniające, token lub sesję.
  • Autoryzacja: decyzja o tym, co co uwierzytelniony rozmówca może zrobić w bieżącym najemcy, środowisku i kontekście biznesowym.
  • Zarządzanie: ograniczanie wydatków, stawek, dostępu do modeli, ekspozycji danych i kontroli administracyjnej, tak aby jeden błąd miał ograniczony promień wybuchu.

Klucze API są przydatne, ale nie powinny być jedyną kontrolą chroniącą wrażliwe lub cenne zasoby. Używaj ich z protokołem HTTPS, sprawdzaniem autoryzacji po stronie serwera, dziennikami audytu, najniższymi uprawnieniami, limitami szybkości, limitami wydatków i bezpieczną obsługą sekretów.

Zacznij od aktywnego spisu kluczy API

Nie możesz zarządzać kluczami, których nie możesz nazwać. Pierwszym praktycznym krokiem jest bieżąca inwentaryzacja każdego klucza API i obiektu podobnego do poświadczeń używanych przez Twoje systemy AI.

Każdy rekord klucza powinien zawierać co najmniej identyfikator klucza, nieodwracalny skrót lub odcisk palca, właściciela, twórcę, zespół lub dzierżawcę, środowisko, obciążenie pracą, zakresy, dozwolone modele, dozwolone punkty końcowe, politykę wydatków, politykę stawek, ograniczenia IP, w stosownych przypadkach, status, czas utworzenia, wygaśnięcie, ostatnio używany znacznik czasu, grupę rotacji i audyt metadane.

Inwentarz powinien obejmować więcej niż klucze środowiska wykonawczego. Uwzględnij osobiste klucze programisty, klucze konta usługi, klucze CI/CD, klucze obszaru roboczego, klucze klienta lub dzierżawy, klucze zarządzane przez sprzedawcę, klucze rozliczeniowe/raportowania, poświadczenia administracyjne API i poświadczenia dostawcy wyższego szczebla.

Najważniejsze pola to własność, cel, zakres, ostatnie użycie i zasady limitów. Bez nich każde przyszłe zadanie związane z bezpieczeństwem stanie się wolniejsze: wycofywanie, rotacja, reagowanie na wycieki, badanie kosztów i obsługa klienta.

Celowo projektuj granice kluczy

Największym błędem w zarządzaniu kluczami API jest używanie jednego klucza ponad zbyt wieloma granicami. Wspólny klucz produkcyjny jest na początku wygodny, ale niszczy przypisanie i powoduje, że unieważnianie jest uciążliwe. W przypadku wycieku może być konieczne zatrzymanie ruchu dla każdej usługi, mimo że nadal nie będzie można określić, które obciążenie spowodowało problem.

Dobre kluczowe granice dostosowują się do kształtu firmy i oprogramowania. Oddziel produkcję od programowania, ludzi od usług, klientów od zespołów wewnętrznych, dzierżawców od siebie nawzajem, poświadczenia środowiska wykonawczego od poświadczeń administracyjnych i klucze klientów wydane przez bramę od kluczy dostawców wyższego szczebla.

Granice środowiska

Programowanie, przemieszczanie i produkcja powinny używać oddzielnych kluczy. Klucz programistyczny nie powinien sięgać danych produkcyjnych ani budżetów produkcyjnych.Klucz przemieszczania nie powinien mieć dostępu do bieżących obciążeń klientów, chyba że istnieje ściśle kontrolowany powód.

Granice obciążenia

Każda usługa, zadanie wsadowe, flota agentów, integracja lub zaplanowane zadanie powinny mieć własny klucz lub konto usługi. Pozwala to odpowiedzieć na podstawowe pytania: jakie obciążenie wydało pieniądze, która usługa przestała być uwierzytelniana, która integracja korzystała z przestarzałego modelu i który klucz powinien zostać zamrożony podczas incydentu.

Granice dzierżawy i klienta

Systemy z wieloma dzierżawcami wymagają przypisania i izolacji. Jeśli do przesyłania monitów używany jest klucz interfejsu API skierowany do klienta, żądanie powinno być powiązane z klientem, dzierżawcą, aplikacją, a najlepiej z pseudonimowym użytkownikiem końcowym lub aktorem. Naruszony klucz jednego dzierżawcy nie powinien umożliwiać dostępu do danych, profilu modelu, budżetu ani dzienników innego dzierżawcy.

Granice poświadczeń dostawcy

Klucze dostawcy wyższego szczebla różnią się od kluczy wydawanych klientom lub aplikacjom wewnętrznym. Dane uwierzytelniające dostawcy powinny pozostać po stronie serwera, przechowywane w skarbcu lub menedżerze tajnych informacji i nigdy nie być wysyłane do przeglądarek, aplikacji mobilnych, klientów stacjonarnych, publicznych notatników ani środowisk kontrolowanych przez klienta.

Bramka może w tym pomóc, udostępniając jeden kluczowy obszar skierowany do klienta, jednocześnie zachowując poświadczenia dostawcy nadrzędnego za bramą. Umożliwia to scentralizowaną analizę użytkowania, odwoływanie licencji, kontrolę zespołową i egzekwowanie zasad u dostawców. Jeśli standaryzujesz klientów w oparciu o interfejs API zgodny z OpenAI, granica bramy staje się szczególnie ważna, ponieważ wiele narzędzi oczekuje jednego podstawowego adresu URL i tokena nośnika.

Zastosuj najmniejsze uprawnienia do modeli, punktów końcowych, narzędzi i wydatków

Najmniejsze uprawnienia oznaczają, że klucz powinien mieć tylko dostęp wymagany dla jego obciążenia. W przypadku systemów AI zakres to nie tylko lista punktów końcowych API. Obejmuje także modele, narzędzia, budżety tokenów, limity stawek, dzierżawców, klasy danych i funkcje administracyjne.

Praktyczne zasady dotyczące kluczy interfejsu API AI mogą obejmować:

  • Dozwolone rodziny modeli lub określone identyfikatory modeli.
  • Dozwolone punkty końcowe, takie jak kończenie czatów, osadzanie, zadania wsadowe lub generowanie obrazów.
  • Niedozwolone administracyjne interfejsy API, interfejsy API do zarządzania kluczami, interfejsy API rozliczeń i interfejsy API do zarządzania obszarem roboczym dla kluczy wykonawczych.
  • Limity szybkości na klucz dla żądań na minutę i tokenów na minutę.
  • Limity wydatków na dzierżawcę, na zespół lub na klienta.
  • Kontrola modelu premium, dzięki czemu przepływ pracy o niskim ryzyku nie może nagle skorzystać z najdroższego modelu.
  • Uprawnienia do narzędzi, takie jak to, czy klucz może wywoływać zewnętrzne łączniki, wykonywać kod, systemy wyszukiwania lub biznes działania.
  • Listy dozwolonych adresów IP dla stabilnych obciążeń po stronie serwera, gdzie ścieżka sieciowa jest przewidywalna.

Kontrola wydatków jest częścią zabezpieczeń API w przypadku mierzonych interfejsów API AI. Wyciek klucza może spowodować bezpośrednie szkody finansowe, nawet jeśli nigdy nie uzyska dostępu do wrażliwych danych. Limity stawek pomagają, ale nie wystarczą. Liczba tokenów, ponowne próby, zadania wsadowe, wywołania narzędzi i wybór modelu – wszystko to wpływa na koszt. Bezpieczna implementacja powinna łączyć kontrolę stawek z pułapami wydatków, listami dozwolonych modeli, wykrywaniem anomalii i kontrolą awaryjnego zamrażania.

Zespoły porównujące koszty modeli i zasady dostępu powinny zapewniać zgodność bezpieczeństwa i finansów. Wycena modelu to nie tylko kwestia zamówienia; określa, ile może wydać skompromitowany lub źle skonfigurowany klucz. Trzymaj zatwierdzone profile modeli powiązane z budżetami i przeglądaj je, gdy zmienia się zestaw modeli, szczególnie w przypadku korzystania z cen modelu AI do kierowania obciążeń według kosztów i możliwości.

Przechowuj wpisy tajne tam, gdzie ich miejsce

Klucze API należą do menedżerów tajnych obiektów, konfiguracji po stronie serwera, kontrolowanych zmiennych CI/CD lub bramy opartej na skarbcu. Nie należą one do kodu źródłowego, JavaScript przeglądarki, pakietów mobilnych, pakietów aplikacji komputerowych, publicznych notatników, zrzutów ekranu, wiadomości na czacie, ładunków analitycznych, zgłoszeń pomocy technicznej ani dzienników.

Narażenie po stronie klienta to częsty tryb awarii. Jeśli klucz dostawcy jest osadzony w przeglądarce lub aplikacji mobilnej, każdy, kto może sprawdzić aplikację, może go wyodrębnić i wysyłać żądania w imieniu posiadacza konta. W przypadku przeglądarek, aplikacji mobilnych, flot IDE i agentów działających w niekontrolowanych środowiskach należy używać proxy po stronie serwera lub krótkotrwałych delegowanych poświadczeń o wąskim zakresie. Nie rozpowszechniaj długoterminowych danych uwierzytelniających dostawców wśród klientów, nad którymi nie masz kontroli.

CI/CD wymagają tej samej dyscypliny. Przechowuj klucze jako chronione zmienne. Ogranicz, kto może je czytać i zmieniać. Unikaj drukowania zmiennych środowiskowych w dziennikach kompilacji. Redaguj nagłówki autoryzacji w zrzutach żądań zakończonych niepowodzeniem. Traktuj wdrożenia podglądu i rozwidlone żądania ściągnięcia jako różne strefy zaufania od chronionych potoków produkcyjnych.

Na szczególną uwagę zasługują dzienniki i systemy obserwowalności.Przechowuj kluczowe odciski palców, identyfikatory żądań, identyfikatory dzierżawców, identyfikatory modeli, status odpowiedzi, liczniki tokenów, liczniki kosztów, metadane adresu IP lub klienta, w stosownych przypadkach, oraz decyzje dotyczące zasad. Nie przechowuj pełnych kluczy API. Redaguj wpisy tajne w śladach, dziennikach zwrotnego proxy, raportach wyjątków, ładunkach webhooka, narzędziach pomocy technicznej, zdarzeniach analitycznych i kolejkach utraconych wiadomości.

Twórz rotację przed wystąpieniem sytuacji awaryjnej

Rotacja nie polega po prostu na usunięciu jednego klucza i utworzeniu kolejnego. Jeśli wdrożone usługi nadal zależą od starego klucza, usunięcie powoduje przestoje. Niezawodny proces rotacji wykorzystuje nakładanie się, obserwację i wyraźny punkt wycofania.

Powszechnym wzorcem jest grupa rotacji z dwoma aktywnymi miejscami. Utwórz klucz zastępczy, wdróż go w każdym zależnym systemie, obserwuj ostatnie użycie starego klucza, zamroź stary klucz, gdy ruch się przeniesie, i usuń go po upływie okna zaufania. Należy jasno określić zasady wycofywania danych: kiedy można ponownie włączyć stary klucz, kto może to zatwierdzić i jak długo może on pozostać dostępny?

Krótki okres życia klucza zmniejsza ryzyko przestarzałych poświadczeń, ale zwiększa obciążenie operacyjne. Długotrwałe klucze zmniejszają ryzyko rezygnacji z wdrożenia, ale tworzą większe okno na zapomniane dane uwierzytelniające i luki w odejściu pracowników. Właściwa polityka zależy od obciążenia pracą. Konto usług produkcyjnych o wysokiej wartości może zmieniać się według stałego harmonogramu z automatyzacją. Tymczasowy klucz programisty powinien szybko wygasnąć. Integracja zarządzana przez klienta może wymagać dłuższego okna migracji i jasnego komunikatu o wycofaniu.

Nie obracaj każdego klucza w ten sam sposób. Poświadczenia administracyjne, które mogą wyświetlać, tworzyć, usuwać lub modyfikować klucze, wiążą się z wyższym ryzykiem niż klucze wnioskowania w czasie wykonywania i powinny zapewniać silniejszą kontrolę, węższy dostęp i bardziej agresywne monitorowanie. Klucze wykonawcze nie powinny mieć uprawnień administracyjnych, chyba że istnieje konkretny, sprawdzony powód.

Wykrywanie wycieków i nieprawidłowego użycia

Wykrywanie wycieków działa najlepiej, gdy kilka systemów wzmacnia się nawzajem. Skanowanie tajne w ramach kontroli źródła może przechwycić klucze zapisane w repozytoriach. Kontrole CI mogą zablokować oczywiste wycieki przed połączeniem. Wzorce niestandardowe mogą wykrywać formaty kluczy wewnętrznych. Pulpity dostawców mogą ujawniać nietypową aktywność. Telemetria bramy może pokazywać nowe adresy IP, nowe lokalizacje geograficzne, nieudane serie uwierzytelniania, nagłą prędkość wydatków lub wywołania nieoczekiwanych modeli.

Przydatne pulpity nawigacyjne zabezpieczeń obejmują klucze uśpione, klucze bez właścicieli, klucze bez limitów, klucze zbliżające się do wygaśnięcia, klucze używane z nowych sieci, klucze z szybkim wzrostem tokenów, zablokowane klucze nadal odbierające ruch, nieudane serie uwierzytelniania oraz klucze klientów, których wydatki zbliżają się do górnego pułapu.

Wykrywanie powinno obejmować również dzienniki i systemy asynchroniczne. Elementy webhook, zadania w tle, kolejki i opóźnione zakończenia wymagają identyfikatorów żądań i oryginalnego przypisania klucza. W przeciwnym razie podejrzane wywołanie zwrotne lub wynik wsadowy może nie być możliwy do powiązania z kluczem i dzierżawcą, który go utworzył.

Kiedy sekret pojawi się w historii Git, usunięcie go z repozytorium nie wystarczy. Każdy, kto uzyskał dostęp do repozytorium, dzienników kompilacji, kopii lustrzanych, forków, artefaktów pakietów lub stron w pamięci podręcznej, mógł już skopiować klucz. Poświadczenia muszą zostać unieważnione lub zamrożone, a następnie wymienione.

Odpowiadanie na złamany klucz API

Dobry plan reagowania na incydenty jest krótki, przećwiczony i konkretny. Pierwszą decyzją jest zazwyczaj zamrożenie lub uchylenie. Zamrożenie szybko zatrzymuje ruch, zachowując zapis do celów dochodzenia. Unieważnienie trwale wyłącza klucz. Niektóre zespoły najpierw stosują funkcję zamrażania, gdy potrzebują ciągłości audytu i opcji natychmiastowego wycofywania zmian; inne unieważniają automatycznie w przypadku potwierdzonych wycieków publicznych. Obydwa podejścia wymagają automatyzacji i jasnych uprawnień.

Praktyczny przepływ reakcji wygląda następująco:

  1. Zablokuj lub unieważnij podejrzany klucz na podstawie ważności i pewności.
  2. Zidentyfikuj właściciela, dzierżawcę, obciążenie, zakresy, dostęp do modelu, zasady wydatków i harmonogram ostatnio używanego.
  3. Sprawdź użycie pod kątem nietypowych monitów, modeli, punktów końcowych, narzędzi, adresów IP, liczby tokenów i kosztów.
  4. Oceń dane, których to dotyczy, dzierżawcy, dalsze działania i wpływ na rozliczenia.
  5. Wydaj klucz zastępczy z poprawionym zakresem i limitami.
  6. Usuń główną przyczynę, taką jak zatwierdzony klucz tajny, ujawniony dziennik, zakrojona zmienna CI lub pakiet po stronie klienta.
  7. Dodaj kontrolę zapobiegawczą, taką jak skanowanie tajnych danych, redakcja dzienników, węższe zakresy, krótsze wygaśnięcie lub alerty dotyczące wydatków.
  8. Udokumentuj incydent i zaktualizuj elementy Runbook.

Krok wymiany nie powinien powodować ponownego tworzenia tego samego ryzyka. Jeśli klucz wyciekł, ponieważ był współdzielony w dziesięciu usługach, zastąp go oddzielnymi kluczami do konta usługi. Jeśli wyciekł przez logi, napraw logowanie przed wydaniem nowego klucza. Jeśli przesadził, ponieważ mógł wywołać każdy model, dodaj listy dozwolonych modeli i limity wydatków.

Klucze zarządzane przez bramę i dostęp do AI wielu dostawców

Zespoły AI często korzystają z kilku dostawców modeli.Każdy dostawca ma swój własny model kluczy, strukturę obszaru roboczego, limity stawek, nazwy modeli, ceny i administracyjne interfejsy API. Zarządzanie każdym kluczem dostawcy bezpośrednio w każdej aplikacji zwielokrotnia ryzyko operacyjne.

Model klucza zarządzany przez bramę może zmniejszyć tę złożoność. Aplikacje wywołują bramę za pomocą klucza skierowanego do klienta lub klucza wewnętrznego. Brama uwierzytelnia osobę wywołującą, stosuje zasady dzierżawy, wymusza kontrolę modelu i wydatków, rejestruje użycie i korzysta z poświadczeń dostawcy nadrzędnego po stronie serwera. Jest to przydatne w przypadku aplikacji obsługujących wiele modeli, platform wewnętrznych, agencji i usług sprzedawców.

W przypadku Model Gate rola bramy jest istotna w tym miejscu: scentralizowane klucze skierowane do klienta, ujednolicona analityka użytkowania, kontrola zespołu, limity wydatków, bezpieczeństwo IP, integracje operacyjne Telegramu, automatyzacja API partnerów i reagowanie na nadużycia. W przypadku firm świadczących usługi dla klientów lub usług podrzędnych automatyzacja interfejsu API partnerów może zapewnić spójność procesów tworzenia kluczy, ograniczania aktualizacji, zamrażania i sprzedawców zamiast ręcznego.

Brama nie zdejmuje całej odpowiedzialności z zespołu aplikacji. Nadal potrzebujesz bezpiecznego magazynu, autoryzacji zaplecza, izolacji dzierżawców, projektu punktu końcowego, higieny CI/CD, zasad dotyczących szybkich odpowiedzi i danych oraz ograniczeń po stronie dostawcy, jeśli są dostępne. Brama staje się płaszczyzną kontroli o dużej wartości, dlatego wymaga silnego przechowywania danych, dzienników audytu, kontroli dostępu, planowania dostępności i separacji administracyjnej.

Typowe błędy w zarządzaniu kluczami API

Najczęstsze błędy są przewidywalne. Zespoły umieszczają klucze dostawców bezpośrednio w aplikacjach klienckich. Używają jednego klucza produkcyjnego dla każdej usługi i klienta. Są one rotacyjne, usuwając je najpierw i wdrażając później. Tworzą klucze bez właścicieli, limitów, zakresów i wygaśnięcia. Rejestrują pełne nagłówki autoryzacji. W celu kontroli kosztów sztucznej inteligencji opierają się wyłącznie na limitach stawek. Dają poświadczenia administratora usług wykonawczych. Usuwają wyciekły klucz z Git bez unieważniania go. Wysyłają pracowników do pracy, ale pozostawiają aktywne klucze osobiste, pliki środowiska lokalnego i zmienne CI.

Kolejnym subtelnym błędem jest traktowanie rejestrowania monitów i odpowiedzi jako czysto operacyjne. Szczegółowe dzienniki mogą pomóc w badaniu nadużyć, ale mogą również zawierać dane osobowe, treści klientów, tajemnice lub informacje regulowane. Rejestrowanie w pierwszej kolejności metadanych jest często bezpieczniejsze: domyślnie rejestruje odciski palców kluczy, identyfikatory modeli, liczbę tokenów, koszty, kody stanu, decyzje dotyczące zasad i identyfikatory żądań, a następnie wymaga kontrolowanego dostępu w celu głębszego debugowania.

Lista kontrolna implementacji

Silny program do zarządzania kluczami API można rozpocząć od szczegółowej listy kontrolnej:

  • Utwórz spis wszystkich kluczy, właścicieli, środowisk, dzierżawców, zakresów, limitów i ostatniego użycia sygnatury czasowe.
  • Oddziel klucze według środowiska, obciążenia, dzierżawy, klienta i klasy poświadczeń.
  • Przenieś poświadczenia dostawcy na serwer i poza przeglądarki, aplikacje mobilne, notatniki i klientów publicznych.
  • Używaj najmniejszych uprawnień dla modeli, punktów końcowych, narzędzi, dzierżawców, budżetów i funkcji administracyjnych.
  • Dodaj limity wydatków, limity stawek, listy dozwolonych modeli, alerty o anomaliach i blokowanie awaryjne kontrole.
  • Przechowuj klucze tajne w menedżerze tajnych kluczy, skarbcu, chronionym magazynie zmiennych CI lub systemie danych uwierzytelniających zarządzanym przez bramę.
  • Edytuj sekrety z dzienników, śladów, analiz, narzędzi wsparcia, webhooków i raportów o błędach.
  • Wdrażaj rotację za pomocą nakładających się kluczy, monitorowanie ostatniego użycia, zamrażanie i ostateczne usuwanie.
  • Zintegruj skanowanie tajnych informacji w repozytoriach i CI/CD, w tym niestandardowe wzorce kluczy.
  • Udokumentuj zachowanie związane z odłączaniem kluczy osobistych, kont usług, kluczy obszaru roboczego i kluczy klientów.
  • Trzymaj danych uwierzytelniających wnioskowania w czasie wykonywania oddzielnie od danych uwierzytelniających dostawcy administracyjnego.
  • Testuj reakcję na incydenty, zanim prawdziwy wyciek wymusi ten proces.

Wniosek

Zarządzanie kluczami API w przypadku interfejsów API AI polega na kontrolowaniu tożsamości, uprawnień, kosztów i promienia operacyjnego wybuchu. Bezpieczny klucz to nie tylko losowy ciąg znaków. Ma właściciela, cel, zakres, środowisko, budżet, wygaśnięcie, ścieżkę rotacji, ścieżkę audytu i plan reagowania na incydenty.

Praktycznym celem nie jest tworzenie biurokracji wokół każdego żądania. Ma to na celu uczynienie normalnej pracy bezpieczniejszą: programiści mogą budować, uruchamiać usługi, zapewniać obsługę klientom, a zespoły ds. bezpieczeństwa mogą odpowiedzieć na pytanie, co się stanie, gdy klucz wycieknie lub nastąpi gwałtowny wzrost wydatków. Zacznij od zapasów i granic, a następnie dodaj najniższe uprawnienia, bezpieczne przechowywanie, rotację, monitorowanie i automatyzację reakcji. W przypadku dostępu do sztucznej inteligencji wielu dostawców brama może scentralizować większość kontroli, ale autoryzacja aplikacji i higiena tajemnicy nadal pozostają głównymi obowiązkami inżynierów.