Zyski:
- Możliwość oddzielenia uwierzytelniania od autoryzacji i stosowania minimalnej autoryzacji za pomocą RBAC/ABAC
- Możliwość uniknięcia mieszanego ryzyka proxy poprzez uruchomienie modelu w kontekście użytkownika
- Możliwość przechowywania i rotacji kluczy API za pomocą tajnego systemu zarządzania
Znaczna część ataków na system AI nie zaczyna się od „oszukania” modelu, ale od kradzieży klucza API lub nadmiernie autoryzowanego konta. Ta warstwa zabezpieczeń wywodzi się z klasycznego bezpieczeństwa informacji, ale dodaje nowe zagrożenia w kontekście sztucznej inteligencji: model wzywa na przejażdżkę w czyimś imieniu, konto usługi ma dostęp do wszystkich danych, klucz wycieka do GitHub. W tej części dowiemy się, jak zawęzić dostęp do systemu AI poprzez uwierzytelnianie, autoryzację (RBAC/ABAC), minimalną autoryzację i zarządzanie tajemnicą.
Różnica między uwierzytelnianiem a autoryzacją
Te dwa terminy są często mylone:
- Uwierzytelnianie: „Kim jesteś?” — udowodnienie, że użytkownik/usługa jest naprawdę tym, za kogo się podaje (hasło, token, certyfikat, MFA).
- Autoryzacja: „Co możesz zrobić?” — określ, do jakich zasobów/akcji może uzyskać dostęp uwierzytelniona strona.
Kluczowa subtelność systemów AI polega na tym, że kiedy model wykonuje pracę w imieniu użytkownika, czy działa z uprawnieniami tego użytkownika, czy z szerokim kontem usługi? To drugie jest niebezpieczne — bo oszukany przez zastrzyk model uzyskuje pełny dostęp do konta usługi.
Uwaga: Problem „zdezorientowanego zastępcy”: użytkownik o niskich uprawnieniach pośrednio uzyskuje dostęp do danych, do których nie może uzyskać dostępu, poprzez outsourcing modelu o wysokich uprawnieniach. Model powinien zawsze działać w kontekście uprawnień użytkownika, a nie jego własnych, szerokich uprawnień.
RBAC i ABAC
- RBAC (kontrola dostępu oparta na rolach): dostęp zależy od roli użytkownika. Rola „specjalisty wsparcia” może czytać notatki klientów, ale nie może ich usuwać. Proste i powszechne.
- ABAC (kontrola dostępu oparta na atrybutach): Dostęp zależy od atrybutów: działu użytkownika, etykiety prywatności danych, pory dnia, sieci, z której pochodzi żądanie. Bardziej dopracowany, ale bardziej złożony.
Większość organizacji zaczyna od RBAC i przechodzi do ABAC w przypadku wrażliwych danych. Praktyczna zasada dotycząca sztucznej inteligencji: model powinien filtrować każdego agenta, do którego dzwoni, i wszystkie dane, do których uzyskuje dostęp, w oparciu o rolę/atrybuty użytkownika składającego żądanie.
Krok po kroku: korzystanie z minimalnej władzy
- Zrób inwentarz. Jakie narzędzia wywołuje model, do jakich danych ma dostęp? Wypisz je wszystkie.
- Uzasadnij każdy dostęp. „Czy ten asystent naprawdę potrzebuje uprawnień do usuwania?” W przeciwnym razie usuń go.
- Domyślnie tylko do odczytu. Model powinien domyślnie móc czytać; Wymagaj oddzielnego tokena zapisu/usuwania o wąskim zakresie.
- Przenieś kontekst użytkownika. Zadzwoń do pojazdu, korzystając z uprawnień użytkownika, a nie konta serwisowego.
- Poświadczenie krótkotrwałe. Używaj krótkotrwałych, automatycznie odnawiających się tokenów zamiast długowiecznych kluczy.
Zarządzanie tajemnicą
Sekret to dane uwierzytelniające, które muszą pozostać tajne, takie jak klucz API, hasło, token lub certyfikat. Najczęstszym wypadkiem w projektach AI jest osadzenie klucza API dostawcy modelu w kodzie i wyciek do kontroli wersji (Git).
Prawidłowa aplikacja:
- Nigdy nie osadzaj kluczy w kodzie; Użyj zmiennej środowiskowej lub systemu zarządzania sekretami (usługi przechowującej zaszyfrowane klucze i kontrolującej dostęp).
- Rotacja: Odnawiaj klucze w regularnych odstępach czasu (np. co 90 dni); W przypadku podejrzenia wycieku należy natychmiast anulować operację.
- Ograniczenie zakresu: Każdy przełącznik posiada jedynie wymagany serwis i wymaganą autoryzację.
- Audyt: Rejestruj, kto, kiedy i gdzie użył klucza.
Cztery szablony do kopiowania
Monit kontroli dostępu:
Dla każdego narzędzia z poniższej listy narzędzi oceń: - Czy to narzędzie jest WYMAGANE do wykonywania pracy tego asystenta? (tak/nie) - Czy jest to tylko do odczytu, czy do zapisu/kasowania? - Czy to narzędzie jest wywoływane przy użyciu uprawnień użytkownika lub konta usługi? Oznacz niepotrzebne lub nadmiernie autoryzowane jako „USUŃ/REDAKTUJ”.<tools>{{tool_list }</tools>
Monit o skanowanie tajnych wycieków:
Znajdź wszystko, co może być zakodowanym na stałe sekretem, w następującym fragmencie kodu: klucz API, hasło, token, ciąg połączenia, klucz prywatny. Podaj wiersz i wpisz dla każdego. KOPIUJ wartość do odpowiedzi;maska (pierwsze 4 znaki + ***).<kod>{{ źródło }</kod>
Reguła decyzyjna najmniejszej władzy:
Kiedy nadejdzie nowe narzędzie/prośba o dostęp, zapytaj: 1. Czy zadanie można wykonać bez tego dostępu? -> Jeśli tak: ODRZUT2. Czy wystarczy tylko do odczytu? -> Jeśli tak: UDZIEL uprawnienia do zapisu3. Czy zakres można zawęzić do jednego źródła? -> Jeśli tak: daratDomyślna odpowiedź to „nie”; Dostęp uzyskuje się dzięki rozumowi.
Przypomnienie kalendarza rotacji:
Dla każdego sekretu zapisz: właściciela, datę utworzenia, ważność, zakres. Zgłoś każdy klucz, który przekroczył 90 dni lub nie był używany przez 30 dni, jako „KANDYDAT DO OBROTU/ANULOWANIA”.
Słaba podpowiedź/silna podpowiedź
słabe podejście
Mocne podejście
Model ma dostęp do wszystkich danych za pomocą jednego konta usługi
Model uzyskuje dostęp z uprawnieniami użytkownika składającego żądanie
Klucz API jest osadzony w kodzie i nigdy się nie zmienia
Rotacja na stanowisku kierownika ds. kluczowych sekretów, 90 dni
Szerokie uprawnienia asystenta „zrób wszystko”.
Domyślnie tylko do odczytu, pisz wąsko
Dostępy nigdy nie są sprawdzane
Regularny przegląd i cofanie dostępu
Trzy mini etui
Przypadek 1 — Wyciek mieszanych danych proxy. Asystent wewnętrzny pracował z kontem serwisowym, które miało dostęp do wszystkich akt pracowników. Stażysta uzyskał dostęp do danych, których normalnie by nie zobaczył, mówiąc „podsumuj tabelę wynagrodzeń kadry kierowniczej”; ponieważ model kwestionował to w kontekście własnego szerokiego autorytetu, a nie użytkownika. Po dostosowaniu kontekstu użytkownika do przenoszenia stażysta mógł pobrać nagrania, które tylko on lub ona mogła zobaczyć.
Przypadek 2 — Wyciek klucza, rachunek na 190 000 TL w ciągu 2 tygodni. Programista umieścił klucz API modelu w skrypcie pomocniczym i przekazał go do publicznego repozytorium. Bot znalazł klucz w 40 minut i używał go przez dwa tygodnie; Rachunek osiągnął kwotę 190 000 TL. Gdy klucz został przeniesiony do menedżera tajnych informacji, podłączony do rotacji i dodano skanowanie repozytorium, incydent się nie powtórzył.
Przypadek 3 — Domyślne przerwanie tylko do odczytu. Asystent DevOps otrzymał polecenie „zresetuj produkcyjną bazę danych” poprzez natychmiastowe wstrzyknięcie. Asystent otrzymał jednak token tylko do odczytu; zapis/kasowanie odbywał się w oddzielnym zatwierdzonym procesie. Polecenie zostało odrzucone z powodu błędu autoryzacji i zdarzenie zostało zarejestrowane jako alarm; Nie doszło do utraty danych.
Wskazówka: Ustaw „nie” jako domyślną odpowiedź na nową prośbę o dostęp. Dostęp jest czymś uzyskanym poprzez uzasadnienie; Dawanie wszystkim szerokości, a następnie ograniczanie, prawie nigdy się nie zdarza, a ryzyko kumuluje się.
Typowe błędy
- Uruchamianie modelu z dużym kontem usługi i utratą kontekstu użytkownika (mieszane proxy).
- Osadzanie klucza API w kodzie i wyciekanie go do kontroli wersji.
- W ogóle nie obraca klawiszy („działa, nie dotykaj”).
- Domyślnie nadaj asystentowi uprawnienia do zapisu/usuwania.
- Jednorazowe przyznanie dostępu i nigdy ponowne jego rozważenie.
- Mylenie uwierzytelniania z autoryzacją i zakładanie, że „jest zalogowany, ma dostęp do wszystkiego”.
Podsumowując
- Uwierzytelnianie to kwestia „kim jesteś”, autoryzacja to kwestia „co możesz zrobić”; W AI oba muszą działać w kontekście użytkownika.
- Model powinien działać w oparciu o uprawnienia użytkownika składającego żądanie, a nie własne szerokie uprawnienia (unikając ryzyka mieszanej agencji).
- Zacznij od RBAC, pogłębij o ABAC w przypadku wrażliwych danych; Ustaw uprawnienia minimalne jako domyślne.
- Nie chowaj tajemnic w kodzie; przechowuj go w tajnym menedżerze, zawęź go i wprowadź regularną rotację.
- Domyślny tryb tylko do odczytu i wąski zapis znacznie ograniczają wpływ wstrzykiwania.
Zadanie aplikacji
Wypisz wszystkie narzędzia i dane, do których ma dostęp Twój asystent AI. Odpowiedz na trzy pytania dla każdego z nich: (1) Czy jest to naprawdę konieczne? (2) Czy wystarczy tylko do odczytu? (3) Czy działa w kontekście użytkownika? Następnie wyszukaj wszystkie zakodowane na stałe sekrety (poprzez powyższy monit skanowania) i napisz plan rotacji dla każdego znalezionego klucza. Usuń co najmniej jedną niepotrzebną autoryzację.
lista kontrolna
- [ ] Model działa w kontekście uprawnień użytkownika wysyłającego żądanie.
- [ ] Dostęp do narzędzi i danych został zawężony do zasady najmniejszych uprawnień.
- [ ] Zapis/kasowanie jest oddzielny od tylko do odczytu, uwierzytelniany i wąski.
- [ ] W kodzie nie są ukryte żadne tajemnice; Jest przechowywany w tajnym menedżerze.
- [ ] Istnieje harmonogram rotacji i procedura anulowania kluczy.
- [ ] Dostępy są regularnie sprawdzane.