Zaplanowane zadanie czy ludzkie logowanie: jaką tożsamość ma widzieć API?

Zaplanowane zadanie i osoba przy monicie logowania wywołują to samo API z różnymi poświadczeniami, różnym czasem życia i różnymi właścicielami. Zadanie potrzebuje ścieżki sieciowej, tożsamości aplikacji i zestawu uprawnień; osoba potrzebuje logowania, drugiego czynnika i sesji. Mieszanie obu daje automatyzację, która psuje się za każdym razem, gdy zmieni się hasło osoby, albo politykę wieloczynnikową osłabioną dokładnie tak, by zadanie cron pozostało żywe.

Trzy bramy, które wyglądają jak jedna

Reguła adresu źródłowego pyta, skąd przyszło żądanie. Uwierzytelnianie pyta, kto dzwoni i jakie dowody przedstawiono. Autoryzacja pyta, czy ten podmiot może wykonać tę operację. VPN zmienia tylko pierwszą z trzech i zmienia ją dla każdego procesu na hoście, a nie tylko dla zadania, więc trzymaj trzy obserwacje osobno w zapisie incydentu.

Dlatego zmiana węzła wyjściowego może naprawić odrzucenie z powodu adresu źródłowego i zostawić nieprawidłowy token nietknięty. Dlatego też ważny token API nie czyni prywatnego punktu końcowego osiągalnym z zadania, które nie ma do niego trasy.

Ścieżka interaktywna to zły szablon automatyzacji

Skryptowanie logowania osoby kusi, bo działa raz. Skrypt przechowuje hasło, być może ziarno hasła jednorazowego, a potem zależy od wyzwania zaprojektowanego tak, by wymagało człowieka. Obecna najlepsza praktyka bezpieczeństwa OAuth, RFC 9700, zakazuje nadania resource-owner-password-credentials i wyjaśnia, dlaczego słabo pasuje do uwierzytelniania dwuczynnikowego i wieloetapowego.

Wspieraną alternatywą jest zwykle przepływ poufnego klienta, w którym serwer autoryzacji uwierzytelnia aplikację i wydaje token. Nadanie client-credentials w RFC 6749, sekcja 4.4, jest jednym z przykładów. Jego istnienie nie oznacza, że każde API je akceptuje, ani że zadanie delegowane przez użytkownika można nim zastąpić, bo to pytania do właściciela usługi. Zapytaj, jaki model bez nadzoru obsługuje usługa, zanim napiszesz kod.

Gdzie VPN wciąż pasuje

VPN może zapewnić ścieżkę sieciową wymaganą przez prywatne API, i to jest uzasadniona rola. Nie uwierzytelnia zadania wobec aplikacji i nie określa, co zadanie może robić. Wspólny adres wyjściowy identyfikuje też host, a nie zadanie, więc wpis na liście dozwolonych dla tego adresu wpuszcza każdy proces, który na nim działa.

Jeśli zadanie działa na współdzielonym runnerze, to rozróżnienie jest ważniejsze, a nie mniej ważne. Inny przepływ pracy na tym samym hoście dziedziczy trasę i adres, a API nie potrafi ich rozróżnić. To ta sama słabość co współdzielone hasło, przesunięta o warstwę niżej. Umieść ograniczenie tam, gdzie aplikacja może je wyegzekwować, i odizoluj runner, jeśli nie możesz mocniej zawęzić listy dozwolonych.

Porównaj oba projekty uczciwie

Ludzkie logowanie daje prawdziwą osobę, prawdziwy drugi czynnik i sesję, którą można zbadać, i nie może działać bez nadzoru. Tożsamość aplikacji daje wykonanie bez nadzoru, sprawdzalny zakres i poświadczenie, które możesz rotować, i nie może działać w imieniu użytkownika, który niczego nie delegował. Żadne nie jest słabszą wersją drugiego; odpowiadają na różne pytania. Wybieraj, pytając, czy zadanie musi działać bez nikogo obecnego i czy operację trzeba przypisać konkretnemu użytkownikowi.

Jeśli obie odpowiedzi brzmią tak, projekt potrzebuje modelu delegowania, a nie pożyczonego hasła. Zapisz tę decyzję tam, gdzie znajdzie ją następny opiekun.

Co sprawdzić przed przekazaniem

Uruchom jedną dozwoloną operację i jedno wymagane odrzucenie z rzeczywistego workera i zachowaj oba wyniki. Następnie sprawdź wygasłe poświadczenie i zachowanie, gdy ścieżka sieciowa jest niedostępna, bo to te dwa błędy budzą kogoś w nocy.

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

Zapisz podmiot, zakres, właściciela rotacji i środowisko wykonania obok tego wyniku. To właśnie ten zapis czyni kolejną rotację rutyną, a nie incydentem. To także część, o którą prosi audytor.