API z danymi regulowanymi zabezpiecza się, modelując, kto mógłby go nadużyć, sprawdzając autoryzację dla każdego obiektu i pola, zbierając i zwracając jak najmniej danych oraz trzymając sekrety i logi audytowe pod ścisłą kontrolą. W praktyce najbardziej liczą się luki w autoryzacji i odpowiedzi ujawniające zbyt wiele danych, a nie złamane szyfrowanie.
Najpierw model zagrożeń dla danych, a nie dla frameworka
Przed wyborem narzędzi trzeba spisać, co API udostępnia i kto mógłby to nadużyć. W banku chodzi o dane kont i transakcji; w firmie energetycznej lub komunalnej mogą to być dane pomiarowe, umowy z klientami i odczyty operacyjne z sieci.
Użyteczny model zagrożeń jest krótki. Wymienia dane wrażliwe, każdego wywołującego, który może do nich dotrzeć, działania, jakie każdy z nich powinien móc wykonać, oraz skutki przejęcia któregokolwiek z nich. Ten dokument wyznacza potem każde z poniższych zabezpieczeń i mówi osobom przeglądającym, co testować.
- Które dane są osobowe, poufne lub regulowane i gdzie są przechowywane.
- Każdy odbiorca API: usługi wewnętrzne, partnerzy, aplikacje mobilne i administratorzy.
- Co każdy odbiorca może odczytać, zmienić lub uruchomić.
- Skutki wycieku tokenu, nieuczciwego pracownika lub przejętego systemu partnera.
Uwierzytelnienie każdego wywołującego, autoryzacja każdego obiektu
Dla użytkowników warto stosować standardowy protokół, taki jak OAuth 2.0 z OpenID Connect, a dla wywołań między usługami krótkotrwałe tokeny lub mutual TLS. Należy unikać długotrwałych, współdzielonych kluczy API, bo nikt nie jest w stanie ustalić, który system ich użył, ani ich unieważnić bez psucia pozostałych.
Uwierzytelnienie dowodzi tylko, kto wywołuje API. Pierwsza pozycja OWASP API Security Top 10 to broken object level authorization: uprawniony użytkownik zmienia identyfikator w żądaniu i odczytuje cudzy rekord. Własność lub przynależność do najemcy trzeba sprawdzać po stronie serwera dla każdego obiektu, każdej funkcji i każdego wrażliwego pola, i nigdy nie ufać identyfikatorowi ani roli przesłanym przez klienta.
Minimalne uprawnienia dla każdego klienta i każdej usługi
Zasada minimalnych uprawnień ogranicza szkody, gdy coś jednak pójdzie nie tak. Każdy odbiorca powinien mieć osobne dane uwierzytelniające, tokeny powinny być ograniczone do konkretnych operacji, a endpointy administracyjne wydzielone na osobnej ścieżce z silniejszymi kontrolami.
Ta sama reguła obowiązuje poniżej API. Konto usługi, które odczytuje dane z liczników, nie powinno móc ich usuwać, a zadanie raportowe powinno łączyć się z bazą przez rolę tylko do odczytu. Uprawnienia warto przeglądać regularnie, bo dostęp przyznany do jednorazowego zadania zwykle zostaje na zawsze.
Mniej zbierać, mniej zwracać, krócej przechowywać
Minimalizacja danych to zarówno zasada RODO, jak i skuteczne zabezpieczenie: dane, których się nie przechowuje, nie mogą wyciec. Dla każdego pola warto zapytać, czy usługa naprawdę go potrzebuje, a to, czego nie potrzebuje, usunąć lub pseudonimizować.
Ta sama dyscyplina dotyczy odpowiedzi. Zamiast serializować całe obiekty z bazy danych, należy definiować jawne schematy odpowiedzi, maskować identyfikatory, takie jak numery kont, tam, gdzie pełna wartość nie jest potrzebna, i ustalać okresy przechowywania, aby stare rekordy były usuwane. Dla każdego celu przetwarzania trzeba udokumentować podstawę prawną i zawrzeć umowy powierzenia z każdym dostawcą, który ma dostęp do danych. To praktyka inżynierska, a nie porada prawna, dlatego ocenę prawną warto powierzyć inspektorowi ochrony danych lub prawnikowi.
Walidacja każdego wejścia i limity dla każdego wywołującego
Każde żądanie należy traktować jako wrogie, dopóki nie zostanie zweryfikowane. Dla każdego endpointu wymusza się schemat, odrzuca nieznane pola i stosuje zapytania parametryzowane, aby dane wejściowe nigdy nie stały się częścią polecenia bazy danych.
Kilka ryzyk z listy OWASP dla API wynika z braku limitów, a nie ze złego kodu. Warto ograniczać liczbę żądań na klienta, limitować rozmiar stron i ładunków oraz chronić wrażliwe procesy biznesowe, takie jak płatności czy zmiany umów, przed automatycznym nadużyciem. Jeśli API pobiera zdalne adresy URL w imieniu wywołujących, trzeba ograniczyć dozwolone miejsca docelowe, aby zapobiec atakom server-side request forgery (SSRF).
Sekrety poza kodem, obrazami i logami
Hasła do baz danych, klucze podpisujące i dane uwierzytelniające partnerów powinny trafiać do dedykowanego menedżera sekretów, być wstrzykiwane w czasie działania i regularnie rotowane. Repozytoria i obrazy kontenerów warto skanować pod kątem sekretów w pipeline budowania, a każdy sekret, który trafił do systemu kontroli wersji, traktować jako ujawniony.
Sekrety rozdziela się według środowisk, aby wyciek testowych danych uwierzytelniających nigdy nie otworzył dostępu do produkcji. Należy ograniczyć, kto może odczytywać sekrety produkcyjne, i rejestrować każdy dostęp do nich.
Logi na potrzeby audytu i projekt, który ogranicza incydenty
Środowiska regulowane muszą po fakcie odpowiedzieć na proste pytanie: kto uzyskał dostęp do jakich danych, kiedy i przez którego klienta. Trzeba to rejestrować przy każdym odczycie i zapisie wrażliwych danych, przechowywać logi tam, gdzie operatorzy aplikacji nie mogą ich zmieniać, i nie umieszczać w komunikatach logów danych osobowych.
Logowanie warto połączyć z alertami o nietypowych wzorcach, na przykład gdy jeden klient odczytuje znacznie więcej rekordów niż zwykle, oraz z przetestowanym planem reagowania na incydenty. Za pośrednictwem Sopra Steria nasi inżynierowie budowali bezpieczne API dla wrażliwych danych sektora użyteczności publicznej w warunkach wymogów regulacyjnych i prowadzili projekt narzędzia do nadzoru operacyjnego, w którym egzekwowane standardy bezpieczeństwa szły w parze z mniejszą liczbą incydentów produkcyjnych. SDK Enterprises stosuje dziś te same praktyki w projektach klientów.
Najważniejsze wnioski
- Krótki, spisany model zagrożeń dla danych powinien wyznaczać każde zabezpieczenie API.
- Autoryzację sprawdza się po stronie serwera dla każdego obiektu, funkcji i wrażliwego pola, a nie tylko przy logowaniu.
- Zasada minimalnych uprawnień dotyczy w równym stopniu tokenów, kont usług i ról w bazie danych.
- Minimalizacja danych zmniejsza zarówno ekspozycję w zakresie RODO, jak i skutki każdego naruszenia.
- Logi audytowe muszą pokazywać, kto, kiedy i do czego uzyskał dostęp, same nie ujawniając danych osobowych.
FAQ
Czy HTTPS wystarczy, aby zabezpieczyć API?
Nie. TLS chroni dane w tranzycie, ale wiele naruszeń API dotyczy uwierzytelnionych wywołujących, którzy docierają do danych, których nie powinni widzieć. Nadal potrzebne są kontrole autoryzacji, walidacja danych wejściowych, limity żądań i logi audytowe.
Czym jest broken object level authorization?
To luka, w której API sprawdza, czy wywołujący jest zalogowany, ale nie sprawdza, czy żądany rekord należy do niego. Zmiana identyfikatora w adresie URL lub treści żądania ujawnia wtedy dane innych użytkowników. Rozwiązaniem jest sprawdzanie po stronie serwera własności lub przynależności do najemcy dla każdego obiektu.
Czy RODO narzuca konkretne zabezpieczenia API?
RODO wymaga odpowiednich środków technicznych i organizacyjnych dostosowanych do ryzyka, nie wskazując konkretnych narzędzi. Ograniczanie dostępu, minimalizacja, pseudonimizacja i logowanie to typowe sposoby spełnienia tego wymogu, a to, co obowiązuje w danym przypadku, powinni potwierdzić Państwa doradcy prawni.