Bezpieczeństwo automatyzacji — uprawnienia, sekrety, audyt i reakcja
Threat model automatyzacji: minimalne uprawnienia, sekrety, audyt, retencja, monitoring i reakcja na incydent.
Bezpieczeństwo automatyzacji ogranicza zakres działania systemu i pozwala odtworzyć, kto, co i na jakiej podstawie wykonał.
Automatyzacja wykonuje działania szybciej i na większą skalę niż człowiek, dlatego błędne uprawnienie lub przejęty sekret może mieć większy skutek. Bezpieczeństwo powinno być elementem projektu procesu, a nie kontrolą dodaną tuż przed produkcją.
Threat model
Należy wskazać aktywa, aktorów, granice zaufania, punkty wejścia i możliwe skutki nadużycia. Zagrożeniem może być przejęcie konta robota, złośliwy dokument, prompt injection, nieautoryzowane API, manipulacja danymi lub usunięcie logów.
Model zagrożeń powinien obejmować także błąd uprawnionego użytkownika i awarię integracji.
Najmniejsze uprawnienia
Każdy robot, przepływ i agent powinien mieć własną tożsamość oraz tylko uprawnienia potrzebne do zadania. Odczyt nie wymaga prawa zapisu. Utworzenie transakcji nie oznacza prawa jej zatwierdzenia. Zakresy należy okresowo przeglądać.
Sekrety
Hasła, klucze i tokeny należy przechowywać w kontrolowanym magazynie, rotować i ograniczać czas życia. Nie powinny trafiać do kodu, promptu, konfiguracji eksportowanej ani logu. Dostęp do sekretu powinien być audytowany.
Audyt i retencja
Log audytowy powinien wskazywać kto lub co wykonało działanie, kiedy, na jakim obiekcie i z jakim wynikiem. Retencja wynika z potrzeb prawnych, bezpieczeństwa i operacji, ale nie powinna być bezterminowa bez uzasadnienia. Logi muszą być chronione przed modyfikacją.
Reakcja na incydent
Runbook powinien umożliwiać wyłączenie automatyzacji, unieważnienie sekretu, ograniczenie uprawnień, identyfikację dotkniętych spraw i bezpieczne wznowienie. Incydent powinien kończyć się analizą przyczyny oraz korektą zabezpieczeń.
Przykład praktyczny
Agent ma narzędzie do tworzenia wersji roboczej faktury, ale nie do jej zatwierdzania. Token działa tylko w środowisku produkcyjnym dla konkretnego API i wygasa po godzinie. Próba wywołania innej operacji jest odrzucana i zapisywana w audycie. W razie incydentu zespół może natychmiast wyłączyć narzędzie bez zatrzymywania całej aplikacji.
Tabela decyzyjna
| Obszar | Kontrola | Dowód |
|---|---|---|
| Tożsamość | osobne konto techniczne | rejestr tożsamości |
| Uprawnienia | least privilege | macierz dostępów |
| Sekrety | vault i rotacja | log rotacji |
| Dane | minimalizacja i szyfrowanie | klasyfikacja danych |
| Audyt | niezmienny log działań | ślad korelacji |
| Incydent | kill switch i runbook | test odtworzenia |
Checklista
- [ ] Wykonano threat model.
- [ ] Każda automatyzacja ma własną tożsamość.
- [ ] Uprawnienia są minimalne i przeglądane.
- [ ] Sekrety są rotowane i poza kodem.
- [ ] Log audytowy jest chroniony.
- [ ] Przetestowano wyłączenie oraz reakcję na incydent.
Ryzyka i ograniczenia
- Konto wspólne: Nie można przypisać działania ani ograniczyć zakresu.
- Sekret w kodzie: Kopia repozytorium ujawnia dostęp.
- Brak segregacji: Automatyzacja tworzy i zatwierdza operację.
- Brak kill switch: Nie można szybko zatrzymać szkodliwego działania.
Następny krok
- Utwórz model zagrożeń dla wybranego procesu.
- Zweryfikuj uprawnienia i sekrety.
- Przećwicz incydent oraz bezpieczne wznowienie.
Źródła i data weryfikacji
- NIST SP 800-53 Rev. 5 — security and privacy controls
- OWASP API Security Top 10 — 2023
- Microsoft Graph — permissions and least privilege
- NIST AI Risk Management Framework
Data weryfikacji źródeł: 1 sierpnia 2026 r.